ADEES: An Adaptable and Extensible Event Based Infrastructure

ADEES: An Adaptable and Extensible Event Based Infrastructure Genoveva Vargas-Solar and Christine Collet IMAG-LSR, University of Grenoble, BP 72 38402 Saint-Martin d’H`eres, France. {Genoveva.Vargas, Christine.Collet}@imag.fr

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

1

Introduction

Large-scale distributed information systems built out of heterogeneous components, using petabytes of structured, semi-structured or non-structured data and accessed by thousands of users are now a reality. Industrial and research activities are currently being carried out to develop suitable tools and related runtime infrastructures for supporting such systems. Middleware has emerged as an important architectural component and event-based architectures acquire a new impetus. Within such infrastructures, components cooperate by sending and receiving events, a particular form of message that has different semantics 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-based infrastructures. However, existing technology suffers from several drawbacks. Event-based communication such as in Java must be hard coded; no separate event service module for managing events is provided. Middleware solutions encourage the specification of layer based architectures where the event service is embedded within the application architecture. In both approaches event management is reduced to event ordering and communication protocols. Other aspects of event management such as event persistence and composition must be implemented 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 least three services for managing event based asynchronous communication: a notification service, a message service and an event service. Nevertheless, specific aspects of event management are to retain depending on the approaches: pull/push communication protocols, component oriented architectures and active database event management models. Yet there are several open issues that need to be addressed to integrate all these aspects in a single proposal and further to provide adaptable, extensible and plug and play event managers to develop complex information systems. This paper introduces ADEES (ADaptable and Extensible Event Service), a meta event service suitable to develop a wide range of event managers supporting flexible cooperation and integration of distributed autonomous components at a middleware level. It describes how ADEES provides adaptability and extensibility to event management and how to build and exploit a service and its event managers. It also presents some experiences in using ADEES to develop Open and Distributed Active Systems (ODAS systems) [2]. Consistently the rest of the paper is organized as follows. Section 2 presents ADEES basic concepts and architecture considering an application example. Section 3 details how adaptable event managers are specified. Section 4 describes how an event service can be specialized and consequently the event managers it may support. Section 5 shows how event services and managers are specified and generated using ADEES. It also discusses some implementation and experience issues. Section 6 compares our proposal with other existing works. Finally, Section 7 concludes this paper and introduces some on-going and future research directions.

2

A Quick Tour of ADEES

Let us consider a financial system for buying and selling actions according to accounts credit availability and the financial market evolution. The system is composed of four components: A Bank Server that manages accounts and that can be accessed for executing banking operations. A Stock Exchange Server that can be accessed for buying and selling actions. It notifies stock exchange information. Financial Information Servers that manage histories about current economical indicators of companies and also indicators of specific areas. Such servers are refreshed periodically so that they can provide reliable information. An E-Trader application that provides information to investors such as stock exchange market evolution, capital state, financial transactions executed during the day. It also provides 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 was updated (e3 ), A purchase operation was executed (e4 ). Events are produced and consumed by the system components (bank and stock exchange servers, the ETrader 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 event production and consumption. For example, the Stock Exchange Server notifies its events explicitly, events representing banking operations, in contrast, are detected asynchronously. Similarly, the E-Trader consumes events representing the financial market as soon as they are produced, while Financial Information Servers wait until the end of the stock exchange session ([17:00]) to consume such events. 2.1

Event Based Communication with Managers

Figure 1 illustrates event based communication using an event service and its managers (built using ADEES). Two event managers EM1 and EM2 have been specialized for interacting with the financial application components. Both event managers are under the control of an Event Service Manager (ESM). The Bank Server produces events e3 that are detected asynchronously by EM1 . The Stock Exchange Server signals events e1 , e2 and e4 explicitly to EM2 . Events consumed by the E-Trader and the Financial Information Servers are notified explicitly by the managers at different instants. For example, the E-Trader receives events concerning the stock exchange as soon as they are produced. Events representing banking operations arrive at the end of the day.

Stock exchange sources

Financial information Server Indexes

e1

Stock exchange server e2 e4

e1

E-trader

2

Event Service Manager

define E5 A purchase operation was authorized

Event Manager EM 1 Event Service

E-trader

e5

Event Manager EM 2

e4

e1

e5

e2

e3

e5 Accounts

2

E-trader

e3

Accounts Supervise an event manager

Bank Server

Event detection/notification

Fig. 1. Event based communication using an event service

Eventually a new E-Trader can connect to the system. According to the events he/she requires the Event Service puts him/her in contact with the corresponding event managers. Finally, traders may decide to add a new event type E5 (a purchase 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 and notifies it to the event manager EM2 . Under the control of the ESM, EM2 has to be 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 event type model and an event management model) the service (its ESM) generates an event manager. This manager can be used by a set of clients to specify instances of the underlying schema, i.e., types of events it is supposed to produce or consume and their associated management policies. An ESM also supervises managers execution. First it provides means to specify, store and manage schemata and instances, together with deployment strategies 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 subscribed producers (for event detection) and consumers (for event notification). According to a specific deployment strategy, the manager connects the client with a new listener or with an existing one. A schema characterizes an event manager that can accept and manage different instances defined by producers and consumers that subscribe to it. Instances describe event types the manager is interested in and associated management policies used to manage events of those types (static adaptability). They can be then modified and added dynamically at execution time (dynamic adaptability). Managers of a service share the same way of describing event type and management models: their schemata are described with respect to the same event type and event management meta-models. Schemata are instances of those metamodels and can be then modified to extend or reduce the functionalities of an event service and its managers (extensibility).

3

Adaptable Event Managers

Events produced and consumed by an event manager have to be characterized by event types and event management policies, respectively described using an event type model (i.e. concepts to describe event types) and a management model (i.e., concepts to describe event management policies). Both models are defined in a schema supported by the event manager. Components that want to share a schema subscribe themselves to the corresponding event manager as event 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 its associated management policies) using the concepts of the models given in the underlying schema. Each client subscribes several instances, one for each event type produced or consumed.

ADEES: An Adaptable and Extensible Event Based Infrastructure

3.1

427

Event Manager Schema

A schema supported by an event manager associates an event type model with an event management model. It also includes a behavior control model that specifies policies for activating and deactivating event management (e.g., activate one or several 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 event types that can be processed by a manager. For example, event types used in our financial 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 tuples of two elements: an event type name (i.e., a string); and a content (i.e., a set of tuples describing a variable name and its associated type). Using ετ1 , event types 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 on the content of the set {[price: real, domain: string, pays: string]}.

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

Instance

An instance comprises an event type and a management model. An Event Type is defined as an instance of an Event Type Model. The model describes the structure of event types: the way event type names are built and the type of information it can contain. A Management Model associates values to detection, production, notification dimensions (policies). Event management aspects appear as domain values. For a given producer or consumer and a given event type, the corresponding dimensions must have a unique value. Such a value is chosen from the domain associated to each dimension of the corresponding schema. In this way producers and consumers can specify different policies to be used to manage each 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 managed using different policies. Furthermore, the same consumer or producer can receive/produce its event types using different policies. 3.3

Adaptability

Adaptability denotes the capability of an event manager to adapt its behavior with respect to a set of clients. Providing a schema and the possibility to define instances at subscription time ensures a first level of adaptability to the event manager. Another level of adaptability is provided as event managers are able to dynamically activate, deactivate and update instances (modify the event type and values associated to dimensions of the management model). Instance activation is done with respect to a deployment strategy implemented by the manager. Clients interact with the event manager through listeners that implement schema instances. When a schema instance is activated, listeners are chosen or generated for managing it. Choosing or reusing a listener depends on the deployment strategy specified in an instance. Deployment strategies are out of the scope of this paper, more details can be found in [11]. Instances deactivation is executed by the event manager that contacts the listener, either to unsubscribe the client from its list or to disconnect it. The manager deactivates 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 service level 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 concerning event management. Thus, it must be possible to specialize models implemented by a manager and authorize the definition of new event types, the specification of new composition operators and new management policies. Also updates on models should be enabled. Consequently, models have been considered as data that must be described, materialized and managed by an event service. Meta-models are the core of ADEES. Due to the lack of space, we only describe 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 data types): EventType and Operator. An event type describes the structure of event names and it can be associated to information described by a set Delta. Each element of the set is represented by the meta-class Delta of the form varname : string, vartype : T ype, where varname is a string and vartype denotes basic data types (T ype) 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 be associated to an event type. It characterizes an operator as a function described by a symbol, a domain, a codomain and an Implementation. Domain and codomain are defined as Cartesian products of basic data types (integer, real, etc.) and EventType. The implementation can be defined in a formal language (e.g., lambda calculus) or in a specific programming language. In both cases, we suppose that it 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 administration) by dimensions associated to values. A value has an associated implementation that specifies its semantics. Dimensions are grouped into components. Each component represents an event management phase. Meta-classes are used to represent such elements (Metamodel, Component, Dimension). They characterize methods for adding and deleting components from a meta-model, dimensions from a component and values from a dimension (extensibility). The meta-model can be instantiated to define different event management models by specifying the components they consist of.

4.2

Extensibility

Extensibility denotes the capability of a service and its managers to extend and reduce their functionalities. It is controlled by the ESM, that can receive explicit requests from clients or detect situations that trigger schema updates. A first level of extensibility is provided by modifying statically existing schemata for defining new managers. Meta-models ensure consistent extensibility, that is to say, they ensure that updates on schemata are done with respect to meta-models dimensions. A second level of extensibility is provided by the possibility to modify dynamically the schema of an existing manager. Updates can be done on type and management models that compose a schema. An event type model can be modified by adding, deleting and updating event type and operator implementations. At the manager level, updates in the schema imply the (de)activation of instances and the reconfiguration of their internal components (e.g., objects that implement new operators must be added and/or deleted). A management model is updated by adding, modifying and deleting values associated to dimensions. Such operations imply the modification of managers internal components and listeners, that must add, substitute or delete objects implementing those functionalities. According to the nature of the updates required, the execution of these operations can be immediate or differed to a specific check point. Updates execution policies are specified when the ESM is configured. Extensibility at the event service level is materialized by meta-models updates. 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 components can be added and deleted to the management meta-model. For example, consider a meta-model that characterizes models that do not include event history 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 the service will manage event histories but existing managers functionalities must be extended too. These operations cause the modification of the ESM and its associated managers.

5

Building a Service and Its Managers

ADEES mainly provides a kernel for programming an event service, i.e. its Event Service Manager (ESM). A programmer can configure specific parameters of an ESM: (1) The generic meta-model implemented by ADEES. (2) Policies to deploy generated 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 accessed by clients and managers through interfaces. Internally, an ESM is composed of three main components. (1) Instantiation: It receives a schema and its instances and instantiates an event manager given a schema, a set of instances an a deployment strategy. (2) Generation: Given a schema, its instances and a deployment strategy, this component generates an event manager component based on rules that specify the way schema and instances are integrated within the event manager component. (3) Subscription: Puts in contact clients with an event manager according to their associated schema instances and interacts with them for executing adaption requests. 5.2

Event Manager

An event manager is built as a set of components and two interfaces to communicate with its ESM and to execute adaption operations. Components implement manager functionalities. (1) Clients connection: Interaction between clients and managers is implemented by listeners. A connection component generates listeners that implement functionalities specified in schema instances. (2) Communication: Listeners implement communication policies for detecting and notifying events. Those concerning detection are managed by detectors, and those concerning notification by notifiers. According to a chosen deployment strategy, one or several clients can be connected to the same or different detectors or notifiers. (3) Management: Event composition, ordering, history management and notification is implemented by a management component. Each component provides an interface for modifying its structure when policies are activated or deactivated. (4) Execution: An execution engine monitors a manager execution and notifies adaptability and extensibility requests to management components. It interacts with the ESM through an interface that enables connection and disconnection of event managers.

ADEES: An Adaptable and Extensible Event Based Infrastructure

6

431

Related Work

The event-based style and related technology has received a new impetus following the explosive development of Internet. The concept of event service has acquired different meanings and it is often difficult to identify the applicability of every single technology and the added value with respect to well known technologies. TIB/Rendezvous [5] and USENET News system [10] are distributed infrastructures that offer an event notification service. The event services are similar to ours in the sense that they are independent components that support applications integration. However, our service compiles event processing strategies that are spread out in these products (subscription, filtering) to offer a general event management toolkit. Distributed event-based infrastructures are frameworks of abstract classes (or interfaces) in an object oriented language [3,8]. The event service is not an independent component, rather it is embedded in objects code. Consequently, tuning components implies hard coding and weak re-usability possibilities. Our approach integrates communication protocols (pull/push) as defined by [8] but it 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 channels and multicast addresses. TIBCO and USENET [5,10] are subject-based services that use an evolved form of channel based subscription (i.e., client addresses are determined by the subject). Clients can express interest in many subjects (channels) by specifying some form of expressions that are evaluated against the subject of an event. Our service adopts subject based interaction using event types that contain information about their conditions of production and filters associated to this information. Similar to active services such as C2 offein [6], and FRAMBOISE [4] our work aims at specifying a service to extend classical DBMS functionalities without making the “huge black box” grow indefinitely. Unlike to our approach, they do not focus on an event service that interacts with “any” reactive component. Finally, as us they define adaptable services (statically) but they do not stress on strategies to provide extensibility.

7

Conclusion

The main contribution of our work is to provide ADEES an event service used to specify, generate and execute adaptable and extensible event managers that may process events in different contexts – i.e., (non) transactional, centralized, distributed, etc. Rather than providing “one-fits-all” managers and services, producers and consumers can tune the required functionalities by describing the models they need, the events they are interested in and the policies that must be 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 underlying infrastructure for encapsulating distribution aspects but also for ensuring low level event communication between event managers and their clients (i.e., producers and consumers). We currently pursue the implementation of our event service and evaluate it with respect to performance requirements. Concerning experiences in using ADEES, we already built Open Distributed Active Systems (ODAS) comprised of event managers and rule managers that can be easily deployed on the network [2]. ODAS systems have been used for our financial example. We are also currently using it to build a dynamic workflow management system used in Web-based electronic commerce applications and to ensure their dynamic evolution. More generally we plan to use it to develop services for supporting novel programming and execution environments that facilitate the structuring and cooperation of heterogeneous components [1].

References 1. C. Collet. The NODS Project: Networked Open Database Services. In Proc. of the 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 services for data-intensive distributed applications. In Proceedings of the International Database Engineering and Applications Symposium, IDEAS’2000, YokahamaJapan, 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 Computer Science, 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. B¨ ultzingsl¨ owen, T. Bleibel, P. Krumlinde, S. Schmuck, and C. Wein. Configuration Active Functionality for CORBA. In Proceedings of the ECOOP97 Workshop, Jyv¨ askul¨ a, 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’´ev´enements flexible pour l’int´egration d’applications bases de donn´ees r´eparties. PhD thesis, Universit´e Joseph Fourier, Grenoble, France, december 2000.