CEP와 EDA의 관계와 정의내리기로 지금 한창 관련자들은 바쁜 중.
Giles Nelson

이라는 자가 자신의 블로그에 CEP와 SOA그리고 EDA에 대하여 다음과 같은 정의 및 구분을 지었다.
CEP is a technology. SOA and EDA are not technologies. SOA andEDA are philosophies for the design and build of modern distributedcomputing architectures.A SOA is a loosely coupled set of services, the functionality ofwhich closely reflects an organisation’s business functions andprocesses. A SOA will typically use modern, Web services technology andstandards for implementation, butis not required to.Building SOA infrastructure requires much thinking about the services that the SOA will use.An EDA is a loosely coupled architecture, the endpoints of whichinteract with one another in an event-driven fashion. Information flowsaround the EDA as events. An EDA will have endpoints which produceevents and endpoints which consume events. An EDA works in a “sense andrespond” fashion. Building an EDA requires much thinking on theevent-types that the EDA will use.An EDA may use business focussed services as endpoints. An EDA may therefore also be a SOA but it does not have to be.CEP is a capability within an EDA, providing analysis and matchingof multiple events being sent between endpoints. You can have an EDAwithout CEP.If you’re building your architecture and focussing on defining event-types, it’s very likely you’re building an EDA.If you are using CEP then you have at least the beginnings of anEDA because you will have been focussing on event-types. Your EDA may asimple one, with one event producer and consumer, but it’s still anEDA.

사람들이 알고있는 내용과 크게 다르지는 않는 정의들이다. 하지만Tim Bass란 이는 CEP는 단지 기술이나 툴뿐만이 아니며 EDA와 상관없이 IT역사에서 언제나 있었던 기술내지는 패턴이었음을 이야기하고 있고, 줄곧 CEP에 대한 전문적인 글을 써온Opher는 전체적인 내용에는 동의를 하면서도 몇가지 토를 달면서, 또 다른 논쟁인CEP가 먼저냐 EDA가 먼저냐에 대하여 그것은 의미없는 일이다, 어떤 고객은 전사 아키텍처를 먼저 생각하지만 어떤 고객은 툴 도입에만 신경을 쓸 수도 있으니 그때 그때 다르지 않겠냐는 입장이다. 어쨌든 웹상에서 EDA, CEP전문가들이 어떻게 보면 별로 중요하지도 않을 것 같은 개념에 열을 올리면서 커뮤니티를 만들어가고 있는 모습에서 EDA와 CEP의 밝은 미래를 엿볼 수 있을 것 같다.