CEP, EDA and SOA

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.

Comments welcome.

Comments

[Jack van Hoof]

Hi Giles,

Thanks for stating it this clear. I totally agree with you. Though I have one remark with regard to point 7. The events in CEP are merely technical events, messages, which not necessarily represent business events. In CEP data from incoming message streams are correlated within time frame constraints. This data may represent "anything", e.g. arbitrary spawn clouds of arbitrary mathematical figures. I would not claim this as being the beginning of EDA.

-Jack

[Opher Etzion]

See my comment here:
http://epthinking.blogspot.com/2008/11/on-head-and-tail-of-eda.html

[Tim Bass]

Dear All,

My comment may be found here:

http://www.thecepblog.com/2008/11/10/cep-is-not-a-just-a-technology-and-not-just-a-tool/

Yours sincerely, Tim

[John Aker]

You have mentioned "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"

Question:

Can CEP exist without EDA, if so how?

Thanks,
John

[Giles Nelson]

John - CEP can be used without a wider view of an EDA to tactically solve a point problem. The use of CEP to implement algorithmic trading strategies in financial markets might be one such instance. However I believe that in using CEP one begins thinking about events and event types and that one therefore has the beginnings of an EDA where such concepts are fundamental. One might not think in terms of explicitly creating the beginnings of an EDA but nonetheless, by thinking about and using event concepts, one has.

[Haitham El-Ghareeb]

Thank You so much for such clear and nice definitions and clarifications Gervas that we really need.