The VLDB Journal (2004) 13: 177–203 / Digital Object Identiﬁer (DOI) 10.1007/s00778-003-0108-y
Amit – the situation manager
Asaf Adi, Opher Etzion
IBM Research Laboratory in Haifa
Edited by K. Ramamritham. Received: February 6, 2002 / Accepted: May 20, 2003
Published online: September 30, 2003 –
Abstract. This paper presents the “situation manager”, a tool
that includes both a language and an efﬁcient runtime execu-
tion mechanism aimed at reducing the complexity of active
applications. This tool follows the observation that in many
cases there is a gap between current tools that enable one to
react to a single event (following the ECA: event-condition-
action paradigm) and the reality in which a single event may
not require any reaction; however, the reaction should be given
to patterns over the event history.
The concept of situation presented in this paper extends
the concept of composite event in its expressive power, ﬂex-
ibility, and usability. This paper motivates the work, surveys
other efforts in this area, and discusses both the language and
the execution model.
Keywords: Active technology – Active databases – High-
level languages – Composite events
In recent years, a substantial amount of work has been done
on systems that either react automatically to actual changes
(reactive systems) or to predicted changes in their environ-
ment (proactive systems). These systems perform actions or
signal alerts in response to the occurrence of events that are
signaled when changes in the environment occur (or are in-
ferred). Such systems are used in a wide spectrum of areas
and include command and control systems, active databases,
system management tools, customer relationship management
systems, and e-commerce applications.
A central issue in reactive and proactive systems is the
ability to bridge the gap between events identiﬁed by the sys-
tem and situations to which the system is required to react.
Some examples from various types of situations that need to
be handled are given in Fig. 1.
There are a variety of tools that have been constructed
to provide a work environment for event-driven applications.
The work described in this paper has been motivated by the
observation that most contemporary tools can react to the oc-
currence of a single event. In many applications (including all
• A client wishes to activate an automatic “buy or sell” program
if a security that is traded in two stock markets has a difference
of more than 5% between its values in the markets such that
the time difference between the reported values is less than
5 min (“arbitrage”).
• A customer relationship manager wishes to receive an alert if
a customer’s request was reassigned at least three times.
• A groupware user wishes to start a session when there are ten
members of the group logged into the groupware server.
• A network manager wishes to receive an alert if the probability
that the network will be overloaded in the next hour is high.
Fig. 1. Example of possible situations
the examples given above), the customer wishes to react to
the occurrence of a situation that is a semantic concept in the
customer’s domain of discourse. The syntactic equivalent of a
situation is a (possibly complex) pattern over the event history.
Thus there is a gap between application requirements and the
capabilities of the supporting tools, which results in excessive
work. This paper aims at bridging this gap and obviating the
excessive work. It should be noted that the “pattern over the
event history” may in some cases be only an approximation
of the actual situation or express the situation with some level
of uncertainty. In this paper, we have made the simpliﬁed as-
sumption of equivalence between these two terms. Some tools
and some research prototypes approach this difﬁculty by pro-
viding a mechanism for the deﬁnition of composite events that
are detected when a predicate over the event history is satis-
ﬁed. However, previous research focused on speciﬁc ﬁelds
such as active database [7,17,31] and network management
[26,30] and resulted in partial solutions that have limited ex-
pressive power and can be used only in these speciﬁc domains
by systems for which they were specially designed. More-
over, these prototypes are not able to fully express some of the
fundamental features of a situation deﬁnition:
1. The events that can participate in a situation detection
2. The context during which a situation detection is relevant