AMQP 1-0 Business Requirements
This page outlines the definitive, finalised Business Requirements for AMQP 1-0, as developed by the User SIG in Q2 2008.
Business messaging requirements:
| Release | Rank | Requirement |
|---|---|---|
| Safety | ||
| 1.0 | |
Secure and trusted global transaction network
|
| 1.0 | Supports business requirements to transport business transactions of any financial value | |
| 1.1 | Sender and Receiver are mutually agreed upon counter parties - No possibility for injection of Spam | |
| Fidelity | ||
| 1.0 | Well-stated reliable delivery semantics covering at-most-once, at-least-once, and once-and-only-once | |
| 1.0 | Well-stated reliable message ordering semantics | |
| 1.0 | Well-stated reliable failure semantics so all exception can be managed | |
| Unified | ||
| 1.0 | Communicates universally over TCP | |
| 1.1 | Negotiate communication over alternate transport protocols (e.g., SCTP, UDP/Multicast, SCMP, etc.) | |
| 1.0 | Provides the core set of message exchange patterns - asynchronous messaging, request/reply, pub/sub | |
| 1.0 | Supports Hub & Spoke messaging topology within and across business boundaries |
|
| 1.1 | Supports Hub to Hub message relay across business boundaries through enactment of explicit agreements between broker authorities |
|
| Interoperable |
||
| 1.0 | Multiple stable implementations from independent providers (minimum 2, desirable 3) |
|
| 1.0 | Globally conformant for the core message exchange and queuing functionality | |
| 1.0 | Implementations independently testable and verifiable | |
| 1.0 | Stable client-broker wire protocol ensuring forward compatibility during client feature evolution |
|
| 1.1 | Stable broker-broker wire protocol ensuring forward compatibility during all feature evolution | |
| 1.0 | Features & network transports extendable by independent communities of use | |
| Scalable and Managed |
||
| 1.0 | Binary WIRE protocol so that it can be ubiquitous, fast, embedded (XML can be layered on top) | |
| 1.0 | High performance fault-tolerant lossless messaging infrastructure |
|
| 1.x | Supports enactment of entitlements at all levels of interaction with the message delivery system | |
| 1.x | Supports traffic flow management, quality of service | |
| 1.x | Decentralized deployment with independent local governance | |
| 1.1 | Global addressing standardizing end to end delivery across any network scope |
|
| Ubiquitous & Pervasive | ||
| 1.0 | Open standard supporting unencumbered use, implementation and extension | |
| 1.0 | Clear and unambiguous core functionality for business message delivery | |
| 1.0 | Fits into existing enterprise messaging applications environments (e.g., Tibco, MQ, JMS) |
Feature Requirements of AMQP 1.0 Protocol:
The User SIG met on May 22, 2008
- We observed that the most compelling use for an open messaging protocol like AMQP is to communicate across political boundaries; either between companies or between divisions within companies.
- The expectation that AMQP 1.0 be a long lived, stable forward compatible wire protocol.
- We considered the evolution of the core functionality of AMQP (the Roadmap) in two phases (A & B) with the requirement that they do not break the wire protocol.
Phase A - Use Case
Hub model only w/ two deployment scenarios:
- Corporate to Bank, bank runs AMQP broker in DMZ connecting Corporate and Bank AMQP Clients using TCP/IP. It replaces FTP and MQ over SSH
- Client to Broker sessions
- Must support secure communications (authentication, confidential & tamper proof)
- Must support reconnection upon connection failure with no loss of message data
- Must support session recovery upon Client process failure
- Broker may be deployed in reliable, fault-tolerate cluster configuration
- Publisher to Consumer message order semantics (Not Discussed)
- Message delivery failure (Not Discussed)
- 0-9 SP1 vs 0-10 SP1 Routing, Queuing, and Class semantics (Not Discussed)
- Client to Broker sessions
- Intra-Corporate message bus, corporation runs AMQP broker as internal message hub
- (Same as Use Case #1 - just internal deployment)
Take away Functional Requirements:
- A-01: Must have TCP/IP Transport Protocol support
- A-02: Must have TSL level connection security support
- A-03: Must support 0-10 Session semantics for TCP/IP
- A-04: Broker may support reliable, fault-tolerate cluster configurations
Phase B - Use Case
Decentralized, Locally Governed Federated Mesh of AMQP Brokers with standardized Global AddressingThe killer application for AMQP is transacted secure business messages between corporations - e.g. send a banking confirmation message to confirms@bank.com, where the protocol is AMQP (this is not email, but feels familiar). The killer application requires both stable federations between different AMQP brokers with message transfer between brokers based on a global addressing scheme.
In Phase B support Broker federation must exist and must not break the Client-Broker Protocol and Broker-Broker protocol must be solid with standardized global addressing.
The group was excited by the prospect of reaching this goal.
Phased evolution of interoperability
The next stage was to discuss what needed to be delivered when. It was agreed that AMQP 1.0 has to make very strong commitments to the stability to the client-to-broker protocol. This, and the other requirements are listed under Phase A below. This list is quite demanding, but the group honestly felt that this is what AMQP 1.0 needs to deliver to be useful to business.
Phase B represents future backwards compatible extensions from the initial 1.0 release - we made no statements on numbering, other than that we believed as a group that business will expect the major version number to stay at 1 for several years.
Phase A
- Client-Broker core semantics finalized (Hardened) - secure, transactional, durable and fault tolerant
- Session-Session connection interoperability support for TCP/IP only
- Discovery semantics for other session support connection transport protocols finalized though optionally supported
- Address the protocol aspects of 'extension commands' (e.g., for JMS selectors)
- Scoped JMS support (TBD - but NO expectation of a standardized AMQP representation for selectors)
- AMQP vendors may implement expanded JMS support as a non-conflicting custom implementation based on the standard extension mechanism (e.g., for selectors)
Phase B
- Broker-Broker Protocol introduced to support efficient and safe messaging between appropriately administered federations of politically independent entities.
- AMQP interpretation of conformant support for JMS finalized (TCK accreditation Not Discussed)
- Global Addressing finalized
Notes:
- The whole point around Phase A is the hardening wire protocol contract in support of evolving functionality.
- It doesn't matter what broker implementation is on the other side on session, it will interoperate (on TCP/IP initially).
- We will be able to communicate globally in any network topology. So long as the network has been appropriately administered.
- e.g., The action of an explicit peer-to-peer legal contract.
- The network is explicitly constructed; I only get messages I want to get; you only get messages I want you to get.
- We're opening a channel for a business conversation.
- There is no SPAM on AMQP. SPAM kills AMQP's business case.