Mixing Service Oriented and High Level Architectures in Support of the GIG Björn Möller Staffan Löf Pitch Technologies Nygatan 35 SE-582 19 Linköping, Sweden +46 13 13 45 45
[email protected] [email protected] Keywords: HLA, RTI, Web Services, Service Oriented Architecture, GIG, Network Based Defense ABSTRACT: Two powerful architectures for interoperability, HLA and SOA (Service Oriented Architectures) have been developed during the past ten years. HLA has been developed within the defense simulation community. SOA has been developed within the commercial enterprise community. At first they may seem quite similar but a closer look reveals fundamental differences in the view of interoperability, the modeling approach and the level of built-in functionality. Still there are several ways these architectures can coexist and provide different types of value in a Global Information Grid (GIG) environment. Two projects with practical experimentation have been carried out to show this. In the "HLA Web Service API Experimentation", carried out between Sweden and the US, we have collected engineering support and analyzed a web service API with classical HLA semantics. In the Swedish "HLA and SOA integration" in support for the network based defence, we have created and tested a prototypical architecture that allows service based and HLA based systems to interoperate. A third architecture that automatically defines domain-oriented services based on the FOM is also discussed. These experiments and architectures show that it is quite easy to add service oriented functionality on top of an RTI. Using this approach service based and HLA based systems can coexist and interoperate. They also show that there are considerable problems with starting out with a traditional SOA-based service and add other separate services to achieve the functionality that federated simulations need and that HLA already provides. This article summarizes experiences from these experiments and architectures and highlights implications for the GIG.
1. Introduction M&S interoperability as defined in the DoDD 5000.59 [1] stands for “The ability of a [...] simulation to provide services to, and accept services from, other [...] simulations, and to use the services so exchanged to enable them to operate effectively together.” While interoperability in many other contexts may be perceived as a general ability to exchange data, the requirement to be able to operate effectively together raises the bar considerably. Some approaches to structure interoperability are well accepted in the community, for example: Technical interoperability – basically the ability to technically exchange data. Semantic interoperability – which adds the requirements to interpret exchanged data in a consistent way between different systems.
Substantive interoperability – which adds the ultimate requirement that systems should interoperate in such a way that the goals of the system are achieved. More refined approaches exist or development, for example LCIM [2].
are
under
1.1 About HLA The High Level Architecture [3] as it stands today represents an approach to solve the technical interoperability and provide support for the substantive interoperability. Technical interoperability is achieved using an “intelligent data bus” where participating systems can exchange data through a publish and subscribe approach. There is no need for systems to be aware of each other, only to share a common information model which is explicitly defined in an XML based format. This approach facilitates composability and reuse since existing systems can be reused in new contexts and new systems can be added to existing federations. HLA also provides a set of services for synchronization of time, time stamp
ordered delivery of data, save, synchronization points as well as functionality for managing responsibilities. 1.2 About SOA and Web Services A service-oriented architecture (SOA) [4] is a collection of services providing an ability, for example, to exchange information. Some of the first serviceoriented architectures were based on CORBA [5] or DCOM [6] technologies. Today SOA based on Web Service and XML/SOAP [7] technology is in focus for civilian enterprise integration. Services are defined using a Web Service Definition Language (WSDL) [8] and published in directories based on the UDDI [9] meta-service. One of the main advantages is that Web Services is supported by a wide range of operating systems and development/deployment environments.
1.5 Three approaches This paper describes three approaches for mixing HLA and Service Oriented Architectures and provides some practical experiences from two of them: •
The Web enabling of the HLA Interface Specification
•
The SOA to HLA Connector
•
The unified SOA and HLA approach
2. Web Enabling the HLA Interface Specification An experiment with web enabling the HLA Interface Specification (IEEE 1516.1-2000) has been carried out. 2.1 Scope
Figure 1: Typical Web Service usage A typical web service provides a domain oriented service, like “Get account balance”. It is usually provided by a front-end server that connects to enterprise servers, often using proprietary mechanisms. The exchange is done in a client server mode with a request/response scheme similar to a web browser. It is worth noting that the services provided are on a “higher”, more business-oriented level than the RTI services. They are technically carried out through a request/response mechanism on a “lower” level, that is, with less functionality than the information exchange in an HLA federation carried out by the RTI.
The task was to provide a technical approach, engineering support and guidelines for the design of a Web Service ”API” for HLA IEEE 1516.1. Note that this really means creating a set of Web Services that correspond to the HLA Interface Specification, not an API associated with any particular programming language. The web services should be described using WSDL. A subset of the WSDL should be tested to gain practical experience and judge the suitability of different approaches. In this first step it was not possible to implement all of the functionality due to resource and time limitations. While the authors believe that it is possible to “web enable” HLA in several ways this approach focuses on web enabling the HLA Interface Specification. 2.2 Design criteria A number of design criteria were established as a first step:
1.3 Why mix HLA and SOA?
No HLA redefinition. We are not redesigning HLA or any of its fundamental semantics. “Classic” HLA compliance should be maintained. It should be transparent to the federation whether a specific federate uses the C++, Java or Web Service API.
During the last ten years HLA has matured and been used to make complex sets of simulations interoperate in state-of-the art setups. The built-in services of HLA cooperate in a complex way to provide filtered and synchronized information to federates.
User acceptance. The web service API should be likely to be accepted in the web service community that we are targeting. This means that we favor Web Service style constructs over exact mapping to the current specification.
In a larger context it has been considered useful to mix HLA and web services. This enables a closer integration of simulation based systems with traditional operational systems in a systems-of-systems approach. Simulation-based capabilities like training, decision support and what-if analysis would thus be readily available and create greater value than today.
Real world usage. A web service API should be likely to be used in real life. It should be easy to use in commonly used Web Service development environments. The performance should be satisfactory for a reasonably large user community.
2.3 Three challenges and solutions During the redesign three major challenges were discovered and solutions for these were suggested:
which is good web service style as well as a practical solution. The most obvious alternative is to provide information in a SOAP header. This would not be captured in WSDL or be guaranteed to be neutral between all WS environments. 2.4 Suggested mapping Instead of translating the HLA services one by one to WSDL a set of guidelines were created showing how to map the services in IEEE 1516.1 to web services constructs. The mapping uses the following standard XML name spaces: XML Schema, prefix: xsd Namespace: http://www.w3.org/2001/XMLSchema
Figure 2: Web Service versus HLA data exchange A) Client-server versus two-way exchange. In Web Services a client invokes a service and data is returned. In HLA there is a spontaneous two-way exchange of information being delivered to and from a federate. The suggested solution is to let the federate provide a callback endpoint when establishing a connection. This is unconventional in the Web Service world and should be optional. Otherwise the federate has to call a service to get callbacks. This can be seen as similar to ”EvokeCallback” and ”EvokeMultipleCallbacks” in IEEE 1516.1. B) Encoding of data. HLA uses machine-native binary data formats whereas Web Services uses stringencoded data. The suggested solution is to string-encode all data. This also applies to references to FOM data. Object class names, attribute names, etc should be referred to by name instead of handles. This is common practice for a web service and also intuitive and easy-to-use. It may however cause some discussion in the HLA community since it differs from the handle approach in the C++ and Java API. C) Maintaining RTI state associated with the calling federate. The RTI (usually the RTI ambassador) needs to maintain its state between the calls. Federates using Web Services will not have an RTI ambassador. The ”RTI Ambassador” may actually reside on the RTI Web Service provider. The suggested solution is to introduce a parameter SessionID in all calls so the server can maintain state. This is similar to ”cookies” used with Web browsers. This will also allow one application to join as several federates, which has been requested by users of the C++ and Java APIs. In addition it will allow several federates to connect to the same RTI Web Service
SOAP encoding, prefix: soapenc Namespace: http://schemas.xmlsoap.org/soap/encoding The suggested mapping looks like this: C++/Java API Construct Web Service Construct RTI Ambassador
SessionID as soapenc:base64Binary
Federate & object handles
Federate & object name as xsd:string
Class, attribute, interaction, parameter & dimension handles
Class, attribute, interaction, parameter & dimension name as xsd:string
Attribute, parameter, user defined tag values
soapenc: base64Binary
Timestamp values (binary) xsd:integer Retraction handles, Region soapenc: base64Binary ID (opaque RTI data) Enumerated RTI parameters (example: Resign directive)
xsd:string
Pairs, lists
XML lists
Figure 3: Mapping IEEE 1516.1 to Web Services These mappings provide an intuitive and easy-to-use Web Service API. Note that some support services for handles are not used since class and attribute names (etc) are used directly. Time stamp values are communicated as integer strings. This removes the problem with sharing time implementations as long as all implementations are large enough to correctly represent the numbers. This means that a ParseString method needs to be added for LogicalTime [10] implementations.
2.5 Sample code WSDL provides definitions of both the requests and responses of a Web Service call. The following is an example of a WSDL definition of a request:
