+1. What's odd is that the concepts of EDA have been around for quite some time yet, as so often seems to be the case, the A part is ignored and the majority zeroes in on implementations/applications (IMO, CEP is a type of application).
-Rob --- In [email protected], "Gervas Douglas" <[EMAIL PROTECTED]> wrote: > > <<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?>> > > You can read this blog at: > > http://soa-eda.blogspot.com/ >
