The Advanced Message Queuing Protocol is an open standard application layer protocol for
message-oriented middleware.
The defining features of AMQP are message orientation, queuing, routing, reliability
and security.
AMQP mandates the behavior of the messaging provider and client to the extent that implementations
from different vendors are truly interoperable, in the same way as SMTP, HTTP, FTP, etc. have
created interoperable systems.
Previous attempts to standardize middleware have happened at the API level and thus did
not ensure interoperability.
Unlike JMS, which merely defines an API, AMQP is a wire-level protocol.
A wire-level protocol is a description of the format of the data that is sent across
the network as a stream of octets.
Consequently any tool that can create and interpret messages that conform to this data
format can interoperate with any other compliant tool irrespective of implementation language.
Overview AMQP is a binary, application layer protocol,
designed to efficiently support a wide variety of messaging applications and communication
patterns.
It provides flow controlled, message-oriented communication with message-delivery guarantees
such as at-most-once, at-least-once and exactly-once, and authentication and/or encryption based
on SASL and/or TLS.
It assumes an underlying reliable transport layer protocol such as Transmission Control
Protocol.
The AMQP specification is defined in several layers: a type system, a symmetric, asynchronous
protocol for the transfer of messages from one process to another, a standard, extensible
message format and a set of standardised but extensible 'messaging capabilities.'
History AMQP was originated in 2003 by John O'Hara
at JPMorgan Chase in London, UK.
From the beginning AMQP was conceived as a co-operative open effort.
Initial development was by JPMorgan Chase.
from mid-2004 to mid-2006 who contracted iMatix Corporation for a C broker and protocol documentation.
In 2005 JPMorgan Chase approached other firms to form a working group that included Cisco
Systems, IONA Technologies, iMatix, Red Hat, and Transaction Workflow Innovation Standards
Team.
In the same year JPMorgan Chase partnered with Red Hat to create Apache Qpid, initially
in Java and soon after C++.
Independently, RabbitMQ was developed in Erlang by Rabbit Technologies, followed later by
the Microsoft and StormMQ implementations.
The working group grew to 23 companies including Bank of America, Barclays, Cisco Systems,
Credit Suisse, Deutsche Börse Systems, Goldman Sachs, HCL Technologies Ltd, Progress Software,
IIT Software, INETCO Systems Limited, Informatica Corporation, JPMorgan Chase, Microsoft Corporation,
my-Channels, Novell, Red Hat, Software AG, Solace Systems, StormMQ, Tervela Inc., TWIST
Process Innovations ltd, VMware and WSO2.
In August 2011, the AMQP working group announced its reorganization into an OASIS member section.
AMQP 1.0 was released by the AMQP working group on 30 October 2011, at a conference
in New York.
At the event Microsoft, Red Hat, VMware, Apache, INETCO and IIT Software demonstrated software
running the protocol in an interoperability demonstration.
The next day, on 1 November 2011, the formation of an OASIS Technical Committee was announced
to advance this contributed AMQP version 1.0 through the international open standards process.
The first draft from OASIS was released in February 2012, the changes as compared to
that published by the Working Group being restricted to edits for improved clarity.
The second draft was released for public review on 20 June, and AMQP was approved as an OASIS
standard on 31 October 2012.
OASIS AMQP was approved for release as an ISO and IEC International Standard in April
2014.
AMQP 1.0 was balloted through the Joint Technical Committee on Information Technology of the
International Standards Organization and the International Electrotechnical Commission.
The approved OASIS AMQP submission has been given the designation, ISO/IEC 19464.
Previous versions of AMQP were 0-8, published in June 2006, 0-9, published in December 2006,
0-10 published in February 2008 and 0-9-1, published in November 2008.
These earlier releases are significantly different from the final 1.0 specification that emerged.
However existing implementations may continue to support these earlier versions alongside
1.0.
Whilst AMQP originated in the financial services industry, it has general applicability to
a broad range of middleware problems.
Type system AMQP defines a self-describing encoding scheme
allowing interoperable representation of a wide range of commonly used types.
It also allows typed data to be annotated with additional meaning.
The example given in the specification is indicating a particular string value is in
fact to be understood as a URL.
Likewise a map value containing key-value pairs for 'name', 'address' etc., might be
annotated as being of representation of a 'customer' type.
The type-system is used to define a message format allowing standard and extended meta-data
to be expressed and understood by processing entities.
It is also used to define the communication primitives through which messages are exchanged
between such entities, i.e. the AMQP frame bodies.
AMQP performatives and the link protocol The basic unit of data in AMQP is a frame.
There are nine AMQP frame bodies defined that are used to initiate, control and tear down
the transfer of messages between two peers.
These are: open
begin attach
transfer flow
disposition detach
end close
The link protocol is at the heart of AMQP.
An attach frame body is sent to initiate a new link; a detach to tear down a link.
Links may be established in order to receive or send messages.
Messages are sent over an established link using the transfer frame.
Messages on a link flow in only one direction.
Transfers are subject to a credit based flow control scheme, managed using flow frames.
This allows a process to protect itself from being overwhelmed by too large a volume of
messages or more simply to allow a subscribing link to pull messages as and when desired.
Each transferred message must eventually be settled.
Settlement ensures that the sender and receiver agree on the state of the transfer, providing
reliability guarantees.
Changes in state and settlement for a transfer are communicated between the peers using the
disposition frame.
Various reliability guarantees can be enforced this way: at-most-once, at-least-once and
exactly-once.
Multiple links, in both directions, can be grouped together in a session.
A session is a bidirectional, sequential conversation between two peers that is initiated with a
begin frame and terminated with an end frame.
A connection between two peers can have multiple sessions multiplexed over it, each logically
independent.
Connections are initiated with an open frame in which the sending peer's capabilities are
expressed, and terminated with a close frame.
Message format AMQP defines as the bare message, that part
of the message that is created by the sending application.
This is considered immutable as the message is transferred between one or more processes.
Ensuring the message as sent by the application is immutable allows for end-to-end message
signing and/or encryption and ensures that any integrity checks remain valid.
The message can be annotated by intermediaries during transit, but any such annotations are
kept distinct from the immutable bare message.
Annotations may be added before or after the bare message.
The header is a standard set of delivery related annotations that can be requested or indicated
for a message and includes time to live, durability, priority.
The bare message itself is structured as an optional list of standard properties, an optional
list of application-specific properties and a body, which AMQP refers to as application
data.
Properties are specified in the AMQP type system, as are annotations.
The application data can be of any form, and in any encoding the application chooses.
One option is to use the AMQP type system to send structured, self-describing data.
Messaging capabilities The link protocol transfers messages between
two nodes but assumes very little as to what those nodes are or how they are implemented.
A key category is those nodes used as a rendezvous point between senders and receivers of messages.
The AMQP specification calls such nodes distribution nodes and codifies some common behaviors.
This includes: some standard outcomes for transfers, through
which receivers of messages can for example accept or reject messages
a mechanism for indicating or requesting one of the two basic distribution patterns, competing-
and non-competing- consumers, through the distribution modes move and copy respectively
the ability to create nodes on-demand, e.g. for temporary response queues
the ability to refine the set of message of interest to a receiver through filters
Though AMQP can be used in simple peer-to-peer systems, defining this framework for messaging
capabilities additionally enables interoperability with messaging intermediaries in larger, richer
messaging networks.
The framework specified covers basic behaviors but allows for extensions to evolve that can
be further codified and standardised.
Implementations AMQP 1.0 broker implementations
SwiftMQ, a JMS, AMQP 1.0 and AMQP 0.9.1 broker and a free AMQP 1.0 client.
Windows Azure Service Bus, Microsoft's cloud-based messaging service
Apache Qpid, an open-source project at the Apache Foundation
Apache ActiveMQ, an open-source project at the Apache Foundation
Apache Apollo, open-source modified version of the ActiveMQ project at the Apache Foundation.
The threading functionality of ActiveMQ has been replaced and non-blocking techniques
implemented more widely.
RabbitMQ an open-source project sponsored by Pivotal, supports AMQP 1.0 via experimental
plugin IBM MQ Light
Not yet AMQP 1.0 broker implementations JORAM, a Java open-source implementation from
the OW2 Consortium.
Apache Qpid maintains support for multiple AMQP versions
Red Hat Enterprise MRG, based on Apache Qpid.
StormMQ, a hosted message queuing service using AMQP.
It is offered as a commercial managed service.
WSO2 offer WSO2 message broker.
See also interoperability examples Kaazing offer an AMQP gateway
Solace Systems offer some integration examples with AMQP
Client implementations Apache Qpid Proton AMQP 1.0 clients in C,
Python, Perl, Ruby, PHP and Java released under the Apache open source license.
SwiftMQ AMQP 1.0 Java Client a free Java client for AMQP 1.0.
Service Bus .NET API Microsoft's AMQP 1.0 .NET client
DE.SETF.AMQP, a Common Lisp client library for AMQP 0-9-1.
EasyNetQ an open source AMQP 0-9-1 .NET client.
RabbitMQ's community lists a broad set of clients and tools
Specification AMQP protocol version 1.0 is the current specification
version.
It focuses on core features which are necessary for interoperability at Internet scale.
It contains less explicit routing than previous versions because core functionality is the
first to be rigorously standardized.
AMQP 1.0 interoperability has been more extensively tested with more implementors than prior versions.
The AMQP website contains the OASIS specification for version 1.0.
Earlier versions of AMQP, published prior to the release of 1.0 and significantly different
from it, include: AMQP 0-9-1, which has clients available "for
many popular programming languages and platforms" AMQP 0-10
Comparable specifications These are the known open protocol specifications
that cover the same or similar space as AMQP: Streaming Text Oriented Messaging Protocol,
a text-based protocol developed at Codehaus; uses the JMS-like semantics of 'destination'.
Extensible Messaging and Presence Protocol, the Extensible Messaging and Presence Protocol.
MQTT, a lightweight pub-sub protocol.
OpenWire as used by ActiveMQ.
An informal comparison of XMPP and AMQP may be found here.
Java Message Service, is often compared to AMQP.
However, JMS is an API specification that defines how message producers and consumers
are implemented.
JMS does not guarantee interoperability between implementations, and the JMS-compliant messaging
system in use may need to be deployed on both client and server.
On the other hand, AMQP is a wire-level protocol specification.
In theory AMQP provides interoperability as different AMQP-compliant software can be deployed
on the client and server sides.
Note that, like HTTP and XMPP, AMQP does not have a standard API.
See also Message queue
Message queuing service Notes
References
External links AMQP Website
OASIS AMQP technical committee High-level Overview of AMQP and the AMQP Model
OMG Analysis of AMQP and comparison with DDS-RTPS Google Tech Talk, with video and slides, about
RabbitMQ Presentation of AMQP and RestMS messaging
at FOSDEM 2009 List of AMQP clients