A Distributed Event Messaging System for Mobile Agent ... - CiteSeerX

A Distributed Event Messaging System for Mobile Agent Communication John McCormick, Daria Chacón, Susan McGrath, and Craig Stoneking Lockheed Martin Advanced Technology Laboratories 1 Federal Street A&E 3W Camden, NJ 08102 {jmccormi, dchacon, smcgrath, cstoneki}@atl.lmco.com

Abstract: Agent mobility presents distinct challenges not handled by traditional, distributed, communication frameworks. By nature, mobile agents change location over time, making targeted messaging difficult to achieve. Also, a communication infrastructure must handle the case that the agent may be migrating when the message is sent. We have implemented a Distributed Event Messaging System (DEMS) that satisfies the communication requirements unique to mobile agents. This infrastructure has enabled efficient control and monitoring of our mobile agents and has facilitated mobile agent collaboration and coordination.

1 Introduction Agent mobility presents distinct challenges to communication frameworks. A mobile agent poses new requirements, such as message delivery to mobile recipients, that distributed object systems cannot currently address. Traditional, distributed object, communication systems, such as those provided by Common Object Request Broker Architecture (CORBA), Distributed Component Object Model (DCOM), and Remote Method Invocation (RMI), provide a satisfactory infrastructure for stationary agent systems, by using name directories and static binding to locate and communicate with agents. In mobile agent systems, these location mappings must change over time, and the difficulty of providing a reference to a mobile object is aggravated when both the sender and receiver are mobile. Race conditions threaten communication integrity when the recipient is migrating. Mobility invalidates the static binding method used by the previously mentioned architectures. A general purpose framework should satisfy these requirements for asynchronous and synchronous communication. Lockheed Martin Advanced Technology Laboratories (LM ATL) has developed a Distributed Event Messaging System (DEMS) that provides a lightweight, communication infrastructure for our Java-based Extendable Mobile Agent Architecture (EMAA) [1]. DEMS meets all the communication challenges presented by mobile agents in general and sentinel agent behavior in particular. Mobile systems require such a robust communication delivery framework to control and monitor dispatched agents. While a mobile agent exhibits a high level of

autonomy, it should be able to receive and respond to commands from a controlling authority. A typical controlling authority would be the system, user, or agent that instantiated it. The agent should also be able to send messages regarding its state back to an interested listener, especially for logging and debugging purposes. Much of our recent work with EMAA has concentrated on sentinel agent behavior, which we define as agents persistently monitoring an environment for user-defined criterion and alerting all relevant parties when that criterion has been met. Achieving sentinel behavior frequently requires multiple collaborating agents, with subordinate child agents reporting status information back to a managing agent or system. Most of the related work that we review in Section 2 uses remote method invocation techniques for communication. The DEMS approach leverages Java’s event model to provide the flexibility required by mobile agent systems. DEMS assumes full responsibility for message distribution, relieving the message source thread from this activity, and delivers the messages in a very efficient manner. We detail the technical approach to building DEMS in Section 3 and demonstrate how it enables mobile agent control and monitoring in Section 4. We also provide performance metrics in Section 5 and lay out our road map for future enhancements to DEMS in Section 6.

2 Related Work Investigating related work in agent communication techniques yields a wealth of interest in representation of the communicated content. However, the delivery mechanisms for the communication often seem to be taken for granted or presume that the agents are static. Solutions to the message distribution problem for mobile agents are being pursued on several fronts: • Open agent and distributed system architecture specifications. • Commercial and academic agent system frameworks. • Government-funded agent infrastructure research. Two of the most significant open specifications addressing mobile agent communication come from the Foundation for Intelligent Physical Agents (FIPA) and the Object Management Group (OMG). Of the major agent systems supporting agent mobility, the two most prevalent approaches to communication distribution are use of a proprietary message routing architecture and extending a distributed object system, such as CORBA. We will compare these approaches as implemented by JATLite (proprietary routing) and Jumping Beans (Mobile CORBA). Finally we will review the Defense Advanced Research Project Agency’s (DARPA) major agent framework, Control of Agent Based Systems (CoABS) GRID, with respect to agent communication infrastructure. The FIPA draft specification for Agent Management [2] defines an Agent Communication Channel (ACC) that is responsible for routing messages among agents within the platform and to agents resident on other platforms. Two communication options are specified for agent-to-agent communication: • Agents can request their local ACC to route messages to target agents and

ACC. • Agents can contact the ACC of target platforms directly responsible for routing messages to target agents. ACC support for agent mobility is only optional at this stage of the specification, and the specification does not address the means of delivery. OMG has published a Mobile Agent Facility (MAF) specification [3] as a CORBA facility. The objective of the specification is to promote a standard interface to diverse mobile agent architectures. The specific issues addressed are agent management, tracking, and transport. Interestingly, agent communication is declared outside the scope of the MAF specification due to CORBA's extensive coverage of object communication. This implies that CORBA's communication framework is thought to be sufficient to support mobile agent communication, but the specification later clearly acknowledges that current distributed objects systems do not meet the communication requirements of mobile agents. Both the MAF and FIPA specifications focus exclusively on unicast or one-to-one communication. The MAF specification is constrained by the CORBA communication framework, while the FIPA specification appears more flexible; Multicast messaging could be an optional feature of the ACC. One important objective of both specifications not currently supported by DEMS is agent platform interoperability, and we address this issue in Section 6. Jumping Beans™ is a Java, mobile, application library developed by Ad Astra Engineering [4]. Their architecture is heavily client/server-oriented and uses a communication infrastructure named Mobile CORBA. All messaging is routed through a central server that maintains dynamic bindings to the mobile agents. This contrasts with DEMS peer-to-peer approach of enabling each host to deliver messages to any other host in the system. What is unclear from Ad Astra’s white paper is the relationship, if any, between their Mobile CORBA implementation and OMG's MAF. Again the emphasis is placed on agent-to-agent communication, while DEMS supports a Multicast distribution mechanism in which the event source is unaware of the total number of listeners or their locations. JATLite, an agent framework developed at Stanford University, uses a specially developed router application for message delivery [5]. The router maintains a file system depository of messages that agents or other components can access as connectivity permits. While the typical implementation is a centralized message depository, the framework supports multiple routers, each with its own depository. Another major initiative in agent systems is the CoABS GRID being developed as part of DARPA's CoABS program. This infrastructure for heterogeneous, agent system collaboration is built on Jini. Its design standardizes on the FIPA-ACL specification for its Agent Communication Language, using a registry service to implement the ACC functionality. The registry is currently only capable of forwarding messages to static registered agents. Techniques for supporting message delivery to mobile agents are being proposed as part of a new mobility service for the GRID.

3 Technical Approach DEMS provides an infrastructure for the creation and distribution of event messages among distributed objects that may be mobile. Farley's text, Java Distributed Computing [6], presents a number of designs for message passing systems for delivering information to agents in a distributed system. The message passing with Java events best matched the behavior needed by DEMS. DEMS expands on Farley’s design by incorporating multiple distribution modes, event caching for mobile listeners, and pipelined event delivery. DEMS is modeled after the Java event model, but the event listeners are handled differently. The Java event model is built on three main classes: event objects, event sources, and event listeners. Event sources create event objects that are then handled by the event listeners registered with it. Each event listener registers with an event source to handle specific types of events. In the traditional Java event model, the event source maintains internally a list of registered listener objects. Upon event firing, each listener is notified directly by the event source. This model breaks down in two critical ways in a distributed system with mobile objects: • The event source may be on a separate system from the listener. • The event source and event listener may be mobile, making registration rendezvous difficult to coordinate. Farley provides an Event Transceiver in his text that handles the first problem. DEMS expands on Farley's design with an EventTransceiverServer that mitigates both problems. One significant advantage of extending from the base Java event model was the ease of integrating the distributed system with Java Swing or AWT interfaces that were based on the Java event model. Farley also presents a message passing system built on RMI. This system has the slight advantage of easy extensibility, but it was inappropriate for our needs for a number of reasons: • RMI presumes non-mobile objects in the distributed system. • EMAA is not RMI-based, so there is no guarantee of a running RMI registry. • The RMI solution requires that the source of the message knows all of the listeners. • Multi-threading of delivery would have to be implemented at the event source. The current implementation of RMI assigns a new, unique identifier to an object if it transfers to a new system. This is the source of the CoABS GRID limitation to static agents. The third and fourth issues are related to the communication model used by RMI and CORBA. If the event source object is responsible for invoking the listener methods, then the source object must know all of the listeners and its thread will be dedicated to the communication activity until complete—unless special multithreaded communication logic is added. By using the EventTransceiverServer, DEMS allows delegation of the communication activity and built-in, multi-threaded delivery, event pipelining, which improves average delivery time.

The EventTranceiverServer, the primary class in the DEMS architecture, has two responsibilities (Figure 1): • Maintain registration tables of listeners located on the local host and the events to be delivered to them. • Deliver incoming events to the appropriate local listeners. Listeners may register to receive events from a specific DistributedEventSource or by DistributedEvent class type. Registering by source is accomplished by referencing the UniqueID of the DistributedEventSource. The EventTranscieverServer maintains the listener registration in three internal Hashtables: source registration, type registration, and unicast registration. If a DistributedEventListener needs to migrate to another system, then it must first unregister with the local EventTransceiverServer. The actual event transmission and receipt functionality is inherited from the TransceiverServer, which uses transmission agents to perform the remote delivery operation. The use of a transmission agent enables multi-threaded event delivery, which we refer to as event pipelining. Dock

1

1

TransceiverServer

EventTranceiverServer



1 {ordered}

UniquelyIdentifiable

*

*

DistributedEventListener

1..*

DistributedEventSource 1

EventObject

* DistributedEvent

1

1

UniqueID

Fig. 1. DEMS Conceptual Class Diagram Builds on Java’s Event Mode

The DistributedEventListener interface specifies a single method required by implementing classes, handleDistributedEvent. This is the method called by the EventTransceiverServer when delivering a DistributedEvent to the DistributedEventListener (Figure 2). Adapter classes for a listener interface are frequently provided to facilitate the demultiplexing of event to specific listener method. Examples of this will be shown in Section 4. The DistributedEventSource interface must be implemented by all classes desiring to transmit DistributedEvents via the EventTransceiverServer. The only method required is getUniqueID, which should return the UniqueID of the source object. A DistributedEventSourceAdapter is provided as a convenience to enable existing class to become sources and to enable an object to have multiple identities with respect to

TransmissionAgent Arrival

Server Activated

TransmissionAgent Thread

Registration Change

New Event

Receive Event Delivery Thread

*

Listener Thread Add/Remove Listener

for each remote host

Transmit Access Local Listeners

*

For each listener

Trigger Event Handler

Fig. 2. EventTransceiverServer Activity Diagram Shows Built-in, Multi-threaded Delivery

the events it generates. An example of this is an agent that uses one adapter to issue commands to child agents and another to report its state events. The DistributedEvent extends Java’s standard EventObject to meet the needs of DEMS. It maintains the UniqueID and Class of the DistributedEventSource that created it. Additionally, each DistributedEvent has its own UniqueID and a sequence number to help ensure proper delivery order and avoid delivery duplication. One critical requirement of classes extending DistributedEvent is that all the class members must be serializable or defined as transient. The EventTranceiverServer supports two transmission modes: Multicast and Unicast. Multicast is the default transmission mode, and its rules follow: • Local delivery to all listeners registered to event source. • Local delivery to all listeners registered to event class. • Event transmitted to all docks in the host list. • Delivery at remote docks follows local delivery rules, but the event is not propagated. Multicast events do not guarantee delivery to any particular listener. Currently the EventTransceiverServer broadcasts the event to all docks in its host list. Its parent class, TransceiverServer, supports limiting the broadcast to a subset of docks, and this capability could be added to the EventTransceiverServer at a future date with little effort. This would allow better control of network bandwidth use. The Unicast transmission mode allows targeting a message to a specific listener. The delivery of a UnicastEvent is guaranteed. The transmission rules for UnicastEvents follow: • Check for target listener locally. • Event delivered if listener registered to receive UnicastEvent from source.

• If not local, event transmitted to all docks. • Delivery at remote docks follows same rules. Although required to register with the local EventTransceiverServer upon arrival and unregister before departure, events transmitted during the migration process will be undelivered. This behavior is unacceptable for control events, which must have guaranteed delivery. A DistributedEvent caching mechanism was developed to guarantee delivery of UnicastEvents (Figure 3). Machine A

Sending ETS

Agent

Transmission Agent

Machine B

Receiving ETS

checkInterrupts wait on caching Acknowledged end wait on caching Acknowledged

requestRemoteCaching sendCachingRequest receiveObject

put in cache

getAcknowledge receiveAcknowledge unregisterListeners

x

migrate Initialize (on Machine B) THREAD BLOCK

register listeners remove forwarding merge

Fig. 3. Event Caching Sequence Diagram Shows Guaranteed UnicastEvent Delivery

Before the agent unregisters and migrates, it invokes the caching mechanism on the local EventTransceiverServer, passing the InetAddress of its migration destination. The local EventTransceiverServer sends a message via a TransmissionAgent to the destination EventTransceiverServer to begin caching UnicastEvents for the agent. Only after acknowledgement that caching has been established is the agent permitted to continue the migration process. Upon its arrival to the new host, the agent registers with the EventTransceiverServer. Any UnicastEvents for the agent that had been cached are delivered at that time and the caching is terminated. The EventTransceiverServer uses synchronized methods when listeners are registered, forwarding is removed, and cached events are being ordered and merged with events currently ready to be delivered. This prevents the possibility of duplicate events being delivered due to the event receipt while the cache is in an inconsistent state.

4 DEMS Application: Agent Monitoring and Control DEMS may be used to monitor agents’ progress and/or to control their execution. A basic set of events, event listeners, and adapters are included in a child package to support this functionality. The AgentEvent class defines the root agent monitoring event. It conveys that an agent has started, stopped, finished, failed, departed, or

arrived. It can also be used to acknowledge a control event or show that lower-level checkpoints have been met. This class is extensible, so an agent application may define additional notification reasons. The AgentEventListener interface defines a template listener that the EventTranscieverServer calls when delivering the event. A class wishing to receive an AgentEvent may implement the AgentEvent Listener; it could alternately extend or contain an instance of the AgentEventAdapter class, which provides a default listener implementation. The AgentEvent is not a Unicast event; it is always transmitted to all EventTransceiverServers, so any listener registered for events from the source will receive all of its AgentEvents. Additionally, an AgentEventListener can register to receive all AgentEvents from all sources. This is particularly useful for enabling overall system monitoring. An example of this is shown in Figure 4. Running Paused Stopped Finished Unprocessed

Fig. 4. GUI Listeners can Provide Visual Agent Itinerary Monitoring

The CommandEvent class defines the root agent control event (Figure 5). It specifies that all command events are unicast; therefore, the only agent that receives a command event is the agent to which it is directed. Three types of control events have been predefined, and they all inherit from the CommandEvent class: AgentControlEvent, VocalControlEvent, and AgentRetaskEvent. UnicastEvent

CommandEvent

AgentControlEvent

VocalControlEvent

AgentRetaskEvent

Fig. 5. CommandEvent Class Diagram

The AgentControlEvent may be used to stop, pause, suspend, or resume an agent’s execution. The VocalControlEvent may be used to turn vocality on and off for a VocalAgent or any agent descended from it. The AgentRetaskEvent can be used to change the parameters of an agent’s task. Default listeners and adapters have been predefined to handle all of these events as well. An agent application may either use the predefined events and listeners or adapters or it may inherit from the existing ones to define application-specific control events.

5 System Performance We selected the average message distribution time as an appropriate benchmark for evaluating performance of a communication framework. The distribution time is defined as the elapsed time from when the message is generated to when the listener receives the message. With respect to DEMS, the time of generation is when the event is submitted to the EventTransceiverServer by the event source. For our preliminary analysis of DEMS, we established an objective of determining the efficiency of the EventTransceiverServer delivery without concurrency. We set up the experiment with the following parameters: • Number of listeners. • Event generation frequency. • Event handler processing time. The number of listeners varied from 1 to 100 and, at each run, all of the listeners used the same processing. This experiment used a single event source whose event generation rate was slow enough to allow all the listeners to have processed a given event before the next was generated. Because we are sure there will not be concurrent event delivery, we can compute the theoretical best average delivery time. Figure 6 shows the typical results for the experiment case. 6000 Actual

5000 4000 3000 2000 1000 0 1

5

10 # Listeners

50

100

Fig. 6. Average Distribution Time, Event Handling Time = 100ms

We computed the efficiency of the distribution process as the theoretical best versus the actual average. Figure 7 shows the resulting graph.

1 0.99 0.98 0.97 0.96 % Efficiency

0.95 0.94 0.93 0.92 5

10

# Listeners

50

100

Fig. 7. High Efficiency Distribution by EventTransceiverServer, Event Handling Time = 100ms

An important property of the DEMS architecture is the parallel delivery to other hosts. If a source has 10 total listeners divided equally across two machines, the average distribution time will be much closer to 200ms than 450ms. This contrasts with the typical, remote, method invocation technique, where the listeners are processed sequentially even if delivery is delegated to a new thread.

6 Conclusions and Future Enhancements DEMS was very successful in providing the agent control and monitoring behavior required for sentinel agent behavior. As part of our research effort, we developed several demonstration applications that allowed a user to launch an agent and monitor its state and migration progress as it performed its itinerary. Users were also able to send command messages to the agents and receive confirmation of their execution. One of the important additional benefits was a alternate method of information delivery to another component in the agent system. Prior to DEMS, an agent needing to deliver information back to a user or system had two options: • Migrate back to the system and deliver the information. • Spawn a child agent to deliver the information. DEMS effectively provides a standardized way of implementing the second option. Using agents as the delivery mechanism enabled the event pipeline behavior of the EventTransceiverServer. Most importantly we were able to achieve an effective, mobile agent, communication framework that was much more lightweight than RMI or CORBA solutions. DEMS is still a work-in-progress and we are pursuing several enhancements. While it currently suits the needs of EMAA, the EventTransceiverServer does not facilitate interoperability with other agent platforms. We are investigating methods for extending the EventTransceiverServer to be aware of the CoABS GRID.

Additionally, we intend to continue our performance analysis of the DEMS. We are quite pleased with the initial results and are ready to focus on the concurrent event pipelining performance. The first goal is to determine how to calculate a theoretical best case for the experiments. We anticipated using the results of the existing and future experiments to identify potential optimizations for the infrastructure.

7 Acknowledgements We wish to thank Julius Etzl, Martin Hofmann, and Ken Whitebread for their aid in defining requirements for monitoring and control within agent systems. In addition, we are also grateful to Russ Lentini for thoroughly testing and validating our Distributed Event Messaging System, and to Virginia Garrison, who developed reusable graphical user interfaces utilizing DEMS for controlling and monitoring EMAA agents. Finally, we are grateful for the developers at ATL who acted as beta testers by using DEMS within their projects and supplied many useful suggestions.

References 1. Lentini,, R., Rao, G., Thies, J., and Kay, J.: EMAA: An Extendable Mobile Agent Architecture. (1997) 2. FIPA. FIPA ’98 Draft Specification: Part 1 Agent Management. (1998). 3. OMG. Mobile Agent Facility Specification. (2000) 4. Ad Astra Engineering. Jumping Beans White Paper. http://www.JumpingBeans.com/, October 1998. Sunnyvale, California. 5. Stanford University. The JATLite Router. http://java.stanford.edu/JATLiteRouter.html 6. Farley, J.: Java Distributed Computing. (1998) 7. Lentini, R., Rao, G., Thies, J.: Agent Itineraries: An Alternative Data Structure For Agent Systems. Dr. Dobbs Journal of Software Tools, 24(5). (1999) 60-70.