Technical Report 1516, IEEE (2000). 2. F. Khul, R. Weatherly, J. Dahmann: Creating Computer Simulation Systems: An. Introduction to High Level Architecture.
Using CORBA to enhance HLA interoperability in distributed and web-based simulation? A. D’Ambrogio and D. Gianni Department of Computer Science, System and Production University of Rome TorVergata, 1 Via del Politecnico, I-00133 Rome (Italy) {dambro,gianni}@info.uniroma2.it
Abstract. In distributed simulation various simulation programs, or else components of a given simulation program, interact as elements of a simulation-oriented distributed computation. The High Level Architecture (HLA) is a standardization effort that provides a general framework for promoting interoperability and reusability in the simulation field. When applied to distributed simulation HLA shows some drawbacks that limit the desired degree of interoperability and reusability. This paper proposes a CORBA-based approach to overcome such drawbacks and improve HLA capabilities. The paper also illustrates how to combine the use of HLA and CORBA for web-based simulation, which is the extension of distributed simulation to web-based network infrastructures.
1
Introduction
In distributed simulation complex simulation scenarios are built through the interconnection of a number of simulation programs in which simulated entities interact and cooperate among themselves. Such simulation programs may be executed on distributed, heterogeneous HW/SW platforms connected by a LAN/WAN infrastructure. The term distributed is to be interpreted in the sense of traditional distributed computing, based on the client/server paradigm. Although distributed simulation has been originally developed for military applications, the term is here used to mean a broader range of applications in the simulation field. HLA is a widely accepted standard that provides a general framework to promote interoperability and reusability in the simulation field. Nevertheless, when applied to distributed simulation, HLA shows some drawbacks that reduce its expected capabilities. This is mainly due to the fact that HLA has been ?
Work partially supported by funds from the FIRB project ”Software frameworks and technologies for the development and maintenance of open-source distributed simulation code, oriented to the manufacturing field” and by the University of Rome TorVergata CERTIA Research Center.
designed to be simulation-specific and not as a general framework for distributed computing. On the other hand, CORBA is a well-known standard designed to provide high levels of interoperability for distributed object computing, but it is not simulation-specific. This paper proposes a CORBA-based approach to increase the degree of interoperability in HLA-based distributed simulation applications. The paper also illustrates how to combine the use of CORBA and HLA for web-based simulation, which is the extension of distributed simulation to web platforms. The paper is organized as follows: Section 1 gives a short overview about HLA and CORBA, Section 2 describes the proposed CORBA-based approach to improve interoperability and reusability of distributed simulation HLA applications while Section 3 extends the proposed approach to web-based simulation, by illustrating how CORBA can be used to implement web-based HLA applications. Finally, Section 4 outlines the related work.
2
Background
This section briefly reviews the basic features of HLA and CORBA, illustrated in Section 2.1 and 2.2 respectively. 2.1
High Level Architecture (HLA)
The HLA provides a general framework within which simulation developers can structure and describe their simulation applications. HLA promotes interoperability between simulation applications and reusability of simulation components in different contexts [1]. Although it has been originally introduced by the Defense Modeling and Simulation Office (DMSO) of the U.S. DoD in 1995, HLA has been published as IEEE standard number 1516 in 2000 and is currently used by many organizations working both in the industry and in the research field. To certify its wide acceptance, HLA has also been recognized as a facility for distributed simulation by the OMG (Object Management Group). A HLA simulation consists of [2]: – a set of Federates, each representing a unit of simulation which can be of three types: • a remote simulation program; • an interface to control the behavior of live participants (human in the loop); • a simulation utility (e.g., data collector, passive viewer, etc.); – a Federation, that identifies the overall simulation consisting of the set of federates; – a RTI (Run Time Infrastructure), which is a simulation oriented middleware that provides services for communication and coordination among federates, time synchronization and simulation management. Federates interact through the RTI by use of either data sharing (HLA Objects) or messages exchange (HLA Interactions).
Simulation Utilities FederateAmbassador
RTIambassador
Simulation Programs FederateAmbassador
RTIambassador
Live Participants Interface FederateAmbassador
RTIambassador
Runtime Infrastructure Fig. 1. Main components of a HLA simulation
Figure 1 shows a typical HLA simulation and highlights how the interaction between federates and RTI is carried out. On the federate side the RTIambassador is used as a local interface to access the RTI services, while on the RTI side the FederateAmbassador is used as a local reference to the federate. A complete RTI implementation provides both the RTIambassador library to be used by federates and the FederateAmbassador library to be used by the RTI. The IEEE Standard 1516 consists of four parts: – 1516 HLA Rules, which govern the behavior of both the federation and the federates [1]; – 1516.1 Object Model Template, which defines the formats for documenting HLA simulations [3]; – 1516.2 Interface Specification, which defines both the RTI – federate and the federate – RTI interfaces [4]; – 1516.3 Federate Execution and DEvelopment Process, which provides a reference process for the development of HLA simulations [5]. 2.2
Common Object Request Broker Architecture (CORBA)
CORBA is an OMG’s standard for distributed object computing. The main feature of CORBA is that client objects may invoke services of other objects on a distributed system without knowledge of their locations and implementations [6]. The object interface is defined by use of IDL (Interface Definition Language), a declarative language which is independent of the implementation language, the location, the hardware and software architecture and the network technology. IDL provides both basic and constructed data types and operations to define services offered by the objects. The interface declaration defines the construct that holds data types and operations. An IDL compiler is available to map IDL
into any programming language (e.g. C, C++, Java), thus achieving a high degree of interoperability and reusability. A CORBA-based distributed application consists of clients that request services offered by remote servers (or object implementations). The Object Request Broker (ORB ) provides communication transparency by operating control and data transfers between clients and servers. A CORBA ORB supports two kinds of client/server invocations: static and dynamic. In the static approach, the client uses IDL stubs to send a request to the object implementation on the server side. These IDL client stubs, as well as the associated IDL server stubs (called IDL skeletons), are automatically generated by compiling the IDL code that defines the interface to the services. In the dynamic approach, the Dynamic Invocation Interface (DII ) allows clients to construct and issue a request by discovering the method to be invoked at run time. On the server side, an Object Adapter resides between the object implementations and the ORB. It provides the run time environment for instantiating object implementations, passing requests to them and assigning them an object reference, that is the mechanism used by the ORB to identify, locate, activate and manage object implementations. CORBA is part of the Object Management Architecture (OMA), which defines additional services for CORBA-based distributed applications. Example services are the Naming Service, for registering object implementations and obtaining object references, and the Security Service, which provides a security infrastructure for object authentication and authorization [6].
3
The HLA/CORBA combined approach for distributed simulation
As already mentioned in Section 1.1, HLA is widely accepted as a general framework for promoting interoperability and reusability in the simulation field. Nevertheless HLA shows some drawbacks that reduce its expected capabilities when used for the development of distributed simulation applications. This is mainly due to the fact that HLA has been designed to be simulationspecific and not as a general framework for distributed computing. As an example, HLA only defines interfaces for simulation datatypes without specifying how to convert them into basic datatypes. Moreover, HLA does not define the format of protocol data units that allow to establish the communication between remote federates through the RTI. For such reasons, the following shortcomings can be identified: 1. the federates are tied to a specific implementation of the RTI; 2. different RTI implementations do not interoperate. One more limitation of currently available RTI implementations is the lack of widely used open source implementations, that could be easily adopted to broaden the HLA usage and obtain an increased level of reusability. Even though
this weakness cannot be directly ascribed to HLA, which only defines the API without specifying implementation details, it has to be taken into consideration when evaluating the reusability properties of current distributed simulation applications. Our proposal overcomes the aforementioned disadvantages by use of a CORBAbased approach, that allows to obtain higher levels of interoperability and reusability, along with location and platform transparency. Moreover, several open source CORBA implementations are currently available. The CORBA-based approach obtains such benefits by introducing an open source implementation of HLA interfaces on the CORBA client side, which makes use of a private RTI implementation executing on the CORBA server side, as better described in the following section. 3.1
HLA/CORBA architecture
Figure 2 illustrates the proposed HLA/CORBA architecture for distributed simulation applications. The application is started by a person or a software component (activation agent) that is responsible for the activation (dashed lines) of the set of federates (papyri) executed on the hosts 1 through n of the distributed platform (each host executes one or more federates). The architecture also includes a RTI server, that provides a complete RTI implementation (RTIAmbassador and FederateAmbassador) to the set of federates running on the remote hosts. HLA service requests and responses, as well as activation requests, are sent through the ORB to the RTI server. The main advantage of such a solution is that the federates do not need a local RTIAmbassador implementation because they makes use of the one provided by the RTI server. The proposed approach is based on the following assumptions: 1. the federates must be HLA compliant, in other words they must be able to use HLA services specified by the IEEE standard 1516; 2. the implementation of the HLA interfaces are available by use of remote CORBA servers Such assumptions are reflected in the implementation of each federate, which is split into a CORBA-HLA Proxy, running on one of the available hosts (1 through n), and a CORBA-HLA Server, running on the RTI server. The full HLA compliance is guaranteed by the implementation schema illustrated by the class diagram in Figure 4. The CORBA-HLA Proxy class is a Java class that implements the HLA Java interface specified by the IEEE standard 1516 and uses the IDL stub to send HLA requests to the CORBA-HLA Server Class, that includes the complete RTI implementation. The IDL interfaces that are compiled to obtain client stub and server skeleton specify the set of services that vehicle HLA requests and responses. An important feature of this approach is that CORBA, with its location and platform transparency, hides the complexity of the back-end infrastructure used
... Host n
Host 2
ORB Activation Agent Host 1
RTI
Key Activation request flow HLA Service request / response flow Federate
Implementation
RTIServer
Fig. 2. Global view of the HLA/CORBA architecture
to elaborate HLA requests. Figure 3 describes the typical steps of a HLA service request. The CORBA-HLA Proxy Class uses the IDL stub (arrow 1) to send a HLA request to the ORB (arrow 2), making all conversions needed to transport data (e.g., objects serialization on byte array or string). The request is then transparently transferred from the client side to the server side (arrow 3), where the skeleton gathers the request and activates the CORBA-HLA Server Class (arrow 4), which in turn is responsible for elaborating the HLA request by use of the RTI implementation (arrow 5). The CORBA-based approach allows to increase the degree of interoperability and reusability of HLA distributed applications, because of the following features: – federates can be developed without the need of a specific RTI implementation; they are only required to send HLA requests by use of CORBA, for which several open source implementations are available; – federates implemented in a given programming language can use a RTI implementation available for a different language without requiring additional bridging libraries. Moreover, the federates can actually be implemented in programming language whose binding is not yet specified by the IEEE HLA standard (only C++, Java and Ada95 mappings are currently defined); – federates can join federations implemented by use of different RTI implementations (wrapped by different CORBA-HLA Servers);
CORBA HLA Proxy Class
CORBA HLA Servant Class
5
4
1
RTI Implementation
IDL STUB
IDL SKELETON
3
2
ORB
Fig. 3. Steps of a HLA service request
hla.rti
IDL Interface
CORBA HLA Proxy Class
IDL Stub
a)
RTI Implementation
IDL Interface
IDL Skeleton
CORBA HLA Server Class
b) Fig. 4. Client side (a) and Server side (b) schema
– CORBA Services can effectively be used to provide additional features to distributed simulation applications. As an example, the Security Service can be used to authenticate federates and verify if they are authorized to join a specific federation. The main disadvantage of the proposed solution may be identified from the efficiency point of view. The use of the CORBA-based infrastructure to vehicle HLA requests and responses introduces additional overhead and precludes the use of multicasting communication and message caching. However, it must be noted that the CORBA-based transmission of requests and responses is not CPU intensive, and that by adopting solutions with a lower degree of interoperability the impact on the overall efficiency can be further reduced. As an example, HLA data structures could be directly implemented on the CORBA client side instead than accessing them on the server side, thus limiting the degree of interoperability but reducing the number of remote interactions.
4
Extension to web-based simulation
Web-based simulation is a recently introduced term to denote the use of web technology in the simulation field. As illustrated in [7], web-based simulation applications can be classified in the areas of: – Web-enabled Simulation Environments (WSE ), or environments that facilitate the reuse of simulation programs available on the web [8]; – Web-based Distributed Interactive Simulation (WDIS ), or the extension of the distributed simulation approach to web-based network infrastructures. Figure 5 illustrates a WDIS-oriented extension to the HLA/CORBA approach illustrated in Section 3. The user interacts with the HLA/CORBA distributed simulation application by use of a common Web browser. On the Web server side a Web Simulation Manager component is executed to implement both the web interface (run on the web browser) and the necessary conversion work to transform HTTP requests into IIOP requests. The IIOP (Internet Inter-Orb Protocol ) defines a set of message formats and common data representations for ORB-based communications over a TCP/IP network [6]. The Web Simulation Manager forwards user requests to the back-end HLA/ CORBA distributed simulation application by use of the following CORBA servers: – the Federates Server, which is executed to select the set of federates from a list of available federates and then to activate the selected ones; – the Federation Controller, which manages the execution of the federation; – the Federate Controllers, which manage the execution of the federates (1 through n) joining the federation; – the Simulation Results Server, which records the simulation results for offline detailed analysis or to get useful data for future simulation applications. Figure 5 shows that the web server is only used to interface common web browsers to the back-end infrastructure, where CORBA-based protocols and servers are used to wrap the HLA/CORBA distributed simulation application. Unfortunately, neither HLA nor CORBA hold all the necessary characteristics to fully exploit the web capabilities. As an example, the use of IIOP for ORBbased communication denies the transmission of requests and responses through network firewalls, that typically allows HTTP traffic only. Work is in progress to combine HLA and Web Services technology in order to obtain a more effective and convenient solution for web-based simulation.
5
Related work
The need for increased interoperability between different HLA implementations is an issue that is gaining considerable attention. Research in this field is addressing the development of a standardized inter-RTI protocol, in analogy to the
Web Server Federates Server
ORB
Federation Controller IIOP
HTTP IIOP Web Browser
Federate 1 Controller
... Web Simulation Manager
HLA/CORBA distributed simulation application
Federate n Controller Simulation Results Server
Fig. 5. HLA/CORBA architecture for web-based simulation
inter-ORB protocol (IIOP) that has been developed in response to the lack of interoperability between different CORBA implementations. Work is in progress both at SISO (Simulation Interoperability Standards Organization) [9] and at research institutions leading the development of the XMSF (Extensible Modeling and Simulation Framework) [10]. The HLA/CORBA integrated architecture this paper proposes represents a short-term solution to the availability of a standard inter-RTI protocol, which is not expected to happen in the immediate future. Previous efforts dealing with the use of IDL for the description of HLA interfaces, such as the one sponsored by the DMSO [11] and the Bachmann’s work [12], have not been successful nor adequately considered within the SISO community [13], due to the following main drawbacks that have instead been overcome by the approach illustrated in Section 3: – the need for specific functions to convert HLA interfaces into their equivalent IDL interfaces; – the explicit description of basic datatypes to be used for implementing HLA interfaces for simulation datatypes, which are instead left undefined by the IEEE HLA standard 1516, that enforces this choice by explicitly providing examples implementations of simulation datatypes that use different basic datatypes; An alternative solution to the lack of interoperability between different HLA implementations is the development of appropriate gateways between two heterogeneous federations. A gateway should be placed at the boundary of each federation, executed by different HLA implementations, and be responsible of the necessary data conversion to guarantee the communication between heterogeneous federates. Unfortunately, the gateway-based approach has shown to introduce deadlocks [14] and, however, it does not primarily address RTI interoperability aspects.
6
Conclusions
The characteristics of distributed simulation applications and the associated HLA limitations in terms of interoperability and reusability have been illustrated. A CORBA-based approach that overcomes such limitations has been introduced. The approach maintains a full HLA compliance by use of a CORBA infrastructure that provides transparent and uniform access to the heterogeneous RTI implementations. A proposed extension to web-based simulation has also been illustrated.
References 1. IEEE: Standard for modeling and simulation (M&S) High Level Architecture (HLA) - frameworks and rules. Technical Report 1516, IEEE (2000) 2. F. Khul, R. Weatherly, J. Dahmann: Creating Computer Simulation Systems: An Introduction to High Level Architecture. Prentice Hall (1999) 3. IEEE: Standard for modeling and simulation (M&S) High Level Architecture (HLA) - federate interface specification. Technical Report 1516.1, IEEE (2000) 4. IEEE: Standard for modeling and simulation (M&S) High Level Architecture (HLA) - object model template (OMT) specification. Technical Report 1516.2, IEEE (2000) 5. IEEE: Recommended practice for High Level Architecture (HLA) federation development and execution process (FEDEP). Technical Report 1516.3, IEEE (2003) 6. T. Mowbray, W. Ruh: Inside CORBA Distributed Object Standards and Applications. Addison Wesley (1997) 7. A. D’Ambrogio, G. Iazeolla: Distributed systems for web-based simulation. In: The 13th International Symposium on Computer and Information Sciences ISCIS98 Ankara TURKEY. (1998) 8. G. Iazeolla, A. D’Ambrogio: A web-based environment for the reuse of simulation models. In: Proceedings of the 1998 International Conference on Web-Based Modeling and Simulation (Part of the 1998 SCS Western MultiConference on Computer Simulation), SCS Western MultiConference on Computer Simulation, SCS (1998) 9. D. Stratton, S. Parr, J. Miller: Developing an open-source RTI community. In: 2004 Spring Simulation Interoperability Workshop, SISO (2004) 10. eXtensible Modeling and Simulation Framework (XMFS) Project http://www. MovesInstitute.org/xmsf. 11. F. Kuhl: Distributed simulation systems (DSS) specification. Technical Report 02-11-11, OMG (November 2002) OMG Document formal/02-11-11. 12. R. Bachmann: HLA und CORBA: Ans¨ atze zur verbesserten integration. In: HLAForum der Tagung Simulation und Visualisierung 200. (2001) 13. A. Tolk: Avoiding another green elephant - a proposal for the next generation HLA based on the Model Driven Architecture. In: 2002 Fall Simulation Interoperability Workshop, VMASC (2002) 14. J. Dingel, D. Garlan, C. Damon: Bridging the HLA: Problems and Solutions In: Sixth IEEE International Workshop on Distributed Simulation and Real Time Applications - Fort Worth, Texas, USA, October 2002
