Primitives and Interfaces

Two objects are identified in the event notification model: a source and a sink of an event. It is essential for an event sink to receive events sent by an event source. The event source should support interfaces for event registration and deregistration; the event sink should support an interface for event notification. Both objects should also support a disconnect operation. The primitives also support the passing of a generic event header with standard attributes (properties), such as event identifier, creation time, type name, event source identifier and priority code. In addition, the interfaces allow a single parameter - event body - for passing application-specific event data dynamically. If more parameters are to be passed in applications, new interfaces should be defined, which can extend the primitive interfaces.

The standard interfaces are specified in the CORBA IDL as follows. The definition of exceptions is omitted.

module BaseEvent {
exception ...
struct EventTime 
 {long sec; long usec; string clock_id;};

struct EventHeader {
 long id;  //the event id
 EventTime create_time; 
 string event_type;
 string source_id;
 long priority; //severity code of event
 };

struct Duration {
 EventTime begin; EventTime end;
 }; 

struct ConsumerSpec {
 Object consumer_ref,
           //the consumer object reference
 Duration, //for time specific filtering   
 string QoS, //QoS constraint
 string who, //for access control
 };

interface Snk {
 void notify(in EventHeader e, in any data) 
 raises (NotConnected);
 void disconnect_snk();
 };

interface Src {
 void register(
  in EventHeader e, 
  in string header_filter, 
  in any event_body, 
  in string body_filter,
  in ConsumerSpec consumer,
  out long uid, //the consumer id
  out long eid) //the registration id
 raises (RegistrationFailed);
 void deregister(in long uid, in long eid) 
 raises (UserNotFound, EventNotFound);
 };
};

At registration of interest, a number of filtering parameters are allowed, including a duration for specifying the start and end time of events of interest. A filter each for the event header and the event body can also be specified, which is defined by a string containing operators including ``* '' for wildcard, ``=='', ``>='', ``<='', ``<'', ``>'', and ``!='' for comparison. Filters can be used in combination with the given value of the parameters in the event header or body. The position of the operators in a filter is important; they correspond to the position of the parameters in the event header or body. Each operator is two characters long with a trailing space in case of ``>'', ``<'' or ``*''. For more complex filtering, see the section on the composite event service. In addition, the relation among the expression of the parameters is conjunction. The parameter QoS is for the consumer to specify quality-of-service requirements such as reliable delivery or fast (unreliable) delivery of events. The parameter ``who'' can be used to pass user identification for access control. Upon registration, a Template will be created which describes what event should be sent to which consumer.

For notification, an event matching the template of an event registration should be passed by the source to the registered sinks. Upon notification, actions can be taken at the consumer depending on applications.

An event communication can be broken by invoking a disconnect_snk operation at the event sink, or a deregister operation at the event source. A deregister operation will either remove a registered consumer with all related event templates or only a particular event template. If a communication is closed by the supplier, the consumer receives a notification through the disconnect_snk operation. The communication can only be resumed upon another register operation.

It should be noted that the defined interfaces allow only a standard event header with fixed number of parameters; the interfaces are also standard. For many applications, specific interfaces can be defined by following a well-defined design pattern in IDL files, e.g. register<T>(), where T may by substituted by a DrawEvent or AccountingEvent for a drawing or an accounting application respectively. A common set of event manipulation operations, such as comparison of the occurrence of an event against the registered templates, are supported through a common class library.

An example of an application-defined event sink interface may look as follows, where is a type name. k parameters are used in this example. The interface extends to the standard Snk interface.

interface Snk<T>: BaseEvent::Snk {
 void notify<T>
  (in T1 arg1, in T2 arg2,..., in Tk argk) 
 raises (NoSuchType, NotImplemented);
 };