HLA – COMPLIANT DISTRIBUTED JSIM

ACKNOWLEDGEMENTS

In the course of my pursuit of computer science, I have met hardship beyond imagination. Many people have helped me in all kinds of ways.

First of all, I would like to thank my major advisor, Dr. John A. Miller, for his constant support and guidance. He has been a constant source of suggestions and help throughout this project and all the time that I am seeking this degree. I would also like to express my gratitude to Dr. Rodney Canfield, Dr. Daniel Everett, Dr. Suchendra Bhandarkar, Dr. Hamid Arabnia, Dr. Thiab Taha, and Ms. Ellen Lether for their valuable help and support.

Finally, I would like to thank my parents and sister, for all their support through the difficult times.

TABLE OF CONTENTS

ACKNOWLEDGEMENTS *

LIST OF TABLES vii

LIST OF FIGURES viii

CHAPTER

LIST OF TABLES

LIST OF FIGURES

CHAPTER 1

INTRODUCTION

With the rapid development of the web and internet technologies, we shall expect that a future Web will be full of simulation models and large amounts of simulation-generated data. The number of simulation models available and the amount of simulation data are likely to be much greater. In order to improve the efficiency and decrease the waste of time and resources, supporting the reuse and interoperation across the simulation models on the web is becoming a critical problem that needs to be solved. A subset of High Level Architecture (HLA) on top of distributed component technology was implemented for the JSIM Web-based simulation environment for this purpose. In JSIM, a graphical builder tool and its supporting software (JSIM Builder) was implemented to let the user design complex simulations consisting of multiple models forming a federation.

1.1 Web-Based Simulation

What is Web-Based Simulation? As far as we know, there is no universal agreement on the definition of it. We can think that Web-Based Simulation (WBS) as a term used to capture a cross-section of simulation and web research and technology [Miller et al., 2000].

With the emergence of new Web technologies, Web-Based simulation has become very popular recently. In the future, we expect that many independently constructed simulations can be composed together quickly and cheaply to create a larger simulation that is perceived by its user more as a combined unity than the sum of components. Because the diversity of simulation models and the variety of simulation data that are stored on different systems, it is very hard to let two different simulation models talk, not to mention letting a bunch of simulation models that run on different machines cooperate, communicate and exchange data. One way to bridge the

diversity of simulation models and simulation data is to utilize the High Level Architecture(HLA).

HLA is a component-based architecture which makes the reuse of simulation models much easier. The HLA is also a layered architecture; it encapsulates the services such as the management of federates and communication among federates in its Runtime Infrastructure (RTI) layer, so the federates just need to take care of their own functions that relate to simulation [Kuhl et al., 1999]. These advantages make us choose implementing HLA over other choices. The emergence of component technology such as Java Beans, Enterprise Java Beans (EJB) and the web technology such as Remote Method Invocation (RMI) make it easier to achieve our goal.

1.2 Background of High Level Architecture (HLA)

In order to support the reuse and interoperation of all the new and existing simulations within the US Department of Defense (DoD), the Defense Modeling and Simulation Office (DMSO) defined the High Level Architecture. HLA aims to generalize and build upon the results of the Distributed Interactive Simulation (DIS). The HLA not only supports a wide variety of federations like DIS, but also supports interoperability among simulations [Fujimoto et al., 1996c]. The HLA activity began in March 1995. It became a standard that was approved by the Under Secretary of Defense (Acquisition and Technology) as the common technical architecture for modeling and simulation in the U.S. Department of Defense in September 1996, and it has been nominated for standardization in NATO (North Atlantic Treaty Organization 1998) [Dahamann et al., 1998].

HLA is the glue that allows a number of computer simulations to be combined into a larger simulation. HLA contains three parts:

• The HLA Rules.
• The HLA Interface Specification.
• The HLA Object Model Template (OMT).

The HLA Rules define the basic principles underlying HLA. The HLA Interface Specification (I/F Spec) defines the interface to the Runtime Infrastructure that provides the means for simulators to coordinate the execution and exchange of information. The OMT provides a standard format for describing information of common interest to more than one simulator (federate).

The chief intent of HLA is to allow simulations to be built by combining other simulations. So HLA is fundamentally an architecture that supports component-based simulation, where the components are individual simulations.

1.3 Related Work

There are several kinds of HLA support software, such as the RTI software and the Object Model Tools. For the Object Model Tools, you can provide an Object Model Development Tool, or an Object Model Library, or an Object Model Data Dictionary [Kuhl et al., 1999].

The RTI software is the most important software among the HLA support software. The first RTI software is known as the 0.X series that is developed with an Interface Definition Language (IDL) using Common Object Request Broker Architecture (CORBA). Then based on the 0.X series, the 1.0 series was developed in C++. The first release is known as F.0 and it came out in 1996. In May 1997, the RTI 1.0 was released. It implements all the HLA services except some federation management functions and Data Distribution Management (DDM). The RTI 1.3 which was released in 1998 implements all the HLA specification 1.3. [Dahmann et al., 1998, Kuhl et al., 1999].

There are some other HLA implementations around, such as the Federated Simulations Development Kit (FDK) developed at Georgia Tech by a research group led by Dr. R. Fujimoto. The FDK is a general purpose distributed (federated) simulation software. It includes the RTI-Kit runtime infrastructure development libraries, the implementation of the HLA RTI and a Graphical User Interface (GUI) called Jane Interactive Simulation System [Perumalla et al., 1999].

Some of the above software is implemented in Java such as one version of the RTI 1.0. Some is implemented partly in Java such as the FDK. Some are not.

1.4 Overview of JSIM

The Java-Based Simulation and Animation Environment (JSIM) which is implemented in Java is the result of many people’s efforts. It combines many new technologies such as Java Bean, EJB, RMI, etc. JSIM is divided into three layers: the environment layer, the engine layer and the foundation layer [Nair, 1997, Zhao, 1997, Ge, 1998, Xiang, 1999].

The foundation layer includes the queue package, the statistic package and the variate package. This layer provides the general-purpose functionality that could be also useful in other applications.

The engine layer includes the event package and the process package. This part provides the core for simulation models. In JSIM, simulation models may be built using either the event package (Event-Scheduling Paradigm) or the process package (Process-Interaction Paradigm).

The environment layer includes the jmodel package, the jquery package, the jrun package, the jqds package and the packages that support JSIM Builder. We implemented the graphical designer in the jmodel package. It allows the simulation models to be built rapidly.

In chapter 4, we are going to talk more details about parts of JSIM that are related to JSIM Builder, such as the ModelBean and model agents. The model agents are implemented in the jrun package.

More details about the packages that support JSIM builder will be discussed in chapter 5. These packages include the jbuild package, the feddeployer package, the fedadaptor package, the util package, and the jbdk package.

1.5 Motivation and Orientation of this Thesis

This thesis is built on the ground of the work that has been done on JSIM, especially the ModelBean and jrun package. We call the project for this thesis JSIM Builder. The design goal of this thesis is to support a subset of HLA by implementing it using state-of-art component and web technology. More specifically, we are going to support the building of federation and federation execution. So implementing a subset of HLA will do this job. Because HLA provides almost all the details that are needed for federations and JSIM does not need some of its services such as the Ownership Management, we think implementing a subset of HLA has the advantages of getting rid of superfluous features.

In JSIM, the simulation models and model agents are called federates. They are in the form of components – Java Beans, and they can be stored on one machine or on different machines. The JSIM Builder provides services that support the management of distributed federates and the communication among them.

This thesis consists of seven chapters. Chapter 1 gives a brief introduction of the various concepts related to this thesis. Chapter 2 discusses the HLA. Chapter 3 discusses some infrastructure technologies for this thesis. Chapter 4 gives an overview of JSIM. Chapter 5 to 6 will focus on the work done for this thesis. Chapter 7 summarizes the project and provides some possible directions for future work.

CHAPTER 2

HIGH LEVEL ARCHITECTURE

2.1 Functional Overview

Before going any further on HLA, we need to know some very important terms that are defined in HLA.

• Federate – In HLA, a federate can be a computer simulation, a manned simulator, a supporting utility (such as a viewer or data collector), or even an interface to a live player or instrumented facility. All object representation is in the federates in HLA [Dahmann et al., 1998].
• Federation – A named set of interacting federates, a common federation object model, and supporting Runtime Infrastructure (RTI), that are used as a whole to achieve some specific objective [DMSO, 1998a].

As shown in figure 1, an HLA federation could be separated into three major parts. The first major component is a collection of federates. A federate is a member of a federation. It is a simulation-associated object that can and only can communicate through the RTI. A federate could be a computer simulation, or a supporting utility. A federate could represent one small simulator, such as one cockpit simulator, or an aggregate simulation, such as an entire national simulation of air traffic flow. HLA has no constraints on how a federate represents a simulation, but it does require that all the federates follow some rules so that object in one federate could communicate with another object in another federate through the services that have been implemented in RTI [Dahmann et al. 1998].

Figure 1: Functional View of an HLA Federation [Dahmann et al., 1998]

The second functional component is RTI. In fact, the RTI is a distributed operating system for federations [Dahmann et al. 1998]. In HLA, the simulation model is encapsulated in the federate. The services that the RTI provides are for general purposes. These services include federate-to-federate interaction, federation management and some support functions. The RTI used by a federation may be implemented as many process or as one. It may need many computers to execute, but conceptually it is one RTI. A RTI may support several federations executing at once.

The third component is the interface that federates use to call RTI. It is a common object model for data exchange between federates in a federation, called the Federation Object Model (FOM). It provides the standard that defines how a federate interacts with RTI. Actually the federate interacts with other federates by its interacting with RTI. The RTI can also send or forward other federates’ request to a federate. Generally, it expresses the agreement about the data between federates.

2.2 HLA Rules

The HLA Rules are one of the three parts of HLA standard. The HLA Rules are the principles and conventions that should be followed to achieve proper interaction between federates during federation execution. They can be divided into two groups: the federation rules and the federate rules. Rules for federations are:

Table 1: Federation Rules [DMSO, 1998a]

The rules for federate are:

Table 2: Federate Rules [DMSO, 1998a]

The HLA Rules are the design principles for the Interface Specification and OMT. They summarize the HLA’s major goals and constraints.

2.3 HLA Interface Specification

The HLA Interface Specification describes the runtime services that the RTI provides to the federates and the federates to the RTI. These services fall into six groups.

• Federation Management services offer two kinds of functions to manage the federation. They include creating a federation and allowing federates to join and resign from it, and some federation-wide operations such as defining a synchronization point.
• Declaration Management services provide an efficient way for federates to exchange data. With these services, the federate can declare its intent to produce or consume data.
• Object Management services support the actual exchange of data at the object level.
• Ownership Management services allow the ownership of object/attributes to be shared and transferred among federates.
• Time Management services support synchronization of simulation.
• Data Distribution Management services manage the object instance and support routing of data among federates.

The HLA Interface Specification defines the way these services are accessed, both functionally and in an application programmer’s interface (API). At present, APIs in CORBA IDL, C++, Ada, and Java are incorporated in the HLA Interface Specification.

2.4 HLA Object Model Template (OMT)

The HLA OMT provides a template for documenting HLA-relevant information about classes of simulation or federation objects and their attributes and interactions. This common template facilitates understanding and comparisons of different simulations and federations. It provides the format for a contract between members of a federation on the types of objects and interactions that will be supported across its multiple interoperating simulations. The HLA requires that federation and individual federates be described by an object model.

The HLA specifies two types of object models: the HLA federation object model (FOM) and the HLA simulation object model (SOM). SOM is used to describe an individual federation member (federate). The content of SOM includes objects, attributes, interactions, and parameters. FOM is used to describe a set of interacting federates. The content of FOM includes an enumeration of all object and interaction classes pertinent to the federation, along with a specification of the attributes or parameters that characterize these classes [DMSO, 1998c]. No matter in which object model, the primary objective of the HLA OMT is to facilitate interoperability among simulations and reuse of simulation components.

CHAPTER 3

TECHNOLOGICAL INFRASTRUCTURE

3.1 Component Technology

Today, software that is large in size and provides a substantial functionality is produced every day. On the other hand, users needing only a couple of advanced features are forced to purchase the more expensive product with superfluous features. To solve this crisis, component technology is a good solution. The software components are reusable building blocks for constructing software systems, and have the capability to function both independently and interactively by working with other components [Cassady-Dorion et al., 1997]. Components differ from other types of reusable software such as the object in that they can be modified during design time as binary executables. By following some agreement, the developers can reuse the components that were produced by other developers at different time and in different places in the world.

There are some software component technologies used today such as the Microsoft’s COM/DCOM and the Sun’s Java Beans. Since Java Bean is an outstanding example of implementing component technology, we are going to discuss some features that Java Beans support:

• Introspection. In Java, the reflection package lets a class inquire about the properties, methods or event of other classes. This feature allows a builder tool to analyze how a bean works.
• Customization, so that a user can alter the appearance and behavior of a bean.
• Events. The beans can fire events, and inform builder tools about both the events they can fire and the events they can handle.
• Properties. The properties of beans can be manipulated programatically, as well as to support the customization mentioned above.
• Persistence. The beans that have been customized in an application builder may have their state saved and restored.
• Platform Independence. Because "write once, run any where" is the goal of Java, Java Beans support it too. In ideal form, components should be language independent, but unfortunately Java Beans rely on the Java language.

3.2 Builder Tools

The Builder tools are important parts of component technology. They provide an environment in which users can assemble components together into an application or a more complex component. Typically such tools are GUI applications, although they need not be [Voss, 2000]. Some Builder tools may operate entirely visually, allowing the plugging and hooking up of components. Some Builder tools may need some hand coding. Typically, Builder tools let users visually hook up components, select events to be fired, and specify handlers for events through mouse drag, or menu selection. Very little code needs to be written by hand to get the initial component interaction working properly.

Currently, the available builder tools are Sun’s Beans Development Kit (BDK), Symantec’s Visual Café, Lotus BeanMachine, Borland Jbuilder, Microsoft J++, and IBM’s VisualAge. Since we are going to implement our builder tool in Java, and Sun’s BDK is a good example of builder tool implementation, we are going to give some details of how it works and how it was designed.

As shown on figure 2, Sun’s BDK can be visually divided into three parts: the ToolBox, the BeanBox window, and the Properties sheet.

Figure 2: Screen snapshot of BDK (Sun microsystem)

Here are brief descriptions of each window.

• The available Beans that can be used by the BeanBox are stored in the ToolBox. To work on a Bean, you choose it from the ToolBox and drop it on the BeanBox window.
• The BeanBox window is the area where you visually link Beans together, define how Beans appear, and interact with other Beans. The BeanBox window is a Bean too. The above screenshot shows the BeanBox window with a Juggler Bean instance dropped in it. The hatched border that is around the Juggler Bean indicates the Juggler Bean is the currently selected Bean.
• The Properties sheet displays the properties of the currently selected Bean in the BeanBox window. In the above screenshot, the Properties sheet displays the Juggler Bean's properties.

3.3 Reflection

If you want to implement a builder tool in Java, there is one important package that you need to know – the reflection package. The reflection package provides methods that can reflect the classes, interfaces, and objects in the current Java Virtual Machine. This package is useful in writing development tools such as debuggers, class browsers, and GUI builders. The following information about the functionality of reflection API is provided by Sun.

• Determine the class of an object.
• Get information about a class's modifiers, fields, methods, constructors, and supper classes.
• Find out what constants and method declarations belong to an interface.
• Create an instance of a class whose name is not known until runtime.
• Get and set the value of an object's field, even if the field name is unknown to your program until runtime.
• Invoke a method on an object, even if the method is not known until runtime.
• Create a new array, whose size and component type are not known until runtime, and then modify the array's components.

The reflection package makes it much easier to implement the JSIM Builder.

3.4 Enterprise JavaBean (EJB)

Today, enterprise developers face some fundamental problems in writing distributed applications. Writing large applications is even more difficult. It is difficult because the applications run on heterogeneous platforms and different environments. The enterprise developers would like to write the application once and run it on all other platforms. In order to support this feature, the Enterprise Java Beans (EJB) technology was introduced.

The Enterprise Java Beans (EJB) architecture is a server-side component model for the Java platform. The design goal of EJB component architecture is to enable enterprises to build scalable, secure, multi-platform, business-critical applications as reusable, server-side components [Roth, 2000].

3.4.1 Enterprise Application Models

An enterprise application model, or in other words, an Enterprise Bean is a body of code with fields and methods to implement modules of business logic [Pawlan, 2000]. It is a building block that can be used alone or with other Enterprise Beans to build a complete and robust thin-client multi-tiered application. An Enterprise Bean can be implemented to interact with other Enterprise Beans.

There are two types of Enterprise Beans: Session Beans and Entity Beans. By using a Session Bean, the client begins a session with an object that acts like an application, executing a unit of work on behalf of the client, possibly including multiple database transactions. By using an Entity Bean, the client accesses an object that represents an entity in a database. Generally, a Session Bean represents a communication session with a client, and an Entity Bean represents a data in a database [Roth, 2000, Pawlan, 2000].

• A Session Bean represents a transient conversation with a client, and might execute database reads and writes. A Session Bean might invoke the JDBC calls itself or it might use an Entity Bean to make the call, in which case the Session Bean is a client to the Entity Bean. A Session Bean's fields contain the state of the conversation and are transient. That means if the server or the client crashes, the Session Bean is gone. This model is typically used with database programming languages such as PL/SQL.
• An Entity Bean represents data in a database and the methods to act on that data. In a relational database context for a table of employee information, there is one Bean for each row in the table. The Entity Beans are transactional and long-lived. As long as the data remains in the database, the Entity Bean exists. This model can be easily used for relational databases and is not restricted to object databases.

3.4.2 Architecture

Figure 3: EJB Architecture ([Roth, 2000])

Figure 3 illustrates the EJB Architecture. The EJB allows for any kind of client, and an EJB server can support multiple protocols such as RMI, IIOP (CORBA), and DCOM. This implies that a client to an EJB server does not have to be written in the Java language [Roth, 2000].

To simplify the programming of enterprise application, The EJB technology wraps a collection of services for supporting an EJB installation in the EJB server. These services include management of distributed transactions, management of distributed objects and distributed invocations on these objects, and some low-level system services. Generally, an EJB server manages the resources needed to support EJB components. An EJB server provider can provide an implementation of a container, (described below) and it can provide an API for third party vendors to plug-in additional EJB containers. The EJB specification allows developers a great deal of freedom in the design and implementation of servers.

Inside the EJB server, an EJB container may be implemented. An EJB container is in fact a home for EJB components. When the Beans are installed into the container, the container provides a scalable, secure, transactional environment in which Beans can operate. The container handles the object life cycle, including creating and destroying an object. It also handles the state management of Beans.

When a Bean is installed in a container, the container provides two implementations: an implementation of the Bean's EJBHome interface and the Bean's remote interface. The container is also responsible for making the Bean's EJBHome interface available in the Java Naming and Directory Interface (JNDI).

To construct a Bean, you must first implement the methods that are declared in the EJBObject interface. For example, if you are writing a checking account Bean, you might implement a "debit" method as part of its interface. You must also implement one of the two types of EJB interfaces, SessionBean or EntityBean. These interfaces include methods related to working set management and are not exposed to a client.

When a Bean is installed on a server, the remote interface, which is usually called a skeleton in CORBA, is automatically generated. The implementation of the remote interface is called the EJBObject. The EJBObject only exposes the remote interface specified by the programmer to the client. The enterprise Bean class does not implement the remote interface, though it does contain methods with the same signatures. The EJBObject acts like a proxy, intercepting the remote object invocations and calling the appropriate methods on the enterprise Bean instance.

An EJB container implements the EJBHome interface of each Enterprise Bean installed in the container. It supports the creation of a Bean, deletion of a Bean and querying information or "metadata" about a Bean. The container makes the EJBHome interfaces available to the client through JNDI. For Entity Beans, the EJBHome interface also contains some methods that allow a client to look up a Bean by a primary key.

3.4.3 Features

As we know, writing distributed transactional applications is a complex task. The EJB was designed to enable server side "write once, run any where". In order to accomplish this goal, the EJB technology provides some features [Roth, 2000].

• A key feature of EJB technology is its support for distributed transactions. To write applications that access multiple distributed databases, across multiple EJB servers, the users just need to declare some properties of the enterprise Beans, rather than hand-code the transactional behavior. This feature shift the burden of managing transactional behavior to the server, specifically the container and EJB server providers, so that the enterprise developers can focus on the application functionality.
• Security is another important feature, and it is also a requirement for all enterprise products. In EJB technology, developers can set up security in two ways: First, developers can set the security descriptor in the Bean's EJB-JAR file. Second, developers can use the java.security package to manage security programmatically.
• Object communication protocol-neutral is the third main design feature of EJB. This means that EJB server can support multiple protocols like RMI, CORBA and Distributed Common Object Model (DCOM). This feature frees the programmer of the protocol choice when s/he implements the client part of the application. It allows the EJB server builder to implement the protocols that are most important to its customer. For example, an Object Request Broker (ORB) vendor might only implement the CORBA protocols, while a UNIX system provider might implement RMI and CORBA. In any case, the protocol used is transparent to the Bean developer who writes only to the Java platform.
• The EJB server inherits a number of benefits from the Java platform. The most obvious of these is that once a Bean-based application is written, it can run anywhere an enterprise Bean server is running. An adjunct benefit to this is scalability. If your current EJB application is hitting a performance wall, you can move your application part-and-parcel to another higher performing platform's EJB server.
• The EJB can also provide containers that can greatly simplify access to existing enterprise applications. Such a container can bridge the differences of Java and non-Java language applications. In such a container, the non-Java language applications may appear as Beans, so that the Java language applications are enabled to access these applications without learning the specifics of the existing systems and applications.

CHAPTER 4

OVERVIEW OF JSIM

We have briefly introduced the JSIM Web-Based Simulation Environment in chapter 1. Through the efforts of many people, JSIM has evolved into a large system that has plenty of methods and functionality. It provides a graphical designer, so that the user can rapidly build the simulation graphically. The jqds package (Query Driven Simulation) under development controls the storage, retrieval and execution of simulation models as Java Beans and utilizes JDBC to access databases. It also provides a code generator that will generate the code automatically, either as an applet or as a Java Bean.

In this chapter, we are going to talk about some issues of the JSIM that is closely related to this thesis.

4.1 Model Bean

To cope with the needs of HLA, every federate should be represented as a component. In JSIM, every simulation model is a Java Bean. It is derived from one super class called ModelBean. The ModelBean class takes care of the bean aspects of each simulation model, and the derived child class is responsible for all the features, related to the real life situation that the model tries to represent (for example, ERoom model represents an Emergency room simulation) [Xiang, 1999].

The ModelBean can fire the following events:

• InformEvent. When this event is fired, it informs the default parameters of the model bean to a model agent. These properties are some simulation parameters, like inter-arrival distribution, service distribution, number of customers, number of services, data monitoring spot, etc. This event provides a way to modify these simulation parameters.
• ReportEvent. When this event is fired, the data collected by the model bean is carried out. If the amount of data required by the model agent have been collected, this event will be fired. This event reports summary data to the model agent.
• InjectEvent. When this event is fired, it indicates that an entity has reached the sink. This event is useful for the interaction among the model beans.

ModleBean can listen to following events:

• SimulateEvent. This event is fired by a model agent. It contains the data from the model agent to guide the model bean to collect simulation output data.
• InjectEvent. This event is fired by other model beans.
• GUI events like mouse click, …etc.

ModelBean is an abstract class. It contains some abstract methods that must be implemented by the child class. These methods provide the chances for the model agents to make decision and change properties of model bean. ModelBean also provides most functions that the simulation needs, so that the coding of the simulation model that extends it becomes very simple. This feature makes it easy for the child class to be created by code generation.

4.2 Jrun Package

The model agents are implemented in the jrun package. In order to let the user decide how the model bean works, JSIM provides several model agents. The model agents are also components in the form of Java Beans. A model agent can listen to the events that are fired by other components. The events for which ScenarioAgent can listen are different from the events for which other model agents can listen. Most importantly, the model agent has some decision-making abilities.

The jrun package currently provides three kinds of model agents. They include:

• BatchMeansAgent. This model agent uses the ABATCH Batch Means algorithm to control the execution and analyze the output data of a model [Fishman and Yarberry, 1997]. It lets the user change the properties like the initial transient period, minimum batch size, number of batches, relative precision and the level of confidence. After the user modifies these properties, BatchMeansAgent will fire a SimulateEvent. The model bean that catches this event will extract the data and start a new simulation process. Then the model bean collects a specific amount of batch data with a given batch size. When the simulation is over, the model bean fires ReportEvent which contains an array of batch mean values that it has collected. The BatchMeansAgent catches the event, obtains the data, and then may display it.
• ReplicationAgent. This model agent analyzes the model output data by using the independent replication algorithm. It lets the user change the properties like the initial transient period, size of each replication and relative precision. After the user modifies these properties, ReplicationAgent will fire a SimulateEvent to ask the model bean to collect a specific amount of replication data with a given replication size. The model bean continues to collect the data and test the relative precision to see if the precision specified by the user has been reached. When the simulation is done, the ReplicationAgent fires ReportEvent, so that the output data can be stored.
• ScenarioAgent. This agent can be used to handle the communication with the user. The ScenarioAgent can catch the java.awt.event like the Button clicked by user. It receives the InformEvent to get all the properties of a model bean from a model agent. It can fire the InstructEvent to send the modified properties back.

The BatchMeansAgent and the ReplicationAgent extend from the ModelAgent class, but implement different analyzing method. Like the ModelBean, the ModelAgent provides some abstract methods that must be implemented by child class. The ModelAgent also provides most functions that the child class needs. These functions that ModelAgent provides to its child classes include displaying output data, handling events that are fired to the child class, firing SimulateEvent, and some functions needed for analyzing the output data.

As we mentioned in chapter 2, HLA FOM contains an enumeration of all objects and interaction classes, parameters and attributes related to the federation. We summarized the FOM for JSIM in table 3. We also summarize the SOM of simulation models in JSIM in table 4.

Table 3: The Content of JSIM FOM

Table 4: The Content of SOM for JSIM Simulation Model

CHAPTER 5

JSIM BUILDER

In JSIM, every simulation model and model agent can be generated as a Java Bean, so an RTI-like software can be implemented to reuse them for building a complex federation. In order to support the reuse and interoperation of simulation models and model agents, JSIM Builder was implemented. JSIM Builder supports a subset of HLA. It provides services that support federation building, federates management, and communication across federates.

5.1 Functionality Overview

At runtime, the simulation models and model agents work as federates for JSIM Builder, and JSIM Builder provides services to the simulation models and model agents like an RTI (shown in figure 4). In JSIM, every simulation model extends ModelBean. ModelBean provides most functions that a simulation needs and leaves few parameters for the simulation model to determine. This kind of Object Oriented (OO) structure is compatible with the rules described for the federate. This is true with the ModelAgent that is extended by most model agents too.

By functionality, the JSIM Builder consists of three parts: the Graphical Builder, the Federate Deployer and the Federation Adaptor. Among all the three parts of JSIM Builder, the Graphical Builder is the most important part. It is the client of the Federate Deployer and the Federation Adaptor, and controls the behavior of them.

Figure 4: JSIM Builder Architecture

Because the functionality of JSIM Builder can be divided into the services that support building the federation and the services that support federation execution, the life cycle of JSIM Builder can be divided into build-time and runtime. Each part of the JSIM Builder provides some services either for build-time or runtime, or for both.

The build-time services are supported by the combined efforts of Graphical Builder and Federate Deployer. The Graphical Builder provides a graphical environment in which user can build complex federations. It can manage and display the available federates that are both from the local machine and from the remote server. The Federate Deployer is on the server side. It provides some methods that help the management of the remote federates. This part is implemented by using EJB.

The build-time services are supported by combined efforts of Graphical Builder and Federation Adaptor. The Graphical Builder provides services that support federation execution, event management, object and method invoking, etc. The Federation Adaptor is on the server side. It is implemented by using RMI. The Federation Adaptor can store one remote simulation model and control the behavior of this simulation model. Together with the Federation Adaptor, the Graphical Builder provides the communication service for linked federates. So other federates in the same federation can interact with the remote simulation model.

Comparing to HLA, the simulation model and model agent can be taken as the federate, and JSIM Builder functions as the RTI to the federates. The federates interact with the JSIM Builder through events. The JSIM Builder is responsible for delivering the event to the interested party. So for the federate itself, no matter it is from a local or remote machine, it works as if it is from a local machine. It just needs to declare whether it is going to fire or receive a message, it does not need to know whom it is going to interact with. The JSIM Builder is responsible for delivering the event to interested party.

5.2 Graphical Builder

One of the main purposes of the Graphical Builder is to support the building of federations. To cope with this goal, a frame is used as the base container to contain all the components of the main window. There are two major components in the Graphical Builder. They are the federate manager and the builder box. The federate manager has a list of the labels of available federates. The builder box is the place where the federation will be built. With the cooperation of the federate manager and the builder box, a federation can be built visually. The menu bar of the frame has some menu items that can control the interaction of the federate manager and builder box.

5.2.1 Build-time Functions

At the build-time, the federate manager, as one of the two major parts of Graphical Builder, provides functions mainly for the management of the federates. The following describes its functionality.

• It loads the available local federates from the JAR files and displays them with their unique label and host machine’s URL address.
• It calls the Federate Deployer and loads the available federates from the JAR files on the remote server and displays them with their unique label and host machine’s URL address.
• It stores information about a federate such as the federate name, the federate label and the host address of the federate, etc.
• It supports the selection of federates.
• It can provide information about a federate to the Graphical Builder if it is needed.

The builder box is another major part of the Graphical Builder. The functions that it contributes to build-time services support the building of the federation. The following describes its functionality.

• It supports loading a federate into it and displaying it visually. The user can choose the display position.
• It supports changing the position of federate in the builder box.
• It supports the changing of the current active federate by clicking it with left mouse button.
• It supports the visual hooking up of federates.
• It supports the displaying of hooking up relation between two federates by showing a yellow line between them.

As two major parts of Graphical Builder, the federate manager and the builder box provide most functions needed for building a federation. The following describes some other functionality that are provided by the Graphical Builder for building federation:

• It can let the user choose a local JAR file and load the federates in this JAR file.
• User can make the decision if s/he wants the remote federate to run locally or remotely.
• It supports the removing of all the federates in the builder box.

As we can see, all the above functions are related to building federations. So we have implemented the creation of federation in Federation Management services.

5.2.2 Runtime Functions

The runtime functions of Graphical Builder are provided by its builder box. They include:

• It responds to GUI events such as a mouse click, and delivers it to the interested federate.
• It supports the management of all the JSIM events such as SimulateEvent, InstructEvent, InformEvent and InjectEvent.
• It stores all the information of loaded federates.
• It generates the adaptor class for the hooked up federates.
• It is responsible for delivering the JSIM event to the interested federate.
• It supports invoking methods of a federate.

As we can see, because the builder box supports event management, JSIM Builder supports DeclarationManagement Services. Data Distribution Management is partly supported by keeping track of loaded federate objects by the builder box. Besides the functions for building federation, the Graphical Builder, along with Federate Deployer and Federation Adaptor, provides the communication service. The communication service supports data exchange that is included in Object Management services. The function of Federate Deployer and Federation Adaptor will be discussed later.

5.2.3 Builder Environment

The initialization of the Graphical Builder includes getting a connection with Federate Deployer’s EJB server, checking if Java Bean is supported or not, and initialization of its GUI.

The JSIM Builder encapsulates all the methods that are related to the Federate Deployer in the BuilderFrame class. The base frame is implemented in the BuilderFrame class. This class also contains the main function of the application. The functionality of the federate manager and the builder box is provided by many classes. The major class of the federate manager is the FederateMgr class. This class can be used to represent the federate manager, because all functions of the federate manager can be reached in it. Similarly, the BuilderBox class can be used to represent the builder box.

When the federate manager is initialized, it first calls the BuilderFrame class to get all the JAR file names that are available both from the local machine and the remote machine. Then it calls the JarLoader to load all federates in those JAR files and put them into its list. When the initialization has been finished, it displays all available federates by their unique federate labels and host addresses and then waits for the user to choose.

The initialization of the builder box does nothing except set the layout and display itself.

Figure 5: Hookup Federate

When the initialization has been finished, the Graphical Builder waits for the user to build a federation. The building of federation is very simple in the JSIM Builder. The user just needs to follow the steps below.

First, the user needs to load all the desired federates – model beans and model agents into the builder box.

Figure 6: Builder Adaptor Dialog

When all the federates have been loaded, the user can hook them up according to certain scenario. Of the two federates that will be hooked up, the one that will fire an event is called the source federate, and the one that will listen to this event is called the target federate. To hook up the federates, the user needs to choose the event that the source federate will fire (shown as figure 5). Then, the user needs to choose the listener method of the target federate in the Adaptor Dialog (shown as figure 6). After all these, the hooking up can be done.

After the hooking up, an adaptor class will be generated. Below is an example of an adaptor if the target federate is from local machine.

If the target federate is from remote machine, another kind of adaptor class will be generated. Below is an example.

Third, after the adaptor class has been generated and compiled, the Graphical Builder will invoke this adaptor class and its setTarget method. In JSIM Builder, the loaded federate is stored in a wrapper. The wrapper of the source target stores a list that contains all the events it will fire and the target federate plus the listener method which will listen to this event. This is the way that the Graphical Builder manages the events. In this way, the Graphical Builder can find the target federate of a certain event and the federate does not need to know if the target is from local or remote. The user may start the federation such as clicking the "start" button of the model agent.

As we can see from the above, building a federation is so simple in JSIM Builder that the user does not need to do any coding. The Graphical Builder encapsulates part of the communication service in itself. This feature facilitates the building of federations.

5.2.4 Runtime Environment

Figure 7: Food Court and ERoom Federation at Runtime

Consider a simple Food Court and ERoom Federation. It contains a ScenarioAgent, two BatchMeansAgent, a FoodCourtBean and an ERoomBean. The ScenarioAgent needs to fire an InstructEvent to the BatchMeansAgents. One BatchMeansAgent needs to fire a SimulateEvent to FoodCourtBean and the other one needs to fire SimulateEvent to ERoomBean. The FoodCourtBean needs to fire an InjectEvent to ERoomBean when a customer feels sick at the food court.

As we can see in figure 7, all the interaction between federates are actually completed by interacting with JSIM Builder. JSIM Builder is the RTI for the federate. According to the definition of federate, all the object representation is in federates in HLA. The ScenarioAgent, BatchMeansAgent, FoodCourtBean and ERoomBean are all federates. They communicate with JSIM Builder through the events. The events are the interface that allows the communication to happen. The JSIM Builder has a wrapper instance for each federate. When this wrapper catches an event, it will invoke the listener method for this event in its adaptor class. The listener method will fire this event to the target federates. When the target federate is from a remote machine, the adaptor class will forward this event to the target’s wrapper on the remote machine and the remote wrapper will fire this event to the target federate.

5.3 Federate Deployer

The functions that the Federate Deployer provides are for build-time. These functions are called by Graphical Builder. They include:

• Sending all the available JAR file names on the server side to the Graphical Builder upon request.
• Sending the length of a JAR file to the Graphical Builder upon request.
• Sending the content of a JAR file in a byte stream to the Graphical Builder upon request.

Sun provides the deploy tool to deploy the Federate Deployer bean. When the server bean is deployed, it waits for the client to call.

The Federation Adaptor of the JSIM builder provides part of the communication service. With the services provides by Federation Adaptor, a remote simulation model can be run on its remote host, and other federates can still interact with it. The complete communication service for federates is encapsulated in the Graphical Builder and the Federation Adaptor. With this communication service, a remote simulation model can be used to build the distributed federations as easily as the local ones. The communication service is responsible for delivering event to interested parties.

The functions provided by the Federation Adaptor are for runtime. These functions include:

• Answering if the Federation Adaptor is waiting to load a simulation model.
• Answering if the Federation Adaptor is waiting to invoke the loaded simulation model.
• Replying to the client’s call for its current status.
• Loading a simulation model and storing it upon the request of Graphical Builder.
• Running the loaded simulation model upon request.
• Handling the InjectEvent fired by another simulation model.

When the Federation Adaptor is initialized, it first binds an instance of the AdaptorImpl class with the RMI server and waits for the client to call. If the user builds a federation with a remote simulation model, the Graphical Builder will generate an adaptor class like the one below. After the adaptor class is generated, it will also be compiled and initialized, so it can catch the event for it. By invoking the adaptor class and its methods, the user could run a remote simulation model with the designed federation without any coding.

5.5 Services Summary

The JSIM Builder provides a subset of HLA services. These services include:

• We implemented part of Federation Management services by supporting creation of federations. We did not implement global synchronization
• We provided Declaration Management services by supporting the management of events. JSIM Builder also keeps track of the source and target federate of an event. When an event is caught by JSIM Builder, it can find the event’s listener method and invoke it.
• The Object Management services are supported by providing a communication service. The communication service includes two parts: the part for Graphical Builder to load a remote federate and the part for the interaction of the linked federates.
• We provided part of the Data Distribution Management by managing the federate instance, but we have not implemented the data routing.
• Ownership Management services. We have not implemented these.
• Time Management services. We have not implemented these.

There are some other RTI software around such as the Georgia Tech’s FDK. The FDK provides some RTI-Kit libraries and a GUI called Jane. Jane provides graphical controls and displays for the simulation [Perumalla et al., 1999]. We compare the functions of FDK and JSIM Builder in table 5.

As we can see, the advantage of JSIM Builder is that federation can be built entirely visually. This is because the JSIM Builder is implemented by using Java Beans and EJB. Although it provides limited functions compared to FDK, as more supporting utility beans are built, these deficiencies could be made up. For example, to monitor the simulation process, we can provide a monitor bean. So JSIM Builder is more flexible.

Table 5: Comparison of FDK and JSIM Builder

CHAPTER 6

AN EXAMPLE OF USING JSIM BUILDER

In JSIM, a federation can be built up by linking a certain number of simulation models and model agents together. The simulation model can represent a real world situation such as a BankBean. The simulation model can be assembled and generated by the graphical designer. There are three kinds of model agents in JSIM now. They are the ScenarioAgent, the BatchMeansAgent, and the ReplicationAgent. After the federation is created, it is ready to be executed. In this chapter, we are going to give examples on how to build a federation by using the JSIM builder. Before further discussion, we summarize the events fired and listened for by simulation models and agents in the following table.

Table 6: Events fired and listened by ModelBean and agents

Consider this situation. There is a food court somewhere – a McDonald and a Wendy. When a customer comes to a food court (FoodCourtBean), if they feel sick, they may choose to go to a nearby hospital (ERoomBean). We call this federation the Food Court and ERoom federation.

According to the scenario above, we will need the following components to build up this federation. An ERoomBean simulation model represents the ERoom. A FoodCourtBean simulation model represents the food court. Two BatchMeansAgents are used to analyze the transaction of the ERoom and the food court. One ScenarioAgent will instruct the federation. In this case, we let the FoodCourtBean run on the local machine and the ERoomBean run on the remote machine. When the customer leaves the food court for the eroom, The FoodCourtBean can interact with the ERoomBean by firing an InjectEvent. The design diagram of this federation is shown in figure 8.

Figure 8: Design Diagram of Food Court and ERoom Federation

Figure 9: Food Court and ERoom Federation

By using the JSIM builder, the user could easily build a federation. For example, to build the federation described above, the user just need to carry out the following steps:

1. Select the ScenarioAgent from the federate manager, and drag-and-drop it into the builder box.
2. Do the same with the ERoomBean and FoodCourtBean and two BatchMeansAgents. For the ERoomBean, you need to choose the one that is from remote.
3. Set ScenarioAgent as the active federate. Hookup the ScenarioAgent’s Instruct event to the BatchMeansAgent‘s handleInstruct method. Do the same to the other BatchMeansAgent.
4. Hookup the SimulateEvent of the BatchMeansAgent to ERoomBean‘s handleSimulate method. Do the same to the other BatchMeansAgent and the FoodCourtBean.
5. Hookup the Injectevent of the FoodCourtBean to the ERoomBean ‘s handleInject method.

Figure 10: Execution of the Food Court and ERoom Federation

After all the hooking up has been done, you may see a screen shot as figure 9. To start the federation, the user just needs to click the "start" button of ScenarioAgent. When the federation is executed, the models of the FoodCourtBean and the ERoomBeans run on different machine. Figure 10 is a scaled screen shot of Food Court and ERoom Federation Execution.

CHAPTER 7

IMPLEMNETATION OF JSIM BUILDER

The aim of JSIM Builder is to support the reuse and interoperation of the JSIM simulation models. In order to achieve this goal, the JSIM Builder adopts some features and implements some technologies such as Java Bean, EJB, and RMI.

In JSIM builder, a federate can be a simulation model such as the BankBean, or it can be a model agent that could provide some decision-making ability. No matter what it is, each federate is in the form of a Java Bean and is stored in a JAR file. Because the Java Beans are the reusable components on the client side and they support some properties like introspection and event, the Graphical Builder can analyze their properties and methods, and invoke them at runtime. Each federate is stored in a JAR file in JSIM. Each JAR file may contain several federates. The JAR file format is provided by Sun. It can be serialized. The JAR file format brings several advantages in implementing JSIM Builder. First, the developer does not need to worry about missing any part of a federate. Second, since it can be serialized, it can be easily transferred through the web.

The federation in JSIM builder is a collection of federates – simulation models and model agents. These federates are hooked up together according to a certain scenario. In JSIM, the graphical designer can create the federate and JSIM Builder can create the federation by using the federate generated by the graphical designer. A federation can represent some real world events, such as daily transaction of a Bank and its nearby supermarket. The federation works by interacting with the JSIM Builder and the JSIM Builder provides a work environment and communication service to it.

The Graphical Builder in JSIM Builder provides a graphical environment for building the federation and managing the federates. In order to introspect the properties and methods of federate, it utilizes the Reflection package that Java provides. The GUI that it provides facilitates the building of federations.

The EJB has the feature of server side "write once, run any where". We implement the Federate Deployer by using the EJB technology, so the server can be moved to another machine without any coding. For the Federation Adaptor, since we specify the server host from the command line, we can still move the server easily, although Federation Adaptor is implemented by using RMI.

In order to let a local federate interacts with a remote federate, the Federation Adaptor provides some methods that can control the behavior of the remote federate. The local federate may invoke these methods through RMI. The implementation of these methods is encapsulated in the Federation Adaptor. The interface of these methods is available to the Graphical Builder. So we can use the JSIM Builder to build a federation with a remote federate. This federate can be run on its remote host, but still cooperate with the whole federation. We implement the Federation Adaptor by using RMI instead of EJB, because the version of EJB that we use has some limitation, such as it restricts the use of GUI and we need a GUI to display the simulation in the server side.

The current release of the JSIM Builder is written and compiled in JDK1.2.2. Details on the implementation of the Graphical Builder, the Federates Deployer, and the Federation Adaptor will be given below.

The JSIM Builder consists of five packages. These packages are the jbuild package, the feddeployer package, the fedadaptor package, the util package and the jbdk package. The jbuild package describes the Graphical Builder. The feddeployer package describes the Federates Deployer. The fedadaptor package describes the Federation Adaptor. The util package contains the interfaces that are needed for RMI, it also contains some utility classes needed by other package such as the Trace class. The jbdk package contains some classes needed that are useful in loading a JAR file.

7.2.1 Graphical Builder

The Graphical Builder is implemented in the jbuild package. This is a large package containing so many classes that we can not get the details of every class. Among all the classes in this package, we would like to introduce some important ones.

• BuilderFrame class. This class implements the base frame. It controls the interaction of federate manager and builder box.
• FederateMgr class. This class represents the federate manager.
• BuilderBox class. This class represents the builder box.
• JarLoader class. This class can load the federates in a JAR file and store the information into the FederatesInfo class.
• FederatesInfo class. This class stores the information of all the federates in a JAR file. It can provide the information to interested party.
• Wrapper class. This class is the wrapper of a loaded federate. It supports GUI event, so that user may interact this federate such as changing the properties of the federate.
• AdaptorDialog class. This class allows the user choose the appropriate listener method for the target federate.
• AdaptorMgr class. This class will generate the adaptor class for the hooked up federates.
• RMIclient class. The connection to the Federation Adaptor’s RMI server is encapsulated in this class. In order to invoke the remote method, the remote adaptor will need to get an instance of the remote interface.

There are still some other classes that help to support the functionality of Graphical Builder. Since they are not important, we are not going to give the details of them.

7.2.2 Federates Deployer

The purpose of the Federate Deployer is to provide some methods to support the management of remote federates. To cope with this goal, the Federate Deployer provides some functions. These functions are described in the feddeployer package.

In the feddeployer package, the SimFederate class contains the server Bean’s remote interface. This interface is available to the client. The client may invoke the methods that are declared in this interface. The SimFederateEJB class implements the all the methods that declared in the SimFederate interface. This class is the major part of this whole package and most functions are implemented here. The methods that provides to the client include:

These methods help the Graphical Builder to manage the federates on server side. For example, the method getJarNames allows the client to get all the JAR files that stores the federates on the server side. When the Graphical Builder is initialized, it will call this method to get all the JAR file names available on the server side. The method getComponentLength allows the client get the length of a JAR file. The method getComponent allows the client get the contents of a JAR file. This method puts the content of a JAR file into a byte stream and returns it to the Graphical Builder. When the Graphical Builder gets the byte stream, it may call the JarLoader class to get the federates in it.

The Federate Deployer is implemented by using EJB, so it has the property of server side "run once, run any where".

7.2.3 Federation Adaptor

The Federation Adaptor is described in the fedadaptor package. The fedadaptor package includes the following classes: the FedAdaptor class, the HolderPane class, the FederateMaster class, the FederateThread class, the AdptorImpl class, the WrapperBox class and some support classes. The FedAdaptor class contains the main function, and it binds the AdptorImpl class with the RMI server. The AdaptorImpl class implements all the methods that are available in the Adaptor interface. The HolderPane class implements a panel. The FederateMaster class is in charge of all the services of the federate. The WrapperBox class supports with initializing the simulation model, storing the simulation model, running the simulation model, and handling the InjectEvent fired by another simulation model.

For the Federation Adaptor, the remote client is the Graphical Builder. The client invokes the Federation Adaptor’s methods through its RMI interface. The Federation Adaptor provides the below methods for the client to call.

These methods are provided to the client in the Adaptor interface in the util package and are implemented in the AdptorImpl class.

CHAPTER 8

CONCLUSIONS AND FUTURE WORK

Based on the work that has been done for JSIM, especially its implementation of component technology and agent technology, we have implemented the builder for JSIM that provides the following capabilities:

• A graphical builder tool is provided so that a federation may be built by dragging and dropping.
• The graphical tool also provides services to manage the federates.
• The JSIM builder takes care of the interaction between federates, so that the user can build a distributed federation in the same way as a local federation.
• A Federate Deployer is implemented so that the federate on the server side could be loaded and managed.
• A Federation Adaptor is provided so that a remote federate could be run on its host machine.
• The adaptor classes are automatically generated, so that a user does not need to do any programming to build a federation.

Compared to RTI1.3 that implemented all the services of HLA, the JSIM builder supports only a subset of HLA services. We implement the Federation Management services by supporting the creation of federation. The Declaration Management services are provided by supporting the management of the events, and its source and target federates. The Object Management services are supported by providing communication service. We also provide part of the Data Distribution Management by managing the federate instance, but we have not implemented the data routing. We have not implemented the Ownership Management and Time Management services.

Below is some possible work that can be done in the future.

In the future, more work needs to be done on services that support the execution of federation, such as the Time Management services, simulation process monitoring.

We implemented Federation Adaptor by using RMI as the communication method. In the future, this part should be converted to using EJB, so that a complete "write once, run anywhere" server may come true.

More functionality needs to be implemented for the Federation Adaptor. For example, the Federation Adaptor should have some local decision making-ability, so that the user can modify the parameters of simulation.

REFERENCES

[Cassady-Dorion et al., 1997] Cassady-Dorion, L., Brumbaugh, M., Maheshwari, S., Wright. J., Brookshier, D., Last, B., Mathis, J.. Industrial Strength Java. Published by New Riders.

[Dahmann et al., 1998] Dahmann, J., Fujimoto, R., Weatherly, R. (1998). The DoD High Level Architecture: An Update. In Proceedings of the 1998 Winter Simulation Conference, pages 797-804, Washington, DC.

[Dahmann et al., 1997] Dahmann, J., Fujimoto, R., Weatherly, R. (1997). The Department of Defense High Level Architecture. Winter Simulation Conference, December 1997.

[DMSO, 1998a] Defense Modeling And Simulation Office. High Level Architecture Rules, Version 1.3.

http://hla.dmso.mil/tech/rules.html

[DMSO, 1998b] Defense Modeling And Simulation Office. High Level Architecture Interface Specification, Version 1.3.

http://hla.dmso.mil/tech/ifspec.html

[DMSO, 1998c] Defense Modeling And Simulation Office. High Level Architecture Object Model Template Specification, Version 1.3.

http://hla.dmso.mil/tech/omtspec.html

[Fishman and Yarberry, 1997] Fishman, G., Yarberry, S.. An Implementation of Batch Means Methos, INFORMS Journal on Computing, 9(3):296-310

[Fishwick, 1996] Fishwick, P. (1996). Web-Based Simulation: Some Personal Observations. In Proceedings of the 1996 Winter Simulation Conference,

Coronado, California

[Fishwick, 1998a] Fishwick, P. (1998a). An Architectural Design for Digital Objects. In Proceedings of the 1998 Winter Simulation Conference, pages 359-365, Washington, DC.

[Fishwick, 1998b] Fishwick, P., editor (1998b). Proceedings of the 1998 International Conference on Web-Based Simulation and Modeling. Society for Computer Simulation, San Diego, CA. http://www.cise.ufl.edu/fishwick/webconf/full

[Fujimoto, 1998] Fujimoto, R.(1998). Time Management in the High Level Architecture

Simulation, Vol. 71, No. 6, pp. 388-400, December 1998.

[Fujimoto et al., 1996a] Fujimoto, R., Weatherly, R.(1996). Time Management in the DoD High Level Architecture.1996 Workshop on Parallel and Distributed Simulation, May 1996.

[Fujimoto et al., 1996b] Fujimoto, R., Weatherly, R. (1996). HLA Time Management and DIS.14th Workshop on Standards for the Interoperability of Distributed Simulation, March 1996.

[Fujimoto et al., 1996c] Fujimoto, R., Weatherly, R.. HLA Time Management and DIS. 14th Workshop on Standards for the Interoperability of Distributed Simulation, March 1996.

[Ge, 1998] Ge, Y.. Development of a Web-Based Simulation Environment Using Java Bean. Master Thesis, 1998, The University of Georgia.

[Hamilton, 1997] Hamilton, C.. (Editor). JavaBeans Sun Microsystems

http://java.sun.com/beans

[Javasoft, 1997] Java beans specification 1.0a

http://splash.javasoft.com/beans/beans/100A.pdf

[Kuhl et al., 1999] Kuhl, F., Weatherly, R,. Dahmann, J.. Creating Computer Simulation System: An Introduction to the High Level Architecture. Published by Prentice Hall PTR.

[Miller et al., 2000] Miller, J., Fishwick, P., Benjamin, P., Szymanski, B., Taylor, B.. (2000). Research and Commercial Opportunities in Web-Based Simulation. Panel on WEBSIM’ 2000.

[Miller et al., 1999] Miller, J., Seila, A., Xiang, X. (1999). The JSIM Web-based Simulation Environment. Future Generation Computing System Journal: Special Issue on Web-Based Modeling and Simulation (1999)

[Miller et al., 1998] Miller, J., Ge, Y., and Tao, J. (1998). Component-Based Simulation Environments: JSIM as a Case Study Using Java Beans. In Proceedings of the 1998 Winter Simulation Conference, pages 373-381, Washington, DC.

[Miller et al., 1997] Miller, J., Nair, R., Zhang, Z., and Zhao, H. (1997). JSIM: A Java-Based Simulation and Animation Environment. In Proceedings of the 30th Annual Simulation Symposium, pages 31-42, Atlanta, Georgia.

[Nair, 1997] Nair, R.. JSIM: A Java-Based Query Driven Simulation and Animation Environment. Master Thesis, 1997, The University of Georgia.

[Nair et al., 1996] Nair, R., Miller, J., and Zhang, Z. (1996). A Java-Based Query Driven Simulation Environment. In Proceedings of the 1996 Winter Simulation

Conference, pages 786-793, Coronado, California.

[Pawlan, 2000] Pawlan, M.. Enterprise Java Beans – Working with Entity and Session Beans.

http://developer.java.sun.com/developer/technicalArticles/Beans/EJBEntity/index.html

[Perumalla et al., 1999] Perumalla, K., Fujimoto, R.. Jane: An Architecture for Interactive Parallel Simulation. WEBSIM '99. January 1999.

[Roth, 2000] Roth, B.. An Introduction to Enterprise Java Beans Technology.

http://developer.java.sun.com/developer/technicalArticles/Beans/IntroEJB/index.html

[Thomas et al., 1998] Thomas, A., Seybold, P.. Enterprise JavaBeans Technology

http://www.javasoft.com/products/ejb/

[Voss, 2000] Voss, G.. Java Beans, Part 1: Definition: Application Builder Tools

http://developer.java.sun.com/developer/onlineTraining/Beans/Beans1/builder-tools.html

[Xiang, 1999] Xiang, X.. Use of Agents to control the execution of Simulation Components. Master Thesis, 1999, The University of Georgia.

[Zhao, 1997] Zhao, H.. A Graphical Designer For JSIM. Master Thesis, 1997, The University of Georgia.

APPENDIX A

JSIM Builder Users Guide

When user uses the JSIM builder to build a federation, s/he could used it totally as a local builder tool, like the Sun’s BDK, or s/he could build distributed federation with it. In order to support building the distributed federation, we must first run the servers on the server side.

A.1 Deploying the EJB server

First of all, under the directory GINI, start the J2EE server at the command line prompt:

j2ee -verbose &

Then run the Application Deployment Tool:

deploytool &

When the Application Deployment Tool is shown (as figure 11), we need to create a new J2EE application.

1. In the Application Deployment Tool, select the File menu.
2. From the File menu choose New Application.
3. In the New Application dialog box, enter SimFederateApp in the Application Name field.
4. Click the button labelled "..." to pop open a file chooser.
5. In the file chooser, locate the directory where you want to place the .ear file that contains the J2EE application. We put GINI.
6. In the File name field enter SimFederateApp.ear.
7. Click New Application.
8. Click OK.

Figure 11: Application Deployment Tool

After the SimFederateApp has been created, we need to create an EJB.jar file, and put it with this application by using the New Enterprise Bean Wizard. To start the New Enterprise Bean Wizard, from the File menu choose New Enterprise Bean. The wizard displays the following dialog boxes.

• Introduction Dialog Box:

1. Read this explanatory text for an overview of the wizard's features.
2. Click Next.

• EJB JAR Dialog Box:

1. In the combo box labelled "Enterprise Bean will go in," select SimFederateApp.
2. In the Display Name field enter SimFederateJAR. Representing the EJB.jar file that contains the bean, this name will be displayed in the tree view.
3. Click the Add button next to the Contents text area.
4. In the Add Contents to JAR dialog box, choose the directory containing the class files. (This directory is GINI.) You may either type the directory name in the Choose Directory field or locate it by clicking Browse.
5. Select each of the following classes from the text area and click Add: jsim/server/SimFederate.class, jsim/server/SimFederateHome.class, jsim/server/SimFederateEJB.class, jsim/server/ServerEnv.class, jsim/server/FileExtension.class,
6. Click OK.
7. Click Next.

• General Dialog Box:

1. In the Class name combo box, select jsim.server.SimFederateEJB.
2. In the Home Interface combo box, select jsim.server.SimFederateHome.
3. In the Remote Interface combo box, select jsim.server.SimFederate.
4. Select the Session radio button.
5. Select the Stateless radio button.
6. In the Display Name field, enter SimFederateBean. This name will represent the enterprise bean in the tree view.
7. Click Next.
8. Environment Entries Dialog Box, Because you may skip the remaining dialog boxes, click Finish.

Now that the J2EE application contains an enterprise bean, it is ready for deployment.

• Specify the JNDI name of the enterprise bean.

1. In the Application Deployment Tool, select SimFederateApp in the tree view.
2. Select the JNDI Names tab.
3. In the JNDI Names field, enter JsimSimFederate and press Return. The client will use this name to locate the home interface.

• Deploy the J2EE application.

1. From the Tools menu, choose Deploy Application.
2. In the first dialog box, verify that the Target Server selection is either "localhost" or the name of the host running the J2EE server. Here we choose "localhost" which is "orion.cs.uga.edu".
3. Select the checkbox labelled "Return Client Jar."
4. In the text field that appears, enter the full path name for the file SimFederateAppClient.jar. This file will reside in GINI/ directory.
5. Click Next.
6. In the second dialog box, verify that the JNDI name for the SimFederateBean is JsimSimFederate.
7. Click Next.
8. In the third dialog box, click Finish.
9. In the Deployment Progress dialog box, click OK when the deployment completes.

A.2 Start the Federation Adaptor

To start the Federation Adaptor, you need first run rmiregistry. Under the prompt, type:

After the rmiregistry is running, we can start the Federation Adaptor. Under the GINI directory, You may run the script runServer.sh.

The content of the RunServer.sh is:

A.3 Start the JSIM Builder

Under the GINI directory, there is a script file called runClient.sh. It contains the initialize information of JSIM builder, such as the host address, the classpath, etc. Before you start it, you need to modify it. Below is an example of the runClient.sh.

After you specify the correct server host and classpath, you may run the script.

A.4 Building Federation

First, the user need to load all the desired federates – model beans and model agents into the builder box. To do this, user just needs to choose desired federate in the list of federate manager, pulls done the "Design" menu and selects the "Load Federate", and then click the desired position in the builder box.

Second, when all the federates have been loaded, the user can hook them up according to certain scenario. Of the two federates that will be hooked up, the one that will fire an event is called source federate, and the one that will listen to this event is called target federate. To hookup the federates, the user may first set the source federate as the current active federate, then pulls down the "Design" menu and select the "Hookup" menu item. There will be popup menu with a list of events shown. User could choose the desired one. Then there will be a rubber band shown with the current active federate as the pivot point. The user may drag rubber band and click the target federate. After that, a dialog with a list of event listener methods will come up. The user may choose the listener method that could listen to the event. Then there will be a dialog pop up that indicates the adaptor class is generating and compiling. After it is done, the dialog will disappear.

Third, after the adaptor class has been generated and compiled, the user may start the federation such as clicking the "start" button of the ScenarioAgent. At the last step, usually some data have been collected during the simulation will be shown, and user may analyze them.

APPENDIX B

JSIM Builder Packages

APPENDIX C

Relevant Part of HLA Java Classes