AMQP 1.0

Advanced Message Queuing Protocol (or AMQP, currently version 1.0) is a messaging protocol created at JP Morgan Chase to directly address business requirements of efficient exchange of information within and between enterprises.  From the start it was meant to be interoperable, and an open standard among organizations, platforms, operating systems, and various broker implementations.  RabbitMQ is a message broker written in Erlang that originally sprang from version 0-9-0.  With time, a working group composed of major technology vendors and user firms came together to enshrine the ideas behind AMQP into an official ISO standard (19464), called version 1.0. 

This “version” is a misnomer of sorts: it ultimately became an entirely distinct protocol addressing different needs than 0-9-0 and subsequent 0-9-1.  While RabbitMQ happily continues employing the ubiquitous 0-9-1 protocol, Microsoft Azure Service Bus is an example of a real-world implementation of 1.0.  This introduction is a basic overview of AMQP 1.0 (ISO 19464). See our Intro to AMQP 0-9-1 to read more about the other protocol.

The AMQP standard provides guidance for building cross-platform apps using heterogenous brokers, libraries, and frameworks, all vendor-independent.  Part of the concept is the message being a "unit of work", placing business interactions above technical details.  AMQP primarily targets message-oriented middleware to help exchange unambiguous, reliable, asynchronous messages between applications.  Features include:

• Efficiency — a binary, connection-oriented protocol (on the wire)

• Reliability — includes settlement (acknowledgement) of delivery 

• Portable data representation — a cross-platform message encoding standard

• Flexibility — various topologies, from peer-peer to client-broker and broker-broker

• Broker-model independence — does not mandate brokers' internal implementations

• Scalability — designed for scale by working group of large enterprises  

• Future-proofing — long-lived information-processing ISO standard positioned as springboard for other ISO standards

AMQP is conceived with autonomous computing, cloud portability, and a secure IoT in mind, based on the idea that messaging is a more general idiom than the invocation of object methods, and thus should exist under the transport layer, not on top of it.  The standard includes queuing, routing (both p2p and pub/sub), QoS and delivery guarantees.  It also supports for SASL/TLS to offer secure transport (SASL/TLS) to value-bearing messages among organizations, platforms, and cloud services.

The protocol is vendor- and platform-agnostic, eliminating vendor lock-in.  It defines message formatting rather than mandating specific application behavior.  That is, instead of defining functions and creating libraries, it focuses instead on the definition of the byte sequences sent across the network.  

Copy link to clipboard

Definition vs. implementation

AMQP is meant to exist as a complementary technology to HTTP, with the latter devoted to request/response, and the former to pub/sub and transactions.  In that sense, AMQP could be thought of as HTTP for middleware — not a software product per se, but a general, broadly applicable protocol definition — with the implementation left up to others. 

Comparison table of AMQP and HTTP features.

AMQP is a superset of the semantics needed to implement APIs like JMS (the de-facto Java API standard for store-and-forward and pub-sub messaging), as well as any other such implementations in any other language on any OS and on any platform.  By design, any AMQP-compliant implementation can talk to any other, with support for the following core messaging patterns: 

• asynchronous directed messaging

• request/reply

• pub/sub

• store and forward