A brief summary:
RabbitMQ is a powerful Message Broker, for me the best considering cost-benefit considerations. I base this information in two main weights:
- RabbitMQ is free, or free.
- RabbitMQ uses the AMQP 0–9–1 protocol to transition its messages.
AMQP is a network communication protocol, such as HTTP, that allows applications to communicate.
Messaging solutions have been around since the 1970s with the idea of solving the integration problems between various vendors. Without the use of messaging middleware, the heterogeneous integration of systems proved to be a very expensive and complex process.
For example, messaging solutions such as IBM Websphere MQ and Tibco Enterprise Message Service are very expensive and tend to be used only by large companies, especially the financial services industry.
In addition to these mishaps, there are also interoperability issues between these solutions. Suppliers, in order to get around this problem, created their own protocols for messaging, so we noticed that they were not integrated with other suppliers, since each one created its solution, this was called a Supplier Lock-in, which in our language sounds like a market reserve or niche reserve.
AMQP has many advantages, but two are more important: to produce an open standard for messaging protocols and to enable interoperability between many technologies and platforms.
There are many systems running on many Operating Systems, which are developed with multiple programming languages, running on various hardware architectures and virtual machines. AMQP not only makes integration among these different systems possible, but also allows different products that implement this protocol to exchange information and this makes AMQP the pioneer as well as the evolution of messaging.
The AMQP model works as follows: messages are posted by the producers and sent to the exchanges. Exchange distributes copies of messages to queues using rules that are called bindings in AMQP jargon.
So AMQP brokers send messages to consumers who access, or subscribe, queues, or consumers search and process queue messages on demand.
When publishing a message, producers can specify various attributes for it, also called message metadata. Some of these attributes may be used by the broker, however, other attributes are only used by applications receiving the message.
Networks are not reliable and applications can fail to process messages, so the AMQP model has the implementation of message acknowledgments, that is, when a message is sent to a consumer, the consumer notifies the broker, either automatically or later.
When acknowledgments are being used, a broker will only remove the message completely from the queue when it has received a notification of this message (or group of messages).
In certain situations, when a message can not be routed, it can be returned to its creator, discarded, or if the broker implements an extension called a dead letter queue, or producers can choose how to manipulate situations such as this is just selecting some parameters.
I will make a small demonstration of consumer service development and service sender within the same project. It is interesting, in real cases, that these services are separated into different projects assigning responsibilities for each service. Later on I will talk about microservices and explain a little more about these responsibilities.
First of all, we need to configure a server with RabbitMQ, and for development I suggest that we use a docker on the localhost machine.
- Docker: https://www.docker.com/get-started
- (Optional, I’ll use in the example) Kitematic: https://kitematic.com
Creating the machine with the administrative page in docker:
To create the machine run the following command:
docker run -d --hostname my-rabbit --name rabbitmq rabbitmq:3-management
Next, to view our virtual machine, open Kitematic:
It is extremely important to save the ports required for mapping, if you do not do this procedure it may be that your rabbitmq always toggles mirrored ports. In the example above, I mapped the admin page port at http://localhost:32784, so if we open this address we will have:
By logging into RabbitMQ you will see your wonderful Dashboard and its features, in this tutorial we will only use it for follow up after our messages are being sent. It is necessary that your RabbitMQ docker is running for Spring Boot to make the connection.
RabbitMQ’s dependence on Spring Boot is the spring-boot-starter-amqp, which despite the generic name brings features of RabbitMQ.
In the application.properties file it is necessary to configure the communication with RabbitMQ that is active in Docker.
The concurrency must be configured according to what is necessary for your business. The queue will be used and created at runtime. We’ll see in the next steps how to use this variable.
In the String application class, use the @EnableRabbit annotation. This annotation will activate the concurrency settings. Note that the variable below called weatherQueue will receive the variable value in the application.properties file. The application is then ready to send and consume queue data in RabbitMQ.
Now let’s set up a component to consume the queue. This component will listen to the queue and when a new message arrives in that queue it will execute the method linked to the queue. To bind the queue, we must configure the method with the @RabbitListener annotation, this annotation informs which queues will be listened to. The Service must be initialized. In our example, the payload of the message will come with the name of a city and we will execute a service that should be initialized with @Autowired, in that service we can do what we want with the message received in Payload. In our example it was just a String, but a Json can be assigned to Payload with a DTO mapping file, but I’ll leave it to explain when I’m writing about creating Rest and RestFUL APIs by Spring Boot. Below is the class I developed as an example:
In the next step, we will create a Spring Boot component class that we will use to send the information to the RabbitMQ queues. It will then be used by other classes to send messages. See the example we made, it’s quite simple.
Now that we have made a Spring Boot component class to listen to the messages and another to send we can start the actual use. As I said earlier, in a production environment, using these two functions within the same project does not make much sense, unless you set by default for your process to always use a queue for running processes. So let’s get down to business:
With this, every time this service is called, it will execute and send to the queue we created and our listener received that information.
I hope you enjoyed this step-by-step, it was done with great care and with the intention of disseminating these technologies.