JBoss.orgCommunity Documentation
In the Drools vision of a unified behavioral modelling platform, Drools Fusion is the module responsible for enabling event processing behavior.
Before we examine Drools Fusion, we need to define some terms. The terms "Event" and "Complex Event Processing" have multiple, overloaded, and sometimes confusing definitions. The goal of this guide is not to attempt to unify all the competing definitions for these terms, but before we start describing Complex Event Processing, we need to define, in informal terms, just what we mean when the guide refers to an "Event."
In the scope of this guide:
Event, is a record of a significant change of state in the application domain. In this context, "domain" refers to the set of data, conditions, and the environment in which the application is running.
For example, in a stock brokerage application, when a sell operation is executed, the operation causes a change of state in the domain. This change of state can be observed on several entities in the domain, such as the price of the securities that changed to match the value of the operation, the owner of the individual traded assets that change from the seller to the buyer, the balance of the accounts from both seller and buyer that are credited and debited, etc. Depending on how the domain is modeled, this change of state may be represented by a single event, multiple independent (or "atomic") events or even hierarchies of correlated events. In this guide, the term "event" refers to the record of the change on a particular piece or pieces of data within the domain.
Events have been processed by computer systems since they were first invented. Throughout computer and software the history, systems responsible for event processing have referred to event processing with different names and and have used different methodologies. It wasn't until the 1990's however, that more focused work started on Event Driven Architecture (EDA) with a more formal definition on the requirements and goals for event processing. Older messaging systems started to change to address these requirements and new systems started to be developed with the single purpose of event processing. Two approaches for event processing developed: Event Stream Processing (ESP) and Complex Event Processing (CEP).
In the begining, Event Stream Processing was focused on the capabilities of processing streams of events in (near) real time, while, in contrast, the main focus of Complex Event Processing was on the correlation and composition of atomic events into complex (compound) events. An important milestone in the development of event processing was the publication of Dr. David Luckham's book The Power of Events in 2002. In this book, Dr Luckham introduced the concept of "Complex Event Processing" and how it could be used to enhance systems that deal with events. Over the years, both approaches have converged into a common understanding and today systems implementing either approach are all referred as "CEP systems."
A brief definition of Complex Event Processing is:
"Complex Event Processing, or CEP, is primarily an event processing concept that deals with the task of processing multiple events with the goal of identifying the meaningful events within the event cloud. CEP employs techniques such as detection of complex patterns of many events, event correlation and abstraction, event hierarchies, and relationships between events such as causality, membership, and timing, and event-driven processes." | ||
--Wikipedia |
In other words, CEP is about detecting and selecting the interesting events (and only these events) from an event cloud, finding their relationships and inferring new data from them and their relationships.
For the remaining of this guide, we will use the terms Complex Event Processing and CEP as a broad reference for any of the related technologies and techniques, including but not limited to, CEP, Complex Event Processing, ESP, Event Stream Processing and Event Processing in general.
Event Processing use cases, in general, share several requirements and goals with Business Rules use cases. These overlapping characteristics happen both on the business side and on the technical side.
On the Business side:
Business rules are frequently defined based on the occurrence of scenarios triggered by events. Some examples are:
In an algorithmic trading application: perform an action if the security price increases X% compared to the day opening price, where the price increases are usually denoted by events from a stock trade application.
In a monitoring application: perform an action if the temperature on a server room increases X degrees in Y minutes, where sensor readings are usually denoted by events.
Both business rules and event processing queries change frequently and require immediate responses for the business to adapt itself to new market conditions, new regulations and new enterprise policies, or a system to addapt to changes in its operational environment..
From a technical perspective:
Both require seemless integration with the enterprise infrastructure and applications, specifically with regard to autonomous governance, including, but not limited to, lifecycle management, auditing, security, etc.
Both have functional requirements such as pattern matching, and non-functional requirements such as response time and query/rule explanation.
Even though they share requirements and goals, historically, Event Processing and Business Rules were separate disciplines. Implementations of each tend to focus on on one discipline or the other.
JBoss Drools was created as a rules engine several years ago. However, to become a single platform for behavioral modelling, it assigns the same importance to these three complementary business modelling techniques:
Business Rules Management (BRM)
Business Processes Management (BPM)
Complex Event Processing (CEP)
In this context, Drools Fusion is the module responsible for adding event processing capabilities into the platform.
Supporting Complex Event Processing, though, involved much more than simply understanding what an event is. CEP scenarios share several common and distiguishing characteristics:
Usually required to process huge volumes of events, but only a small percentage of the events are of real interest.
Events are usually immutable, since they are a record of state change.
The rules and queries usually on events must run in reactive modes, i.e., they must react to the detection of event patterns.
There are usually strong temporal relationships between related events.
Individual events are usually not important. The system is concerned about patterns of related events and their relationships.
The system is usually required to perform composition and aggregation of events.
Based on these common characteristics, Drools Fusion has defined a set of requirements to be fulfilled in order to support Complex Event Processing appropriately:
Support Events, with their propper semantics, as first class citizens.
Allow detection, correlation, aggregation and composition of events.
Support processing of Streams of events.
Support temporal constraints in order to model the temporal relationships between events.
Support sliding windows of interesting events.
Support a session scoped unified clock.
Support the required volumes of events for CEP use cases.
Support (re)active rules.
Support adapters for event input into the engine (pipeline).
In the Drools unified platform, all features of one module are leveraged by the other modules. This means that while the above of requirements that are not fulfilled by Drools Expert, Drools Fusion is able to take advantage of Drools Expert's features such as like Pattern Matching. In the same way, all features provided by Drools Fusion are leveraged by Drools Flow (and vice-versa) making process management aware of event processing and vice-versa.
In remainder of this guide, we will describe each of the features Drools Fusion adds to the Drools unified platform. All these features are available to support different use cases in the CEP world, and you are free to select and use the ones that will help you model your business use cases.