Event notification among distributed objects

Distributed objects

A distributed object is an object whose methods can be invoked by processes on other computers. Its state is encapsulated and is accessible only through methods defined in a remote interface, and each remote object has a unique remote object reference (network address, object id, interface) that can be passed as a parameter or result. Examples are Java RMI remote objects and CORBA objects.

Need of event notification

• Objects must react to changes in other objects (a stock price changes, a document is edited, a sensor value passes a threshold) without constant polling, which wastes network and CPU.
• It gives asynchronous, loosely coupled communication: publishers and subscribers need not know each other.
• It supports one-to-many delivery to many subscribers at once.
• It supports heterogeneous systems, and scales better than polling.
• Typical uses: collaborative editing, stock-trading, monitoring, mobile and ubiquitous computing, alarms.

Distributed event notification architecture

 Event generators          Event service         Subscribers
 (objects of interest)  +-----------------+    +-------------+
 [Obj A] --event-->     | filter, route,  | -->| Observer 1  |
 [Obj B] --event-->     | store (mailbox) | -->| Observer 2  |
                        +-----------------+    +-------------+
        <---- register / unregister (subscribe) ----

Components

1. Event generators (objects of interest): objects whose state change produces an event.
2. Events / notifications: objects holding type, source, time and attributes.
3. Subscribers (listeners): register their interest and receive notifications by remote method call.
4. Observers / event service (notifier): an intermediate object which separates generator from subscriber; can forward, filter by pattern, and store events in a mailbox for later delivery.

Operation

1. The subscriber registers with the event generator (or event service) for given event types. A lease (time limit) may be given.
2. An event occurs in the generator; a notification object is created.
3. The generator (or event service) invokes notify on every registered subscriber by RMI.
4. The subscriber acts on it; it unsubscribes when it no longer needs the events or lets its lease expire.

Models: push (the generator sends events) and pull (the subscriber asks for events). Examples: Jini distributed event specification, CORBA Event/Notification Service.