Comments on: EDA vs SOA

By: Confluence: Event-Driven Architecture

Confluence: Event-Driven Architecture — Mon, 25 Jun 2007 08:40:02 +0000

From: Teresa Gallo \mailto:tgallo@herzumsoftware.com\ Sent:

From: Teresa Gallo \mailto:tgallo@herzumsoftware.com\ Sent: Sunday, June 17, 2007 5:47 AM To: herzum@herzumsoftware.com Cc: ‘Francesco Bruno’; ‘Luigi Guadagno’ Subject: RE: URGENT QUESTION RE: alcuni deliverable miur \\ Grazie Peter……

By: Confluence: Event-Driven Architecture

Confluence: Event-Driven Architecture — Mon, 25 Jun 2007 08:29:07 +0000

From: Teresa Gallo \mailto:tgallo@herzumsoftware.com\ Sent:

By: Ronan Bradley

Ronan Bradley — Wed, 20 Jun 2007 10:28:38 +0000

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

By: Jack van Hoof

Jack van Hoof — Tue, 19 Jun 2007 15:09:27 +0000

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