Advanced Message Queuing Protocol
Encyclopedia
The Advanced Message Queuing Protocol (AMQP) is an open standard
application layer
protocol for message-oriented middleware
. The defining features of AMQP are message orientation, queuing, routing (including point-to-point and publish-and-subscribe
), reliability and security.
AMQP mandates the behaviour 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 (e.g. JMS
) and this did not create 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 octet
s. 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.
AMQP is middleware to provide a point of rendezvous between back-end systems (data stores and services) and front end systems such as end user applications. The first applications were for trading desks in the financial industry, where real time order and market data are transmitted. Though originally used inside of enterprises, AMQP can easily be used to move messages between organizations.
AMQP lets system architects build common messaging patterns out of a simpler underlying model. Typical messaging patterns are: request-response, in which messages are sent to or from specific recipients, publish-and-subscribe, in which information is distributed to a set of recipients according to various subscription criteria, and round-robin, in which tasks are distributed fairly among a set of recipients. Realistic applications combine these, e.g. round-robin for distributing work plus request-response for sending back responses.
The protocol specification defines a binary wire protocol used between a client and server (also known as a broker). In addition the specification outlines a message queuing model and services that an implementation must provide.
The queuing model of AMQP provides for a wide range of messaging use-cases and further refines the functions of the clients and brokers. The function of brokers can be usefully broken into two kinds: exchanges and message queues. Message queues store messages, and various implementations can achieve various quality of service. For example a slow but tornado-proof message queue would keep redundant copies in multiple geographic regions while a fast but fragile message queue might keep everything in a single process's RAM. To help improve interoperability some of these aspects of the message queues are specified in the protocol, e.g. you can state what you need when asking a message queue broker implementation to create a new queue.
The standard AMQP exchanges have no semantics for storing messages. They route them to queues, which store them on behalf of recipients. Exchanges implement a range of message routing techniques: one-to-one message passing (like email to one recipient), one-to-N (like an email list), one-to-one-of-N (like a queue for the next open checkout), and so on. Since all exchanges accept messages from N senders, AMQP allows all one-to-any routing to be N-to-any. The rules that configure an exchange, known as bindings, can range from very simple (pass everything into this message queue) to procedural inspections of message content. AMQP allows arbitrary exchange semantics through custom exchanges (which can queue, generate, consume, and route messages in any way desired by the implementation).
Messages consist of an envelope of properties used in routing and by applications and a content, of any size. AMQP message contents are opaque binary blobs. Messages are passed between brokers and clients using the protocol commands Basic.Publish and Basic.Deliver. These commands are asynchronous so that conditions that arise from a command's evaluation are signalled by sending additional commands back on the channel that carried the command originally. AMQP also provides a synchronous message delivery command, Basic.Get/Get-Ok.
Examples of error conditions include signalling by an exchange that it could not route a message because no route was found, or signalling that a message queue declined to accept a message (say because it was full). Message brokers may be configured to handle exceptions in different ways. For example, routing the associated message to a dead letter queue or even bringing the broker to a hard stop.
and iMatix Corporation who also developed implementations in C/C++ and Java. JPMorgan Chase & Co. and iMatix documented the protocol as an interoperable specification and assigned to a working group that included Cisco Systems
, TWIST
, IONA Technologies
, and iMatix. The working group consists of Bank of America
, Barclays, Cisco Systems
, Credit Suisse
, Deutsche Börse Systems
, Envoy Technologies, Inc., Goldman Sachs
, HCL Technologies Ltd, Progress Software
, iMatix Corporation, INETCO Systems, Informatica Corporation (incl. 29 West), JPMorgan Chase Bank Inc. N.A
, Microsoft Corporation
, my-Channels, Novell
, Red Hat, Inc.
, Software AG, Solace Systems
, StormMQ
, Tervela Inc.
, TWIST Process Innovations ltd, VMware (incl. Rabbit Technologies) and WS02.
A notable design goal of AMQP was to enable the creation of open standard
protocol stack
s for business messaging both within and between firms by combining AMQP with one of the many open standards describing business transactions, such as FpML
or more generically as a reliable transport for SOAP
.
Whilst AMQP originated in the financial services industry, it has general applicability to a broad range of middleware
problems.
The entities used for the actual sending and receiving of messages are all declared on a channel. A declaration assures the issuing client that the entity exists (or was previously declared by another client). Some of the entities are named. The naming is unique within the scope of the entity and its broker. An attempt to declare an entity with the same name results in an error; to change entity properties, one must delete it first (and then redeclare).
Clients have no way to retrieve the list of all available named entities; no such operations are defined in the AMQP specification. Only if the name is known the client can perform operations on the entity.
Names are encoded in UTF-8
, must be between 1 and 255 characters in length and must start with a digit, a letter or an underscore character.
Messages are guaranteed to be delivered in the first-in-first-out order, unless certain kinds of rerouting operations (e.g. due to failures) occur or due to the priorities in the message.
The properties of queues are:
Note that queues are scheduled to replace exchanges in AMQP/1.0.
Not all these are implemented as standard, or by all implementations.
An exchange will deliver up to one copy of a message to a queue if the routing key in the message matches the routing key in a binding (multiple semantically identical bindings will not result in duplication). What constitutes a match depends on the type of exchange:
Other types of exchanges, e.g. vendor-specific, are explicitly permitted in the specification.
The concept of binding named queues to named exchanges has powerful properties (with binding making those two entities independent of each other). It is, for instance, possible to bind a single queue with multiple bindings to the same or to different exchanges. Or multiple consumers can share the name of a queue and bind to it with the same parameters and will therefore get only message that the other consumers did not consume. Or multiple consumers can declare independent queues but share the bindings and get all the message every other consumer would get on the bound exchange with these bindings.
The 1.0 specification changes the AMQP model illustrated above by removing the concepts of exchanges and bindings, and replacing these with queues and links. This change aims to remedy two problems with the previous approach:
According to John O'Harahttp://lists.amqp.org/pipermail/amqp-pmc/2010-May/001319.html however, JPMorganChase and RedHat introduced links into AMQP/1.0 simply to solve an operational problem of slow consumers causing memory build up in brokers.
Other changes include the introduction of a queue addressing schema similar to E-mail
and XMPP
. This raises addresses to first-class entities, and allows for the publication of service location record
s using the DNS
.
The process of bringing the 1.0 Specification to a Standard involves a requirement elicitation phase, then the release of a "public review" spec (PR) which should be reviewed and asked for comments, optionally resulting in further modifications. When there are no substantive changes to the PR, it is voted to be the 1.0 Recommendation. At least two implementations have passed the test coverage. The Recommendation has been voted to be 1.0 Standard. , a the final spec has been produced and was accepted by the AMQP working group.
There are also vendor specific, proprietary specifications includes those by the Amazon Simple Queue Service
, IBM WebSphere MQ, Microsoft Message Queuing
, JMS
and the OpenWire as used by ActiveMQ.
There has not as yet been a formal comparison of these and other protocols in the same space, although an informal comparison of XMPP
and AMQP may be found here. JMS
, the Java Messaging service, is often compared to AMQP. However, JMS is an API specification (part of the Java EE
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.
Open standard
An open standard is a standard that is publicly available and has various rights to use associated with it, and may also have various properties of how it was designed . There is no single definition and interpretations vary with usage....
application layer
Application layer
The Internet protocol suite and the Open Systems Interconnection model of computer networking each specify a group of protocols and methods identified by the name application layer....
protocol for message-oriented middleware
Message-oriented middleware
Message-oriented middleware is software or hardware infrastructure supporting sending and receiving messages between distributed systems. MOM allows application modules to be distributed over heterogeneous platforms and reduces the complexity of developing applications that span multiple...
. The defining features of AMQP are message orientation, queuing, routing (including point-to-point and publish-and-subscribe
Publish/subscribe
Publish–subscribe is a messaging pattern where senders of messages, called publishers, do not program the messages to be sent directly to specific receivers, called subscribers. Published messages are characterized into classes, without knowledge of what, if any, subscribers there may be...
), reliability and security.
AMQP mandates the behaviour 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
Middleware
Middleware is computer software that connects software components or people and their applications. The software consists of a set of services that allows multiple processes running on one or more machines to interact...
have happened at the API level (e.g. JMS
Java Message Service
The Java Message Service API is a Java Message Oriented Middleware API for sending messages between two or more clients. JMS is a part of the Java Platform, Enterprise Edition, and is defined by a specification developed under the Java Community Process as JSR 914...
) and this did not create 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 octet
Octet (computing)
An octet is a unit of digital information in computing and telecommunications that consists of eight bits. The term is often used when the term byte might be ambiguous, as there is no standard for the size of the byte.-Overview:...
s. 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 was originally designed to provide a vendor-neutral (i.e. interoperable across multiple vendors) protocol for managing the flow of messages across an enterprise's business systems.AMQP is middleware to provide a point of rendezvous between back-end systems (data stores and services) and front end systems such as end user applications. The first applications were for trading desks in the financial industry, where real time order and market data are transmitted. Though originally used inside of enterprises, AMQP can easily be used to move messages between organizations.
AMQP lets system architects build common messaging patterns out of a simpler underlying model. Typical messaging patterns are: request-response, in which messages are sent to or from specific recipients, publish-and-subscribe, in which information is distributed to a set of recipients according to various subscription criteria, and round-robin, in which tasks are distributed fairly among a set of recipients. Realistic applications combine these, e.g. round-robin for distributing work plus request-response for sending back responses.
The protocol specification defines a binary wire protocol used between a client and server (also known as a broker). In addition the specification outlines a message queuing model and services that an implementation must provide.
The queuing model of AMQP provides for a wide range of messaging use-cases and further refines the functions of the clients and brokers. The function of brokers can be usefully broken into two kinds: exchanges and message queues. Message queues store messages, and various implementations can achieve various quality of service. For example a slow but tornado-proof message queue would keep redundant copies in multiple geographic regions while a fast but fragile message queue might keep everything in a single process's RAM. To help improve interoperability some of these aspects of the message queues are specified in the protocol, e.g. you can state what you need when asking a message queue broker implementation to create a new queue.
The standard AMQP exchanges have no semantics for storing messages. They route them to queues, which store them on behalf of recipients. Exchanges implement a range of message routing techniques: one-to-one message passing (like email to one recipient), one-to-N (like an email list), one-to-one-of-N (like a queue for the next open checkout), and so on. Since all exchanges accept messages from N senders, AMQP allows all one-to-any routing to be N-to-any. The rules that configure an exchange, known as bindings, can range from very simple (pass everything into this message queue) to procedural inspections of message content. AMQP allows arbitrary exchange semantics through custom exchanges (which can queue, generate, consume, and route messages in any way desired by the implementation).
Messages consist of an envelope of properties used in routing and by applications and a content, of any size. AMQP message contents are opaque binary blobs. Messages are passed between brokers and clients using the protocol commands Basic.Publish and Basic.Deliver. These commands are asynchronous so that conditions that arise from a command's evaluation are signalled by sending additional commands back on the channel that carried the command originally. AMQP also provides a synchronous message delivery command, Basic.Get/Get-Ok.
Examples of error conditions include signalling by an exchange that it could not route a message because no route was found, or signalling that a message queue declined to accept a message (say because it was full). Message brokers may be configured to handle exceptions in different ways. For example, routing the associated message to a dead letter queue or even bringing the broker to a hard stop.
Development
AMQP was developed from mid-2004 to mid-2006 by JPMorgan Chase & Co.JPMorgan Chase & Co.
JPMorgan Chase & Co. is an American multinational banking corporation of securities, investments and retail. It is the largest bank in the United States by assets and market capitalization.It is a major provider of financial services, with assets of $2 trillion and according to Forbes magazine is...
and iMatix Corporation who also developed implementations in C/C++ and Java. JPMorgan Chase & Co. and iMatix documented the protocol as an interoperable specification and assigned to a working group that included Cisco Systems
Cisco Systems
Cisco Systems, Inc. is an American multinational corporation headquartered in San Jose, California, United States, that designs and sells consumer electronics, networking, voice, and communications technology and services. Cisco has more than 70,000 employees and annual revenue of US$...
, TWIST
Transaction Workflow Innovation Standards Team
Transaction Workflow Innovation Standards Team is a not-for-profit industry standards group. It does not charge anything for involvement. The main goal of Twist is to create non-proprietary XML message standards for the financial services industry...
, IONA Technologies
IONA Technologies
IONA Technologies was an Irish software company. It was founded in 1991.The company began life as a campus company in Trinity College, Dublin and maintains headquarters in Dublin, Boston and Tokyo....
, and iMatix. The working group consists of Bank of America
Bank of America
Bank of America Corporation, an American multinational banking and financial services corporation, is the second largest bank holding company in the United States by assets, and the fourth largest bank in the U.S. by market capitalization. The bank is headquartered in Charlotte, North Carolina...
, Barclays, Cisco Systems
Cisco Systems
Cisco Systems, Inc. is an American multinational corporation headquartered in San Jose, California, United States, that designs and sells consumer electronics, networking, voice, and communications technology and services. Cisco has more than 70,000 employees and annual revenue of US$...
, Credit Suisse
Credit Suisse
The Credit Suisse Group AG is a Swiss multinational financial services company headquartered in Zurich, with more than 250 branches in Switzerland and operations in more than 50 countries.-History:...
, Deutsche Börse Systems
Deutsche Börse
Deutsche Börse AG is a marketplace organizer for the trading of shares and other securities. It also is a transaction services provider. It gives companies and investors access to global capital markets. It is a joint stock company and was founded in 1993. The headquarters are in Frankfurt,...
, Envoy Technologies, Inc., Goldman Sachs
Goldman Sachs
The Goldman Sachs Group, Inc. is an American multinational bulge bracket investment banking and securities firm that engages in global investment banking, securities, investment management, and other financial services primarily with institutional clients...
, HCL Technologies Ltd, Progress Software
Progress Software
Progress Software Corporation , formerly Data Language Corporation, is an American software company that sells business application infrastructure software. Its best known product is the OpenEdge ABL , which was developed in the early 1980s. The best known application written in Progress is...
, iMatix Corporation, INETCO Systems, Informatica Corporation (incl. 29 West), JPMorgan Chase Bank Inc. N.A
JPMorgan Chase & Co.
JPMorgan Chase & Co. is an American multinational banking corporation of securities, investments and retail. It is the largest bank in the United States by assets and market capitalization.It is a major provider of financial services, with assets of $2 trillion and according to Forbes magazine is...
, Microsoft Corporation
Microsoft
Microsoft Corporation is an American public multinational corporation headquartered in Redmond, Washington, USA that develops, manufactures, licenses, and supports a wide range of products and services predominantly related to computing through its various product divisions...
, my-Channels, Novell
Novell
Novell, Inc. is a multinational software and services company. It is a wholly owned subsidiary of The Attachmate Group. It specializes in network operating systems, such as Novell NetWare; systems management solutions, such as Novell ZENworks; and collaboration solutions, such as Novell Groupwise...
, Red Hat, Inc.
Red Hat
Red Hat, Inc. is an S&P 500 company in the free and open source software sector, and a major Linux distribution vendor. Founded in 1993, Red Hat has its corporate headquarters in Raleigh, North Carolina with satellite offices worldwide....
, Software AG, Solace Systems
Solace systems
Solace Systems is a content networking company based in Kanata, Ontario, Canada that manufactures and sells middleware appliances. Middleware appliances are rack-mountable network devices that implement message-oriented middleware and content-based routing in purpose-built hardware...
, StormMQ
StormMQ
In computing, StormMQ is a message queuing service , using the standard Advanced Message Queuing Protocol . StormMQ is a hosted, On-Premise or Cloud solution for Machine-to-Machine Message Queuing using AMQP...
, Tervela Inc.
Tervela
Tervela Inc. is a privately-held technology company based in New York, New York and Acton, Massachusetts. The company is backed by Goldman Sachs, , Acartha Technology Group, and North Hill Ventures...
, TWIST Process Innovations ltd, VMware (incl. Rabbit Technologies) and WS02.
A notable design goal of AMQP was to enable the creation of open standard
Open standard
An open standard is a standard that is publicly available and has various rights to use associated with it, and may also have various properties of how it was designed . There is no single definition and interpretations vary with usage....
protocol stack
Protocol stack
The protocol stack is an implementation of a computer networking protocol suite. The terms are often used interchangeably. Strictly speaking, the suite is the definition of the protocols, and the stack is the software implementation of them....
s for business messaging both within and between firms by combining AMQP with one of the many open standards describing business transactions, such as FpML
FpML
FpML is an XML message standard for the OTC Derivatives industry.All categories of privately negotiated derivatives will eventually be included within the standard...
or more generically as a reliable transport for SOAP
SOAP
SOAP, originally defined as Simple Object Access Protocol, is a protocol specification for exchanging structured information in the implementation of Web Services in computer networks...
.
Whilst AMQP originated in the financial services industry, it has general applicability to a broad range of middleware
Middleware
Middleware is computer software that connects software components or people and their applications. The software consists of a set of services that allows multiple processes running on one or more machines to interact...
problems.
The AMQP model
AMQP defines a number of entities. From a connection perspective the relevant ones are:- Message broker: a server to which AMQ clients connect using the AMQ protocol. Message brokers can run in a cluster but these details are implementation specific and are not covered by the specification.
- User: a user is an entity that, by providing credentials in form of a password, may or may not be authorized to connect to a broker.
- Connection: a physical connection e.g. using TCP/IP or SCTP. A connection is bound to a user.
- Channel: a logical connection that is tied to a connection. Hence communication over a channel is stateful. Clients that perform concurrent operations on a connection should maintain a distinct channel for each of those. For example, a client that uses a threaded model of concurrency can store the channel data in a thread-local variable.
The entities used for the actual sending and receiving of messages are all declared on a channel. A declaration assures the issuing client that the entity exists (or was previously declared by another client). Some of the entities are named. The naming is unique within the scope of the entity and its broker. An attempt to declare an entity with the same name results in an error; to change entity properties, one must delete it first (and then redeclare).
Clients have no way to retrieve the list of all available named entities; no such operations are defined in the AMQP specification. Only if the name is known the client can perform operations on the entity.
Names are encoded in UTF-8
UTF-8
UTF-8 is a multibyte character encoding for Unicode. Like UTF-16 and UTF-32, UTF-8 can represent every character in the Unicode character set. Unlike them, it is backward-compatible with ASCII and avoids the complications of endianness and byte order marks...
, must be between 1 and 255 characters in length and must start with a digit, a letter or an underscore character.
Exchanges
Exchanges are the entities to which messages are sent. They are named and have a type as well as properties such as:- passive: the exchange will not get declared but an error will be thrown if it does not exist.
- durable: the exchange will survive a broker restart.
- auto-delete: the exchange will get deleted as soon as there are no more queues bound to it. Exchanges to which queues have never been bound will never get auto deleted.
Queues
Queues are the entities that store received messages. They are named and have properties but not a type. Clients can subscribe to queues to the effect that the message broker delivers (pushes) the contents of the queue to the client. Alternatively clients can pull messages from the queue as they see fit.Messages are guaranteed to be delivered in the first-in-first-out order, unless certain kinds of rerouting operations (e.g. due to failures) occur or due to the priorities in the message.
The properties of queues are:
- alternate-exchange: when a message is rejected by a subscriber or orphaned by queue deletion, it gets routed to this exchange and is removed from the queue.
- passive: the queue will not get declared but an error will be thrown if it does not exist.
- durable: the queue will survive a broker restart.
- exclusive: there can only be one client for this specific queue.
- auto-delete: the queue will get deleted as soon as no more subscriptions are active on it. This has the same behavior as the auto-delete property for exchanges: if no subscription has been ever active on the queue it will not get auto-deleted. An exclusive queue however will always get auto-deleted when the client terminates session.
Note that queues are scheduled to replace exchanges in AMQP/1.0.
Messages
Messages are unnamed and are published to an exchange. A messsage consists of a header and a content body. While the body is opaque data the header contains a number of optional properties:- routing-key: this field is used in ways dependent on the type of the exchange.
- immediate: the message will be handled as unroutable if at least one of the queues which would receive the message has no subscription on it.
- delivery-mode: indicates that a message might need persistence. For such messages the broker makes a best effort to prevent the message loss before consumption. If there is an uncertainty on the broker's end about the successful delivery of the message (e.g. in case of errors) it might deliver the message more than once. Non-persistent delivery modes do not have this behavior.
- priority: an indicator (a number between 0 and 9) the precedence level of the message.
- expiration: the duration in milliseconds before the broker may handle the message as unroutable.
Bindings
A binding is a relationship between one queue and one exchange that specifies how messages flow from the exchange to the queue. The binding properties match the routing algorithm used in exchanges. Bindings (and exchange algorithms) can be placed on a curve of increasing complexity:- Unconditional - the binding has no properties and requests "all" messages from the exchange.
- Conditional on a fixed string - the binding has one property, the routing key and requests all messages that have an identical routing key (note that a binding's routing key is also used by some exchange types).
- Conditional on a pattern match - the binding has one property, the routing key and requests all messages that match the routing key using a pattern-matching algorithm. Arbitrary pattern syntaxes could be used. AMQP implements topic matching.
- Conditional on multiple fixed strings - the binding has a table of properties, the arguments and requests all messages whose headers match these arguments, using logical ANDs or ORs to combine matches.
- Conditional on multiple patterns - the binding has a table of properties, the arguments and requests all messages whose headers match these arguments, using a pattern matching algorithm and logical combinations.
- Conditional on algorithmic comparison - the binding has an algorithmic expression (like an SQLSQLSQL is a programming language designed for managing data in relational database management systems ....
SELECT WHERE clause) and requests all messages whose headers match that expression. - Conditional on content inspection - the binding specifies arbitrary criteria that are resolved by inspection of the actual message content.
Not all these are implemented as standard, or by all implementations.
Exchange types and the effect of bindings
These four entities form the basic model of the AMQP. The key to understand how a message is passed to a queue lies in the relationship between the type of an exchange and the resulting interpretation of message and binding routing keys.An exchange will deliver up to one copy of a message to a queue if the routing key in the message matches the routing key in a binding (multiple semantically identical bindings will not result in duplication). What constitutes a match depends on the type of exchange:
- a direct exchange matches when the routing key property of a message and the key of the binding are identical.
- a fanout exchange always matches, even on bindings without a key.
- a topic exchange matches the routing key property of a message on binding key words. Words are strings which are separated by dots. Two additional characters are also valid: the *, which matches 1 word and the #, which matches 0..N words. Example: *.stock.# matches the routing keys usd.stock and eur.stock.db but not stock.nasdaq.
- a headers exchange matches on the presence of keys as well as key–value pairs which can be concatenated with logical and/or connectives in a message header. In this case the routing key is not used for matching. Instead of routing key, header keys and/or key-value pairs are used for mathing; for keys match is done on keys that are present; for key-value pairs match is done on keys and values of the keys respectively.
Other types of exchanges, e.g. vendor-specific, are explicitly permitted in the specification.
The concept of binding named queues to named exchanges has powerful properties (with binding making those two entities independent of each other). It is, for instance, possible to bind a single queue with multiple bindings to the same or to different exchanges. Or multiple consumers can share the name of a queue and bind to it with the same parameters and will therefore get only message that the other consumers did not consume. Or multiple consumers can declare independent queues but share the bindings and get all the message every other consumer would get on the bound exchange with these bindings.
Specification revisions and the future of AMQP
The following specifications of the AMQ protocol have been published, in chronological order:- 0-8 in June 2006
- 0-9 in December 2006
- 0-10 (documents are undated)
- 0-9-1 in November 2008
- 1.0 draft in May 2010
- 1.0 final in October 2011
The 1.0 specification changes the AMQP model illustrated above by removing the concepts of exchanges and bindings, and replacing these with queues and links. This change aims to remedy two problems with the previous approach:
- The publisher needs to know too much about the receivers topology (what exchanges and exchange types are available).
- Producer flow control is challenging - if an Exchange is routing a message to 2 different queues, one empty and the other nearly full, what flow control information should be relayed to the producer and how would that be determined?
According to John O'Harahttp://lists.amqp.org/pipermail/amqp-pmc/2010-May/001319.html however, JPMorganChase and RedHat introduced links into AMQP/1.0 simply to solve an operational problem of slow consumers causing memory build up in brokers.
Other changes include the introduction of a queue addressing schema similar to E-mail
E-mail
Electronic mail, commonly known as email or e-mail, is a method of exchanging digital messages from an author to one or more recipients. Modern email operates across the Internet or other computer networks. Some early email systems required that the author and the recipient both be online at the...
and XMPP
Extensible Messaging and Presence Protocol
Extensible Messaging and Presence Protocol is an open-standard communications protocol for message-oriented middleware based on XML . The protocol was originally named Jabber, and was developed by the Jabber open-source community in 1999 for near-real-time, extensible instant messaging , presence...
. This raises addresses to first-class entities, and allows for the publication of service location record
SRV record
A Service record is a specification of data in the Domain Name System defining the location, i.e. the hostname and port number, of servers for specified services. It is defined in RFC 2782, and its type code is 33...
s using the DNS
Domain name system
The Domain Name System is a hierarchical distributed naming system for computers, services, or any resource connected to the Internet or a private network. It associates various information with domain names assigned to each of the participating entities...
.
The process of bringing the 1.0 Specification to a Standard involves a requirement elicitation phase, then the release of a "public review" spec (PR) which should be reviewed and asked for comments, optionally resulting in further modifications. When there are no substantive changes to the PR, it is voted to be the 1.0 Recommendation. At least two implementations have passed the test coverage. The Recommendation has been voted to be 1.0 Standard. , a the final spec has been produced and was accepted by the AMQP working group.
Implementations
These are the known publicly available AMQP implementations:- OpenAMQ, an open-source implementation of AMQP, written in CC (programming language)C is a general-purpose computer programming language developed between 1969 and 1973 by Dennis Ritchie at the Bell Telephone Laboratories for use with the Unix operating system....
by iMatix. Runs on Linux, AIX, Solaris, Windows, OpenVMSOpenVMSOpenVMS , previously known as VAX-11/VMS, VAX/VMS or VMS, is a computer server operating system that runs on VAX, Alpha and Itanium-based families of computers. Contrary to what its name suggests, OpenVMS is not open source software; however, the source listings are available for purchase...
. APIs in C/C++ and Java JMSJava Message ServiceThe Java Message Service API is a Java Message Oriented Middleware API for sending messages between two or more clients. JMS is a part of the Java Platform, Enterprise Edition, and is defined by a specification developed under the Java Community Process as JSR 914...
. Discontinued by iMatix after their switching to ØMQØMQØMQ is a high-performance asynchronous messaging library aimed at use in scalable distributed or concurrent applications. It provides a message queue, but unlike message-oriented middleware, a ØMQ system can run without a dedicated message broker...
. - StormMQStormMQIn computing, StormMQ is a message queuing service , using the standard Advanced Message Queuing Protocol . StormMQ is a hosted, On-Premise or Cloud solution for Machine-to-Machine Message Queuing using AMQP...
, currently the only hosted message queuing service using AMQP. It is offered as a commercial managed serviceManaged servicesManaged services is the practice of transferring day-to-day related management responsibility as a strategic method for improved effective and efficient operations inclusive of Production Support and lifecycle build/maintenance activities...
. - RabbitMQRabbitMQRabbitMQ is an open source message broker software , using the standard Advanced Message Queuing Protocol . The RabbitMQ server is written in Erlang and is built on the Open Telecom Platform framework for clustering and failover. Rabbit Technologies Ltd., acquired in April 2010 by VMware, develops...
, an independent open-sourceOpen-source softwareOpen-source software is computer software that is available in source code form: the source code and certain other rights normally reserved for copyright holders are provided under a software license that permits users to study, change, improve and at times also to distribute the software.Open...
implementation bought by VMwareVMwareVMware, Inc. is a company providing virtualization software founded in 1998 and based in Palo Alto, California, USA. The company was acquired by EMC Corporation in 2004, and operates as a separate software subsidiary ....
in 2010. The server is written in Erlang. - Apache QpidApache QpidApache Qpid is an open source messaging system which implements the Advanced Message Queuing Protocol. It provides transaction management, queuing, distribution, security, management, clustering, federation and heterogeneous multi-platform support.-See also:*Apache ActiveMQ*Message-oriented...
, a project in the Apache Foundation. Bindings to many languages without the use of DLLs. - Red Hat Enterprise MRG implements the latest version of AMQP 0-10 providing rich set of features like full management, federation, Active-Active clustering using Apache QpidApache QpidApache Qpid is an open source messaging system which implements the Advanced Message Queuing Protocol. It provides transaction management, queuing, distribution, security, management, clustering, federation and heterogeneous multi-platform support.-See also:*Apache ActiveMQ*Message-oriented...
as upstream, adds a web console and many enterprise features. Also available in the latest 3 versions of Fedora as AMQP Infrastructure. - JORAMJORAMis an open-source message broker which is certified to fully implement the Java Message Service API 1.1 . JORAM is available for since May 2000....
, a Java open-sourceOpen-source softwareOpen-source software is computer software that is available in source code form: the source code and certain other rights normally reserved for copyright holders are provided under a software license that permits users to study, change, improve and at times also to distribute the software.Open...
implementation from the OW2 Consortium.
Clients
There are many clients, including:- DE.SETF.AMQP, a Common LispCommon LispCommon Lisp, commonly abbreviated CL, is a dialect of the Lisp programming language, published in ANSI standard document ANSI INCITS 226-1994 , . From the ANSI Common Lisp standard the Common Lisp HyperSpec has been derived for use with web browsers...
client library for AMQP. - libamqp a C client for AMQP 1.0.
Comparative specifications
These are the known open specifications that cover the same or similar space as AMQP:- Stomp, a text-based pub-sub protocol developed at Codehaus; uses the JMS-like semantics of 'destination'.
- RestMS, an HTTP-based message routing and queuing protocol that provides AMQP interoperability through an optional profile.
- XMPPExtensible Messaging and Presence ProtocolExtensible Messaging and Presence Protocol is an open-standard communications protocol for message-oriented middleware based on XML . The protocol was originally named Jabber, and was developed by the Jabber open-source community in 1999 for near-real-time, extensible instant messaging , presence...
, the Extensible Messaging and Presence Protocol.
There are also vendor specific, proprietary specifications includes those by the Amazon Simple Queue Service
Amazon Simple Queue Service
Amazon Simple Queue Service is a distributed queue messaging service introduced by Amazon.com in April of 2006. It supports programmatic sending of messages via web service applications as a way to communicate over the internet...
, IBM WebSphere MQ, Microsoft Message Queuing
Microsoft Message Queuing
Microsoft Message Queuing or MSMQ is a Message Queue implementation developed by Microsoft and deployed in its Windows Server operating systems since Windows NT 4 and Windows 95. The latest Windows 7 also includes this component...
, JMS
Java Message Service
The Java Message Service API is a Java Message Oriented Middleware API for sending messages between two or more clients. JMS is a part of the Java Platform, Enterprise Edition, and is defined by a specification developed under the Java Community Process as JSR 914...
and the OpenWire as used by ActiveMQ.
There has not as yet been a formal comparison of these and other protocols in the same space, although an informal comparison of XMPP
Extensible Messaging and Presence Protocol
Extensible Messaging and Presence Protocol is an open-standard communications protocol for message-oriented middleware based on XML . The protocol was originally named Jabber, and was developed by the Jabber open-source community in 1999 for near-real-time, extensible instant messaging , presence...
and AMQP may be found here. JMS
Java Message Service
The Java Message Service API is a Java Message Oriented Middleware API for sending messages between two or more clients. JMS is a part of the Java Platform, Enterprise Edition, and is defined by a specification developed under the Java Community Process as JSR 914...
, the Java Messaging service, is often compared to AMQP. However, JMS is an API specification (part of the Java EE
Java Platform, Enterprise Edition
Java Platform, Enterprise Edition or Java EE is widely used platform for server programming in the Java programming language. The Java platform differs from the Java Standard Edition Platform in that it adds libraries which provide functionality to deploy fault-tolerant, distributed, multi-tier...
specification) that defines how message producers and consumers are implemented. JMS does not guarantee interoperability between implementations, and the JMS-compliant messaging system
Enterprise messaging system
An enterprise messaging system is a set of published Enterprise-wide standards that allows organizations to send semantically precise messages between computer systems. EMS systems promote loosely coupled architectures that allow changes in the formats of messages to have minimum impact on...
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
Extensible Messaging and Presence Protocol
Extensible Messaging and Presence Protocol is an open-standard communications protocol for message-oriented middleware based on XML . The protocol was originally named Jabber, and was developed by the Jabber open-source community in 1999 for near-real-time, extensible instant messaging , presence...
, AMQP does not have a standard API.
See also
- Message queueMessage queueIn computer science, message queues and mailboxes are software-engineering components used for interprocess communication, or for inter-thread communication within the same process. They use a queue for messaging – the passing of control or of content...
- Message queuing service
- Stomp
- XMPPExtensible Messaging and Presence ProtocolExtensible Messaging and Presence Protocol is an open-standard communications protocol for message-oriented middleware based on XML . The protocol was originally named Jabber, and was developed by the Jabber open-source community in 1999 for near-real-time, extensible instant messaging , presence...
- 0MQ
External links
- AMQP Website
- Original background whitepaper
- High-level Overview of AMQP and the AMQP Model (version 0-9-1)
- 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
- What is wrong with AMQP (and how to fix it) — iMatix secession reasons
- List of AMQP clients