RMI functionalities; event notification

Functionalities provided by RMI software

• Remote invocation: call methods of objects in other processes with the same syntax as local calls.
• Proxy and skeleton generation: marshalling, sending, dispatching.
• Remote object references and a remote reference module to map them.
• Naming and binding: a registry / naming service to look up objects by name.
• Parameter passing: by value (serialisation) or by remote reference; transfer of object state and class code (dynamic class loading).
• Request-reply protocol with invocation semantics (at-most-once), timeouts, exceptions.
• Distributed garbage collection of remote objects and activation of objects on demand.
• Security through a security manager and optional encrypted channels.
• Concurrency: server threads handle many calls at once.

Event and notification system

Events let objects react to changes in other objects without polling. It uses the publish-subscribe paradigm.

 Object of interest -> Event service -> Subscriber A
 (publisher)           (notifier)    -> Subscriber B
        events (notifications), decoupled and asynchronous

Roles

• Event generator (object of interest): where an event (state change) happens.
• Event / notification: an object with data about the event (type, time, source).
• Subscriber (observer): registers interest and receives notifications.
• Observer / event service (notifier): forwarding, filtering, patterns and mailboxes between generators and subscribers.

Implementation in distributed objects

1. The subscriber (implementing a remote listener interface) calls register on the generator to subscribe to an event type.
2. When the event happens, the generator creates a notification and calls the subscriber's notify method by RMI.
3. The subscriber handles it. It can unsubscribe at any time.

In Jini the registration carries a lease, a time limit, so that dead subscribers are removed. In CORBA, the Event Service uses event channels (push and pull models).