Architectural frameworks for event handling in large distributed systems are discussed in [2, 7, 14, 19, 23, 24, 25]. The CORBA Event Service [14] introduces the concepts of event channel, supplier and consumer. An event channel is an intermediate object which decouples the supplier and the consumer. Event communication may be untyped in which a single parameter of type ``any'' is used for passing events; applications can cast any type of data into this parameter. For typed event communication, an interface I is defined in CORBA IDL. In the typed push model, suppliers invoke operations at the consumers using the mutually agreed interface I; in the typed pull model, consumers invoke operations at suppliers, requesting events, using the mutually agreed interface Pull<I>. Some application scenarios may be supported by the push and pull models, or a combination of them. But it is not possible for a client to select only those events which are of interest, at fine granularity, by means of a detailed specification of parameters and wild cards. Furthermore, in the push model, the supplier is responsible for acquiring the reference to an appropriate notification interface in order to push events to the consumer. The CORBA event service also lacks the ability to filter events; only filtering by interface type is available. Other major limitations include overly general, thus inefficient for many applications, lack of standard semantics and protocols for event channels and lack of type safety in untyped interfaces. Schmidt and Vinoski have reviewed the CORBA event service [21].
The Cambridge Event Paradigm [2] addresses some of the shortcomings mentioned above as well as some advanced event handling issues. The publish-register-notify mode is very well supported: a service that is the source of (parameterised) events publishes in a Trader the events it is prepared to notify, along with its normal interface specification. For scalability, a client must register interest (by invoking a register method with appropriate parameters or wild cards) at the service, at which point an access control check is carried out. Subsequently, whenever a matching event occurs the client is notified. Filtering by parameters including wildcard parameters and by event types at event sources are the key features, which eliminate the need of placing filters between the event server and client. For example, users may specify filtering criteria which describe the PrintFinished event on a file named ``foo'' (by giving the file identifier upon event registration), or on every file (by giving a wildcard file identifier ``*''). The Cambridge work focuses on providing event handling primitives which are based on the direct push model. A heartbeat protocol has been incorporated, which can be tuned for the trade-off of computation cost between timely and delayed event evaluation in order to ensure correctness in the light of network failures. Access control on event registration have also been proposed; you may not be allowed to monitor the movement of your boss, for instance. In addition, a Composite Event Language and an evaluation engine have been developed to allow the use of composite events. The language currently has five operators: Without (-); Sequence (;); And (&), Or (|); Whenever ($) (see [8] for details). For example, a composite event $Enter(x, r) will trigger whenever someone x enters a room r; and an event Enter(a, 123) | Enter(b, 123) will trigger if either person a or b enters room 123.
The design, however, is based on a conventional RPC system rather than an object-oriented paradigm. The implementation uses MS-RPC3, a locally developed RPC system, thus has limited interoperability. Furthermore, it requires extension to the MS-RPC IDL for specification of events, thus has the need to marshal events separately from ordinary RPCs. It does not directly address issues of indirect event communications, although a composite event server may be used as an event mediator.