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:

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:

1. 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)
2. 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.