CEP is Not a Just a Technology and Not Just a Tool
I read the debate (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). More comments and blog posts followed (including this one, and this one). Frankly speaking, I was surprised to see so much misunderstanding on fundamental concepts. For example, Giles Nelson blogged:
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.
The statement “CEP is a technology” is a bit misleading, demonstrating how little folks understand CEP and how quick they are to reduce CEP to a “technology” that fits their software solution, versus a design philosophy for solving complex problems.
I generally agreed with the overall concept of what Jack van Hoof tried to say; however, Jack also implies that CEP is just some small piece of the puzzle that is a part of an overall EDA approach. This is both right and wrong.
First of all, you can perform CEP without an EDA, so folks in the debate are comparing apples and oranges. EDA is a design pattern, or philosophy, for processing events with extreme loose coupling. CEP is a design pattern, or philosophy, for creating complex situational knowledge from a cloud of events. CEP can be, and has been, performed with or without an EDA or an SOA. See, for example, this presentation, Event Driven Architecture (EDA), November 2, 2006.
Mark Palmer add his inconsistently wrong on view on CEP into the discussion:
“We didn’t use CEP because it didn’t exist. Until recently.”
This is absolutely false. Every major voice in CEP/EP has stated that CEP/EP has been around for a long time. What did not exist, until recently, was the three letter acronym “CEP” and the handful of niche player vendors positioning their products as “CEP”. In fact, processing complex events has been around as long as I can remember (more than 20 years on work in IT networks), especially in the network and security management space.
Of all the voices in the debate, Opher Etizon correctly points out that CEP and EDA are orthogonal. Opher has been consistant and correct in this point. You do not need an EDA or SOA to do CEP and that is a fact. Nor do you need CEP to do EDA or SOA, and that is a fact.
David Luckham then asks,
Hmmm. Someone asked me a while back if “CEP was going to get ‘confused’ like SOA is now”.
Might be worth a community discussion on how to try avioding that happening! Or can we?
In reply, frankly speaking, CEP has been “confused” since the term was minted, as I pointed out in my first keynote talk on event processing, see slide 4 of my presentation, Processing Patterns for PredictiveBusiness, titled A Vocabulary of Confusion.