If you are a developer or an architect, you may have heard of messaging. Messaging is a popular trend if you want to work with software development, design solutions that involve distributed systems, or if you’re thinking about asynchronous ways to build your application. It can even help solve some integration challenges.

In this article, I’ll share why messaging is so present in software development these days. We’ll also look at the most common messaging protocols and message brokers and compare the top messaging integration patterns. But first, let’s begin with a brief definition of messaging.

What is Messaging?

Messaging is a development practice where we use messages to establish communication and integration in synchronous or asynchronous ways between applications. Messaging uses a Message Broker or a MOM (Message Oriented Middleware), which is nothing more than a server explicitly built to process the sending, receiving, redirecting, and monitoring of messages exchanged between systems.

Five Protocols for Messaging

There are five main protocols used in modern messaging development projects. There are other types, but these below are the most common ones that you’ll come across.

The first one is the Java Message Service (JMS) and, as the name says, it’s more related to integrations between services or components developed in the Java language. It’s primarily used by an Application Server where cooperative applications are built and developed in Java.

Advanced Message Queuing Protocol (AMQP) is more modern and is indifferent to the language of the software or application it works with. If your favorite language has support for this protocol, your applications can integrate with others using a Broker that supports this protocol.

In terms of usage, the Simple/Streaming Text Oriented Messaging Protocol (STOMP) is the most interesting one. This protocol is more focused on data streaming, where the message is serialization and when you need this data to be shared as close to real-time as possible.

The next I’d like to highlight is the Message Queue Telemetry Transport (MQTT), which is mainly used for communication between smart Internet of Things (IoT) devices. This protocol makes the implementation and communication easier between those devices in the network and enables notifications to be sent to other systems that are listening.

Last but not least is the Microsoft Message Queuing (MSMQ). As the name says, this protocol is an implementation by Microsoft. MSMQ is used mainly when applications are built on the native language for this environment. It was used in NT versions for Windows, and also with the Server Version (Windows Server 2016) and for Windows 10. The protocol is quite specific to the Microsoft environment.

Most Common Message Brokers

So, what are the most common brokers in the IT industry today, and which protocol do they support? There are many options, but I’ll focus on the main ones I’ve seen throughout some projects.

Most common in corporate environments, we have the IBM MQSeries. This one only supports the JMS protocol, as it is an old broker and was born during the time of the enterprise Application Servers.

The ActiveMQ broker is more versatile — it supports JMS and AMQP protocols, so if you use this one, you can integrate applications that are built using older versions of Java and newer applications in modern languages that support the AMQP protocol.

One of the most famous brokers today, RabbitMQ, is simple to use and has a good capacity and performance in large use cases. RabbitMQ is most used for projects that use the AMQP protocol exclusively.

Another famous one, Kafka, is a larger broker used when the scope for the project needs high performance and real-time data transfer. This broker uses the STOMP protocol.

The Main Integration Models

There are three main integration patterns when using messaging and a message broker.

Point-to-Point

In a point-to-point integration pattern, the exchange of information is based on queries. The message is initially sent by an application that we call a “producer,” and the message is consumed by another application (or multiple applications) that we call the “consumers.” These consumers are “listening” to a specific queue.

In this model, it’s possible for one message to be consumed (one-to-one). So, even if several consumers listen to the same queue, one consumer will get the message just once, and the message itself will no longer be at the broker.

Publish/Subscribe

The Publish/Subscribe model, also known as Pub/Sub, is based on topics, where the messages are sent by the producer and delivered to all consumer applications that can “assign” to be on this topic.

This model allows the message to be delivered to several consumers (one-to-many), so consumers that use the durable sign to the topic can consume the messages while they are active on the broker.

Dead Letter Queue

The name “dead letter” comes from the physical mail system, where when a specific letter can’t be delivered, it’s sent to a department for someone else to deal with. We have something similar in messaging. When it’s not possible to deliver a message, there’s an option to have a queue where we can send this message for someone to take action, as nobody consumed it.

Here we need to make an important comment. The dead letter queue (DLQ) is responsible for receiving messages that were not delivered or not consumed. Using the DLQ as an error message for integration errors or fails is wrong. When the integration fails, one should use another type of queue or even create alerts in the monitoring tools to notify the right person, depending on the broker you are using for your project.

Messaging in Microservices

Messaging is also relevant when working on a project using a microservices architecture. Although every microservice should be independent of each other, they must share data and send notifications related to an event that happened.

Using messaging, we can solve many of these communication scenarios between microservices without increasing the coupling between them and keeping them independent from each other.

Event Sourcing

One pattern common among event-driven microservices architectures is event sourcing. Event sourcing uses messaging to propagate data by events triggered by a first microservice, with the purpose of sharing this information with others. This helps keep data consistency for the microservices that share the same data. This pattern is also linked to the CQRS pattern, helping retain low coupling for our architecture.

We can see in the image below an example of information that needs to be shared between microservices and keeping the updated data for both.

What Do I Earn, and What Do I Lose?

In this final segment of the article, I’ll mention some of the principal advantages and disadvantages when using messaging in software development projects.

Advantages of Messaging

The first advantage I’d like to highlight here is that the producer of the message does not have to worry about whether the consumer of the message is available at the moment the message is sent. Messaging can also provide low coupling between services, keeping the integration and the communication asynchronous.

Depending on the protocol, it’s possible to integrate applications from different developing languages and technologies (for example, using AMQP, you can communicate Java applications with other built-in PHP, Python, etc.).

Another advantage is that it’s possible to consume the sent message even before an integration fails, if the message is still on the broker’s queue. Lastly, using messages for events to share data helps keep the information consistent between applications.

Disadvantages of Messaging

Of course, everything has a bad side depending on our choice. In my view, using this approach for developing applications or microservices can make your development tasks more complex than usual, which can be a disadvantage. Also, This pattern is not recommended for scenarios requiring synchronous communication between applications.