Final Technical Report
Download 0.55 Mb.
|
- Navigate this page:
- Object representation and XML
- Future Directions
Communication StrategiesThe communication strategy is responsible for the details of communication with other agents: for the way data is represented and transmitted, and for the way agent names are mapped onto whatever lower-level entities are required. [Footnote: The term “strategy” is perhaps too grand, but it was chosen because “method” is too strongly associated with its meaning in object-oriented programming.] From the point of view of an I-X agent, it is able to send and receive objects - the same sorts of objects that it normally manipulates, such as issues, activities, constraints, plans, and collections of objects, such as lists, sets, and maps. The agent knows nothing about how objects are encoded and decoded for communication. The external representation is typically some form of XML, but it can also be something else, such as Java’s object serialization. Nor does the agent know anything about the technology used to send and receive messages. By confining this knowledge to the communication strategy, it becomes possible to use the same agents with a variety of different strategies and to avoid becoming tied to any particular approach that may change or become obsolete. This is especially important at a time of rapid and uneven development, such as we’re now seeing for XML and agent technologies, and when different projects may be committed to different choices. Two simple strategies are built-in to make it easy to create and test new agents when more elaborate communication mechanisms are not available or are too much work to use or set up. Both use a server that maps agent names to host:port addresses. One encodes objects using Java serialization; the other represents objects in XML that is then serialized as a Java String. Other strategies can be plugged-in when an agent is run. At present, there are strategies for the CoABS Grid, KAoS (implemented as a subclass of the Grid strategy), Jabber, and AKTbus. A strategy must implement only two methods: one that sends an object to a specified destination, and one that tells it to make its agent able to send and receive, by performing whatever registration and setup tasks are necessary. However, it can also affect the agent in certain other ways, such as setting its name (if the name must be established during the agent-registration process) or by adding a “tool” that provides a GUI to data held by the strategy (such as, say, an address book). Object representation and XMLIn order for agents to work with objects, leaving the external representations to communication strategies, it must be reasonably easy to translate between objects and external representations. This is an area of active development, with terms such as “serialization”, “marshalling”, “unmarshalling”, and “data binding” now in common use. To facilitate such translation, and to avoid being tied to any particular technology of that sort, we have adopted some (JavaBean-like) conventions for the definitions of classes whose instances are meant to me communicable (such as having zero-argument constructors and “get” and “set” methods that correspond to fields) and have defined a straightforward mapping between such objects and XML that can be used when other mappings are not required. The mapping is in two parts which can be replaced independently. One determines the “syntax” of classes such as which of their fields should be visible; the other uses that information to translate objects to and from XML. Unlike some other approaches, this does not generate class definitions from XML definitions such as XML Schemas. Instead, it uses Java’s reflective capabilities to extract information from the class definitions. The “class syntax” used by the XML translator is also used to manipulate objects in other ways, such as deep copying and “walking” structures to extract or change information, and to inform a “tree editor” that can be used view and modify both objects and the corresponding XML. There is also a utility that generates BNF-like syntax definitions, such as the following for Issue and related classes: ISSUE ::= priority=”PRIORITY” sender-id=”NAME” ref=”NAME” report-back=”YES-NO”>
STATUS ::= blank | complete | executing | possible | impossible | n/a PRIORITY ::= lowest | low | normal | high | highest YES-NO ::= yes | no
Much of the I-X code is still in a relatively early phase of its development in which certain aspects of the overall structure, as well as many of the details, are still being worked out. The aim is to provide a “kit” containing reusable components at the level of controllers, issue-handlers, model-managers, constraint-managers, viewers, and so on; but often they will first be developed in the context of specific I-X systems and then be “promoted” into the kit when their appropriate general form becomes clear. The kit will also evolve as work on new components suggests better implementation techniques and better forms of organization. It is likely that I-Plan will be the next major agent to be developed. It is intended to be similar to a simpler O-Plan and to be suitable for embedding in other I-X systems. I-Plan, and other systems whose model managers support multiple versions of the model, may use an already implemented context mechanism based on the one in O-Plan. It allows individual fields in objects to contain different values in different contexts, with the contexts forming a tree in which contexts inherit values from their ancestors. (It is possible to extend the same mechanism to allow multiple-inheritance, but we do not anticipate needing that capability.) Since the same data structures can be used in systems that always use only one context, the presence of the context mechanism allows us to define define data structures of greater generality and hence reusability. I-Space will also see active development, and this will lead to more sophisticated ways to working with groups of agents on shared issues and activities. Intentionally Blank Directory: project -> documents project -> Terminal Decision Support Tool Systems Engineering Graduate Capstone Course Aiman Al Gingihy Danielle Murray Sara Ataya project -> Rajinder Sachar Committee project -> Cape Lookout National Seashore Historic Resource Study By project -> Cape Lookout National Seashore Historic Resource Study By project -> Chesterfield fire department response to severe storm emergencies executive analysis of fire department operations in emergency management project -> Revolutionizing Climate Modeling – Project Athena: a multi-Institutional, International Collaboration project -> What is a Hurricane? project -> Southampton Station History and Significance History Newtown Branch documents -> Atlantic Region Climate Change Conference Sept. 14 -16, 2010 documents -> Dense Traffic these documents, drawings and specifications are the property of roadeye flr general partnership, and shall not be reproduced or used without written permission from roadeye flr general partnership. RoadEye Download 0.55 Mb. Share with your friends:
|