The marketing folks and their friends are buzzing with hype. Well intended, they want to convince the marketplace that EDA is really a type of SOA, or that EDA is an evolution of SOA. Unfortunately for the end user, they are mostly off target.
On this topic, I tend to agree with Dr. Mani Chandi. Mani gave an excellent talk at the recent Gartner Event Processing Symposium titled, Evaluating Costs and Benefits of Event-Driven Applications. In his keynote presentation, Dr. Chandi did not make any marketing statements about EDA (and events) somehow being the “magic” missing from SOA. Instead, he focused his keynote on the differences between SOA (request-reply) and EDA (proactive event push) and how to determine the best architectural pattern (EDA, SOA or both) when designing an application.
I was really pleased to listen to a CEP presentation based on sound design principles and not on the “EDA piggybacks on SOA market share” story to promote CEP and EDA. Most, if not all, good network engineers know that orchestrated request-reply is quite different than asynchronous event processing. Only marketing folks would convince us otherwise, hoping to somehow get the CEP “camel’s nose” under the “SOA tent”!
There is a downside (more than one!) to trying to put the CEP nose under the SOA tent. First of all, SOA, while a great idea, suffers from over hype and the increasing weight of it’s less-than-successful status, even after years of over marketing. Secondly, EDA and CEP actually have a chance of success. SOA has seen such a lack of progress that the analysts continue to redefine it, so it will eventually fit somewhere!
If you fly high enough, the snow bears, the igloos and the snow all look the same – and we are seeing folks flying snow blind in the EDA and SOA space.
Network engineers have been dealing with events and EDA in the form of SNMP traps for many years, and SOA in the form of polling devices for information for the same amount of time. Experienced engineers don’t debate which is better, SNMP traps or SNMP polling, they use the appropriate pattern based on solid design principals and engineering tradeoffs, just like Dr. Chandi discussed in his recent presentation.
EDA is not SOA. SOA is not EDA.
EDA is EDA. SOA is SOA.
Let’s don’t send CEP on an ill-fated flight to the future of event processing with a large SOA stone around it’s neck.