CEP Thesis PDF
CEP Thesis PDF
FACULTY OF I NFORMATICS
Declaration
Hereby I declare, that this paper is my original authorial work, which
I have worked out by my own. All sources, references and literature
used or excerpted during elaboration of this work are properly cited
and listed in complete reference to the due source.
Acknowledgement
I would like to thank my supervisor doc. RNDr. Tom Pitner, Ph.D.
for the support and consultations throughout the work, the RedHat
BRMS team which helped me to get familiar with the Drools platform, my family and friends for the provided mental support and all
the people who took time to read the text and helped me to enhance
it and correct mistakes.
iii
Abstract
The aim of the thesis is to get acquainted with the core of Drools
platform, its module responsible for enabling event processing capabilities and bases of Complex Event Processing. The acquired knowledge is used to explore the possible utilization of Complex Event
Processing within the scope of web applications and demonstrate
the practical conclusions in a Java web application using Drools. This
application handles the user actions as events and processes them in
Drools rule engine.
iv
Keywords
Complex Event Processing, events, CEP, Drools, Drools Expert, Drools
Fusion, rule engine, rete network, web application
Contents
1
2
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . .
Drools Expert and Drools Fusion . . . . . . . . . . . . . . .
2.1 Overview of Drools . . . . . . . . . . . . . . . . . . . .
2.1.1 Introduction and history . . . . . . . . . . . . .
2.1.2 Drools projects . . . . . . . . . . . . . . . . . .
2.1.3 Alternatives to Drools . . . . . . . . . . . . . .
2.2 Rule engine . . . . . . . . . . . . . . . . . . . . . . . .
2.2.1 Production and Hybrid Rule Systems . . . . .
2.2.2 Working memory and agenda . . . . . . . . . .
2.2.3 Advantages and disadvantages of using a rule
engine . . . . . . . . . . . . . . . . . . . . . . .
2.3 Rete Algorithm . . . . . . . . . . . . . . . . . . . . . .
2.3.1 Introduction . . . . . . . . . . . . . . . . . . . .
2.3.2 Rete network . . . . . . . . . . . . . . . . . . .
2.3.3 Optimization and effectiveness . . . . . . . . .
2.4 Constructing the rules . . . . . . . . . . . . . . . . . .
2.4.1 Assembling resources . . . . . . . . . . . . . .
2.4.2 Drools Rule Language . . . . . . . . . . . . . .
2.5 Drools Fusion . . . . . . . . . . . . . . . . . . . . . . .
2.5.1 Complex event processing . . . . . . . . . . . .
2.5.2 Event definition . . . . . . . . . . . . . . . . . .
2.5.3 Clocks . . . . . . . . . . . . . . . . . . . . . . .
2.5.4 Temporal operators . . . . . . . . . . . . . . . .
2.5.5 Sliding windows . . . . . . . . . . . . . . . . .
2.5.6 Entry points . . . . . . . . . . . . . . . . . . . .
2.5.7 Event processing modes . . . . . . . . . . . . .
2.6 Drools 6 . . . . . . . . . . . . . . . . . . . . . . . . . .
Motivation to include CEP in web applications . . . . . .
3.1 The role of the user in the aims of websites . . . . . .
3.2 Benefits of incorporating Complex Event Processing .
3.3 Existing solutions . . . . . . . . . . . . . . . . . . . . .
The application . . . . . . . . . . . . . . . . . . . . . . . . .
4.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . .
4.2 Analysis and design . . . . . . . . . . . . . . . . . . .
4.2.1 Roles . . . . . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
1
3
3
3
3
5
6
6
8
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
9
10
10
11
15
16
16
18
21
21
22
23
24
25
26
27
27
29
29
30
32
33
33
34
34
vi
.
.
.
.
.
.
.
36
37
38
38
40
42
44
.
.
.
.
.
.
.
.
.
46
51
52
52
53
54
56
61
62
vii
1 Introduction
As the impact of information technologies on society increases every
year, constructing more and more complex and sophisticated systems is inevitable. The automation of human processes or appropriate computer assistance combined with monitoring and accountability is one of contemporary concerns. There are also frequent requirements not to only enhance an already established system, but to extend it in ways that enable the utilization of present logic and data
for different purposes such as additional processing, data mining or
fraud detection.
The difficulties with imperative languages and the traditional approaches to building such a system and augmenting it in the way
previously mentioned reside in the middle layer. A complex system
is usually comprised of at least persistence, logic and presentation
layers, whereas each can represent more layers, views or components. The logic layer is the critical scope of several matters such
as processes in general, decision making, current aspects evolving
or reusing, and adding additional features. Using an imperative language in a classical way in a complicated system might eventually
lead to unnecessary long and chaotic code, performance decrease
and the introduction of new bugs [1].
One of the possible solutions is to use a rule engine, which can
separate the appointed logic into more understandable, maintainable and reusable rules, which can be also maintained and verified
by domain experts. This goal of this thesis is to describe the core of
the Drools engine, as well as its module called Drools Fusion enabling Complex Events Processing capabilities, and explore the possible utilization of Complex Event Processing within web applications.
The practical conclusions are demonstrated in a Java web application
using Drools, which handles the user actions as events and processes
them in rules.
The structure of the thesis text is separated into several chapters,
where the first part covers the description of technologies and motivation concerning the topic, and the second part describes the composed application. The first chapter represents the introduction and
the last one the conclusion.
1
1. I NTRODUCTION
The second chapter focuses on the Drools engine and its essential
components utilized to develop this thesis. This chapter commences
with an overview of the Drools project and the platform. After the
introduction to rule engines, it pursues the explication of the Drools
core by describing the employed algorithm. Following sections target the composition of rules and the module for event processing.
The chapter is concluded with a description of the upcoming version
of Drools.
The third chapter examines the motivation of including Complex
Event Processing into the scope of web applications. It discuss the
importance and role of a user in this area, the benefits that the inclusion might provide and the existing solutions.
The fourth chapter describes the developed application. It discusses the analysis and design of the application, the implementation
and deployment. The characterization and description of the implementation is focused on the components regarding rules and event
processing, and applied use cases.
26
2.6 Drools 6
The next version of Drools predicted to be released in the second
quarter of 2013 is going to introduce a great deal of changes. It is go27
28
IN WEB APPLICATIONS
IN WEB APPLICATIONS
IN WEB APPLICATIONS
more, it can be managed by the domain experts and not only by the
programmers.
32
4 The application
4.1 Overview
As a consequence of the Drools being a project written in Java, the
application exploring and demonstrating the possible utilization of
Complex Event Processing encompassing actions of the user in web
environment is a Java EE application. Generally, an application desiring the same functionality might employ different technologies and
be based for example on C# or PHP, as event processing engines for
these languages can be found.
The type and specialization of the application has been selected as
product-based, as e-commerce is one of the significant areas of user
processing. Owing to the fact that the purpose of the application is
exploratory and demonstrational, the feature set is not required to be
as broad as of a real one. However, it should provide a considerable
amount of functions to develop various scenarios.
Basic functionality is represented by browsing and buying products which reside in separate categories. This is associated with managing shopping cart and checkout proceedings. Additional features
include functions such as searching amongst the products or simple
discussion of each product.
Most of these features are available to any visitor. Apart from
this type of user, the application distinguishes users logged in for
customers and administrators, each with different possibilities and
rights.
On the whole, as unregistered visitors and registered customers
browse the website, put products into the shopping cart, buy products or perform different actions, events are generated and inserted
into the engine. The events are processed by the rule engine, which
may result in activating rules. After the rules are fired, their consequences are performed and that results in influencing the web application itself or presenting the outcome to the administrator.
The application possess the prosaic name FusionWeb. It is composed as a Maven project and its sources are available at GitHub3 .
3. See https://github.com/IxiCZ/fusionweb.
33
4. T HE APPLICATION
As it is a Java EE application, it requires an application server to run,
nevertheless it has been deployed to a Platform as a Service solution4
as is described in chapter 4.4.1, where it can be easily explored as it
contains a description in the About page and direct logging links.
34
4. T HE APPLICATION
feature set and security realm. The use case diagram depicting the
interaction of the users in roles with the application is delineated in
Figure 4.2.
Figure 4.2: Use case diagram of roles interacting with the application.
Any user not logged in is represented by the Anonymous user
role. They are allowed to performed actions associated with browsing products, such as paging through the categories, displaying details or searching the product by keywords, and also managing their
shopping cart. However to complete the checkout and create the
order the user is required to log in as a Customer. Customers can
perform additional actions such as commenting on products and inspecting their orders. All the steps carried out by these two roles are
transformed to events and inserted to the Drools engine.
35
4. T HE APPLICATION
Administrator represents the user responsible for managing the
application content and responding to any issues happening. In other
words, an administrator can operate with the application in a standard custodian way and perform for instance managing orders, but
can also benefit from the outcome of the event processing engine.
4.2.2 Data model
4. T HE APPLICATION
The design of events represents different levels of data modelling.
Drools rule language enables the definition of events either as standard Java classes or directly in drl files. The latter option has been selected for facts and events assisting in the correct rule firing, but not
representing the user actions in the application itself. Useful cases of
those, contributing to explored scenarios have been depicted as java
classes. Their simple class diagram is in Appendix A.
4.2.3 Plugging Drools in
One of the essential decision at the beginning of constructing the application was generating events in a manner of tier location, to put
it in another way, where the standard Java EE components will interact with Drools and feed it with events. This resolution influences
not only the possible ways of implementation, but also the amount
and character of potential actions that can be processed and transformed into events, not to mention other aspects, such as simplicity
of future modifications, further reusability or greater adjustments.
As one might expect, the business and persistence tiers werent
taken into bigger consideration, as they considerably reduce the information regarding the action origin, in other words, they wouldnt
be easily able to determine by whom and how is a specific operation
initiated.
Another possibility was to link it by means of backing beans for
the user interface. This could be realized not only by ponderous placement of the code within methods, but for example by annotating
the methods with their own appropriate annotations. This approach
brings several drawbacks. The purpose of beans is to execute and
control the operation through reasonable amount of methods and attributes. Merging them with the Drools part would result in more
complicated code handling, as any refactoring, modification or extension could project also into the necessary adjustments in Drools
components. In a more important manner, beans would lack some
interesting information such as which part of the page initiated the
action.
Therefore, the final conclusion determined to realize the connection as far up in the tier terminology as possible, to be more precise,
in the user interface components. This has not only enabled the fine
37
4. T HE APPLICATION
distinction between different situations, but also easier plugging in,
with the meaning that any not yet considered link can be enriched
with the apposite listener. The type of the listener and passed on
parameters subsequently determine the events that should be generated.
To conclude, the overall majority of the elements generating the
events listens to actions in user interface components. The outcome
of rule consequences and other mechanisms such as monitoring and
layout configuration communicate with various tiers. Figure 4.4 outlines this in a simple view.
4.3 Implementation
4.3.1 Java EE
The prerequisite for composing and building the Drools components
was to develop a simple Java EE application representing the place
of origin for generating events. The application employs the technologies of Java Enterprise Edition platform version 6 and follows
the guiding techniques for developing enterprise applications from
Oracle [32].
38
4. T HE APPLICATION
The web tier is composed by means of JavaServer Faces (JSF)
technology. It a is server-side component framework which is primarily composed of API for constructing components and tag libraries
for integrating the components into web pages. The tag elements
in web pages are essential for generating the events as that is the
place where events originate. To be more precise, the JSF part consists
of descriptor configuration files, tagged web pages, custom components such as converters or validators and managed beans that represent container-managed objects applying techniques such as dependency injection or lifecycle callbacks.
The business tier and logic are encapsulated by Enterprise JavaBeans (EJB) technology. Beans represent server-side components
which facilitate transaction management and scaling. The application employs for the most part two types of them: stateless and singleton. The hierarchy of stateless beans is used for enquiring and
handling the data model stored in the database. Singletons with a
combination of application post construction are applied for creating
and filling up the tables in database, or establishing the Drools session.
The persistence tier is provided by Java Persistence API (JPA). It
enables the management of relational data by means of object/relational mapping capabilities, where class entities correspond to the
tables in the database and their instances to rows in the tables. Apart
from the annotations to determine the mapping of entities and entity relationships to relational data, the entity classes in the application also employ mechanisms for validating data called JavaBeans
Validation, and Named Queries. Managing entities is administered
through Java Persistence Query Language (JPQL) and Criteria API.
The targeted database is set in the descriptor file.
The security of the application is achieved by means of both declarative and programmatic security aspects. The scope of user capabilities is determined by his or her role. Administrator and Customer
roles are assigned to users at the end of the authorization mechanism of logging in with username and password. The resources are
declaratively labelled in a descriptor file to be available only to a certain role. That means, that if users not logged in attempt to reach
the resource they are redirected to the login page and if users in an
incorrect role try to reach it, they are prevented to do so.
39
4. T HE APPLICATION
To conclude, applying the afore described technologies forms a
fundamental point for further enriching and adapting for the purpose of incorporating event processing. The application was developed also considering other aspects such as design employing CSS
or internationalization using a resource bundle for messages.
4.3.2 Drools assembly at the start of the application
At the start of the application it is necessary to assemble the Drools
session, in other words, to create a proper Rete network and environment from resources, configuration and various components for it to
be able to receive events and commence firing rules. This is achieved
in an init method of EJB bean, heading of which is in Figure 4.5.
@Singleton
@Startup
@Lock ( LockType .READ)
@DependsOn ( { " StartupDBConfigBean " } )
public c l a s s DroolsResourcesBean {
@PostConstruct
public void i n i t ( ) {
...
Figure 4.5: Heading of the bean responsible for Drools assembly.
The @Singleton annotation determines the bean type to be a
singleton session bean. Singleton session beans are instantiated only
once and exist for the lifecycle of the application. The @Startup annotation dictates this creation to occur upon application deployment.
Subsequently the dependency injection (not depicted in the example)
is performed and then the @PostConstruct method is invoked.
The @DependsOn annotation is used in situations where more
singleton session beans require being initialized in a specific order.
The usage in the example specifies that another bean needs to be
constructed first. The purpose of this initial bean is to establish the
tables in the database and to fill them with starting data such as a
40
4. T HE APPLICATION
considerable amount of products or users in roles. The bean outlined
in the example does not only assemble the Drools session, but also
afterwards serves as an access point to it. The @LockOn annotation
is used for influencing the container-managed concurrency, as the
EJB container controls the access to the methods. As a whole, the
bean is labelled by the read type, which means that its methods can
be concurrently accessed or shared by various clients. However, to
preserve the consistency, some methods modifying the state are annotated with the LockType.WRITE, which locks the bean while the
method is called.
The detailed diagram of the Drools session assembly is depicted
in Figure 4.6.
4. T HE APPLICATION
achieve the result and return the result object. The engine contains
predefined functions such as sum or count, and enable to compose
own by implementing appropriate interface. The example of its own
accumulate function is the function for iterating over set of events
representing visited products and returning the most frequent one.
After KnowledgeBuilder is created, the resources represented by
drl files are fed into it. The rules and other elements are divided into
multiple files to facilitate the process of their maintaining and testing.
To be aware of the concept of time, KnowledgeBase requires to be
constructed in stream mode. Subsequently, the knowledge packages
from KnowledgeBuilder are added into it and it creates the StatefulKnowledgeSession. The session is then enriched by channels and listeners. Employment of channels is one of the possible ways to propagate the information from rule consequence. The listeners are used
for logging as they invoke methods relating to the activations and
rule firing, such as after each fired rule.
4.3.3 Overview of generating and processing events
The generation of the majority of events originates in the user interface JSF command links and buttons. In other words, they result from
the user navigating through the website and performing actions. An
example of such component is illustrated in Figure 4.7.
<h:commandButton
action="#{shoppingCart.addItem(
productController.selected)}"
actionListener=
"#{shoppingCartListener.productAddedIntoCart(
productController.selected,
userController.user)}"
value="#{bundle.AddToCart}"
styleClass="addToCartDetail"
/>
Figure 4.7: Example of a command button with listener producing
events.
42
4. T HE APPLICATION
The attributes value and styleClass determine the appearance of the button. The attribute action specifies the bean and its
method processing the input, and resulting in navigation. The element applied for generating events is actionListener. It defines
a bean method which processes an action event (not to confuse the
term with the discussed events) invoked by the component tag. To
put it in another way, this attribute registers when a component is
activated and executes appropriate method, which creates an event
and inserts it into the session. There are two arguments in this example from which the event is constructed, the user and product,
nevertheless, more of them can be applied to compose even more
detailed events.
After composing the event, the listener inserts it into the session.
There it passes through the Rete network and might create activations of one or more rules. When the rules are fired, their consequences are executed. The form of rule consequences can be diverse.
Some of them are applied to compose different types of events or
perform other actions considering only the engine and its elements,
such as updates or retraction of events. Other rules need to propagate
an acquired result or piece of information outside the session. There
are various ways to achieve this. A component capable of invoking
some desired method can be inserted into the session as a fact; however, this brings a disadvantage of blending these components with
processed data. Therefore, a more appropriate option is to employ
globals or channels. Globals are named objects which require being
set on the session and declared in the rule file to be used. Channels
are instances of classes implementing the appropriate Drools interface for receiving objects, and also needs to be registered to the session.
The general overview of the process resulting in the storing of
notification is outlined in Figure 4.8. When a user uses the relevant
component in the page, the listener generates an event and inserts it
into the session, where it might activate a rule. After the rule is fired,
its consequence employing a channel is executed and it creates an
apposite notification and stores it into the database.
43
4. T HE APPLICATION
4. T HE APPLICATION
insertions, for example when the application should evaluate the absence of certain facts over last hour, or if the reaction rate is not essential, an automatic timer can be applied. The application currently
applies the combination of both approaches.
The EJB container constructs the automatic timer when a properly
annotated enterprise bean is deployed. The Figure 4.9 depicts a bean
used for firing rules.
@Startup
@Singleton
@DependsOn ( { " StartupDBConfigBean " ,
" DroolsResourcesBean " } )
public c l a s s F i r e R u l e s S c h e d u l e r {
@Inject
p r i v a t e DroolsResourcesBean d r o o l s ;
@PostConstruct
@Schedule ( hour= " " , minute= " /5 " , second= " 0 " ,
persistent=false )
public void i n i t ( ) {
drools . fireAllRules ( ) ;
}
Figure 4.9: Bean used for firing rules every five minutes.
The bean is created at startup after the completion of table creation and constructing the session. The bean representing the access
point to the Drools session is injected and an automatic timer is constructed by the container. The character of the timer is determined
by the @Schedule annotation, where the frequency is defined by an
expression with similar syntax to the unix cron utility. This example
specifies the rules to fire every five minutes.
As the use of the timer is combined with the firing rule after every
event insertion, this method requires annotation with the LockType.WRITE to prevent concurrency problems.
45
4. T HE APPLICATION
4.3.5 Use cases of Complex Event Processing utilization
The application illustrates four general use cases of Complex Event
Processing utilization implemented by means of Drools. They are as
follows: notifications, statistics, layout adjustment and monitoring.
Notifications represent immediate reaction when an application
reaches a state defined in rules and reports it, in other words, when
something is happening that administrator should know about and
presumably react to. This does not necessarily imply an undesired
state, as the administrator might for instance want to be aware of the
situation where price of a product can be raised.
The application differentiates four types of notification: severe,
warning, info and good. The example of a severe notification is the
one composed when there is a product visited a lot, but not bought
much in the last hour. The condition of the rule responsible for this
calculates the difference between the sum of all visiting events for
each visited product event from the last hour and sum of all events
representing the buying of the product from the last hour, and if the
result is greater that the set number, the rule is activated and the consequence of the rule creates the notification. An example of a good
notification is one reporting a greatly bought product in the last hour.
Although some notifications can be composed with the application of a single rule, some requires the cooperation of more rules to
achieve this result. Following example depicts three rules employed
for creating notifications when there is a lot of unsuccessful product
search events with the same searched text in the last hour.
rule "Insert searched text event"
when
ProductSearchUnsuccessfulEvent($searchedText:
searchedText)
not SearchedText(text == $searchedText)
then
insert(new SearchedText($searchedText));
end
rule "Retract searched text event"
when
46
4. T HE APPLICATION
$searched : SearchedText($text : text)
not ProductSearchUnsuccessfulEvent(
searchedText == $text)
then
retract($searched);
end
rule "Create notification if too many unsuccessful
seach events"
no-loop
when
$searchedText: SearchedText($text: text)
not SearchedTextReported(text == $text)
over window:time(1h)
ArrayList(size >= 10) from collect(
ProductSearchUnsuccessfulEvent(searchedText
== $text) over window:time(1h))
then
channels["productSearchUnsuccessful"]
.send($text);
insert(new SearchedTextReported($text));
end
This collection of rules employs not only the events generated
by the UI component listener, but also a supporting fact and event
declared in rules. The first two rules manage insertion and retraction of the supporting fact SearchedText used for easy grouping
of events in the rule creating the notification by searched text. The
first rule inserts this fact if it does not exist, and the second rule retracts it when there is not a corresponding event anymore, in other
words, if all events of this kind with this searched text have expired.
The third rule calculates the count of corresponding events for each
such searched text and compares it to the set number. This rule also
uses a supporting event to report this kind of behaviour not more
than once per hour.
The channel applied in the third rule in the example is the specific channel created for this situation, expecting the searched text.
The channel creates the notification object and sets a proper mes47
4. T HE APPLICATION
sage to it. This has the advantages of detailed channel differentiation
and uncomplicated rule consequences, however the notification attributes such as severity level or text cannot be easily altered in rules.
Folowing example depicts a simple rule employing another channel
of a general character which expects notifications.
rule "Create notification when discussion entry
contains help"
when
$event: DiscussionEntryEvent(
text.toLowerCase().contains("help"))
then
channels["notificationsGeneral"].send(new
Notification(NotificationSeverity.WARNING,
new Date(), "The discussion entry created
by user " + $event.getUsername() +
" by " + $event.getProductName() +
" product contains help." ));
end
As the channel expects the already composed notification, it has
to be created in the rule. This can impede the transparency of the
rule, but facilitate its customization. Also a hybrid approach could
be applied, where only a text, severity level, or their tuple could be
sent. Namely this rule could be easily implemented using the standard techniques in the code as its condition could be rewritten to a
simple if statement. However, the separation of this logic from the
rule enables the easy construction of dozens of similar conditions
without the necessity of altering the code and it can be achieved by
even a non-programmer familiar with the rules.
Statistics are generated results from rules every established period of time. The application possesses two types of them, hourly
and daily, where the difference is only in the frequency of their execution and therefore the amount of time they take into consideration.
The example of a rule generating a statistic:
rule "Report how many customers logged in
in the last day"
timer (cron:0 0 0 */1 * ?)
48
4. T HE APPLICATION
no-loop
when
$total: Number() from accumulate(
$e: CustomerLogInEvent() over
window:time(24h), count($e))
then
channels["statisticsDaily"].send("In the
last day logged in "+ $total +
" customers." );
end
The rule applies the accumulated count function to all events
from the last day and sends the result message through the appropriate channel. The timer element is employed to achieve regular
execution. It can be defined either using the standard Unix cron expression, or by the interval expression described in the Drools Expert
documentation [12]. Only initial firing of the rules is required for the
timer to be activated.
The purpose of layout adjustment can be various, from attracting
new visitors to recommending products to familiar users. However,
to achieve that properly, the presentation components have to be designed with this purpose in mind. The example of this is that the
most visited product in the last hour is established as the main product on the home page, where this alternation is executed every hour.
The rule responsible for this is in the folowing example:
rule "Change main product if there is a better
one."
timer (cron:0 0 */1 * * ?)
no-loop
when
exists(ProductNavigationEvent()
over window:time(1h))
$current: CurrentMainProduct()
$mostVisitedProductEvent:
ProductNavigationEvent() from accumulate
($PNEventMain: ProductNavigationEvent()
over window:time(1h),
49
4. T HE APPLICATION
mostVisitedProduct($PNEventMain))
eval ($current.getId() !=
$mostVisitedProductEvent.getProductId())
then
modify ($current) {
setId($mostVisitedProductEvent.
getProductId());
}
channels["defaultLayout"].send(
$mostVisitedProductEvent.getProductId());
end
This rule employs a supporting fact representing the current main
product. This fact is inserted in another rule possessing a simple
condition based on non-existence of this fact. The rule also utilizes
its own accumulate function mostVisitedProduct, which iterates
over collection of events and returns the most frequent one. The condition of the rules also requires the new main product to be different
from the last one. In other words, if the same product is the most visited again, the rule is not activated. If the rule is activated, the current
main product fact is altered and the id is sent through the channel responsible for setting of the main product.
Furthermore, it would not be difficult to modify the rule to inspect other elements to set the main product, so it could be for instance based on the most bought or the most visited product. The
more sophisticated version could alternate these options in a defined
pattern and then automatically set the most successful one depending on the time of day, user category or different aspects.
Monitoring in the application represents a scenario where events
in the session can be examined to determine what is currently happening. Administrators can choose a user recently logged in and see
what the user is presently doing. This is implemented by the means
of Drools object filters. The session is capable of returning the collection of events meeting the defined condition. This condition is
represented by the implementation of the specific interface. The administrator can utilize such information for example to inspect the
navigation through the website or series of steps leading to buying a
product.
50
4. T HE APPLICATION
4.3.6 Testing of the rules
Testing of the rules is achieved by means of unit testing each rule or a
couple of rules representing a certain scenario. Each such test case is
covered by several unit tests attempting to evaluate a different situation. The tests comprising these unit tests are grouped in compliance
with the separation of the rules into drl files, in other words, a test
may add into Knowledge Builder only the drl file holding the declarations and the drl file representing the tested logic.
Each test is composed of unit tests and a before and after method.
The before method is responsible for composing the session before
each unit test and the after method for correct disposal of it. The constructing of the session is performed in the similar way as in the init
phase of the application with the exception of resources, channels
and clock. Only the resources necessary for the scenario are used for
creating knowledge packages. The mock objects are substituted for
actual channels as they require the application server to operate.
4. T HE APPLICATION
soning aspects, the clock implementation in the tests must be different. Drools provides two clock implementations, demonstrated in
Figure 4.10, where the Real Time Clock applies the JVM clock and
Pseudo Clock enables the application to control the flow of time in
all different ways. In order for the real-time clock to be the default
option, the setting of the pseudo-clock has to be configured during
creating the session.
4.4 Deployment
4.4.1 OpenShift
Openshift is a Cloud Computing Platform as a Service (PaaS) solution built on open source technologies managed by RedHat. It offers built-in support for Java, Ruby, Python, PHP, Perl, and Node.js
and customizable cartridge functionality for adding any other language, for instance Cobol. Furthermore, it provides both automatic
and manual scaling of the resources. Deploying the application on
Openshift is associated with selecting and applying present cartridges such as server or database, or building ones own [34].
Managing the application on Openshift can be achieved either
through the command line or Eclipse IDE with the appropriate plugin installed. The security is provided by means of SSH as the public
SSH key needs to be provided by the user to use the account.
The application has been deployed to Openshift in order to be
easily demonstrated and explored. It uses the following cartridges:
JBoss Application Server 7.1 to be the server, MySQL Database 5.1 for
the relational database and phpMyAdmin 3.4 to easily inspect the database. The configuration for the openshift profile is similar to the
one of local server and can be found at the github repository for the
application3 . The url through which the application can be reached
is:
https://fusionweb-ixi.rhcloud.com/
3. See https://github.com/IxiCZ/fusionweb.
52
4. T HE APPLICATION
4.4.2 An application server
For deployment to an application server the required elements are a
properly configured Java application server and a database system
capable of communicating with it, in other words, for which the appropriate driver exists.
The database system only needs to contain a corresponding database to the one defined in server configuration. Tables are created
and filled during the deployment of the application.
The configuration of the application server must set the database
as data source and establish the security domain. The guide how
to install the application to the JBoss Application Server is in Appendix B.
53
5 Conclusion
This thesis presents the introduction to Drools project and focuses
on explicating the core of the engine, the employed algorithm, rule
language and module for event processing capabilities. It also discuss the motivation of incorporating Complex Event Processing into
the scope of web applications and demonstrates the conclusions in
practical solution applying Drools.
The application was designed and implemented as a multi-tier
Java EE application capable of generating events as users browse,
navigates or perform various actions by means of it, where different
ways of realizing the event generation had been considered. To provide the sufficient base for the event processing, the application was
developed to contain the appropriate features such as user logging
in, product ordering or administration, and to offer more interesting types of events, features such as product discussion or searching amongst the products. The uppermost endeavour was given to
linking the Drools with the application and processing the events by
apposite rules.
The application presents various scenarios of utilization of Complex Event Processing in this scope. For ease of demonstration the application has been deployed to Platform as a Service solution, where
it can be explored and the instances of use cases are documented.
The application is a prototype of a possible solution. As a consequence, it does not cover all possible use cases which could be applied in this area. For instance, the distinguishing of events could
contain more attributes such as exact element and position on the
page generating it or detailed information about the user. In addition, many additional types of events might be defined and a great
deal of rules considering the events could be composed. A real complex solution would also require to consider other aspects, such as
caching or clustering.
To conclude, the area of Complex Event Processing can be utilized in the scope of web applications providing various benefits of
analysing the events and reactions of their processing. The incorporation of such a mechanism is currently required to be handled individually and for the proliferation of this approach, advanced tech54
5. C ONCLUSION
niques and frameworks should be developed.
55
Bibliography
[1] Bali, M. (2009). Drools JBoss Rules 5.0 Developers Guide. Birmingham: Packt Publishing.
[2] Drools - The Business Logic integration Platform. (n.d.).
Retrieved March 6, 2013, from
http://www.jboss.org/drools/
[3] Meeks, K. (2008, January 26). Introduction to Drools.
Retrieved from
http://www.readbag.com/intltechventurespresentations-2008-01-26-introduction-to-drools
[4] Amador, L. (2012). Drools Developers Cookbook. Birmingham:
Packt Publishing.
[5] Salatino, M. (2009). JBPM Developer Guide. Birmingham: Packt
Publishing.
[6] Aliverti, E. & Salatino, M. (2012). jBPM5 Developer Guide. Birmingham: Packt Publishing.
[7] Drools Planner. (n.d.).
Retrieved March 8, 2013, from
http://www.jboss.org/drools/drools-planner.html
[8] Sandeep, J. (2012, August 6). Comparison between Websphere
ILOG JRules and JBoss Drools BRMS.
Retrieved March 8, 2013, from
http://www.javagenious.com/ilog/WebSphere_ILOG_
JRules_BRMS_vs_JBoss_Drools.html
[9] Open Source Workflow Engines in Java. (n. d.).
Retrieved March 8, 2013, from
http://java-source.net/open-source/workflowengines
[10] Gualtieri, M. & Rymer, R. R.. (2009, August 4). The Forrester
WaveTM: Complex Event Processing (CEP) Platforms, Q3 2009.
56
B IBLIOGRAPHY
Retrieved from
ftp://ftp.software.ibm.com/itsolutions/SOA/
wave_complex_event_processing_cep_platforms.pdf
[11] Mijovic, V. & Vrane, S. (2011). A survey and evaluation of CEP
tools.
Retrieved from
http://www.e-drustvo.org/proceedings/
YuInfo2011/html/pdf/165.pdf
[12] The JBoss Drools team. Drools Expert User Guide Version
5.5.0.Final. (2012, November 13).
Retrieved March 9, 2013, from
http://docs.jboss.org/drools/release/5.5.0.
Final/drools-expert-docs/pdf/drools-expertdocs.pdf
[13] Agero, M., Esperon, G., Lopez De Luise, D. & Madou, F.
(2010). Enhancing Source Code Metrics Scope Through Artificial
Intelligence.
Retrieved from
http://www.iiis.org/cds2010/cd2010sci/citsa_
2010/paperspdf/ia292nw.pdf
[14] Browne, P. (2009). JBoss Drools Business Rules. Birmingham:
Packt Publishing.
[15] Lloyd, J. W. (1994). Practical Advantages of Declarative Programming. University of Bristol.
[16] Forgy, Ch. (1974). A network match routine for production systems. Working paper.
[17] Doorenbos, R. B. (1995, January 31). Production Matching for
Large Learning Systems.
Retrieved from
http://reports-archive.adm.cs.cmu.edu/anon/
1995/CMU-CS-95-113.pdf
[18] Mello, P., Proctor, M. & Sottara D. (2010, September 16). A Configurable Rete-OO Engine for Reasoningwith Different Types of
57
B IBLIOGRAPHY
Imperfect Information. IEEE Transactions on Knowledge and
Data Engineering, Vol. 22.
[19] Tirelli, E. (2011, October). BRMS: Best (and worst) Practices and
Real World Examples.
Retrieved March 24, 2013, from
http://www.slideshare.net/etirelli/brms-bestpractices2011octfinal
[20] Luckham, D. (2002). The Power of Events: An Introduction to
Complex Event Processing in Distributed Enterprise Systems.
Boston: Addison-Wesley Longman Publishing.
[21] Etzion, O. & Niblett, P. (2011). Event Processing in Action.
Greenwich: Manning Publications.
[22] Luckam, D. (2012). Event Processing for Business. New Jersey:
John Wiley & Sons.
[23] Breddin, T., Groch, M. & Walzer, K. (2008). Supporting Temporal Reasoning in the Rete Algorithm for Complex Event
Processing.
Retrieved from
http://www.rn.inf.tu-dresden.de/uploads/
dexaPaper.pdf
[24] Allen, F. J. (1981). An Interval-Based Representation of Temporal Knowledge.
Retrieved from
http://www.ijcai.org/PastProceedings/IJCAI-81VOL1/PDF/045.pdf
[25] The JBoss Drools team. Drools Fusion User Guide Version
5.5.0.Final. (2012, November 13).
Retrieved March 25, 2013, from
http://docs.jboss.org/drools/release/5.5.0.
Final/drools-fusion-docs/pdf/drools-fusiondocs.pdf
[26] Proctor, M. Life Beyond Rete - R.I.P Rete 2013 :). (2013, January
02).
58
B IBLIOGRAPHY
Retrieved March 30, 2013, from
http://blog.athico.com/2013/01/life-beyondrete-rip-rete-2013.html
[27] Fusco, M. Drools 6: News & Noteworthy. (n. d.).
Retrieved March 30, 2013, from
http://2013.33degree.org/talk/show/20
[28] Layton, J. How Amazon Works. (n. d.).
Retrieved April 2, 2013,
http://money.howstuffworks.com/amazon.htm
[29] Lacey, D. (2009). Managing the Human Factor in Information
Security. New Jersey: John Wiley & Sons.
[30] Nielsen, J. How Long Do Users Stay on Web Pages? (2011,
September 11).
Retrieved April 4, 2013, from
http://www.nngroup.com/articles/how-long-dousers-stay-on-web-pages/
[31] Gonsalves, A. SeeWhy Takes Complex Event Processing To
Web Analytics (2009, May 8).
Retrieved April 6, 2013, from
http://www.informationweek.com/software/
business-intelligence/seewhy-takes-complexevent-processing-to/217400025
[32] Cervera-Navarro, R., Evans, I., Haase, K., Gollapudi, D., Jendrock, E., Markito, W. & Srivathsa, C. The Java EE 6 Tutorial
(2013, Jabuary).
Retrieved April 10, 2013, from
http://docs.oracle.com/javaee/6/tutorial/doc/
[33] EJB 3.0 Expert Group. JSR-000220 Enterprise JavaBeans 3.0
(n.d.).
Retrieved April 20, 2013, from
http://jcp.org/aboutJava/communityprocess/
final/jsr220/index.html
59
B IBLIOGRAPHY
[34] Red Hat, Inc. OpenShift Platform as a Service (n.d.).
Retrieved April 30, 2013, from
https://www.openshift.com/paas
60
A Events diagram
61
2.
3.
4.
Copy the driver for the database to the standalone/deployments folder (for example the apropriate JDBC Driver for MySQL
is called Connector/J and can be obtained at http://www.
mysql.com/products/connector/. The file
mysql-connector-java-5.1.22-bin.jar would then be
copied to server-folder/standalone/deployments)
5.
(f)
Save and close the file. The configuration can also be man64
7.
65