Implementation and Performance Evaluation of a Real-Time E-Brokerage
System *
Prabhudev Konana Aloysius K. Mok, Chan-Gun Lee, Honguk Woo
Department of MSIS,
The University of Texas at Austin
pkonana@mail.utexas.edu
Guangtian Liu
SBC Technology Resources, Inc.
gliu@tri.sbc.com
Abstract
Timeliness is an important attributefor e-brokerageboth
in the detection of opportunities in a narrow time window
and also in facilitating diflerentiation of end-to-end qual-
ity of service. In this paper; we demonstrate how real-time
event monitoring techniques can be applied to time-critical
e-brokerage. We start with a formal timed event model
which provides the semantics for specifying complex tim-
ing correlation rules in composite events. Theformal event
model of the system is based on RTL (Real Eme Logic)
which is important for disambiguating informal specijica-
tions when multiple instances of the same event type may
appear in a timing correlation rule involving composite
events. This leads to our design of an e-brokerage, on-line
stock monitoring & alerting system which enables users to
express their complex preferences andprovides an alert ser-
vice to users in a timely mannel: The users preferences are
monitored by a real-time event monitor In this paper; we
shall report the design of this system and some performance
data characterizing some key timing parameters. Our sys-
tem is being used by a class of MBA students in a$eld test.
1 Introduction
The e-brokerage is an important component in the rapid
proliferation of e-commerce. E-brokerage has found ap-
plication in various domains such as stock trading, travel
services, books, and auctions[23]. Whereas it is becom-
ing more important for e-brokerages to allow the customers
'This work is supported by the National Science Foundation CAREER
Award under contract No. 119-9875746
0-7695-0900-2/00 $10.00 0 2000 IEEE
Department of Computer Sciences,
The University of Texas at Austin
(mok,cglee,honguk) @cs.utexas.edu
to express their complex preferences and to process the re-
quests in a timely manner, extant e-brokerages have yet to
fully meet the timeliness requirements[ 17, 181. In partic-
ular, most of the extant e-brokerages are passive in that
it is up to the customer to access the e-brokerage site as
frequently as is needed until the customer's need is satis-
fied. For example, suppose a user wants to be notified when
the stock value of IBM decreases by at least 5%, the stock
value of Oracle increases by over 2%, and the interval be-
tween these two events is within 30 minutes; in current sys-
tems the user must keep track of the stock values manu-
ally by frequently accessing the stock information source.
There are some emerging application packages which pro-
vide more active services based on the user preferences, but
they are still limited in their capabilities. Most of these e-
brokerages rely on existing commercial databases or propri-
etary database technologies to provide the active services.
Consequently, they are limited by what these databases can
provide in terms of specifying event timing correlation pre-
cisely and they lack the flexibility for efficient real-time
monitoring by having to rely on functionalities designed for
non-time-cognizant monitoring of database states. In con-
trast, our approach is to directly interface with the stream of
real-time event data which is cached as is appropriate and
monitored in parallel to database updates.
In our design, we apply a real-time event monitor[21]
to an e-brokerage, on-line stock monitoring & alerting sys-
tem. The real-time event monitor provides the functions for
specifying/detecting the composite events. Our approach
benefits from a formal specification of timed events which
allows us to unambiguously design a unified scheme[22] for
specifying composite events. Our system enables users to
express their complex preferences, such as the above men-
tioned example, in terms of a rule that is similar to the
event-condition-action (ECA) rule pervasively supported in
109
most of active databases; unlike the untimed ECA rules,
our trading rule language has formal semantics based on
RTL, (Real Time Logic), a logic for timed events. With
the real-time event detecting functionality supported by the
real-time event monitor, our system provides an alert ser-
vice to users in a timely manner. The preferences of users
are monitored by the real-time event monitor after being
converted into the composite events. This real-time event
monitor is designed to be a middleware layer of functional-
ity between existing database systems and application pro-
grams. By unbundling the real-time functionality as a lay-
ered structure, our system can be readily extended to other
application domains of e-brokerage by redefining and im-
plementing the domain specific components[101. We have
designed and built such an e-brokerage facility for real-time
stock-trading. A field test is currently being conducted by a
class of MBA students at the University of Texas at Austin.
The rest of the paper is organized as follows. Section
2 discusses related works, section 3 gives an overview of
our system design, and section 4 discusses our implemen-
tation based on the proposed architecture. In section 5 , the
experiment environment for the performance evaluation is
described and results are presented. The final section is the
conclusion and discusses directions for future work.
2 Related works
That e-brokerage requires active and real-time function-
ality has been discussed in several related areas. The is-
sues of automatic triggering of transactions on the occur-
rence of specified event and methods dealing with temporal
data have been discussed in the active database literature
(ADB)[5, 11, 251. Issues of timely transaction processing
are discussed in related topics such as real-time databases
(RTDB)[l, 21, active and real-time databases (ARTDB)[3,
5,221 and real-time systems (RTS)[26. 16,281.
Event models to specify and to detect composite events
were discussed in [4, 18, 12, 22, 291. In [22], a uni-
fied scheme was proposed for specifying composite events
which we use in our system. Also [24] presents a Gen-
eralized Event Monitoring(GEM) language for describing
primitive and composite events. Although the schemas for
event definitions appear quite similar in most models, they
differ in their event detection mechanisms. A wide variety
of mechanisms, e.g., Petri-net [8], event graphs [20,4] and
finite state machine [ 121 have been proposed for event de-
tection. There has also been significant work in the run-time
monitoring of programs for correctness validation. For ex-
ample, [19] takes an approach similar to our work in that
they use the specification based on a formal logic and run-
time event checker, but their emphasis is on program cor-
rectness and not timed event correlation.
A number of research prototypes with active capabili-
110
ties and advanced event specificationsand detection mech-
anisms have been proposed. These include Postgres [30],
Ode [ l I], HiPAC [5], and SAMOS [7]. In addition, [4] pro-
vides a comparative study of these active databases. [ 13,9]
presents a way to estimate performance of object-oriented
active database management systems and compare several
systems such as ACOOD, NAOS, Ode, and SAMOS.Al-
though our system does not directly support transactions,
we refer to their benchmark for evaluating the performance
of our system because the common idea of measuring event
detection latency.
3 Design of E-Brokerage
3.1 Event Model
Events represent state changes of interest that may occur
in an application domain in real-time. For example, “AOL
stock price changes to 50 dollars” may be an event of inter-
est to stock investors. We adopt the event model proposed
in [20]. This event model, based on RTL (Real Time Logic)
provides rich expressiveness and eliminates semantic am-
biguities that are frequently found in other systems in the
specification of timed events where multiple instances of
the same event name may occur in a correlation pattern. We
present the event model briefly here. Refer to [20] for de-
tails.
Events are a finite set of names specified by the users
and the system. Events are recurrent. In other words, an
event may have multiple occurrences in a normal run of
the application. Events are classified as primitive or com-
posite events. Primitive events have the atomicity property
in that they cannot be broken down into any other simpler
events. They are usually pre-defined by the system. Com-
posite events consist of primitive events and other compos-
ite events connected by operators. Events may appear as the
argument in the following time functions.
3.1.1 Event Functions
Definition 1 @ ( e , i ) = the occurrence time of the ith in-
stance of event e.
Definition 2
when 0 5 t < @ ( e ,1)
t, = { k a s ( i ) when @ ( e ,i ) 5 t 5 current t i m e
(i.e. the most recent occurrence index of an event e at time
t)
Definition 3
@,(e, t , i ) = @ ( e ,# ( e , t ) +i )
(i.e. the occurrence time of the ith instance of event e from
time t )
Definition 4 Attr(e,attr, i) = the attribute value of attr
at the ith instance of event e
Definition 5 Attr,(e, attr, t , i) = Attr(e,attr, #(e, t ) + part is evaluated to true, then the action part is executed.
2)
(i.e. the attribute value of attr at the ith instance of event e
relative to time t )
Definition 6 occ(e,i) = boolean predicate which indicates
whether the ith instance of event e has occurred or not
Definition 7 maz(e,attr, il, i2) = the maximum value of
an attribute attr of event e whose occurrence indexes are
between il and 22. Also min(e, attr, il, i2) is defined simi-
larly for the minimum value.
3.1.2 Timing Constraints
We use the following syntactic form, the basic constraint, to
express a timing constraint between two events.
T 1 + D qpT2,
where D is an integer constant, op is one of (>, >), and
T1, T2 are event occurrence times denoted by occurrence
function terms.
Example 1 shows how we can express the timing con-
straint between two primitive events using the event func-
tions which we explained above. The constraint means that
the deadline of the jth instance of event e2 to occur is 10
time units after the ith occurrence of event e l .
+
Example 1 Q(e1,i) 10 2 Q ( e z , j )
More complex timing constraints can be expressed by
using basic constraints and logical operators.
Example2 (occ(Start-T,i) A Q(Start-T,i) 30 > + 3.2.3 Relational Operators
Q,(Ca"it-T, Q ( S t a r t T , i ) ,1 ) V (occ(Start-T,i) A
+
Q ( S t a r t 2 , i ) 30 > Q,(Abort-T, Q ( S t a r t 2 ,i), 1 )
Example 2 specifies that a transaction T should be either
committed or aborted within 30 time units after it is started.
We use E3( TC) to represent the event that a timing con-
straint TC is satisfied and use E,( TC) to represent the
event that a timing constraint TC is violated.
3.2 Specifying the preference
3.2.1 Event-Condition-Action(ECA)Rule
Most active database systems use the Event-Condition-
Action(ECA) paradigm to specify database triggers. The
following is the skeleton of ECA rule.
when event
if condition
then action
111
This specification enables the condition parts of rules to be
checked only on the occurrence of an event instead of by in-
efficient periodic polling of database state. If the condition
Such ECA rule is very useful in providing integrity con-
straints, trigger/alerts, and version control policies, etc.[6].
This schema is also suitable for monitoring/detecting com-
posite events with the timing constraints. In the next subsec-
tion, we present a language which is used in our real-time
event monitor to specify composite events and timing cor-
relations.
3.2.2 A unified schema for specifying composite events
In [22, 201, we proposed a unified schema for specifying
timing constraints and composite events. The following
is the format of defining a composite event in the unified
schema.
DEFINE CEVENTName
ATTRIBUTES ([name:type]{,[name:type]}' )
WHEN Timingconstraint [SATISFIEDNIOLATED]
IF Condition
THEN Action Statements;
The above specification schema supercedes the Event-
Condition-Action(ECA) rule. In EmingConstraint and
Condition, any timing constraint composed of event func-
tions can be placed. In Condition we can have other func-
tions such as SQL, pre-defined user-level functions, and
user-defined functions in addition to event functions. Con-
dition is examined only after ErningCondition is evaluated
as satisfied (or violated). The real-time event monitor[21] in
our system uses an efficient algorithm[27,28] to detect the
composite events specified in the form of the above schema.
In this section, we define Disjunction(OR), Conjunc-
tion(AND), Sequence(SEQ), and Within(1S-WITHIN) op-
erators which can be used as connectives when defining a
composite event on the relation of pre-defined events. There
may be several other ways to define these operators in our
event model. We selected the most appropriate definitions
for our stock monitoring & alerting system from the several
definitions in [20].
A disjunction event E = El OR E2 occurs when E1
occurs or E2 occurs. We can define this operator as
E1 OR E2 = E3(occ(El,i)V occ(E2,j))
A conjunction event E = E1 AND E2 occurs when two
instances of E1 and E2 occur after the previous occurrence
of this composite event. We can define this operator as
E1 A N D E2 =
E, (occ(E1,i) A 0, (Ez ,@(El,i) ,0) > 0, ( E ,@ ( E l ,i) ,0))
V ( o c c ( E ~ ,Aj )Q v ( . & , @ ( E z , j ) , O >
) @r(E,@(Ez,A,O)))
 A sequence event E = El SEQ E2 occurs when E2 occurs
provided E1 has already occurred within in some interval.
We can define this operator as
E1 SE& E2 = E,(occ(Ez,Z) Aoccr(E1,O(Ez,i),O)
AQr(E1,Q(&,Z),O) 2 Q(E2,i- 1))
A within event E = El IS-WITHIN t E2 occurs when E1
and E2 has occurred within the specified interval t. We can
define this operator as
E1 IS-WITHINt E2 = Q(E1,i) - t 5 Qr(E2,0(E1,i),0) by the TRL translator.
V Q ( & , i ) - t I Qr(El,@(Ez,i),O)
As we discussed in [22], because an event may occur multi-
ple times during a computation, applying the relational op-
erators on events instead of event instances may lead to se- Feed Server changes the message into an internal format
mantic ambiguity; there are indeed several ways to define
the relational events [20]. Because the unified schema al-
lows us to define relational operators on event instances, we the Monitor Server reports to the Stock Server. On recep-
can define them precisely and avoids ambiguity when mul-
tiple instances of the same event name occur in the same
rule.
4 E-Brokerage Implementation
We have designed and implemented an e-brokerage
package which acts as a middleware layer between an in-
formation source for stock data and the application pro-
grddatabase.
4.1 System Overview
Figure 1. System Overview
The above system in Figure 1 is expanded from the work
in [20] and maintains same three components architecture.
The client application component consists of the Stock In-
terface Applet and the Application Plug-in Adaptor. The
application server component consists of the Stock Server,
the RuleNser base, the trading rule language(TRL) trans-
lator, and the Stock Agent. The real-time event monitor
component consists of the Monitor Server and the Feed
112
Server. Actually, by replacing the client application compo-
nent with another or adding some features, we can provide
different services such as automatic buyhell on the occur-
rence of a certain event. Also, by changing the application
server component, we can create another e-brokerage such
as an automatic auction agent.
A user can input their trading rules through the Stock In-
terface Applet on the web. These trading rules are expressed
in TRL and passed to the Stock Server. Again, the rules are
changed into the set of definitions of the composite events
The Stock Server registers and subscribes the composite
events to the Monitor Server. The real-time stock quotes
are provided by the Stock Agent to the Feed Server. The
and forwards it to the Monitor Server. Whenever a sub-
scribed event instance is detected by the Monitor Server,
tion of such an event instance, the Stock Server evaluates
the conditions of the rule which corresponds to the received
composite event. If the condition part of the rule is evalu-
ated as true, then the user defined actions such as notifying
by email are executed.
All components in the system except for the Application
Plug-in Adaptor which is implemented in Delphi, are im-
plemented in Java, using JDK 1.2.1. The Stock Interface
Applet uses JFC/Swing library and the signed applet fea-
tures. To implement TRL translator and Event Compiler,
we use a lexical analyzer generator, &ex[ 151 and a parser
generator, CUP[ 141.
4.2 Client Application Component
4.2.1 Stock Interface Applet
The Stock Interface Applet is a JAVA applet which can
be downloaded from the Server’s website. This uses the
JFCISwing for graphical components and signed applet fea-
ture to communicate with the Application Plug-in Adaptor
to forward data to MS Excel on the client side. User man-
agement and rule management functions are provided in the
Stock Interface Applet. It also manages the information dis-
play and message forwarding. On the receipt of information
from the Stock Server, it displays the notification message,
current stock value, the fired rule, and the firing time, etc.
If the user selects the application plug-in option, it also for-
wards the information to the Application Plug-in Adaptor.
The screen of the Stock Interface Applet is shown in Figure
2.
4.2.2 Application Plug-in Adaptor
Whenever a rule is fired, messages are sent to the Stock
Interface Applet as well as by email. These messages can

Figure 2. Stock Interface Applet
be transferred to applications by an automation mechanism.
The Application Plug-in Adaptor can manipulate the infor-
mation so that it can be forwarded and inserted into an ap-
plication which manages a user’s portfolio and keeps track
of stock values. For example, MS Excel can be connected
to the Application Plug-in Adaptor and messages can be ac-
cumulated in Excel sheets.
4.3 Application Server Component
4.3.1 Trading Rule Language (TRL) and TRL transla-
tor
TRL is a language designed for describing the user’s
preferences in stock trading. The user can express hisher
preferences in TRL without ambiguity ranging from simple
rules which are already supported in the extant commercial
systems, e.g., “notify me whenever IBM’s price changes”
to very complex ones by composing several conditions
using the relational operators such as And, Or, Sequence,
and Within. Refer to [20] for the BNF definition of TRL. To
fix ideas, we present an example of a user’s preference, the
equivalent TRL to the stated preference, and the definitions
of the composite events transformed from the TRL. The
user can express hisher preference directly in TRL or via
the web-based Stock Interface Applet which automatically
generates the equivalent TRL. Figure 3 shows the Stock
Rule Edit Window that generates the TRL.
User’s Preference:
If DELL‘S price increases by 10% in any 1 hour interval,
IBM’s price decreases by 20% in any 30 minutes interval,
and they occur within 50 minutes then notify me by an
email.
Corresponding TRL:
113
When (DELL.price increases by 10% within 1 hour
is-within 50 minutes 1BM.price decreases by 20% within
30 minutes )
if true
then send “Alert! DELL increased by lo%, IBM decreased
by 20%” to user@aol.com
Corresponding composite events:
DEFINE CEVENT CE 1
ATTRIBUTES ([“OccurrenceTime” : time])
WHEN occ(DELL,i)SATISFIED
IF pred(IncreaseP,“DELL”,”price”,O.1,3600000.0,”DELL”)
THEN “OccurrenceTime” := @(DELL,i);
DEFINE CEVENT CE2
ATTRIBUTES ([“OccurrenceTime” : time])
WHEN occ(IBM,i) SATISFIED
IF pred(DecreaseP,”IBM’,“price”,O.2,l8OOOOO.O,“IBM’)
THEN “Occurrence Time” := @(IBM,i);
DEFINE CEVENT CE3
A’ITRIBUTES ([“OccurrenceTime” : time])
WHEN
@(CEl,i)+ 3000000 2 Qr(CE2,@(CEl,i),l)OR
@(CEl,i)- 3000000 5 Qr(CE2,@(CEl,i),0)SATISFIED
IF true THEN { ;};
To demonstrate the importance of having a formal se-
mantics, notice that we have an assignment of the Occur-
rence Time in CEl’ and CE2 but not in CE3. If we do
not explicitly specify the Occurrence Time in the definition
of CE3, the detection time would be assigned to the Oc-
currence Time of the event by default. There may exist a
delay between the arrival time of primitive events such as
DELL and the detection time of CE1. If we do not assign
the arrival time of DELL to the occurrence time of CE1, the
timing condition statements in CE3 may be incorrect.
4.3.2 Stock Server
The Stock Server accepts the user-defined rules in TRL
from the Stock Interface Applet. These rules are checked
syntactically and semantically before being further pro-
cessed. The Stock Server transforms the received rules
into the definitions of the generated composite events by
invoking the TRL translator. The composite event defini-
tions are registered and subscribed to the Monitor Server by
the register/subscription interface. The subscribing proce-
dure enables the Stock Server to receive a notification from
the Monitor Server when the registered composite event has
occurred. The pairs (a rule in TRL, composite events) are
stored in the Rule Base. The Event Subscriber, which is
a component of the Stock Server, implements event regis-
tering, subscribing, and receiving interfaces. When an de-
tected event instance arrives at the receiving interface, the
‘The composite event names are generated by the TRL translator

Figure 3. Rule Edit Window
corresponding rule is retrieved and evaluated against the
condition in the rule. If the evaluation returns true, the Stock
Server performs the appropriate action (e.g. sending email
or notification to the Stock Interface Applet) of the rule.
To prevent receiving automatic email notification too fre-
quently, the user can specify the minimum interval between
successive emails for each rule and the maximum number
of emails per day.
4.3.3 RulelUser Base
Rule/User Base is a repository for storing the rules and users
information. Upon request from the Stock Server, it per-
forms the functions of insert, delete, edit, or retrieve rules.
The Stock Agent processes stock symbols entered by the
user such that the specified stock information will be gath-
ered.
4.3.4 Stock Agent
In order to simulate an environment which uses real stock
quotes, we conduct some experiments with openly available
stock price information from a website. The Stock Agent
visits the site, keeps track of changes made on relevant stock
data, gathers, and send the data to the Feed Server. It also
controls several parameters such as gatherindsending rates
and stock symbols which can have an impact on the perfor-
mance. The number of event types and occurrences are han-
dled by these parameters for our performance experiments.
To consider the performance of pulling Web data from a fi-
nancial information site, the Stock Agent maintains updated
data and has uses proxy which replies to requests from the
Feed Server in a timely manner.
114
4.4 Real-time Event Monitor Component
4.4.1 Monitor Server
I I
I*[ R d - t i m e Evmu
Figure 4. Monitor Server
Figure 4 shows three subsystems of the Monitor Server
developed in [21, 201. The Subscription Server receives
the definitions of the primitivekomposite events and the
subscription requests from the Stock Server. In addition,
the primitive event instances sent by the Feed Server are
received by the Subscription Server. Only the subscribed
events are notified to the Stock Server.
The Event Compiler transforms the event definitions to
the internal graph-based structures and passes them to the
Event Monitor. The condition and attribute assignment in
the composite events are represented in the syntax tree. The
timing conditions are represented in the constraint trees by
using the compilation algorithm discussed in [28].
The Event Monitor detects the composite events by
checking the compiled events against the incoming data
stream of primitive events from the Feed Server and the
composite events already generated. When a composite
event is detected, the event monitor transmits the detected
event instance to the Subscription Server which again for-
wards it to the Stock Server. The internal structure of the
Event Monitor is shown in Figure 5 .
4.4.2 Feed Server
At run time, the Monitor Server accepts real-time stock data
from the Feed Server with each tick modeled as an event in-
stance. These real-time stock data are pulled by the Stock
Agent and manipulated to include occurrence times, open
price, high prices, current prices, and volumes. Multiple
Feed Servers can coordinate to feed the manipulated mes-
sages into the Monitor Server.
5 Performance Evaluation
To evaluate the performance of our system, several ex-
periments were conducted. Because we want our evaluation
to be realistic, we enlisted MBA students from a class at the
University of Texas at Austin to use our system in a con-
trolled environment with real stock quotes. During this ex-
periment, we collected feedback from participants and con-
structed a template rule set for further experiments. Since
there is as yet a standard performance evaluation benchmark
for real-time data monitoring, even for the active database
area [9], we rely on and extend the performance evaluation
criteria discussed in [ 131to fit our problem domain. Our pri-
mary interests are to verify the correctness of event specifi-
cation and detection and to evaluate the delays in the detec-
tion of composite events. The detection latencies were eval-
uated under various numbers of rules and event arrival rates.
We also evaluated individual subsystem delays which make
up the total detection latency. We used the trading rules sub-
mitted by the MBA participants to generate domain-specific
large rule sets, and we used stock quotes in real-time for re-
alistic testing.
5.1 Performance measure
The basic performance metric for evaluation is the delay
in detecting composite events. Based on the real-time event
monitor shown in Figure 5 , the total detection latency is the
sum of the four delays which are defined in [20].
0 D, - the component event message transmission delay
between the Feed Server and the Monitor Server.
0 D, - the delay before a component event instance is
placed in the queue for concurrency control.
0 D, - the queuing delay before a component event in-
stance is ready to be processed.
0 D, - the event processing time.
The composite event detection latency D = D, + D,+
D, + D,.
Figure 5. Event Monitor
115
5.2 Experimental setup
The system was run on an Sun Ultra 5 workstation with
360MHz UltraSparc CPU and 128M memory, running So-
lark 8. We used the socket utilities in the java.net to trans-
mit event messages from the Feed Server to the Monitor
Server. All packages were written in JDK version 1.2.1.
Two issues are critical to the experiments - the genera-
tion of valid rule sets, and the generation of event streams
that affect the rule sets. Rules were generated with various
types of events: simple events and composite events. We
selected 74 companies* and defined primitive events with
the attributes occurrence time, open price, high price, low
price, current price and volume. Composite events were
generated based on how composite events are syntactically
formed. We used operators -disjunction, conjunction, se-
quence, and within - on two simple events to form a com-
posite event.
The rule generating program allows us to specify the
number of rules to generate, and the proportion of rules re-
lated to a particular primitive event. It can also control the
ratio of fired rules in a rule set depending on current stock
values, The program randomly generates rules by modi-
fying the stock symbols and adjusting conditions of a pre-
defined composite rule in the template rule set. The Feed
Server was programmed to generate related events with the
attribute values in real-time. The event arrival rate can be
controlled by the Stock Agent and the Feed Server. An
event for each symbol was fed every 60 seconds for ex-
periments, so the event arrival rate was held as constant
except during the experiment for assessing the impact of
the event arrival rate. We conducted experiments related to
three performance critical aspects: number of rules, event
arrival rate, and ratio of fired rules.
The Monitor Server is programmed to capture the aver-
age and maximum values of D,,D,,D,,D, and D. The
Stock Server can also measure time duration of each fired
rule between event occurrence time and finishing action
time in the Stock Server. This includes detection latency
and action execution time.
5.3 Experimental results
5.3.1 Impact of rule base size and ratio of fired rules
This experiment was to study the effect of increasing the
number of rules. Figure 6 shows the average detection la-
tency for this experiment. The X-axis represents the Rule
Base size and the Y-axis represents the time in milliseconds.
The experiments were run for various Rule Base size from
100 to 500. As expected, the number of rules has an impact
2These companies were chosen by MBA students while they were par-
ticipating in our field test
 1400 1400
1200 1200
1000 lo00
800 aoo
600 600
400 400
200 200
0 0
100 200 300 400 500 100 200 300 400 500
Rule Base size(ratio of fired rules=l .O) Rule Base size(ratto of fired rules=0.5)

Figure 6. Detection latency vs. Rule Base size

1200 DC -t--
lo00
800
600
400
200
0
0 0.25 0.5 0.75 1
Ratio of fired rules(Rule Base size=500)

Figure 7. Detection latency vs. ratio of fired rules

on the detection latency. In addition, we can notice the de- loo00 I I I I I I

tection latency of the Rule Base with high ratio of fired rules
increases rapidly since large number of component events3
can increase the number of composite events created by the
Monitor Server and subsequently the number of events in
the waiting queue of the Event Monitor. In addition to this
experiment, by increasing the ratio of fired rules from 0.25
to 1 when the Rule Base size is 500, we can notice that the
detection latency is affected by the number of fired rules
but the number of rules which are not fired is not critical in
performance aspects. Figure 7 shows the average detection Figure 8. Detection latency vs. Event arrival
latency for various ratio of fired rules. The X-axis of the rate
graph on the left represents the number of rules. The X-axis
of the right graph represents the ratio of fired rules. The
Y-axis represents the time in milliseconds in both graphs.
event arrival rate and causes the queuing delays to increase
dramatically.
5.3.2 Impact of Event arrival rate
Figure 8 shows the effect on the detection latency depend- 5.3.3 Execution Delay
ing on various event arrival rates. The number of events and
A series of experiments were repeated for rule sets with the
Rule Base size for every tests was held constant at 17648
different number of rules to find the impact of Rule Base
and 500 respectively to avoid effects by other performance
size on including execution delays. Besides detection laten-
factors. In this figure, the X-axis represents the number of
cies of the Monitor Server, significant delays can be caused
feed event per a minute. The result shows that the detec-
by the Stock Server which provides the services to execute
tion latency D is about lOOOms up to the point when the
actions for fired rules. These experiments for execution de-
event processing capacity cannot meet the demand of the
~~ ~
lays were almost the same as those for assessing the impact
'We call the event, which is used as an operand in defining a composite of Rule Base size except that these included delays in the
event A, a component event of A Stock Server and between servers after triggering a com-

116

100 290 3.00 400 500
Rule Base size(ratio of fired rules=0.5)
Figure 9. Overall delay
posite event in the Monitor Server. Figure 9 shows that as
expected, the overall performance degrades as the number
of rules increases. The execution delays are affected not
only by the number of fired rules but also by the imple-
mentation details of the notification services provided by
the Stock Server.
Because of a lack of comparative benchmark data, we
did not compare the performance of our system with that of
other event models. Our experiments did allow us to make
several observations. In all cases, the Monitor Server speci-
fies and detects composite events correctly with various sets
of composite events. The detection latency for the experi-
ments seemed acceptable to the MBA participants. As ex-
pected, it was dependent on the number of composite events
created in the Monitor Server; performance limit was deter-
mined by Rule Base size and event arrival rate because they
affect the number of composite events created in the Moni-
tor Server. Execution delay also has the same limits except
that it is more critically impacted by the implementation of
triggering actions in the Stock Server.
The critical issue is the scalability of the Event Moni-
tor. In order to improve scalability, queuing delays must be
reduced by balancing the event arrivals and the processing
time of events. The event processing time can be improved
by sharing events among different rules whereby the event
checking occurs only once. Another method to improve
scalability is to partition the composite events into mutu-
ally exclusive sets where each composite event has its own
composite event detector running in parallel with other sets
on multiple processors. There is nothing inherent in our
architecture to prevent us from performing these optimiza-
tions. This may not be the case in other approaches that rely
on the functionality of active databases which treat the ECA
rules independently of one another.
6 Conclusion and Future Work
We presented the design and performance evaluation of
an e-brokerage package for implementing a real-time stock
monitoring & alerting system. This system is being field
117
tested by MBA students at the University of Texas at Austin.
Unlike extant approaches, our system has as its semantic
basis a formal timed event model based on the logic RTL
(Real Time Logic); this allows us to unambiguously define
complex timed event correlation patterns where multiple in-
stances of the same event name may occur. We also made
use of efficient detection algorithms for monitoring the sat-
isfaction of composite events specified in a unified schema
for ECA-like rules.
We built the system by integrating three loosely coupled
components - the client application, the application server,
and the real-time event monitor. This separation provides
the unbundling which enables client-server computing and
interoperability. We expect each of these components to be
easily integratable with any domain-specific system.
A number of performance experiments were carried out
using stock data in real time. We evaluated the latency of
the Monitor Server with respect to various parameters such
as Rule Base size, fired rule ratio, and event arrival rate.
While fast processing speed is of value, a more meaningful
goal for real-time guarantees is that of identifying the proper
limits of the parameters (e.g. feed rate and Rule Base size)
that may drive the system into saturation and thereby pre-
vent the system from providing real-time service to users.
The field test by MBA students has helped us to validate the
correctness of the system and gave us valuable feedback.
We believe that a system such as our real-time stock
monitoring & alerting package is an important component
in the larger picture of e-commerce. The current situation
is a chicken-and-eggs problem in that economic efficiency
requires that the timeliness of market information be priced
and this in turn requires differentiated end-to-end qualities
of service which is currently not supported on the Internet.
Our real-time Monitor Server is a component of this chain
in providing guaranteed quality of service: timeliness in in-
formation access and in taking action. To the individual
user, in this case our MBA student participants, the bottom
line is of course the financial returns that timely (not only
fast) recognition of market condition may provide. While
it is too early to draw firm conclusions, we have received
suggestions about how our system can be used to gain com-
petitive advantages.
Now that we have the basic machinery in place, there are
many avenues to extend this research in the larger context
of investigating what it means to provide real-time services
over the Internet. Possible future work includes techniques
and experiments in scaling up, such as exploiting the se-
mantics of composite events to facilitate event sharing and
parallel execution of event detection. The former exploits
redundancy/similarity properties between rules, the latter
exploits exclusivity properties between rules.
References
[l] R. Abbott and H. Garcia-Molina. Scheduling Real-Time
Transactions: Performance Evaluation. ACM Transactions
on Database Systems, 17(3):513-560, September 1992.
[2] A. Bestavros. Advances in Real-time Database Systems Re-
search. ACM SIGMOD RECORD, 25(1):3-7, March 1996.
[3] H. Branding and A. P. Buchman. On providing soft and hard
real-time capabilities in an active DBMS. In Proc. of the
International Workshop on Active and Real-time Database
Systems, 1995.
[4] S. Chakravarthy and D. Mishra. Snoop: An Expressive
Event Specification Language for Active Databases. Data
and Knowledge Engineering, 14(1): 1-26,October 1994.
[5] U. Dayal, B. Blaustein, and et al. The HiPAC Project: Com-
bining Active Databases and Timing Constraints. ACMSIG-
MOD RECORD, 17(1):51-70, March 1988.
[6] U. Dayal, E. N. Hanson, and J. Widom. Active Database
Systems. In Modem Database Systems: The Object
Model, Interoperability, and Beyond, Massachusetts, 1994.
Addison-Wesley.
[7] S . Gatziu and K. R. Dittrich. SAMOS: An active, Object-
Oriented Database System. IEEE Quaterly Bulletin on Data
Engineering, 15( 1):23-26, 1992.
[8] S . Gatziu, A. Geppert, and K. Dittrich. Detecting Composite
Events in Active Database Systems Using Petri Nets. In
Pmc. of the 4th International Workshop on Research Issues
in Data Engineering, pages 2-9,Feburary 1994.
[9] S . Gatziu, A. Geppert, and K. R. Dittrich. A Designer’s
Benchmark for Active Database Management Systems: 007.
In Proc. of the Workshop on Rules in Databases (RIDS),
pages 309-326,September 1994.
[lo] S . Gatziu, A. Koschel, G. V. Bultzingsloewen, and
H.Fritschi. Unbundiling Active Functionality. ACM SIG-
MOD RECORD, 27(1):354, March 1998.
[11) N. H. Gehani and H. Jagadish. Ode as an Active Database:
Constraints and Triggers. In Proc. of the International Con-
ference on Very Large Data Bases(VLDB), September 1991.
[12] N. H. Gehani, H. Jagadish, and 0. Shmueli. Composite
Event Specification in Active Databases: Model and Imple-
mentation. In Proc. of the International Conference on Very
Large Data Bases( VLDB), pages 327-338,August 1992.
[13] A. Geppert, M. Bemdtsson, D. Lieuwen, and C. Roncan-
cio. Performance Evaluation of Object-Oriented Active
Database Management Systems Using the BEAST Bench-
mark. Theory and Practices of Object Systems(TAPOS),
4(4), October 1998.
[14] http://www.cs.princeton.edu/%7Eappel/modern/java/CUP/.
[ 151 http://www.cs.princeton.ed11/%7Eappel/modern/java/JLex/.
1161 E Jahanian and A. Goyal. A Formalism for Monitoring
Real-Time Constraints at Runtime. In Proc. of the IEEE
Fault-Tolerant Computing Symposium, pages 148-155,June
1990.
[I71 P. Konana, J. R. Durrett, G. Liu, A. K. Mok, and A. B. Whin-
ston. Design of Time Cognizant Electronic Brokerages. In
Proc. of the INFORMS Conference on Information Systems
and Technology,April 1998.
118
[18] P. Konana, G. Liu, Y. Liu, , and A. Mok. Timeliness in
Electronic Commerce: Issues in Brokerage Design. In Proc.
of the International Conference on Telecommunicationsand
Electronic Commerce (ICTEC), pages 20-22, November
1998.
[19] I. Lee, S . Kannan, M. Kim, 0. Sokolsky, and
M. Viswanathan. Runtime Assurance Based On For-
mal Specifications. In Proc. of the Intemational Conference
on Parallel and Distributed Processing Techniques and
Applications (PDPTA),July 1999.
[20] G. Liu. An Event Service Architecture in Distributed Real-
Time Systems. PhD thesis, Department of Computer Sci-
ences, The University of Texas at Austin, 1999.
[21] G. Liu and A. K. Mok. Implementation of JEM - A Java
Composite Event Package. Technical report, Real-Time Sys-
tem Laboratory, Computer Science Department, University
of Texas at Austin, November 1998.
[22] G. Liu, A. K. Mok, and P. Konana. A Unified Approach
for Specifying Timing Constraints and Composite Events in
Active Real-Time Database Systems. In Proc. of Real-Time
Technology and Applications Symposium(RTAS), June 1998.
[23] P. Maes, R. H. Guttman, and A. G. Moukas. Agents that Buy
and Sell: Transforming Commerce as we Know It. ACM
SIGMOD RECORD, 42(3):81,March 1999.
[24] M. Mansouri-Samani and M. Sloman. GEM: A Gen-
eralized Event Monitoring Language for Distributed Sys-
tems. IEWIOP/BCS Distributed Systems Engineering Jour-
nal, 4(2),June 1997.
[25] D. McCarthy and U. Dayal. The Architecture of an active
data base management system. In Proc. of the ACM SIG-
MOD International Conference on Management of Data,
pages 215-224, 1989.
[26] A.Mok. A Graph-Based Computation Model for Real-Time
Systems. In IEEE Parallel Processing, pages 619-623,Au-
gust 1985.
[27] A. K.Mok and G. Liu. Early Detection of Timing Constraint
Violation at Runtime. In Proc. of IEEE Real-Time Systems
Symposium(RTSS), December 1997.
[28] A. K. Mok and G. Liu. Efficient Runtime Monitoring of
Timing Constraints. In Proc. of Real-Time Technology and
Applications Symposiwn(RTAS), 1997.
[29] A. K. Patankar and A. Segev. An Architecture and Construc-
tion of a Business Event Manager. In Temporal Database:
Research and Practice, LRcture Notes in Computer Science,
pages 257-280. Springer Verlag, 1998.
[30] M. Stonebraker and L. A. Rowe. The Postgres Pa-
pers.Technical Report UCB/ERL M86/85. Technical report,
Department of Electrical Engineering and Computer Sci-
ence, The University of Califomia at Berkeley, 1987.