[rabbitmq-discuss] Interoperability and Server Agnosticism (was Re: Pressured to move to AMQP 1.0)

[Gordon Sim]

On 06/05/2014 02:27 PM, Tony Garnock-Jones wrote:
> What is the level of server-agnosticism that people are actually seeing
> with AMQP 1.0?

A reasonable degree, though I would certainly love to see some consensus 
from implementers on extending that.

Specifically you can get reliable (i.e. acknowledged) or unreliable 
(unacknowledged) transfer to and from queues, you can get pub-sub, you 
can get request-reply with several different brokers[1] all based on the 
core protocol as published.

I would argue that's probably more than you get with either STOMP or 
MQTT on their own.

In addition several brokers support some extensions and conventions that 
essentially allow full JMS functionality against different brokers over 
AMQP 1.0.

> It's clear that people can get the AMQP 1.0 transport and data encoding
> languages to interoperate. They might even get some links established.
>
> Is it possible to get server implementation agnosticism while
> programming at the AMQP 1.0 equivalent of the conceptual level of
> exchanges, queues, and bindings?
>
> I read the OASIS spec yesterday, at long last, and it doesn't seem to
> cover anything at that level, and the various extension registries at
> amqp.org <http://amqp.org> are all empty.

There have been some filters registered for some time now:

   http://www.amqp.org/specification/1.0/filters

These are relied on for full JMS behaviour and also include some support 
for the old exchange types.

> Perhaps there's a de-facto standard for AMQP 1.0 broker behaviour?

There is work ongoing I believe to standardise the JMS mapping, 
including any extensions it requires, which will provide some of this.

--Gordon

[1] Both Qpid brokers, Qpid dispatch router, ActiveMQ, ApolloMQ, 
HornetQ, SwiftMQ and apart from the request-response, RabbitMQ. There is 
of course also Microsoft's ServiceBus and IBM's MQLight, but I haven't 
yet tried either of those.