There have been some great posts on event processing recently. Tim Bass started it off with CEP is Not BPM, BAM, BRE, BRMS or SOA and got a ton of really interesting comments - well worth reading. Mark Palmer responded with Smart Order Routing and CEP - Made for Each Other while I responded with Business rules, decisions and events. Tim posted again with CEP is Not Low Latency Messaging, EAI or ESB and now it's my turn again!
I think Paul Haley's comment in one of the threads is particularly relevant - Complex Event Processing is a combination of many elements:
- Complex Event Detection and Correlation
- Decision Making
- Actions or Processing
If we are to develop useful definitions we must drop below the level of products to clearly articulated "lumps" of functionality and then discuss both how those lumps can and must interoperate and what sensible commercial packaging might look like. So a CEP product must handle event detection, event correlation, decision making and processing but it must also allow an external decision making environment to be used to make decisions that are "bigger" than the event processing context and it must be able to invoke a process management environment where a large number of sequential actions must be taken.
I posted about this before and I would refer you to this post about IDC's approach in which I used this graphic.
 Subscribe to this blog by RSS
Hi James: a few comments / suggestions about your version of the IDC graphic:
- CEP is a technology / approach, so there is no reason why one cannot use CEP-based technology (e.g. real-time decision engine) for a decision server
- sense and respond is a classic use case for CEP, but appears in a list of processes sharing info via the ESB
- BAM is another application area that is a classic use case for CEP
- complex events can drive processes (per process warehouse), but surely the bottom boxes are processes too?
Probably some of these are roles and some are technologies and some are applications...
Cheers
Hi James and Paul,
Good discussion. I have added one more post to the mix:
More on Why Routing is Not Complex Event Processing
http://www.thecepblog.com/2008/09/04/more-on-why-routing-is-not-complex-event-processing/
Cheers.
Yours faithfully, Tim
It’s a fascinating discussion, and is certainly helping to further shape my understanding of the role and nature of CEP, and the contact points between CEP, decisioning, routing, service buses and business process automation. Over the last year or more, the only times I have violently disagreed with people in the CEP world is when they have misunderstood or misrepresented the true nature of underlying rule engine technology or denied the obvious overlaps with some of the concerns that CEP must address. Of course, low-level technological correspondence does not imply equivalence at the application level - business rules applications are not designed to address CEP requirements. On the rules side, however, we have three decades of experience of building underlying low-level technologies that clearly offer something of interest and worth to the CEP community. At that level, CEP is good for the rules community, and I believe the rules community is good for CEP.
I think Tim does us a service by drawing out the central distinction of CEP – detecting higher-level event abstractions using sophisticated analysis within event clouds; that requires, amongst other things, efficient inferencing over dynamic and ever-changing data sets (the data, here, representing events). Now, where have I come across that idea before...?