CEP is an innovative technology; it deals with two problems that are prominent and relevant today: real-time processing and high-volume of data. I argue that CEP is here to stay.
Nonetheless, one can’t say it has become mainstream yet.
I believe the reason being is that CEP is not particularly simple; for instance, I am sure one will find several different definitions of the term CEP if one looks around. Partly, I think the culprit is that we’ve spent too much time trying to define what is CEP, rather than what it does. With that intent on mind, I will be presenting a CEP Design Patterns at the upcoming J1 2009.
The idea is to focus on simple, practical problems around event processing, and then show how these problems can be solved with different CEP design patterns. The material is not yet finalized, however so far I am planning on discussing the following patterns:
- Event filtering
- New event detection
- Partitioned event filtering
- Old event detection
- Event enrichment
- Event aggregation
- Batched event aggregation
- Event correlation
- Missing event detection
The current schedule is to present on Wed at 3:00. Hope to see you there.
A World of Events 
A few corrections…
Here is the updated list of CEP design patterns:
1. Event filtering
2. New event detection
3. Event partitioning
4. Old event detection
5. Event enrichment
6. Event aggregation
7. Event batching
8. Event correlation
9. Application time-stamped Events
10. Missing event detection
The session is scheduled at: Wednesday 03-Jun-09, 01:30 PM-02:30 PM.
Hi Alex,
Folks have been processing complex events for two decades prior to creating an abstact, ill-defined, three letter acronym “CEP” and many, many folks continue to build very nice systems to process complex events (today) and do not use the hollow marketing term “CEP”.
In other words, processing complex events has been around for decades and will continue to be around for many more decades, regardless of software vendors naming their latest stream query processors “CEP” and blasting the airwaves with repetitive phrases.
This biggest hurdle to the advancement of “complex event processing” (honestly speaking) is all the folks in the “CEP” field who are ignoring two decades of prior art, and a mountain on ongoing work today, who are actually processing complex events versus blowing smoke rings that form the letters “CEP” 🙂
On the other hand, in the long view, all those folks will be footnotes in the larger “CEP” community, which is the community of experts working to solve complex event processing problems without all the marketing hype.
As many experts have mentioned, the “CEP community” is 5 to 10 years (maybe more) behind the folks actually process complex events today.
Yours faithfully, Tim
Hi Tim,
I don’t disagree with you, (complex) event processing is not new, but I would also advocate that it is common for a technology to undergo several iterations through its life. One only hopes that each iterations helps improve, and most importantly, raises the abstraction layer for that technology. Consider request-response, how much different in its end-goal is invoking a remote method through IIOP from requesting a web service over SOAP?
It is not just about being to compute, but being to compute with a simpler model, otherwise we would still be using a Turing Machine to solve all problems.
A decade ago, I remember having to change the implementation of an SNMP manager to be able to detect if an expected SNMP trap had not yet arrived in some stipulated time, as defined by its MIB. This took weeks to be accomplished. If I were to do this today, it would take me 5 min to write a CQL query to achieve the same goal.
Nonetheless, I strongly concur that we must not ignore existing knowledge in the field. With that in mind, I will ask you to point me to some concrete problem and solution that is being disregarded and I will investigate how we could try to solve it using our models.
Cheers,
Alexandre