AMQP's features were specified by users drawing on their collective hundreds of years of experience solving real-world problems.  The features below show what AMQP can do, and some additional capabilities we intend to add in future, compatible, minor updates.




Open Internet Protocol standard supporting unencumbered (a) use, (b) implementation, and (c) extension


Clear and unambiguous core functionality for business message routing and delivery within Internet infrastructure - so that business messaging is provided by infrastructure and not by integration experts


Low barrier (opportunity cost) to understand, use and implement




Infrastructure for a secure and trusted global transaction network

  • Consisting of business messages that are tamper proof
  • Supporting message durability independent of receivers being connected, and
  • Message delivery is resilient to technical failure

Supports business requirements to transport business transactions of any financial value


Sender and Receiver are mutually agreed upon counter parties - No possibility for injection of Spam




Well-stated message queuing and delivery semantics covering: at-most-once; at-least-once; and once-and-only-once aka 'reliable'


Well-stated message ordering semantics describing what a sender can expect (a) a receiver to observe and (b) a queue manager to observe


Well-stated reliable failure semantics so all exceptions can be managed




Any AMQP client can initiate communication with, and then communicate with, any AMQP broker over TCP/IP


Provides the core set of messaging patterns via a single manageable protocol: asynchronous directed messaging, request/reply, publish/subscribe, store and forward


Supports Hub & Spoke messaging topology within and across business boundaries


Any AMQP client can request communication with, and if supported negotiate the use of, alternate transport protocols (e.g. SCTP, UDP/Multicast), from any AMQP broker


Supports Hub-to-Hub message relay across business boundaries through enactment of explicit agreements between broker authorities


Supports Peer-to-Peer messaging across any network




Multiple stable and interoperating broker implementations each with a completely independent provenance including design, architecture, code, ownership (minimum 2, desirable 3)


Each broker implementation is conformant with the specification, for all mandatory message exchange and queuing functionality, including fidelity semantics


Implementations are independently testable and verifiable by any member of the public free of charge


Stable core (client-broker) wire protocol so that brokers do not require upgrade during 1.x feature evolution: Any 1.x client will work with any 1.y broker if y >= x


Layered architecture, so features & network transports can be independently extended by separated communities of use, enabling business integration with other systems without coordination with the AMQP Working Group


Stable extended (broker-broker) wire protocol so that brokers do not require upgrade during 1.x feature evolution: Any two brokers versions 1.x, 1.y can communicate using protocol 1.x if x<y




Binary WIRE protocol so that it can be ubiquitous, fast, embedded (XML can be layered on top), enabling management to be provided by encapsulating systems (e.g. O/S, middleware, phone)


Scalable, so that it can be a basis for high performance fault-tolerant lossless messaging infrastructure, i.e. without requiring other messaging technology


Global addressing standardizing end-to-end delivery across any network scope.


Interaction with the message delivery system is possible, sufficient to integrate with prevailing business operations that administer messaging systems using management standards.


Intermediated: supports routing and relay management, traffic flow management and quality of service management


Decentralized deployment with independent local governance


Continue to Architecture...