"So CEP is not EDA, EDA is more than CEP. Promoting CEP as being EDA is far too simple. And yet that is what is happening in the current IT space."Mark Palmer from StreamBase answered some
"Especially the vendors of event processors focus too much on CEP as being EDA".
"CEP, in fact, is a really important element of an effective EDA. It's not a required element, but it sure makes it better"That's how I presented it at JavaOne back summer 2007, and this still happens to be true - no matter how vendors are mashing up various concepts about it to try to differentiate one from each other (CEP and Grid, CEP and Web2.0, CEP and DDS, CEP and edge processing, CEP and SOA, CEP and BRMS, CEP and XTP etc.).
Here are two excerpts from the presentation I delivered with Thomas Bernhardt from Esper/EsperTech fame:
If you talk to folks using CEP (build or buy - does not matter) in some industries such as investment banking, they'll tell you this has nothing to do with SOA but has to do with XTP.
It's time to learn from past history.
A similar debates occurred not that long time ago around the SOA and ESB terms (2005 article on ComputerWorld). For the record, back in 2001 ESB and SOA did not even existed. Yet, some visionaries such as Sonic folks introduced ESB as a COTS product, despite established or maturing MOMs presence such as TibcoRV, MQ, or JMS-based/J2EE MOMs and a whole set of in house built solutions.
With no surprise, in 2008, I'd be curious to hear someone that would disagree with the statement below, which is in fact a copy/paste/replace from comments happening right now in the blogosphere rel. CEP and EDA as stated at the beginning of this post:
An ESB is not SOA, SOA is more than ESB. Promoting ESB as being SOA is far too simple. And yet that is what happened in the early days (back in 2001).Got it now? Here is mine bold claim:
A CEP engine is to EDA what an ESB is to SOA.
(And it's also more than just that)
Posts
5 comments:
Excellent post, very much agree, Alex, with the loose analogy that ESB is to SOA as CEP is to EDA.
However, I have one nit to pick on the subject of ESBs (not that your raised it, per se, but the analogy does). Having been involved with the creation of one ESB, IONA's Artix, and commercially with another, Sonic ESB, the notion that ESBs are disruptive is facile thinking. ESBs, although they are excellent tools, are simply an evolutionary technology, whose close ancesters were CORBA, DCE, and even simple sockets. ESBs were just a better, standards based version of these previous generations of middleware.
CEP, on the other hand, brings fundamentally disruptive capabilities to EDA; the ability to express event-based computing logic that's aware of streaming events, temporal relationships, causal relationships, and handle the volumes of event rates that are found in typical event driven systems - these are are revolutionary, not evolutionary, technology breakthroughs that ESB does not contain.
- Mark Palmer
http://streambase.typepad.com/streambase_stream_process/
@Mark,
I think CEP is not really revolutionary either. Event processing and correlation evolved from interupt handling in computer systems and actuator/sensor technologies in industrial processes. Disruptive is that these technologies can now be applies to business events at an enterprise level. Thanks to networking, ESB, standaardization and generic event processors.
-Jack
Just because CEP evolved from other sensor and industrial processes, doesn't disqualify them from being "disruptive" (which obviously a subjective term). Most CEP-based solutions, in fact, don't even have an ESB - most use a middleware technology that's 24 years old - TIB. So I think that argues against "networking, ESBs, and standardization" as what's disruptive.
But even if we choose to disagree, whichever way you chose, events are indeed a good, modern, perhaps disruptive way of building modern applications.
If I am being asked "tell me how CEP is revolutionary", I'd argue this is because it provides an higher abstraction to deal with streams, time windows and causality as first class citizens in the programming/development/composition model (depending the implementation but end result is the same). An analogy would be procedural / object oriented programming. You can say it is evolution (and the name makes this explicit sometime to help adoption and promote reuse of past practice and knowledge - f.e. C++) but its revolutionary in its implications.
Post a Comment