Ronan Bradley's FinanceTech Directions

Reading Joe McKendriks’s blog piece on “Is EDA the ‘new’ SOA” got me thinking again about how EDA and SOA fit together. Event Driven Architectures (EDA) is sometimes held up as an alternative to SOA. While this may be theoretically the case, I think EDA-style capabilities are most likely to build on top of SOA to take advantage of the higher degree of integration provided by a SOA deployment.

Rather than going into detail on what EDA is, I will quote some definitions from Jason Bloomberg of ZapThink back in 2004 and suggest that anybody who wants to know more goes to Brenda Michelson’s excellent primer on the world of events and EDA in her elemental links blog.

Jason’s definitions are:

EDA is an approach where events trigger asynchronous messages that are then sent between independent software components that are completely unaware of each other.

While

SOA, on the other hand, is an architectural approach where software functionality is exposed as loosely coupled, location independent services on the network.

Therefore the primary difference between SOA and EDA is the level of decoupling between the software components. The total decoupling of source of the event and the eventual destinations in EDA means that the message fully defines the interaction between components – a very different situation from SOA where the server and client interaction is ruled by the service definition. In fact, EDA is not a new pattern – it is a form of “publish and subscribe” which has been around for a long while and effectively used to solve certain classes of problems.

The question from Joe was “Is EDA the new SOA?” – I would say no for two reasons:
• The level of enforced decoupling in EDA can make it awkward to shoehorn the range of problems that an enterprise architecture has to solve into a pure EDA form.
• For those problem types that EDA is well-suited for, SOA can be extended with a bit of EDA and therefore do the job.

Rather, I see EDA being used ‘on top’ of SOA – to allow identification and processing of unusual events or combinations of events that should generate alerts or recovery processes. SAP for one is already providing some of this type of capability within its NetWeaver product set where BPEL-defined processes can be fired off in response to specified events. This type of functionality will be crucial in terms of delivering control across the SOA-based network of integrated components exchanging more information and information of greater business value.

Ronan