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

[Gordon Sim]

On 06/05/2014 06:00 PM, Tony Garnock-Jones wrote:
> 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.

Yes, that's true. You do need to potentially tailor the exact name you 
use in each case. That is an area I think we could improve by some 
consensus between existing implementers without requiring much extra 
effort by anyone.

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

ApolloMQ has a very nice approach that is a lot like RabbitMQ policies. 
You define a configuration along with a pattern and when links are 
attached for non-existent nodes matching that pattern, the policy is 
used to create them.

The Qpid c++ broker has copied this approach. It lets you control what 
part of the 'node' namespace can be created on demand and how to do that 
creation. It also centralises the configuration making it easy to change 
and enforce (as opposed to having to have it updated in all clients).

I'd love to see other implementations adopting similar approaches. (It 
would work with STOMP as well).

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

I've found that request-response doesn't work so well with STOMP because 
of the lack of support for creating temporary reply-queues and including 
a reference of some sort to them in the reply-to.

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

I think having the ability to create a temp reply queue and a clear way 
of specifying that in the reuest message such that responses get back 
where they are expected is very helpful. AMQP 1.0 provides this.