What’s up with AMQP 1.0?


In August 2011 the AMQP Working Group passed the reins to the newly formed OASIS AMQP Member Section. After being developed in a very pragmatic manner by a consortium of “financial service institutions, infrastructure providers, and integration, transaction and networking specialists” (sic), the AMQP protocol became a internationally recognized standard.

A few months later, the final version of the AMQP 1.0 protocol was published. Though it may seem like a tiny increment from the previous version (0-9-1), the latest version of the protocol actually went through some major changes. So let’s go for a quick rundown of these changes.

For those who aren’t familiar AMQP is a a wire-level protocol for exchanging information. It is an open protocol that makes it possible to exchange data between different languages including PHP, .net, Java, Python and JavaScript.

According to the AMQP website, the version 1.0 of the protocol offers:

  • efficient wire protocol,
  • support multiple brokers,
  • message security,
  • global addressing,
  • extensible layering,
  • supports multiple middleware standards.

All this sounds pretty nifty but how does it impact you as an end user experienced with pre-1.0 AMQP? Read on to find more.

Messaging Only

The first and foremost difference is that AMQP 1.0 focuses on the messaging layer only. All attempts to define a broker model have been removed. Focus is a good thing but one can consider that somewhat the protocol has lost some of its teeth. On the other hand, by removing any broker related concerns, the door is now open to any kind of implementation, whatever the semantics of their message routing and handling. Messaging interoperability with strong support for transactions and security is now achievable.

AMQP 1.0 is therefore a messaging protocol. All notions of broker management, like configuring message routes, will now be specific to the particular AMQP broker that will be used.

In that matter, the most prominent loss is the notion of exchange, and with it the notions of exchange types (direct, fanout, topic…).

Exchanges begone

Unlike, JMS where publishers need to know if they deal with a queue or a topic, pre-1.0 AMQP was relying on exchanges, a neutral destination that could, behind the scene, have been consumed by a single queue or many of them, with simple or complex routing policies.

In practice the problem was the following: exchanges, like queues, can be configured to auto-delete themselves when all consumers and produces have disappeared. This could have led to errors for producers in the case the targeted exchange was gone. Because the exchange creation is an idempotent operation, it became a common practice for publishers to create exchanges the same way consumers did. For this they needed to know a lot about the actual nature of the exchange, the way it routed messages, etc… a knowledge that should have been limited to the receiving end was now invading the producing end.

So exchanges have been removed from AMQP 1.0. Instead producers and consumers (which are now called “links”) now interact respectively with targets and sources. These are abstract concepts that encapsulate an address and extra properties.

Addressing schema

The meaning of sources’ and targets’ addresses are left to the interpretation of each AMQP implementation. It is even conceivable to have AMQP brokers actually ignoring the address altogether.

With the introduction of addresses, the notion of routing key has been removed. Instead an opaque “subject” header has been added, header whose interpretation also varies for each broker.

To illustrate this, let’s look at how RabbitMQ interprets “address” and “subject” in order to bind it to its actual broker implementation that directly comes from AMQP 0-9-1, and this from a publisher standpoint:

TargetSubjectAMQP 0-9-1 equivalent
/exchange/XRKPublish to exchange X with routing key RK
/queueQPublish to default exchange with routing key Q
/queue/QignoredPublish to default exchange with routing key Q

From a consumer standpoint, “subject” is ignored altogether:

SourceAMQP 0-9-1 equivalent
/queue/QConsume from queue Q
/exchange/XDeclare a private queue, bind it to exchange X, and consume from it.

Using one the RabbitMQ administration tools, like the web console or the CLI, is now required to configure the necessary exchanges and queues prior to using them.

So how are all these changes affecting your favorite integration broker?

The Mule transport for AMQP currently supports version 0-9-1 of the protocol. This allows the transport to be used with several existing AMQP servers, like the very popular RabbitMQ and Apache Qpid. We think that AMQP is being called to play a major role in the future, thus we will work to support version 1.0 of the protocol in the near future so that Mule can be used with AMQP to take web messaging to the next level.

What’s your take on this? Were you waiting for AMQP to reach 1.0 before considering it?

And more generally: do you think messaging on the web will play a major role in the future (think streaming APIs, server-push instead of client pull, event-driven architecture, is AMQP too late)?

Please share your insights in the comment section.

Follow: @rossmason@mulesoft