[snip] > 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.
...but there are significant architectural challenges in achieving the correlation of thousands-of-events, and once you are in a position to correlate those events, some great opportunities for optimising business processes are opened up. I guess if you see a need for CEP within an organisation, then architecturally that requirement is best met by designing in from the ground up. Put another way, retrofitting CEP is (often) a serious challenge. > 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. I've used pass-by-reference (aka out-of-band messaging) approaches to solve architectural issues where the event itself (and key meta data) was important, but transmission of the full business object for each and every event was not only infeasible from an infrastructure perspective, but also wasn't required by the majority of recipients of the event. A practical example might be invoicing, where including a reference to an invoice document image - of interest to a minority of recipients, but still required to ensure 'integrity' of the event object from a business perspective. One point of view is that it is just an extension of, say, doing a lookup against an order number included in an event. I don't see pass-by-reference as a violation of EDA architectural principles - it is actually one of the documented EDA architecture patterns where I work - and there is no need for it to result in tightly coupled systems *provided* that the full business object is exposed through a service-like interface in a canocalised form. > My conclusion is that EDA is not yet well understood in the market. > Perhaps next year? Can you expand on this a bit more? EDA has been around since pretty much the dawn of time in technological terms - at least 15 years - do you perhaps mean the marriage of EDA & SOA, or CEP specifically? Patrick
