On Fri, 2008-01-18 at 12:12 +0000, Martin Ritchie wrote: > I disagree it is (or should be) standard JMS-over-AMQP hence you could > swap for a RabbitMQ or OpenAMQ broker and things work just fine. > > What you are doing is creating AMQP Lock-in which is totally different > to vendor lock-in.
I agree with this statement but only based on this: > Having a specification document that defines JNDI-BindingURLs, > ReplyTo and broker side JMS semantics to me is the correct approach to > take. This leave the vendor free to implement the client and broker as > they wish but as long as they support the specified JMS functionality > then you can mix and match JMS Clients and Brokers. 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. Arnaud
