The Architecture of the READY Event Notification Service

Abstract

In this paper, we present the architecture and implementation of READY, an event notification service that provides efficient, decoupled, asynchronous event notifications. READY supports consumer specifications that match over both single and compound event patterns, communication sessions that manage quality of service (QoS) for event delivery, grouping constructs for sessions and specifications, event zones and boundary routers that bound the scope of event distribution and control the mapping of events across zones.

1. Introduction

An event notification service is a key enabling technology for building new event-based services on distributed platforms; it provides the middleware for gluing together independently-developed distributed applications. Though event-driven computation is not a new idea, there has been little work on high-level constructs for event services. The most basic event service has four kinds of entities (supplier, consumer, event, and event service) and three basic functions (supply an event, register interest in a kind of event, and unregister interest). Existing commercial event services do not provide event models that are much richer than this most basic service, e.g., there are typically no constructs that enable operations over multiple entities (events, consumers, etc.).

Event services are an important component of many application frameworks [3, 6]. Frameworks specify a consensus on common component types, event types and behavior patterns for specific application domains (how components invoke each other directly, when components supply key events, etc.). Since consensus may evolve over time, it is important to use an event service that supports event type evolution. By providing high-level constructs that describe expected patterns of behavior, more of a framework's specification can be captured and shared by applications.

In this paper, we present our work on the READY event notification system [4, 5]. READY supports consumer specifications that match over both single and compound event patterns; communication sessions that manage quality of service (QoS) and ordering properties for event delivery; grouping constructs for both specifications and sessions; event zones and boundary routers that bound the scope of event distribution and control the mapping of events across zones, among others. The overall architecture of READY, the components employed and a CORBA version of the implementation are also presented.

2. High-level event constructs

Here, we summarize the READY event constructs; further details can be found in [4]. READY clients interact with READY using admin, supplier and consumer sessions. Admin sessions are used for creating and destroying supplier and consumer sessions and session groups and for other administrative operations. Supplier sessions are used to supply events to the service. A supplier must declare the kinds of events that it will supply to a supplier session. Consumer sessions are used to register specifications that describe event patterns and actions to take when matches are found for patterns - the most common action, notify, causes the delivery of a notification with the matched event(s).

One can suspend and resume a specification, enabling and disabling matching, respectively. One can connect and disconnect a consumer session, enabling or disabling delivery of notifications for that session. Specifications can be grouped into a specgroup, enabling efficient suspend and resume of a large number of specifications. Consumer sessions can be grouped into a congroup, enabling sharing of specifications and specgroups and uniform control over their QoS and delivery properties. When a notify action occurs for a shared specification, all consumer sessions deliver the notification. A specification or specgroup is always associated with a single consumer session or congroup, and using suspend/resume on a session or congroup suspends/resumes all associated specifications.

2.1. Event structure and types

READY uses CORBA's Notification Service [12] structured events to optimize event matching. Events consist of header, filterable body, and remainder of body. The header consists of event type, and event name, and an optional variable part that may contain QoS-specific attributes, timestamps, access rights, and so on. Event types consist of a type name (T) and a domain name (D), which distinguishes type names in administrative, application, and vertical domains. The filterable body part contains attribute-value pairs, while the remainder of the body is an opaque value.

READY event type definitions specify required and optional fields for the optional header part and the filterable body. In addition, event types (i.e., type names) can have subtypes. A subtype declaration simply adds additional required or optional field specifications to those of its parent type. Compound type names like Mail.Msg.New can be used with the convention that the structure of the type corresponds to some type hierarchy - this simplifies the integration with publish-subscribe systems: simple matching expressions over compound types mimic the matching over compound subject names found in these systems.

2.2. Specifications

A specification is composed of event matching expressions together with actions that are triggered by successful matches. Matching expressions bind event variables to events that match a given event pattern. A simple matching expression is a pattern that matches a single event; Ev1: MyAlarm | $Priority > 5 binds Ev1 to the first MyAlarm event with Priority greater than 5. The general form of expressions that match a single event is:

{ event_var : event_type | expression }

The expression is any legal expression from the filter grammar specified in [12]. The $ symbol stands for the event being matched against, and component expressions such as $Priority evaluate to values of components of this event. Component expressions that select sub-parts of top-level event fields can also be used (see [12] for details).

Simple matching expressions can be combined to form compound matching expressions that describe a combination of events using the operators '&&' (and), '||' (or), ';' (then), and butnot. The '&&', '||', and butnot operators begin matching both LHS and RHS at the same time, where '&&' matches successfully once both sides match,  '||' matches successfully once either side matches, and butnot matches successfully when the LHS matches first. In contrast, the sequencing (;) operator does not attempt to match the RHS until the LHS has matched.

Another form of compound matching is to specify sequences of events that match the same ``element pattern'' (a matching expression used for each element of the sequence) using the following:

{ event_var[j..k] : event_type | expression }

The event_var[j..k] indicates that the event variable will be bound to a sequence of events, with j and k being the minimum and maximum number of events, respectively. Note that j can be zero, indicating no lower bound, and k can be an asterisk, indicating no upper bound. As a top-level expression, sequence matching completes when j successful element matches occur. When contained within a larger expression, a sequence match is successful once j element matches occur, but elements continue to be added to the sequence until either k element matches occur or the containing expression successfully matches.

A where expression can be attached to a matching expression to further constrain the set of possible matches. This expression must be a boolean expression over the event variables in the matching expression. This form is useful for expressing inter-event constraints, especially constraints over sets of events. For instance, a span constraint can be used to require that the maximum pairwise distance between Priority values for the matched events must be less than 5.

Actions are imperative statements executed at specified points during matching. An assignment action binds an event variable to a newly-created event. This is most often used to perform aggregation, where a set of matching events is summarized by a single new event. Actions that operate over event variables include the notify action and the announce action, which acts as a supplier of a new event. Actions that do not require contacting suppliers or consumers are referred to as local actions; these actions only involve changing the internal state of the READY servers. Normally notifications go to the consumer session or congroup associated with the specification, while announcements are supplied to the local zone (discussed below), but these defaults can be overridden.

2.3. Event zones

Event consumers and suppliers can be partitioned based on logical, administrative, vertical, political, or geographical boundaries. Each such partition constitutes an event zone and, typically, all event traffic between suppliers and consumers in a given zone remains within this zone. Nevertheless, there are cases where the events supplied in a zone may be useful to consumers in other zones and, hence, inter-zone routing is needed. Inter-zone routing has to support event translations (zones can differ in terms of event types, conventions adopted for use of particular fields within events, etc.) and address any information flow constraints that may exist across zone boundaries.

READY uses boundary routers, specialized READY servers that connect READY zones, for inter-zone event routing. Event routing and translation across a boundary is performed by mapping specifications that match against events in one zone and announce, possibly translated, events in another zone. Although one could write a static application that registers with two zones, consuming events in one and supplying events in the other, our approach is more flexible; READY supports dynamic addition, removal, suspension, and resumption of (groups of) mapping specifications. Finally, a further refinement of boundary routers is the ability to restrict event throughput used by inter-zone mapping specifications.

3. The architecture of READY

Each instantiation of READY uses one or more event zones, and each event zone may contain multiple READY servers. Boundary routers link together two or more event zones, and each event zone may use several routers. Boundary routers can be linked together in a hierarchical or a peer-to-peer topology, depending on the characteristics of the applications build on top of a given READY instance.

The above figure shows the architecture of a READY server. Each server consists of several components, some of which might also be used in the implementations of the various session objects created on client machines, or even as stand-alone components used by consumers for their own purposes after they receive event notifications. In the remainder of the section, we present details on some of the components.

3.1. Time dispatcher

The time dispatcher (TD) triggers registered callbacks at specific times or repeatedly at specified time intervals. During callback registration, a registration handle and time-related information are passed to TD. The pair (callback, registration handle) constitutes a unique registration identifier and allows the same object to use the same callback for multiple registrations. Using this pair, a registration can be suspended, resumed, or removed. The time-related information can be: an absolute time; a relative time from either the registration time or some absolute time in the future; or a repeating time interval with possible start and end times.

When TD invokes a callback, the handle provided during registration is passed to the callback function, together with a pointer to an instance of a Time::Tick event that contains the requested time-related information when the matching expression assigns the event to an event variable (an event instance is used here in order to have the same interface for both time- and event-related callbacks). When an absolute or a relative time is specified during registration, the callback is automatically unregistered after it is successfully invoked. When a time interval is specified, the callback is automatically unregistered when an end time is specified and this time is passed.

3.2. Event dispatcher

An Event Dispatcher (ED) triggers registered callbacks when event instances are received from suppliers. At callback registration, a sequence of event types, a registration handle, and an optional start time at which the registration becomes active and matching occurs are provided. The sequence of event types determines if the callback is invoked when an event instance is received, and event types can be any of D::T, D::*, *::T, and *::*. Callbacks are invoked for events in domain D with type T in the first case, events in domain D, independently of their type, in the second case, events with type T, independently of their domain, in the third case, and for all events in the last case.

The pairs of callbacks and registration handles are used similarly to the TD case. When a callback is invoked, the handle provided at registration and a pointer to the event instance that triggered the callback are passed to the callback function. The start time is needed for handling compound matching using the sequence (;) operator. Here, callback registrations for the RHS of the specification occur after the registered callbacks for the LHS of the specification are invoked. Therefore, to avoid losing events that occur between the time the LHS callbacks are invoked and the time the RHS callbacks are registered, events should be buffered and the RHS callbacks should be registered with the match time of the LHS. Buffering of events is triggered by pre-registration of the future RHS callbacks at the time the LHS callbacks are registered.

3.3. Simple and compound matching

Matching is implemented using simple matching elements (SMEs) and compound matching elements (CMEs), which are generated by the READY parser during the parsing of consumer specifications. These entities are organized into trees: parent nodes use children to do some of the matching work and then they combine the results in various ways or perform actions on the results (e.g., notifications). Currently, every element has one parent. In the future, a matching element that covers common sub-expressions across multiple consumer specifications might have multiple parents. SMEs are the leaves of matching trees and encapsulate the following specifications:

{ event_var : event_type	|	expression }
{ event_var[j..k] : event_type	|	expression }

SMEs register and unregister themselves with the event dispatcher in response to register and unregister invocations from their parents. CMEs are the parent nodes in the matching tree hierarchies, and are responsible for passing context information to their children and maintaining bindings of matched events. In addition, they are responsible for starting, stopping, suspending, and resuming matching of their children. Context information represents information that is the same across all matching elements (e.g., elements that are part of the same consumer session share the same QoS). Binding information for matched events represents the mapping between event variables, which are used in consumer specifications, and event instances that resulted in successful matches. Binding information is updated by SMEs on every match and is passed to parent CMEs on demand or when matching is completed - this happens on every match when the specification specifies only one event instance, or when the maximum number of matched events is reached when ranges of event instances are used in the specification.

3.4. QoS management

Several QoS properties may be used to specify session properties and indicate the delivery characteristics of notifications. Session-related QoS properties determine the reliability guarantees of consumer and supplier sessions and READY servers. The supported properties are: best effort and reliable connections, recording of events to persistent storage (to prevent event loss), and recording of session information, such as specifications, QoS settings, and established sessions, to disk (for handling failures and mobile applications).

Notification-related QoS properties determine the ordering of consumer notifications. The supported properties are: None, FIFO, Priority, Validity, Supplier-based, Type-based, and Timestamp. Validity refers to the time-to-live event header field, if present, and may be expressed as an absolute or a relative time; events whose time-to-live has expired are discarded. Timestamp refers to event timestamps and may require global ordering of event timestamps - this is done by placing matched events in a queue ordered by the lowest event timestamp and sending notifications when the event at the front of the queue has a timestamp that is less than the current time minus occur_delay, where occur_delay is the sum of the worst-case clock skew and communication delay between an event supplier and a READY server.

4. Implementation details

The initial READY prototype used its own Application Programming Interface (API) and a socket-based TCP/IP communication protocol. Socket connections were established between suppliers and servers, as well as between consumers and servers. Each supplier application used only one connection per READY server, and its supplier sessions were multiplexed over this connection. Similarly, each consumer application used only one connection per READY server, and its consumer sessions were multiplexed over this connection.

Currently, we are developing a version of READY that is using the Common Object Request Broker Architecture (CORBA) [10]. CORBA is an emerging open distributed object computing infrastructure being standardized by the Object Management Group (OMG) and embraced by numerous corporations and commercial products. Even though we could offer a CORBA-based version of the original READY API, using CORBA's Interface Definition Language (IDL), we chose to base our implementation on the Notification Service [12] specification. The standardization of the Notification Service and the fact that it already supports parts of the READY functionality were the main reasons for this choice.

Furthermore, we chose to build READY on top of a CORBA Object Request Broker (ORB) rather than on top of an existing implementation of the CORBA Notification Service because: (i) compound matching is not supported by the Notification Service and (ii) existing implementations do not offer the necessary hooks to discover the filters registered by event consumers. Consequently, several parts of the READY functionality would have to be implemented as a separate client library that gets linked with event consumer applications. While this approach is feasible, it would require changes to be made to event consumer applications built using the Notification Service specification and, moreover, several language bindings for the above client library would have to be developed.

The omniORB2 [13], a free high performance CORBA 2 ORB, is the ORB used in the current implementation. Our plans are to first finish the implementation of the Notification Service on top of omniORB2 and then offer compound matching by using the READY filter language in the place of the constraint language specified in the Notification Service specification. Since this change does not affect the interfaces of the Notification Service, the resulting implementation would be fully backwards compatible with the CORBA Notification Service.

5. Related work

Yeast [7] is a general purpose event notification system that provides a global space of events that is visible and shared in a wide area network. A event action specification can have a pattern of events which, when matched, triggers a specified action. High-level applications are built as collections of specifications. READY (REliable, Available, Distributed Yeast) extends the Yeast specification language by adding structured events, QoS directives, sessions and session groups, and several other language constructs.

The CORBA Notification Service [12] extends the CORBA Event Service [11] by adding structured events, event type discovery, event filtering, sharing of filters among several consumers, QoS properties, and an optional event type repository. READY offers better grouping mechanisms, much more powerful filtering (compound matching, aggregations, etc.), and handles event routing between servers transparently. Topologies of CORBA Notification Channels has to be explicitly managed by the clients of the Notification Service.

Other related work include Microsoft's Distributed Component Object Model (DCOM) which extends the Component Object Model (COM) [8] by adding network-based component interaction (COM does not support a decoupled mode of communication nor does it provide any of the higher-level constructs provided by READY); NEONet [9], a persistent messaging middleware offering a publish-subscribe mechanism with format parsing and conversion capabilities (unlike READY, NEONet does not offer local action support, grouping constructs, and compound event matching functionality), Vitria's Velocity server [14] and Tibco's Information Bus (TIB) [15] publish-subscribe middleware products (however, they do not offer grouping constructs, multi-event matching, local actions and event aggregation).

The OPERA group at the University of Cambridge has ongoing work on event-based distributed computation. This work includes a compound matching service that has constructs similar to READY's compound matching operators. In terms of functionality, one of the main differences between this project and READY is our study of higher-level constructs such as the session and grouping constructs. Recently, this group began exploring federation of event services [2] provides an extensible framework for developing applications and services for unified messaging. Hermod views the messaging system as a distributed active database with READY being the component that exposes modifications that occur in the core of the system in the form of events. Marvel [16] is a web-based network management environment that aggregates information from several agents and presents it as web pages containing Java applets. READY collects events from the various network elements, aggregates, filters and correlates them before sending them to Marvel aggregation management objects.

References