SOA and EDA
This paper is published under the terms and conditions in the
Most of what is written about design patterns is written
with client-server applications in mind.
Client-side components send queries and commands to server-side components that access the applicationís state data.
This can be done using a tightly-coupled mechanism like a
remote procedure call (RPC).
But it is nowadays expected that client and server
components will more likely interoperate using SOA or EDA mechanisms.
The terms SOA and EDA are used variously; this paper outlines the basic ideas.
The term SOA was originally a label for a style of component interoperation that was more loosely-coupled than earlier RPC and Distributed Objects styles.
SOA meant a software architecture in which remote components interoperate using asynchronous mechanisms.
A client component can request a service from a remote server.
But the client does not maintain a connection, and is able continue if the server doesnít respond.
The request and reply messages may be sent using the SOAP protocol, or using REST, which relies on standard internet protocols.
The client and server components know of each otherís existence.
The client component identifies the server component, and the server needs the clientís identity to return a reply.
Here, an EDA is special kind of SOA in which senders and receivers are so far decoupled they do not know of each otherís existence.
component knows which Events it wants to know about, and which Events it should
publish or post for others know about.
Components do know about Events; but Event senders donít know who Event receivers are, and vice-versa.
An EDA is especially useful where many components may detect an Event and/or many want to know about an Event.
may be built around an Event publisher; meaning the Event senders and receivers
talk only to the publisher
an EDA can be built around shared data space in which Events are logged for
others to read when they want.
The trend for several decades has been towards
increasingly distributed and loosely-coupled computing.
Some now consider EDA to be the default SOA style, since
it means any two systems can work independently of each other - physically.
This makes system development and testing easier, and
facilitates agile development.
On the other hand, the two systems may still depend on
each other logically, and one
overarching business process may require both to succeed.
SOA and EDA typically rely on some
kind of middleware that manages message passing, using message queues.
The middleware product might be called a message broker, a message bus or service bus.
like NServiceBus, RabbitMQ,
Azure Service Bus and MassTransit do for
applications/developers what email clients do for you and me.
middleware works how e-mail works, meaning each node has an inbox and outbox.
middleware empties the outboxes, conveys messages, and
fills the inboxes.
operating systems provide a built-in (transaction capable) middleware product
for reliable messaging.
So you do
not necessarily require higher level middleware such as MSMQ or Azure Queues.
the operating system expects you to use low-level API's (like SMTP and POP3?) to
send and receive messages.
you can use an e-mail application directly, which is easier and takes away much
of the low-level stuff for you.
manages messages passing within a logical network Ė a cluster of nodes that
send and receive messages to and from each other.
solution architect, overseeing all application components to be
integrated, defines the logical network.
example) you use NServiceBus to integrate 5
applications, you distribute a configuration file containing 5 logical
addresses to each node.
introduce a 6th application/node, you have to update and redistribute this
one logical message bus controls one logical network, and one node can be
connected to multiple different logical service buses.
message bus has its own 'canonical schema' of messages Ė containing all the
Commands, Events and Queries sent around that logical network.
is usually considered more efficient than polling a shared data space (which
might be a database or a message queue).
But it could be less efficient if senders
send Events that receivers donít want to know about, and receivers have to
process events many times before they need the data that is updated.
Event consumers donít need to know of an Event (e.g. new customer address)
immediately, then a shared data space solution may be more efficient.
Here EDA is seen as special kind of SOA, in which Event senders and Event receivers are decoupled as far as possible.
Footnote: Creative Commons Attribution-No Derivative Works Licence
2.0†††††††††† 15/04/2015 12:40
Attribution: You may copy, distribute and display this copyrighted work
only if you clearly credit ďAvancier Limited: http://avancier.websiteĒ before
the start and include this footnote at the end.
No Derivative Works: You may copy, distribute, display only complete and verbatim
copies of this page, not derivative works based upon it.
For more information about the
licence, see† http://creativecommons.org