First from Giles Nelson at: 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. Comments welcome.>> followed by Jack van Hoof at: http://soa-eda.blogspot.com/ <<Giles Nelson joined the debate about CEP versus EDA. I am very happy with that because he is deeply involved in the evolvement of Apama, which is a state-of-the-art complex event processor marketed by Progress Software. Giles expressed his view in 7 clear statements. I (almost) totally agree with him, though I have one remark with regard to his point 7 where he states: If you are using CEP then you have at least the beginnings of an EDA because you will have been focussing on event-types. This is a dangerous statement that could create confusion. The events in CEP are merely technical events, messages, which not necessarily represent business events or any other real-life events. In CEP data from incoming message streams are correlated within time-frame constraints. This data may represent "anything", e.g. arbitrary spawned clouds of arbitrary mathematical figures which are written to arbitrary ordered messages, without any functional or time-based relationship. The time-frames CEP uses to constrain the correlations between the messages could be the time-frames in which the messages are received by the CEP-engine and not content based on when the message was created or when the figures were spawned or generated. So I would not claim using CEP as being the beginning of EDA. From an EDA-perspective I would rather claim using CEP as being the finishing implementation.>> Gervas
