4 min read

AMQP 0-9-1

Written by:

Martin Fietkiewicz

Advanced Message Queuing Protocol (AMQP) is actually two different and incompatible messaging protocols with common lineage, but with divergent topologies and scopes. One branch includes all the versions up to and including 0-9-1; the other is the "redesigned" — but entirely different — version 1.0, also known as the ISO standard (19464) established in 2011 by the AMQP working group (now part of OASIS).

Version 1.0 was an attempt to create a version of the protocol that was so flexible that it could be everything to everyone, but did not account for the migration barriers that a wholly new, backward-incompatible protocol would create. As such, there was little incentive for developers to migrate from using version 0-9-1, which worked at the time and continues to work to this day, a decade later.

The respective degrees of adoption of these disparate queuing protocols have been driven by the requirements of different message broker implementations. Some, like RabbitMQ, focus on exchanges and routing keys and intend to support 0-9-1 indefinitely (while offering support for 1.0 as a plugin). Some, like Microsoft Azure Service Bus, focus on the specifications of the ISO standard (1.0), and their AMQP documentation doesn't even mention the existence of the otherwise ubiquitous version 0-9-1.

From this point forward, the focus of this brief introduction will be chiefly on version 0-9-1, used by RabbitMQ and Ably, among others. See our Intro to AMQP 1.0 to read more about the other protocol.

Note: Unless you're actually implementing AMQP, you don't generally choose brokers based on the protocol; you select brokers based on your needs as well as the brokers' feature sets fulfilling said requirements, and then go with the version of AMQP that they recommend.

Copy link to clipboard

History

AMQP is a messaging protocol originally created at JP Morgan Chase to directly address business requirements of efficient exchange of information within and between enterprises. However, it has much broader messaging middleware applicability. From the start it was meant to be interoperable, and an open standard among organizations, platforms, operating systems, and various broker implementations, initially in C, C++, and Erlang (RabbitMQ).

With the protocol gaining popularity (chiefly through RabbitMQ), a working group of major technology vendors and user firms (OASIS) came together to enshrine the broader ideas behind AMQP as an official ISO standard, ultimately creating a new, backward-incompatible protocol. This became version 1.0, which has far fewer semantic requirements, but is overall substantially more complex, and completely different at wire-level than 0-9-1.

The ultimate result has been very little migration, and at best support for 1.0 as a plug-in to existing messaging brokers, a large proportion of whom are perfectly happy with the "earlier" 0-9-1.

Copy link to clipboard

Technical overview

The Erlang implementation of AMQP by Rabbit Technologies in the late 2000s was one of the first, and became a de facto reference implementation. The specification outlines both the wire protocol — defining the semantics for negotiations between a client and a broker — and the logical model for the core queuing functionality of a message broker, addressing message-oriented architecture needs such as exchange bindings, queue provisioning, configurable routing, and adjustable time-to-live (TTL) among loosely-coupled publishers and subscribers distributed across systems and organizations.

RabbitMQ broker components

Figure 1: RabbitMQ broker components (based on diagram from CloudAMQP)

From a client perspective, the idea is to provision queues, name them, subscribe to them by name, and have publishers push messages to them as needed. Additionally, AMQP uses exchanges and bindings, and provides the ability to augment, reroute, store, and process messages to be consumed from the queue as "units of work" by the subscribed servers.

AMQP is an end-to-end communications protocol, full-featured from publisher to broker, and broker to client. In Ably's case, it is used chiefly for worker servers to consume multiple queues per channel, and multiple messages at a time in the following architectural configuration:

Worker servers using AMQP to consume messages from the Ably Reactor queue.

Figure 2: Worker servers using AMQP to consume messages from the Ably Reactor queue.

Copy link to clipboard

Benefits

AMQP is widely adopted, platform- and vendor-neutral, and interoperable at scale across organizational boundaries. It's simple, reliable, fast, and buffered. It allows reliable brokering of messages in configurable ways including publishing messages to the queue without waiting for consumers (decoupling); storing messages until a consumer processes them and sends an acknowledgment (resilience); and adding more consumers to increase throughput (scalability). It's also open-source and has been battle tested for over a decade.