Software Technologies for the Interoperability ...

Software Technologies for the Interoperability, Reusability and Adaptability of Distributed Simulators A. D’Ambrogio, D. Gianni, G. Iazeolla Department of Computer Science University of Rome TorVergata Via del Politecnico, 1 00133, Roma, Italy {dambro, gianni, iazeolla}@info.uniroma2.it Keywords: Interoperability, Reusability, Adaptability, Framework, HLA, CORBA.

ABSTRACT: Giving interoperability and reusability capabilities to distributed simulators is fundamental to the widespread use of distributed simulation. The HLA standard has introduced considerable improvements with respect to previous standards, though it suffers from shortcomings such as (1) lack of interoperability among different IEEE-compliant implementations, (2) no support to the adaptation and integration of individual federates and (3) poor reusability, which is limited to entire federates only. In this paper, we present two independent technologies that overcome such shortcomings. The first technology consists of a CORBA-HLA architecture that overcomes limitation (1), the second technology is a new development framework called SimJ that overcomes limitations (2) and (3). The CORBA-HLA architecture decouples federates from the specific HLA implementation so that federates can be effortlessly run on top of any HLA implementation that exposes services through an IEEE-complaint IDL interface. The SimJ framework eases the development of individual federates by providing a uniform and standard interface for local and distributed simulators, and makes it possible the reuse of components smaller than entire federates in both local and distributed simulators.

1. Introduction Current distributed simulation technologies provide a valid but not complete support for the development of distributed simulators. Indeed the development of distributed simulators does not rely on software technologies that, when applied to the development of traditional distributed software systems, allow to improve those quality attributes that have a direct impact on productivity, such as reusability, interoperability and adaptability. The integration with such technologies seems inevitable for the convenient use of distributed simulation technologies and for their widespread beyond the initial military domain [1]. A well-known and widely adopted distributed simulation technology is the High Level Architecture (HLA) [2]. An HLA-based distributed simulator is generally developed by adapting existing federates

(i.e., units of simulation) and/or by coding new ones from scratch. A non negligible effort is always needed to adapt a federate to a new interaction object model. Moreover, some rework has to be done in order to run a federate on top of a different, yet compliant, HLA implementation. Analogously, distributed simulation architectures do not support the development of federate internal structure because they aim to be reused in as many as possible domains and therefore do not deal with local issues. In summary, the development of an HLA-based distributed simulator software is characterized by: •

poor reusability, because the reuse strategy takes into consideration only entire simulators and not finer grain components running inside them.

•

poor interoperability, because an extra effort is always needed to adapt simulators to

different, though infrastructures. •

fully

compliant, HLA

poor adaptability, because an extra effort is always needed to implement basic coordination and synchronization mechanisms, and to adapt local simulators to different conceptual frameworks.

This paper introduces two independent technologies that overcome the above mentioned shortcomings and bring effort savings to the whole development process: CORBA-HLA [3], which improves simulator reusability and interoperability; and SimJ [4], which improves simulator reusability and adaptability. CORBA-HLA, by leveraging highly interoperable protocols across simulator domain, overcomes HLA interoperability shortcomings. Specifically, it brings technical interoperability into HLA [5]. SimJ introduces fine grain component reuse and provides a uniform interface that allows developing of distributed simulators with no extra effort compared to local ones. This paper is organized as follows: first, a brief background on HLA and CORBA is given; second, the CORBA-HLA integration is introduced; third, the SimJ framework is presented. 1.1 Related works The need for increased HLA interoperability and reusability is an issue that is gaining considerable attention. On the contrary, the adaptability of HLA services has not been generally addressed because it is clear that raising the level of abstraction of low-level general-purpose HLA services inevitably leads to limitations in terms of flexibility. This is often not acceptable in military domain simulations, but it is worth being considered in the field of Discrete Event Simulation (DES) [6]. Concerning interoperability, various projects introduced short and long term solutions. Short term solutions mostly adopt the idea of using interoperable protocols for general purpose distributed computing to vehicle HLA calls and data, as CORBA-HLA does [3]. In this group, projects to be mentioned are Pitch Web Service API [7], XMSF [8], Grid-based HLA [9]; all adopting SOAP as a communication protocol. In the long term, the most noticeable engagement is the SISO project for an Inter-RTI standard protocol [10]. Concerning reusability, HLA community main efforts focus on standardizing the format of communication

data exchanged by federates. On the other hand, local simulation environments (e.g., CSIM [11], Arena [12], Extend [13], Modline [14], etc.) facilitate the development of local simulators, by use of simulation languages, but they do not have the capabilities to interoperate according to HLA standard [15]. The extension of such languages to include HLA support can be very problematic, particularly in the case of proprietary languages. Typical extension mechanisms are based on the use of wrapping techniques, which however can lead to unstable code and poor simulator maintainability, because the wrappers contain some logic of their own in addition to the simulator logic [16]. For these reasons, the development of individual federates is mostly carried out by use of standard programming languages (e.g., C, Java, etc.) with the additional effort of developing: simulation mechanisms, simulator components and interfaces to the HLA. Other libraries and frameworks are available to support the development of individual simulators. The most known are PDNS [17], Dis-SimJava [18], D-SOL [19] and μSik [20]. PDNS enables ns [21] to distribute simulate, and therefore it is only suitable for computer network simulation. Dis-SimJava and D-SOL does not use HLA; whereas μSik cares of simulator performance, instead of reusability and interoperability. 1.2 Background 1.1.2 HLA 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 [2]. 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) [22]. A HLA simulation consists of [2]: • a set of Federates, each representing a unit of simulation which can be of three types: o a remote simulation program;

o an interface to control the behavior of live participants (human in the loop); o 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). Sim ulation Utilities FederateAmbassador

Sim ulation Program s FederateAmbassador

objects may invoke services of other objects on a distributed system without knowledge of their locations and implementations [26].

Live Participants Interface FederateAmbassador

Figure 2 CORBA architecture RTIambassador

RTIambassador

RTIambassador

Runtime Infrastructure Figure 1 Main components of a HLA simulation Federate – RTI interactions are carried out through standard HLA interfaces. 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. RTI implementations provide the RTIambassador library to be used by federates, whereas they let simulator developers care of implementing the FederateAmbassador interface for given federate. The IEEE Standard 1516 consists of four documents: • • • •

1516 HLA Rules, which govern the behavior of both the federation and the federates [15]; 1516.1 Object Model Template, which defines the formats for documenting HLA simulations [23]; 1516.2 Interface Specification, which defines both the RTI -- federate and the federate -RTI interfaces [24]; 1516.3 Federate Execution and DEvelopment Process, which provides a reference process for the development of HLA simulations [25].

1.1.3 CORBA CORBA is an OMG's standard for distributed object computing. The main feature of CORBA is that client

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, etc.), 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, which 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 [26].

2. CORBA-HLA The system architecture is made up of [3] a CORBAHLA server, a RTI server and n hosts that run federates (Figure 3). The CORBA-HLA server is the host that exposes RTI services to the CORBA environment; it therefore includes CORBA-HLA server side components and RTI local components to interact with the RTI server. The RTI server is the host that runs the RTI. This host interacts only with the CORBA-HLA server, where the RTI local components are run. The n hosts run the federates that are involved in the federation execution; they interact only with the CORBA-HLA Server, which acts as a front-end for the actual HLA implementation.

Local RTI

IDL Interface





CORBA HLA Proxy Class

RTI Implementation

IDL Interface

IDL Stub

IDL Skeleton

CORB A HLA Server Class

b)

An intrinsic feature of this approach is that CORBA hides the physical location and the platform details of CORBA server that elaborates HLA requests.

Local RTI

ORB Host 1

hla.rti

Figure 4 Client side (a) and Server side (b) schema Host n

Local RTI

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 through remote CORBA servers. Such assumptions are reflected in the architecture, which includes a CORBA-HLA Proxy, running on each host, and a CORBA-HLA Server, running on the CORBA-HLA 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. It uses the IDL stub to send HLA requests to the CORBA-HLA Server Class, which wraps the complete RTI implementation. The IDL interfaces, specify the set of services that vehicle HLA requests and responses. They are given to a idltojava compiler which generates client stub and server skeleton.

a)

... Host 2

1.

RTI

RTI Executive

Local RTI

Implementation

RTI Server

Key HLA Service request / response flow Federate CORBA-HLA (either Local RTI or RTI Executive) Pitch Local RTI

Figure 3 CORBA-HLA system architecture The main advantages of such approach are that the federate sites do not need an actual RTIAmbassador, because HLA service calls are sent through the ORB to the RTI server, and that federates are dynamically linked to a given RTI server, specifically the one that fits the federation needs. The proposed approach is based on the following assumptions:

Figure 5 describes the typical steps of a HLA service request. The federate invokes (1) a RTIambassador service through CORBA RTI Ambassador, which makes all the needed conversions and forwards (2) the request to the ORB. Then the ORB transparently delivers service calls and parameter data to the associated CORBA RTI Server (3), which first converts data to a local manageable format (4) and then re-places the service call to the actual RTIambassador (4). Afterwards, RTI Local library operates as usual; it interacts with RTI Executive (5). Similarly, the communication process from RTI executive to federates. RTI Executive notifies RTI Local library (6) of a call back service, i.e. a FederateAmbassador service. Upon receiving the call, CORBA RTI Server performs the needed data conversions (7) before sending it out (8). The ORB then delivers it to CORBA RTI Proxy (9), which forwards the request to the standard FederateAmbassador interface (10), which in its turn sends to the federate.

Site 1

Site 2

Federate 1

Federate 2

CORBA/HLA Client (Proxy)

CORBA/HLA Server (RTI A)

CORBA/HLA Server (RTI B)

RTI A Local Library

RTI B Local Library

IIOP RTI A Executive

IPC local calls

RTI B Executive

Figure 5 Switching federates from different For its feature, CORBA-HLA improves HLA reusability and interoperability because of: - federate decoupling from specific RTI implementations; -

federate reuse across HLA standard and not standard programming languages, like Fortran, etc.

Specifically, the former is obtained by the client-server independence, whereas the latter is obtained by CORBA interoperability across programming languages. An example of how a federate can instantaneously switch, and thus be reused, from a RTI A to a RTI B is shown in Figure 6. Federate 1, developed with CORBA-HLA, can effortlessly switch from Server A, which uses RTI A, to Server B, which uses RTI B.

support for a Web-enabled Simulation Environment (WSE) [27] [28]. Examples of these services are: - register services, to discover federates available; - security services; to crypt federate-RTI communication, authenticate and authorize federates to join in federations. 2.2 Drawbacks – CORBA-HLA preliminary performance tests The main disadvantage of the proposed solution may be identified from the efficiency point of view. The use of the IIOP protocol and of get-and-forward clients and servers introduces additional overheads and precludes the use of multicasting communication. However, CORBA-HLA has been shown to reach acceptable execution time / simulated time ratios in NWAN (National WAN) to support real time application (Figure 77 shows the execution configuration). Different and unsatisfactory results were reached in IWAN (Intercontinental WAN), Figure 8. A preliminary performance analysis detected that the main cause of CORBA-HLA overheads is the latency time introduced by double-way implementations of some HLA services. Although such services could be implemented as one-way, they would require the introduction of specific control logic within the CORBA client. However, this solution contrasts with the main purpose of the CORBA-HLA architecture, which proposes CORBA as a mere intermediary between the federates and an actual RTI implementation. Italy

Key Federate

Grid resource

IIOP protocol Pitch protocol over TCP and UDP pRTI 1516

ORB and CORBA RTI

HLA ov er

IIOP

Federate 3 Client

TorVe rgata CORBA R TI Server

Le cce

Figure 6 Steps of a HLA service request SimLab

2.1 Beyond using CORBA to improve HLA interoperability and reusability Server

HLA integration with CORBA can go beyond the simple use of get-and-forward client and server components to improve HLA interoperability and reusability. In fact, CORBA also provides general services for distributed software that might give a

FederationManager

Federate 1

Executive

Federate 0

Local Client

Client

Client

Figure 7 NWAN Execution configuration

US - Georgia

A simulation component represents a structural building block upon which a simulator can be designed and composed. The components of a SimJ simulator can be grouped into entities, events, ports and links, as illustrated in Figure 9.

Italy

CoC's LAN Ge orgi a Te ch

WAN

TorVe rgata COR BA R TI Se rv er

Federate 2

Client

SimLab

Key Federate IIOP protocol Pitch protocol over T CP and UDP pRT I 1516

Server FederationManager

Federate 1

Client

Client

Executive

Federate 0

Local

ORB and CORBA RT I

Client

Figure 8 IWAN Execution configuration

3. SimJ SimJ [4] is a Java-based framework for the development of local and distributed discrete event simulators with HLA. SimJ main feature is that simulation components are locally developed and then immediately available for deployment in local simulators, running on a single host, and distributed simulators, running on a set of hosts connected by a network infrastructure, with no extra effort. Such features improve HLA reusability and adaptability. The reusability is improved because fine grain local components can be deployed in distributed environments and reused in several distributed simulators. The adaptability is improved because simulator developers do not have to deal with basic local-todistributed environment interactions; instead, they define simulation components’ logic as they were to be run in a common local simulator framework. This is achieved by introducing an abstract interface to the simulation execution, whose inner implementation takes care of all the details needed to execute the simulator either in a local or distributed execution environment, so that simulator developers only deal with the abstract interface and are not concerned with the execution details. Currently, SimJ only supports the use of the HLA as a distributed simulation infrastructure standard and the PI simulation paradigm. Nevertheless, its modular design allows the easy addition of further DES paradigms and DS standards. The SimJ architecture is funded on the concepts of simulation component and simulation engine.

Figure 9. SimJ simulation components A SimJ entity represents a logical process, i.e., the fundamental building block in the PI simulation paradigm. SimJ events represent both the fundamental building blocks in the ES paradigm (not yet implemented in SimJ) and the basic events needed in the PI paradigm, such as start events, notify events, sleep events and so forth. SimJ events also encapsulate the mechanisms to serialize/deserialize events exchanged by remote entities in a distributed simulation. A SimJ port is used by a simulation entity to exchange events with other entities. A port can be of either output or input type. Entities send and receive events through the output and the input ports, respectively. Finally, Simj links connect the output ports of sending entities to the input ports of receiving entities. In such a way sending entities are decoupled from receiving ones. The SimJ simulation engine is the facility responsible for the simulation initialization and execution. It is implemented in SimJ by a class hierarchy whose root provides a common interface that is then refined by actual implementations of engines for different DES paradigms [29], execution environment (either local or distributed) and DS standards. The next two sections describe SimJ components and engines in more details. 3.1 SimJ COMPONENTS The components of a SimJ simulator can be grouped into entities, events, ports and links. The next subsections illustrate how such components are implemented and used to build a SimJ simulator. 3.1.1 SimJ Entities and Events

SimJ provides a hierarchy of classes. Entity is the root class, which represents the common properties of

generic entity, further specialized in LocalEntity and RemoteEntity. LocalEntity defines common properties of every simulation entity running locally. SimJ developers can specialize this class into entities for a given simulation application (e.g., entities that represent aircrafts for an air traffic management simulation application or routers for a computer network simulation application). The specialization can be achieved by defining the entity’s logic through redefinition of the abstract method body. The logic includes mathematical computation and invocation of engine’s services. By means of such services, they are able to send events; wait for incoming event, time or condition; or hold on for a given time. Once a custom library of local entities has been developed, it can be provide to SimJ users, who will be able to build their simulators by simply connecting entities through proper links. RemoteEntity is a local reference to a LocalEntity running in a remote SimJ. Since it does not incorporate custom logic, its definition comes with SimJ. Local entity interacts with other entities, either local or remote entities, by use of abstract engine’s services. It is engine’s duty to distinguish between local entity and remote entity.

3.1.2 SimJ Events

SimJ events are organized in the class hierarchy shown in Figure 10. The root class defines a common event abstraction for every simulation paradigm. It provides

the process method that has to be specialized to build either ES simulation components or standard events for the PI paradigm (e.g. start, notify, sleep, etc.). PEvent class is the base class for all PI paradigm events. It includes attributes such as sender, recipient, time, tag and data, and methods to serialize/deserialize events when exchanged over the distributed simulation architecture. PLocal defines the base notification event that is specialized to implement the other basic events (wait, hold) for the PI paradigm. Local to distributed events, as well as distributed to local, are incorporated in such hierarchy and therefore can be handled by the engine in the same way as the local ones. 3.1.3 Ports

A SimJ port is used by a simulation entity to exchange events with other entities. The main advantage of using ports is that entities can interact without referencing directly to each other. This increases their degree of reusability. A port can be of output or input type. Entities send events to output ports and receive events from input ports. Output ports are directly addressed by entities that send events, while input ports are only used as shortcuts for the receiving entities (the event source can indeed be inferred by the event itself). Each SimJ port is characterized by its owner (the entity to which it belongs) and the link to which it is connected. 3.1.4 Links

A SimJ link connects the output ports of sending entities to the input ports of receiving entities. They decouple sending entities and receiving ones, and implement one-to-one, one-to-many, many-to-one and many-to-many associations between sending entities (output ports) and receiving entities (input ports). For each link the simulation engine checks that it actually connects output to input ports and schedules events on all its input ports. 3.1.5 SimJ Simulation Engines

Figure 10 SimJ Event's hierarchy

A SimJ simulation engine is responsible for the simulation initialization and execution. SimJ provides several types of simulation engines for the each DES paradigms and specific DS standards. An Engine root class provides a common abstract interface for simulation initialization and execution (i.e. simulation start and event scheduling), as illustrated by the class diagram in Figure 11. SimJ currently only implements the simulation engine for the PI paradigm and the HLA standard.

The local and distributed simulation engines for the PI simulation paradigm are described in the next two subsections, respectively. SimEngine

ES_SimEngine

AS_SimEngine

PI_SimEngine

PI_Local_SimEngine

PI_HLA_SimEngine

Figure 11. SimJ simulation engines 3.1.5.1 Local Simulation Engine

This engine introduces the basic support for the PI paradigm. It provides the implementation of services send, wait and hold through the scheduling of specific type of events, below described; and a set of synchronization primitives to manage the execution of the entities (i.e., the logical processes in the PI paradigm). The engine’s core method is the start method. It repeats a sequential series of entity activations, conditionally to entity runnable state, and a series of event processing, until the simulation end is reached. Entity activations are the execution of defined segments of entity behaviour between two wait or hold service requests. Once all the entity have been activated, thus no further activation are possible, it enters the event processing cycle. Processing events, the engine might bring some entities to a runnable state again. For example an entity blocked on a wait request will be runnable again once an event is received. The engine guarantees simulation reproducibility and causality, respectively, by enforcing entity activation order and activating one entity at time; and by forbidding sending of events to past time. 3.1.5.2 Distributed Simulation Engine

This engine extends the local engine by implementing event scheduling services for remote recipients, by redefining the start method and by allowing the reception of distributed events.

The new scheduling services perform first a check to determine whether the recipient is local or remote, then if they have to deliver a local recipient event, they simply call the upper schedule event method. Otherwise, they wrap the event in a HLA interaction, and properly schedule it into the distributed system by means of the HLA sendInteraction service. The start method now includes a distributed system initialization and takes into account that distributed events might be received before the next local event time. Therefore, the start method advances to the next event time before processing it. The method needs not take into account incoming distributed events because it allows its FederateAmbassador to transparently schedule local versions of distributed event into its event list. The local version is the result of unwrapping procedure operated on incoming HLA interaction. After having unwrapped the distributed event, the FederateAmbassador checks whether the event has local recipient or not. In the case it has, the local version, completely processable by “local” engine, is scheduled into the engine’s event list. Otherwise, the event is discarded. This check is necessary because of HLA broadcasting communication mechanisms. The blocking time advancement to the next local event time is realized by synchronizing time advance request to their expected time advance grant. The engine requesting a time advance request to t will not be allowed to proceed with its execution until it is not notified with a time advance grant to time t. Distributed engines’ life cycle is regulated by an external component named Federation Manager [2], according to HLA terminology. The manager creates the distributed simulation (the federation in HLA terms), joins it and waits for other federates (instances of distributed engines) to join. When all federates have joined the federation, the manager starts the subscription to the distributed events of interest. When all federates have subscribed, the manager starts the federation execution. It continues until all federates receive the simulation end event. At this time, each engine processes the local simulation end, and quits the federation. Then, the manager itself quits and destroys the federation. The distributed simulation engine has been designed to be distributed platform independent, though it can now be only run on top a RTI infrastructure.

To improve reusability across RTI implementations, however, SimJ introduces a LogicalTimeFactorySimpleDataTypes interface, which extends the HLA LogicalTimeFactory interface. In such a way, LogicalTime objects are instantiated by use of simple data types (double, long, etc.), independently of the specific RTI implementation. In its current version, SimJ comes with implementation of factory interfaces on pRTI1516 [30] and CORBA-HLA [3]. Other HLA implementations can be immediately used by just implementing the LogicalTimeFactory interface.

4. Conclusions This paper has introduced two independent technologies that improve the interoperability, the reusability, and the adaptability of HLA-based software. By leveraging IIOP, CORBA-HLA brings technical interoperability into HLA [5]. Federates can now be effortlessly switched from a HLA compliant implementation to another without reworking. This also improves federates reusability. By introducing a DES abstraction for the components development, SimJ brings fine grain component reuse into the HLA. Simulation components can be now developed locally and then indifferently deployed in a local or distributed environment without any extra effort. Besides that, SimJ also improves the adaptability of HLA primitives by providing simulation developers with a local-like DES conceptual framework to develop distributed simulation components.

5. References [1] A. Tolk, “Avoiding another Green Elephant – A Proposal for the Next Generation HLA based on the Model Driven Architecture”, 2002 Fall Simulation Interoperability Workshop, 02F-SIW004, Simulation Standards Organization, Orlando, Florida, September 2002. [2] F. Khul, R. Weatherly, J. Dahmann: Creating Computer Simulation Systems: An Introduction to High Level Architecture. Prentice Hall (1999) [3] A. D’Ambrogio and D. Gianni, “Using CORBA to enhance HLA interoperability in Distributed and Web-based Simulation”, Proceedings of International Symposium on Computer and Information Science 2004 (ISCIS04), Antalya, Turkey, Springer-Verlag, pp 696-705, October 2004.

[4] A. D'Ambrogio, D. Gianni and G. Iazeolla, “SimJ: A Framework to Develop Distributed Simulators”, Proceedings of the 2006 Summer Computer Simulation Conference (SCSC06), pp. 149-156, August, 2006, Calgary, Canada [5] A. Tolk, “What Comes After the Semantic Web – PADS Implication for the Dynamic Web”, Proceedings of the 20th Workshop on Principles of Advance in Distributed Simulation (PADS06), May 2006, Singapore [6] E. Page, S. Griffin, S. Lynn Rother, “Providing Conceptual Framework Support for Distributed and Web-based Simulation within High Level Architecture”, Proceedings of the SPIE: Enabling Technologies for Simulation Science II, April, 1998 [7] Björn Möller, Staffan Löf “A Management Overview of the HLA Evolved Web Service API”, 2006 Fall Simulation Interoperability Workshop, 06F-SIW-024, Simulation Interoperability Standards Organization, September 2006. [8] eXtensible Modeling and Simulation Framework (XMFS) Project http://www. MovesInstitute.org/xmsf. [9] Y. Xie, Y.M. Teo, W. Cai, S.J. Turner, “Servicing Provisioning for HLA-Based Distributed Simulation on the Grid”, Proceedings of the 19th Workshop on Principles of Advanced and Distributed Simulation (PADS05), pp. 282 – 291, June, Monterey, CA, US, IEEE Computer Society [10] D. Stratton, S. Parr, J. Miller: Developing an open-source RTI community. In: 2004 Spring Simulation Interoperability Workshop, SISO (2004). [11] Mesquite Software, http://www.mesquite.com.

CSIM19,

[12] Rockwell Automation, http://www.arenasimulation.com.

Arena,

[13] Imagine That Inc., http://www.imaginethatinc.com.

Extend,

[14] Simulog, http://www.simulog.fr/ps/mod1.htm.

Modline,

[15] IEEE: Standard for Modeling and Simulation (M&S) High Level Architecture (HLA) frameworks and rules. Technical Report 1516, IEEE (2000). [16] A. Verbraeck, “Component-based Distributed Simulation”, Proceedings of the 18th Workshop

on Parallel and Distributed Simulation (PADS04), pp. 141-148, Kuftein, Austria, May, 2004. [17] G. Riley, M. Ammar, R. Fujimoto, A. Park, K. Perumalla and D. Xu, “A Federated Approach to Distributed Network Simulation”, ACM Transaction on Modeling and Computer Simulation (TOMACS), Vol. 14, n. 2, Apr, 2004. [18] E.H. Page, R.L. Moose and S.P. Griffin, “WebBased Simulation in SimJava using Remote Method Invocation”, Proceedings of the 1997 Winter Simulation Conference, Atlanta, GA, pp 468-474, December 1997. [19] P. Jacobs, N. Lang, A. Verbraeck, “D-SOL: A Distributed Java Based Discrete Event Simulation Architecture”, Proceedings of the 2002 Winter Simulation Conference, San Diego, CA, 8-11 December, pp 793-800. [20] K. Perumalla, “μsik: A Micro-kernel for Parallel/Distributed Simulation Systems”, Proceedings of the 19th Workshop on Parallel and Distributed Simulation (PADS’05), Monterey, CA, June 2005. [21] ns2, http://www.isi.edu/nsnam/ns/. [22] F. Kuhl: Distributed simulation systems (DSS) specification. Technical Report 02-11-11, OMG (November 2002) OMG Document formal/02-1111. [23] IEEE: Standard for modeling and simulation (M&S) High Level Architecture (HLA) - object model template (OMT) specification. Technical Report 1516.2, IEEE (2000).

[24] IEEE: Standard for modeling and simulation (M&S) High Level Architecture (HLA) - federate interface specification. Technical Report 1516.1, IEEE (2000). [25] IEEE: Recommended practice for High Level Architecture (HLA) federation development and execution process (FEDEP). Technical Report 1516.3, IEEE (2003). [26] T. Mowbray, W. Ruh, Inside CORBA Distributed Object Standards and Application, Addison Wesley (1997). [27] A. D’Ambrogio, G. Iazeolla, “Distributed Systems for Web-based Simulation”, Proceedings of the 13th International Symposium on Computer and Information Sciences, ISCIS98, Ankara, Turkey, 1998. [28] G. Iazeolla, A. D’Ambrogio, “A Web-based Simulation Environment for the Reuse of Simulation Models”, Proceedings of the 1998 International Conference on Web-based Modeling and Simulation (Part of the 1998 SCS Western Multiconference on Computer Simulation), SCS, San Diego, CA, US, 1998. [29] J. Banks, J. Carson, B.L. Nelson and D. Nicol, Discrete-Event System Simulation, 4th ed., Prentice-Hall, 2005. [30] Pitch pRTI1516 Product http://www.pitch.se/prti1516/.

Page,