application development tools such as Borland C++ Builder and Microsoft Visual Basic, can be chosen for federate development. Recompilation of the federates ...
A COM Component Set for HLA Interface Specification Zeki Savas Cengiz, Halit Oguztuzun Department of Computer Engineering Middle East Technical University 06531 Ankara,Turkey {zsavas, oguztuzun}@ceng.metu.edu.tr Keywords: High Level Architecture (HLA), Run-Time Infrastructure (RTI), Component Based Development (CBD), Component Object Model (COM)
ABSTRACT: We present a Microsoft Component Object Model (COM) component set to mediate between the userprovided HLA federate code and DMSO RTI, providing programming language interoperability. By using this component set, any programming environment capable of creating and using COM objects, in particular, rapid application development tools such as Borland C++ Builder and Microsoft Visual Basic, can be chosen for federate development. Recompilation of the federates is avoided in case of switching to another RTI implementation; only the component needs to be ported to the new RTI. Implementation and testing issues of the components are also discussed. 1. Introduction
1.1 Motivation
Component-Based Development (CBD) refers to the techniques and tools that allow the construction of applications from both new and preexisting components [4]. There is no reason not to apply component-based development process to High Level Architecture (HLA) based simulation applications. In fact, HLA itself is a component architecture and defines a component model. When we think a federation as a component-based application, federates represent components. In this point of view CBD process is applied up to federate level. From another point of view a federate can be built from reusable components. These components can connect to each other at run time to form a federate.
One constituent of the HLA is the Interface Specification, which defines the set of services and identifies callbacks that are used by federates to interact with each other [1]. The Interface Specification includes over 125 services. Run-Time Infrastructure (RTI) is the software that implements the HLA interface specification.
In this paper, we describe a Microsoft COM (Component Object Model) component set for HLA Interface Specification that can be easily used in any programming language/environment, such as MS Visual Basic, MS Visual C++ and Borland C++ Builder, that supports the COM component model under Microsoft Windows operating systems. We use two different component models, HLA and COM, together and access HLA objects from COM environment.
With the acceptance of HLA as a standard, different RTI implementations started to appear in the market. The number of HLA-based simulations we develop in our research center also increases. Most of the simulations we develop run under Windows operating systems. Today these simulations use DMSO RTI, but in future another RTI can be used and this will bring the problem of modifying and recompiling existing simulation applications. If we use the RTI services from a component that is running under Windows Operating System in simulation development, in case of RTI change we need only to modify the component. There is no need to recompile the applications. This approach also allows multilanguage development as COM is a binary standard. Interfaces and the implementations are separated from each other. Any language processor that complies with this binary standard can create or use COM objects [5].
1.2 Problem Definition
2.2 Component Models
While developing HLA-based simulations using DMSO RTI NG 1.3 v.3.2 libraries in Windows Operating System, for a programming language there are two options: Java and Microsoft VC++ 6.0. But we have other simulations and components that are not HLAbased and written in other programming languages. This brings the problem of rewriting these simulations completely in VC++ 6.0 or in Java, in order to make HLA-based simulation. Accessing RTI services through a component set of Microsoft Component Object Model from applications solves the problem.
A component model defines standards for constructing components, and rules for composition, communication and interaction with other components. The Object Management Group’s (OMG’s) Common Object Request Architecture (CORBA) Component Model, SUN Microsystems’ Enterprise JavaBeans Component Model and Microsoft’s Component Object Model (COM) are widely used component models. Overviews of these component models are presented in [3] and [14].
2. Related Work/Background There are several past SIW papers that discuss component based simulation development. In [5] using COM technologies in simulation development is discussed. Usage of JavaBeans component architecture for HLA federate development is presented in [6] and [7]. [9] discusses how simulation models can be used as components in distributed simulation systems. In [8] how the Micro Saint Simulation software models interoperate by using COM services is presented. In [10] an overview of CBD process is given and a componentbased framework for the development of HLA-based simulation is introduced. 2.1 What is a Component? Although there is no universally accepted definition for what a software component is, there are many definitions proposed in the literature. Some definitions that apply to our work are presented here. “A software component is a software element that conforms to a component model and can be independently deployed and composed without modification according to a composition standard.” [3]. Other relevant definitions are as follows. A definition from [2] states “software components are binary units of independent production, acquisition, and deployment that interact to form a functioning system”. “A component is a chunk of software that offers related services accessible through a standard interface.” [4]. A detailed discussion on component terminology is found in [15].
A component model implementation is “ a dedicated set of executable software elements required to support the execution of components that conform to the model” [3].
3. Component Object Model (COM) COM is an architecture for “component reuse that allows dynamic and efficient composition of systems from independently developed binary components” [11]. It is a specification that is based on binary standard for reuse through interfaces. This binary standard allows multilanguage development. A COM component implemented in Visual Basic can easily be used in any programming language/environment that supports COM, such as Visual C++. The crucial notion in COM is that of an interface. An interface is a group of public methods of a component. A component can have multiple interfaces. Components interact with each other through their interfaces. An interface definition language (IDL) is used to specify the names of methods and their parameters in an interface to provide programming language independence. For each COM component package, for each interface and class, a globally unique identifier, a 128-bit integer, is used. Microsoft Interface Definition Language (MIDL) compiler compiles the IDL code into the C source file and header files. It also generates type libraries with .tlb extension. These type libraries can be used to define the types of the component interfaces and to access methods on interfaces in various languages. For example, in C++, #import “component.tlb” imports the component type library and thereby defines the interface pointer types by appending the suffix Ptr to the interface names. If a component contains IRti interface, by using IRtiPtr a component instance can be created and then the methods IRti provides can be accessed. Pointers like IRtiPtr are called smart pointers [12]. All COM components have the same base interface that is called IUnknown, which defines three methods:
• • •
AddRef( ) Release( ) QueryInterface( )
QueryInterface allows to query a component if it contains a COM class we specify with an Interface ID; if it does, we get a pointer to it, else we get an error code [12]. IUnknown only defines these functions. Implementing them is the job of the producer of the COM component.
as an ActiveX control. The main difference between the two versions is the method of passing FederateAmbassador callbacks to the federate. While writing a COM component the choice of binding type is important. To support late binding, another interface called IDispatch must be implemented. However, late binding is restricted to the argument types that OLE32.DLL supports. Proxy/Stub codes for custom data types that can be used in early binding can not be used in late binding.
A COM component can be in the form of Dynamic Link Library (DLL) or files with .exe extension. COM components can be grouped as • • •
Out-of-process server In-Process server ActiveX Control
An out-of-process server is a COM component that runs separately in its own process space. Clients of the component use proxy/stub in order to invoke interface methods. In-Process servers do not have a process of their own and run in client’s process. An ActiveX Control is a special type of in-process COM server with a visual user interface. It is usually used for visual user interface design and web-based applications. A COM component links dynamically, and is located and activated by using the COM library functions. COM library is the component model implementation. It consists of several functions for COM objects. It is in the form of DLL’s. The COM component that assists activation of a COM component is the Service Control Manager (SCM). All COM components must be registered in the system registry so that SCM can locate them.
4. Component Set 4.1 Design Issues HLACOM component and its companion components NFedAmb, HLASupportCOM are designed as inprocess servers; thus they use the same address space as the federate. Figure 1 contains the logical view diagram, and Figure 2 contains the component diagram of HLACOM in UML. There are two options for the component type. It can be a simple COM object or an ActiveX Control. Since there may not be any need for a visual user interface for HLACOM component, we implement it as a simple COM object. We separately implemented HLACOM Component
IDispatch
HLACOM IRti
IRti //Federation Management Methods createFederationExecution(... //Declaration Management Methods publishInteractionClass(.... //Object Management Methods registerObjectInstance(.... //OwnerShip Management Methods attributeOwnerShipAcquisition(.... ........ //Time Management Methods enableAsynchronousDelivery(.... ........ //Data Distribution Management Methods createRegion(.... ........ //Ancillary Methods getAttributeHandle(.... ........
Figure 1 – HLACOM Component A dual interface is an interface that can allow a COM component to support both early and late binding. All components support dual interface. Late binding restriction on types compels us to implement the component HLASupportCOM having a separate interface for each HLA supporting class such as AttributeHandleValuePairSet. HLACOM has one interface (other than IDispatch): IRti. When an instance of HLACOM is created in an application, all RTI services can be directly used over this instance through IRti. NFedAmb is the component that implements the functionality declared in FederateAmbassador. The
FmCOM IFm
DmCOM
_IFedAmbEvents
IDm
IOm
NFedAmb
HLACOM IRti
HLASupportCOM
TmCOM
ITm
AsCOM IAs
OmCOM
OwmCOM
DdmCOM
IOwm
IDdm
Figure 2 – Component diagram of HLACOM. HLASupportCOM and IDispatch interfaces are not shown. _IFedAmbEvents is the event interface of NFedAmb. Events are notification messages that are sent from the component to the clients of the component. All Federate Ambassador callbacks are passed to the federate by invoking _IFedAmbEvents event methods. Federate Ambassador callbacks are implemented by using connection points and sinks. It is the only way for a nonActiveX COM component to inform a client. A client gives the server component a callback address, in fact an interface address, to call when something happens. This callback address is referred to as a sink, and the server that can do this is said to have a connection point. In NFedAmb there is a one instance of a Federate_wrapper class that implements FederateAmbassador. Event methods of _IFedAmbEvents having names with the prefix Fire_ consist of internal event functions. Federate_wrapper methods directly call the internal event functions that fires the events by passing all the necessary parameters and then events trigger the client function. HLASupportCOM component provides interfaces for each of supporting classes. Supporting classes are created from these interfaces. HLASupportCOM interfaces are:
• • • • • • •
IAttributeHandleSet IAttributeHandleValuePairSet IFederateHandleSet IFedTime IParameterHandleValuePairSet IRegion IException
Some methods of HLACOM require byte array as parameters. Converting values to byte arrays is easy in a language like C++ that supports pointers, type casting and has operators to get the address of a variable. But in a language like Visual Basic, additional component is needed for data conversion. The byteArray component is developed for this reason. It performs conversions from primitive data types to byte arrays or from byte arrays to primitive data types. This component can be used outside HLA context as well. 4.2 Implementation Instead of writing COM objects from scratch we can develop our components with the assistance of two class libraries that Microsoft provides: the Microsoft
Foundation Classes (MFC) and the Active Template Library (ATL) along with their wizards. MFC is more of a library of user interface classes. Components developed by using MFC classes depend on the large MFC DLL’s while components developed by using ATL classes tend to have small memory footprints [13]. Thus we chose ATL as the basis for the implementation of all our components. #import "HLASupportCOM.tlb" no_namespace ………… IExceptionPtr *excp; ……… excp = new IExceptionPtr(_uuidof(Exception)); …… CFm::createFederationExecution(….. { …… try{ ……… } catch (…) {…} catch (RTI::CouldNotOpenFED& ) { (*excp)->setException(CouldNotOpenFED);} ……… return S_OK; }
Figure 3 – Example of usage of Exception in FmCOM In HLACOM we have public member variable rtiAmb from RTI::RTIambassador class. Interface for each group of services is implemented as a separate component for ease of testing, and together they compose HLACOM. These are FmCOM, DmCOM, OmCOM, OwmCOM, TmCOM, DdmCOM , AsCOM providing the interfaces for Federation Management, Declaration Management, Object Management, Ownership Management, Time Management, Data Distribution Management, and Ancillary Services, respectively. In NFedAmb, we have public variable fedAmb from Federate_wrapper class. Federate_wrapper class is derived from FederateAmbassador class. Every method of Federate_wrapper fires the corresponding event in NFedAmb. Different programming languages have different exception mechanisms. In HLASupportCOM, an Exception object is provided. It is implemented as a singleton and used by all components. A singleton is an object that is instantiated only once and then accessed by a number of clients. Components calling CoCreateInstance will all get the same instance of
the class. HLACOM has a public variable for RTI exceptions. When an exception is caught in any component, its number is sent to the Exception object. In clientK side, the code checks Exception object to see which exception has been caught and then handles the exception. Figure 3 presents a sample usage of Exception in FmCOM.
5. Testing Issues and Applications A test federation that uses every service that RTI presents is implemented by using HLACOM, NFedAmb and HLASupportCOM. Every service is invoked one by one and the response is observed. Federates of the test federation are implemented by using a mixture of VC++, BC++ Builder and Visual Basic. During the tests, memory overhead of component set is 2036 KB and a first call to any method after components are loaded takes 270 microseconds. Each subsequent call takes 2 microseconds. These values are measured on Pentium III 1000 MHz having 256 MB RAM PC under Windows 2000. The components are also successfully used in two separate graduate student projects. One of the projects is a tank shooter simulation for training the tank platoon leaders, tank commanders and the shooters. The simulation involves a 3D virtual environment, 3D tank models, missile models and interactions between them. The tank federate is implemented as a COM component that uses HLACOM components. Tank Federate component is successfully used in BC++ Builder and Visual Basic clients. Another application is the web-based version of the Tank Shooter simulation. It is developed in the same way that we develop a typical C++ Builder application. In BC++ Builder, the application is implemented as an Active Form by using tank and HLACOM components. This Active Form can be referenced in an HTML document and viewed with ActiveX-enabled browser. When the simulation page is called from a browser, if the component is not installed to the computer, it is first downloaded and after registration application starts to run.
6. Conclusion and Future Work HLACOM, together with NFedAmb and HLASupportCOM, is a COM component that allows accessing HLA objects from COM environments. As a future work, we are planning to implement it as an outof-process server and implement a web-based simulation
using HLACOM ActiveX control with Active Server Pages (ASP). Designing a system that supports CBD, requires more effort in the beginning, but in the long run, software development and maintenance time is expected to be reduced. CBD process can be applied to the federate development. Federates can be built from components, and can be components as well. Under Microsoft operating systems, COM is one of the alternative component models for federate component development. From the user’s perspective, using an ActiveX-based HLA component is much simpler. The user only installs the ActiveX control and writes the event codes. While using an HLA component that uses a connection point, the user must know how to write a sink in the programming environment. The procedure of writing a sink differs from one programming language/environment to the next. Using a component with connection point requires more skill. Note that .NET-compliant federates can be supported by using the Runtime Callable Wrapper (RCW). RCW acts as a bridge between the COM object and the .NET client. RCW allows to use HLACOM components in .NET applications.
7. References [1] Defense Modeling and Simulation Office, “High Level Architecture Interface Specification, Version 1.3” April 1998. [2] Szyperski, C., “Component Software Beyond Object-Oriented Programming”, Addison-Wesley, 1998 [3] Heineman, G., Councill, W (eds.), “ComponentBased Software Engineering”, Addison Wesley, 2001 [4] Rofail A., Martin T., “Building N-Tier Applications with COM and Visual Basic 6.0”,Wiley,1999 [5] Ruffing C., “Using COM to Facilitate Simulation Development and Extensibility”, in Proceedings of the Fall SIW, 2000, Paper 00F-SIW-045 [6] Cusack M., Hoare P., “Component based development in HLA using Java”, in Proceedings of the Spring SIW, 1999, Paper 99S-SIW-042 [7] Cusack M., Exon N., Hoare P., Hoyle R., “Visual construction of JavaBean federates”, in Proceedings of the Spring SIW, 2000, Paper 00S-SIW-051 [8] Schunk D.W., Bloechle K.Wendy, “Simulation Interoperability with the Micro Saint Simulation Software and COM Services”, in Proceedings of the Winter 2001 Simulation Conference
[9] Naud J.M., “Simulation Models as Components in an HLA World”, in Proceedings of the Spring SIW, 1999, Paper 99S-SIW-098 [10] Radeski A., Parr S., Keith-Magee R., Wharington J., “Component-Based Development Extensions to HLA”, in Proceedings of the Spring SIW, 2002, Paper 02S-SIW-046 [11] Box,D., “Essential COM”,Addison-Wesley,1998 [12] Swanke E.J., “COM Programming by Example”,R&D Books CMP Media,Inc.,2000 [13] Bates J., “Creating Lightweight Components with ATL”, Sams, 1999 [14] Mili H., Mili A., Yacoub S., Addy E., “Reuse-Based Software Engineering”, Wiley, 2002 [15] Kiziltan Z., Jonsson T., Hnich B., “On the Definition of Concepts in Component Based Development”, http://citeseer.nj.nec.com/437569.html
Author Biographies ZEKI SAVAS CENGIZ is a naval officer in Turkish Navy. He graduated from the Turkish Naval Academy in 1991. He served in several ships from 1991 to 1996. In the period 1996-1999, he worked as a software engineer in Turkish Coast Guard Command. He is currently working on M.S. in Software Components for Distributed Simulations in the Department of Computer Engineering at Middle East Technical University. HALİT OGUZTUZUN is an assistant Professor in the Department of Computer Engineering at the Middle East Technical University, Ankara, Turkey. He received B.S. and M.S. degrees in Computer Engineering from METU in 1982 and 1984, and PhD in Computer Science from the University of Iowa, Iowa City, IA in 1991. He is also affiliated with Modeling and Simulation Research Center at METU.
