Messaging in Distributed Network Applications
Before directly jumping onto ‘what is messaging?’. Let’s see what was the real scenario before.
The challenge was the communication between distributed network applications.
Modern large-scale applications are rarely built as monoliths. Instead, they are built as distributed network applications with parts of the application spreading across different parts of the world or in different processes.
All parts of the application need to work together to behave as one reliable application. For that they need a way to communicate with each other.
One of the solutions is Messaging (Message Oriented Middleware), which allows distributed applications to communicate and exchange data by sending and receiving messages.
What is Messaging?
Messaging is a method of communication between software components or applications. One thing that is important here is that it’s more of communication between IOT devices rather than involving people. And that’s what makes it different than the term ‘messaging’ that we hear or do in our day to day life. So you can say it’s a computer to computer messaging.
Thus, it differs from electronic mail (email), which is a method of communication between people or between software applications and people.
In a messaging system, each node can request for services and provide services unlike the client-server network where the client nodes requests for services and server node responds with services.
A messaging client can send messages to, and receive messages from any other client.
Basic Messaging Model
Major components in a messaging system are:
- Message Producer — The source of messages.
- Message Consumer — That receives messages.
- Message Broker — servers like Apache ActiveMQ Artemis that delivers the messages to consumers.
- Messages — The actual content with header and metadata.
In a messaging system, a producer sends a message to the consumer via a message broker. We can say, message brokers are the building block of message-oriented middleware (MOM) as they are the ones that mediates the communication among applications, minimizing the producer and consumer’s dependencies on each other in order to be able to exchange messages.
Characteristics of Messaging
1. Loosely coupled
Messaging systems decouple the producer from the consumers of messages. The producer and consumers of messages are completely independent and know nothing of each other.
The producer and consumer need not to be available at the same time. The messaging system will make sure that the messages from the producer are delivered safely as soon as the consumer is available.
Let’s say component A sends a message to a destination, and the recipient can retrieve the message from the destination. What makes the communication loosely coupled is that the destination is all that the sender and receiver have in common.
This makes your system more scalable as your system grows and encourages flexibility to add new systems or retire old ones.
2. Asynchronous/Synchronous Communication
Messaging systems primarily use an asynchronous message passing pattern with no tight relationship between requests and responses. Unlike synchronous communication, where you have to wait for a response for each request you make.
Designing systems to be asynchronous allows you to use your hardware resources more efficiently and allows you to create much higher performance applications.
Most messaging systems also support a request-response(synchronous) mode but this is not a primary feature of messaging system.
Use cases
1. Notifications (point-to-point)
One of the use cases of messaging is notifications. It uses point-to-point messaging style.
Point-to-point applications typically use queue to pass messages between each other.
Consumers see only the messages they acquire from the queue.
An application sends a message to another application by identifying a destination queue. The underlying messaging and queuing system receives the message from the sending application and routes the message to its destination queue. The receiving application can then retrieve the message from the queue.
2. Sensors (pub-sub, fan-out)
Sensor is another user case of messaging and it uses publish subscribe messaging style.
Pub-sub applications typically use topic to pass messages between each other.
It involves a producer that could be a device with a sensor and N consumers.
These consumers subscribe to the topic and each subscriber receives a copy of each message sent to the topic. So every consumer, who subscribed, sees every message.
3. Data Collectors (pub-sub, fan-in)
Data collectors is also an example of publish subscribe messaging style.
It involves N producers and 1 consumer.
Data flows from all the devices to a consumer i.e a data collector.
Thank you for reading!Note: This blog is written keeping Apache Qpid and Apache ActiveMQ Artemis in mind. Generic concepts may apply to other Messaging systems as well.
References: https://activemq.apache.org/components/artemis/documentation/latest/
Published
Originally published at http://rakhiroriya.wordpress.com on December 16, 2022.
