J AVELIN !

1. JAVELIN ! Prototypingin Michael D. Myjak Vice President & CTO The Virtual Workshop, Inc. P.O. Box 98 Titusville, FL 32781 <mmyjak@virtualworkshop.com> Keith Briggs President iMT, Inc. P.O. Box 4380 Mountain View, CA 94040 <keith@imtinc.com>

2. Prototyping in JAVELIN Java Virtual Environment Layered Infrastructure & the Java Real-Time RTI Implementing Object Transfer In the HLA

3. Motivation • HLA Is Being Designed to Establish a Common Technical Framework to Facilitate Interoperability • For ALL M&S • Unfortunately, Architectural Tradeoffs Are Often Required to Satisfy Multiple and Often Conflicting Developmental Goals • This Is Especially True When One or More Operational Resources Are Constrained • Good, Fast, Cheap, Pick Any Two!

4. The Goal... • To Support Simulation Interoperability • Platform and Network Independence • Operate In a Broad Range of Heterogeneous Environments • Instantiation and Management of HLA Object Classes (Called Object Instances) • Manage HLA Object Instances Like TrueObject Oriented Object Instances • Different Than Described in the Current Draft IEEE-1516 (version 4)

5. The Goal Was Further Refined • Specifically • No Facility Exists Within HLA (Between Joined Federates) to Support • The Transference of Objects • In HLA Only Instance Attributes Can Be Managed in a Federation • Public and Private Data Management • Only Published FOM Data Is Supported • Management and Transportation of Object Behaviors • Non-existent In HLA...

6. Our Position... • Federate Scenario Level Interoperability • Cannot Occur in a Load Balanced Environment Across a Federation • As Currently Drafted in IEEE 1516 • To Improve HLA... • There Must Be Agreement Among Federates on • Object Behaviors • Private Attribute Data • Current Essential State Data Associated With the Production of Object Attribute Value Updates.

7. Why Load Balancing • Effective, Dynamic Load Balancing - • Is an Invaluable Feature Necessary for the Efficient Management of Federation Objects and Their Components. • However… • The Draft Federate API Specification [IEEE-1516] Describes Neither the Functionality nor the Essential Primitives Necessary to Support a Load Balancing Service Within HLA

8. Effective Load Balancing • To Effectively Balance Federation Resources and Processor Loads… • The Entire Object Must Capable of Being Transferred From One Joined Federate to Another • Including All Object Components • Methods • Instance Variables • Current Essential State Data. • Support Advanced Distributed Simulation in Cost-effective, Heterogeneous Environments

9. Feasibility Study • To Prove the Feasibility of Such a Task - • We Implemented a Prototype Object Transfer Service Feature Using JAVELIN and a Prototype of the Java Real-time RTI. • Functions Supported Include • Suspending an Object • Check pointing It’s Essential State Data • Packaging the Object Into a Byte Stream • Transferring the Byte Stream • Reanimating the Object • Prototyped the Internal RTI Management Operations Necessary to Complete the Re-hosting and Synchronization of HLA Object Instances.

10. Moving at the Speed of Java... • Java 1.1.7 (and Now V2.0) Serializable Interface Is Effective and Efficient in Performing the Transfer • We Accomplished the Task With Little Difficulty. • Worked With UCF Students and Faculty • The Virtual Workshop Provided the Design Criteria and Established Project Requirements • Managed the Effort Through UCF Software Engineering Program for College Credit • Full Term Class Project • Full Documentation Generated • (Software Life Cycle Process) • Test Results and Demonstration Were Provided

11. Considerations (1 of 4) • Abstraction • Pulls Common Features Shared by Objects Into Classes. • A Class Definition Describes • The Data Associated With Each Instance of the Class, • Defines the Set of Operations That Can Be Invoked on an Instance of the Class • And Proscribes the Functions That Are Executed in Response to Requests for Those Operations.

12. Considerations (2 of 4) • Encapsulation • Associates Data With the Functions That Manipulate the Data Into Objects. • Enforces Data Hiding • Since the Only Way to Access an Object's Data Is Through the Operations in the Object's Public Interface • Also Needed to Be Able to Communicate (I.E., Transmit) the Encapsulated Object

13. Considerations (3 of 4) • Inheritance • Both of Interfaces and Implementations • This Is the Mechanism That Supports the Specialization or Refinement of Classes Into Subclasses • Inheritance Is Only One Example of Reuse in Object-oriented Programming • Transporting an Object Directly Impacts the Inheritance Tree • Used to Manage the Relationship Between HLA Object Instances.

14. Considerations (4 of 4) • Polymorphism • The Ability for a Request for a Specific Operation to Be Handled Differently Depending on the Type of Object on Which It Is Invoked. • For Example, Subclasses of a Common Superclass May Override Functions Defined by the Superclass to Differentiate How Instances of the Subclasses and the Superclass Behave.

15. HLA Is Different • Many Terms, Common in Lexicon of Object-oriented Programmers, Are Overloaded With Different Meanings Under HLA. • For Example, • HLA Classes Are Described As “Having Common Properties, Behavior, Relationships, and Semantics.” • However, the HLA Does Not Adhere to the Classical Object-oriented Abstraction • Behaviors are not managed • Semantics change with each Federate

16. HLA Is Different • HLA Rule #8 states: • Federates shall be able to transfer and/or accept ownership of instance attributes dynamically during a federation execution, as specified in their Simulation Object Models. • Under HLA, objects are distributed and Ownership of objects is not permitted. • To own the privilegeToDeleteObject attribute, but not own the object is not only counter intuitive, but it goes against commonly accepted Object Oriented Programming practices.

17. HLA Really Is Different • Under The HLA Abstraction... • Behaviors Are NOT an Immutable Characteristic of an Object. • In Fact, the Opposite Is the Case. • Behaviors Change With Each Federate • Serious Problem with Interoperability! • The Description of and Support for Class Operations Are, Quite Surprisingly, Absent From HLA Terminology.

18. The Prototype... • Assume the issue of Object classification overloading has been resolved • View an HLA Object Instance as more than just a logical collection of public instance variables (i.e., attributes sans methods and state). • Prototype an Object over HLA as • an instance with state, • well-defined behaviors and • occupies some physical location(s) within the federation. • Now, can we transfer and/or accept the transference of federation objects, by dynamically changing ownership (and thus the physical location) of instances during a federation execution?

19. The Real Question... • The next logical question is whether the existing service(s) for attribute ownership transfer provide adequate functionality for object ownership transfer. • We believe this is the case, with the exception that transaction time and object deprecation are not yet incorporated into the existing HLA model. • However, the latter is relatively simple to fix. The former may take a little more work. [Myjak, 99a]

20. Rule #8 Extensions • In HLA, ownership is described as the ability for a federate to update the value of an instance attribute. • This privilege is uniquely held by a single joined federate. • To do otherwise, would invite ambiguity and generate non-deterministic results. • In our paradigm, objects are instances, owned by federates that maintain their state (i.e., they are homomorphic). • Extending the HLA RTI to provide services that allow joined federates to exchange ownership of objects brings the HLA metaphor closer in line with conventionally accepted OOP practice.

21. Implementation Strategy • Distributed Object Ownership Management Implies That Some Underlying Mechanism • “Clone” the Existing Object and State • Serialize the Cloned Object • Transfer the Serialized Cloned Object to the Receiving Host • Reanimate the Cloned Object • Synchronize It With It’s Parent Object • Receiving Federate Assumes Ownership • Source Host Deprecates the Parent Object. • In Our Version, the Java Real-time RTI Is Built Upon a System-independent Infrastructure We Call Javelin. • We Can Test This Theory Because We Own the Source!

22. JAVELIN Implementation • The Javelin software facilitates the transfer of objects and prevents objects from being transferred to hosts that do not publish it. • In the prototype implementation, object selection is made via a user interface. • The Graphical User Interface (GUI) was selected for this prototype implementation because if was easily constructed and quite useful in demonstrating the resultant affects of transferred objects. • In later releases, this interface may be deprecated, or moved to the Federation Manager’s platform so independent or automatic control can be maintained for load balancing.

23. SUN SGI IBM Linux Linux Simple Network Test Environment • A local net example with a few federates Simulation nodes PC NT 6 RTI Manager Token also manages Local Net

24. Follow-on Research • JAVELIN is designed to work hierarchically • Nest step is to transfer objects between Two connected network segments Distributed JAVELIN Broker Simulation nodes 1-5 Segment 2 RTI Manager Token Local Net Manager Token JAVELIN Broker Segment 1

25. The Across Long Distance Peers • Three local network segments connected via Interconnecting Hub Segment 3 Local Routers Simulation nodes 1-5 Interconnecting Hub Segment 2 Segment 1 RTI Manager Token Local Net Manager Token JAVELINBroker

26. And Across Wireless Networks • Example using a generic Wireless Internet or Private Intranet, etc. LAN 3 WAN Border Router/Gateway Wireless | Embedded Simulation nodes 1-5 RTI Manager Token Local Net Manager Token JAVELIN Broker LAN 1

27. Javelin Michael D. Myjak Vice President, R&D The Virtual Workshop, Inc. P.O. Box 98 Titusville, FL 32781 <mmyjak@virtualworkshop.com> Keith Briggs President iMT, Inc. P.O. Box 4380 Mountain View, CA 94040 <keith@imtinc.com>