Transcript No Slide Title

Distributed-OMAR:
Reconfiguring a Lisp System as a
Hybrid Lisp/(Java) Component
Nichael Cramer
17 Nov 1998
GTE-I / BBN Technologies
The OMAR System
• Additional information:
– Stephen Deutsch ([email protected]).
– http://www.sover.net/~nichael/misc/
– (Papers available at front.)
Distributed-OMAR
GTE-I / BBN Technologies
The OMAR System
• Simulation Development Environment.
–
–
–
–
–
–
Editing/Browsing tools.
Displays for runtime monitoring.
Application-specific displays (e.g. radars).
Procedure language (SCORE).
Simulation engine.
“Human in the Loop” experiments.
Distributed-OMAR
GTE-I / BBN Technologies
The OMAR System
• OMAR has been primarily used in the
modeling of human performance.
– Multi-tasking capabilities of humanoperators.
– Teamwork activities.
– Air Traffic Control and Flight Deck
simulation.
Distributed-OMAR
GTE-I / BBN Technologies
The OMAR System
• For the present talk:
– OMAR is a large, simulation application,
written in Lisp (ACL) and CLIM, running
on Unix (Solaris and SGI) platforms.
– Signal/Event-based semantics for interprocedure communication.
Distributed-OMAR
GTE-I / BBN Technologies
Distributed-OMAR
• OMAR was successful.
– (I.e. the customer was very happy.)
• Interest in “distributing” OMAR.
– OMAR as “intelligent agent” in existing
systems.
– Network of OMAR agents.
– Interact with other agents/components.
– Web-based operation.
Distributed-OMAR
GTE-I / BBN Technologies
Distributed-OMAR Architecture:
Design Goals
• Distributed
– OMAR should be able to participate as an
equal in distributed systems consisting of
multiple remote, independent Agents or
other Components.
– OMAR’s internal modules should be able to
run in a distributed manner as needed.
Distributed-OMAR
GTE-I / BBN Technologies
Distributed-OMAR Architecture:
Design Goals
• Flexible.
– Usable with:
• Broad range of systems.
• Multiple “external” languages/platforms.
• Assortment of middleware choices.
– Stable as standards change.
Distributed-OMAR
GTE-I / BBN Technologies
Distributed-OMAR Architecture:
Design Goals
• Robust and Maintainable.
– To the extent possible, there should be a
single D-OMAR
• I.e. not a “Corba-OMAR”; a “RMI-OMAR”; etc.
– Main System Functionality in Core-OMAR
(Lisp) system.
• Efficient.
Distributed-OMAR
GTE-I / BBN Technologies
Distributed-OMAR Architecture:
Design Goals
• Maintain the central Lisp functionality.
– Maintain the advantages that Lisp provides.
• Dynamic class inheritance.
• Rapid-prototyping capabilities.
• Etc.
– Specifically: Want to be able to continue
writing the core simulation engine in Lisp.
Distributed-OMAR
GTE-I / BBN Technologies
Distributed-OMAR Architecture:
Overview
• Distributed-OMAR presents itself to the
external components as being a single
unified component in the target language.
– Examples:
• An “OMAR Bean” in Java.
• An “OMAR Federate” in HLA.
Distributed-OMAR
GTE-I / BBN Technologies
Distributed-OMAR Architecture:
High-Level Structure
• Core-OMAR module...
• (Compact version of Lisp simulation system.)
• through inter-module communication…
• (Socket-based serialization protocol.)
• to Connection in External language.
• (Presence of D-OMAR in foreign language.)
Distributed-OMAR
GTE-I / BBN Technologies
Distributed-OMAR Architecture:
High-Level Structure (cont.)
• In external Language, D-OMAR presents
a basic “External Connection” object.
– External Connection behaves as a source
and sink of D-OMAR events in the External
language.
Distributed-OMAR
GTE-I / BBN Technologies
Distributed-OMAR Architecture
• Can run with assortment of external
languages.
– Java is language of choice.
– But, other languages available.
• “Piggy-back” off features of external or
embedded language.
– Can use standard networking tools.
• E.g. RMI in Java; CORBA; HLA …
– Graphics packages, etc.
Distributed-OMAR
GTE-I / BBN Technologies
Distributed-OMAR Architecture
• The Core-OMAR system remains
compact and intact.
– Remains in pure CommonLisp.
– It continues to be able to do what it does
well.
• Only a small layer (Cap) needs to
changed to work in different systems.
Distributed-OMAR
GTE-I / BBN Technologies
Core OMAR Module
• Original Lisp “Kernel”.
– Score
– SFL
– Rule-based language
Core
OMAR
• Pure Common Lisp
– Plus socket package.
– Direct graphics/editing
support removed.
• Primarily Signal (Event)
based semantics.
Distributed-OMAR
GTE-I / BBN Technologies
Core OMAR API
• Well-defined, cleaned-up
functional API protocol.
Core
OMAR
• Commander
– “Incoming” Commands
• Listener
– “Outgoing” Commands
Distributed-OMAR
GTE-I / BBN Technologies
OMAR Master
• Implementation of the
Core-OMAR API.
Core
OMAR
Master
• Governs communication
with “outside world”.
• More than one possible
implementation.
– Command-Line.
– “OMAR Classic”
Distributed-OMAR
GTE-I / BBN Technologies
Distributed Master
• Communicates to external “Connections”
– Connection written in language of host
system (e.g. Java, C++).
• Communication is a socket-based,
serialization, message-passing protocol.
Distributed-OMAR
GTE-I / BBN Technologies
Sockets
• Sockets:
– Standard mechanism for inter-process
communication.
– TCP/IP based communication layer.
– Common to virtually all platforms.
Distributed-OMAR
GTE-I / BBN Technologies
Serialization
• Serialization:
– Mechanism for moving objects (Strings,
Events, Structures, etc) between processes.
– (Encoding representation of Objects into a
byte-stream representation, to be decoded by
an external process.)
Distributed-OMAR
GTE-I / BBN Technologies
Message-Passing
• Message-passing:
– High-level specification of a request for a
state-change.
• Event, method call, ….
– In the stream, an object with a “state-flag”
and a set of arguments.
Distributed-OMAR
GTE-I / BBN Technologies
Distributed Master (continued)
• External Connections can run on:
– Same machine (standard mechanism).
– Different machine.
• Event-based communication.
– Independent of language of Connection.
• Single protocol for all Connection types.
Distributed-OMAR
GTE-I / BBN Technologies
Distributed Master (continued)
• Current Connection types:
– Control GUI Connection.
• OMAR editing and simulation-control panels.
– Application GUI Connection.
• Panels specific to Current application.
– External Connection.
• Communicates with other “Agents”.
Distributed-OMAR
GTE-I / BBN Technologies
Distributed-OMAR Component
Control
GUI
Connection
Core
OMAR
Java
External
Connection
Distributed
Master
Application
GUI
Connection
Distributed-OMAR
GTE-I / BBN Technologies
Control GUI Connection
Scenario
Control
Panel
Core
OMAR
Control
GUI
Connection
Distributed
Master
LISP
Procedure
Browser
JAVA
Concept
Editor
Distributed-OMAR
GTE-I / BBN Technologies
Control GUI Connection -Java
• In the Java world, OMAR (as viewed
through the external Connection) is now
“just another Java component”.
• To which other Java component connect in a
standard way.
Distributed-OMAR
GTE-I / BBN Technologies
Control GUI Connection -Java
(continued)
• Can use any standard Java mechanism
for inter-component communication.
– Regular Object-Oriented method calls.
– RMI.
• For example, publish and subscribe to
Events in standard way (“Listener”).
Distributed-OMAR
GTE-I / BBN Technologies
Control GUI Connection -Java
(continued)
• In short, foreign-language Connection
behaves as “conduit” into Core-OMAR.
• Connections serve as “sources” and
“sinks” of Events in the Java world.
• Finally, nothing special about the fact
that the connection is written in Java.
Distributed-OMAR
GTE-I / BBN Technologies
Control GUI Connection
Scenario
Control
Panel
Core
OMAR
Distributed
Master
Control
GUI
Connection
Procedure
Browser
Concept
Editor
Distributed-OMAR
GTE-I / BBN Technologies
Distributed-OMAR Architecture
External
D-OMAR
Agent
1
Control
GUI
Connection
Core
OMAR
Java
External
Connection
Distributed
Master
Application
GUI
Connection
Distributed-OMAR
External
D-OMAR
Agent
2
External
Agent
3
GTE-I / BBN Technologies
Communication with External Agents
• Standard External Connection Object.
– Common to all module types.
• D-OMAR presents a thin “Cap” to
External language.
– Wrapper on External-Connection object.
– Specific to communication/middleware type.
– Inner structure hidden to outside world.
Distributed-OMAR
GTE-I / BBN Technologies
Communication with External Agents
External
Agent
1
Communication
Specific
“Cap”
Java
External
Connection
External
Agent
2
External
Agent
3
Distributed-OMAR
GTE-I / BBN Technologies
Communication with External Agents
• Java Inter-Agent Communication:
–
–
–
–
–
Standard O-O method invocation.
RMI (Remote Method Invocation).
Corba
Voyager
HLA
Distributed-OMAR
GTE-I / BBN Technologies
Standard O-O Method Invocation
External
Agent
1
Standard
Cap
OMAR
Java
External
Connection
External
Agent
2
Distributed-OMAR
GTE-I / BBN Technologies
Remote Method Invocation (RMI)
External
Agent
1
RMI
Cap
Java
External
Connection
Central
Remote
Server
External
Agent
2
Distributed-OMAR
GTE-I / BBN Technologies
ORB Connection (e.g. Corba)
Corba
Cap
Java
External
Connection
External
Component
1
O
R
B
External
Component
2
Distributed-OMAR
GTE-I / BBN Technologies
Distributed-OMAR Architecture
External
D-Omar
Agent
1
Control
GUI
Connection
Core
OMAR
External
D-Omar
Agent
2
Java
External
Connection
Distributed
Master
Application
GUI
Connection
Distributed-OMAR
Distributed
Omar
Component
External
Agent
3
Remote
Systems
GTE-I / BBN Technologies
OMAR Communication
with Other Implementation Languages
• Event-communication doesn’t depend on
details of Event-Listener.
• Connection only needs to support:
– Sockets.
– Serialization protocol.
Distributed-OMAR
GTE-I / BBN Technologies
OMAR Communication
with Other Implementation Languages
• Connection need not be written in Lisp or
Java.
• Nothing in Core-OMAR module changes.
• An example: HLA.
Distributed-OMAR
GTE-I / BBN Technologies
D-OMAR/HLA Architecture
External
Federate
1
Control
GUI
Connection
(Java)
Federate
Cap
Core
OMAR
(Lisp)
Distributed
Master
(Lisp)
C++
External
Connection
R
T
I
Application
GUI
Connection
(Java)
Distributed-OMAR
External
Federate
2
GTE-I / BBN Technologies
D-OMAR/HLA Architecture
• C++ based External Connection and
HLA Cap have been implemented and
initially tested.
• Currently converting to vendor supplied
Java/C++ Federate interface/wrapper.
Distributed-OMAR
GTE-I / BBN Technologies
Distributed-OMAR Architecture:
Summary/Status
• Consolidated Core-OMAR kernel.
– In Common-Lisp/CLOS
• + Processes.
• + Socket-code.
• (Again, no graphics code.)
– Can run in any Lisp that supports these.
• Currently using Allegro Common-Lisp.
• (MCL all but sockets/Open Transport).
• (Harlequin)
Distributed-OMAR
GTE-I / BBN Technologies
Distributed-OMAR Architecture:
Summary/Status (continued)
• Standard Protocol for Connection to
External Languages.
• Current implementations in:
– Java.
– C++ (HLA).
– Lisp.
Distributed-OMAR
GTE-I / BBN Technologies
Distributed-OMAR Architecture:
Summary/Status (continued)
• GUI implementation in Java.
• Implementation of Java-based
communication among collection of DOMAR agents.
• In Java: Runs “anywhere”.
Distributed-OMAR
GTE-I / BBN Technologies
Distributed-OMAR Architecture:
Summary/Status (continued)
• Current Platforms:
–
–
–
–
Windows NT/98.
Sun/Sparc.
(SGI)
(MacIntosh)
Distributed-OMAR
GTE-I / BBN Technologies
Distributed-OMAR Architecture:
Summary/Status (continued)
• Middlewares used.
– Corba.
– HLA.
– RMI.
• (Nexus object for collection of D-OMAR agents.)
– (Simple Java Method calls.)
Distributed-OMAR
GTE-I / BBN Technologies
Distributed-OMAR Architecture:
Summary/Status Recap
• Single Common-Lisp source code for all
system configurations
– At most, involves a recompile.
• Single Java source code (exclusive of
application-specific Cap).
– Class files (binaries) “Run anywhere”.
Distributed-OMAR
GTE-I / BBN Technologies
Distributed-OMAR:
Reconfiguring a Lisp System as a
Hybrid Lisp/(Java) Component
Nichael Cramer
17 Nov 1998
GTE-I / BBN Technologies
Appendix 1:
ObjectStream Structure
• ObjectStream class:
– Supports socket-based read/write bytes
operations.
– Supports serialization API.
• (read-object <objstream>)
• (write-object <objstream> <object>)
Distributed-OMAR
GTE-I / BBN Technologies
Appendix 1:
ObjectStream Structure
• ObjStreamParser object:
– Passed as argument to ObjStream.
– Governs details of translation in
reads/writes in serialization.
Distributed-OMAR
GTE-I / BBN Technologies
Appendix 1:
OMAR Parser Class Structure
– base-parser:
• (Error-handling; basic read/write operations.)
– core-parser:
• (strings, numbers, arrays, etc.)
– lisp-parser:
• (Cons cells; lists; etc.)
– omar-event-parser:
• (omar-events; concept-structures; etc.)
Distributed-OMAR
GTE-I / BBN Technologies
Appendix 2:
ObjectStream as “Eval-Server”
• “Message-passing” not the only protocol
ObjectStream.
• Java calls to Lisp can be written as
(stringified) Lisp form.
Distributed-OMAR
GTE-I / BBN Technologies
Appendix 2:
ObjectStream as “Eval-Server”
• Eval-Server:
– Use existing serialization protocol.
– Java submits request as string into Lisp.
• submitEval(“(setq mainval (* 3 substate))”);
– Lisp performs a read-from-string.
– Returns (serialized) result value to Java.
Distributed-OMAR
GTE-I / BBN Technologies
Appendix 3:
DrawStream/Procedure Browser
• Tool for graphically viewing structures of
and communications between procedures
in D-OMAR models.
• Multiple Views:
• Super-/sub-procedures (who calls, etc.)
• Signals generated/waited-for
• Procedure view.
Distributed-OMAR
GTE-I / BBN Technologies
Appendix 3:
DrawStream/Procedure Browser
• Super/Sub-procedures and Signal views
are graph-based.
– Java Gui requests data-structure to view.
– Lisp prepares the data-structure and ships it
off (via serialization) to Java.
– Java uses standard graphing display code to
display the results.
Distributed-OMAR
GTE-I / BBN Technologies
Appendix 3:
DrawStream/Procedure Browser
• Procedure view (uses DrawStream):
• View is laid-out and “drawn” in Lisp.
– Uses pre-existing Lisp display code.
– Display code draws to a DrawStream object.
– DrawStream encodes drawing commands as
a sequence of bytes.
Distributed-OMAR
GTE-I / BBN Technologies
Appendix 3:
DrawStream/Procedure Browser
• Representation (sequence of bytes) is
shipped to Java.
– Currently as an Array (in an Event).
– Alternatively: “Live” byte-stream.
• Bytes are rendered in Java.
– DrawStreamCanvas.
• Decodes byte-sequence representation.
Distributed-OMAR
GTE-I / BBN Technologies
Appendix 3:
DrawStream/Procedure Browser
• Gestures are handled:
– Transmit screen location back to Lisp.
– Lisp returns any appropriate object.
• Note that the DrawStream object and the
Java DrawStreamCanvas class are “write
once” constructs which can be re-used
with other Lisp displays.
Distributed-OMAR
GTE-I / BBN Technologies
Appendix 3:
DrawStream/Procedure Browser
• Demo.
Distributed-OMAR
GTE-I / BBN Technologies
Distributed-OMAR:
Additional information:
http://www.sover.net/~nichael/misc/
Nichael Cramer
17 Nov 1998
GTE-I / BBN Technologies
Distributed-OMAR:
Reconfiguring a Lisp System as a
Hybrid Lisp/(Java) Component
Nichael Cramer
17 Nov 1998
GTE-I / BBN Technologies
Why not simply Corba?
(foreign-function calls?, etc?)
• When we started, no Lisp Corba binding.
– This has changed/is changing.
• But, for example, no signal servicing.
• Don’t want to be “Corba-specific”.
– I.e no multiple versions to run with:
• HLA, DCOM, RMI…
Distributed-OMAR
GTE-I / BBN Technologies
Why not simply Corba?
(foreign-function calls?, etc?)
• Lightweight
– Don’t need an ORB to (e.g.) just run a GUI.
– D-OMAR has a single protocol to
communicate with all external processes.
• Works with any CommonLisp
– (Provided it supports sockets.)
Distributed-OMAR
GTE-I / BBN Technologies
Why not simply Corba?
(foreign-function calls?, etc?)
• By moving the burden into (Java), we can
automatically leverage any Java-based
middle-ware support.
– In short, we are betting that Java will always
have better support for middleware, GUIs,
etc.
Distributed-OMAR
GTE-I / BBN Technologies
Why not simply Corba?
(foreign-function calls?, etc?)
• Finally, if the decision is made to convert
D-OMAR to a Corba base, we only have
to re-write the Connection protocol.
– Modular design ensures a (relatively ;-)
painless transition.
Distributed-OMAR
GTE-I / BBN Technologies
Distributed-OMAR:
Reconfiguring a Lisp System as a
Hybrid Lisp/(Java) Component
Nichael Cramer
17 Nov 1998
GTE-I / BBN Technologies
Distributed-OMAR:
Reconfiguring a Lisp System as a
Hybrid Lisp/(Java) Component
Nichael Cramer
17 Nov 1998
GTE-I / BBN Technologies
Example: Command-Line Master
Core
Omar
Command
Line
Master
> :Scenario select “ATC”
> :Scenario run
> Report: time = 0.
> Report: time = 5.
> Report: Event (Comm AC-11 ATC-23)
> Report time = 10.
> Report: Event (ATC-23 Acknowledge)
GTE-I / BBN Technologies
Application GUI Connection
Radar
Display
Control
GUI
Connection
Core
Omar
Distributed
Master
Application
GUI
Connection
ATC
Control
Panel
Cockpit
Display
GTE-I / BBN Technologies
Control GUI Connection -Java
(continued)
• Events function as high-level request for
state-change.
• Independent of nature of Subscriber.
• No restrictions on how Subscriber uses
events.
– I.e. it can “do what it wants” with events.
Distributed-OMAR
GTE-I / BBN Technologies
D-OMAR/HLA Architecture
• “Federate-Cap” functions as conduit
into/from Core-OMAR module.
• Because Cap has no application-specific
information, it can be reused.
• All modeling behavior is handled within
Core-OMAR.
Distributed-OMAR
GTE-I / BBN Technologies
D-OMAR/HLA Architecture
External
Federate
1
Federate
Cap
Core
OMAR
C++
External
Connection
Distributed
Master
R
T
I
LISP
Distributed-OMAR
C++
External
Federate
2
GTE-I / BBN Technologies