CEP and BRE / BRMS redux
Posted by Paul Vincent
With the recent news that one of the 2 main pure-play BRMS vendors has got itself acquired, it might be a good idea to catch up [*1] on the differences between Business Rule Engine (BRE) and Business Rule Management System (BRMS) software components with their equivalents used in Complex Event Processing:
Business rules vs Decisions
If you compare, for example, the Business Rules Group definition of “business rule” [*2] with the types of rules we automate in CEP or BRMS tools, you find that the former mostly equates to constraints on the business, and the latter are types of behavior (as in: IT process implement behaviors, or decisions). BRMS tools manage decision-type rules that are in turn derived from “business rules for business people” (or “source rules”). The different philosophies are apparent in the 2 OMG standards, SBVR (covering business constraints) and PRR (for system behavior) [*3].
A Complex Event Processing system usually defines business rules as declarative decisions (in, for example, a rule-driven CEP system), or maps the rules to flows or procedural language constructs. Sometimes a CEP system just defines facts (such as a continuous query indicating some interesting complex event), or presents the complex events (such as in a dashboard) to support some manual decision-making process.
Business rules relate to Events
Quoting from Ron Ross’ book [*4]: “Processes connect to rules via events … which can fire one or more rules”.
Quoting from Dave McComb’s book [*5]: “A more likely successor [to explicitly called rule engines] will be a business rules engine that operates on message traffic. ”
So these experts (in the related fields of business rules and semantics) seem to agree on the close connection between business rules and events: a corollory is that moving business rule definitions (and management thereof) closer to the source event would be “A Good Thing”. Until recently there has been no mention from the BRMS vendors of the Complex Event Processing space; the only BRMS vendor comment so far seems to provide a somewhat defensive response by implying that BRMS are for rich rulesets and CEP is for fast events. In the enterprise world, of course, you often need both rich rulesets and fast event handling. “Rule management” is as much required for the low-latency rules as for the high-latency workflow / BPM rules (as usually served by the BRMS vendors). Combining the 2 is clearly going to be an interesting evolution, already started with the TIBCO BusinessEvents rule-driven CEP product.
BRMS standards?
One interesting caveat to the propagation of rule management to Complex Event Processing, is the lack of appropriate standards at the rule management level. You can use SBVR to specify business constraints, and derive the likely events from the term and fact model (such as new car rental agreement, new customer, rental car return, etc). But you also need to map them to appropriate processes. For the most part, customers are delighted enough with the agility they get from rule management without demanding cross-vendor standards. Yet. But standards are often (as commented at a recent event) a prerequisite for federal etc adoption.
BRE Performance
… is, like in the Complex Event Processing field, a somewhat “hot topic” among certain Business Rules Approach fans. Although the vendors in this space tend to be quite relaxed on this - performance is almost always “sufficient”. And this is true, as far as rule engine performance goes. The main problem for the BRE vendors is that they get blamed for transaction performance, when the fault really lies in the data marshalling needs and the app server: there is not much point in shaving 10% off your rule transaction time of 40ms, if you are reliant on a database transaction which costs 400ms. This is where CEP-based rule execution can be surprisingly effective over traditional BRE approaches, as CEP systems generally avoid database transaction costs.
Notes:
[1] See earlier posts on this topic: Differences between a BRE and a rule-driven CEP engine (part 1) and (part 2).
[2] “A business rule is guidance that there is an obligation concerning conduct, action, practice, or procedure within a particular activity or sphere.”
[3] Both SBVR and PRR rules are “representations” of business logic - so both can claim to define “business rules”, although naturally SBVR notations are meant to be more “business friendly”. Usually PRR is used to explicitly define “decisions” including event-based decisions and rules.
[4] See Business Rules Concepts, 2nd Edition (thats the one with the green cover - google books only has the old version), Ch2, pp34. Note that in Ron’s view, you apply events to business (constraint) rules which in turn can generate events to indicate violations. Such as the rule “each customer has 1 and only 1 account manager”, which is applied to events such as newCustomer, deletedAccountManager, setCustomerAccountManager, and can generate appropriate exceptions when the constraint is not satisified.
[5] See Semantics in Business Systems, AppA, pp297.
Complex Event Processing (CEP), Rules, Trends | 30 July 2008 |
6 Comments
Other Links to this Post
RSS feed for comments on this post. TrackBack URI
By PatternStorm, July 30, 2008 @ 06:49
Hi Paul,
Given the definition below:
Definition:
A Rules Engine can be interactive or not. A non-interactive RE is passed a set of rules and a set of facts and executes the rules on the facts, an interactive RE is initialized with a set of rules and is passed facts as they occur: it executes the rules each time it receives a new fact.
1.-A rules-based CEP engine is an interactive RE.
2.-Is it true that most of today’s available REs are non-interactive? Would like to see a classification of most popular RE according to whether they are interactive or not.
Thank you very much!
Regards,
PatternStorm
By vincent, July 30, 2008 @ 07:22
Hi PatternStorm: Normally (or rather, historically) “interactive” in a BRE context implies interactive expert systems (i.e. a dialog with an end user). All BREs “interact”, some synchronously (eg SOA decision services, the main BRMS/BRE vendor domain) and some asynchronously (usually needed for CEP). But the classification is not clear-cut: an SOA decision service from a conventional BRE vendor may also be able to receive and send events during its transaction processing (i.e. interact).
And of course, there is more to CEP than simply “interactive” execution of rules…
Cheers
By vincent, July 31, 2008 @ 07:37
Update to “Business rules relate to Events”
I commented there wasn’t much response from BRMS vendors to CEP. Well maybe there are 2:
- Open source BRE/BRMS announces CEP version
- BRMS vendor’ blogger working on CEP offering
The latter makes an interesting claim that “some vendors [are] claiming CEP will kill BRMS”, which seems odd as (by virtue of the 2 vendors above, and TIBCO’s work) it seems *convergence* is much more likely. Perhaps they haven’t seen any of David Luckham’s presentations on CEP where he talks about managing the rules in event processing?
Update(2): Oops! The 2nd link above has been taken down - probably “Too Much Info”. Google cache still has it if you are really interested though…
By Charles Young, July 31, 2008 @ 17:24
With regard to CEP, there is currently a huge amount of paddling going on just below the surface within the rules engine community - much more than is immediately visible. My own (no doubt controversial) view is that CEP has caught the rules engine community by surprise. It’s not as if the basic principles of CEP were unknown to them. There is well documented research into pattern match-based forms of event processing using production systems reaching back over decades. It’s just that no major rules engine vendor has, until recently, taken CEP seriously. That has changed massively over the last year or two, although it will take time for the results of that change to work through into actual shipping product. Watch out, though. As vendors start to combine their mature pattern matching, set-based rule engines with temporal logic and other CEP functionality, they will give the existing CEP engines a real run for their money. CEP represents a whole new dimension of possibility to them in regard to how they evolve their technologies, and it is a natural fit with those technologies.
I absolutely agree that there is a clear distinction to be made between a BRMS and a CEP tool, especially at the level of usage scenario, user interaction and tooling. One point to remember, though, is that the fundamental underlying processing is often, in essence, computationally equivalent. These two worlds overlap greatly at a lower level. It is therefore really very easy to see how existing rules engine technologies could be extended to handle concepts such as multiple event streams, sliding windows, etc., as ‘first class citizens’. They already major in pattern matching. Most decent engines can handle CEP concepts today to some level (typically falling short of the full promise of CEP), albeit by requiring rules developers to do some additional coding around the engine of their choice.
Beware of the myths that surround issues like performance, supposed inability to handle uncertainty, etc. Too many of the comments I’ve seen about rule processing engines are seriously misinformed.
One minor comment. I didn’t quite get the point about database transaction costs in ‘traditional BRE approaches’. The BREs I’ve used have no dependency on databases, except possibly as rule stores, and do not incur such costs. Some do have direct support for optionally running rules against data held in databases, and so may incur such costs if these features are used. If you had the retrieval of rule sets from rule stores in mind, then this is generally only a ‘first hit’ problem. Any half-decent engine will cache rule sets for repeated use. Most engines also offer performant alternatives to retrieving rules from databases. I don’t see that this is fundamentally different to the CEP world.
By vincent, July 31, 2008 @ 23:43
Hi Charles: Good comment, thanks. Two points:
1 - fully agree on the overlap between transaction-oriented and CEP-oriented BREs. Basically the appearance of the former will (if they do enter this space) authenticate another angle to the existing CEP space:
— low latency low complexity CEP engines
— high scalability distributed CEP engines
and then
— business rule-based CEP engines.
2 - the database transaction costs are an overhead of the typical transactional useage of a BRE: get data associated with the invocation event, process decision, send decision back and update the DB. Most BREs (including CEP-BREs like TIBCO BusinessEvents) also include direct DB access functionality so this can be rule-driven, but in a CEP engine this might only be used for boot-strapping the stateful memory, not on every event. CEP engines have mechanisms for avoiding expensive DB transactions, like in-memory databases. So the point is a usage, not a technology one for existing BREs…
[Note: Charles is a respected MS BRE expert -- see for example this post on how the MS BRE uses rule update events - looking forward to seeing how the MS BRE might play in this space! ]
By vincent, November 20, 2008 @ 03:24
Tim Bass has started a discussion on CEP vs (or rather as) BRMS in his blog:
http://www.thecepblog.com/2008/11/19/should-we-simply-rename-cep-brms/
To some extent, CEP event processing rules are defining (business) facts: the combination of events X, Y, Z represent business fact (or event) E. This may or may not be useful to be managed by the business (ie in some BRMS). So these are overlapping, not subsuming, concepts.