Concordia's Event Manager is the focal point for selected events. This distributed events paradigm is useful in situations where either the sender of the event does not know all the intended recipients or the recipients do not know who the sender may be. As an example, an object which acts as a server for a resource, may send an event to interested clients indicating that the resource has been updated in some way.
The Event Manager provides a means for objects to send and receive events. It functions as both a registration and notification facility. Objects interested in receiving selected events must register with the Event Manager. Objects interested in sending events to other objects must send them to the Event Manager, which filters them and only forwards each event to the objects that have explicitly registered to receive events of that type. The Event Manager forwards events to each agent at its correct location, even if the agent has traveled to another host after registering to receive events. Also, if an agent is intransit when an event is sent to the Event Manager, the event is automatically queued and later flushed after the agent arrives at its new destination. Hence, no selected events are lost when agents travel.
This Event Manager registration and notification functionality is encapsulated within the EventManagerConnection class.
Mobile agents connect to the Event Manager by calling the Agent's makeEventManagerConnection method. This method takes a boolean argument that specifies if a proxy should be used to communicate with the Event Manager (i.e., a value of true indicates that the caller wishes to use a proxy). By using a proxy for communications, objects are shielded from Event Manager failures. The proxy is responsible for maintaining communication with the Event Manager and for re-establishing the connection if a failure occurs.
After connecting to the Event Manager, agents may register the distributed events they wish to receive with the Event Manager. This is accomplished by invoking the Agent's registerEvents method and passing it an array of Class objects representing the types of events they wish to receive (i.e., class objects for events derived from EventType). Note that the classes which define the events being registered with the Event Manager must be available to the Event Manager at the time that registerEvents is called. If this method is called from the Agent's constructor, then those classes must be in the CLASSPATH of the local Concordia Server, since the agents constructor is called before any Related Classes are loaded. Alternatively, the call to registerEvents can be moved to the beginning of the method which is executed in agents first itinerary, assuming the classes defining the events are in the list of Related Classes for the Agent.
It is also possible to register to receive all events sent to an Event Manager by invoking the Agent's registerAllEvents method.
Agents may dynamically add new event registrations by simply invoking registerEvents at any time. However, an agent may also indicate to the Event Manager that it is no longer interested in receiving certain types of events by calling the Agent's unregisterEvents method and passing an array of Class objects representing the events it is no longer interested in receiving.
Alternatively, agents may delete all their registrations by invoking the Agent's unregisterAllEvents method.
Agents send events to other objects via the Agent's postEvent method. This method takes an object derived from EventType as an argument. The event is then forwarded via the Event Manager to all objects that have registered to receive events of that type.
Next we will illustrate how the DBAccessAgent can use events.