Developed by John O’Hara from JPMorgan AMQP (Advanced Message Queuing Protocol) sets a standard on how messages should be structured and transmitted. Goal is to solve the problem of interoperability by providing a truly interoperable, cross-platform messaging standard. Is this the next messaging standard?
The need for a cross-platform messaging standard is exactly the idea behind AMQP. Whereas JMS provides a standard messaging API for the Java Platform, AMQP provides a standard messaging protocol across all platforms. AMQP is not a specification for a standard API, it is rather a specification for a wire-level binary protocol to describe how messages should be structured and transmitted. AMQP is further fully agnostic to which AMQP client API or AMQP message broker is used, so we can easily integrate a RabbitMQ client and a RabbitMQ message broker with a Apache Qpid client without any problems. This blogpost will compare the core functionality for routing, exchange patterns and message structure.
JMS uses a simple message routing mechanism where both the message producer and message consumer exchange messages by connecting to a particular queue or topic.
AMQP uses a different message routing mechanism. Rather than the message producer sending a message to a queue (JMS), it sends a message to an exchange along with a routing key. Exchanges are bound to queues in AMQP through what are called bindings. Message consumers connect to a queue and receive messages from the queue that is bound to an exchange. If the routing key send by the message producer matches the binding specified between the exchange and the queue, then the message is router to the queue and consumed by the message consumer.
Important to remember
– Exchange is where you deliver the messages to.
– Queues is where you consume the messages from.
– Binding is configuration that maps the message from the exchange to the queue(s).
Message (exchange) Patterns
As we all know they are two messaging models supported by JMS:
– One to one (queues) also know as point-to-point messaging. A message send to a queue will only be received by only one message consumer.
– One to many (topics) also know as publish-subscribe messaging. A message send to a topic will be received by all message consumers that subscribe to that topic.
AMQP only has queues. It however offers multiple different messaging patterns by introducing exchange types.
– Direct exchange is similar to the JMS point-to-point messaging based on queues, you can however potentially bind multiple queues to the exchange making it possible to have more than one message consumer.
– Fanout exchange, topic exchange and header exchange in AMQP are all similar to the JMS publish-subscribe messaging based on topics. With the fanout exchange queues bind to the exchange without a binding argument while topic exchange uses a binding argument using wildcards. The header exchange closely matches publish-subscribe messaging by using message header values to determine a binding match for routing.
Message (structure) differences
Like JMS AMQP also divides a message into similar sections (header, application properties, body) and has immutable routing and metadata properties. The main message structure difference is that with AMQP the body (payload) is a binary message. This shouldn’t be a big issue because normally both message producer and consumer would be aware of the message and be able to convert it from and back to the original object (XML, JSON etc.).
The AMQP specification is an open specification being developed by the AMQP working group. There are currently several open source implementations available like RabbitMQ, StormMQ and Apache Qpid.
For more information visit the AMQP website at http://www.amqp.org.
Before ending this blogpost a catchy real-world example of AMQP in action (exchange and queues).
Alvaro Videla, Imagine you go to the Apple store to buy some headphones. Some person at the store will ask you “what do you need?”. You answer that you need headphones, then they send you to queue behind some of their colleagues where they are helping people find the stuff they need.
Another person comes to the store, the same person that first attended you asks them “what do you need?” This client answers: “I need to get my Mac fixed”. The store person shows him where to queue in order to get tech support from his colleagues.
An so on.
In this case this person that’s asking “what do you need?” is the exchange, routing people to the appropriate queues according to their needs. Behind the queues there are many employees, being the “workers, or consumers” from those queues, attending each request at a time, on “first come first served” basis, probably doing some sort of round robin based on who’s available first.
If the person asking “what do you need” wasn’t there, then you would have to have internal knowledge of the store to know who could help you, possible bouncing from desk to desk until you found the right one where to queue.
Granted, navigating an Apple store isn’t that complex, but in an app where you might have many queues, servicing different kind of requests, it’s nice to have an exchange routing messages based on the routing and binding keys. A publisher just need to care on adding the right routing key, and a consumer just need to care on creating the proper queue with the right binding key, to say “I’m interested in these kind of messages”.
I hope this makes sense.