Copyright ACM, 2000
SAC'00 Villa Olmo, Como, Italy

 

Active Services for Federated Databases

Genoveva Vargas-Solar, Christine Collet, Helena G. Ribeiro
Genoveva.Vargas@imag.fr
Christine.Collet@imag.fr
Helena.Ribeiro@imag.fr
LSR-IMAG
BP 72 38402
Saint Martin d'Heres, France
 
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 flexible event and rule services that cooperate to execute active rules. The event service specifies 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 notified by event managers. They are executed according to an adaptable execution model. Conditions and actions can concern multiple DBMS.

Key Words: 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 different underlying data models, data definition and manipulation facilities, transaction management and concurrency control mechanisms. DBMS in the federation can be integrated by a mediator providing a unified 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 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 financial 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 financial situation. Clearly, an FDBMS application would fulfill 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 specific 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 predefined actions in reaction to specific events when some conditions are satisfied.

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 specific environment defined 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, verification and validation of global integrity constraints, notification, 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 flexible 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 affect the execution of global operations. Third, the management of events stemming from different 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 definition 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 fulfill 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 full-functioning 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.
 

  
Figure 1: Active FDBMS
 The knowledge model describes how to define, represent and administrate data and rules. The FDBMS data model defines the data structure and the operations that can be executed over data. The rule data model defines the Event, Condition and Action parts of the rule. Conditions and actions are specified considering the FDBMS data model. Hence, they may implicitly concern several DBMS in the federation.

Event definition is supported by an event model. It specifies the set of event types representing the significant situations that have to be observed across and within the FDBMS (event type model); and the way such events have to be detected, composed and notified (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-definition of the federation and applications. Therefore, we first 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 notifies 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.
 

  
Figure 2: Active Services
 

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 different 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 different strategies[6]. The execution of one rule: the evaluation of the Condition part and the execution of the Action, if the Condition is satisfied. A parametric interface to specify interaction among the services of the FDBMS has been proposed in [5].

 
3. Event Service

The event service defines a framework for specifying and generating (implementing) event managers. It supports two meta models for specifying event managers (i.e., defining 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 specific 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 interval defines the interval during which events of the actual type can be recognized. Thus, events are instances of an event type that can be significant 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 defined 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 defined in a parametric way. In our example, assume that a service delivers finantial information such as the variation of the dollar price. The event the dollar price changes, E1, can be defined as follows:

(<instant> (UpdateDollar, [sv,ev]) [with delta] [where mask])).

When a rule adopts an event type it specifies 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 specified 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 defined in terms of dimensions associated to domains. Dimensions characterize different aspects of event processing phases: definition, detection, production, and notification. 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 specifies 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 different 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 notification are determined by their context of production. Considering that events can stem from different transactional contexts and that they may be even invalidated by an abort of their producing transaction, event composition and notification policies should specify how to use event instances for event composition? when to notify them?

Event notification concerns information delivery, filtering and life-span of events. Notification takes place with respect to a particular event visibility. Consumers are notified about all instances of an event type (e.g., every instance of E1) or they may impose restrictions over the notification of the instances (e.g., all instances of E1 produced in Mexico). Moreover, events can be delivered to consumers at different 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 notified 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 notification mechanism.

4. Rule Service

A rule service manages (define, update, activate, deactivate) and executes ECA active rules.

Rule Definition
Defining a rule means to describe its ECA components (ON-IF-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 defined according to the execution model. In our application example, we can define the rule Rdollar as follows:

RULE Rdollar

CONSUMPTION         consume
E_PROCESSING         instance
NET EFFECT               off
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(myaccount.clientname+@bank.fr','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-defined values [8]. This model specifies: i) when to execute a rule with respect to the notification 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 notification until the end of its validity time interval. Rules can be triggered every time their triggering event is notified or only once for a set of triggering events. Furthermore, one can specify whether the net effect must be taken into account or not, for the execution of each rule. The net effect 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 effect of update operations executed during the triggering transaction, will not be computed ( NET_EFFECT off). 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 notification 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 sufficient access over global transactions to be informed of their execution status, and influence to abort, block and restart them according to rule behavior properties.

In our example, the execution of Rdollar starts immediately after the notification 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 specified according to different 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 definition order and execution cycles.


5. Related Works

The research trend that aims to offer active functionalities as open services is recent. Basically, approaches intend to make active capabilities available for (non) database applications in distributed environments.

C2offein [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 specific 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 workflow 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 define active mechanisms to execute rules in distributed environments. Similar to us, rules can be triggered by events stemming from different sources. Event management in [10,7] resembles to ours as it supports different monitoring techniques with different qualities of communication protocols. However, none of them propose event managers that can be adapted dynamically at run-time. Different to us, in [10,9] rules are always executed as separate transactions, independent of the triggering transactions.

6. Conclusions and Future Works

The main contribution of our work is a service based architecture that provides flexible 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 offer flexible rule execution and event management adapted to different 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 definition 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 specified an FDBMS that integrates two O2 DBMS that provide XA/XOpen interfaces for a 2PC protocol. A mediator offers 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 financial analysis, cooperating systems, etc. We want to explore the execution of rules adapted to distributed and cooperative applications considering aspects such as dynamic modifications of rules and quality of service (e.g., unpredictability of clients behavior versus performance requirements, timely execution of reactions).



Bibliographie
[1]
Bützingsloewen G.; Koschel A.; Lockemann P.; Walter H.D. ECA Functionality in Distributed Environment. In N. W. Paton, editor, Active Rules in Database Systems, Monographs in Computer Science. Springer Verlag, 1998.

[2]
Chakravarty S.; Le R.; Dasari P. ECA Rule Processing in Distributed and Heterogeneous Environements. In Proceedings of the 14th. International Conference on Data Engineering, Florida-USA, February 1999. IEEE Computer Society Press.

[3]
Collet, C.;Vargas-Solar G. "Flexible and semantic event managers: toward a seamless communication between distributed database applications". Technical report, LSR-IMAG, Grenoble-France, 1999.

[4]
Collet, C.; Vargas-Solar, G.; Ribeiro, H.G. "Toward a Semantic
Event Service for Distributed Active Database Applications".
In Proceedings of the 9th International Conference on Database Expert Systems and Applications (DEXA'98), Vienna, Austria, August 24-28, 1998.

[5]
Collet, C.;Vargas-Solar G.; Ribeiro, H.G. "Active capabilities for federated database systms". Technical report, LSR-IMAG, Grenoble-France, 1999.

[6]
Coupaye T., Collet, C. "Semantics based implementation of flexible execution models for active database systems".
In Proceedings of the 14emes Journées Bases de Données Avancées (BDA'98), Hammamet, Tunisie, 26-30 octobre 1998.

[7]
Frithschi H.; Gatziu S.; Dittrich K. Framboise - an approach to construct active database mechinisms. Technical report 97.04, Departement of Computer Science, University of Zurich, April 1997.

[8]
Ribeiro, H.G.; Collet, C. "Behavior of active rules within
Multi-Database Systems". In Proceedings of the XIII Simpósio Brasileiro de Banco de Dados (SBBD'99). Florianópolis, Brésil, 11-13 octobre 1999.

[9]
Hanson E.; Khosla S. An introduction to the triggerman asynchronous trigger processor. Techinal report TR-97-007, CISE Department, University of Florida, April 1997.

[10]
Koschel A.; Kramer R.; Bützingsloewen G.; Bleibel T.; Krumlinde P.; Schmuck S.; Wein C. Configurating Active Functionality for CORBA. In Proceedings of hte ECOOP97 Workshop, Jyväskulä-Finland, June 1997.

[11]
Lamport L.; Melliar-Smith P. Synchronizing Clocks in the presence of faults. Journal of the ACM, 32(1):52-78, 1985.

[12]
Mylopoulos J.; Gal A.; Kontogiannis K.; Stanley M. A generic integration architecture for cooperative information systems. In Proceedings of hte First IFCIS Internation Conference on Cooperative Information Systems (CoopIS'96), Brussels-Belgium, June 1996. IEEE.

[13]
Paton N.W. Active Rules for Databases. Springer Verlag, 1998.

[14]
Shwiderski S. 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, Systèmes, Réseau). 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.


Footnotes

1 ordered
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].
2 transaction
The triggering transaction is the transaction within which events are produced; a triggered transaction is the one that executes a triggered rule.

Copyright 2000 ACM

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 fee.
SAC 2000 March 19-21 Como, Italy
(c) 2000 ACM 1-58113-239-5/00/003>...>$5.00