--- In [email protected], "Gervas Douglas" <[EMAIL PROTECTED]> wrote: > ...that of event-driven architecture (EDA), a seemingly new > term which has at best blurred lines with the more widely used SOA > acronym. So up next we will take a look at what constitutes EDA and > its relevance to the SOA market.
No, no, no. EDA didn't blur any line with SOA. They are orthogonal notions. > ... > come up with Web Services Eventing (WS-Eventing) by the W3C or Web > Services Notification by OASIS, at first glance the use of these > standards will likely spark the thought of the EDA/SOA marriage. Why? Use of WS-* doesn't automatically imply that SOA principles are being applied. And why "marry" the two? Why not just apply the principles from both approaches (as well as others) to the business architecture, the enterprise architecture, the integration architecture, the application architecture, as needed? > From a CEP standpoint, one would be hard pressed to > admit the technical justification of SOA or anything related to > services in order to make CEP a reality, Right. Because SOA, EDA and CEP are each independent notions. None of them imply the need for the other. > The sell > point to most CEP solutions is that they offer real time event > processing, something which is in stark contrast to the static > nature of most middleware event processing systems, which generally > entail lag times, I have to call BS on this one. "Middleware event processing systems" can be as real-time as needed--but typically it isn't needed and "near real-time" is good enough. For example, TIBCO Rendezvous is arguably one of the classic cases of "middleware event processing systems" applied to the financial industry. > there is a certain reluctance in combining SOA, EDA and > CEP in the same sentence, Using them in the same sentence is fine. Just don't try to lump them all under one umbrella. > The reality is that SOA has a much to gain from CEP, as does CEP > from SOA. I disagree. I think enterprise architectures, application architectures, integration architectures, etc. have much to gain from SOA, EDA and CEP concepts. For example, if one applies SOA and EDA principles to an enterprise architecture description, its still the enterprise architecture description. Likely, the EA description incorporates many principles from various approaches. So why limit its name to just one or two of its characteristics? I think we'd all be better served if we stop trying to "marry" different approaches under a single banner. -Rob
