https://blogs.vmware.com/vfabric/2013/02/choosing-your-messaging-protocol-amqp-mqtt-or-stomp.

html

Choosing Your Messaging Protocol: AMQP, MQTT, or STOMP

297 Replies

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 and STOMP. 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 to expose 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.

For more information on this protocols and RabbitMQ, check out the book that VMware’s own Alvaro
Videla wrote on this topic: RabbitMQ in Action.