Advanced Message Queuing Protocol Specification

Joint Specifications Overview

Contributors: Cisco Systems, Inc., Credit Suisse, Envoy Technologies Inc., iMatix Corporation, IONA Technologies, JPMorganChase Bank & Co., Rabbit Technologies, a joint venture of CohesiveFT and LShift Ltd., Red Hat, Inc., TWIST Process Innovations Ltd., 29West Inc.

In response to internal requirements, market demand and partners' electronic trading needs, the contributors are collaborating on specifications for defining and building messaging infrastructure that is broadly applicable for enterprise use, totally open, platform agnostic, interoperable, and which aims to provide developers with simpler and more powerful ways of constructing messaging dependent applications. The resulting specifications are published under royalty-free terms.

Why the AMQProtocol?

There is a large gap in the current networking protocol standards; Nearly every case has been tackled except the most common guaranteed-delivery messaging middleware. Such middleware is the underpinning of both back and middle office systems, in every automated business process in medium to large enterprises, and is a necessary utility. JMS offers a partial solution, but is limited by its reliance on Java and its inability to specify any wire-level interoperability. A solution is this space is required to be an open work and be able to be used from any platform and any language.

This lack of open protocol standards means that interoperability between existing proprietary solutions is poor, and new entrants to the market have to reinvent even the most basic facilities before they can begin to add their own innovations. The AMQProtocol can be integrated into existing products or provide open interoperability for API's like JMS. The AMQProtocol can be used with most of the current messaging and Web Service Specifications such as JMS, SOAP, WS-Security, WS-Transactions, and many more, complimenting the existing work in the industry. AMQP will also provide specified routing to and from multicast for subnet optimizations or grid type deployments.

What is the AMQProtocol?

To enable complete interoperability for messaging middleware, both the networking protocol and the semantics of the broker services are specified in AMQProtocol. Thus AMQProtocol has:

• A defined set of messaging capabilities called the "AMQProtocol Model" (AMQProtocol Model). The AMQProtocol Model consists of a set of well-specified components that route and store messages within a broker service, plus a simple set of rules for wiring these components together;
• A network wire-level protocol, AMQProtocol, that lets client applications talk to a broker and interact with the AMQProtocol Model it implements.

One can partially imply the semantics of the server from the AMQProtocol specifications but having them explicitly described helps the understanding of the protocol.

The AMQProtocol Model

The model defines the server's semantics explicitly, since interoperability demands that these be the same in any given server implementation. The AMQProtocol Model specifies a modular set of components and standard rules for connecting these. There are three main types of component, which are connected into processing chains in the server to create the desired functionality:

• The "exchange" receives messages from publisher applications and routes these to "message queues", based on arbitrary criteria, usually message properties or content;
• The "message queue" stores messages until they can be safely processed by a consuming client application (or multiple applications);
• The "binding" defines the relationship between a message queue and an exchange and provides the message routing criteria.

This model emulates the classic middleware concepts of store-and-forward queues and topic subscriptions trivially. It also expresses less trivial concepts such as content-based routing, message queue forking, and on-demand message queues.

In very gross terms, an AMQProtocol server is analogous to an email server, with each exchange acting as a message transfer agent, and each message queue as a mailbox. The bindings define the routing tables in each transfer agent. Publishers send messages to individual transfer agents, which then route the messages into mailboxes. Consumers take messages from mailboxes, which creates a powerful and flexible model that is simple.

The AMQProtocol wire-format

The AMQProtocol wire-format is a binary protocol with modern features: it is multi-channel, negotiated, asynchronous, secure, portable, neutral, and efficient.

AMQProtocol is usefully split into two layers; a functional layer and a transport layer. The functional layer defines a set of commands (grouped into logical classes of functionality) that do useful work on behalf of the application. The transport layer that carries these methods from application to server, and back, and which handles channel multiplexing, framing, content encoding, heart-beating, data representation, and error handling. Both the transport layer & high-level protocols are plugable, which allows evolution of the protocol and the adoption of emerging technologies.

An open approach, feedback from implementation projects to the specifications:

The goal is to encourage the creation of excellent implementations of the protocol and that specifications themselves would likewise evolve based on technical merit and practicalities necessary for adoption by both the parties working the specification and the users in the greater community. Given this, one of the important aspects is how issues found in implementations due to protocol deficiencies make their way back into the specifications to be corrected.

In the same way anyone can issue a JIRA on any Apache project having signed the Apache CLA (modeled from Apache governance), anyone can issue a "JIRA" to the specification working group by means of the RLA (Reviewer License Agreement (PDF)). This agreement provides a license to that IP so that the specification team can incorporate it into specification and the specifications can remain entirely open and royalty free.

In the same spirit of an Apache-style process, if an individual has shown understanding of the project and made substantive contribution to the specification, based on technical merit and understanding of the goals of the work an invitation may be extended to have the new member join the specification Working Group. On such acceptance the Party is required to sign an agreement that makes sure they also grant ongoing and consistent licenses to the work.

The current AMQP specifications are published at a "version 0-10" level, indicating that the specifications are not in their final form. The specifications are published with the intent of getting feedback from the community in order to ensure that the eventual version 1.0 level of the specifications is mature and ready for use by developers and businesses.

Download the Advanced Message Queuing Protocol Version 0-10 specification

You can download/view the complete Advanced Message Queuing Protocol Version specifications, the schema files, and related Specifications:

• Download the Advanced Message Queuing Protocol Specification (PDF)
• Download the Advanced Message Queuing Protocol definitions (XML)