Here are some thoughts on how this should be structured from Giles Nelson's blog (http://apama.typepad.com/my_weblog/2008/10/cep-eda-and-soa.html):
<<I'd like to add my voice to the debate this week (here, here and here) on how Complex Event Processing (CEP) fits into the wider software architectural themes of Service Oriented Architectures (SOA) and Event Driven Architectures (EDA). Although I think I know how these three areas relate to one another fairly well, I was able to further clarify my thinking this week by spending some time with Neil Macehiter of Macehiter Ward-Dutton Advisors, a UK based software analyst. I found our discussion enlightening as Neil had a slightly different way of looking at these things than I had heard expressed previously. So let me try and express my own view on this in as clear a way as possible. 1. CEP is a technology. SOA and EDA are not technologies. SOA and EDA are philosophies for the design and build of modern distributed computing architectures. 2. A SOA is a loosely coupled set of services, the functionality of which closely reflects an organisation's business functions and processes. A SOA will typically use modern, Web services technology and standards for implementation, but is not required to. Building a SOA requires much thinking about the services that the SOA will use. 3. An EDA is a loosely coupled architecture, the endpoints of which interact with one another in an event-driven fashion. Information flows around the EDA as events. An EDA will have endpoints which produce events and endpoints which consume events. An EDA works in a "sense and respond" fashion. Building an EDA requires much thinking on the event-types that the EDA will use. 4. An EDA may use business focussed services as endpoints. An EDA may therefore also be a SOA but it does not have to be. 5. CEP is a capability within an EDA, providing analysis and matching of multiple events being sent between endpoints. You can have an EDA without CEP. 6. If you're building your architecture and focussing on defining event-types, it's very likely you're building an EDA. 7. If you are using CEP then you have at least the beginnings of an EDA because you will have been focussing on event-types. Your EDA may a simple one, with one event producer and consumer, but it's still an EDA.>> Gervas --- In [email protected], Michael Poulin <[EMAIL PROTECTED]> wrote: > > I agree with Rob. However, coupling between sender and recipient in EDA is shifted into more delicate area of intentions (sender) and interests (receiver). How technically quantify these categories is a question. > - Michael > > > > > ________________________________ > From: Rob Eamon <[EMAIL PROTECTED]> > To: [email protected] > Sent: Tuesday, December 2, 2008 8:42:39 PM > Subject: [service-orientated-architecture] Re: Roch Clarifies Some Key Terms > > > Not a bad set of definitions. A couple of discussion items: > > EDA is not necessarily pub/sub. > > EDA does not result in "completely decoupled" systems. In a > brokered/intermedia ted approach, they are more loosely coupled, but are > still coupled in two ways: 1) the messages they exchange; 2) the > mechanism over which they exchange them. While the recipient doesn't > care exactly where the message originated, it cares that *something* > originates it and does so via the intermediary to which it is connected. > > -Rob >
