![](bg2.png)
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 five
describes related work, whereas section six contains
concluding remarks.
2 ECA FRAMEWORK
Event-Condition-Action rules have recently gained
significant 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 conflicting 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 briefly 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, first, 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 fires,
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 modifi-
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 defined as
a specification 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 specifically 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