One consistent question we get from outside the CEP market is: what is the difference between a “standard” Business Rules Engine (or BRE) and a (rule-driven) Complex Event Processing engine? This is particularly interesting because a rule-based CEP engine like TIBCO BusinessEvents shares many features with normal BREs.
Let us look at the main extensions that CEP requires over “standard” BREs, and then in a later post we’ll look at the advantages the BRE approach brings to CEP.
1. Optimization for stateful rule services
Most BREs today are deployed as “decision services”, and are used in “stateless” transactions to make “decisions” as a part of a business process. A CEP application is instead processing multiple event streams and sources over time, which requires a “stateful” rule service optimized for long running. This is an important distinction, as a stateful BRE for long-running processes needs to have failover support – the ability to cache its working memory for application restarting or distribution. And of course long-running processes need to be very particular over issues like memory handling – no memory leaks allowed!
2. Rule language including event references
Obviously a CEP application needs to reason over (new) events, so the concept of event-driven or Event Condition Action rules is required.
3. Rule language including temporal and historic constructs
More complex event rules will be interested in comparing event histories over time. This means that the rule engine needs to incorporate mechanisms to store events (or have seamless access to stored events) and their associated metadata (such as timestamps). Such storage obviously needs to be resilient and fast, for example using distributed caching technology.
4. Internal structures to help organize and manage event correlations etc
Although optional, CEP rule engines do not need to rely just on rule processing (and rulesets) for organizing behavior. A typical mechanism for organizing event-based information aggregation is a state model, event processing being defined as state transitions encoded as rules.
5. Links to an Event Driven Architecture
The idea behind CEP is real-time event processing – which in turn necessitates a real-time event infrastructure to “feed” the CEP system with events.
—–
None of the above points explicitly exclude the use of a standard BRE in CEP applications – indeed many have been used as such in the past because of the obvious advantages of a declarative rule-driven approach to handling complex event correlation and business logic. But the above should give some indication as to the customizations / extensions that need to be added to a standard BRE to make it a CEP technology.
Note: Of course, there is no reason the BRE vendors cannot extend their BREs to include some or all of the CEP features above. Indeed some BREs already do.
