High-level constructs in the READY event notification system

Abstract

There is growing interest in the use of general-purpose even t notification services as “middleware” for gluing together independently-developed distributed applications. This approach was first discussed by Oki et.al.in 1993 [14], where an early version of the (now) TIBCO Information Bus [20] was described. Since then, many other commercial products have been developed that accept events from event suppliers (publishers) and deliver them to event consumers (subscribers). Publish-subscribe mechanisms have also been retro-fitted to existing middleware products, including pe rsistent message queue products and TP monitors. There is also standards work in this area, including the CORBA Event Service [15] and more recently the CORBA Notification Service [16], a feature-enriched version of the Event Service. Despite all of these products and the standardization efforts, and despite the fact that event-driven computation i s not a new idea, there has been relatively little work on highlevel constructs for event services. The most basic event service has four kinds of entities (supplier, consumer, eve nt, event service) and three basic functions (supply an event to the service, register interest in a kind of event, unregiste r nterest). Existing commercial event services do not provide event models that are much richer than this most basic service. For example, there are typically no constructs that en able operations over multiple entities. This paper describes high-level constructs (operating ove r multiple events, multiple consumers, etc.) provided by READY, an event notification system being developed at AT&T Labs [7]. Entities in the READY model include: 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 s essions; event domains and boundary routers that bound the scope of event distribution and control the mapping of event s across domains. The result is a more powerful and flexible event service. The remainder of the paper is organized as follows. Section 2 offers an overview of related systems. In Section 3, we focus on client interactions with READY. Section 4 introduces READY event types. Section 5 describes specifications, which control the actions performed by READY servers due to supplied events. Section 6 describes constructs for managing boundaries between event domains. Finally, Section 7 discusses the current status of READY as well as some general issues raised by our work. We are in the process of completing an initial implementation of READY. At the same time we are exploring the merits of READY's high-level constructs by using READY as a core component of a unified messaging system [2]. Some of the examples presented here are taken from that domain.