What is messaging and what do I get out of it?

Before we start, let’s check a brief definition about what’s messaging:

“... It’s a development practice where we use messages to establish communication and integration in synchronous or asynchronous ways between applications, using a Message Broker or a MOM for this purpose…”

Message Broker? MOM?

Message Broker or MOM (Message Oriented Middleware) are nothing more than a server (infra) built specific to process and support the send/receiving, redirecting and also monitoring the messages shared and exchanged between the systems integrated by message.

Protocols for Messaging

Initially, I’ll talk about the 5 main protocols most used today in projects:

• Java Message Service (JMS): As the name says, it’s more related to integrations between services or components developed in Java language. Also most used by Application Server where cooperative applications were built and developed in Java.
  
  
• Advanced Message Queuing Protocol (AMQP): This protocol is more modern and is indifferent to the language the software/application is built for. If your favorite language has support for this protocol, your applications can integrate with others using a Broker that supports this protocol.
  
  
• Message Queue Telemetry Transport (MQTT): Most used for communication between smart devices for IoT (Internet of things). This protocol makes the implementation and communication easier between those devices in the network and also, to send messages or notifications to other systems that are listening to.
  
  
• Simple/Streaming Text Oriented Messaging Protocol (STOMP): This protocol is more focused for Data Streaming, where the message is serialization and when we need this data to be shared most near to a real time for the consumers.
  
  
• Microsoft Message Queuing (MSMQ): This protocol, as the name says, is an implementation by Microsoft, most used when applications are built on native language for this environment. It was most used in NT versions for Windows, and also with the Server Version (Windows Server 2016) and for Windows 10. It’s really most specific to the Microsoft environment.
  

Main Brokers from the Industry

We can list here the most used brokers in the IT industry today and which protocol they support. There are more than the ones mentioned here, but I focused on the main ones that I saw during some projects.

• IBM MQ Series: This one only suportes the JMS protocol, as is an old broker and it was born during the time of the enterprise Application Servers.
  
  
• ActiveMQ: More versatile, it supports JMS and AMQP protocols, so, if you use this one, you can integrate applications that are built using Java in olders versions or even newer applications in modern language and that supports the AMQP protocol.
  
  
• RabbitMQ: This one of the most famous brokers used today. Its use is simple and has a good capacity and performance in big performances. It’s used most for projects that use exclusively the AMQP protocol.
  
  
• Kafka: Another famous one. Larger used when the scope for the project needs high performance and real time data transfer. Uses the STOMP protocol. 

Integration Models

At this point of the article, I’ll share 3 main patterns of integration when using messaging and a message broker.

Point-to-Point

The exchange of the information is based on queues, where the message is sent initially by an application that we call producer and the message is consumed by another application (or others applications) that we can call as consumers. Those 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, only one consumer will get the message only one time and the message itself will no longer be at the broker.

Publish/Subscribe‍

Also known as the model “Pub/Sub”, it’s based on topics, where the messages are sent by the producer and delivered to all consumers applications that can “assign” on this topic.

This model allows that the message can 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 a pattern of the Mail, where a specific letter can’t be delivered, so it’s sent to a “department” or someone “responsible” to take some action about this letter that was not delivered for any reason.

We have something similar when dealing with 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 an action, as it was not consumed by nobody.

Here we need an important comment. The DLQ (as this dead letter is commonly named) 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, we can use another type of queue or even create alerts/notifications in the monitoring tools to take action from someone, depending on the Broker you are using on your project.

Messaging in Microservices

The subject messaging also is actually linked, when we’re working on a project related to Microservices Architecture.

Once every microservice should be independent from each other, but even that, we have the need to share data, send data to other microservice or some 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.

Let’s talk about a pattern called Event Sourcing. This one is most used for Event Driven Architectures.

Event Sourcing

This is an architectural pattern when implementing Microservices. Event sourcing uses messaging, to propagate data by events triggered by a first microservice, with the purpose of sharing this information with others, and keep the consistency of data for the microservices that share the same data. This pattern is also linked to the CQRS pattern, helping for the 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.

Ok, what do I earn and what do I lose?

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

Advantages when using Messaging

• 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.
  
  
• Provides low coupling between the application , 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).
  
  
• It’s possible to try to consume the sent message even before an integration fails, if the message is still on the queue of the Broker.
  
  
• The usage of messages for events to share data helps to keep the information consistent between applications.

Disadvantages when using Messaging

• Using this approach for developing applications or microservices, can make your development tasks more complex than the usual.
  
  
• This pattern is not recommended for scenarios that need synchronous communication between applications.

Want to know more? Click on the link and book an appointment with our experts:

https://meetings.hubspot.com/30minute_servicemesh