A few days ago I discussed how Web oriented Architecture (WOA) relates to SOA. Today I’ll touch on EDA. Some aren’t sure whether to go with EDA or SOA. The great news is, that’s not a decision you need to make. It’s like asking yourself a nonsensical question like “should I have a drink or should I quench my thirst?”
Let me cut to the chase: EDA is “event driven SOA”, it’s as simple as that.
If you design your SOA around numerous independent, autonomous services which are unaware of each other and merely publish events which other services subscribe to, then you have event-driven SOA. Or EDA. Take your pick.
So if the two terms (SOA and EDA) are so intertwined where has the confusion come from?
The answer is: EDA is a subset of SOA. It is quite possible that your SOA may use RPC style ‘command messages’. This is a technique that falls outside the scope of EDA – but it is quite legitimate in SOA. When I ‘legitimate’ I mean ‘if used correctly, with implications clearly understood’. It should be the exception rather than the rule.
So. If you have a drink then you’ll quench your thirst. If you create an event-driven SOA then you’ll have EDA. Forget about acronyms – they’re used by vendors and analysts trying to create markets or carve out niches for themselves. Architects should be looking for the substance behind the hype.