ADEES: An Adaptableand Extensible Event Based Infrastructure

Genoveva Vargas-Solar and Christine Collet

IMAG-LSR, University of Grenoble, BP 72 38402 Saint-Martin d’Heres, France.{Genoveva.Vargas, Christine.Collet}@imag.fr

Abstract. This paper describes ADEES, an open and evolutionaryevent-based architecture to develop complex distributed information sys-tems. Different from most existing event supports that provide limitedevent description models and fixed management models, ADEES canbe extended and customized on a per-application basis. It is not an-other “one-size-fits-all” event manager! It is used to generate event man-agers adopted by components to produce and consume events accordingto the event description and event management models they need (e.g.event as anonymous messages, specific composite event operators, syn-chronous/asynchronous detection, push/pull protocol).The second aspect concerns the ability of a event service and event man-agers to reconfigure and adapt themselves with respect to applicationrequirements and to their environment. Adaptability and extensibility isachieved, thanks to meta-programming and reflection techniques.

1 Introduction

Large-scale distributed information systems built out of heterogeneous compo-nents, using petabytes of structured, semi-structured or non-structured dataand accessed by thousands of users are now a reality. Industrial and researchactivities are currently being carried out to develop suitable tools and relatedruntime infrastructures for supporting such systems. Middleware has emergedas an important architectural component and event-based architectures acquirea new impetus. Within such infrastructures, components cooperate by sendingand receiving events, a particular form of message that has different seman-tics when considering communication protocols [5,10], distributed systems [8],middle-ware [8,3,7], or active databases [9].

The diversity of proposals show the potential and relevance of event-basedinfrastructures. However, existing technology suffers from several drawbacks.Event-based communication such as in Java must be hard coded; no separateevent service module for managing events is provided. Middleware solutions en-courage the specification of layer based architectures where the event service isembedded within the application architecture. In both approaches event man-agement is reduced to event ordering and communication protocols. Other as-pects of event management such as event persistence and composition must beimplemented at the application level. In many cases, management policies are

R. Cicchetti et al. (Eds.): DEXA 2002, LNCS 2453, pp. 423–432, 2002.c© Springer-Verlag Berlin Heidelberg 2002

424 G. Vargas-Solar and C. Collet

implemented by different services. For example, CORBA [8] provides at leastthree services for managing event based asynchronous communication: a notifi-cation service, a message service and an event service.

Nevertheless, specific aspects of event management are to retain dependingon the approaches: pull/push communication protocols, component oriented ar-chitectures and active database event management models. Yet there are severalopen issues that need to be addressed to integrate all these aspects in a singleproposal and further to provide adaptable, extensible and plug and play eventmanagers to develop complex information systems.

This paper introduces ADEES (ADaptable and Extensible Event Service), ameta event service suitable to develop a wide range of event managers support-ing flexible cooperation and integration of distributed autonomous componentsat a middleware level. It describes how ADEES provides adaptability and ex-tensibility to event management and how to build and exploit a service and itsevent managers. It also presents some experiences in using ADEES to developOpen and Distributed Active Systems (ODAS systems) [2].

Consistently the rest of the paper is organized as follows. Section 2 presentsADEES basic concepts and architecture considering an application example. Sec-tion 3 details how adaptable event managers are specified. Section 4 describeshow an event service can be specialized and consequently the event managers itmay support. Section 5 shows how event services and managers are specified andgenerated using ADEES. It also discusses some implementation and experienceissues. Section 6 compares our proposal with other existing works. Finally, Sec-tion 7 concludes this paper and introduces some on-going and future researchdirections.

2 A Quick Tour of ADEES

Let us consider a financial system for buying and selling actions according toaccounts credit availability and the financial market evolution. The system iscomposed of four components: A Bank Server that manages accounts and thatcan be accessed for executing banking operations. A Stock Exchange Server thatcan be accessed for buying and selling actions. It notifies stock exchange informa-tion. Financial Information Servers that manage histories about current economicalindicators of companies and also indicators of specific areas. Such servers arerefreshed periodically so that they can provide reliable information. An E-Traderapplication that provides information to investors such as stock exchange marketevolution, capital state, financial transactions executed during the day. It alsoprovides interfaces for accessing the bank and the stock exchange servers.

Situations are described by events such as Telecom actions UpwardTrend(e1), the Stock exchange session opens/closes (e2), A bank account credit wasupdated (e3), A purchase operation was executed (e4). Events are produced andconsumed by the system components (bank and stock exchange servers, the E-Trader application). For instance, an E-Trader consumes events concerning actions(e.g., Telecom actions UpwardTrend) produced by the Stock Exchange Server.

ADEES: An Adaptable and Extensible Event Based Infrastructure 425

Components have different characteristics and needs with respect to eventproduction and consumption. For example, the Stock Exchange Server notifiesits events explicitly, events representing banking operations, in contrast, aredetected asynchronously. Similarly, the E-Trader consumes events representingthe financial market as soon as they are produced, while Financial InformationServers wait until the end of the stock exchange session ([17:00]) to consume suchevents.

2.1 Event Based Communication with Managers

Figure 1 illustrates event based communication using an event service and itsmanagers (built using ADEES). Two event managers EM1 and EM2 have beenspecialized for interacting with the financial application components. Both eventmanagers are under the control of an Event Service Manager (ESM). The BankServer produces events e3 that are detected asynchronously by EM1. The StockExchange Server signals events e1, e2 and e4 explicitly to EM2. Events consumedby the E-Trader and the Financial Information Servers are notified explicitly by themanagers at different instants. For example, the E-Trader receives events con-cerning the stock exchange as soon as they are produced. Events representingbanking operations arrive at the end of the day.

Event detection/notification

e5e2

e4

e4

e3

e1

e2

e3

e1

e1

e5

was authorized

define E5

Supervise an event manager

e5

Accounts

Accounts

A purchase operation2

IndexesStock exchange server

EM

Financial informationServer

Event ServiceManager

Stock exchange sources

Bank Server

2E-trader

Event Manager

Event ManagerEM 1

E-trader2

Event Service

E-trader

Fig. 1. Event based communication using an event service

Eventually a new E-Trader can connect to the system. According to the eventshe/she requires the Event Service puts him/her in contact with the correspondingevent managers. Finally, traders may decide to add a new event type E5 (apurchase has been authorized by the bank) to be notified as soon as produced.

426 G. Vargas-Solar and C. Collet

This operation is done at the ESM level that handles the new definition andnotifies it to the event manager EM2. Under the control of the ESM, EM2 has tobe reconfigured for managing events of type E5.

2.2 General Architecture of an Event Service

An event service built using ADEES is represented by an event service manager(ESM) and the event managers it monitors. Provided a schema, (i.e., an eventtype model and an event management model) the service (its ESM) generatesan event manager. This manager can be used by a set of clients to specifyinstances of the underlying schema, i.e., types of events it is supposed to produceor consume and their associated management policies.

An ESM also supervises managers execution. First it provides means to spec-ify, store and manage schemata and instances, together with deployment strate-gies for the specified event managers. Then, for each event manager specification,the ESM generates components for event detection, production and notification.It also defines listeners that will serve as proxies between the manager and sub-scribed producers (for event detection) and consumers (for event notification).According to a specific deployment strategy, the manager connects the clientwith a new listener or with an existing one.

A schema characterizes an event manager that can accept and manage differ-ent instances defined by producers and consumers that subscribe to it. Instancesdescribe event types the manager is interested in and associated managementpolicies used to manage events of those types (static adaptability). They can bethen modified and added dynamically at execution time (dynamic adaptability).

Managers of a service share the same way of describing event type and man-agement models: their schemata are described with respect to the same eventtype and event management meta-models. Schemata are instances of those meta-models and can be then modified to extend or reduce the functionalities of anevent service and its managers (extensibility).

3 Adaptable Event Managers

Events produced and consumed by an event manager have to be characterizedby event types and event management policies, respectively described using anevent type model (i.e. concepts to describe event types) and a managementmodel (i.e., concepts to describe event management policies). Both models aredefined in a schema supported by the event manager. Components that wantto share a schema subscribe themselves to the corresponding event manager asevent producers and consumers. When subscribing to an event manager, a client(a producer or a consumer) specifies an instance (i.e., an event type and itsassociated management policies) using the concepts of the models given in theunderlying schema. Each client subscribes several instances, one for each eventtype produced or consumed.

ADEES: An Adaptable and Extensible Event Based Infrastructure 427

3.1 Event Manager Schema

A schema supported by an event manager associates an event type model with anevent management model. It also includes a behavior control model that specifiespolicies for activating and deactivating event management (e.g., activate one orseveral types for one or several clients). The schema of our event manager EM1

example can be defined as: S : 〈ετ1, εµ1〉 where ετ1 is an event type model andεµ1, an event management model.

Event Type Model Gives concepts and general structures used to describe eventtypes that can be processed by a manager. For example, event types used in ourfinancial application can be described using the event type model:

ετ1 = 〈 type name: string, {〈 variable name: {real, integer, string}〉}〉As shown in the above description, the model characterizes event types as tuplesof two elements: an event type name (i.e., a string); and a content (i.e., a setof tuples describing a variable name and its associated type). Using ετ1, eventtypes Telecom Actions UpwardTrend (e1), a bank account credit has been updated(e3) are expressed as follows :

ActionsUpwardTrend, {[price: real, domain: string, pays: string]}where domain = ’Telecom’ (e1)

UpdateAccount, {[accid: string, owner: string, amount: real, date: string]} (e3)Note that where is a selection operator provided by ετ1 to express constraints onthe content of the set {[price: real, domain: string, pays: string]}.

Event Management Model An event management model describes the space ofpolicies that can be used for managing events and the interfaces exported bya manager to control its execution. It is defined as dimensions chosen from aset of predefined ones that have been identified from an event management tax-omony proposed in [11]. A dimension represents an aspect of the event manage-ment model (i.e., detection, production, notification, history management) andof management administration policies (i.e., management (de)activation, deploy-ment strategies, operations associated to dimensions). Each dimension takes itsvalue from a specific domain.

3.2 Instance

An instance comprises an event type and a management model. An Event Type isdefined as an instance of an Event Type Model. The model describes the structureof event types: the way event type names are built and the type of informationit can contain. A Management Model associates values to detection, production,notification dimensions (policies). Event management aspects appear as domainvalues. For a given producer or consumer and a given event type, the corre-sponding dimensions must have a unique value. Such a value is chosen from thedomain associated to each dimension of the corresponding schema. In this wayproducers and consumers can specify different policies to be used to manageeach of the event types they produce and/or consume.

428 G. Vargas-Solar and C. Collet

Indeed, two consumers can receive events of the same type but managedusing different policies. Furthermore, the same consumer or producer can re-ceive/produce its event types using different policies.

3.3 Adaptability

Adaptability denotes the capability of an event manager to adapt its behaviorwith respect to a set of clients. Providing a schema and the possibility to defineinstances at subscription time ensures a first level of adaptability to the eventmanager. Another level of adaptability is provided as event managers are ableto dynamically activate, deactivate and update instances (modify the event typeand values associated to dimensions of the management model).

Instance activation is done with respect to a deployment strategy imple-mented by the manager. Clients interact with the event manager through lis-teners that implement schema instances. When a schema instance is activated,listeners are chosen or generated for managing it. Choosing or reusing a lis-tener depends on the deployment strategy specified in an instance. Deploymentstrategies are out of the scope of this paper, more details can be found in [11]. In-stances deactivation is executed by the event manager that contacts the listener,either to unsubscribe the client from its list or to disconnect it. The managerdeactivates the processing of the corresponding instance.

According to the type of modification updates are immediate or differed.Management rules describing update execution policies are defined at the servicelevel and they are configured when an Event Service Manager is created [11].

4 Extensible Event Managers

As they evolve, applications can modify and increase their requirements con-cerning event management. Thus, it must be possible to specialize models im-plemented by a manager and authorize the definition of new event types, thespecification of new composition operators and new management policies. Alsoupdates on models should be enabled. Consequently, models have been consid-ered as data that must be described, materialized and managed by an eventservice. Meta-models are the core of ADEES. Due to the lack of space, we onlydescribe these models informally. A formal specification can be found in [11].

4.1 Event Type and Management Meta-models

The event type meta-model is composed of two main meta-classes (abstract datatypes): EventType and Operator. An event type describes the structure of eventnames and it can be associated to information described by a set Delta. Eachelement of the set is represented by the meta-class Delta of the form 〈varname :string, vartype : Type〉, where varname is a string and vartype denotes basicdata types (Type) such as integer, real, string, etc.

ADEES: An Adaptable and Extensible Event Based Infrastructure 429

Operator is a data type that describes the type of operators that can beassociated to an event type. It characterizes an operator as a function describedby a symbol, a domain, a codomain and an Implementation. Domain and codomainare defined as Cartesian products of basic data types (integer, real, etc.) andEventType. The implementation can be defined in a formal language (e.g., lambdacalculus) or in a specific programming language. In both cases, we suppose thatit is correct so, from the meta-model point of view, it is a black box.

An event management meta-model characterizes event management phases(i.e., detection, production, notification, history management and administra-tion) by dimensions associated to values. A value has an associated implemen-tation that specifies its semantics. Dimensions are grouped into components.Each component represents an event management phase. Meta-classes are usedto represent such elements (Metamodel, Component, Dimension). They characterizemethods for adding and deleting components from a meta-model, dimensionsfrom a component and values from a dimension (extensibility). The meta-modelcan be instantiated to define different event management models by specifyingthe components they consist of.

4.2 Extensibility

Extensibility denotes the capability of a service and its managers to extend andreduce their functionalities. It is controlled by the ESM, that can receive explicitrequests from clients or detect situations that trigger schema updates. A firstlevel of extensibility is provided by modifying statically existing schemata fordefining new managers. Meta-models ensure consistent extensibility, that is tosay, they ensure that updates on schemata are done with respect to meta-modelsdimensions.

A second level of extensibility is provided by the possibility to modify dy-namically the schema of an existing manager. Updates can be done on typeand management models that compose a schema. An event type model can bemodified by adding, deleting and updating event type and operator implemen-tations. At the manager level, updates in the schema imply the (de)activation ofinstances and the reconfiguration of their internal components (e.g., objects thatimplement new operators must be added and/or deleted). A management modelis updated by adding, modifying and deleting values associated to dimensions.Such operations imply the modification of managers internal components andlisteners, that must add, substitute or delete objects implementing those func-tionalities. According to the nature of the updates required, the execution ofthese operations can be immediate or differed to a specific check point. Updatesexecution policies are specified when the ESM is configured.

Extensibility at the event service level is materialized by meta-models up-dates. For example, it is possible to modify the structure of the EventType (e.g.,change the types associated to the Delta attributes). Also, dimensions and com-ponents can be added and deleted to the management meta-model. For exam-ple, consider a meta-model that characterizes models that do not include eventhistory management. New dimensions can be added to such a meta-model for

430 G. Vargas-Solar and C. Collet

describing the new functionality. This implies that new managers specified in theservice will manage event histories but existing managers functionalities mustbe extended too. These operations cause the modification of the ESM and itsassociated managers.

5 Building a Service and Its Managers

ADEES mainly provides a kernel for programming an event service, i.e. its EventService Manager (ESM). A programmer can configure specific parameters of anESM: (1) The generic meta-model implemented by ADEES. (2) Policies to deploygenerated managers. (3) Policies used for managing event managers.

5.1 Event Service General Architecture

The general architecture of an ESM consists of components that can be accessedby clients and managers through interfaces. Internally, an ESM is composedof three main components. (1) Instantiation: It receives a schema and its in-stances and instantiates an event manager given a schema, a set of instancesan a deployment strategy. (2) Generation: Given a schema, its instances anda deployment strategy, this component generates an event manager componentbased on rules that specify the way schema and instances are integrated withinthe event manager component. (3) Subscription: Puts in contact clients with anevent manager according to their associated schema instances and interacts withthem for executing adaption requests.

5.2 Event Manager

An event manager is built as a set of components and two interfaces to communi-cate with its ESM and to execute adaption operations. Components implementmanager functionalities. (1) Clients connection: Interaction between clients andmanagers is implemented by listeners. A connection component generates listen-ers that implement functionalities specified in schema instances. (2) Communi-cation: Listeners implement communication policies for detecting and notifyingevents. Those concerning detection are managed by detectors, and those concern-ing notification by notifiers. According to a chosen deployment strategy, one orseveral clients can be connected to the same or different detectors or notifiers. (3)Management: Event composition, ordering, history management and notificationis implemented by a management component. Each component provides an in-terface for modifying its structure when policies are activated or deactivated.(4) Execution: An execution engine monitors a manager execution and notifiesadaptability and extensibility requests to management components. It interactswith the ESM through an interface that enables connection and disconnectionof event managers.

ADEES: An Adaptable and Extensible Event Based Infrastructure 431

6 Related Work

The event-based style and related technology has received a new impetus fol-lowing the explosive development of Internet. The concept of event service hasacquired different meanings and it is often difficult to identify the applicabil-ity of every single technology and the added value with respect to well knowntechnologies.

TIB/Rendezvous [5] and USENET News system [10] are distributed infras-tructures that offer an event notification service. The event services are similarto ours in the sense that they are independent components that support applica-tions integration. However, our service compiles event processing strategies thatare spread out in these products (subscription, filtering) to offer a general eventmanagement toolkit.

Distributed event-based infrastructures are frameworks of abstract classes(or interfaces) in an object oriented language [3,8]. The event service is not anindependent component, rather it is embedded in objects code. Consequently,tuning components implies hard coding and weak re-usability possibilities. Ourapproach integrates communication protocols (pull/push) as defined by [8] butit provides an event processing layer to offer facilities (i.e., ordering, composing,storing) within a configurable environment.

Concerning interaction with clients, CORBA event service [8] and MOM [7]are channel based infrastructures similar to reliable multicast between channelsand multicast addresses. TIBCO and USENET [5,10] are subject-based servicesthat use an evolved form of channel based subscription (i.e., client addressesare determined by the subject). Clients can express interest in many subjects(channels) by specifying some form of expressions that are evaluated against thesubject of an event. Our service adopts subject based interaction using eventtypes that contain information about their conditions of production and filtersassociated to this information.

Similar to active services such as C2offein [6], and FRAMBOISE [4] our workaims at specifying a service to extend classical DBMS functionalities withoutmaking the “huge black box” grow indefinitely. Unlike to our approach, theydo not focus on an event service that interacts with “any” reactive component.Finally, as us they define adaptable services (statically) but they do not stresson strategies to provide extensibility.

7 Conclusion

The main contribution of our work is to provide ADEES an event service usedto specify, generate and execute adaptable and extensible event managers thatmay process events in different contexts – i.e., (non) transactional, centralized,distributed, etc. Rather than providing “one-fits-all” managers and services, pro-ducers and consumers can tune the required functionalities by describing themodels they need, the events they are interested in and the policies that mustbe used to detect, order, compose and notify events.

432 G. Vargas-Solar and C. Collet

The first version of ADEES has been implemented using CORBA as under-lying infrastructure for encapsulating distribution aspects but also for ensuringlow level event communication between event managers and their clients (i.e.,producers and consumers). We currently pursue the implementation of our eventservice and evaluate it with respect to performance requirements.

Concerning experiences in using ADEES, we already built Open DistributedActive Systems (ODAS) comprised of event managers and rule managers thatcan be easily deployed on the network [2]. ODAS systems have been used forour financial example. We are also currently using it to build a dynamic work-flow management system used in Web-based electronic commerce applicationsand to ensure their dynamic evolution. More generally we plan to use it to de-velop services for supporting novel programming and execution environmentsthat facilitate the structuring and cooperation of heterogeneous components [1].

References

1. C. Collet. The NODS Project: Networked Open Database Services. In Proc. ofthe 14th European Conference on Object-Oriented Programming (ECOOP 2000)-Symposium on Objects and Databases, Cannes, France, June 2000.http://www-lsr.imag.fr/Les.Groupes/storm/NODS/index.html.

2. C. Collet, G. Vargas-Solar, and H. Grazziotin-Ribeiro. Open active servicesfor data-intensive distributed applications. In Proceedings of the InternationalDatabase Engineering and Applications Symposium, IDEAS’2000, Yokahama-Japan, September 2000. IEEE.

3. Flanagan, editor. JAVA in a nutshell. O’Reilly, 1997. O’Reilly andssociates, Inc.4. H. Frithschi, S. Gatziu, and K.R. Dittrich. Framboise – an approach to construct

active database mechanisms. Technical Report 97.04, Department of ComputerScience, University of Zurich, Zurich, April 1997.

5. TIBCO Inc. Rendezvous information bus, 1996.http://www.rv.tibco.com/rvwhitepaper.html.

6. A. Koschel, R. Kramer, G. Bultzingslowen, T. Bleibel, P. Krumlinde, S. Schmuck,and C. Wein. Configuration Active Functionality for CORBA. In Proceedings ofthe ECOOP97 Workshop, Jyvaskula, Finnland, June 1997.

7. MOMA Educational Information: A Middleware Taxonomy.http://www.moma-inc.org/, 1998. White paper.

8. OMG, editor. The Common Object Request Broker Architecture and Specification.Object Management Group, 1997.

9. N. W. Paton. Active Rules for Databases. Springer Verlag, 1998.10. Internet Requests For Comments (RFC)977, February 1986.11. G. Vargas-Solar. Service d’evenements flexible pour l’integration d’applications

bases de donnees reparties. PhD thesis, Universite Joseph Fourier, Grenoble,France, december 2000.