In a large organization, no single IT staffer will be able to observe all the millions of system events and glean from them a pattern worth paying attention to. It’s a problem with the level of knowledge decreasing in proportion to the rising amount of data.
Back in 2007, Red Hat joined an effort to craft a system for automating the process of detecting actionable patterns from huge amounts of system data. Maybe one human being can’t detect the patterns in a trillion data points, but a rules engine could. This rules engine is called Complex Event Processing (CEP). Last week, the company announced it’s ready to integrate the results of its work into its business rules engine, JBoss Enterprise BRMS 5.2.
CEP forms the backbone of an open source project called Drools. Its vision is to enable an understanding of what’s happening in a system on a very large scale, and to enact rules and processes in reaction to those occurrences. The developers of CEP understand that system events in and of themselves say nothing of relevance, but a rule processing system – perhaps using procedural logic, maybe even neural networking – can at least give them handles with which they may be addressed. And with those handles, broader rules may be written using a language based around Java, called Drools Fusion.
“CEP deals with complex events. A complex event is a set of simple events. For example, a sequence of large withdrawals may raise a suspicious transaction event,” explains author Michael Bali, in his book Drools JBoss Rules 5.0. “The simple events are considered to infer that a complex event has occurred.”
Simple events are the sort recorded in logs all the time; complex events are more the type that responds to rules, using the simple events as arguments. Bali offers some examples related to a fraud detection system. Here, transactions such as withdrawals are considered complex events – they require a chain of simple events to complete. Suppose a chain of three or more withdrawal transactions took place within a three-minute period, and the sum of those withdrawals constituted more than 90% of the account holder’s 30-day moving average balance. That chain of events should raise an alarm, so Drools Fusion can be applied to the task of stating how the system should respond.
Rules in Drools Fusion look… kinda like Java. Each rule is a module, the simplest of which is divided into two clauses. The when clause lists all the conditions upon which the rule is invoked, in separate lines. All of the conditions here must prove true. The then clause gives the procedural code for the response, often in the form of calls to Java methods.
This example is a clip of a screenshot from the familiar Eclipse environment, showing an example formation of an event that updates a database’s entry for a stock price.
Drools documentation insists upon referring to events as “first-class citizens,” treating them as the principal indicator of states of change in any system. The rules processing engine processes these events in parallel. Then Drools Fusion specifies how the system should respond to events, as well as to the strange absence of any events.
As Drools Fusion documentation on JBoss.org reads, “The same way in that it is necessary to model rules and processes that react to the presence of events, it is necessary to model rules and processes that react to the absence of events. Example: ‘If the temperature goes over the threshold and no contention measure is taken within 10 seconds, then sound the alarm.’ Drools Fusion leverages on the capabilities of the Drools Expert engine, allowing it complete and flexible reasoning over the absence of events, including the transparent delaying of rules in case of events that require a waiting period before firing the absence.”
JBoss veteran developers are already familiar with Drools over the past four years of work. But now, support in Enterprise BRMS 5.2 will take it out of the gestation phase, and into the main front end used by business managers and COOs.
