Earlier we looked at the coarse-grain delta between commercial BREs and rule-driven CEP engines. Lets look now at the implications of these, and also why BRE technology is good for Complex Event Processing.
1. CEP is an inherently [*1] long-running process, whereas (as commented earlier) most BRE’s are focused on stateless decision services [*2]. This results in a special requirement for long-term rule and working memory control, as an important requirement for system agility (from the need for business agility) is the ability to change the rules “on the fly”. If I am running a stateless rule service in a transactional manner, rule updates can be quite simple (I simply reload the rulebase in between transactions). Stateful rule service rule updates naturally need to be handled in a more sophisticated manner.
2. BRE’s traditionally deal with rules (and rulesets) and object models [*3]. CEP engines deal with events and event-processing mechanisms (e.g. rules), but as events can also refer to objects, object models need to be made available too.
3. Many BREs are also associated with Business Rule Management Systems (BRMSs), although not exclusively. For example, TIBCO iProcess Decisions falls into the category of “BRMS” but does not include a “rule engine” per se, but instead maps rules to an efficient Java service (usually invoked during a BPM process). However, the benefits of rule management can also apply to CEP – we will look into more detail on BRMSs and their specific benefits for EDA and CEP later …
One could make a case that rule-driven CEP was to EDA what BRE rule services are to SOA. But rule-driven CEP tools like TIBCO BusinessEvents can operate as both, sharing rules as necessary: so perhaps this classification is already redundent!
Notes:
[*1] “Inheritantly” long-running because if I am monitoring events over time, then some time must elapse in order to be able to receive the events and reason over them. Of course, this could be a relative term – perhaps there are scientific monitoring CEP applications that run only in a few seconds.
[*2] Note that in theory stateful and stateless rule execution modes are interchangeable: a stateful rule service can be restarted with new data in a transactional stateless manner, and a stateless rule service can be left running in a stateful manner. Obviously there are optimizations for each mode.
[*3] Most BREs also include a concept for orchestrating ruleflows (sometimes executed by a separate orchestration engine). The “explicit orchestration” approach constrasts with concepts like state management which are better suited to complex event manipulation.
