About AMQP

What is AMQP?

AMQP is an Open Standard for Messaging Middleware:

By complying to the AMQP standard, middleware products written for different platforms and in different languages can send messages to one another. AMQP addresses the problem of transporting value-bearing messages across and between organisations in a timely manner.

Why should you care?

Messaging and integration is a necessary part of all enterprise systems

• All significant IT efforts include a messaging and integration component (10%-30% of project cost)
• Proprietary middleware has been a source of lock-in, preventing competition in middleware for both quality and cost
• Interoperability is more difficult than it need be

Other open business standards would ideally avoid being founded on proprietary technologies, and use open information and business process models and message formats. However, NO suitable open technology exists to actually send the messages!

AMQP aims to become the de-facto open standard for messaging middleware

How AMQP is different from other middleware standards?

Why AMQP is different from other middleware standards:

• A straight-forward and complete solution for business messaging
• Completely open
• Created by users and technologists working together
• Made to satisfy real needs
• Specifies store-and-forward and publish-and-subscribe semantics in one specification

AMQP aims to specify the basic messaging middleware needs for common business applications.

What does the AMQP Specification Encompass?

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

• A defined set of messaging capabilities called the "AMQP Model". The AMQP Model consists of well-specified components that route and store messages within a broker service, as well as a simple set of rules for wiring these components together.
• A network wire-level format that allows client applications to talk to a broker and interact with The AMQP model it implements.

It is possible to partially imply the semantics of the server from the AMQP specification. However, having them explicitly described helps in understanding of the protocol.

Why was AMQP developed?

Though most networking protocol scenarios have been addressed, a large gap exists in common guaranteed-delivery messaging middleware. Middleware is a necessary utility; it underpins mission-critical IT systems and plays a key role in automating business processes in medium and large organizations.

Currently, JMS offers only a partial solution because it is limited by its reliance on Java and its inability to specify any wire-level interoperability. It is crucial that any solution that addresses this problem be an open work that can be leveraged from any platform and any language.

The Advanced Message Queuing Protocol (AMQP) can be used as the basis for new products, integrated into existing systems, or provide enhanced interoperability for APIs, including JMS.

AMQP can be used with most of the current messaging and Web Service Specifications, such as JMS, SOAP, WS-Security, WS-Transactions, complimenting existing work in the industry. AMQP will also provide specified routing to and from multicast for subnet optimizations or grid-type deployments.

The AMQP Model

The AMQP model explicitly defines a server's semantics because interoperability demands the same semantics for any server implementation. The model specifies a modular set of components and standard rules for connecting these components. There are three main types of components 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. It also expresses less trivial concepts such as content-based routing, message queue forking, and on-demand message queues.

In very gross terms, an AMQP 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 AMQP Wire-level Format

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

The AMQP wire-level format is 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 layers are plugable, which allows evolution of the protocol and the adoption of emerging technologies.

Download the AMQP Specifications

Specifications can be downloaded from Using AMQP page.

Find AMQP Products

See the AMQP Products page.