TOWARDS CREATION OF LOGICAL FRAMEWORK FOR

EVENT-DRIVEN INFORMATION SYSTEMS

Darko Anicic and Nenead Stojanovic

Forschung Zentrum Informatik (FZI), University of Karlsruhe, Germany

Keywords:

Event-Condition-Action Rules, Reactive Systems, Rule-based Reasoning, Logic Programming.

Abstract:

Event-Condition-Action (ECA) rules offer extensible and ﬂexible approach to realizing active Enterprise In-

formation Systems. Such systems are enabled to actively respond on events or state changes. Hence their

behavior is programable by means of ECA rules. We propose an implementation of ECA rules in a completely

logical framework, using Transaction Datalog¬ as an underlying logic. In this way, we extend the current

ECA framework by means of powerful and declarative semantics, which also have an appropriate procedu-

ral interpretation. We show how a logical calculus of Transaction Datalog¬ can be exploited for realizing

composite events, conditions, and actions; justifying the use of declarative semantics for solving some of the

existing issues in reactive systems.

1 INTRODUCTION

Event-driven architecture (EDA) represents a new

hype in enterprise information systems, that comple-

ments the service-oriented architecture. Event-driven

applications trigger actions as a response to the detec-

tion of events. The event may signify a problem or

an impending problem, an opportunity, a threshold,

or a deviation. Upon generation, the event is immedi-

ately disseminated to all interested parties (humans or

machines). The interested parties evaluate the event,

and optionally take action. The event-driven action

may include the invocation of a service, the trigger-

ing of a business process, and/or further information

publication/syndication. EDA is the architecture of

choice for implementing straight-through multistage

business processes that deliver goods, services and in-

formation with minimum delay and maximal ﬂexibil-

ity. It is a style of application architecture centered

on asynchronous push-based communication leading

to the so-called active enterprise information systems,

that are able to react autonomously on various inter-

nal and external events. However, despite its enor-

mous importance, this kind of systems is still missing

a comprehensive mechanism for (formal) representa-

tion of event-action causality (usually coded in Event-

Condition-Activity rules). One challenge is, for ex-

ample, to formally represent two set of actions, trig-

gered by the same event, that have to be synchronised

with each other (e.g., one action from an ECA rule

has to be accomplished in order to start an action from

another ECA rule). Such and similar formal descrip-

tions could than serve for executing different activi-

ties, and reasoning about behavioral aspect of reactive

information systems.

In order to formalise reactive systems, we are

proposing Transaction Datalog¬ (T D ¬) (Bonner,

1998) to be used as an underlying logic. In fact,

the main contribution is the extension of the standard

ECA framework with the formal semantics of T D ¬.

We use deductive rules to deﬁne new implicit events

or complex conditions and actions. Moreover we ar-

gue that the interaction between events and actions is

possible and achievableby means of logic. As pointed

in (Bry and Eckert, 2007b), use of rules for describ-

ing, rule based, ”virtual” events is highly desirable

due to a number of reasons: rules serve as an ab-

straction mechanism and offer a higher-levelevent de-

scription. Rules allow for an easy extraction of differ-

ent views of the same reactive system. Rules are suit-

able to mediate between the same events differently

represented in various interacting reactive systems.

Finally, rules can be used for reasoning about causal

relationship between events. Similar argumentation

for the rule-based events also applies for the condi-

tion and action part. Moreover integration of events,

conditions, and actions by means of logic brings new

possibilities in utilising behavioral aspects of event-

394

Anicic D. and Stojanovic N. (2008).

TOWARDS CREATION OF LOGICAL FRAMEWORK FOR EVENT-DRIVEN INFORMATION SYSTEMS.

In Proceedings of the Tenth International Conference on Enterprise Information Systems - ISAS, pages 394-401

DOI: 10.5220/0001716703940401

 SciTePress

driven enterprise information systems.

Our goal is to enable information systems to cap-

ture internal and external (relevant) changes. A sys-

tem needs to properly react on changes in an auto-

mated manner. Such reaction can be seen as an act of

change propagation. In general, an action changes the

state of the system or triggers a new event. Therefore

it is a question how to effectivelycontrol the whole re-

active system, i.e. how machines can keep executing

certain activities, ensuring at the same time the system

consistency. In order to achieve this goal, we combine

a reactive system (i.e., ECA system) with deductive

capabilities in a Logic Programming style. First, our

extension is motivated by the aim to synthesize active

behavior (from ECA rules) with procedural and de-

ductive semantics (from Transaction Datalog¬). Sec-

ond, the extended framework integrates reactive and

continuous behavior appropriately.

The paper is organised in the followingmanner: In

the second section we give a short introduction into

the ECA rules, whereas the third section introduces

TransactionDatalog¬. Our logic-based realisation of

ECA rules is described in setcion four. Section ﬁve

describes related work, whereas section six contains

concluding remarks.

2 ECA FRAMEWORK

Event-Condition-Action rules have recently gained

signiﬁcant attention in information systems where re-

active behavior is required, i.e., systems capable to

detect events and respond to them automatically. The

context, in which events are triggered, is also taken

into account. The general form of ECA rules is: ”ON

Event IF Condition DO Action”. Interpretation of a

single ECA rule is to execute Action when Event oc-

curs, provided that Condition holds. When a set of

rules is considered, the interpretation is getting more

complicated (Berstel et al., 2007). This, particularly

holds, when taking into account the execution model

of rules (i.e., behavior of rules at run-time). First, the

rule set may contain conﬂicting rules. Second, there

is an issue how to execute rules with respect to: order-

ing, priorities, granularity; such that, they still capture

the intended meaning. For those reasons we use the

semantics of (T D ), trying to create an ECA frame-

work that is more robust and formal. In the following,

we brieﬂy describe the basic elements of an ECA rule.

Event. In general, reactive systems are recursive sys-

tems, where event is a central notion for driving the

execution. Hence the role of events is, ﬁrst, to identify

situations in which the system is supposed to react,

and second, to start the execution of ECA programs

in an appropriate moment.

Condition. The context, in which an ECA rule ﬁres,

is described by the condition part. The condition part

is usually represented as a query to a persistent knowl-

edgebase. More importantly, the condition acts as a

glue between different parts of a rule (i.e., event and

action). In Section 4, we will introduce a more com-

plex condition form, where the condition part may

also be represented as any Datalog-like rule.

Action. The action part changes the state of a system.

While events are triggered as a consequence of state

changes, the actual state changes are caused by ac-

tions. Hence the reactive behavior of ECA systems

is realized through the execution of actions. Typi-

cal examples of actions are: updating persistent data,

calling a web service, triggering new events, commit-

ting a database transaction, or the rule base modiﬁ-

cation. In some cases, more simple (atomic) actions

may be combined to form a complex action. An ex-

ample of a complex action is a sequence of atomic ac-

tions. Further on, a complex action may be deﬁned as

a speciﬁcation of alternative actions (i.e., if one action

fails, the other one will start executing). In Section 4,

we propose use of Transaction Datalog¬, in order to

specify complex actions. Use of Transaction Datalog

in an ECA framework, does not allow us only to cre-

ate more complex actions, but also to enable coordi-

nation and cooperation between them. Communica-

tion, synchronization and concurrency between run-

ning actions are also supported.

3 OVERVIEW OF TRANSACTION

DATALOG¬

In this section we give a short overviewof Transaction

Datalog, highlighting the language’s most important

properties with respect to this paper.

Transaction Datalog. Transaction Datalog (T D ) is a

subset of Transaction Logic (T R ) (Bonner and Kifer,

1995), and Concurrent Transaction Logic (C T R )

(Bonner and Kifer, 1996). Concurrent Transaction

Logic is a general logic designed speciﬁcally for

the rule-based paradigm, and intended to provide a

declarative account for state-changing actions. Our

motivation to use this particular logic, in an ECA

framework, lies in a set of special logical and tem-

poral connectives provided by T D . For instance, a

sequence of actions may be executed sequentially or

in parallel. Further, actions may be synchronized and

communicate among themselves (e.g., one action can

read what another action writes). On the other side,

an action may also be executed in isolation from the

TOWARDS CREATION OF LOGICAL FRAMEWORK FOR EVENT-DRIVEN INFORMATION SYSTEMS

395

other actions. T D allows users to specify properties

of state-changing programs, and to reason about them

(Bonner and Kifer, 1995).

Transaction Logic has a ”Horn” fragment, with

both, a procedural and declarative semantics (Bonner

and Kifer, 1995). T D is derived from this Horn frag-

ment, just like, classical Datalog is derived from clas-

sical Horn logic (Bonner, 1998). Compared with the

full logic, T D has simpler semantics, hence gives a

possibility for more effective implementation. At the

same time, we will show (in Sections 4.1 and 4.3) that

T D is still expressive enough to fulﬁl requirements

for an expressive ECA framework.

Syntax. The syntax of Transaction Datalog is the

same as the classical Datalog syntax (Ullman, 1990),

extended with three additional predicate symbols:

p.empty, ins.p and del.p. Intuitively, p.empty means

”Is relation p empty”, ins.p means ”Insert atom p in

the knowledgebase”, and del.p means ”Delete atom p

from the knowledgebase”. T D , further, includes: se-

rial conjunction, concurrent conjunction, and modal-

ity of isolation, respectively denoted ⊗, |, ⊙. For

example, if r, q,t, and w are atomic actions, than p

is deﬁned as p(X) ← del.q(X) ⊗ ⊙(t(X) | w(X)) ⊗

ins.r(X), is a complex action (represented as a Trans-

action Datalog rule). Executing the action p, in-

tuitively, we perform three successive sub-actions:

delete an atom q(X), execute in parallel sub-actions, t

and w, and ﬁnally, insert an atom r(X) to the knowl-

edge base. If any of the sub-action fails, the whole

action will fail. In that situation, the system retracts

to its initial state (i.e., a state before the execution

started). This mechanism keeps the system always

in a consistent state. The isolation operator is used to

constrain communication between concurrently run-

ning sub-actions. For instance, consider a complex

action ϕ

| (⊙ϕ

) | ϕ

. During the execution of such

an action, sub-actions ϕ

and ϕ

may communicate

between themselves. However ϕ

will be executed in

isolation of them.

The following example from (Bonner, 1998),

demonstrates another important feature of T D , that

is synchronization.

Example 3.

actionA ← actionB | actionC.

actionB ← taskB

⊗ ins.startC

⊗ taskB

⊗ startB

⊗

taskB

actionC ← taskC

⊗ startC

⊗ taskC

⊗ ins.startB

⊗

taskC

The ﬁrst rule deﬁnes a complex actionA, which

consists of two sub-actions: actionB and actionC.

The two sub-actions execute concurrently, but not

independently. In particular, each action performs

three tasks, where taskC

(from actionC) cannot start

until taskB

(from actionB) is ﬁnished. Similarly,

taskB

cannot start until taskC

is completed (i.e.,

speciﬁed with ins.startB

from actionC, and an atom

startB

from actionB). Therefore we see that actionB

communicates with actionC. Moreover the two sub-

actions, actionB and actionC, are synchronized be-

tween themselves.

Negation. Unlike (Bonner,1998), we use Transaction

Datalog embellished with negation-as-failure (Lloyd,

1989), thus extending T D to T D ¬ (the same way as

classical Datalog is extended to Datalog¬). In Section

4, we will deﬁne complex ECA rules that possible in-

clude negated events and actions. When negation is

allowed, there might not be a least ﬁxed point (i.e.,

unique solution for a given set of rules), but several

minimal ﬁxed points (Ullman, 1990). In such situa-

tions, there is a problem to determine what is the ac-

tual meaning of the rules. We permit the stratiﬁed

negation (Ullman, 1990), as with that form of nega-

tion, one can still choose an intuitive meaning in case

of the non-unique solution. In addition, we should

also mention that rules in T D may be recursive as in

classical Datalog.

Execution Paths. Transaction Datalog provides a

declarative account for state-changing actions. A

state is deﬁned as a ﬁnite set of ground atomic formu-

las with EDB predicates

. To model complex, concur-

rent actions, T D has a notion of execution paths, that

records the execution history of the complex actions.

Intuitively, the path represents periods of continuous

execution, separated by periods of suspended execu-

tion (during which other action may execute) (Bonner

and Kifer, 1996). In Section 4, we further discuss im-

portance of the execution paths with respect to our

ECA framework. Transaction Datalog has a model

theory inherited from T R , and an operational seman-

tics based on a proof procedure with uniﬁcation. For

detailed analysis about syntax, semantics, and an in-

ference system of T D , we refer the reader to (Bonner,

1998; Bonner and Kifer, 1996).

4 IMPLEMENTING ECA RULES

WITH T D ¬

In this section we review the role of basic elements

of an ECA rule (i.e., event, condition, action), putting

them in a logical framework, and implementing them

with Transaction Datalog¬.

As in classical Datalog, there are two sorts of predi-

cates: base or EDB, and derived or IDB predicates.

ICEIS 2008 - International Conference on Enterprise Information Systems

396

4.1 Event

The execution in reactive systems is driven by events.

We distinguish between an internal and an external

event. The internal event occurs as a consequence of

a state-change in the system (e.g., a fact has been in-

serted in the knowledgebase, a transaction commit-

ted, an exception occurred in the system etc.), while

the external event is raised by a happening outside the

system (e.g., caused by an external procedure, a sen-

sor or an application)

. In either case, an event needs

to be registered, such that, an ECA system can recog-

nize the event and behave accordingly. For this pur-

pose we use an event ontology (e.g., complex events

are build out of atomic events by means of class rela-

tionship etc.).

Composite Event. Composite (or complex) event

consists of atomic events that satisfy some pre-

deﬁned patterns. For instance, a pattern may be de-

ﬁned as a conjunction, disjunction, or negation of

atomic events, followed by some temporal constraints

(e.g., one event happened 10 min after another one).

We use Transaction Datalog¬ to formally specify

these patterns, and later on, to identify complexevents

by capturing the state-changes in the knowledgebase.

We assume a discrete time model, where time

is an ordered set of time points. In this paper

points are represented as integers, but other time

models for time and data representation are possi-

ble without restrictions. The notion of an atomic

event is deﬁned as a relevant state change

a system, characterized by the time. Formally,

an event is e(T

, T

, X

, ..., X

), n ≥ 0, where

e is an event name (i.e., a predicate symbol),

and T

, T

, X

, ..., X

is a list of arguments.

, X

, ..., X

represent a set of data terms. Events

contain data relevant for a reactive system. The data

of event is a data term that may be either a variable,

a constant, or a function symbol. T

, T

deﬁnes a

time interval during which the event has occurred.

Following the argumentation from (Paschke et al.,

2007), interval-based events are suitable for Com-

plex Event Processing (CEP). For an atomic event

, T

, X

, ..., X

), it appears that T

is equal to

. However consider a complex event e that is a se-

quence of events e

, e

, and e

in the following order:

before (e

before e

). If an event was not deﬁned

over a time interval (i.e., the detection time of the

terminating event is used as occurrence time of the

complex event), an inconsistency would occur due to

the possibility to detect e as a sequence: e

before (e

Note that there is no strict difference between an (ex-

plicit) event and a state change (i.e., an implicit event).

What is a relevant change depends on an application.

before e

) as well as for the sequence: e

before (e

before e

). In order to prevent such unintended se-

mantics, a complex event e(T

, T

, X

, ..., X

) that,

for instance, consist of events e

, T

, X

, ..., X

)

and e

, T

, X

, ..., X

) is deﬁned over an interval

, T

] where T

= min{T

, T

} and T

= max{T

, T

Deﬁnition 4.1 A complex event is a formula of the

following form:

• an atomic event;

• (event

∧ event

∧ ... ∧ event

), where n ≥ 0 and

each event

is an event (Conjunctivecomposition);

• (event

∨ event

∨ ... ∨ event

), where n ≥ 0 and

each event

is an event (Disjunctive composition);

• (event

⊗ event

⊗ ... ⊗ event

), where n ≥ 0 and

each event

is an event (Sequential composition);

• ¬event, where event is an event (negation).

• ⊙event, where event is an event (isolation).

A rule is a formula of the form eventA ← eventB,

where eventA is an atomic event, and eventB is ei-

ther an atomic or a complex event  In the above

deﬁnition, every event

is deﬁned over a time interval

, T

] with possible set of data terms that are omitted

due to space reasons.

In following examples we demonstrate the power

of Transaction Datalog¬ language, and give justiﬁca-

tion for its use in our ECA framework.

Example 4.1 deﬁnes a complex event,

checkStatus, which happens ”if a priceChange

event is followed with a stockBuy event”. Further on,

the two events have happened within a certain time

frame (i.e., t < 5).

Example 4.1

checkStatus(T

, T

, X,Y, Z,W) ←

priceChange(T

, T

, X,Y) ⊗ stockBuy(T

, T

, Z,Y,W) ∧

− T

< 5).

In our system, we have an event ontology where the

following has been deﬁned

• priceChange(T

, T

, X,Y) is an event, that de-

scribes the change in the stock price X (e.g., ±5%)

of a companyY;

• stockBuy(T

, T

, Z,W,Y) deﬁnes a transaction, in

which, a buyer Z has bought W amount of stocks

from a company Y.

Note that, apart from events deﬁned in the event on-

tology, we use a number of built-in predicates with prede-

ﬁned meaning (e.g., ”−” and ”<” represent ”subtraction”

and ”less then” arithmetic operations).

TOWARDS CREATION OF LOGICAL FRAMEWORK FOR EVENT-DRIVEN INFORMATION SYSTEMS

397

In some cases a user may be interested in an-

alyzing past events. For this purpose, we need a

formalism that allow us, not only to create complex

events, but also to query them. We have an event

system log, which serves to record each event occur-

rence in the system. In the following example we ask

for all events where the change in stock price was

bigger than 10%.

Example 4.2

?− priceChange(T

, T

, X,Y) ∧ X > 10.

As all events are accumulated in the event system

log, we can also describe situations where negated

events are used. For instance, Example 4.3 represents

a notFul filledOrder event, that triggers when a

customer has made a purchase, but the purchase has

not been delivered within a certain time. Therefore,

we see, that the system is also capable to support

non-monotonic features (i.e., the existence of an

event which is deﬁned in absence of other events,

may be retracted, if one of the absent event occurs

later). Note that, since the event stream is inﬁnite,

one should always deﬁne a time interval as a scope of

a query, or a rule. In the Example 4.3 the interval in

which we check whether an item has been delivered

is [T

, T

Example 4.3

notFul filledOrder(T

, T

, X) ← purchased(T

, T

, X) ⊗

¬delivered(T

, T

, X) ∧ (T

− T

> 3).

Example 4.4

complexEvent(T

, T

, X) ← eventA(T

, T

, X) ⊗

eventB(T

, T

, X)

In Example 4.4, we demonstrate use of the se-

quential composition operator (from Deﬁnition 4.1),

i.e., a complexEvent will occur if eventA is followed

by eventB. If eventA has happened, the system needs

to ”remember” it, and to raise complexEvent once

eventB happens. Detection of complex events is done

by following the state-change (transition) path. In

general case, executing a Transaction Datalog rule,

the system may change the state from S

to S

(i.e.,

going through states: S

, S

, ..., S

). If the rule de-

scribes a complex event, this state-transition may be

seen as the progress towards detection of a com-

plex event. In this way, if eventA has occurred

but eventB has not, the system will wait, and raise

complexEvent once eventB is triggered. Note, if we

replace eventB(T

, T

, X) with eventA(T

, T

, X) from

the example 4.1, we can deﬁne a repeated event (e.g.,

double click).

Finally, the modality of isolation operator ⊙ is

used for deﬁning a composite event with additional

constraints. Usually a composite event consists of

(atomic) events that satisfy some pre-deﬁned pat-

tern. In this respect, a composite event is not de-

pendant on all events monitored in the system, but

those that constitutes that particular event. However

the modality of isolation operator allow us to con-

struct a composite eventthat is, apart from its (atomic)

events, also constrained with other events from the

system. For instance, a composite event e, deﬁned

as e(T

, T

, X,Y) ← e

, T

, X) ⊗ e

, T

, X,Y) ⊗

, T

, X,Y), will be triggered if e

, e

, and e

happen next to each other with no other events in-

between. Of course, a time interval for such compos-

ite events should be clearly deﬁned as a scope over

which events are monitored (i.e., [T

, T

] in this case).

4.2 Condition

The condition part determines whether an ECA rule

(triggered by a certain event) will be executed or not.

The condition part is usually represented as a query,

since it depends on the current state of the system. In

our framework, the condition of an ECA rule may be

signiﬁcantly more complex.

Deﬁnition 4.2 The condition part of an ECA rule

is any Datalog¬ rule, where the rule head is the

condition name, and the rule body is the condition

deﬁnition 

The following T D formula represents an action,

act, that will be executed iff the condition part, cond,

is fulﬁlled:

⊙[cond ⊗ act]

In this way we express a T D formula, that is at

the same time, a Condition-Action rule. Hence the

action, act, will be executed only if the condition,

cond is fulﬁlled. Further on, the condition part (cond)

may be extensively dependant on a number of other

sub-conditions, as deﬁned by Deﬁnition 4.2, and

shown below:

cond ← cond

∧ (cond

∨ cond

) ∧ ¬cond

cond

← cond

∧ cond

4.3 Action

In general case, the purpose of the action part is to

change the state of the system. An example of a

ICEIS 2008 - International Conference on Enterprise Information Systems

398

state change is a single update in the knowledgebase.

However atomic actions, such as data update, are too

limiting in practise. More often we need to com-

bine atomic actions into complex actions. We ex-

tend the standard ECA framework with deductive ca-

pabilities, such that the action part can be formally

described with Transaction Datalog¬. First, our ex-

tension is motivated by the aim to integrate active be-

havior (from ECA rules) with deductive capabilities

(from Transaction Datalog¬). Second, the extended

framework integrate reactive and continuous behav-

ior appropriately.

In the following, we give legal possibilities for

creating a complex action out of atomic ones.

Deﬁnition 4.3 An action is a formula of the following

form:

• an atomic action;

• (action

∧action

∧... ∧action

), where n ≥ 0 and

each action

is an action (Conjunctive composi-

tion);

• (action

∨action

∨... ∨action

), where n ≥ 0 and

each action

is an action (Disjunctive composi-

tion);

• (action

⊗ action

⊗ ... ⊗ action

), where n ≥ 0

and each action

is an action (Sequential compo-

sition);

• (action

| action

| ... | action

), where n ≥ 0 and

each action

is an action (Concurrent composi-

tion);

• ¬action, where action is an action (negation).

• ⊙action, where action is an action (isolation).

A rule is a formula of the form actionA ← actionB,

where actionA is an atomic action, and actionB is

either an atomic or a complex action 

A rule may be seen as an action procedure, where

the rule head is a complex action name, and the rule

body is the action deﬁnition. Likewise events, actions

are not just propositions, but contain data terms. Each

action a(X

, X

, ..., X

) may be of arity n, n ≥ 0, where

, X

, ..., X

is a list of variables or constants, repre-

senting parameters of the action procedure.

Utilising T R operators, complex action may cre-

ate complex processes that, at the end, may form a

workﬂow (Bonner, 1999). As we can see, from Sec-

tion 3 and Deﬁnition 4.3, actions may run in parallel

possibly having non-serializable access to shared re-

sources, or for instance, they can communicate and

synchronise themselves.

As mentioned in Section 3, T D has a notion of

execution paths. Execution paths show the way com-

plex actions are executed, and record their execution

history. Formally, an execution path of a complex

action is represented as a ﬁnite sequence of pairs:

, S

, ..., S

n−1

, where each state-change (i.e.,

i+1

) represents a period of an atomic action execu-

tion. For instance, imagine an event e

has occurred,

and caused a corresponding complex action a

to start

executing. The event e

has occurred when the knowl-

edgebase was in the state S

, and after the execution

of the action a

, the system will be brought to the state

. Since the a

is a complex action, the system will

go through a set of states S

, S

, ..., S

n−1

. Ev-

ery state transition, S

i+1

, corresponds to execution

of an atomic action. Now suppose that during the ex-

ecution of a

, an event e

has occurred. The event e

has caused an action a

to happen, which is a sim-

ple action, and hence, will be completed before a

Note that a

will change the state of the whole sys-

tem, while a

is still executing. Thanks to an inter-

leaving semantics of T D , after the execution of both

actions, our whole ECA system will still remain in a

consistent state. The interleaving semantics assumes

a single execution path although a number of concur-

rent complexactions may be running at the same time.

Every complex action consists of a sequence of sub-

actions, where each sub-action changes a state of the

system. However by interleaving these sequences, we

obtain a new sequence of state changes, which is an

execution path.

However some complex actions need to be

executed continuously (i.e., without interruption by

other sub-actions, or suspension). In this situation we

use a modality of isolation. For example, consider a

complex actionA which consists of three sub-actions:

actionA ← ⊙ [taskA

⊗ taskA

]

An execution path of the above action is a sin-

gle pair of states, S

, S

. Although actionA is a com-

plex action, it has been modeled to change the state

only from S

to S

(not as a sequence of changes:

, S

). Therefore if some other actions are

executing at the same time, their execution paths will

not be interleaved with the one of actionA. There-

fore assuming that actionA started to execute ﬁrst, the

other actions will be committed after the actionA.

In the Example 3 (section 3) we have explained

how a complex action can be implemented with

two concurrently running, synchronised, actions. In

case we want to synchronise the two actions with

some (external) events, we may replace constructs for

the synchronisation (i.e., ins.startC

and ins.startB

)

with some events startC

, startB

. In this way, our

ECA framework features tighter integration between

TOWARDS CREATION OF LOGICAL FRAMEWORK FOR EVENT-DRIVEN INFORMATION SYSTEMS

399

events and actions. Moreover this integration has

been achieved at the logical level, which allows rea-

soning about actions and events. For instance a pat-

tern such as ”notify me if an actionA happened be-

fore an eventE, and the eventE happened before an

actionB” would be easy extractable by the reasoner.

4.4 Executing ECA Rules

In this section we give more details about basic con-

cepts underlying our ECA framework with respect

to the evaluation of ECA rules. We adhere to the

general syntax of an ECA rule:

ON Event IF Condition DO Action

However our approach differs from existing

frameworks in deﬁning the Event, Condition, and Ac-

tion part. As given by Deﬁnitions 4.1, 4.2, and 4.3,

each component of an ECA rule may be deﬁned as a

set of either T D ¬ or Datalog¬ rules.

ECA-based systems, with complex events, con-

ditions, and actions; have been extensively studied

elsewhere in (Paton and D´ıaz, 1999; Bry and Eck-

ert, 2007a). One of the common issue in these sys-

tems is a speciﬁcation of an execution semantics when

a set of ECA rules is considered (rather than a sin-

gle a rule). The execution semantics gives an answer

how rules are treated at run-time. Imagine a situation

where several events occur at the same time trigger-

ing several actions to happen (i.e., several ECA rules).

The system does not know in which order to apply

those rules. Different choices may lead to different

executions. For these, and similar issues, various ex-

ecution semantics have been proposed, e.g., selecting

only one rule from the conﬂict set, executing all rules,

rejecting the execution of any rule and triggering an

exception etc. (Paton and D´ıaz, 1999)

Our approach is accomplished in a completely

declarative framework (i.e., using the formal seman-

tics of T D ¬ language). We write ECA rules as a

set of logical equations. These equations are spec-

iﬁed declaratively (i.e., specifying what we want to

achieve, rather than how we want to achieve that).

Now, let us assume the same issue as earlier in this

text (i.e., several ECA rules have been triggered at the

same time). In our case, we deploy an inference en-

gine to ﬁnd an execution path. Precisely, the goal of

the inference engine is to ﬁnd a possible execution,

for a given set of rules following the procedural se-

mantics of T D ¬ (Bonner and Kifer, 1996).

In conclusion, following the semantics of T D ¬,

the reasoner executes a set of ECA rules, executing

at the same time, a set of (possibly) complex actions.

These actions may run in parallel, or in a sequence

(or combined). More importantly is that our frame-

work has two-fold beneﬁt of using semantics. The

ﬁrst advantage is deployment of an inference engine

for ﬁnding a legal execution path among all possible

choices of executions. Usually, the execution path

depends on run-time properties of a logic program.

Hence searching for an executable path (in run-time)

is rather a reasoning task. Using declarative seman-

tics, our framework is capable to accomplish this task

in an automated manner. We see this approach, as

more ﬂexible, and in some real-world scenarios, as

the only one. The second advantage is: executing a

path (found by the reasoner), the system will never

run into an inconsistent state.

ECA rules are considered as an appropriate form

of reactive rules for a distributed environment (e.g.,

Web). However their use in a distributed environment

may be very unpredictable, with respect to their in-

tended semantics (Kifer et al., 2006). In general case,

execution of an event may trigger other events, and

these events may trigger even more events. There

is neither guarantee that, such a chain of events will

stop, nor that states (through which a distributed sys-

tem passes) are valid. We see semantics as a means to

establish some sort of a consistency check mechanism

in an ECA framework. The purpose of this mecha-

nism is to control state-changing actions, keeping the

system always in a consistent state. By executing a set

of complex ECA rules, our system changes its states.

In this transition, every state in which the system en-

ters, needs to be a legal state (with respect to the ECA

rules and the semantics provided by T D ). Howeverif

the inference engine, searching for a possible execu-

tion path, enters to an illegal state (w.r.t the semantics

of given rules), such a state-transition will be rolled

back. In this way, our framework is an attempt to

implement ECA rules in a completely logical frame-

work, trying to achieve better run-time properties of

the entire ECA system.

5 RELATED WORK

This section brieﬂy overview current approaches in

realizing an ECA framework, with the declarative se-

mantics, and logical rules. Work on modeling behav-

ioral aspect of an application (using various forms of

reactiverules) has started in the Active Database com-

munity. Different aspects have been studied exten-

sively, ranging from modeling and execution of rules,

to architectural issues (Paton and D´ıaz, 1999). How-

ever, what is clearly missing in this work, is a clean

integration of active behavior with deductive and tem-

ICEIS 2008 - International Conference on Enterprise Information Systems

400

poral capabilities. This is exactly a goal of our ap-

proach. Going in that direction, (Behrends et al.,

2006) is an attempt which combines ECA rules with

Process Algebra. The idea is to enrich the action

part, with the declarative semantics of Process Alge-

bra, particularly CCS algebra (Milner, 1983). Use of

Process Algebra speciﬁcation aims to enable the rea-

soning functionality (e.g., model checking) in such

an ECA system. Recently, the event part of a rule

has also been put in a logical framework (Bry and

Eckert, 2007a). There, an event may be deﬁned us-

ing reactive, but also, deductive rules. In (Paschke

et al., 2007) a homogenousreaction rule language was

given. The approach combines different paradigms

such as reactive rules, declarative rules and integrity

constraints. In conclusion, all previously mentioned

studies, are motivated to use more formal semantics.

Our approach may also be seen as an attempt towards

that goal, though followed by a pure Logic Program-

ming style.

6 CONCLUSIONS AND FUTURE

WORK

We propose an expressive ECA framework that uses

Transaction Datalog¬ as an underlying formalism.

The framework clearly extends capabilities of Active

Databases with declarative semantics, and power of

rule-based reasoning. Further on, Active Databases

usually combine two or more formalisms (e.g., SQL

as a declarative language for querying, and Java, or

some other high-level language, for procedural pro-

gramming). Similarly, in (Behrends et al., 2006),

Process Algebra has been chosen as a formalism

for the complex action speciﬁcation and execution.

The event and condition part may possibly be spec-

iﬁed by other languages (e.g., XPath/XQuery, Dat-

alog, SPARQL, F-Logic etc.). Using Transaction

Datalog¬, we provide a uniﬁed framework that is

also clean and simple. Transaction Datalog does not

make a sharp distinction between declarative and pro-

cedural programming. Therefore, our framework pro-

vides a seamless integration of these two program-

ming styles, and allows speciﬁcation of more com-

plex events, conditions, and actions (e.g, events can

be combined as a sequence of atomic events or actions

can talk to each other or be nested and executed in

parallel). We believe this approach is more pragmatic

from the implementation and optimization point of

view. For the next steps we will continue to formalise

our ECA framework. Currently, we are working on

practical reasoning procedures for T D ¬. Later on,

we plan to work on efﬁcient algorithms for CEP with

T D ¬, as well as on the prototype implementation.

REFERENCES

Behrends, E., Fritzen, O., May, W., and Schenk, F. (2006).

Combining eca rules with process algebras for the se-

mantic web. In RuleML.

Berstel, B., Bonnard, P., Bry, F., Eckert, M., and Patranjan,

P. L. (2007). Reactive rules on the web. In Reasoning

Web. Springer.

Bonner, A. J. (1998). Transaction datalog: A compositional

language for transaction programming. In Database

Programming Languages. Springer.

Bonner, A. J. (1999). Workﬂow, transactions and datalog.

In PODS ’99: Proceedings of the eighteenth ACM

SIGMOD-SIGACT-SIGART symposium on Principles

of database systems. ACM.

Bonner, A. J. and Kifer, M. (1995). Transaction logic pro-

gramming (or, a logic of procedural and declarative

knowledge. In Technical Report CSRI-270.

Bonner, A. J. and Kifer, M. (1996). Concurrency and com-

munication in transaction logic. In Joint International

Conference and Symposium on Logic Programming.

MIT Press.

Bry, F. and Eckert, M. (2007a). Rule-based composite event

queries: The language xchangeeq and its semantics. In

RR. Springer.

Bry, F. and Eckert, M. (2007b). Towards formal founda-

tions of event queries and rules. In Second Int. Work-

shop on Event-Driven Architecture, Processing and

Systems EDA-PS.

Kifer, M., Bernstein, A., and Lewis, P. (2006).

Database Systems - An Application-Oriented Ap-

proach. Addison-Wesley Longman Publishing Co.,

Inc., Boston, MA, USA, 2nd edition.

Lloyd, J. W. (1989). Foundations of Logic Programming.

Computer Science Press.

Milner, R. (1983). Calculi for synchrony and asynchrony.

In Theor. Comput. Sci.

Paschke, A., Kozlenkov, A., and Boley, H. (2007). A ho-

mogenous reaction rules language for complex event

processing. In International Workshop on Event Drive

Architecture for Complex Event Process. ACM.

Paton, N. W. and D´ıaz, O. (1999). Active database systems.

In ACM Comput. Surv. ACM.

Ullman, J. D. (1990). Principles of Database and

Knowledge-Base Systems, Volume I. W. H. Freeman

& Co., New York, NY, USA, 2nd edition.

TOWARDS CREATION OF LOGICAL FRAMEWORK FOR EVENT-DRIVEN INFORMATION SYSTEMS

401