vincent
Tue, 23 Oct 2007 00:04:06 +0000
There have been a few mutterings in postings from “CEP industry colleagues” that could be construed as implying that we at TIBCO overplay the importance of the role of rules in Complex Event Processing. Others seem to downplay the idea of rules for CEP. So its time to set the record straight…
1. Rules are-a-subset-of CEP techniques. There are plenty of other ways to do event filtering, correlation and analysis (such as neural nets). But if-then rules might well be the simplest and easiest to understand, for many tasks.
2. Rule = query + action. A lot of the earlier ESP vs CEP debate centred around the definition of event cloud and unordered events versus ordered events. The plain truth is that a few applications (like some in algorithmic trading) rely on quickly detecting certain patterns in as short a time as possible. But there are many more applications where the value in event processing is not just the initial “situation assessment” but in the “aggregated situations” and “business rules applied in complex situations”. This is where it becomes useful to have not just a query language approach to CEP, but a more sophisticated rule-driven approach, where the actions can be the generation of informational events (i.e. inference) and more sophisticated behaviors can be defined.
2. Rules != Rule Engine. The majority of rules in the IT world do not bother with a “rule engine” [*1]. They are programmed procedurally or in flow diagrams. But using a rule engine allows you to define rules declaratively (delegating control flow to the engine), which is good when you have rules that
(i) need to be defined as they occur (per “agile development”),
(ii) need to change as the application area develops (”agile maintenance” or “agile development”, depending on whether you have gone into production yet),
(iii) are large or variable in number - putting rules in the right order in a procedural flow or program can waste a lot of time on programming a suitable control flow, with the usual effect that certain rules are duplicated in code to cause future problems.
3. Rule language != CEP language. Most rule languages are designed to deal with IT data models, not real-time or time-based event models. So usually some extensions are needed before a rule language can be used for CEP. And of course I can also define a CEP language that is not obviously rule-based.
4. Business rules != Rule language. Attendees at BR Forum [*2] this week [*3] will hear lots about business rules, and lots about rule representations. They will also hear about how people join the 2 together (i.e. map policy “X” to production ruleset “Y”). This is because rule languages (for rule engines etc) are not the same as business rule statements seen in policy documents, mortgage rate sheets, diagnosis charts etc. Usually some other representation is needed, mapping business readable rules onto the executable rules (a mapping that is not standardized across vendors, by the way). A great example of this is the simple decision or look-up table.
5. Business rule management overlaps-with CEP management. David Luckam’s end-keynote at the recent Gartner Event Processing summit commented on the need to do “rule management” on CEP applications. He was commenting on that fact that CEP applications embed business rules to be useful. But of course there is a need to do model-driven development and entity management of rules, events and processes, and trace back to the business models.
- - -
So: business rules and rule engines are not the same as CEP, but hopefully you can see where they overlap and why they are interrelated. Certainly at TIBCO we have found the declarative inference engine (from the business rules’ IT world) extremely powerful and useful in the CEP world. And there is plenty more mileage in the concept yet!
- - -
Notes:
[*1] There are many uses of the term “rule engine”. The simplest is to consider a rule engine as something (an engine!) that takes rules and data as input, and outputs something (usually actions or updates to data). The basic idea is to separate out rules and the data that feeds them, where the rules themselves are a form of data loaded into the engine (usually less frequently than the “normal” data, I might add). So this covers a wide range of sins, which is why event CASE tool vendors claim they have rule engines. In the rule industry, there is usually an implied additional characteristic of “inferencing” where the control flow of the rules is also controlled by the engine, and rule execution impacts later rule executions. Which is where the shouting usually starts at BRForum…
[*2] I attended John Rymer’s tutorial on the topic of Forrester’s framework for “selecting a business rules platform”. Naturally, loads of vendors attended and gave John a hard time - I’m sure though that the Forrester characteristic selection process is of course nothing like the latest Greg The Architect episode . There was LOTS of feedback, including the question from someone else on why he didn’t consider CEP tools. Well of course, the answer is that CEP tools are not called “business rules platforms”, even when they are fulfilling the same role…
[*3] Without any sense of irony, the BRForum organisers have put our presentation on CEP and business rules in parallel with a panel on … “Emerging Trends in Enterprise Decisioning”! Oh well. Perhaps CEP will be covered there too!


Source...