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