EDA vs SOA

I have been involved in some recent research into event-driven architecture (EDA) and its relationship to service-oriented architecture (SOA), as a result of confusion abounding over the two concepts. Some people seem to think EDA = SOA 2.0. Others that they are already doing EDA in their SOA implementations because they are using asynchronous communications such as a JMS or IBM WebSphereMQ. This confusion is exacerbated by vendors with their own agendas - TIBCO has been banging the EDA drum for ages as the preferred way to go to solve integration problems, IBM has just held a massive event to drive its own SOA agenda, Oracle seem to be trying to straddle the two approaches, and complex event processing (CEP) vendors like Progress have their own stories about EDA.

My own analysis, together with Dr. Ronan Bradley, also of Lustratus, has concluded that as is so often the case, the problem comes down to confusion over terminology. EDA is an architecture, just like SOA. It is a way of running operations, and before anyone starts to ask whether I am on the side of SOA or EDA, the two can happily coexist. But the confusion arises when people start to use EDA as a term to refer to particular implementations rather than to the architecture itself.

In fact, we identified 3 major ways that EDA relates to SOA, and concluded that EDA may have a key role to play as SOA matures - to deal with the increasing management complexity of widescale SOA deployments through a 'management by exception' approach.

For those interested in reading the detailed research, Lustratus has published an Insight on the subject, available at the Lustratus site.

Steve

Comments

[Jack van Hoof]

Both EDA and SOA architectural styles focus magically on the same architecture from an inverse viewpoint:
http://soa-eda.blogspot.com/2007/06/magical-of-soa-and-eda.html

Because of the completely different nature and use of EDA and SOA it is necessary to be able to distinguish between the both and to name them. You might say making such a distinction is a universal architectural principle:
http://soa-eda.blogspot.com/2006/11/why-to-distinguish-between-soa-and-eda.html

SOA may be loosely coupled in the technical domain, where common web services technology is used, but it certainly is not in the functional domain where SOA is associated with ‘calling’ foreign (reusable) services and eliminating data redundancy:
http://soa-eda.blogspot.com/2006/11/how-eda-extends-soa-and-why-it-is.html

[Ronan Bradley]

Jack,

I think your analysis is excellent in distilling the essence and differences as architectures between SOA and EDA (particularly in http://soa-eda.blogspot.com/2007/06/magical-of-soa-and-eda.html).

As Steve mentioned in the original posting, where the confusion arises is the EDA term is currently used in three different contexts:

- As an architecture,
- To refer to the technology used to implement the arcitecture in the context of application integration (IBM Websphere-MQ et al)
- And most recently as short hand for describing the application of the EDA architecture to the SOA visibility and control problem.

It is this final use of the term which is novel and of most potential value in the SOA context (it also sparked most confusion due in part to Oracle's attempt to brand it SOA 2.0).

Ronan