SOA and EDA
basics
This paper is published under the terms and conditions in the
footnote.
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.
Contents
Service-oriented
architecture (SOA)
Event-driven
architecture (EDA)
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.
Each
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.
An EDA
may be built around an Event publisher; meaning the Event senders and receivers
talk only to the publisher
Alternatively,
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.
Wim: Middleware
like NServiceBus, RabbitMQ,
Azure Service Bus and MassTransit do for
applications/developers what email clients do for you and me.
Some
middleware works how e-mail works, meaning each node has an inbox and outbox.
The
middleware empties the outboxes, conveys messages, and
fills the inboxes.
Most
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.
However,
the operating system expects you to use low-level API's (like SMTP and POP3?) to
send and receive messages.
Or else,
you can use an e-mail application directly, which is easier and takes away much
of the low-level stuff for you.
Middleware
manages messages passing within a logical network – a cluster of nodes that
send and receive messages to and from each other.
A
solution architect, overseeing all application components to be
integrated, defines the logical network.
If (for
example) you use NServiceBus to integrate 5
applications, you distribute a configuration file containing 5 logical
addresses to each node.
When you
introduce a 6th application/node, you have to update and redistribute this
configuration file.
I assume
one logical message bus controls one logical network, and one node can be
connected to multiple different logical service buses.
Each
message bus has its own 'canonical schema' of messages – containing all the
Commands, Events and Queries sent around that logical network.
Messaging
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.
Where
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