I seem to recall that we bind both to the unnamed exchange and amq.direct. There was a lot of debate at the time about this (well I argued about it!). I was and still am of the opinion that the unnamed exchange is pointless and confusing and introduced for a very bad reason - namely treating the protocol as an API. It was imatix that wanted this.
I do not think there will be any performance reason to use the low level API - if there is I see that as a bug so let us know! If you use the low level protocol be aware that we offer absolutely no compatibility guarantees between versions. And it will inevitably change significantly in AMQP 1-0 since exchanges disappear. As Gordon mentions below I have long argued that a stable API is critical for app development and that implies abstraction from the protocol. We inevitably need some specific extension points but that should limit the required set of changes to code as users upgrade. In that vein I look forward to seeing and commenting on the WCF impl that our colleagues at MSFT are working on. RG -----Original Message----- From: Gordon Sim <[email protected]> Sent: 02 July 2009 11:34 To: [email protected] Subject: Re: qpid + Java without JMS...? Aidan Skinner wrote: > On Thu, Jul 2, 2009 at 1:55 PM, Bryan Kearney<[email protected]> wrote: > >> The only thing I could see is that some of the exchange binding as done >> through JMS is a bit odd. I create 3 JMS "Queues" which result in on QPID >> queue being created with 2 bindings. If there was a more logical connection >> between QPID queue and JMS Queue as well as binding and message selector >> then perhaps it might be easier. > > That seems... odd. I would expect 3 JMS queues named A, B and C to > result in 3 Qpid queues called A, B and C bound to amq.direct with > routing key of A, B or C respectively. I would actually expect (or at least prefer!) those 3 JMS queues to correspond to three queues named A, B and C bound only to the default (nameless) exchange. As mentioned before that fact that queues are dynamically created when you subscribe to them but not when you publish to them is odd. I agree that the mapping of JMS to AMQP in its current form is not always the most intuitive. Trying to do something that might be natural in AMQP through JMS is also not always intuitive (and on occasion not possible). However my own recommendation would be to use JMS and point out the awkward aspects of this mapping with a view to improving things. Having a stable API is a very useful thing (as Mr Greig has pointed out more than once!). --------------------------------------------------------------------- Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:[email protected] --------------------------------------------------------------------- Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:[email protected]
