This page describes the design of the EODiSP HLA software package. For a better understanding, it is recommended to read the EODiSP HLA architecture page first. Additionally, this document is best read in combination with the EODiSP HLA API documentation. This page contains references to classes and interfaces described in the API documentation and describes associations and interactions between them.

Package Overview

Basically, the RTI design is split into three packages, namely the crc, lrc and a common package. The common package defines the remote interfaces of the CRC and LRC, whereas the other two packages contain the design of the CRC and LRC applications. The latter two packages depend on the common package but not on each other. The next figure shows these package dependencies in a UML package diagram.

The design is driven by the IEEE HLA standard. Two interfaces are defined in the standard: the RTIambassador and the FederateAmbassador interface. The RTIambassador is the interface of the runtime infrastructure as it is seen by a federate. The FederateAmbassador defines the callback interface of a federate as it is seen by the RTI. The EODiSP HLA or, more precisely, the LRC implements the RTIambassador interface. The FederateAmbassador interface needs to be implemented by a federate developer.

The following sections describe the crc and lrc packages in more detail, including their remote interfaces in the common package.

CRC Package

The central RTI component keeps track of its current federation executions and its joined federates along with their subscriptions and publications of object class attributes and interactions. By design, this information shall only be stored on the CRC and never on the LRC. This centralized approach makes sure that only the most up-to-date information is being accessed by any federate. In practice this means that the LRC does not save (cache) any information about subscriptions and publications of a federate, but always receives this information from the CRC.

The CRC makes available two remote interfaces, the CrcRemote and FederationExecutionRemote interfaces. The CrcRemote interface handles general queries not related to a particular federation execution, whereas the FederationExecutionRemote interface handles request targeted to a federation execution. Figure 2 shows the UML diagram of these interfaces.

The core design of the CRC is defined in the crc package. There's one central class, the Crc class, from which most other classes and interfaces are reachable. It manages federation executions, which in turn manage their joined federates. The joined federates hold the subscriptions and publications of object classes and interactions.

The two remote interfaces, CrcRemote and LrcRemote, are implemented by dedicated Impl classes. The remote interfaces are not directly implemented by the core classes (namely, the Crc and FederationExecution) to make distinguish remote calls from local calls easier and to separate the remote interfaces from local interfaces/classes. Note that the FederationExecution class maintains a (strong) reference to the FederationExecutionRemoteImpl class. This is needed because the remote invocation method infrastructure used with EODiSP HLA does not use a distributed garbage collector. Having a reference from a federation execution makes sure that a instance of FederationExecutionRemoteImpl only gets garbage collected (and thus unexported) when the the federation execution is destroyed. Otherwise the instance of FederationExecutionRemoteImpl would possibly be garbage collected too early.

LRC Package

The local RTI component manages one or more local federates. It routes service calls from these local federates to the CRC or to other federates (through their LRCs). An LRC does not save the state of a federation execution or federate but receives all information about subscriptions and publications from the CRC.

The LRC exports two interfaces, the LrcRemote interface (remote) to receive callbacks from the CRC and other LRCs, and the RTIambassador interface (local) to receive service calls from its managed federates. The remote interface is shown in Figure 3.

With the current design, all callbacks from other LRCs and the CRC go through the LrcRemote interface. Another possible approach would have been to export a remote interface for each federate that is managed by the Lrc. However, exporting only one interface allows to transfer data that is needed by more than one local federate only once and then distribute this data to each federate locally.

The implementation of the LrcRemote interface takes the same approach as the remote interface implementations of the crc package. The LrcRemote interface is not directly implemented by the Lrc class but by the LrcRemoteImpl class. This makes distinction between calls originating from a local federate (through the RtiAmbassador interface) and calls origination from remote LRCs or CRCs easier and makes the remote interface independent of other lrc classes and interfaces.