2013 International Conference on Recent Trends in Information Technology (ICRTIT)
Dynamic Complex Event Processing – Adaptive
Rule Engine
Bhargavi R, Ravi Pathak, Vaidehi V
Department of Information Technology,
Madras Institute of Technology, Anna University
bhargaviren@gamil.com, pathak.ravi1989@gmail.com, vaidehivijay@gmail.com
Abstract — Recently Complex Event Processing has emerged as
a lightweight way to monitor multiple data streams to identify
events or patterns of interest. Complex Event Processing is a rule
based technology. Rules which represent the patterns of interest
are defined by domain experts. Existing CEP engines have
limitation on addition, deletion and modification of rules. Rules
are configured initially once and are not changed later. Some of
the engines support initial configuration and occasionally support
addition of rules at runtime using the polling mechanism. This
paper proposes a dynamic CEP by making the rule engine
adaptive by using Event driven or push based approach for
updating the rules dynamically in the Complex Event Processing
System at runtime. Event driven approach facilitates
Knowledgebase to update rules without polling or observing any
resource and hence enhances the system performance. The
resulting CEP engine with dynamic infrastructure facilitates easy
addition and deletion of the rules in an easy and efficient way.
Index Terms— Complex Event Processing, Event Driven
Architecture, Rule Based Expert System, Knowledgebase, data
streams.
I. INTRODUCTION
Many of the distributed applications require continuous
monitoring and processing of information or data in a timely
fashion as it flows from periphery to the system. Intrusion
detection in surveillance, detection of fraudulent credit card
usage, stock market analysis, healthcare monitoring are few
such applications. The key requirements of all these
applications are - early identification of an event or situation
of interest and quick response generation. Complex Event
Processing Technology is being used recently to address the
requirements of such time critical applications. Complex event
processing not only perform traditional database and data
mining processes such as data validation, cleaning, enrichment
and analysis, but can also query, filter and transform data from
multiple sensors to enable events to be detected in real time.
They provide the ability to automate pattern monitoring,
which allows events to be correlated so that event response
mechanisms can be developed and critical events can be
isolated so that efficient remediation can be taken. Recently,
CEP is used in several monitoring solutions like analyze stock
markets, search for fraudulent use of credit cards or mobile
phones and perform forecasting in traffic networks or power
grids [11] – [14]. CEP infrastructure consists of three main
components: a set of event sources, a set of event processing
ISBN:978-1-4799-1024-3/13/$31.00 ©2013 IEEE 189
agents (EPA) and a set of event sinks or event listeners. Event
Processing Agents are continuous queries or signatures of
patterns which perform CEP tasks like filtering, aggregating
and correlating events or searching for event patterns. EPAs
interface with event sources, event listeners and some times
other EPAs. The implementation of any CEP application
consists of three steps: First, all the event sources are
registered at the system, next all EPAs are defined on the
event sources and finally, event listeners are registered and
attached or connected to the corresponding EPAs. Once a CEP
application has been deployed and started, no changes in the
event sources or listeners or EPAs are expected. Based on this
most of the existing CEP engines have limitation on addition
or modification of rules. Rules are configured initially once
and are not changed later. In CEP reasoning is done using a
reactive EPAs/rule-based inference engine designed to deal
with a continuous stream of real-time event objects. Rules are
defined by domain experts. The system is initially configured
with all the rules which define the complex events or patterns
to be identified and alerted. These domain experts need to
provide the set of basic events which serves as input to the
rule, their interrelationships, and the parameters of the events
that determine the complex event. Providing all the required
details is a hard task, even for experts. In addition, rules may
change over time, due to the dynamic nature of the
application. This paper proposes improvements to CEP
technology by making changes to behavior of the
infrastructure dynamic. The proposed dynamic rule updation
addresses the above mentioned issue.
The core of CEP engine is a rule based Expert System
which is also widely used for decision making in Artificial
Intelligent systems. From the most popular expert systems
DENDRAL [18] and MYCIN [19] to the present days
Business Rule Management System rule based expert system
are still marking their excellence. The major challenges in
Rule based Expert Systems are Knowledge Representations,
Knowledge, Facts and Rules or Policies Management. In this
paper we are proposing an event driven solution to dynamic
rule updating in Rule based Expert system.
Rest of the paper is organized as follows: Section II gives
the related study. Section III explains the proposed model.
Section IV gives the implementation details. Performance of
the proposed method is discussed in Section V and Section VI
has the conclusion.
 2013 International Conference on Recent Trends in Information Technology (ICRTIT)
II. RELATED WORK
This section discusses some of the works in the related area.
Turchin et al [10] have presented a model and a mechanism
for automatically deriving rule parameters. Their model
provides a one-time parameter derivation mechanism as well
as a continuous adjustment of parameters based on a correct-
predict paradigm and involves a continuous adjustment to
parameters using machine learning techniques. Their approach
follows that of Kalman estimators, modified to take into
account indirect, rather than direct feedback. This is like
domain experts provide feedback on the accuracy of event
materialization, rather than on the parameter values
themselves.
Paschke et al [9] have proposed a logic-based homogenous
reaction rule language and a rule and event-based middleware
called RuleML which combine technologies from declarative
rule-based programming with enterprise application
technologies for CEP and SOC. The authors have defined
interval-based event algebra with event definition, event
selection and event consumption. They also proposed a
homogenously integrated event messaging reaction rule
language, called Prova AA. But the proposed work does not
support dynamic addition or update of rules.
Bastian et al [15] have proposed anomaly management
using Complex Event Processing. Authors have discussed the
need for a dynamic CEP with several applications. They
proposed a framework for CEP infrastructure to support
dynamism by incorporating anomaly identification. However
the work does not throw any light on rule management.
Most of the existing CEP systems are based on event driven
architecture and they use Stream Processing engines and
database system to support continuous querying, pattern
recognition and response generation in near real time. Esper
[16] uses EsperJMX[21] for runtime management of Esper
CEP; In Esper[2] on Demand Query/rule facility provides for
ad-hoc execution of an EPL expression, but it has some
limitations like it cannot perform sub queries, some clauses
are not allowed in there expressions, and if it has to remain it
need to be executed explicitly all the time. Drools [17] use
Drools Guvnor[20] for multiuser management of rules in
Drools. Internally Drools uses Knowledge Agents [1] which
uses polling mechanism to support dynamic rules/queries at
runtime. The existing CEP engines support initial
configuration and occasionally support addition of rules at
regular intervals of time using the polling mechanism. From
the literature survey it can be observed that there are several
applications [15] which demand dynamic rule engine to
support adaptability. This paper proposes improvements to
CEP technology by making changes to behavior of the
infrastructure dynamic. The proposed methodology uses Event
driven or pull based approach for updating the rules
dynamically at runtime. Event driven approach facilitates
Knowledgebase to update rules without polling or observing
any resource and hence enhances the system performance. The
resulting CEP engine with pull based architecture for dynamic
rule updation at runtime facilitates easy addition, deletion and
modification of the rules in an easy and efficient way.
190
III. PROPOSED DYNAMIC CEP RULE ENGINE
CEP technology characterized by rule based detection
paradigm and hence static. In any CEP application all the
events of interest are analyzed, selected and added to the
system by a domain expert. All these events are then
formulated as rules which are a combination of patterns or
logical, relational or spatio-temporal relationships among the
input data and action to be taken on the occurrence of event of
interest. Initially rule engine or the expert system
preconfigured with all the rules that need to be matched
against the input data streams. Once the rules are defined and
configured the system freezes i.e. rules can not be added
dynamically at run rime. But there several applications in
which new rules need to be added to the system after
deploying the system for some time (hours, weeks, months,
years). For example suppose Medical diagnosing system like
MYCIN is initially configured for identifying Cold, Cough
and Fever. At a later point in time the system may need to
identify cases of pneumonia also. Then arises the need to add
new rules in knowledge base to make the rule engine to
identify pneumonia.
There are two approaches to dynamically update the rule
base at run time with out stopping or restarting the system
1. First approach is to poll a resource (directory or
URL) at regular intervals of time to check if new
rules need to be added, if needed then create new
processing agents and add to inference engine and
interface them with the corresponding input streams
and output listeners.
2. Second approach is event driven approach in which
the system gets notified whenever a new rule is to be
added and then update the rule base by creating and
adding new processing agents to inference engine and
interfacing them with the corresponding input
streams and output listeners.
The second approach/ Proposed approach is more efficient as
system is notified whenever there is a need to update the rule
base rather than polling the resource again and again.
Figure. 1 General architecture of Rule Engine
 2013 International Conference on Recent Trends in Information Technology (ICRTIT)

The architecture of a rule engine is shown in Figure 1.In the

following paragraph various components of the rule engine are Figure 2 shows the proposed dynamic rule engine
explained. architecture based on event driven approach.
Expert: An Expert is a domain knowledge person whose
knowledge is used to frame up rules or policies to reason the
inputs.
Rule: A rule is a prescribed method for processing the input
data/ events. Any event of interest or situation of interest is
represented as a rule. These rules are basically domain specific
rules which require expert domain knowledge. A rule is
expressed in the form of
Rule “Rule identifier”
When
(conditions)
Then
(Actions)
end Figure 2 . Proposed Event Driven Architecture for dynamic Rule Updating

Condition can be simple logical, relation or spatiotemporal
relations across different events. An action is any reactive
action like sending SMS/email, or sending an alert etc, to be
taken on the occurrence of event of interest.
Knowledge Base: Knowledge base is the repository of all the
knowledge of the application. Knowledge base contains rules
or policies to be applied on the inputs coming from different
sources for its applicability, processes, functions and type
models.
Working Memory: Working Memory is the short term memory
which keeps recent data for querying and processing the input
data with respect to temporal data.
Inference Engine: Inference Engine is the reasoning module. It
has the functional units corresponding to all the rules. These
functional or processing modules are called as processing
agents. Each processing agent is associated with one or more
input streams and a sink or listener. Matching of the input data
or facts against the rules stored in the knowledge is done by
inference engine. Working memory is used by the inference
engine for storing the required data. The engine executes by
performing the following match-resolve-act cycle.
• Match: In this first phase, the conditions of all rules
are matched against the data in the working memory.
As a result a conflict set is obtained, which consists of
objects of all satisfied rules.
• Conflict-Resolution: In this second phase, one of the
rule objects in the conflict set is chosen for execution.
If no rules are satisfied, the engine waits for next input
from user.
• Act: In this third phase, the actions of the rules
selected in the conflict-resolution phase are executed.
These actions may change the contents of working
memory. At the end of this phase, execution returns to
the first phase.
User Interface: User Interface is a GUI (Graphical User
Interface) for the user is to interact with the system giving
inputs to the system and getting the experts decision as output.
Following are the functions of the proposed components:
Expert Interface: It is a user interface which interacts with
experts and Knowledge Engineer to create new rules. Rules
are entered in the specific format.
Update Event Source: Update event source is responsible for
generating the knowledge update event. This module lies in
between Expert Interface and Knowledge Listener.
Knowledge Event: Knowledge Event is an event object
instance. Knowledge event triggers the Knowledge Base
update.
Knowledge Listener: The Knowledge Base acts like a
Knowledge Listener interface. It listens to the Knowledge
event, and updates the Knowledge Base. This module uses the
rules given by the expert in the Expert Interface and creates a
knowledge package instance and adds it to the knowledge
Base. Thus the rule base is updated dynamically.
Steps for dynamic rule updating:
1. Enter and submit the new rules to be added in the
Expert Interface.
2. Generate Knowledge Event instance. Knowledge event
instance has all the needed information for creating the
new rule.
3. Knowledge Lister gets notified on the Knowledge
event occurrence.
4. Create knowledge package with the information
collected from the Knowledge event.
5. Add the knowledge package to the Knowledge base.
6. Knowledge base is updated with the new rules as
added knowledge package.
The proposed architecture for the rule engine is highly
scalable. Consider big enterprises where huge streams of input
data generated every second and there are several rules to be
executed. A distributed CEP system with multiple CEP rule
engines with each rule engine working with a subset of rules

191
 2013 International Conference on Recent Trends in Information Technology (ICRTIT)
can be used to get better performance. In such a scenario there
may be a subset of rule engines working with different
knowledge bases and a subset of rule engines with multiple
replicas of the same knowledge base.
The proposed Event driven dynamic rule engine can be
easily scaled to update several knowledge or rule bases
simultaneously in the above mentioned distributed
environment. Following are the steps involved in the process:
1. All Knowledge Listeners gets registered to registry at
Knowledge Source.
2. Knowledge Source gets the list of all Knowledge
Listeners by querying its registry.
3. Whenever Expert defines rules on the Expert Interface
and submits the rules Knowledge Event is generated.
4. The knowledge event notifies all the Knowledge
Listeners and there rule bases are updated
simultaneously.
Figure.3 .Distributed Architecture for Rule Updating
Figure 3 shows the architecture of the distributed dynamic
CEP system
IV. IMPLEMENTATION
The proposed event driven dynamic CEP engine is
implemented in Java. Java based JBoss Drools CEP engine is
taken as the core CEP engine and the existing APIs are
extended to implement the event driven dynamic CEP engine.
The following modules have been introduced to support event
driven rule updates.
1. Knowledge Update Listener: It is a new added interface
and it is implemented by all the classes which will have
Knowledge Base.
2. Knowledge Event: This is a new added class. The
knowledge event object contains precompiled rules which
192
are send to Knowledge Listener and later gets added to
the Knowledgebase.
3. User Interface for adding dynamic rules: To support user
friendliness, a user interface is provided using which
users/experts browse, add and compile the new rules
before being added to the knowledge base.
V. EXPERIMENTAL SETUP AND VALIDATION
The proposed event driven dynamic rule engine is validated
with tele-healthcare monitoring application.
Figure. 4. Architecture of sample Application
The application is developed to monitor the status of health
condition which is indicated by the abnormalities in vital
parameters of a person. The vital parameters like BP, heart
rate, pulse rate, spo2 etc are measured using wearable
physiological sensors. The data generated by the sensors is
transmitted to a server where the proposed event driven
dynamic rule engine is running. Initially the knowledge base
of the rule engine is configured to detect the abnormalities in
BP and heart rate. When the data from the sensors arrive at the
rule engine it checks the data against the existing rules. When
the doctor finds that pulse rate and spo2 also need to monitored
continuously or some other patterns among the vital
parameters need to be added then the rules are added easily
using the Interface provided and whenever the newly added
rules get matched alerts are generated.
VI. PERFORMANCE
Performance of the proposed dynamic rule engine can be
analyzed from two angles.
Based on computational time:
Any rule engine which uses polling technique for rule
additions and updates runs a thread which polls the resources
at regular intervals of time to check if any updates are
required. During the polling process Knowledge update takes
place if rule updates are requested by the user. Proposed push
 2013 International Conference on Recent Trends in Information Technology (ICRTIT)
based or event driven based approach does not require regular
polling and knowledge update takes place only when there is a
rule update request. Let ‘n’ be no of times the system polls the
resources in a given time T. Let t1be the time taken for each
polling process and t2 be time taken to update the knowledge.
Suppose that update requests exist only ‘m’ times in the total
time T. Time taken for the total rule updates incase of polling
based rule engine and proposed push based rule engine can be
computed as follows.
Polling based rule engine:
Total time taken = (n-m)*t1 + m*(t1+t2) (1)
Proposed event driven based rule engine:
Total time taken = m*t2 (2)
Therefore the difference in total time for rule updates is given
by
Time Difference =n*t1 (3)
So, Push based techniques is n*t1 times efficient than Pull
based technique.
Based on knowledge update waiting time:
In polling based system if the polling interval is too large
then the knowledge updates happen very late and the impact
of the rule updates can be seen very late. This problem can be
overcome by making the polling interval small. But, this
causes more polling overhead as seen above. Consider a
simple scenario shown in Table 1. Knowledge event
Occurrence column indicates the time instance at which the
knowledge update events are generated.
Sl No Knowledge Event
Occurrence (sec)
1 3
2 10
3 18
4 20
5 23
6 27
Table 1
As the knowledge base update time is the same in both the
cases i.e. polling based and Push based only the waiting time
is considered for analysis. Average waiting time for
knowledge base update in a Polling based system with a
polling interval of 5 seconds can be computed as follows:
WT1 = (5-3) =2 sec
WT2 = (10-10) = 0sec
WT3 = (20-18) = 2sec
WT4 = (20-20) = 0 sec
WT5 = (25-23) = 2 sec
WT6 = (30-27) =3 sec
Average waiting time: = 2+0+2+0+2+3/6= 1.5sec
193
Push based system:
It is assumed that time taken to update knowledge base=0 sec
i.e. as new rules are written it gets added instantaneously to
the system.
Therefore,
WT1 = (3-3) =0 sec
WT2= (10-10) =0 sec
WT3= (18-18) =0 sec
WT4= (20-20) =0 sec
WT5= (23-23) =0 sec
WT6 = (27-27) =0 sec
So Average Waiting time = (0+0+0+0+0+0)/6 = 0 sec
From the above it can be concluded that push based or event
driven system gives better performance when compared
against polling based system.
VII. CONCLUSION
This paper proposes a push based or event driven approach
for incorporating the dynamism in CEP engines. The proposed
method allows the user to add or modify the rules dynamically
at runtime. The proposed system is implemented to extend the
open software Drools Complex Event Processing engine. It is
observed that the proposed dynamic CEP engine performs
well when compared with engines that allow addition of rules
based on regular polling approach.
Acknowledgment
This research project is supported by NRDMS, Department
of Science and Technology, New Delhi. The authors would
like to extend their sincere thanks to NRDMS, DST, New
Delhi for the support.
REFERENCES
[1] Drools Expert User Guide, Version 5.4.0 CR1, JBoss Drools Team,
2012, pp.31-33.
[2] Esper Reference, Version 4.9.0, Esper Team and EsperTech Inc, 2012,
pp.441-443
[3] Miro Samek (2009, March).”State machine for event based systems”.
[Online]
[4] Available:http://www.barrgroup.com/Embedded-Systems/How-
To/State-Machines-Event-Driven-Systems
[5] Kendal SL,Creen M, “Developing Rules based System,” in An
introduction to knowledge engineering, London, Springer,2007,pp 126-
140
[6] Hasan Suleiman,Sean O’Reianin and Edward Curry “Approximate
Semantic Matching of Heterogeneous Events ,”in 6th ACM International
Conference on Distributed Event-Based Systems (DEBS 2012) Berlin,
Germany, pp- 252–263
[7] Hinze, A., Sachs, K., and Buchmann, “A. Event-based applications and
enabling technologies”, in Proceedings of the 3rd ACM International
Conference on Distributed Event Based Systems, ACM (2009),pp1-15.
[8] Luckham, D.C. “The power of events: an introduction to complex event
processing in distributed enterprise systems”. Addison-Wesley Longman
Publishing Co., Inc., Boston, MA, USA, 2002.
[9] A. Paschke, Alexander Kozlenkov, and Harold Boley, “A homogenous
reaction rule language for complex event processing”, In In Proc. 2nd
International Workshop on Event Drive Architecture and Event
Processing Systems (EDA-PS), 2007.
 2013 International Conference on Recent Trends in Information Technology (ICRTIT)

[10] Y. Turchin, A. Gal, and S. Wasserkrug, “Tuning Complex Event

Processing Rules Using the Prediction-Correction Paradigm”, Proc.
Third ACM Int’l Conf. Distributed Event-Based Systems (DEBS’09),
pp. 1 – 12, 2009.
[11] V. Gulisano, R. Jimenez-Peris, M. Patino-Martinez and P. Valduriez.
StreamCloud: a large scale data streaming system. In ICDCS, pp. 126 -
137, 2010.
[12] K. Patroumpas and T. Sellis. Event processing and real-time monitoring
over streaming traffic data. In W2GIS, pp. 116 – 133, 2012.
[13] N. Schultz-M_ller, M. Migliavacca and P. Pietzuch. Distributed complex
event processing with query rewriting. In DEBS, pages 1 - 12, July
2009.
[14] K. Teymourian, M. Rohde and A. Paschke. Knowledge-based
processing of complex stock market events. In EDBT, pages 594 - 597,
2012.
[15] Bastian Hoßbach and Bernhard Seeger. 2013. Anomaly management
using complex event processing: extending data base technology paper.
In Proceedings of the 16th International Conference on Extending
Database Technology (EDBT '13). ACM, New York, NY, USA, pp.
149-154, 2013.
[16] http://esper.codehaus.org/
[17] http://www.jboss.org/drools/
[18] Lindsay, Robert K., Bruce G. Buchanan, E. A. Feigenbaum, and Joshua
Lederberg. DENDRAL: A Case Study of the First Expert System for
Scientific Hypothesis Formation. Artificial Intelligence 61, 2 (1993):
209-261.
[19] Buchanan, B.G.; Shortliffe, E.H. (1984). Rule Based Expert Systems:
The MYCIN Experiments of the Stanford Heuristic Programming
Project. Reading, MA: Addison-Wesley. ISBN 978-0-201-10172-0.
[20] Drools Guvnor User Guide, Version 5.4.0 CR1, JBoss Drools Team,
2012, pp.1-2.
[21] http://www.espertech.com/resources/sd_esperjmx.html

194