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

[Tony Garnock-Jones]

On 5 June 2014 10:25, Gordon Sim <gsim at redhat.com> wrote:

> 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.
>

Thanks. I've gone back and puzzled out some of how that might be done,
based on the spec document. But it doesn't look like many of the brokers
actually do things based on the spec's ideas of "distribution mode" and
"filter". Instead, they encode routing, filtering, and node type into
source and target *names*.

The documentation for each of (at least!) ApolloMQ [1], ActiveMQ [2], and
RabbitMQ [3] makes it clear that the semantics of AMQP 1.0 routing,
filtering, and delivery is largely based on encoding things into node
names. Each broker does this quite differently, and seemingly quite
independently of support for destination modes and filters.

This makes me think that reliably selecting, say, queueing functionality
requires intimate knowledge of the specific broker the client will be
running against, in order to choose the correct way of encoding the notion
of "queue" into the node name.

I may have missed something in the protocol spec, but on top of this, it
looks like there is no standard way to create nodes (queues/exchanges) with
application-chosen names. How do implementations deal with that?

Not being able to choose node names for shared resources in a portable way
makes it difficult both to select specific functionality (because of the
encoding of node type and filtering into node names) and to establish a
shared understanding of resource names between clients communicating via a
broker.

Based on what you've said so far, I don't think AMQP 1.0 server-agnostic
interop is there yet. It sounds more like it's en par with STOMP, actually,
which can do all of the things you list above, with the caveat that some
things are encoded into resource names, just like it seems AMQP 1.0
implementations do.

(Aside: Why isn't request-reply layered atop regular messaging? Why does it
need special support? That seems weird.)

Cheers,
  Tony

[1] http://activemq.apache.org/apollo/documentation/amqp-manual.html
[2] http://activemq.apache.org/amqp.html
[3] https://github.com/rabbitmq/rabbitmq-amqp1.0#routing-and-addressing
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20140605/713235b3/attachment.html>