The components of COBEA include event handling primitives with which an event sink and an event source interface are defined, and event services namely a mediator and a composite event server. The architecture is illustrated in Figure 1, where components may be as primitives (grey circles) or stand-alone servers (white circles). These components can be used by applications via standard interfaces; and once included, they handle events for the applications as indicated by the arrows in dotted lines. Figure 2 shows inheritance structure of the component interfaces, in which an application may define its own typed interfaces for handling events with a choice to extend or not to extend the standard/generic interfaces defined in COBEA. We focus on the direct/indirect push model which forms the core of event communication. The pull model can easily be supported by using the CORBA request/response, or most RPC communication primitives, or the forthcoming CORBA Messaging Service [17], or by incorporating the pull interfaces defined in the CORBA event service.
Figure 1: The COBEA Architecture
Figure 2: The Inheritance Hierarchy
The event primitives support mainly event registration and notification operations defined by the event sink and event source interfaces. An application object can play the role of an event consumer or supplier by supporting the event sink or source interface respectively, or by supporting both interfaces, while providing other services at the same time (Figure 3 shows the incorporation of the event primitives in an application). Once registered the interest, the consumer will be notified whenever the event occurs. New interfaces for application-specific event handling can be derived from the primitive interfaces.
Figure 3: Direct event communication through primitives
The event services define a number of objects acting either as event mediators or providing services for handling composite events. The main task of a mediator is to decouple the consumer and supplier by accepting events from the suppliers, and passing events only to the interested consumers. Thus consumers and suppliers do not need to know each other for communicating events. Many applications require notification of events from a number of suppliers in a specified pattern of combined events from these different sources. A composite event service is designed to meet such requirements.
One design principle is that the architecture should be lightweight yet powerful enough in order to support the construction of various distributed active systems. Some of the interfaces in COBEA may be defined by inheriting from the CORBA event service interfaces; for instance, the snk interface can extend the CORBA PushConsumer interface. Extending the CORBA event service this way means, however, that all the interfaces defined by the CORBA event service must be supported. We believe it is not necessary because in our Notification Model, most CORBA event service interfaces are undesired to use by applications. Later in Section 5.1, we will discuss how COBEA can be made to work with the CORBA event service.
Another design principle is that a filter should normally be placed on a supplier or a server to reduce the traffic to the consumers; the filtering criteria can be checked either at the supplier or at the server. It is important that filters should be kept as simple as possible. Sophisticated filtering which is less commonly used by most applications can be done at the application level rather than at the event system support level. There is a trade-off between the volume of event traffic generated and the complexity of supplier, mediator or consumer objects. Related work such as the ECA (Event-Condition-Action) rules in active databases [4, 5, 22] uses conditions which are like filtering criteria but can not be separated from either the evaluation engine or the action to take upon event occurrences. In our event architecture, filters can be placed at an event server, at a supplier, at a consumer, or chained among them, thus allowing less event traffic and greater flexibility.
Three options are available for implementing COBEA on top of the general-purpose communication system (e.g. an RPC system): create a new description language for specification of events, extend an existing IDL, or construct libraries to work with an existing IDL and its RPC system. The first two approaches allow the freedom to experiment with new ideas; the second approach in particular allows a standard extension to RPC systems for event specification. However, experience shows that application programmers are very reluctant to move existing programs, or write new ones, to make use of a non-standard environment. It is also very cumbersome for small research groups to maintain a non-standard RPC system, and keep its capabilities and performance competitive with that of a standard system. Thus, we base the implementation on CORBA - an open standard for distributed object computing [15]. We make the interfaces standard or follow a well-defined design pattern instead of using a non-standard IDL. As interoperability is concerned, CORBA 2.0 is designed to deal with heterogeneity and interoperability while most RPC systems are not.
This CORBA-based approach has the following advantages:
Based on the architectural framework, we are currently implementing a class library for COBEA. We have implemented the primitives, a composite event evaluation engine plus a parser based on the composite event algebra developed at the Cambridge Computer Laboratory. We are implementing two types of event service, namely an event mediator and a composite event service; the latter will incorporate the evaluation engine and the parser mentioned above. Furthermore, applications based on COBEA can easily be made to work with the CORBA Event Service, because all COBEA interfaces are specified using standard CORBA IDL. We have also developed a fault detection system for telecommunication network management based on COBEA.