Active Services for Federated Databases Genoveva Vargas-Solar
LSR-IMAG BP 72 38402 Saint Martin d’Heres, France
Christine Collet
Helena G. Ribeiro
y
LSR-IMAG BP 72 38402 Saint Martin d’Heres, France
LSR-IMAG BP 72 38402 Saint Martin d’Heres, France
[email protected] [email protected]
[email protected]
ABSTRACT
This paper presents an architecture of a component based active mechanism suitable for federated database systems, i.e., a collection of autonomous DBMS with a common understanding of their universe of discourse. The main components of the mechanism are exible event and rule services that cooperate to execute active rules. The event service speci es and generates event managers that detect, produce and notify events using an event management model. The rule service manages Event-Condition-Action rules global to federated database systems. Rules are triggered by events noti ed by event managers. They are executed according to an adaptable execution model. Conditions and actions can concern multiple DBMS. Keywords
active databases, unbundling active capabilities, federated database systems 1. INTRODUCTION
Database management systems (DBMS) are becoming part of environments composed of large-scale distributed heterogeneous and networks of autonomous, loosely coupled components. In particular, federated database management systems (FDBMS) can be seen as networks that integrate a number of pre-existing autonomous DBMS which can be homogeneous or heterogeneous. They can use di erent underlying data models, data de nition and manipulation facilities, transaction management and concurrency control mechanisms. DBMS in the federation can be integrated by a mediator providing a uni ed view of data: a global schema, a global query language, a global catalog and a global transaction manager. The underlying transaction model considers, in general, a set of transactions synchronized by a Supported by the CONACyT of the Mexican Government and the ECOS-ANUIES program. ySupported by the CAPES of the Brazilian Government. Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. SAC ’00 Villa Olmo, Como, Italy Copyright 2000 ACM 0-89791-88-6/97/05 .. 5.00
$
global transaction. Synchronization is achieved using protocols such as the Two-Phase Commit protocol. FDBMS applications are built upon this global environment and they interact with the mediator to execute global database operations (i.e., operations that can concern various DBMS in the federation). In order to illustrate intuitively the use of FDBMS, consider a nancial context where a shareholder has two bank accounts in Mexico and in France managed by database applications. This person needs to execute banking operations either accessing the accounts independently or making applications cooperate to have a global view of his/her nancial situation. Clearly, an FDBMS application would ful ll these requirements, letting to execute transparently banking global (e.g., consult of the global credit) and local operations (e.g., withdraw 1000 pesos from the account in Mexico). Assume now that shareholders need speci c operations to be executed timely when certain conditions come up: When the dollar price changes in France, IF my account in France has more than 100000 francs THEN send an e-mail to advise me to buy dollars. When money is withdrawed from my bank accounts, IF my global credit is less than 1000 pesos THEN abort the operation.
Even if some DBMS provide some active capabilities (triggers), federated database systems are often limited when considering the encoding of the behavior of data and the reaction of the system(s) to data changes. Operations are executed after explicit request submitted by a user or an application. These systems may be referred as passive FDBMS, in opposition to active FDBMS that are able to execute automatically prede ned actions in reaction to speci c events when some conditions are satis ed. As in active DBMS [13] the major idea in active FDBMS is to add a reactive mechanism as ECA rules. Rules are processed in a speci c environment de ned as an active FDBMS application including global transactions. In such environments, possible uses of active rules are numerous, for instance, view maintenance, global schema updates, veri cation and validation of global integrity constraints, noti cation, application and component integration and cooperation, etc. The use of rules in FDBMS applications implies at least three challenges. First, the inherent heterogeneity of the system imposes the need of a exible rule execution model adaptable to the characteristics of the participating DBMS. Second, the active mechanism must deal with the autonomy of both the global system itself and the participating
DBMS. In an FDBMS, DBMS can keep their communication and execution autonomy. Thus, they may share or not control information and they may continue to control their execution at any moment, independently of the federation. They can commit or abort local transactions at any time and this can a ect the execution of global operations. Third, the management of events stemming from di erent contexts. Communication protocols are needed to observe events from their sources (DBMS) and signal them to consumers (rules). Events are messages containing information about the federation and its components. Therefore, they should be processed respecting information consistency, legacy and performance needs. For providing active capabilities within FDBMS, it is necessary to go beyond what has been proposed and developed in the context of the active databases domain [2]. This paper proposes an event service and a rule service that cooperate to execute active rules within an FDBMS. The remainder of this paper is organized as follows. Section 2 gives an overview of our approach. It discusses aspects to consider for specifying an active FDBMS and it characterizes the component based active mechanism we propose. Section 3 describes our event service and outlines the main characteristics of an event management model suited for FDBMS. Section 4 presents our rule service and gives details about rule de nition and execution aspects. Section 5 compares related works that aim at providing active capabilities. Finally, Section 6 concludes and discusses some future research directions. 2. THE SERVICES APPROACH
Active FDBMS require a federation wide mechanism for event handling and reaction execution. In such a context it must be possible to detect events to make them visible to other components of the federation. Events can be either observed or raised by each participating DBMS. It must be also possible to couple the execution of actions with the execution of FDBMS applications. From the wide variety of proposals distribution has not been widely introduced in active database environments. Furthermore, the experience of research works shows that active capabilities are potentially useful and pertinent to answer to non database applications. However, the architecture of these systems does not allow to provide active functionalities able to ful ll the requirements of every application. Therefore, we provide active capabilities as services instead of a monolithic system. Services are independent components and they are the core of an extensible mechanism. The problem is how to unbundle the mechanism so that a fullfunctioning and lean active mechanism remains? Figure 1 shows processes that have to cooperate for getting an active FDBMS, each of them based on a model. The knowledge model describes how to de ne, represent and administrate data and rules. The FDBMS data model de nes the data structure and the operations that can be executed over data. The rule data model de nes the Event, Condition and Action parts of the rule. Conditions and actions are speci ed considering the FDBMS data model. Hence, they may implicitly concern several DBMS in the federation. Event de nition is supported by an event model. It speci es the set of event types representing the signi cant situations that have to be observed across and within the FDBMS
define events & rules
detect, compose & notify events
Knowledge Model FDBMS Data Model ECA Rules
FDBMS
Event Model Event Type Model Event Management Model
execute rules
Execution Model FDBMS Transactions Rules
Figure 1: Active FDBMS (event type model); and the way such events have to be detected, composed and noti ed (event management model). An FDBMS application is executed according to the execution model of the system (e.g., global transactions). Similarly, rules are executed according to an execution model that characterizes the coupling of event consumption, condition evaluation and action execution within and across FDBMS or global transactions. Implementing the above models must not demand the complete re-de nition of the federation and applications. Therefore, we rst isolated the active mechanism from the FDBMS control. Then, we isolated the event mechanism from the rule execution one to specify two independent services. The event service detects complex situations within clients (DBMS, applications) and noti es them automatically to other clients. The rule service executes asynchronous reactions to events. The technical challenge of this approach is the amalgamation of communication, database and active aspects [1]. Figure 2 depicts the general behavior of the mechanism and the two services cooperating for rule execution. The event service administrates event managers that detect, produce and notify events. The FDBMS and application execution are monitored to detect and produce (i.e., recognize, order and compose) events described by rules. Then, events are delivered to the rule service under di erent modes and communication protocols depending rule execution models. The rule service is responsible of rule execution that consists of two phases. The planning phase that builds an execution plan according to di erent strategies[6]. The execution of one rule: the evaluation of the Condition part and the execution of the Action, if the Condition is satis ed. A parametric interface to specify interaction among the services of the FDBMS has been proposed in [5]. 3. EVENT SERVICE
The event service de nes a framework for specifying and generating (implementing) event managers. It supports two meta models for specifying event managers (i.e., de ning their event type system and their event management model).
Event type description
The Event Type Meta Model [3] provides concepts for describing primitive event types (names and contexts) that concern speci c application domains, as well as semantics of composition operators. An event type is an expression describing operations executed by a particular source, produced over a validity time interval. The validity time in-
Event Service
Rule Service
execution plan rule 1
Event Manager definition event types
Production
rule 2
events
rule 6 rule 4 rule 3 rule 5
Definition
primitive events
Notification
definition event types
one rule processing Detection events
signal events
Triggering
condition (true)
Execution
event monitoring (false)
Evaluation
Clients
global transaction for one rule
condition
t DBMS
action
t
t
DBMS
t DBMS
program
Figure 2: Active Services terval de nes the interval during which events of the actual type can be recognized. Thus, events are instances of an event type that can be signi cant for consumers (e.g., the rule service). An expression can describe primitive or composite events. In FDBMS, primitive event types represent database operations, temporal and user de ned events. Composite event types characterize events produced by applying operators such as sequence, conjunction, disjunction, negation, parallel, etc. to other events. Event types are instances of the meta model and are characterized by an instant of detection, a name, an algebraic expression, a validity time interval, a context and a mask. Types are de ned in a parametric way. In our example, assume that a service delivers nantial information such as the variation of the dollar price. The event the dollar price changes, E1 , can be de ned as follows: ( (UpdateDollar, [sv ,ev ]) [with delta] [where mask])). When a rule adopts an event type it speci es the instant of detection (before, after or duration based) and it instantiates the validity time interval, the delta and the mask. Valid values are those speci ed in the domains of the corresponding event management model. These aspects will be discussed in Section 4.
Event management
The Event Management Meta Model [4] is de ned in terms of dimensions associated to domains. Dimensions characterize di erent aspects of event processing phases: de nition, detection, production, and noti cation. A domain gives the possible values for a dimension. The event management model (i.e., an instance of the meta model that restricts domains) supported by an event manager speci es the possible protocols used to retrieve events, the methods to recognize (detect and order), compose and notify events. In that way, an event type can be managed in di erent ways by the same manager according to consumers and producers needs.
Detection and production dimensions describe the conditions in which events are detected and how they are recognized and ordered1 . They include information to determine how component events contribute to compose events and how event parameters enter into the computation of the composite event parameters. For an FDBMS, events can be produced within local or global transactions, ACID transactions; within distributed or non classical transactions; or even within non transactional applications. The validity of events (i.e., reliability of the information contained in events.) and in consequence detection, production and noti cation are determined by their context of production. Considering that events can stem from di erent transactional contexts and that they may be even invalidated by an abort of their producing transaction, event composition and noti cation policies should specify how to use event instances for event composition? when to notify them? Event noti cation concerns information delivery, ltering and life-span of events. Noti cation takes place with respect to a particular event visibility. Consumers are noti ed about all instances of an event type (e.g., every instance of E1 ) or they may impose restrictions over the noti cation of the instances (e.g., all instances of E1 produced in Mexico). Moreover, events can be delivered to consumers at di erent instants, according to the context of production of events and on consumers needs. Finally, it is necessary to establish interaction protocols depending on producers and consumers characteristics. Events are detected and noti ed under pull and push communication protocols. Both operations can be executed with an (a)synchronous mode. The synchronous (asynchronous) mode implies that producer (consumer) executions are (not) interrupted by the detection or the noti cation mechanism. 1 Events are ordered according to an instant of production that belongs to a global time that can be computed using methods as those proposed in [14; 11].
4. RULE SERVICE
A rule service manages (de ne, update, activate, deactivate) and executes ECA active rules.
Rule De nition
De ning a rule means to describe its ECA components (ONIF-DO) and its behavior properties. Events describe FDBMS operations or external operations. Conditions are generally predicates on database states expressed with a query language. Actions are sequences of operations that can concern multiple DBMS, applications, the operating systems and services. The behavior properties of the rule depend on application needs and they are de ned according to the execution model. In our application example, we can de ne the rule Rdollar as follows: RULE Rdollar CONSUMPTION consume E PROCESSING instance NET EFFECT o COUPLING immediate, independent, separate ON after (UpdateDollar, [9:00, 17:00]) with delta(price: real, country: string) where country = 'France' IF select myaccount from myaccount in Accounts where myaccount.country = "France" and myaccount.credit > 100000 DO system(mail(
[email protected]','Buy dollars'));
The rule is triggered by events of type UpdateDollar that represent the dollar price in France produced after an update that occurred at an instant in [9:00, 17:00]. If the credit of the account myaccount in France is higher than 100000 dollars { which is tested by the Condition part of the rule { a mail is automatically sent to advise the owner to buy dollars. Here we assume that when evaluated, the query in the Condition will be rewritten according to the global catalog. The following presents behavior properties determined by the execution model.
Rule Execution
The core of the rule service is a parametric execution model based on a set of parameters and pre-de ned values [8]. This model speci es: i) when to execute a rule with respect to the noti cation of events and how to synchronize its execution with applications and FDBMS execution; ii) how to order possibly inter-related rules triggered at the \same" time. Events are particularly important for rule execution, since they trigger rules. Event consumption policies specify how to handle an event that has triggered a rule. Events are considered for rule execution during their validity time interval. An event can be taken into account either for one execution of the rule or for several executions after its noti cation until the end of its validity time interval. Rules can be triggered every time their triggering event is noti ed or only once for a set of triggering events. Furthermore, one can specify whether the net e ect must be taken into account or not, for the execution of each rule. The net e ect is the result of the execution of a sequence of operations on the same data (or object). In the previous example, Rdollar is triggered by events of type UpdateDollar. Each event instance is considered for only one execution (CONSUMPTION consume). The rule is executed for each update of the dollar price in France (E PROCESSING instance-oriented). The net e ect of update operations executed during the triggering transaction, will not be computed (NET EFFECT o ).
As said before, rule execution has to be coupled with the underlying transaction model of the FDBMS. Rule execution can start either immediately after the noti cation of its triggering event or it can be deferred, for example to the end of the global triggering transaction2 . A rule is executed either as a new transaction that belongs to the same global triggering transaction or as a separate global transaction. In addition, the global transaction in which a rule is executed can be or not dependent from the global triggering transaction. Clearly, coupling aspects imply that the rule service has both sucient access over global transactions to be informed of their execution status, and in uence to abort, block and restart them according to rule behavior properties. In our example, the execution of Rdollar starts immediately after the noti cation of events. The rule is executed as a separate independent global transaction (COUPLING immediate, independent, separate). Finally, several rules can be triggered by the same event. When this situation comes up, one has to determine when and how these rules have to be executed. This is done by building an execution plan based on execution strategies speci ed according to di erent criteria [5]. In general, criteria combine sequential and parallel execution based upon rule dependencies. Sequential execution is achieved using rule ordering strategies that consider rule priorities, triggering and de nition order and execution cycles. 5. RELATED WORKS
The research trend that aims to o er active functionalities as open services is recent. Basically, approaches intend to make active capabilities available for (non) database applications in distributed environments. C2 o ein [10] proposes separately usable components for distributed systems supported by CORBA. The system consists of parametric wrappers enabling event processing and a rule engine whose characteristics are tailored to speci c applications. FRAMBOISE [7] proposes a construction system of ECA-services decoupled from a particular DBMS. Event detection is performed by event detectors which have to be specialized for the respective DBMS. A rule service is responsible for the maintenance of the rule base and implements rule execution. CoopWARE [12] and TriggerMan [9] also propose execution mechanisms for distributed rules. The former has been developed for a work ow environment, and the latter proposes an asynchronous trigger processor as an extension module for an object-relational DBMS. [2] propose an architecture of a framework to support ECA rules suitable for distributed and heterogeneous systems. In general, these works resemble insofar to ours as they de ne active mechanisms to execute rules in distributed environments. Similar to us, rules can be triggered by events stemming from di erent sources. Event management in [10; 7] resembles to ours as it supports di erent monitoring techniques with di erent qualities of communication protocols. However, none of them propose event managers that can be adapted dynamically at run-time. Di erent to us, in [10; 9] rules are always executed as separate transactions, independent of the triggering transactions.
2 The triggering transactionis the transactionwithin which events are produced; a triggered transaction is the one that executes a triggered rule.
6. CONCLUSIONS AND FUTURE WORKS
The main contribution of our work is a service based architecture that provides exible and independent active capabilities suitable for FDBMS applications. A rule and an event services are proposed to cooperate to specify and execute ECA rules. They respectively o er exible rule execution and event management adapted to di erent participating DBMS characteristics. The implementation of the services is underway. We have chosen an object oriented environment (CORBA) to unify the services between each other. In particular we use (i) CORBA interface de nition language (IDL) to specify interfaces between event managers, event producers and the rule service (ii) CORBA Event Service as a \low level" communication infrastructure for event managers. We have speci ed an FDBMS that integrates two O2 DBMS that provide XA/XOpen interfaces for a 2PC protocol. A mediator o ers a global view of the FDBMS and implements a 2PC protocol to execute global transactions. The rule service interacts with the mediator to execute rules (i.e., evaluate conditions and execute actions). Further research directions include making active capabilities available to other applications such as electronic commerce, real-time nancial analysis, cooperating systems, etc. We want to explore the execution of rules adapted to distributed and cooperative applications considering aspects such as dynamic modi cations of rules and quality of service (e.g., unpredictability of clients behavior versus performance requirements, timely execution of reactions). 7. REFERENCES
[1] G. Butzingsloewen, A. Koschel, P. Lockemann, and H.D. Walter. ECA Functionality in a Distributed Environment. In N. W. Paton, editor, Active Rules in Database Systems, Monographs in Computer Science. Springer Verlag, 1998. [2] S. Chakravarthy, R. Le, and R. Dasari. ECA Rule Processing in Distributed and Heterogeneous Environments. In Proceedings of the Fourteenth International Conference on Data Engineering, Florida, USA, February 1998. IEEE Computer Society Press. [3] C. Collet and G. Vargas-Solar. Flexible and semantic event managers: toward a seamless communication between distributed database applications. Technical report, LSR-IMAG, Grenoble-France, 1999. [4] C. Collet, G. Vargas-Solar, and H. Grazziotin-Ribeiro. Toward a semantic event service for database applications. In Proceedings of the 9th. International Conference, DEXA98. Lecture Notes in Computer Science Springer-Verlag, Viena-Austria, august 1998. [5] C. Collet, G. Vargas-Solar, and H. Grazziotin-Ribeiro. Active capabilities for federated database systems. Technical report, LSR-IMAG, Grenoble-France, 1999. [6] T. Coupaye and C. Collet. Semantics based implementation of exible execution models for active database systems. In les actes des 14iemes Journees Bases de Donnees Avancees, Hammamet- Tunisie, october 1998.
[7] H. Frithschi, S. Gatziu, and K. Dittrich. Framboise { an approach to construct active database mechanisms. Technical Report 97.04, Department of Computer Science, University of Zurich, Zurich, April 1997. [8] H. Grazziotin-Ribeiro and C. Collet. Behavior of active rules within multi-database systems. In Proceedings of the XIV Symposium on Databases, Florianopolis-Brazil, october 1999. [9] E. Hanson and S. Khosla. An introduction to the triggerman asynchronous trigger processor. Technical Report TR-97-007, CISE Department, University of Florida, United States, April 1997. [10] A. Koschel, R. Kramer, G. Bultzingslowen, T. Bleibel, P. Krumlinde, S. Schmuck, and C. Wein. Con guration Active Functionality for CORBA. In Proceedings of the ECOOP97 Workshop, Jyvaskula, Finnland, June 1997. [11] L. L. and P. Melliar-Smith. Synchronizing Clocks in the Presence of Faults. Journal of the ACM, 32(1):52{78, 1985. [12] J. Mylopoulos, A. Gal, K. Kontogiannis, and M. Stanley. A generic integration architecture for cooperative information systems. In Proceedings of the 1st IFCIS International Conference on Cooperative Information Systems (CoopIS'96), pages 208{217, Brussels, Belgium, June 1996. IEEE. [13] N. W. Paton. Active Rules for Databases. Springer Verlag, 1998. [14] S. Schwiderski. Monitoring the behavior of Distributed Systems. PhD thesis, University of Cambridge, April 1996. Biographical Information
Christine Collet is Professor at the INPG (National Politechnical Institute of Grenoble) in France. She is leader of the Database Group and responsible of the NODS project (Networked Open Database Services) at the laboratory LSR (Logiciels, Systemes, Reseau). Genoveva Vargas-Solar, and Helena Grazziotin-Ribeiro, assistant professor at the Universidade de Caxias do Sul- Brazil, are currently Ph.D students at the University Joseph Fourier in Grenoble. Their research interests are active and distributed databases, distributed and cooperative systems, database services for internet applications (i.e., data and application servers) and data-warehouses.
