ABSTRACT: The HLA RTI is accessed using a standard service API that is independent of application domain. A popular approach to simplify the use of HLA is to hand-code, or to generate an object-oriented RTI
middleware with an API that closely matches a specific FOM. This is informally known as Object Oriented HLA (OO-HLA).
This paper describes OO-HLA with pros and cons and points to some important design considerations. It also
summarizes some practical experiences from designing, implementing and using a COTS product that generates OO-HLA middleware in C++ and Java.
OO-HLA middleware can greatly simplify the implementation of HLA interfaces for federates, improve qualityand save time and money. At the same time, such a FOM-specific API will never be able to support generic,
domain-independent tools, for example for federation management and data logging, thus limiting the potential for reuse. Another fact that reduces the potential of OO-HLA APIs, as compared to the current standardizedHLA API, is that one single FOM will never be able to support all current and future interoperability needs.
There are fundamental differences between object oriented programming languages and HLA. A number of assumptions about how a federate wants to use for example ownership, DDM and time management must be
made in order to support these services in an object oriented API. Similarly it is also necessary to make a number of assumptions about the HLA-based interplay between federates in order to fully use object oriented features such as method invocations.
The overall conclusions are as follows:
- It is of great benefit to both have access to the traditional, generic HLA API and to be able to hand-code or
generate FOM-specific object-oriented middleware. - A commonly used subset of the full HLA functionality directly matches the object-oriented constructs.
- For more advanced HLA concepts the object oriented paradigm is too limited to allow a direct mapping.
These concepts, like time management, ownership and DDM can indeed be made available based on additional
utility classes, design patterns and exception handling. There are several potential structures of such an API, for example with respect to time-stamping and ownership. Different designs will match different users needs. - It is possible to create one standardized API pattern for OO-HLA but it is more likely that several different
designs patterns are necessary to support different users needs.
Authors: Björn Möller, Fredrik Antelius
Publication: Proceedings of 2010 Spring Simulation Interoperability Workshop, 10S-SIW-058, Simulation Interoperability Standards Organization, April 2010.