“Coupling is a measure of how many assumptions parties make about each other when they communicate”
Service interaction is considered a first-class citizen in various industry standards.
The importance of interaction increases as monolithic systems are broken down into smaller services, becoming more service-oriented, and as processes increasingly cross organizational boundaries.
The key to making great and growable systems has much more to do with designing how its modules communicate rather than what their internal properties and behaviors should be.
Messaging is an example of a loosely coupled communication solution where a message is the information building block, which aims at minimizing the assumptions communicating services make about each other.
Another Level of Indirection
“All problems in computer science can be solved by another level of indirection”
“…except for the problem of too many levels of indirection”
Synchronous communication is a simple solution to exchange information among remote entities.
Consider opening a socket over a connection-oriented protocol such as TCP/IP and transmit a raw stream of data through it. It’s a fast and inexpensive way to exchange information
Such a tightly-coupled mechanism is based on a number of assumptions which needs to be satisfied in order the communication to take place:
- Temporal dependency: all components have to be available at the same time.
- Location: each component must know each other address.
- Data structure and representation: in its simplest implementation, all components have to agree on the data format and on the binary representation.
Messaging is a loosely coupled communication solution which minimizes producer and consumer dependencies.
A messaging system acts as an indirection layer among entities that want to communicate.
Messaging System
Instead of sending information directly to a specific address, it can be sent to an addressable channel guaranteeing location transparency to resolve the problem of location dependency.
In order to remove the temporal dependency, that channel can be enhanced to queue up the information until the remote components are ready to receive it. A producer sends messages into the addressable channel and continues processing without needing to worry about delivery, while a consumer receives messages from the channel at its discretion. The paradigm is often referred to as asynchronous communication.
Messaging makes no assumption on data representation, so that standard data formats such as JSON and XML can be used to remove the need to share data handling logic among all components.
Bus vs Broker
The terms Bus and Broker are often mentioned when it comes to messaging.
But what is the difference between them?
A Broker is centralised, it can receive messages from multiple sources, determine the correct destination and route each message to the correct channel.
Using a central Message Broker is sometimes referred to as hub-and-spoke architectural style.
With a brokered messaging system within a Microservice distributed system, all messaging happens through the central system. Note that the central system can be clustered.
A Bus is a decentralised system, meaning there is no centralised messaging system. It is a combination of a common data model, a common command set, and a messaging infrastructure to allow different systems to communicate through a shared set of interfaces.
A message bus is analogous to a communications bus in a computer system, which serves as the focal point for communication between the CPU, main memory, and peripherals. Just as in the hardware analogy, there are a number of pieces that come together to form the message bus.
With a message bus implementation, the messaging infrastructure is cohesively coupled to a Microservice instance itself, very much as a Microservice’s database is. Thus a Microservice’s application code will affectively communicate with a Bus instance in the same infrastructure environment as the Microservice itself.
In a Microservice environment, a Bus paradigm is favoured above a Broker paradigm because the philosophy behind Microservices is mostly a distributed environment.
References:
- https://iopscience.iop.org/article/10.1088/1742-6596/608/1/012038/pdf
- https://medium.com/@dasunpubudumal/distributed-systems-messaging-eee8e70c4a77
- https://www.enterpriseintegrationpatterns.com/patterns/messaging/MessageBroker.html
- https://www.enterpriseintegrationpatterns.com/patterns/messaging/MessageBus.html
- https://www2.dmst.aueb.gr/dds/pubs/inbook/beautiful_code/html/Spi07g.html
