<div dir="ltr">On 5 June 2014 10:25, Gordon Sim <span dir="ltr"><<a href="mailto:gsim@redhat.com" target="_blank">gsim@redhat.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
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.<br>
</blockquote><div><br></div><div>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*.<br>
<br>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.<br>
<br>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.<br>
<br><div>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?<br><br></div><div>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.<br>
<br></div>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.<br>
</div><div><br>(Aside: Why isn't request-reply layered atop regular messaging? Why does it need special support? That seems weird.)<br></div></div><br>Cheers,<br></div><div class="gmail_extra">  Tony<br><br>[1] <a href="http://activemq.apache.org/apollo/documentation/amqp-manual.html">http://activemq.apache.org/apollo/documentation/amqp-manual.html</a><br>
[2] <a href="http://activemq.apache.org/amqp.html">http://activemq.apache.org/amqp.html</a><br>[3] <a href="https://github.com/rabbitmq/rabbitmq-amqp1.0#routing-and-addressing">https://github.com/rabbitmq/rabbitmq-amqp1.0#routing-and-addressing</a><br>
</div></div>