On 18/01/2008, Arnaud Simon <[EMAIL PROTECTED]> wrote:
>
> >
> > Perhaps I misunderstand what you are saying, providing multiple
> > addressing via JNDI will not cause any vendor lock in except in the
> > format and functionality that is specified in the BindingURL (Again
> > this should be an AMQP specified format, which would remove that
> > problem) There would be zero requirement for non pure JMS code in the
> > client library as they would simply do:
> >
> > Destination specialDestination =
> > (Destination)jndiContext.lookup("SpecialAMQPDestination");
> >
> > That is pure JMS + JNDI no AMQP lock-in.
>
> That is pure JMS code with not standard JMS semantics. If your
> application uses this special destination for sending messages to
> several queues you'll then need to re-write it when migrating to another
> JMS provider. What you are doing is introducing a vendor lockin as your
> application will not behave as expected with a "standard" JMS
> implementations. So, what I am saying is that such JMS extensions should
> maybe not be hidden into config files.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. Any vendor that implements the JMS-over-AMQP specification can be used. This is what we are striving for. If we don't hide the binding configuration and require the use of non standard JMS interfaces we then require a set of org.amqp.jms interfaces which IMO isn't going to happen. 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. -- Martin Ritchie
