On Jan 18, 2008 8:48 AM, Gordon Sim <[EMAIL PROTECTED]> wrote: > Arnaud Simon wrote: > > My point was really that we need to define what an AMQP Destination is > > and its associated interface and semantics. We'll then provide a way of > > configuring it from whatever configuration mechanism (It could be JNDI > > or via provider specific properties). In that way we don't hide non-JMS > > semantics but document them and keep AMQP JMS implementations > > inter-operable. The point is really that AMQP should define what a > > Destination is. > > I think I agree with much of this, but for me a destination in AMQP is > not quite the same thing as a JMS-over-AMQP implementation of the JMS > Destination interface.
Yes, from what I understand the the concept of destination that I have seen comming up in discussions is different from a JMS-over-AMQP implementation of the JMS Destination interface. > > > I believe that (ideally! [1]) the Qpid JMS client should be constructed > in such a way that you can get a variety of AMQP 'behaviours' [2] based > on the details of the Destination object you construct your Consumer or > Producer from. We've got the simple mapping handled reasonably well now, > but I think we could get more flexibility through some refactoring of > the code. Fully agree here. If we can do that without violating the JMS spec and also using 100% pure JMS is a big win. I see a lot of uses cases where you would need to bind a queue to a direct exchange with a routing key other than the queue name. Binding a queue with several routing keys or bind your queue to a fanout exchange. We should be able to express the power of AMQP through pure JMS as much as we can. There are a lot JMS applications out there and if we only provide what they currently do, then what incentive is there for them to switch? They wouldn't care whether it is AMQP or not as long as it works. But if we can provide them with more flexibility, which they can tap without chaning code then there is a stronger incentive to consider us. > > Perhaps in the future the 'official' JMS-over-AMQP mapping will define > this (or something else) as 'required' flexibility, but in my view we > should proceed with how we (the Qpid community) believe things should be > for now. > The Qpid community can (and should) influence this mapping. We can experiment now so we know what works and what doesn't. > --Gordon > > [1] I appreciate its easy to describe my wishes at a high level, and > rather more effort to actually make them possible. I will try and find > some time to think things though in more detail. > > [2] E.g what exchanges to use, multiple bindings to a queue, whether and > when things are declared & whether the 'passive' flag is used when so > doing, whether the 'mandatory' flag is set on published messages, > whether the exclusive flag is set when issuing a subscribe etc. etc. > -- Regards, Rajith Attapattu Red Hat blog: http://rajith.2rlabs.com/
