This page describes the design of the EODiSP core software package. For a better understanding, it is recommended to read the EODiSP core architecture page first. Additionally, this document is best read in combination with the EODiSP core API documentation.

Overview

The EODiSP core is split into three components: the simulation manager application, the model manager application and the model repository. The next sections provide an overview of the design of these components.

Repository

The model repository is a central place that stores information shared by the simulation manager and the model managers. The repository makes this information available through the ReposModelService interface (the remote interface is made available to clients by a remote object exported through EODiSP remote). It is essential and necessary that both the simulation manager and the model manager applications have a connection to a repository in order to function properly. Since these two applications can be run in local mode (i.e. without any network connection), the model repository application can also be installed locally on the computer where a simulation will eventually be running.

The data in the repository is stored in an XML file. This was chosen because all persistent data in the EODiSP framework are stored in this way. It has the advantage of not adding additional dependencies to the application. The data model of the repository is shown as a UML class diagram in Figure 1.

The Repository class serves as the root object from which all other objects are reachable. First, the Repository stores Categories and SOM's. A Category can be used to categorize different projects (e.g. an EarthCARE simulation could be a category that would hold all models that are relevant to the EarthCARE simulation). This is useful for repository clients which are interested in only one ore some categories, since it limits the amount of data to be transfered. The categorization is done upon the SOM objects, hence the link from the Category to the SOM object. The back reference (the link from the SOM object to the Category object) is used in order to allow a SOM to participate in multiple Categories without redefining or copying the SOM.

The SOM object itself links to federates whose implementation conform to the specification in the SOM. The Federate object references objects with information such as the model manager application it will run on or the init declaration data it expects.

Additionally, the repository stores a unique Id for each model manager (ModelManager class) and simulation manager (SimManager class) application. These Id's will be stored as soon as an application registers itself with the repository. Repository clients do not store any information about the manager applications but hold only a reference in form of this Id. This, again, limits the need for data updates in case the information changes.

All data that are stored in the model repository should not be duplicated in another application to avoid update conflicts in case of changes. This is the reason why an EODiSP application can only work together with a functional model repository.

The data that is stored in the repository needs to be transferred over the network to repository clients (in the case of the EODiSP, this will be at least the simulation manager and the model manager applications). This is a common requirement in distributed applications or frameworks and it requires the objects to be transferred to be serializable. One option would be to write these objects manually. For the model repository, however, an existing solution has been chosen. The solution is called Service Data Objects (SDO). It is implemented as a thin layer on top of EMF, which is used to manage the XML data store of the repository. SDO in combination with EMF is capable of creating so called data graphs from an XML data store such as the one used in the model repository. These data graphs can be serialized and sent over the network. The form of a serialized data graph is itself XML. The transferred data graph can be used on the client side to perform changes. All these changes are recorded within the data graph in order to be sent them back to the model repository. The model repository will inspect the changes made by the client and commit them to the actual XML data store.

SDO is a specification from IBM. Its documentation is available at SDO specification. It has a defined set of interfaces that allow a client to operate on a data graph in a generic way. This means that the client does not need to know where the data represented by the data graph is coming from. The client always operates on the same interfaces. This, in principle, would allow the model repository to change its storage back-end to something else than XML (e.g. a relational database).

Simulation Manager

The simulation manager application consists of a core and a GUI part. Here, only the core part is described, the GUI part has its own documentation section.

The core part of the simulation manager application is used mainly to encapsulate common, not GUI-related functionalities into separate packages. Thus, it provides services to work with the repository and to manipulate their own model data. This separation would make it possible to replace the whole GUI implementation.

In addition to the data on the repository, the simulation manager application stores some local data. The UML class diagram in the next figure shows its data model.

The SmProject serves as the root class. It contains objects of two classes; Simulation experiments (Experiments object) and federations (Federations object). As mentioned above, the simulation manager application does not locally store information that is available from a repository. It does, however, store a remote Id of the object it references. This remote Id is of the form of a UUID and can be used to retrieve a referenced object (with its data) from the repository. In the case of the simulation manager application, two objects store such a remote Id, the LocalFederate object, which is a reference to a Federate object in the repository, and the LocalInitDecl object, which is a reference to a InitDecl object in the repository.

The simulation manager core package implementation can be used through interfaces that expose the functionality of the application. For instance, the simulation manager application GUI uses this interface to retrieve data from the repository, to start a simulation experiment, etc. Two interfaces are defined for this purpose:

• Interface for the simulation manager core functionality. This includes functions such as start an simulation experiment, connect to the repository, etc. This interface is described in the Javadoc documentation available at: SmCoreService. This interface is only available locally, i.e. it is not exported by the EODiSP remote package.
• Interface to work with the project model of the simulation manager application. Hence, this is the access code for the data illustrated in Figure 2 above. This interface is described in the Javadoc documentation available at: SmModelService. This interface is only available locally, i.e. it is not exported by the EODiSP remote package.

Model Manager

From a design point of view, the model manager application is very similar to the simulation manager application described in the previous section. It also consists of a core and a GUI component, and again, only the core part is described here. The GUI part has its own documentation section.

The model manager has some data that it stores locally. This is illustrated in the UML class diagram in the next figure.

The root object is the MmProject. It contains LocalSOM and LocalFederate objects with associated data. Unlike the simulation manager application, some data are stored locally and remotely on the repository. This is true for the name and description attribute of the LocalFederate object and the description attribute of the LocalSOM object. The reason to store this informations on both nodes is to avoid the situation where a model manager cannot connect to a repository and thus looses the informations about a Federate or SOM it actually owns. This data replication is however not critical because only one model manager (the owning one) can update this informations on the repository. Therefore, no update conflicts will occur. On the other hand, it makes it possible to register federates or SOM's in more than one repository without rewriting all the information.

In addition to the connection to the repository, the model manager serves as a remote component for the simulation manager. This is described in the core architecture documentation at Core Architecture. This interface is defined in the EODiSP core package and is exported by using the facilities provided by the EODiSP remote package. The interface is described in the Javadoc documentation available at ModelManagerRemote. It provides methods to start and stop a federate on the model manager.