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.

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! ]

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.

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…

And of course, there is more to CEP than simply “interactive” execution of rules…

Cheers

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