Defines the event listener model used to communicate database events between managers, between controllers, between managers and controllers, and between controllers and clients. Most of the event listener use is implemented in the base classes for the managers, controller APIs, and client APIs. All classes derived from these base classes have the event listener infrastructure already implemented. The only requirement of the derived classes is to dispatch an event notification whenever an object is added, modified, or deleted from the database. This means the notification would be initiated in the manager methods and propagate to the controller API, because it has registered an event listener with the manager, and continue to propagate to the client API, because it has registered a remote event listener with the controller, and then the client application will receive the notification if it has registered an event listener with that client API.

Package Specification

The MxEvent object represents the event that has occurred. It contains an MxEventType_t, describing the type of event that occurred, along with the time the event was created, a reference to the source of the event, and a serializable payload that is related to the event that occurred. The descriptions of the various event type values in the MxEventType_t.Values will describe what is expected in the payload.

To implement the event listener/dispatcher model a class needs to simply implement the MxEventNotifier interface. It can also implement the MxEventType_t.Values enumeration-style class to gain direct reference to the event types. This class can then instantiate an MxEventSupport or MxThreadedEventSupport class within it to provide the implementation of the listener/dispatcher pattern without having to implement it themselves.

To receive events from a class that implements the MxEventNotifier interface, you need to create a class that implements the MxEventListener interface and register an instance of that class with the class that will provide the notifications. Your event listener class will need to implement the method that allows you to process the events received from the notifier.

The MxRemoteEventListener class is provided in conjunction with the MxRemoteEventProxyIfc and MxRemoteEventProxyImpl classes to allow the event listener/dispatcher pattern to seemlessly extend over RMI to support remote event listeners and dispatchers. This is used by the Client APIs to hide the fact that RMI is used in its implementation.

Related Documentation

The MxObjectManager base class has its add, modify, and delete methods already designed to automatically dispatch events for these three actions. The MxObject instance passed in to these methods is sent as the payload for the corresponding events (a clone is sent for add/modify events). So, managers that derive from this base class and use the base class methods to manage the derived data objects will get notification done for free for these actions.

The MxController base class and MxControllerIfc base class interface implements the MxEventNotifier and MxEventListener interfaces. The MxClientImpl base class uses the MxRemoteEventListener class in conjunction with the MxRemoteEventProxyIfc and MxRemoteEventProxyImpl classes to implement the add/remove listener methods for the MxClient base class interface. Also, the MxClientImpl class will automatically register a remote listener with the corresponding controller interface assigned through its constructor. So, if an MxEventListener implementation in a client application is registered with the client API it is also registered remotely with the controller API. So, to complete the event listener circuit from client to manager all you need to do is make sure the controller class derived from the MxController class registers itself with its corresponding manager class.