Survey
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
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