Choosing Your Messaging Protocol: AMQP, MQTT, or STOMP

One of the most common questions I’m asked to cover when I discuss software architecture topics is the difference between the various application messaging protocols that exist today—issues like how and why the protocols came about, and which one should be used in a particular application.

Their question is valid.

Today, application architects need to use a messaging broker to speed and scale their applications, particularly in the cloud. Even once you select your messaging middleware application, application developers need to then select the protocol. Understanding the subtle differences between them can be difficult.

Today, we will consider three of the most common and popular TCP/IP-based messaging protocols, and provide a quick summary on the advantages of each: AMQP, MQTT andSTOMP. Before we go on, I should also point out that all three of these protocols are supported in RabbitMQ version 3.0—something we will use as an example and come back to later.

So, in alphabetical order…

AMQP in a Nutshell

AMQP, which stands for Advanced Message Queuing Protocol, was designed as an open replacement for existing proprietary messaging middleware. Two of the most important reasons to use AMQP are reliability and interoperability. As the name implies, it provides a wide range of features related to messaging, including reliable queuing, topic-based publish-and-subscribe messaging, flexible routing, transactions, and security. AMQP exchanges route messages directly—in fanout form, by topic, and also based on headers.

There’s a lot of fine-grained control possible with such a rich feature set. You can restrict access to queues, manage their depth, and more. Features like message properties, annotations and headers make it a good fit for a wide range of enterprise applications. This protocol was designed for reliability at the many large companies who depend on messaging to integrate applications and move data around their organisation. In the case of RabbitMQ, there are many different language implementations and great samples available, making it a good choice for building large scale, reliable, resilient, or clustered messaging infrastructures.

AMQP is a binary wire protocol which was designed for interoperability between different vendors. Where other protocols have failed, AMQP adoption has been strong. Companies like JP Morgan use it to process 1 billion messages a day. NASA uses it for Nebula Cloud Computing. Google uses it for complex event processing. Here are a couple of additional AMQP examples and links:

• It is used in one of the world’s largest biometric databases India’s Aadhar project—home to 1.2 billion identities.
• It is used in the Ocean Observatories Initiative—an architecture that collects 8 terabytes of data per day.
• More examples and links are available at amqp.org.

MQTT Overview

MQTT (Message Queue Telemetry Transport) was originally developed out of IBM’s pervasive computing team and their work with partners in the industrial sector. Over the past couple of years the protocol has been moved into the open source community, seen significant growth in popularity as mobile applications have taken off, and it is in the process of moving into the hands of a standards body.

The design principles and aims of MQTT are much more simple and focused than those of AMQP—it provides publish-and-subscribe messaging (no queues, in spite of the name) and was specifically designed for resource-constrained devices and low bandwidth, high latency networks such as dial up lines and satellite links, for example. Basically, it can be used effectively in embedded systems.

One of the advantages MQTT has over more full-featured “enterprise messaging” brokers is that its intentionally low footprint makes it ideal for today’s mobile and developing “Internet of Things” style applications. In fact, companies like Facebook are using it as part of their mobile applications because it has such a low power draw and is light on network bandwidth.

Some of the MQTT-based brokers support many thousands of concurrent device connections. It offers three qualities of service: 1) fire-and-forget / unreliable,2) “at least once” to ensure it is sent a minimum of one time (but might be sent more than one time), and 3) “exactly once”.

MQTT’s strengths are simplicity (just five API methods), a compact binary packet payload (no message properties, compressed headers, much less verbose than something text-based like HTTP), and it makes a good fit for simple push messaging scenarios such as temperature updates, stock price tickers, oil pressure feeds or mobile notifications. It is also very useful for connecting machines together, such as connecting an Arduino device to a web service with MQTT.

Learn more at mqtt.org.

The Dirt on STOMP

STOMP (Simple/Streaming Text Oriented Messaging Protocol) is the only one of these three protocols to be text-based, making it more analogous to HTTP in terms of how it looks under the covers. Like AMQP, STOMP provides a message (or frame) header with properties, and a frame body. The design principles here were to create something simple, and widely-interoperable. For example, it’s possible to connect to a STOMP broker using something as simple as a telnet client.

STOMP does not, however, deal in queues and topics—it uses a SEND semantic with a “destination” string. The broker must map onto something that it understands internally such as a topic, queue, or exchange. Consumers then SUBSCRIBE to those destinations. Since those destinations are not mandated in the specification, different brokers may support different flavours of destination. So, it’s not always straightforward to port code between brokers.

However, STOMP is simple and lightweight (although somewhat verbose on the wire), with a wide range of language bindings. It also provides some transactional semantics. One of the most interesting examples is with RabbitMQ Web Stomp which allows you toexpose messaging in a browser through websockets. This opens up some interesting possibilities—like updating a browser, mobile app, or machine in real-time with all types of information.

Learn more at stomp.github.com.

RabbitMQ: The Polyglot Broker

Hopefully, this can help many begin to navigate the protocol soup out there for each of your use cases. Since it is common for companies to have many applications with different needs, it is certainly possible you may need all three brokers across different applications. That’s where a solid multiprotocol, polyglot broker like RabbitMQ comes in—since it can send STOMP, MQTT, or AMQP in and get one of the other ones out. You don’t need to be locked-in by one of these protocols—all three are supported by the RabbitMQ broker, making it an ideal choice for interoperability between applications. The plugin architecture also enables RabbitMQ to evolve to support additional or updated versions of these protocols in the future.