AMQP1.0 SIG

Development of AMQP1.0 DRAFT

The development of AMQP1.0 will follow the process developed by the Process SIG and the specification will meet the requirements of the User SIG.

Initial materials are being prepared by the members of the AMQP1.0 SIG for distribution to the PMC (see below). The materials will be reviewed by the PMC and also by formal Reviewers (who have signed the [RLA|AMQP Reviewer License Agreement]). As a result of these reviews the DRAFT will be modified until the PMC agrees it has a specification fit for release as the AMQP 1.0 Committee Draft. The Committee Draft should be used as the basis of implementations.

The Committee Draft will only be promoted to AMQP 1.0 Final once two materially independent implementations have been developed and demonstrated to interoperate. It is expected that the implementers will discover Errata on the specification, which will be considered and appropriately applied to the specification. The Errata will not lead to major changes in the Committee Draft specification unless the implementers can convince the PMC of the merit of such change.

Once implementations are proven to interoperate, the PMC will consider voting on the release of AMQP 1.0 Final.

Change Controlled Materials

Subversion Repository for AMQP1.0 Work

Read in the order "illustrations", "model", "transport". All documents are "works in progress".

Name	Size	Creator	Date
amqp-model-draft91.pdf	312 kb	Rob Godfrey	Dec 03, 2008
amqp-model-draft91.odt	49 kb	Rob Godfrey	Dec 03, 2008
amqp-illustrations27.odg	43 kb	Rob Godfrey	Dec 04, 2008
amqp-illustrations27.pdf	144 kb	Rob Godfrey	Dec 04, 2008
amqp-transport.pdf	428 kb	Rob Godfrey	Dec 15, 2008
amqp-transport.odt	62 kb	Rob Godfrey	Dec 15, 2008

Notes on the Evolution of AMQP 1.0 DRAFT

The following notes are intended to help people familar with AMQP 0-8/0-9/0-10 to come up to speed with changes in 1.0 DRAFT.

Global Addressing

Even though Global Addressing is only a mandatory user requirement for AMQP 1.1 we need to know up front the addressing scheme for communicating between organisations because this has an impact on the protocol down the line.

The "obvious" address scheme adopted by email and XMPP fits the bill pretty well and has the immediate benefit of having a world pre-trained in how to use it.

So we have:

queue_name@machine.dns.name

and, importantly:

queue_name@example.com

This last one has important implications. In email it works because DNS contains "MX" (mail exchanger) records that say to your mail relay "example.com can really be found at mail.example.com". AMQP uses a standard DNS extension to achieve the same effect - the SRV (service location) record. In the example above there would be an SRV DNS record pointing to, say, amqp.example.com:5672 (yes, it includes the port number) where my AMQP client (or broker) can learn how to talk to your server. This also integrates very neatly with X509 CA checking. JOH CHECK THIS.

Elimination of Exchanges

There were issues with Exchanges:

The fact that the publisher needed to know too much about the receivers topology (what exchanges/types were available)
Producer flow control was very 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?

This has led to the conversion of Exchange into two logical components - an inbound queue + a exchange service. Clients would enqueue messages, and then the "exchange" would dequeue the message apply all the bindings to forward the message to other queue(s) in an internal broker operation. This solves some problems very well:

It decouples the transfer of responsibilities between the client and the broker from the process of forward routing.
The simplification of the process makes producer flow-control easy. One would expect the inbound queue to be kept at a small capacity, and the exchange would dequeue+forward as fast as possible. If the exchange can't forward messages quickly enough, or if one of the targets gets full (preventing the completion of the forwarding transaction), the inbound queue will fill up and cause the necessary flow control to propagate to the publisher(s).
Simplifies the wire protocol considerably - there are now only queue operations. All "exchange" operations (bindings) become management commands on "links" (new term to avoid confusion with old terms and other common networking usages of the word "binding").
Makes it possible to retrofit the AMQP transport to legacy middleware which don't have Exchanges.

Rationalisation of Bindings and Selector/Consumers/Subscriptions into Links

Requires some involved description. It's all about flow control.

Administration

There was no clear way of doing administration in the previous AMQP versions. The nearest thing was a custom extension to an Exchange. However, this has problems (not meta-circular, cannot be relayed over the MOM, different ACL scheme, not asynchronous).

The proposed mechansim uses a queue to which admin commands are send, and the results get returned to a user supplied reply-queue and correlated as expected. This queue is proposed as "amqp$admin".

There was some debate as to whether admin commands should be part of Transactions or not. A long history of RDBMS technology shows that DDL is almost never part of a transaction and presents many challenges (like rolling back the deletion of a full queue). Consequently, we have taken the RDBMS lead of keeping queue administration outside and in-flight transacation. This has led to the concept of queues and links which never take part in any current transaction - non-transacted queues and links. The amqp$admin queue is such a queue and the reply queue should be likewise adorned. Admin commands take place rapidly, but asynchronously.

Virtual Hosts Eliminated

Virtual hosting can now be emulated entirely within the scope of an implementation.

Upon Open, a peer will assert the FQDN which it thinks it is commecting to. This allows the Broker process to support multiple IP addresses and DNS names and multi-homed interfaces. The Broker can decide how to behave based on what the client asserts.

Support for DNS Service Location

As per RFC 2782 "A DNS RR for specifying the location of services (DNS SRV)"

See global addressing above.

Support for "inline" STARTTLS (removal of amqps / dedicated SSL socket)

After considerable debate, it has been decided to abandon the "amqps" idea. There will only be one amqp port, and TLS encryption will be negotiated on it like any other security (albeit with the special, but proven, incantations required to get a TLS session negotiated).

The compelling reason is that a plain AMQP port can be encrypted, even if TLS is not used - see Kerberos, which is supported by SASL. So the amqps moniker is at best inaccurate and at worst could cause alarm at a plain amqp connection.

STARTTLS if used, MUST come before SASL auth.