Just as SOA adds the "business" aspect to methods to be invoked, in my opinion EDA should add the "business" aspect to events to be processed in order to structurally mature the IT-landscape that supports the business. A bunch of services doesn't make an SOA, neither does a bunch of events make an EDA.
And from an architectural point of view, EDA is even a lot more than event processing from a "business" event perspective as stated above.
E.g. think of the architectural challenges of semantics mediation, extremely loosely coupled process flows and transaction control. And think of security in a extremely loosely coupled environment: authentication, authorization, encryption, credential assertion, non-repudiation. All of these aspects are not explicitly addressed in CEP (Complex Event Processing), but are in EDA.
CEP is just one among these aspects. The overall architecture from a business events perspective is called EDA: Event-driven Architecture. And, on the other hand, EDA does not only deal with complex events (correlations) but also with simple events.
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.
Especially the vendors of event processors focus too much on CEP as being EDA. That is completely wrong and won't help us one step further beyond SOA as we know it today.
Vendors, please change your attitude and help the business to seriously mature their IT-landscapes in stead of proclaiming techniques and products as architectural styles!
Monday, October 27, 2008
EDA versus CEP, once again...
Subscribe to:
Post Comments (Atom)
Posts
9 comments:
For quite a while now, we have been trying to explain to people that Service Oriented Architecture (SOA) is a lot more than Just A Bunch Of Web Services (JBOWS).
So I plan to start using a new acronym - JBOCE - Just A Bunch Of Complex Events.
See my SOAPbox blog.
Unfortunately, that is happening in most companies nowadays, mixing architecture principals with implementation methods. I wonder what caused this? Is this because of the vendors or just certain people in IT department to use it for bragging purpose to get the budget from the business.
Hi Jack,
I fully support your point of view, who wouldn't?
Thanks for putting it in such a clear words.
CEP deals with a subset of the aspects of an EDA.
Why aren't the vendors talking about EDA instead of CEP? EDA has a potential comparable to SOA, where's IBM?
Regards,
PatternStorm
Hi Jack - It's been a while, but I'm glad to be posting in response to your thoughts on my new channel at StreamBase. I posted some thoughts here:
http://streambase.typepad.com/streambase_stream_process/2008/10/eda-and-cep-wheres-the-beef.html
Basically the question I was raising is: "Who is causing the confusion?" and "Perhaps the reason the industry focuses on CEP is because it's the disruptive element of EDA?"
- Mark Palmer, StreamBase
Hi Jack,
I'm definitely of the same opinion as you on this matter. Good job in trying to beat this message into peoples minds. It's necessary to try to sort out this mess of SOA/EDA/CEP before the whole CEP/EDA thing dies out because it's used and thought of in a wrong way. Keep up the writing!
/Marco
Great topic. My raw take: a CEP engine is to EDA was an ESB is to SOA.
Details here.
Agree on Alex's comment. Architecture is not vendor products. A lot of companies are still in the mentality of EAI time.
Hi Jack,
Thanks for post. My comments are here:
http://www.thecepblog.com/2008/11/10/cep-is-not-a-just-a-technology-and-not-just-a-tool/
Yours sincerely, Tim
I have to agree - there is a real need for clarity of definitions, without the hijacking of definitions to suit product vendors
Post a Comment