When to use SOA and when to use EDA?
The answer comes from this post (Jack van Hoof's blog):
In contrast to SOA, EDA provides a way of loose coupling. EDA is not a synchronous command-and-control type of pattern, but just the contrary: an asynchronous publish-and-subscribe type of pattern. The publisher is completely unaware of the subscriber and vice versa; components are loosely coupled in the sense that they only share the semantics of the message.SOA=Command and Control, EDA=Business Process Chain
If you are seeking to support strong cohesion in the business processes, situations where all process steps are under one control, SOA is the way to go. The command-and-control style of SOA - in general – is applicable to:If you are seeking to support independency between business process steps, EDA is the way to go. This style of architecture is appropriate in federated and autonomous processing environments. Recognizable situations where EDA might be applicable are:
- Vertical interaction between the hierarchical layers of functional decomposition
- Functional request-and-reply processes such as man-machine dialogues; the user waits for an answer
- Processes with a transactional nature which require commit and rollback facilities
- Data enrichment in a message to be published to bring the message to its full content in a formal format
- Horizontal communication between tiers in a process chain
- Workflow type of processes
- Processes that cross recognizable functional organization borders, external (B2B) as well as internal
This same post presents the "SOA X EDA" view:
EDA Overview
Brenda Michelson wrote an EDA overview in her blog (in fact, the best definition I've read).
Also from this post from Brenda' blog are the pictures below:
1. Complex Event Flow
2. EDA Implementation Components
2 comments:
Davi - thanks for calling out my work. -brenda
Davi, thank you for referring to my blog-posting - Jack
Post a Comment