Mediator and its Interfaces

For many applications, it is useful to have an event mediator. Figure 4 shows the indirect model of event communication. The advantages of having a mediator are: (1) a consumer or a supplier does not have to keep all the contacts to every event supplier or consumer but only the contact to the mediator; (2) simple event suppliers can be built which do not support a registration method; (3) commonly used filters may be built once for all; e.g. a filter at a mediator may be placed for all faulty events from one or more suppliers; (4) it is also easier to adopt group communication protocols such as a reliable multicast protocol at a mediator.

  
Figure 4: Indirect event communication through a mediator (only simple suppliers are shown)

One assumption on the mediator is that a supplier needs a mediator to publish events; an event may be published by its type name and/or attributes (parameter names). A consumer needs to find a mediator to receive events. Finding a mediator is orthogonal to using it. Particular bindings between mediators, suppliers and consumers may also be arranged.

For standard events, the interfaces are as follows. Users may attach an application-specific piece of information when registering a new supplier.

module Mediator {
exception ...
interface Admin {
 Object new_supplier(
  in string appl_info, 
  in boolean relay, 
  out string uid)
 raises(RegistrationFailed);

 void remove_supplier(
  in string uid, 
  in string application_info) 
 raises (NoSuchSupplier, NoFound);
 };

interface proxy: 
 BaseEvent::Snk, BaseEvent::Src {
 proxy lookup(in string type_id) 
 raises (NotFound);
 };
};

For application-specific events, the interfaces should again be defined in the IDL files. Moreover, a generic interface is required for registration and notification of these events in many applications, e.g. event notification in telecommunication management. The generic interface allows dynamic addition of new event types and does not require all event types to be defined in IDL files. It is possible for a particular implementation to support only the generic interface. An exception NotImplemented will be raised if operations defined by Snk<T> or Src<T> are invoked. The generic interface of a mediator is defined as follows.

module TypedMediator { 
exception ...
interface TypedAdmin: Mediator::Admin {
 Object new_typed_supplier(
  in string type_id, 
  in boolean relay, 
  out string uid) 
 raises(RegistrationFailed);

 void remove_typed_supplier(
  in string type_id, in string uid)
 raises(NoSuchSupplier, NoSuchType);
 };

interface TypedProxy {
 void typedProxyRegister(
  in string type_id, 
  in boolean relay,
  in NVList *arglist, 
  in short argno, 
  in string filter,
  in ConsumerSpec consumer,
  out string uid,
  out string eid) 
 raises(RegistrationFailed);
 
 void typedProxyNotify(
  in string type_id, 
  in short argno, 
  in NVList *arglist)
 raises(NotConnected);

 TypedProxy typedProxyLookup(
  in string type_id) 
 raises (NotFound);
 };
};

The semantics of a mediator (either generic or application-specific) depends on the types of suppliers, which can be simple or sophisticated. To support a simple supplier, a mediator will not register events at the suppliers. It accepts any event from the registered supplier, matches it against the registered event templates and notifies the consumers. To support a sophisticated supplier, a mediator can relay event registrations to the suppliers as required or process the events as for a simple supplier. To relay, a mediator does nothing but register the consumer's reference and assign a user_id to the consumer; the user_id is useful for the consumer to deregister its interest, and for the mediator to tell which consumer the received event belongs to. After this, the mediator invokes the register<T> method at the supplier with its own reference (instead of the consumer's reference) and the user_id, and then waits for notification. Upon notification, the mediator relays the notification to the consumer by invoking the notify<T> method at the consumer. Upon registration and notification, the mediator needs to construct a specific interface for registration e.g. register<T> at the supplier, and a specific interface for notification e.g. notify<T> at the consumer in case a TypedProxy is used. In both cases, the supplier should inform the mediator about the event types it notifies before the mediator accepts any registration from a consumer for the events.