Platforma průmyslové spolupráce CZ.1.07/2.4.00/17.0041 Název Drools Fusion and Utilization of Complex Event Processing in Web Applications Popis a využití • studijní materiál pro platformu Drools, komplexní zpracování událostí (CEP) • use case pro využití CEP v oblasti webových aplikací • výuka: pokročilá Java Jazyk textu • anglický Autor (autoři) • Iva Žáková Oficiální stránka projektu: • http://lasaris.fi.muni.cz/pps Dostupnost výukových materiálů a nástrojů online: • http://lasaris.fi.muni.cz/pps/study-materials-and-tools Contents 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 2 Drools Expert and Drools Fusion . . . . . . . . . . . . . . . . 3 2.1 Overview of Drools . . . . . . . . . . . . . . . . . . . . . 3 2.1.1 Introduction and history . . . . . . . . . . . . . . 3 2.1.2 Drools projects . . . . . . . . . . . . . . . . . . . 3 2.1.3 Alternatives to Drools . . . . . . . . . . . . . . . 5 2.2 Rule engine . . . . . . . . . . . . . . . . . . . . . . . . . 6 2.2.1 Production and Hybrid Rule Systems . . . . . . 6 2.2.2 Working memory and agenda . . . . . . . . . . . 8 2.2.3 Advantages and disadvantages of using a rule engine . . . . . . . . . . . . . . . . . . . . . . . . 9 2.3 Rete Algorithm . . . . . . . . . . . . . . . . . . . . . . . 10 2.3.1 Introduction . . . . . . . . . . . . . . . . . . . . . 10 2.3.2 Rete network . . . . . . . . . . . . . . . . . . . . 11 2.3.3 Optimization and effectiveness . . . . . . . . . . 15 2.4 Constructing the rules . . . . . . . . . . . . . . . . . . . 16 2.4.1 Assembling resources . . . . . . . . . . . . . . . 16 2.4.2 Drools Rule Language . . . . . . . . . . . . . . . 18 2.5 Drools Fusion . . . . . . . . . . . . . . . . . . . . . . . . 21 2.5.1 Complex event processing . . . . . . . . . . . . . 21 2.5.2 Event definition . . . . . . . . . . . . . . . . . . . 22 2.5.3 Clocks . . . . . . . . . . . . . . . . . . . . . . . . 23 2.5.4 Temporal operators . . . . . . . . . . . . . . . . . 24 2.5.5 Sliding windows . . . . . . . . . . . . . . . . . . 25 2.5.6 Entry points . . . . . . . . . . . . . . . . . . . . . 26 2.5.7 Event processing modes . . . . . . . . . . . . . . 27 2.6 Drools 6 . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 3 Motivation to include CEP in web applications . . . . . . . 29 3.1 The role of the user in the aims of websites . . . . . . . 29 3.2 Benefits of incorporating Complex Event Processing . . 30 3.3 Existing solutions . . . . . . . . . . . . . . . . . . . . . . 32 4 The application . . . . . . . . . . . . . . . . . . . . . . . . . . 33 4.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 4.2 Analysis and design . . . . . . . . . . . . . . . . . . . . 34 4.2.1 Roles . . . . . . . . . . . . . . . . . . . . . . . . . 34 vi 4.2.2 Data model . . . . . . . . . . . . . . . . . . . . . 36 4.2.3 Plugging Drools in . . . . . . . . . . . . . . . . . 37 4.3 Implementation . . . . . . . . . . . . . . . . . . . . . . . 38 4.3.1 Java EE . . . . . . . . . . . . . . . . . . . . . . . . 38 4.3.2 Drools assembly at the start of the application . 40 4.3.3 Overview of generating and processing events . 42 4.3.4 Firing the rules . . . . . . . . . . . . . . . . . . . 44 4.3.5 Use cases of Complex Event Processing utilization . . . . . . . . . . . . . . . . . . . . . . . . . . 46 4.3.6 Testing of the rules . . . . . . . . . . . . . . . . . 51 4.4 Deployment . . . . . . . . . . . . . . . . . . . . . . . . . 52 4.4.1 OpenShift . . . . . . . . . . . . . . . . . . . . . . 52 4.4.2 An application server . . . . . . . . . . . . . . . 53 5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 Bibliography . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 A Events diagram . . . . . . . . . . . . . . . . . . . . . . . . . . 61 B Deploying the application to JBoss Application Server 7 . 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. INTRODUCTION 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. 2 2 Drools Expert and Drools Fusion 2.1 Overview of Drools 2.1.1 Introduction and history Drools is an open source project written in Java, licensed under the Apache License, Version 2.01 . The current fifth version of Drools released in May 2009 introduced the Business Logic integration Platform (BLiP), which provides a unified and integrated platform for rules, workflow, event processing and automated planning optimization. The project as such is maintained by the community, providing a new release every couple of months that includes new features and bug fixes. A productized version involving sanitized community releases and support called JBoss Enterprise Business Rules Management System (BRMS) is offered by Red Hat, Inc [2]. First work on the rule engine of Drools began in 2001; this first version was never released due to constraints engendered by the brute force linear search approach. In Drools 2.0, the concept was changed to be loosely based on the Rete algorithm, and the federation into JBoss in 2005 enabled the development of enhanced Rete implementation [3]. The performance was significantly improved and the community started to emerge. As the development of Drools gradually progressed through the versions, Drools specific aspects were introduced such as Drools Rule Language, more performance improvements of the algorithm were accomplished and several other projects were incorporated into Drools [1]. The latest version is currently 5.5, released in November 2012; it is this version which is explicated following. Drools 6 is currently being developed, which will present not only new features, but also a new algorithm as well. 2.1.2 Drools projects The platform is currently composed of five main modules: Drools Expert represents the rule engine itself. It is the declarative, rule based coding environment, which is used to define, execute 1. See http://www.apache.org/licenses/LICENSE-2.0.html. 3 2. DROOLS EXPERT AND DROOLS FUSION and maintain the rules. Thus it can be considered as the core of the platform [4]. In a simplified way, it is not possible to use, for instance, only Drools Fusion per se. To develop correct and efficient rules, it is also advisable to comprehend how the rule engine works. Drools Fusion represents the module enabling the event modelling capabilities. Data processed by the rule engine can consequently be perceived as events and not only as the simple facts. The ability to identify temporal relationships between events, to compose and aggregate them, and other aspects discussed further, make it possible to implement standard Complex Event Processing scenarios such as fraud detection or automatic trading. However, the application of a rule engine can facilitate creating them, produce another perspective on the subject, or assist in tackling entirely new problems. jBPM engine enables the modelling and design of the business processes by means of BPMN 2.0 specification. Furthermore it provides the executional environment for processes and makes it possible to describe them in a formal language [5]. The current jBPM5 resulted from the merger of the original jBPM with the project Drools Flow. That enabled easy integration of rules into business processes. Moreover, there are multiple tools available in the form of Eclipse plugin or web editor to easily model and visualize the processes. Drools Guvnor represents a centralized repository for keeping various knowledge assets such as business processes, models or rules, with a web graphical user interface also able to be used by domain experts, analysts or users with no programming experience. It contains a set of process-oriented tools and also tools for the authoring phase of created assets. The storing of rules and other assets is managed by a Java Content Repository (JCR) [6], which supports version and access control. Drools Planner, renamed OptaPlanner in the upcoming version, represents the module for optimization and solving discrete optimization problems. It uses a system of efficient score calculation combined with optimization heuristics and metaheuristics. Because of this, it can explore solutions during an established amount of time and solve any NP-complete problem in a reasonable period of time [7]. Frequent use cases are, for instance, resource scheduling, queue planning or traveling salesman problem. Another valuable component is the Drools and jBPM plugin for 4 2. DROOLS EXPERT AND DROOLS FUSION Eclipse IDE. It facilitates writing and debugging rules and processes with syntax assistance or visualization. To conclude, the platform provides the means to model complex behaviour of a broad spectrum of problem situations. The flow of data, information or logic can be decomposed into processes, perceived as - or transformed into - events, solved and optimized, or only processed by the rule engine. This thesis focuses on the core of the platform - the rule engine itself (Drools Expert) and the module enabling the event modelling capabilities (Drools Fusion). 2.1.3 Alternatives to Drools Owing to the multiple area specializations of the platform, alternatives to Drools vary according to the purpose of use. The noted paid option for a rule engine is WebSphere ILOG JRules BRMS from IBM. In comparison with Drools Expert, it supports Java, .NET and COBOL environments and contains a richer feature set for business analysts to be included more in the rule development and management lifecycle [8]. Other rule engine options are, for instance, Microsoft InRule, FICO Blaze Advisor Business Rules Management or Decision Management System [1]. A great deal of both paid and open source workflow and process engines can be found, the most popular open source options are as follows: Activiti, Bonita Open Solution, or ActiveBPEL [9]. The range of Complex Event Processing (CEP) solutions is also quite large. The Forrester Research2 evaluation of CEP platforms from 2009 [10] established 114 criteria to compare ten vendors offering commercial solutions and Progress Software and Aleri came out as the strongest. The only vendor in this evaluation also offering an open source version of the product was EsperTech with Esper. Esper in comparison with Drools Fusion uses SQL-like syntax, which can be easier for programmers to learn, contains fewer temporal operators and may have better performance results within a short period of time [11]. Overall, there are a great deal of other options, which can be more effective or appropriate for certain problems where only one Drools 2. See http://www.forrester.com/. 5 2. DROOLS EXPERT AND DROOLS FUSION module is required or the financial aspect is not an issue. The key factors of Drools are the facts that it is an open source solution and a unified platform, which enables it to combine several modules to create complex behavioural modelling. 2.2 Rule engine 2.2.1 Production and Hybrid Rule Systems The term rule engine can cover a broad variety of systems, from ones using rules in the most simple form for instance for validation, to the complex systems where the logic processed by the rule engine is quite essential [12]. The Drools rule engine originated as a special type of rule engine known as a Production Rule System (PRS). A Production Rule System is often considered to be at the centre of an expert system, or is directly interchanged with the term. Since an expert system is a system that applies knowledge in the form of ontological model and declared rules defined by domain experts for the purpose of solving problem in a particular field [13], it would be misleading to describe the Drools rule engine as an expert system. To be accurate, it is a device to build expert systems. The computational model of Product Rule System specifies the set of rules, where each rule is comprised of a condition and a consequential action. During the run of the system, the conditions are evaluated following the processed data and the consequential actions are executed. Therefore, each rule is in the following format: when // condition then // action The important aspect to comprehend is the difference between the imperative if... then in the sequential code and the declarative when... then in rules. The rules do not specify a detailed sequence of steps. The rules declare the conditions specifying when the actions should be performed; the rule engine takes the rules, the data and 6 2. DROOLS EXPERT AND DROOLS FUSION evaluates them in the most efficient way. Those rules with the condition evaluated to true have their action executed. The data matched against the rules reside in memory in the form of facts. The matching itself is called pattern matching and is performed by an inference engine. The pattern matching can result in scheduling the executions - called the firing - of the rule actions by the agenda, and as a consequence, firing of rules can conclude in matching against other rules and engender firing those. This mechanism is referred to as forward chaining [12]. Figure 2.1 indicates the high-level view of a Production Rule System. The rules stored in Production Memory are matched against the facts that reside in Working Memory by the Inference Engine via pattern matching and can result in executions administered by the Agenda. Figure 2.1: High-level view of a Production Rule System [12] The described forward chaining could be characterized as reactionary and data-driven, as the asserting of facts into working memory results in executions. Another approach is called the backward chaining, which is goal-driven. The engine starts with a conclusion, which it tries to satisfy. If it cannot, it attempts to satisfy a subgoal conclusion, which would assist in satisfying an unknown part of the current goal. This activity then can continue recursively and ends 7 2. DROOLS EXPERT AND DROOLS FUSION when the initial conclusion is proved or no other subgoals exist. An example of backward chaining system is, for instance, Prolog. More reasoning techniques such as imperfect reasoning or defeasible logic exist [12]. Systems combining more types of these capabilities are referred to as Hybrid Reasoning Systems (HRS). Since Drools 5 also introduced backward chaining into its engine in the form of derivation queries, the current preferences incline to describe it as the Hybrid Reasoning System. 2.2.2 Working memory and agenda The data and information in the object-oriented environment are represented by the object instances. When these instances are inserted into the Working Memory of the engine, in Drools terminology they become facts and henceforth can be evaluated against the declared conditions of the rules. In consequence of the insertion, a wrapper to the fact is created, which can be onwards used as the reference to update it or retract it. If a fact is modified, the update is required to be called tor the engine to re-evaluate the rules against the altered fact. A retract should be called provided that the information is no longer needed or would cause undesired behaviour. When facts are inserted, updated or retracted from the Working Memory, the engine identifies the corresponding rules by means of pattern matching and creates the activations for the matching rules. The Agenda represents the list of all these activations, in other words of all the rules prepared to fire. It is important to note that the act of generating the activations does not execute the rules action consequences, nor that all the rules prepared to fire must necessarily do so. The activation list does not start firing until the appropriate method is called. When this method is called and the agenda contains more than one activation, the engine needs to determine which activation should fire first. This decision is based on the conflict resolution strategy of the engine. The result of conflict resolution strategy can be based on many factors such as the attributes of the rule, the rule recency, which declares how many times has the rule fired, the complexity of the rule or the rules load order [14]. The selected activation is subsequently executed, which can result in altering some facts, re-evaluating the 8 2. DROOLS EXPERT AND DROOLS FUSION rules against the new Working Memory state and as consequence creating new activations or removing the present ones. After the process of the execution is finished, if the Agenda still holds some activations, the procedure continues with determining new rule activations to fire. This cycle carries on until there are no more activations. The whole process is outlined in the following Figure 2.2. Figure 2.2: The outline of rules execution cycle [6] The rule attributes provide additional impact on the Agenda behaviour such as avoidance of circular reactivations or assembling the rules into activation groups. 2.2.3 Advantages and disadvantages of using a rule engine Many advantages result from the declarative approach. The maintainability is improved as the time can be allocated to what needs to be accomplished instead of how [15]. Furthermore, decomposing 9 2. DROOLS EXPERT AND DROOLS FUSION the logic into rules may decrease the subsequent complexity and increase the flexibility owing to easy modification of the rules. The rule language can also enable the domain experts to be originators of the written logic and control its evolution. However, switching to rule engine does not always have to be the right decision. To shift the thinking paradigm to a declarative rules style and to learn how to write the rules properly and effectively can be time consuming, which is not suitable for small projects where logic is not going to change in the future. Apart from this, the complex rules are more difficult to debug than traditional lines of codes, in the absence of highly advanced debuggers. In addition, it is not the best solution for situations where memory is the crucial factor, since a lot of calculations are stored for the engine to be efficient [1]. 2.3 Rete Algorithm 2.3.1 Introduction The speed efficiency and scalability of the Drools rule engine is engendered by the Rete algorithm on which it is based. The Rete algorithm [16], the name of which originates from the Latin word for ‘net’, represents a pattern matching algorithm for implementing production systems. The algorithm was designed by Dr Charles L. Forgy and first published in 1974. Since then, it has been modified and augmented by Dr Forgy himself and also many rule engines established on its basis [17]. The Drools rule engine uses the enhanced Rete algorithm called Rete-OO. It is an optimized implementation for object oriented systems including several types of schemes for reasoning with imperfect information and enables the architecture to be influenced by configuration parameters [18]. Whereas it has been mathematically proved to be faster and more scalable than the traditional if... then solution [14], the price for efficiency is in the higher memory consumption and usage due to a high amount of caching in order not to evaluate the conditions multiple times. The inference engine applies the algorithm for pattern matching. In other words, the algorithm is responsible for matching the facts against rules and determining for which rules activations should be 10 2. DROOLS EXPERT AND DROOLS FUSION created. 2.3.2 Rete network The algorithm transforms the conditions of the rules into the Rete network. This discrimination network is represented by a rooted, acyclic and directed graph and is modified whenever a rule is altered, added or removed from the knowledge base. Its purpose is to efficiently filter data passing down the network. The network is comprised of various node types. Suppose that the rule base consists only of the subsequent rule: rule "Person older than 18." when Person(age > 18) then // consequence end This rule executes its consequence for a Person fact, where the fact has the attribute age greater than number 18 (the rules and their description are covered in section 2.4.2). The Rete network would be composed as depicted in Figure 2.3. Figure 2.3: The Rete network for a simple rule. 11 2. DROOLS EXPERT AND DROOLS FUSION A visualization graph representing the Rete network comprising of coloured nodes determined by their type can be generated by the Drools Eclipse plugin. The root of each Rete network is represented by the node called the ReteNode. It can be perceived as the entrance to the network, and all the objects inserted to the memory must enter it. Then follows the first level of discrimination, portrayed by one or many nodes of EntryPointNode type. The entry point mechanism enables the abstraction in the form of partitioning the working memory for facts and more importantly for event streams, which is covered in 2.5.6. In other words, objects entering the memory can be inserted either into the default entry point, or into a named one, which is reflected in the Rete network. The ensuing level of discrimination is provided by at least one node of type ObjectTypeNode. This node performs filtering based on the fact type, which means that nothing but the facts of corresponding type are allowed to pass through. In this instance only objects of the type Person continue further down the network. Furthermore, following nodes will apply the constraints regarding the Person type. The first level of matching is represented by the nodes of AlphaNode type. They have one input and define intra-element conditions, meaning that they evaluate constraints on single facts. The constraints may have various forms, such as literals, variables, inline evaluations or return values. Multiple constraints on the same type are expressed by more alpha nodes, each representing a single constraint. The order of the constraints in the rule is important. Figure 2.4: Rete network of transposing the constraints in the rule. Transposing the constraints in the rule influences the concluding appearance of the Rete network, see Figure 2.4. For one thing, the more restrictive constraint should precede the less restrictive for the 12 2. DROOLS EXPERT AND DROOLS FUSION rules to be efficient. More importantly, the order can affect re-usability of the rules in the more complex rule set. The penultimate node in the Figure 2.3 is LeftInputAdapterNode. These nodes are used to create a tuple from single fact in order to enter some type of nodes. The leaves of Rete networks are represented by nodes of TerminalNode type. They correspond to the action parts of rules, or to be more precise, to the activations of these rules, which should be assigned to agenda for future execution. Each rule introduces at least one TerminalNode, whereas a complex rule using the conditional disjunctive ‘or’ can have more than one of these nodes. To conclude, if a Person fact was inserted into a default entry point, it would enter the Rete network in ReteNode, then it would continue through EntryPointNode and ObjectNodeType to AlphaNode. The AlphaNode would evaluate its constraint. Thereafter the situation would depend on the age attribute of the fact. If the age was less or equal to 18, the fact would not be propagated further and the insertion method would be finished. Otherwise the fact would pass through to the LeftInputAdaptedNode, where it would be transformed into a tuple and then reach the TerminalNode, which would result in placing the “Person older than 18.” rule on the agenda. If the fact was inserted into another entry point or was of another type, the advancement would end at the relevant node. The introduction of more convoluted aspects uses a rule base comprising of two the following rules: rule "Person living in Brno." when Person(city == "Brno") then // consequence end rule "Young person owns an accommodation in Brno." when $person: Person(city == "Brno", age < 30) Accommodation(owner == $person) then 13 2. DROOLS EXPERT AND DROOLS FUSION // consequence end The first rule executes its action for Person fact, where attribute city is equal to literal ‘Brno’. The second rule requires a couple of Person facts with the city attribute equal to ‘Brno’, age less than 30 and an Accommodation fact with the owner attribute equal to the prior Person fact. The Rete network of this rule base is depicted in Figure 2.5. Figure 2.5: More complex Rete network. Another important node type is BetaNode. These nodes have two inputs: one for tuples, one for facts, and define inter-element conditions. They enable comparison of facts or their attributes with each other. The mentioned inputs are associated with memories which keep information about facts that have arrived. Later the facts can be evaluated against facts coming to the other input and the result propagated further. There are various types of beta nodes. In the Figure 2.5 JoinNode is used, which is responsible for joining and evaluating a tuple and a 14 2. DROOLS EXPERT AND DROOLS FUSION fact. The other types of BetaNode represent various rule constructs, the most used are NotNode, ExistsNode, AccumulateNode and CollectNode. More complex rules or rules using different constructs can also apply other types of nodes such as EvalNode or FromNode. If a Person fact is inserted into the default entry point of the afore described rule base, it will pass through ReteNode, EntryPointNode, ObjectTypeNode for Person type to the first AlphaNode. If the constraint evaluation is successful, it will propagate to both the successor nodes. Within the left flow (in Figure 2.5) it continues through LeftInputAdapterNode to TerminalNode,which results in placing the activation of the first rule to agenda. Along the right flow it is evaluated in another AlphaNode. Supposing the evaluation of the constraint is successful, the fact is wrapped into a tuple in LeftInputAdapterNode and reaches the JoinNode. This tuple is added to the memory for tuple inputs of JoinNode and its fact memory is examined in order to find a match. Provided that there is no match, the proceeding is finished. If an Accommodation fact is inserted then, it passes through the ReteNode, EntryPointNode and ObjectTypeNode for Accommodation type to the JoinNode. There it is added to the memory for facts and the tuple memory is examined to find a match and evaluate constraints. If the process is successful, a tuple consisting of both the Person and Accommodation fact is constructed and continues to the TerminalNode, where it creates an activation of the second rule. 2.3.3 Optimization and effectiveness It have been established and demonstrated in Figure 2.4 that the structure of the Rete network eminently depends on the order of conditions and constraints in the rule. As a consequence, the composition of the rules has a direct impact on the node sharing in the Rete network. The rules from previous example having their Rete network depicted in Figure 2.5 have except ReteNode, EntryPointNode and ObjectTypeNode also in common the AlphaNode. If the constraints for Person fact in the second rule were transposed, the network would contain an AlphaNode for each rule instead of one shared alpha node for both the rules. The node sharing enables the minimization of the size of the Rete network. For the algorithm to 15 2. DROOLS EXPERT AND DROOLS FUSION be truly effective, the rules should share as many nodes as possible, making it possible to minimize the evaluations of the same conditions. Also in general, the condition and constraints of the rules should start with the more restrictive ones. Overall, the phase of designing the rules should not be rushed. The aforementioned cases focus on inserting the facts. The activations of the rules are also re-evaluated in the case of modifying and retracting facts. The modification of a fact is achieved by a combination of retracting and inserting the fact. The technique called the asymmetrical Rete [1], which uses the tuple related to the fact to retrace the steps and retracts it from corresponding nodes, has been used for retraction since Version 5. For the correct and effective functioning of the application it is important to emphasize the difference between insertion (or modifying and retraction) and firing the rules. Unless the firing the rules engenders in insertion, modifying or retraction, the utmost conditions processing occurs before the rules firing is even executed. The firing is responsible only for executing the actions of the activated rules in the agenda. Whereas the original Rete algorithm started with only four basic types of nodes, the advanced Drools algorithm employs many node categories. To achieve a commendable performance the implementation uses techniques such as hashmap lookups for objects, caching results or indexing [12]. In conclusion, the algorithm provides an efficient way of evaluating the rules. As a real complex application can contain hundreds or thousands of rules, the network would be indubitably wide, but comparatively flat. 2.4 Constructing the rules 2.4.1 Assembling resources In order to commence composing the rules and building the basis of Drools application, it is essential to comprehend the assembling of the resources. That is associated with three conceptions: Knowledge Builder, Knowledge Base and Knowledge session. Knowledge Builder comprises parsers and semantic modules. 16 2. DROOLS EXPERT AND DROOLS FUSION These elements enable the building of the binary representation of defined knowledge models. To put it in another way, the builder responsible for forming the knowledge packages from given resources. At present, it is possible to apply about a dozen of different resource types, such as types supporting processes, xml based documents or decision tables, which enable managing rules in a spreadsheet format. The discussed aspects focus on Drools Rule Language (DRL), where rules are usually stored in the .drl files. Knowledge Base represents the container for compiled knowledge assets, such as rules, internal types or processes, which are grouped into knowledge packages. It allows not only their storage, but also their reuse in order to save computing time, since their creation is expensive [1]. To be more precise, it enables to establish the sessions, where their creation is in comparison inexpensive. Knowledge Session represents the place where the rules run. By its means happens the interacting with the engine, such as inserting, updating or retracting facts and firing the rules. There are two types of session: stateless and stateful. The stateless session does not maintain the state between interactions. It is used for situations where a particular result needs to be computed. The stateful session maintains the state and is required where some previous information is necessary. The detailed creation of the Knowledge Session is depicted in Figure 2.6. Figure 2.6: Thorough illustration of creating a Knowledge Session [1]. There are two possible ways of firing the rules. The first is by calling a fireAllRules method on a session, which results in im- 17 2. DROOLS EXPERT AND DROOLS FUSION mediate firing of the activations placed on the agenda and potential activations created by them, followed by further continuation of the program. The second possibility is through the fireUntilHalt method, which fires an activation when it is created. The possible disadvantages of this solution are that it needs to be executed in a separate thread and is not recommended for certain scenarios. 2.4.2 Drools Rule Language Rule files are represented by text files with .drl extension and they have usually following structure [12]: package package-name imports globals type declarations functions queries rules The structure of the file is not completely fixed. The file should start with package and imports; type declarations ought to precede their use, but functions, queries and rules can permeate. The elements are also not required to be in only one file. They can be spread across multiple files, for instance one holding only imports and declarations and one rules, or be separated into multiple rule files depending on logic. The important aspect is the order of their feeding into the Knowledge Builder. Package represents the namespaces that are able to group elements from multiple files. In other words, all rule files appertaining to the same package are required to share the same package name. package cz.example.pkg.first; 18 2. DROOLS EXPERT AND DROOLS FUSION Import statements operate on the same basis as standard Java imports. Objects within the declared package are imported automatically. Objects from other packages must be imported or accessed by their fully qualified names. import cz.example.pkg.second.Person; import java.util.List; Global variables enable objects to be reached within rules without insertion into session as facts. They are used in rule consequences for techniques such as logging, reporting or returning values. Their use in rule conditions is discouraged due to the fact that the engine is not notified about their modification. global List results; Type declaration has dual purpose. The first is declaration of metadata for already existing types. These metadata are used for reasoning process of the engine regarding the type. Metadata concerning Complex Event Processing are discussed in 2.5.2. The second purpose is to define new types. Metadata can be applied there as well, especially for achieving certain characteristics, such as the equality principle. Defining new types can be desirable in situations where there are reasons not to interfere with an already created domain model, or for types used only in rules and not much elsewhere. declare Cat name : String owner : Person registrationNumber : int @key end Functions are used either in order to avoid code duplication or to separate some logic to a certain place. They can be used in both condition and consequence of the rule. The static methods of classes can be also imported to serve as functions. function String greeting(String name) { return "Welcome "+ name + "!"; } 19 2. DROOLS EXPERT AND DROOLS FUSION Query represents a simple way to obtain facts complying with defined conditions from code. Furthermore, a combination of queries can be used to solve tasks. query "Adults." person : Person( age > 18 ) end Rules possess the following structure: rule "name" // attributes when // condition then // action end There is approximately a dozen rule attributes. They influence the position of the rule on the agenda, assemble rules into groups, enable activation of the timer for regular rule execution or prevent the recursive firing. The conditional part of the rule is sometimes referred to as LHS (Left Hand Side) and can be composed of multiple conditions. These conditions are represented by patterns which can match facts inserted into the session. Patterns can contain constraints related to the inspected type, such as: Person (age > 18) The attributes are retrieved through the getters. The facts and their attributes can be bound to a variable and used later in the rule. The conditions support logical operators such as or, not or exists. The facts can be gathered into collections, processed and evaluated by means of great deal of operators. Their thorough description can be found in Drools Expert documentation [12]. The action part of the rule is sometimes referred to as the consequence or RHS (Right Hand Side) and can contain any Java code. The amount of code should not be large. It is possible to insert, modify 20 2. DROOLS EXPERT AND DROOLS FUSION and retract the facts here and also to use a technique called logical insert, which ensures the automatic retraction of the inserted fact, in the case that the condition of the rule is no longer true. To conclude, Drools Rule Language provides a wide variety of components to express the desired logic. The best practices [19] determine that each rule should describe one scenario and nested conditional logic and loops in the action part should be avoided. 2.5 Drools Fusion 2.5.1 Complex event processing The matter of processing events in intuitive form is not recent. Weather prediction, network monitoring or information gathering have been based on assembling and processing events for decades. However, the forming of event processing theory and principles did not commence until the late nineties. The first book presenting concepts and applications in this area was The Power of Events by David Luckham, published in 2002 [20]. Since then, a great deal of both theoretical research and commercial applications has been produced and presented. Even though the literature offers various definitions of the term event, it can be generally described as an occurrence within a particular system or domain [21]. To put it in other words, it signifies a change of state that happened. This abstraction enables the modelling of a broad variety of situations by means of events. The event can represent a human action, such as a door opening or order placement, an environment change like a rise in sea level or temperature, or any occurring issue in a system. Furthermore, the processing of several events can result in the composition of one or many highlevel events. The Complex Event Processing allows operating with events in a meaningful and sophisticated way, including their creation, reading, transformation, abstraction, and discarding [22]. The utilization of Complex Event Processing can be applied in various areas. Common scenarios are: monitoring, detection, dynamic behaviour and predictive processing, performed individually or combined. An example of monitoring and detection in the public sector is patient 21 2. DROOLS EXPERT AND DROOLS FUSION monitoring, where the nurse is alerted when a certain combination of events is recognized; as for commercial scenarios, one frequent application is fraud detection, where a combination of seemingly unrelated events signify suspicious behaviour. Another important requirement in many systems is to perform a problem analysis which can be achieved by a combination of searching through logged data and observing the events. One application of dynamic behaviour and predictive processing is, for instance, the stock trading system. Drools fusion is the module enabling the event modelling capabilities to the Drools rule engine, such as defining facts as events, event cycle management, temporal reasoning and sliding windows. Since the traditional Rete algorithm does not support temporal restriction on nodes, the Drools algorithm had to be enhanced [23] to provide features such as aggregation of values in time-based win- dows. 2.5.2 Event definition Event represent a special type of fact. An important requirement for events is that they are supposed to be immutable. They represent a change of state that happened, and therefore should not be redefined. The engine applies this fact in event lifecycle definition and optimizations. However, this does not determine the immutability of the event object. Event data enrichment is one of the possible use cases. To put it in another way, it is possible to enrich the event with additional data, but already established attributes should not be modi- fied. The declaration of facts as events is performed by using metadata tag @role. The events can be created from imported types, as well as new ones defined in drl: import cz.example.Person; declare Person @role( event ) end declare InnerPerson 22 2. DROOLS EXPERT AND DROOLS FUSION @role( event ) name: String age: int end The @role tag is necessary for the fact to be considered as an event, moreover the event can employ additional metadata tags: declare PowerBlackout @role( event ) @timestamp( blackoutStart ) @duration( blackoutDuration ) @expires( 3h ) end Each event is automatically assigned with the start timestamp corresponding with the time of insertion into the session. The tag @timestamp determines, that for this timestamp is used the class attribute blackoutStart instead of the time of the insertion. There are two types of events: point-in-time and interval-based. The point-in-time can be perceived as interval-based with duration equal to zero. All events are implicitly considered as point-in-time. The @duration tag labels the event as interval-based, where the duration is read from the blackoutDuration class attribute. As a matter of fact, each event has two timestamps, determining start and end of the event, where the end timestamp is constructed from the start timestamp and the duration. The automatic life cycle of events enables the removal of events that are no longer relevant to rules from the session. This expiration is calculated from temporal constraints and sliding windows. The @expires tag should override this calculation. 2.5.3 Clocks The assertion of the timestamp and temporal reasoning over the facts require the system to acquire the time from somewhere. The desired time can differentiate due to environment the system is running in. The time conditions for standard system operation differ from rules testing and simulations, or running in a special environment, such as 23 2. DROOLS EXPERT AND DROOLS FUSION a cluster. As a consequence, the engine is enabled to employ different clock implementations. The engine provides two clock implementations. The first is real time clock, which uses the Java Virtual Machine implementation and represents the option for standard use and flow. The second is pseudo clock, where the flow of time is easily manipulated. Without this option, scenarios using long time intervals would be difficult to simulate. The clock can be set for each session creation. 2.5.4 Temporal operators The events in Complex Event Processing based systems are required to have temporal attributes which enable the definition of their temporal relationships and temporal operation amongst them. Drools Fusion defines 13 temporal operators outlined by James F. Allen in [24] to determine all possible relationships between two events. The temporal operators are as follows: after, before, coincides, during, finishes, finished by, includes, meets, met by, overlaps, overlapped by, starts and started by. Some of them require interval-based events to be applicable. An example of after operator application in a rule condition: $sea1: SeaReport( $shoreId : shoreId, $temp : temperature ) SeaReport( shoreId = $shoreId, temperature > ($temp + 2), this after[1h, 2h] $sea1 ) A rule with such a condition will be activated if two events with same identification, and difference in temperature of at least 3, also meet the after operator. Figure 2.7: Illustration of using after operator in the rule. 24 2. DROOLS EXPERT AND DROOLS FUSION The operator determines that the difference between end timestamp of the first event and start timestamp of the second one is between one and two hours as it is depicted in Figure 2.7. This operator can be also defined using negative parameters for negative distance, or fewer parameters, where only one value would be coupled with positive infinity and no value generates an interval with 1ms and positive infinity. The other operators allow the determination of different temporal relationships between events and are thoroughly described in Drools Fusion documentation [25]. 2.5.5 Sliding windows The concept of sliding windows enables restriction of the stream of events to a defined and moving interval. There are two types of sliding windows: time based window and length based window. The time sliding window is a constantly moving time interval that takes into consideration only the events within the defined interval in terms of time. Figure 2.8: Time sliding window of three time units [6]. The Figure 2.8 illustrates an example of a time sliding window of 25 2. DROOLS EXPERT AND DROOLS FUSION three time units. Time units support milliseconds, seconds, minutes, hours and days. The following condition would apply only to events happening in the last thirty minutes. WarningEvent() over window : time (30m) The essential variable for length sliding window is the order of events insertion. The window takes into account not more than the defined number of inserted events. The following example applies the window for the last fifty inserted events. WarningEvent() over window : length (50) 2.5.6 Entry points The entry points introduce abstraction over streams. The system can have various event streams, for example each for differen source of events. The engine enables objects to be inserted either into the default entry point or to a named one. To put it another way, each entry point represents a different stream of events. There can be various motivations for the separation of events into streams. The streams can be homogeneous and contain only one type of events to increase the abstraction or the same types of events arriving from different sources might require being processed in a different way. In general, multiple entry points are used for partitioning the memory by the character and purpose of facts, and for decreasing cross products that can degrade the pattern matching performance. A simple example of entry points utilization in rules: rule "Passenger checks in at airport counter." when CheckIn( $passenger : passenger ) from entry-point "Airport Counter Stream" then // the passenger’s luggage is processed end 26 2. DROOLS EXPERT AND DROOLS FUSION rule "Passenger checks in from home" when CheckIn( $passenger : passenger ) from entry-point "Online System Stream" then // the passenger’s luggage is added // to automatic drop-off list end The checking in of the passenger is handled differently depending on the entry point where the checking event was inserted. Each event stores the information of the entry point it was inserted into. The Rete network containing these rules would have the ReteNode root followed by multiple nodes of EntryPointNode type. 2.5.7 Event processing modes The engine provides two modes of processing: cloud and stream mode. The processing mode defines the behaviour including time and temporal aspects. The default processing mode is cloud mode. There is no concept of time and its flow in this mode. As a consequence, it does not provide sliding windows, event life cycle, event ordering and clocks. In other words, all events are perceived as an unordered cloud. This mode is mostly targeted to be used with objects defined as facts, but it can also be employed for some scenarios including events that have no temporal relationships. The stream mode enables the processing of streams of events with the concept of time. Since it is not the default processing mode, it has to be established in the Knowledge Base configuration. The requirements for it to work correctly are the time ordering of events within a stream and time synchronization of streams through the session clock. 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 go- 27 2. DROOLS EXPERT AND DROOLS FUSION ing to be based on a new algorithm which merges concepts of multiple algorithms such as Leaps, Collection Oriented Match and Left and Right Unlinking. It targets the better use of parallelism and running in more constrained environments, for instance mobile devices [26]. Drools 6 is going to present context dependency injection and annotation driven development enabling sessions and bases to be injected. Furthermore, it allows the publishing of rules and processes as maven artifacts. Other innovations include the extension of Drools Knowledge Language in order to increase its expressiveness and power [27]. 28 3 Motivation to include Complex Event Processing in web applications 3.1 The role of the user in the aims of websites The growth and progress of the Internet is inseparably associated with evolution and advancement of websites. There are many types of them. Content-based websites profit from subscribed customers, sold pieces of content, or advertising. The scope for product-based and service-based websites is also quite large, from e-commerce and auction sites to cloud solutions. The common objective for these and a great deal of other types is represented by the user. The potential capabilities of websites increase every year. The first websites were static and offered the same content for every visitor. As the technology progressed, the content commenced to differ for logged users. Following advancements introduced techniques using identification of the user by storing information in the cache of the browser, dynamic web pages processing user data or storing and analysing the actions of the user. Further improvements are constantly being developed to ensure better attracting, profiling and predicting of the user and his or her actions. One of the companies pursuing the goal of the exceptional customer tracking is Amazon. With servers storing terabytes of data and millions of back-end operations every day it attempts to analyse the user data and recommend suitable products based on information in cache, searched products or reviews. The company also owns several patents regarding content personalization and use of product viewing histories [28]. However, aspects concerning the content adaptation are not the only ones to follow. Another appreciable aspect is detection of unsolicited behaviour. This can include various fields of interest where the apparent one is security. Each decade since the inception of networks, a new security focus has been introduced, namely risk assessment, securing of data centres, enterprise networks and the beginning of 21st century electronic commerce [29]. A great deal of present threats relate to the user. Misusing the sensitive data gathered from 29 3. MOTIVATION TO INCLUDE CEP IN WEB APPLICATIONS social networks or exploitation of computational power to create bots to impersonate the user are just examples of current concerns. Detecting the suspicious behaviour commence to be necessary. 3.2 Benefits of incorporating Complex Event Processing As has been established in the introduction to Complex Event Processing 2.5.1, an event can be described as an occurrence within a particular system or domain. This enables the perception and definition of any incident that occurred or action that was performed as an event. Even though the scope of the utilization of Complex Event Processing incessantly widens, so far there have not been many employments of it in web applications. This thesis considers the actions of users in web applications as events and explores their potential processing in order to enrich the web applications. One of the most important augmentation that Complex Event Processing provides is the temporal reasoning. The definition of a temporal relationship over the events and the means to accumulate them easily in a meaningful way enable new or more easily performed use cases in various areas to be embraced. It enables the owner of the web application, or the application itself, not only to monitor the behaviour of visitors, but also to react quickly to specific situations. The unanticipated attendance of an article published long ago in the last ten minutes could indicate some affairs just happening. The accumulation of negative rating in the previous hour should be further investigated and engender appropriate reaction, such as retracting the rated element. Due to the pace of nowaday life and the amount of competition on the Internet, the ability to recognize such situations and to respond to them promptly may account for the success or the failure of the website, in other words the profit or loss. For instance, recent considerable unsuccessful search on the website of an unknown Apple product might indicate a fresh announcement of it by the company and should result in immediate incorporation of the product and launching its pre-orders. The automation of the reaction can vary from the one handled by 30 3. MOTIVATION TO INCLUDE CEP IN WEB APPLICATIONS the person responsible responding to the created notification to fully automatic. An example of latter one can be the composition of main page. A disinterested or dissatisfied visitor is said to leave a page in 10-20 seconds, while the subconscious impression can be created in even shorter time [30]. The layout and content of the page can be established on various aspects, for example of what is currently happening, such as viewed, bought or discussed elements. Another example is creating heuristics for recommending products. The streams of events represented by such as the website itself, social networks, or review and benchmark magazines, could influence the recommendation list, for instance in terms of what other users of the same age bought in last hour. Fraud detection is one of the common scenarios of Complex Event Processing utilization. Seemingly unrelated events are identified in patterns, which can uncover a sophisticated fraud or another type of deception occurring in the system. The same techniques are needed in websites where the exact application depends on the nature of the website. It can be particularly used to detect the suspicious behaviour and then further analysed to determine the origin and character of it, whether it is deliberate action, an error or false alarm. This can be specially combined with temporal reasoning in consequence of the fact that the events can be relevant or appealing for only certain period of time. There are many advantages of using Complex Event Processing instead of performing code with same purpose over data in a standard way. Not all events are of interest to the system. As a matter of fact, the system might actually use only a small amount of events. As the events are represented by objects and expire after the time window employing them passes or by another expiration policy, they do not require being stored in a database of another storage to be processed. The traditional process would have to store all the data that events represent and then apply some enquiries over them, not to mention the management of their deleting or keeping. This has even greater impact in situations where the storage access is one of the restricting aspects. The advantage of employing Drools Fusion to be the place for Complex Event Processing capabilities is in the rule engine. The logic represented by rules can be easily modified and broadened. Further- 31 3. MOTIVATION TO INCLUDE CEP IN WEB APPLICATIONS more, it can be managed by the domain experts and not only by the programmers. 3.3 Existing solutions Although the number of vendors offering solutions based on Complex Event Processing is increasing, the quantity of areas they have successfully penetrated is quite limited so far. The most frequent utilizations can be found in fields of algorithmic trading, financial fraud detection or network monitoring. The only company found acknowledging the use of CEP in the scope of web applications is SeeWhy, which specializes in e-commerce analysis. They use this technology to ameliorate shopping cart abandonments. According to their statement, up to 70% of customers abandon their shopping cart before the completion and their service can assist in resolving 30% of it [31]. 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. THE 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. Figure 4.1: Application screenshot of browsing products. 4.2 Analysis and design 4.2.1 Roles Users are classified into three different groups. Each group is represented by a separate role and each role is associated with diverse 4. See https://fusionweb-ixi.rhcloud.com. 34 4. THE 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. THE 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 Figure 4.3: Entity-relationship diagram. Figure 4.3 depicts the entity-relationship model employed by the application. Most entities are used for describing products, orders and users. However, there are two entities which store results from event processing. This does not imply the necessity of the outcome to be in a form of stored records. The rule consequence may have various forms, from sending a notification email to influencing the application. 36 4. THE 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 weren’t taken into bigger consideration, as they considerably reduce the information regarding the action origin, in other words, they wouldn’t 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. THE 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 gen- erated. 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. Figure 4.4: Simple illustration of situating Drools into architecture. 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. THE 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 ses- sion. 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. THE 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 class 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. THE 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. Figure 4.6: Detailed Drools session assembly. The KnowledgeBuilder is configured to also be constructed with integration of own accumulate functions. Accumulate functions enable the rule to easily iterate over collection of objects, apply them to 41 4. THE 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. Figure 4.7: Example of a command button with listener producing events. 42 4. THE 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 ses- sion. 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. THE APPLICATION Figure 4.8: Overview of user action resulting in notification. 4.3.4 Firing the rules As it has been established, the insertion of the fact into the session only creates the activations of the rules. To execute the consequential parts of rules, the rules need to be fired. Drools enable the firing of rules in two general ways. The first is one-time firing by means of fireAllRules method on the session and the second is managing of different threads with fireUntilHalt method execution on the session, which fires a rule when it is activated. Due to the fact that managing a own threads in applications is strongly discouraged within Java EE container [33], the first way is employed. The appropriate approach to this depends on the character of the rules. If the rules can be activated only by event insertion and it is important to execute the rule consequence as soon as possible after the activation, the firing method can directly follow the act of insertion. However, if rules contain constraints dependent not only on event 44 4. THE 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 class FireRulesScheduler { @Inject private DroolsResourcesBean drools ; @PostConstruct @Schedule ( hour=" ∗ " , minute=" ∗/5 " , second=" 0 " , p e r s i s t e n t=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. THE 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. THE 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 mes- 47 4. THE 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. THE 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. THE 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. THE 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. Figure 4.10: The two Drools clock implementations [6]. Due to the fact that many of the rules employs the temporal rea- 51 4. THE 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 one’s 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. THE 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 tech- 54 5. CONCLUSION niques and frameworks should be developed. 55 Bibliography [1] Bali, M. (2009). Drools JBoss Rules 5.0 Developer’s 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/intltechventures- presentations-2008-01-26-introduction-to-drools [4] Amador, L. (2012). Drools Developer’s 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/workflow- engines [10] Gualtieri, M. & Rymer, R. R.. (2009, August 4). The Forrester WaveTM: Complex Event Processing (CEP) Platforms, Q3 2009. 56 BIBLIOGRAPHY Retrieved from ftp://ftp.software.ibm.com/itsolutions/SOA/ wave_complex_event_processing_cep_platforms.pdf [11] Mijovi´c, 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-expert- docs.pdf [13] Agüero, 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 BIBLIOGRAPHY 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-best- practices2011octfinal [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-81- VOL1/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-fusion- docs.pdf [26] Proctor, M. Life Beyond Rete - R.I.P Rete 2013 :). (2013, January 02). 58 BIBLIOGRAPHY Retrieved March 30, 2013, from http://blog.athico.com/2013/01/life-beyond- rete-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-do- users-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-complex- event-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 BIBLIOGRAPHY [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 Figure A.1: Simple class diagram of significant events. 61 B Deploying the application to JBoss Application Server 7 1. Download the latest final version of JBoss Application Server 7 (currently it is 7.1.1 from http://www.jboss.org/jbossas/ downloads). 2. Extract the downloaded archive to the destined folder. 3. Create the database for the application in the database system. 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. Configure the server: (a) Open file server-folder/standalone/configuration/ standalone.xml (b) Add the appropriate data source (inside the datasources xml element), example: jdbc:mysql://localhost: 3306/fusionweb?zeroDateTimeBehavior= convertToNull com.mysql.jdbc.Driver 62 B. DEPLOYING THE APPLICATION TO JBOSS APPLICATION SERVER 7 mysql-connector-java-5.1.22-bin.jar root 1234 false false false The jndi-name must correspond to the one in persistence.xml file (default is this). The connection-url must correspond to the relevant url for connecting to the database. The driver must be the same as the defined driver (in the next step). The security element represents the credentials for logging into the database. (c) Add the corresponding driver (inside the drivers xml element), for example: com.mysql.jdbc.Driver 63 B. DEPLOYING THE APPLICATION TO JBOSS APPLICATION SERVER 7 (d) Add the security domain (inside the security-domains xml element). Example: The security domain specifies the authentication of the users. The value of dsJndiName must be same as the data- source. (e) Increase the timeout for the deployment - as during the time the deployment is created, the tables filled and the session constructed, it might not meet the default timeout for the deployment. To the deployment-scanner xml element add attribute deployment-timeout="600". (f) Save and close the file. The configuration can also be man- 64 B. DEPLOYING THE APPLICATION TO JBOSS APPLICATION SERVER 7 aged through the administration console of the server. 6. Start the server. It can be achieved through IDE or the execution of the appropriate file in the server-folder/bin folder (for Linux based operating systems standalone.sh). 7. Deploy the application - either through IDE, console or copy the FusionWeb.war file into server-folder/standalone/deployments. Explore the application on: http://localhost:8080/FusionWeb/ 65