Composite Event Service

There is an increasing demand for using composite events, for example, in telecommunication network management, several alarms raised by some network devices may contribute together towards a particular network problem known to the network manager; this requires that several events (i.e. alarms in this case) be signalled as a whole to the consumer (i.e. the network manager in this case). A composite event server is therefore included in our architecture as one of the main components. Specification of composite events needs to follow a well-defined syntax to allow standard parsing by a composite event server. A composite event algebra has been developed at Cambridge on which a composite event language is based. For instance, a sequence of events A and B is specified as A ; B, and event A or event B happens is specified as A | B.

One way to register a composite event with a server is using an application-specific interface. Typical parameters in such an interface include event type name, a list of parameters associated with the event in which each parameter is represented by a structure (e.g. NamedValue in CORBA) with attributes such as parameter name, parameter type, parameter value, parameter mode (i.e. in, inout or out), a filtering string, a string expression of the composite event (e.g. A | B) in the Cambridge Composite Event Language, and other parameters such as the consumer's reference, duration, QoS etc. The interface looks like:

(string , NVList , string , ..., string , NVList , string , string expression, Duration d, ... );

where CT is the type name of a composite event. As before, the position of the characters in the filter corresponds to the position of each of the parameters in the list.

Another possible way to register a composite event is using a standard interface in which expressions of composite event are specified in a well-defined syntax (e.g. the constraint language from the OMG Life Cycle Service [14]) and passed as a string. For example, a composite event may be expressed as:

``event_type = ``enter''; room =``T14''; person = ``Oliver''; duration = ``Mon to Fri'';'' | ``event_type = ``absence''; room = ``T14''; person = ``*'';''

The interface may look like:

registerComp(string expression, Duration d, ...);

We concentrate on the former because it is consistent with our interface design in COBEA. It is also useful to have a generic interface for composite event registration as it is for base events. To be notified of a composite event, a consumer has to submit upon registration the parameters to be passed through the notification. If the base events are not available at the server, the server will look for the suppliers; this is similar to the lookups by a consumer for a supplier. The interface is as follows.

module CompositeEventServer {
exception SyntaxError {};
interface CompAdmin:TypedMediator::TypedAdmin {};

typedef struct BaseEvent 
 {string type_id; NVList *arglist; string filter};

typedef sequence<BaseEvent> CompEvent;

//generic composite event registration
 void typedRegisterCompEvent(
  in short eventno, //the number of base events
  in CompEvent comp_event, //related base events
  in string expression,//describes the comp. event
  in short out_argno,      
  in NVList *out_arglist,  
  in ConsumerSpec consumer,
  out long uid,
  out long eid)
 raises (SyntaxError,RegistrationFailed);

  void typedNotifyCompEvent:
   TypedMediator::TypedProxyNotify {};
  };

The CompAdmin is for a supplier to register itself with the server by indicating the base events it supports, and to get a reference to a proxy for passing the base events. There is no difference from a supplier's point of view whether a base event is used in a composite event or not.

Upon a registration of a composite event, the server will analyse the parameter comp_event to retain the type name, the parameters and the filters for each of the base events. The relation of the base events is obtained from the expression, e.g. A;B;C where A, B and C are base event type names. The server also retains from out_argno and out_arglist the parameters for constructing a notification interface to invoke at the consumer. More complex filtering is possible given the support for composite events. For example, consumers may specify a list of parameter values in events to be received ; a composite event A(12, ``foo'', ``<==='') | A(14, ``foo'', ``>=== '') may be used for an event filter which checks if the first parameter is less than 12 or larger than 14, and the second parameter is ``foo''. Note that the composite event is expressed here intuitively rather than by using the interfaces defined in this section.