I attended the 1st International SOA Symposium in the Amsterdam ArenA at 6 and 7 october. The reason why I attended this symposium was because EDA came to the scene. But I really was disappointed.
Clemens Utschig-Utschig and Manas Deb (Oracle) together spent a complete presentation titled - "SOA and EDA" - to the subject. I did not one moment notice the architecture aspect during their talk. Clemens and all the others I listened to mention EDA and start talking about complex event processing; that is not architecture, that is technique. The clue with EDA is to drive your architectural approach from a business events perspective, just like SOA is driven from a business services perspective.
CEP is a way of processing messages (fair enough to name these messages "events"). That was clearly understood and explained by all of the "EDA-speakers". But EDA is about how business events drive the overall architecture of the IT-systems and it is about how these events should be modeled. EDA it is not primarily about the ability to process and correlate streams of thousands of messages per second as the speakers were trying us to believe. The real EDA paradigm was one step to far for all of the respective speakers, unfortunately.
Another misconception was that the speakers I heard were trying to convince the audience to only pass the references to data in the message, WRONG! One of the architectural principals behind EDA is self-contained documents that describe events. Passing references (primary keys) is a performance trade-off, not an architectural principal. Passing references creates dependencies to sources the might be out of your scope or control; it assumes knowledge of reference data. Passing references is a pattern toward tight coupling in stead of toward loose coupling.
My conclusion is that EDA is not yet well understood in the market. Perhaps next year?
Tuesday, October 14, 2008
Market does not understand EDA
Subscribe to:
Post Comments (Atom)
Posts
15 comments:
Hi Jack,
there's a lot of confusion in the market about what is CEP and what is not CEP. I won't enter today that discussion, but there's a school of thought (far from the Stream Processing/SQL based one) that thinks that CEP is about modelling complex events, where a complex event is a situation and a situation is just some arbitrary well-defined combination of simple events or other situations. This school of thought uses this event metamodel to organize situations in layer and construct a hierarchy of layers so that situations in a layer combine among themselves to produce situations in the layer above, recursively, following the principles of layered architectures. This is a powerful approach for EDA when it comes to model events...After all EDA has been around for a long time albeit processing events one at a time, what the approch above provides is a powerful way to model events so that EDA can process situations.
Regards,
PatternStorm
Doesn't shock me that vendors and their representatives are choosing to focus on the technical aspects, or to redefine ideas to suit their own products. Main thing is that people like yourself keep them honest.
I was interested in the tradeoffs you discover around having a single canonical data model in practice though, I realize you've blogged about this before and I intend to read all that content, but in addition I wondered if you'd read this excellent blog entry on the topic:
http://service-architecture.blogspot.com/2006/08/single-canonical-form-not-for-soa.html
In particular I'm interested in the process you go through to deal with semantic dissonance when designing your CDM, which must be quite a major issue?
Hi Jack,
What is your opinion in this respect on the architecture pattern referal-index (verwijsindex in dutch), as it finds application in many Governance initiatives and creates a common civil information 'infrastructure'? E.g. youth-care-chain, patient-care-chain (epd).
I do not immediately link this to tight coupling?
Cheers,
Rijk van Vulpen is enterprise architect at Caerleon.
Hi Jack,
Re: pointer vs. fully described, I couldn't agree more. The event needs to be fully described to accurately reflect the business at the time the event occurred and (as you say) to keep the event generators and subscribers (process, apps, engines, people etc) extremely loosely coupled.
Oddly, yesterday at a business lunch, I used this very example as an often misunderstood EDA/EP practice.
Brenda
Hey Jack -
if the message did not make it across during manas' and my presentation, I am sorry, that was surely not intended.
Here are some of my thoughts that might help to clarify it.
I *do* believe that a) the industry and the market understand EDA (and they do since 10 some years now, just look at all the event based apps) and b) the scientific world understands EDA for a while now too (at least reading through many of the papers published on that topic)
So what is the big deal about EDA it's about state changes that eventually cause or reflect more complex changes (if they being layered and aggregated), simply speaking.
An event by scientific definition is a change of state (with nothing more and nothing less in it) - the provider of the event has the capability of expressing this event, and *should* provide substantial means to gather the context around it (or create more events that leave it to the consumer to *recreate* the context on their side)
A convenient thing when it comes to events is that - yes the *change* is fully self contained, but *never* the context, and this is what we referred to.
I am happily following up by email with you if you want.
clemens dot utschig at oracle dot com
Hi Clemens,
Thanks for your clarifying comment. I agree with you on the aspect of event processing. But what I try to say is that I miss the business aspect of it.
Just as SOA adds the "business" aspect to methods to be invoked, I think EDA adds the "business" aspect to events to be processed. A bunch of services doesn't make an SOA, neither does a bunch of events make an EDA.
To me it appears that everybody knows what event processing means, but hardly anyone focuses on the business level of events. Especially not the high level "simple" business events, which is the starting point of EDA.
I will spend another posting on why - IMHO - it is important in EDA to also express the context of the event in the message and not only a reference to the context.
-Jack
Jack -
ok fair enough. I have hoped that the example with the airport we have discussed, helped that understanding - and why especially a combination of SOA and EDA makes a lot of sense.
Nevertheless, here is one additional thought, when it comes to the value of events. It allows for real-real time, and the aggregation of those events helps to be able to react faster to foreseeable, or unforeseeable (chains of) events.
Does that make sense?
best clemens
-Clemens,
I totally agree with you on the real-time aspect. That is a great value of event processing.
These postings of mine might clarify why EDA - as an architectural style - is more than just event processing.
How to mediate semantics in an EDA
How to implement a loosely coupled process flow (EDA)
Using Events to Bridge Decoupled Service Boundaries
I hope it makes any sense to you.
-Jack
It's sad to see EDA being hi-jacked by vendors once again. Didn't we see that already with SOA?
Thanks for the good post.
EDA, DEP.
Both words that I did not know until I read the RSS-feed. Ok, I left Architecture 2 years ago. Still I did my share in defining and managing a SOA-Architecture with a large European insurer.
SOA is already getting unhyped again and will probably regain strength in zwo- three years.
Nothing introduced like any three letter word will be understood possibly next year, as indicated in the reference.
I would rather postulate that too few people understand a meaning of a phrase containing architecture or event within 15 to 20 years. It took 20 years to fully understand OO. It might take another 15 years to understand MDA.
SAP when it came out with net-weaver was speaking of ESOA (event driven SOA). The term is not used anymore to my knowledge.
I am a little bit worn out by following hypes every other three months. They don't add value. Reading "code complete" by Steve McConnell would add content. But that's to old-fashionend today:)
Good blog, and I agree with you. However, something you said in your blog caught my attention:
"Another misconception was that the speakers I heard were trying to convince the audience to only pass the references to data in the message, WRONG!"
Pragmatically speaking, it is many times simply not possible to pass the entire scope of data in an event (e.g., a policy, quote, or benefits information). This type of data is quite complex and sometimes cannot be "bundled" in a message.
I find this to be one of the more difficult areas of EDA. In a perfect world an event should at least contain the data that changed or was added to prompt the business event. This gets further complicated when you consider than several concurrent processes can act on the same data. In many ways having a reference to that data is better than having many copies of it floating around.
Mark Richards, Sr. Architect, Collaborative Consulting, LLC
@Mark Richards,
You are right, Mark, but only if you run your EDA in a context under one control. If the events flow to area's out of your control it may become a burden to pass only reference data.
That's why an architectural principal should be not to pass references in the first place. Only performance trade-offs could overrule this principal, of course.
-Jack
An event should NEVER include the whole thing, strictly, it is *only* the changed context, nothing else, the rest the event engine is supposed to aggregate and join from other events that are useful, there or missing (= non event).
What manas and me talked about, where the implications, of people designing a message, payload based system containing the whole context.
@Clemens,
Thanks for your opinion. What you describe is a way toward strong coupling; consumer and producer must have a common datapool (e.g. an Oracle Grid). In my opinion that is a trade-off in favor of efficiency. In terms of fast event processing it is probably the best way to go at this moment in time.
However, I evangelize a way toward loose coupling, where consumer and producer don't share anything but the message. In terms event communication at the level of autonomous business functions (EDA) that is the most effective (the most loosely coupled), and often - across strong control borders - the only possible.
The arguments sound a bit like those of a normalized relational database versus a denormalized data warehouse; it depends on what your purpose is.
-Jack
Well I must say that author has really good view about the topic and I will share it to others.
Post a Comment