Discussions

News: Market does not understand EDA

  1. Market does not understand EDA (6 messages)


    Taken from: Thoughts on SOA and EDA 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 Event-driven Architecture (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?

    Threaded Messages (6)

  2. Better reference?[ Go to top ]

    I think it would be beneficial if you provided a link to a sound introduction of EDA, specifically the issues you raise here regarding its architecture component, to those unfamiliar with it so we can better understand your concerns that you encountered here. Just seems like I walked in to the middle of a ongoing discussion here.
  3. Re: Better reference?[ Go to top ]

    You might read this article (PDF). Or this posting comaring SOA with EDA on my own weblog. You might also try the EDA tag on my weblog. It will definitely bring you new insights.
    I think it would be beneficial if you provided a link to a sound introduction of EDA, specifically the issues you raise here regarding its architecture component, to those unfamiliar with it so we can better understand your concerns that you encountered here.

    Just seems like I walked in to the middle of a ongoing discussion here.
  4. <....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....</blockquote> Advocating passage of references is a good tip that shows that speakers knows what they are talking about. It is oftentimes plain impossible to pass all the data on the event and plain unnecessary. Most of the time it is better to treat event message as notification message and leave it up to the receiver what to do with it and when. Furthermore the passage of reference relies on presence of data grid that holds the data and is able providing clients with needed data quickly and reliable. The 'loose' coupling means nothing when it is not defined what type of coupling we are talking about, for example we could have 'loose' coupling at build time, that means that we do not need exact information about the data structure we will get at runtime. But that does not mean that we do have 'loose' coupling at the semantic level.
  5. Your description of the terms EDA and CEP is very good and IMHO generally intelligible for people with Knowledge in modern Information Technologies - therefore the most part of the TSS-Community. Additionally: Your own and the following blogs/informations are excellent references and sources to extend the EDA/CEP-Knowledge to almost anyone: http://en.wikipedia.org/wiki/Complex_event_processing http://soa-eda.blogspot.com http://complexevents.com/ http://www.thecepblog.com/what-is-complex-event-processing/ http://www.ibm.com/developerworks/library/ws-soa-eda-esb/ http://java.sys-con.com/node/117740 http://tibcoblogs.com/cep/category/soa/ http://blogs.progress.com/soa_infrastructure/2008/06/event-driven-so.html http://www.coral8.com/blogs/cep-technology-blog http://epthinking.blogspot.com/ http://elementallinks.typepad.com/bmichelson/2006/02/eventdriven_arc.html ... and further references by this sites ... Have a nice weekend Roland
  6. Services[ Go to top ]

    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.
    That seems to be a somewhat extreme view point. Passing references certainly will require system services for resolution of references, and can be viewed as an aspect of an overall architecture that provides the means to resolve the references (and that will clearly mediate and provide a degree of decoupling in the system, as required).
  7. That's because...[ Go to top ]

    Not enough marketing events are held for "event-driven architecture." More events for EDA!