webMethods has put out a series of articles on SOA (SOA Made Simple). The latest installment comes up with a new term “EDA” or Event Driven Architecture. And like SOA, it is not really a new thought pattern.
I have to say after reading the article that I don’t really agree with their attempt to draw a distinction between SOA and the new EDA. The sticking point to me is the thought that SOA is request/reply and EDA is more pure asynchronous messaging being driven by events/triggers etc. There is nothing about SOA and it’s concepts that require a request/reply or synchronous architecture. SOA can also be event driven and frequently is. SOA is a concept on how services are constructed and wired not how they are invoked or triggered.
Honestly this looks like an attempt to make SOA or now the new EDA fit a product suite. A lot of other vendors are attempting to do this as well. Enough of my opinion here, tell me what you think. Here is a link to the article on Advantage.
I agree that Event-Driven Architecture (EDA) is not a contrasting or superior architecture to SOA, at least not when SOA is defined broadly and understood correctly.
However, many early implementors and the tool vendors that supply them view SOA as a runtime-searchable library of point-to-point, synchronous web services with no consistent approach to security, orchestration, transformation or failover.
Sure, EDA is a marketing-driven term, but it is also helpful in understanding what it takes to be successful with SOA on an enterprise scale.
Now, if WM could just get a few more of the EDA features such as WS-Security and Soap over JMS baked into the core of the product instead of into Glue and ServiceNet they’d really be onto something.
Both wM and TIBCO are parroting what Gartner (Roy Schulte and David Smith) defines as SOA and EDA.
IMO, Schulte has introduced the “EDA” stuff to replace the old “pub/sub” stuff which sounds dated when compared to the new, way-wicked cool sounding “SOA.” It’s a way to remind those that jumped on the SOA bandwagon that “hey, there’s still this messaging stuff out there–don’t forget about it.” But that’s just pure speculation on my part.
From that blog:
“I think the concept of EDA is similar to ESB, and that it probably arises from the integration vendors, looking for a home for their technologies in the new architecture.”
EDA a new architcture? I disagree. Event-driven is a concept that has been around for years and many, many vendors have provided tools that fit that concept.
One of my fellow members on the SOA Blueprints TC recently quoted from this IBM-authored article on the Service Integration Maturity Model.
I haven’t quite had time to digest what the authors mean by “eco-system integration”, but I did find the seven levels of service integration maturity to be a useful start toward assessing the maturity of an organizations SOA efforts.
Not sure about that Yemi. I think it refers more to using Spring-like external configuration to modify the behavior of the service-oriented architecture at runtime without deployment of programming changes. I also see some of the JBoss interceptors or AOP facets concepts at work here. You don’t have to modify existing web services to change how a enterprise-wide performance monitoring “facet” would work or to tweak the logging level of a particular service invocation.
Good dialog as always. I did here Roy Schulte speak today about the EDA and SOA. The summary version is that the traditional EAI vendors are appropriate for large corporations with lots of integration points. Kind of what we already knew. The EDA term has been around for a while but I got the impression he is using it to bring the traditional vendors back into the fold.
I think you need to think about EDA and SOA not as competing architectures, but complementary.
Events signal a change to the state of the system. A user asks for something, a piece of hardware fails, a timer expires. Services perform an action. In essence, a service says "Give me X, I’ll do Y and give you back Z” It should be a truly a modular piece of code, but the modularity is at the business functional level.
So, an event simply causes a service or sequence of services to execute.
I think a more appropriate term would be Event-Driven, Service Oriented Architecture. The separation is because neither is required for the other to work.
Our lives are filled with events that drive us to use a service. The phone rings, we talk on it. This is an event and a service.
So, I don’t believe that EDA and SOA are irrelevant or just marketing terms, but rather trying to create a model of reality.
