Hello friends, today we will learn about AMQP concept, will understand the differences between AMQP and traditional JMS API and see how to install RabbitMQ message broker on our local machine. AMQP is a new but very popular concept in the messaging world. Its popularity today is due to its improvements over the conventional messaging like JMS such as. So, let’s first introduce about AMQP and then we will see how we can install RabbitMQ on our local machine. In the next post, we will see how we can use AMQP in a Spring-based application and interact with RabbitMQ for messaging. So, let’s get started with the AMQP concepts today.
What is AMQP?
AMQP means Advanced Message Queuing Protocol, which is a network level message protocol
Which operates in Application Layer (Layer 7) of OSI TCP/IP model. So AMQP is a protocol, unlike earlier popular messaging components mostly API based like Java Messaging Service (JMS). AMQP provides an interoperable messaging protocol where different types of clients can interact with it simultaneously, unlike in JMS only Java-based clients can interact with each other. So, till now it has been clear that AMQP is a messaging protocol designed to simplify and overcome the difficulties of traditional JMS based API, also AMQP is getting momentum today and new messaging components are being built using this only. In the next sections, we will touch upon on the problems of JMS API and will see how AMQP comes into the picture and solves the problem.
Why is it relevant?
Traditional messages which we are familiar about with JMS has few limitations; mostly it expects homogeneous publisher and consumers to interact with the message broker and the message format was somehow tightly coupled with the API we choose to interact like JMS in Java world. To overcome these, few products like WebSphere MQ and Hire Tibco Developers with came into pictures, but those are also not fully loosely coupled and most importantly those are very costly in terms of the license cost. Also, the interoperability problem that those products tried to solve resulted in creating new proprietary message protocols which do not interoperate with others, therefore resulting in ‘vendor lock-in.’
AMQP has various design areas, but two of the most vital are:
- To deliver an open standard for informing middleware
- To empower interoperability between different technologies and stages
There is a many of software running on many operating systems worked with different programming languages running on different hardware structures and virtual machines. AMQP does not just make it possible for these dissimilar systems to speak with each other, yet additionally empowers different products that actualize AMQP to exchange data.
What are message Brokers?
Messaging brokers are the real messaging middleware that receives messages from producers (applications that publish them) and routes them to consumers (applications that process them).
How AMQP works
Unlike JMS where publisher applications directly send messages in Queues/Topics and Consumers also directly point to those queues for message consume, AMQP is a bit different in terms of message exchange.
- Here is message is first sent to a component of Message Broker (like RabbitMQ) called Exchange. Exchange in AMQP can think about post office or mailbox sort of thing where it takes care of routing the messages in right recipients, in messaging world it is the message Queues which is again connected to multiple consumers.
- Exchanges distribute message copies to queues using rules called bindings.
- Then AMQP brokers either deliver messages to consumers subscribed to queues, or consumers fetch/pull messages from queues on demand.
Here is the sample interaction diagram on how AMQP works.
So, Exchange is the Middleman of the message routing process and route messages in different Queues based on the binding producer's mention. Now we will see what message attributes in AMQP perspective is.
Message Attributes – Those are metadata of messages some are used by the broker and rest are used by consumers directly. The important message attribute that is used by the broker is binding. Other message attributes can be custom
Message Acknowledgements: As messages are sent over networks which are sometimes unreliable, and applications then fail to process messages resulting failure in the business goal of the applications, so we need some sort of message acknowledgments system which confirms that the messages that have been published have been routed to the consumers properly. In this process, the consumer sends the ack to the message broker in tern passed to the publishers.
At the point when message affirmations are being used, an agent will just totally remove a message from a line when it gets a notification for that message (or group of messages).
When messages can be sent to a dead letter queue if there is any problem of routing the messages to designated consumers.
Different Exchange patterns
Till now we have understood the role of Exchanges and how messages are routed to Queues in simple routing way, but there are few new models of routing in AMQP which are a heart of the messaging. Exchanges take a message and course it into at least zero lines. The steering algorithm used depends upon the exchange compose and rules called bindings. Currently, those are the message routing types possible with AMQP.
Direct exchange – This is mostly the simple routing that we have seen above, in this communication pattern 1-1 communication of queues or unicasting, means in each message is routed to a single target queue provided in the binding of the messages. A direct exchange distributes messages to queues based on the message steering key. The steps of direct exchange are:
- A queue binds with the exchange with a routing key when created.
- When a new message arrived in the exchange with routing key, the exchange routes it to the right queue matching the routing key.
The AMQP Direct Exchange closely matches the Point-to-Point messaging model of JMS
Fanout exchange: This is 1-to-n communication or broadcasting between publishers and consumers. Fanout exchange routes messages to all the queues that are bound to it and here routing key are ignored.
If multiple queues are bound to a fanout exchange when a new message is published to that exchange a copy of the message is delivered to all queues aligned to the same exchange in fanout way. Fanout interactions are ideal for the broadcast steering of posts.
Topic exchange - Subject exchanges route messages to one or several lines dependent on coordinating between a message routing key and the pattern that was utilized to bind a line to an exchange. The topic exchange composes is regularly used to actualize different distribute/subscribe in pattern varieties. Topic exchanges are ordinarily used for the multicast steering of messages.
Headers exchange - Header exchange is designed for routing on multiple attributes that are more easily expressed as message headers than a routing key. In Headers exchanges communication it ignores the routing key attribute. Instead, the characteristics used for steering are taken from the headers trait. A message is viewed matching if the estimation of the header equals the value specified upon binding.
A Quick Comparison with JMS
So, we have learned the basic concepts around AMQP and seen why it has been grown up from the limitations of JMS. In this section, we will see bit more details about the comparison with JMS and finally will try to close when we should use JMS and when we should go for AMQP. To understand the importance of AMQP over JMS we will start with a problem statement and will see how JMS has limitations but AMQP can solve the scenario properly.
JMS defines API for interoperability within the Java platform, but not outside of java platform. Integration between Java and other platform or languages is usually proprietary and often leads to vendor lock-in.
| Scenario | JMS Capability | AMQP Capability | Conclusion |
|---|---|---|---|
| Messaging between two or more Java clients within java platform. | In this case JMS can solves the problem easily as JMS is designed to be work between java clients. | AMQP can also solve the same problem easily. | So, if all the clients are Java based and we have already some existing modules interact with JMS then in this scenario JMS will be best to use. AMQP here will lead to unnecessary complexity unless in future we don’t have any extension plan to include non-java clients. |
| Messaging between Java producer and Ruby Client. | Here JMS can’t work directly with the standard JMS based message broker as for Java side we need JMS compatibility and in Ruby side we need STOMP. So, to solve this interoperability problem, we need some message broker which supports both JMS and STOMP. ActiveMQ can be such broker and we can use this. | As AMQP is a protocol and implementation of AMQP based message broker like RabbitMQ gives API in multiple languages, we can use AMQP also with different API compatible to the programming language/platform | We can think about using AMQP here as it will significantly reduce the dependency on the particular vendor like in this case ActiveMQ. But if we write our code in AMQP then code will be generic and we can replace the message broker easily in future. |
| Messaging between .NET C# and Ruby | Here .NET C# uses NMS API whereas Ruby uses STOMP, but we don’t have any popular vendor who solves this interoperability by providing a bridge between those two different types of client. | Here we can easily use AMQP as it is a protocol and AMQP based message broker like RabbitMQ gives API in multiple languages. So we can easily solve this using AMQP. | Same as above, we should use AMQP based message broker and language API. |
Rabbit MQ installation using Docker
Now we will see how we can run RabbitMQ server in local machine using Docker. RabbitMQ is an AMQP compliant message broker and very popular today.
I have done all my testing in MAC O/S, but the docker commands are generic, so will work in windows as well.
To start docker image of RabbitMQ, we need to use the below command, it will download and start RabbitMQ image in local M/C.
docker run -d --hostname my-rabbit --name rabitmq-server rabbitmq:3
Now we need to install the RabbitMQ management container using the following command. We are here exposing the 15672 port from the container to the local machine so that we can use the console from a browser.
docker run -d --hostname my-rabbit -p 15672:15672 --name some-rabbit-management rabbitmq:3-management
If both commands work well, then both RabbitMQ and RabbitMQ management part starts up and we can use the console at http://localhost:15672/
The default user of RabbitMQ is guest/guest, once login we can see the RabbitMQ console as below.
Now we can do further things like creating Exchange. Queue, Bindings and sending sample message and reading. Those are very straightforward, I will suggest you do a basic validation of the concept we discussed by doing some hands-on in RabbitMQ.
In the next post, the developers of Outsourcing Java Development Company will see how they can write applications using spring and RabbitMQ as a message broker.
Happy Learning.
You can find references in below link:
