Rivero L.Encyclopedia of database technologies and applications.2006

INTRODUCTION

As it is well known, business requirements are changing faster than applications can be created and/or modified. Most of these requirements are in the form of or are related to business rules. Business rules are precise statements that describe, constrain and control the structure, operations and strategy of a business. They may be thought of as small pieces of knowledge about a business domain. They offer a way of encapsulating business semantics and making them explicit in the same way that databases enable the separation of data from application programs.

Traditionally, business rules have been scattered, hard-coded and replicated by different applications. The lack of a formal approach to the management of business rules and a standard business rule language has made it virtually impossible to create, modify and manage business rules in a flexible way. As a result, it has been difficult to adapt applications to new requirements quickly.

Isolating the business rules from the application code enables developers to easily find and modify the pertinent rule(s) when a policy change is needed or when application requirements change. This makes it possible to quickly change rules without modifying the rest of the application code, thereby enhancing maintainability.

In the last decade, one of the trends in database technology has focused on extending conventional database systems (DBMSs) to enhance their functionality and to accommodate more advanced applications. One of these enhancements was extending database systems with powerful rule-processing capabilities. These capabilities can be divided into two classes: deductive, in which logic-programming-style rules are used to provide a more powerful user interface than that provided by most database query languages (Ceri, Gottlob, & Tanca, 1990), and active, where production-style rules are used to provide automatic execution of predefined operations in response to the occurrence of certain events (Act-Net Consortium, 1996; Dayal , Buchmann & McCarthy, 1988). The latter is particularly appropriate for enforcing business rules as it has been demonstrated in Ceri and Widom (1996) and Paton (1999). Database systems enhanced with active capabilities are known as active databases systems, or aDBMSs for short.

By means of active database systems, general integrity constraints encoded in applications have been moved

into the database system in the form of rules. These rules go beyond key or referential integrity constraints. Active databases support the specification and monitoring of general constraints (rules), they provide flexibility with respect to the time of constraint checking, and they provide execution of compensating actions to rectify a constraint violation without rolling back the involved transaction. Additionally, support for external events and actions were introduced mostly to satisfy the requirements of monitoring applications.

As a consequence, applications sharing the same database system and data model can also share business rules. In this way, the business knowledge that was dispersed in many applications in the form of programming code is now represented in the form of rules and managed in a centralized way. Consequently, when business rules change, only those affected rules must be modified in the aDBMS.

BACKGROUND

Historically, production rules were used first to provide automatic reaction functionality. Production rules are Condition-Action rules that do not break out the triggering event explicitly. Instead, they implement a pollingstyle evaluation of all conditions. In contrast, Event- Condition-Action (ECA) rules explicitly define triggering events, and conditions are evaluated only if the triggering event was signaled. Active databases adopted this eventdriven approach to avoid unnecessary and resourceintensive polling in monitoring database changes and applications.

In active relational databases, events were modeled as changes of the state of the database, i.e., insert, delete and update operations on tables (Hanson, 1989; Stonebraker, Jhingran, Goh, & Potamianos, 1990). This basic functionality is common fare in commercial DBMSs today. In object-oriented systems, more general primitive events were defined: temporal events, both absolute and relative; method invocation events; and user-defined events (Dayal & Blaustein, 1988; Gatziu & Dittrich, 1993; Zimmermann & Buchmann, 1999).

In addition to these primitive events, more complex situations that correlate, aggregate or combine events can be defined. This is done by using an event algebra

(Zimmer & Unland, 1999) that allows the definition of socalled composite or complex events.

By means of a rule definition language (RDL), ECA rules are specified. This language provides constructors for the definition of rules, events, conditions and actions. Once rules are specified with an RDL, the rule base should be checked according to the following properties: termination, confluence and observably deterministic behavior (Aiken, Widom, & Hellerstein, 1992). For instance, termination analysis ensures that the current rule base is safe and correct with respect to the intended reactive behavior. In general, these properties cannot be proven automatically, but an analyzer might assist in detecting inconsistencies. After this verification step, rules are ready to be processed.

ECA RULE PROCESSING

Rule execution semantics prescribe how an active system behaves once a set of rules has been defined. Rule execution behavior can be quite complex, but we restrict ourselves to describing only essential aspects here. For a more detailed description, see Act-Net Consortium (1996) and Widom and Ceri (1996).

All begins with event instances signaled by event sources that feed the complex event detector, which selects and consumes these events. Consumption modes (Chakravarthy, Krishnaprasad, Anwar, & Kim, 1994) determine which of these event instances are considered for firing rules. The two most common modes are recent and chronicle. In the former, the most recent event occurrences are used, while in the latter, the oldest event occurrences are consumed. Notice that in both cases a temporal order of event occurrences is required. Different consumption modes may be required by different application classes.

Usually there are specific points in time at which rules may be processed during the execution of an active system. The rule processing granularity specifies how often these points occur. For example, the finest granularity is “always,” which means that rules are processed as soon as any rule’s triggering event occurs. If we consider the database context, rules may be processed after the occurrence of database operations (small), data manipulation statements (medium), or transactions (coarse).

At granularity cycles and only if rules were triggered, the rule processing algorithm is invoked. If more than one rule was triggered, it may be necessary to select one after the other from this set. This process of rule selection is known as conflict resolution, where basically three strategies can be applied: (a) one rule is selected from the fireable pool, and after rule execution, the set is deter-

Active Database Management Systems

mined again; (b) sequential execution of all rules in an evaluation cycle; and (c) parallel execution of all rules in an evaluation cycle.

After rules are selected, their corresponding conditions are evaluated. Notice that conditions can be expressed as predicates on database states using a query language, and also external method invocations can be used. The specification of conditions can involve variables that will be bound at runtime with the content of triggering events. If a condition evaluates to true, then the action associated with this rule must be executed. Actions can be any sequence of operations on or outside of a database. These operations can include attributes of the triggering event.

For some applications it may be useful to delay the evaluation of a triggered rule’s condition or the execution of its action until the end of the transaction, or it may be useful to evaluate a triggered rule’s condition or execute its action in a separate transaction. These possibilities lead to the notion of coupling modes. One coupling mode can specify the transactional relationship between a rule’s triggering event and the evaluation of its condition while another coupling mode can specify the transactional relationship between a rule’s condition evaluation and the execution of its action. The originally proposed coupling modes are immediate, deferred and decoupled (Dayal & Blaustein, 1988).

To sum up, an ECA-rule-processing mechanism can be formulated as a sequence of four steps (as illustrated in Figure 1):

1.Complex event detection: It selects instances of signaled events in order to detect specified situations of interest where various event occurrences may be involved. As a result, these picked instances are bound together and signaled as a (single) complex event.

2.Rule selection: According to the triggering events, fireable rules are selected. If the selection is multiple, a conflict resolution policy must be applied.

3.Condition evaluation: Selected rules receive the triggering event as a parameter, thus allowing the condition evaluation code to access event content. Transaction dependencies between event detection and the evaluation of a rule’s condition are specified using Event-Condition coupling modes.

4.Action execution: If the rule’s condition evaluates to true, the corresponding action is executed taking the triggering event as a parameter. Condi- tion-action dependencies are specified similarly to Step 3.

It should be noticed that Step 1 (complex event detection) can be skipped if rules involve primitive events only.

TOOLS

Several tools are required in order to adequately support the active functionality paradigm (Act-Net Consortium, 1996). For instance, a rule browser makes possible the inspection of the rule base; a rule design assistance supports the process of creation of new rules and is complemented with a rule analyzer that checks for a consistent rule base; and a rule debugger monitors the execution of rules.

FUTURE TRENDS

Modern large-scale applications, such as e-commerce, enterprise application integration (EAI), Internet or intranet applications, and pervasive and ubiquitous computing, can benefit from this technology, but they impose new requirements. In these applications, integration of different subsystems, collaboration with partners’ applications or interaction with sensor devices is of particular interest.

It must be noticed that in this context, events and data are coming from diverse sources, and the execution of actions and evaluation of conditions may be performed on different systems. Furthermore, events, conditions and actions may not be necessarily directly related to database operations. This leads to the question of why a full-fledged database system is required when only active functionality and some services of a DBMS are needed.

The current trend in the application space is moving away from tightly coupled systems and towards systems of loosely coupled, dynamically bound components. In such a context, it seems reasonable to move required active functionality out of the active database system by offering a flexible service that runs decoupled from the database. It

can be combined in many different ways and used in a variety of environments. For this, a component-based architecture seems to be appropriate (Collet, VargasSolar, & Grazziotin-Ribeiro, 1998; Gatziu, Koschel, von Buetzingsloewen, & Fritschi, 1998;), in which an active functionality service can be seen as a combination of other components, like complex event detection, condition evaluation and action execution. Thus, components can be combined and configured according to the required functionality, as proposed by the unbundling approach in the context of aDBMSs (Gatziu et al.) or by using a service-oriented architecture (SOA) as described in Cilia, Bornhövd, and Buchmann (2001).

CONCLUSION

Active databases support the specification of business rules in the form of ECA rules. The business knowledge that was dispersed in many applications in the form of programming code is now represented in the form of rules and managed in a separated way. This facilitates the adaptation to new requirements and improves the maintainability of systems.

As mentioned above, the current trend of active functionality technology shows a shift towards loosely coupled and distributed systems and the availability of such functionality as a service.

REFERENCES

Act-Net Consortium. (1996). The active database management system manifesto: A rulebase of ADBMS features. ACM SIGMOD Record, 25(3), 40-49.

Aiken, A., Widom, J., & Hellerstein, J. (1992). Behavior of database production rules: Termination, confluence, and observable determinism. Proceedings of ACM International Conference on Management of Data (SIGMOD),

59-68.

Ceri, S., Gottlob, G., & Tanca, L. (1990). Logic programming and databases. Springer.

Ceri, S., & Widom, J. (1996). Applications of active databases. In J. Widom & S. Ceri (Eds.), Active database systems (pp. 259-291). Springer.

Chakravarthy, S., Krishnaprasad, V., Anwar, E., & Kim, S. (1994). Composite events for active databases: Semantics, contexts and detection. Proceedings of the International Conference on Very Large Databases (VLDB) (pp. 606-617).

Cilia, M., Bornhövd, C., & Buchmann, A. (2001). Moving active functionality from centralized to open distributed heterogeneous environments. In Lecture notes in computer science: Vol. 2172. Proceedings of the International Conference on Cooperative Information Systems, CoopIS (pp. 195-210).

Collet,C.,Vargas-Solar,C.,&Grazziotin-Ribeiro,H.(1998). Towards a semantic event service for distributed active database applications. In Lecture notes in computer science: Vol. 1460. Proceedings of the International Conference on Databases and Expert Systems Applications, DEXA (pp. 16-27).

Dayal, U., Blaustein, B., Buchmann, A., Chakravarthy, S., Hsu, M., Ledin, R., et al. (1988). The HiPAC project: Combining active databases and timing constraints. ACM SIGMOD Record, 17(1), 51-70.

Dayal, U., Buchmann, A., & McCarthy, D. (1988). Rules are objects too. In Lecture notes in computer science: Vol. 334. Proceedings of the 2nd International Workshop on Object-Oriented Database Systems (pp. 129-143).

Gatziu, S., Koschel, A., von Buetzingsloewen, G., & Fritschi, H. (1998). Unbundling active functionality. ACM SIGMOD Record, 27(1), 35-40.

Gatziu, S., & Dittrich, K. R. (1993). Events in an active object-oriented database system. Proceedings of the 1st International Workshop on Rules in Database Systems (RIDS’93) (pp. 23-29).

Hanson, E. (1989). An initial report on the design of Ariel: A DBMS with an integrated production rule system. ACM SIGMOD Record, 18(3), 12-19.

Paton, N. (Ed.). (1999). Active rules in database systems. Springer.

Active Database Management Systems

Stonebraker, M., Jhingran A., Goh, J., & Potamianos, S. (1990). On rules, procedures, caching and views in data base systems. Proceedings of the 1990 ACM International Conference on Management of Data (SIGMOD)

(pp. 281-290).

Widom, J., & Ceri, S. (Eds.). (1996). Active database systems: Triggers and rules for advanced database processing. Morgan Kaufmann.

Zimmer, D., & Unland, R. (1999). On the semantics of complex events in active database management systems.

Proceedings of the 15th International Conference on Data Engineering (ICDE’99) (pp. 392-399).

Zimmermann, J., & Buchmann, A. (1999). REACH. In N. Paton (Ed.), Active rules in database systems (pp. 263277). Springer.

KEY TERMS

Business Rules: They are precise statements that describe, constrain and control the structure, operations and strategy of a business. They may be thought of as small pieces of knowledge about a business domain.

Consumption Mode: It determines which of these event instances are considered for firing rules. The two most common modes are recent and chronicle.

Coupling Mode: It specifies the transactional relationship between a rule’s triggering event, the evaluation of its condition and the execution of its action.

ECA Rule: It is a (business) rule expressed by means of an event, a condition and an action.

Event: It is an occurrence of a happening of interest (also known as primitive event). If the event involves correlation or aggregation of happenings then it is called a complex or composite event.

Event Algebra: Composite events are expressed using an event algebra. Such algebras require an order function between events to apply event operators (e.g., sequence) or to consume events.

Rule Base: It is a set of ECA rules. Once this set is defined, the aDBMS monitors for relevant events. The rule base can be modified (new rules can be added, or existent rules can be modified or deleted) over time.

Rule Definition Language (RDL): Set of constructs for the definition of rules, events, conditions and actions.

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 catalogue, 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 TwoPhase 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:

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 (Paton, 1998), 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, are view maintenance, global schema updates, verification and validation of global integrity constraints, notification, application, component integration and cooperation, and so forth.

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 is events management 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 (Chakravarthy, Le & Dasari, 1998). This article proposes an event service and a rule service that cooperate to execute active rules within an FDBMS.

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 also be 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 providing 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.

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).

Figure 1. Active FDBMS

•data

•ECA rules

execute rules

Execution Model

•transactions ;

•reactions.

Active Federated Database Systems

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 (Bützingsloewen et al., 1998).

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 on rule execution models. The rule service is responsible for rule execution that consists of two phases:

•The planning phase that builds an execution plan according to different strategies (Coupaye & Collet, 1998).

•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 Collet, Vargas-Solar, and Grazziotin-Ribeiro (2000) and Grazziotin-Ribeiro (1999).

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 (Collet et al., 1998; VargasSolar, 2000; Vargas-Solar & Collet, 2002) provides con-

Active Federated Database Systems

cepts 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, temporaland user-defined events. Composite event types characterize events produced by applying operators such as sequence, conjunction, disjunction, negation, parallel, and so forth 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 financial information such as the variation of the dollar price. The event type the dollar price changes E1 can be defined as follows:

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

The type represents all the possible events representing the fact that the dollar price changes; this is why some of the attributes of the type are not instantiated. The type just specifies that all events will have an instant of production, an eventually associated information about their context [with delta] and a filter [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, delta, and mask. Valid values are those specified in the domains of the corresponding event management model.

recognized and ordered1. They include information to determine how component events contribute to com- A pose 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 even be 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 lifespan 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 producer and consumer 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.

Event Management

The Event Management Meta-Model (Collet et al., 1998; Vargas-Solar, 2000; Vargas-Solar & Collet, 2002) 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 consumer and producer needs.

Detection and production dimensions describe the conditions in which events are detected and how they are

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 (i.e., CONSUMPTION, E_PROCESSING, NET EFFECT, and COUPLING) depend on application needs, and they are defined according to the execution

model (see the next section). 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

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 catalogue. 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 predefined values (Grazziotin-Ribeiro & Collet, 1999). This model specifies

(1) when to execute a rule with respect to the notification of events and how to synchronize its execution with applications and FDBMS execution and (2) how to order possibly interrelated 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.

Active Federated Database Systems

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 or cannot be dependent from the global triggering transaction. Clearly, coupling aspects imply that the rule service has both sufficient accesses 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 ex-

ample, 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 (Collet, Vargas-Solar & Grazziotin-Ribeiro, 2000; GrazziotinRibeiro, 1998). 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.

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 (Koschel et al., 1997) 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 (Fritschi, Gatziu & Dittrich, 1998) 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.

Active Federated Database Systems

CoopWARE (Mylopoulos et al., 1996) and TriggerMan (Hanson & Khosla, 1997) 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. Chakravarthy et al. (1998) propose a framework for supporting ECA rules suitable for distributed and heterogeneous systems.

In general, these works resemble to ours insofar 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 Koschel et al. (1997) and Frithschi et al. (1998) resembles 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 Koschel et al. (1997) and Hanson and Khosla (1997), rules are always executed as separate transactions, independent of the triggering transactions.

CONCLUSION

Flexible infrastructures for supporting component-based distributed applications construction using rules are based on event and rule services used to specify, generate, and execute adaptable and extensible managers that may cooperate to detect events and execute rules in different contexts—that is, (non) transactional, centralized, distributed, and so forth.

Active services characteristics can be described by meta-models that specify policies for event type specification, event management, and reaction execution. A generation approach can be adopted to specify and implement open active database systems comprised of event and rule managers. In conclusion, active services for database federations can be implemented by services and managers as software components customizable according to (database) applications requirements and their environment (i.e., other services, the network, etc.).

Besides the generation approach that provides adaptability, open distributed active services (1) group together, in a flexible way (meta-modeling), functionalities proposed in non-classical (active) database domains and (2) use such solutions for improving communication and integration between database services and other components.

REFERENCES

Bützingsloewen, G., Koschel, A., Lockemann, P., & Walter, H.D. (1998). ECA functionality in a distributed environment. In N.W. Paton (Ed.), Active rules in database