[rabbitmq-discuss] Interoperability and Server Agnosticism (was Re: Pressured to move to AMQP 1.0)
gsim at redhat.com
Thu Jun 5 15:25:09 BST 2014
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 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
> 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:
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.
 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.
More information about the rabbitmq-discuss