Reaction Rules

Reaction rules are concerned with the invocation of actions in response to events. They state the conditions under which actions must be taken. They define the behavior of a system (or an agent) in response to perceived environment events and to communication events [72].

Reaction rules, often called ECA (Event-Condition-Action) rules, are conceptually of the following type:

ON event

IF condition is fulfilled THEN perform action

This concept assumes an event controller, which monitors certain types of events, and upon occurrence of such an event, the condition of the rule is evaluated. If the condition is true, the action associated to the rule is executed.

In the following, we will discuss these three components of ECA rules in more detail.

The Event Component

ECA rules have been implemented for different application environments and for some time there was no common framework to describe the events signaled to the rule engines. How-ever, along with some research projects in the field of active databases, implementation- and application-independent frameworks for the classification and detection of events have been proposed.

A prominent example is the event algebra Snoop [17], which is used as the event specification component of the Sentinel active database system [18]. Snoop is built around a concept of parameter (or event consumption) contexts, i.e. contexts that defined the semantics of events.

This makes the approach extensible and widely applicable because new contexts with new event semantics can be introduced. Thus, applications of Snoop such as presented in [10], which applies Snoop to XML events, are possible.

In Snoop, an event is defined as an atomic occurrence, i.e. it happens completely or not at all. Further, events can be annotated by event modifiers like begin-of and end-of, which transform arbitrary time intervals into two logical instantaneous events.

Events

Primitive Events Composite Events

Database Events Explicit Events Temporal Events

Absolute Relative Transaction /

Procedure / Function

Access Insert / Delete / Update

Figure 4.1: Snoop’s event hierarchy [17]

A classification of the event types supported by Snoop is illustrated in Fig. 4.1. Snoop distinguishes primitive and composite events. Primitive events are finite sets of events that are pre-defined in the (application) domain of interest. Snoop foresees the following types of primitive events:

• Database events: These events represent the basic database management system (DBMS) operations, i.e. access, insertion, deletion and update of data. Further, the beginning and the end of database transactions, attached procedures and functions are also considered relevant events.

• Explicit events: These are events specific to the application environment and business logic of the system; they take place outside of the DBMS and need to be explicitly signaled to the system.

• Temporal events: These events are referring to points in time. They can be specified as an absolute time point (e.g. a cut-off date), or as a relative time point (e.g. the date of delivery of goods which depends on the date of the order).

Composite events are recursively constructed over other composite events and primitive events. The means for combining events to more complex events are Snoop’s event operators, which include:

• Disjunction (∨): The disjunction of two events E1 and E2, denoted as E1∨ E2, occurs when E1 occurs or E2 occurs.

• Sequence (;): The sequence of two events E1 and E2, denoted as E1; E2, occurs when E2

occurs provided E1 has already occurred.

• Conjunction(Any, All): the conjunction event, denoted

Any(I, E1, E2, ..., En) where I ≤ n, occurs when any I events out of the n events occur, ignoring the order of their occurrence. The All operator can be used to specify that I = n, i.e. that all the listed events have to occur.

• Aperiodic operator (A, A*): The event A(E1, E2, E3) occurs each time the event E2

occurs within the temporal interval defined by the occurrences of E1 and E3. The event A ∗ (E1, E2, E3) occurs only the first time this happens.

• Periodic operator (P, P*): The periodic operator is used to repeat an event during a specified interval P (E1, [t], E3) where E1 and E3 are events and the constant t is the specification of the time between each event. Only those periodic events that occur within the interval between E1 and E3 are signaled.

Examples of the complex events that can modeled using these operators are shown below;

we take the examples directly from [17] and use their simplified syntax to make the rules more readable:

Example 1: “Sample IBM stock every 30 minutes from 8 a.m. to 5 p.m. each day and compute the maximum value over a day”. This rule can be written as follows:

On P*(8 a.m., [30 mins.]: IBM-stock-price, 5 p.m.) Condition true

Action compute maximum

Example 2: “When four withdrawals are made on an account in a day, do not allow further withdrawals”. This rule can be expressed as follows:

On A(8 a.m., Any(4, withdraw-on-an-account*), 5 p.m.) Condition true

Action block further withdrawals

The Table 4.1 gives an overview over a variety of active database systems and compares the various properties of the event components of the systems to the Snoop/Sentinel approach. The tables shows which of the systems support database, temporal, explicit and complex events.

Further, it shows which concepts support event modifiers and which support parameter contexts.

The Condition Component

If an event of an ECA rule is signaled to the rule engine, the condition of that rule will need to be evaluated in order to decide whether the rule is eligible to be fired or not. The separation of event and condition specifications provides both extensibility and a clear understanding of the

“when” (an event), the “what” (a condition) and the “how” (an action).

A condition is a boolean function of data values, such as “the credit is greater than 100”.

A condition does not produce any side effect. It may be valid over an interval of time, while an event is atomic.

Conditions define states of a database or an expert system, and as such they can be inter-preted as guards that protect transitions in a state-transition system. A guarded transition will only fire if its guard condition is fulfilled.

According to [43], the condition component can be classified into elementary and composite conditions:

• Elementary conditions are conditions on sets or literals (i.e. atomic predicates or negated predicates). An example of a set condition would be “if person X is element of the customer list”. An example of a predicate condition is “if salary > 100”.

Table 4.1: Overview of event concepts in the active database world (modified presentation of [17])

Feature / Primitive Event Types Expressiveness

System Database Temporal Explicit Complex

Interbase Yes No No Disjunction Pre, Post No

Postgres Yes No No Disjunction equiv. to

post

No

Starbust Yes No No Disjunction Post No

HiPAC Yes Absolute,

OSAM* Yes No No Disjunction before,

af-ter

• Composite conditions are constructed by applying boolean operators like conjunction and disjunction to the (elementary and composite) conditions to form more complex conditions.

The Action Component

The action component of an ECA rule specifies what the system is supposed to accomplish in case the specified event occurs and if the associated conditions holds. As in events and conditions, we can distinguish two kinds of actions [51]:

• an elementary action that is comprised of a single task to be carried out

• a composite action that is a structure – usually, a sequence – of several tasks to be executed.

Furthermore, we can distinguish actions by their use, i.e. by the effects they achieve [43]:

• Data manipulation actions encompass the creation, modification, retrieval, derivation and deletion of data. These data objects are not necessarily stored in a database but may also be stored outside the automated part of an information system (e.g. on a form). Insert and delete concern entire tuples and the other three may involve specific properties.

• User actions encompass a task which may be related to a data object but does not imply one of the operators mentioned above. User actions may contain any text, e.g. “call supplier and reorder product”. A detailed syntax for their content (i.e. the specification of certain actions) is not always feasible.

• Message actions consist of a message to a processor of the information system. This message may be issued to an application or a human actor. A business rule whose action can be classified as a message action is called an alerter. The message can inform the target person on a situation and may trigger a specified action. Thus, the syntax for message actions contains at least a message and sometimes also the recipient of the message.

More on the definition of actions can be found in Chapter 3 of this report.