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.
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