AMQP version 1.0 provides the pieces necessary to enable messaging clients and servers to interoperate seamlessly, regardless of their technology.
It comprises an efficient wire protocol that separates the network transport from broker architectures and management. AMQP version 1.0 supports various broker architectures that may be use to receive, queue, route, and deliver messages or be used peer-to-peer.
There are three major pieces specified in the scope of AMQP 1.0. These define the networking protocol, a representation for message envelope data and the basic semantics of broker services.
Transport (TCP/IP)
- Reliable, ordered byte transmission, and network flow control
- Subdivision of TCP/IP into channels
Messaging Protocol & Type System
- Portable Representation of Message Properties
- Transport of Messages between Transport Peers
- Transfer of Responsibility for Messages between Peers
- Flow Control of Messages
Message Broker – the MOM Layer
- Intermediation, Temporal Separation of Messaging Applications
- Safe Storage of Messages
- Transactional Resources
- Local “Addresses”
- Message Distribution features; Shared Queues, Topics, etc..
- Reply Queues
API Mappings
- Canonical representation of concepts between API’s
- Send JMS <> WCF <> C <> Python …
Routing between Brokers –in a forthcoming addition
- Political Separation of Messaging Applications
- Message Forwarding
- Address Forward/Reverse Translation
- Subscription Propagation
Management –in a forthcoming addition
- Standardised management of any AMQP broker
- Send AMQP management Messages to the broker to effect changes
- Leverage all the routing and security features of Broker and Routing
The AMQP Network Protocol
The AMQP Network protocol defines:
- A peer to peer protocol; though normally in AMQP one peer is playing the role of a client application and the other peer is playing the role of s trusted message routing and delivery service, or broker
- How to connect to services, including a method for failing over connections to alternative services
- A mechanism to enable peers to discover one another’s capabilities
- Comprehensive security mechanisms, including SSL and Kerberos for seamless end-to-end confidentiality
- How to multiplex a TCP/IP connection in order that multiple conversations may happen over one TCP/IP connection. This greatly simplifies firewall management.
- How to address a source of messages with the network peer, and to specify which messages are of interest
- The lifecycle of a message through fetching, processing, and acknowledgement. AMQP makes it very clear when responsibility for a message is transferred from one peer to another thereby enhancing reliability
- How to enhance performance, if desired, by pre-fetching messages across the network ready for the client to process without delay
- A way of processing batches of messages within a transaction
- A mechanism to allow a complete message transfer from login to logout in one network packet for lightweight applications
- Very capable flow control, which enables consumers of messages to slow producers to a manageable speed, and which enable different workloads to proceed in parallel at different rates over one connection
- Mechanisms for resuming message transfers when connections are lost and re-established; for example in the event of service failover or intermittent connectivity
This low-level network protocol is comprehensive and capable, but it is normally invisible to users of messaging software. Like email, users will send messages to target@example.com and will be unaware of these details of how intermediaries process that request.
That said, it is possible for networking specialists to use this protocol for other purposes, but it is anticipated that by far the greatest use of the protocol will be to connect messaging clients to messaging brokers; the brokers hosting queues and topics and taking care of safe storage, routing and delivery.
Message Representation
AMQP provides portability between systems. It therefore needs a way to represent business data that may be required to route and deliver the message in a portable way accessible from many programming languages. The AMQP 1.0 Type System and message encoding facilities provide a portable encoding for messages to meet this need.
Normally, this encoding is only used to add routing properties to the “envelope” of the message; the contents inside the envelope are transported untouched. Applications will likely use XML, JSON or similar encodings in their message content. Optionally, and application could choose to use AMQP encoding for message content too, but this is entirely optional.
Broker Services
The value of using message brokers is that a trusted intermediary designed for the purpose handles the complexities of message queuing, routing and delivery. That intermediary is the message broker.
AMQP defines the minimum set of requirements expected of a message broker, and where there are frequently used more advanced facilities; it specifies how those facilities are to be exposed to clients.
The goal of AMQP is to enable applications to send messages via the broker services; these lower level concepts are necessary but not the goal in themselves. When you send a message via a courier, you don’t drive the delivery truck yourself!