Two remarks:
- We must provide JMS support for portability purpose and ease of
migrating messaging applications onto AMQP. The benefit of developing
pure JMS AMQP based applications are:
- interoperability with all AMQP brokers (no vendor lock-in)
- as with standard JMS, provider can be changed if required.
- AMQP is more than JMS so we must also expose the AMQP specific
features. However, an application that uses AMQP specific features is:
- not portable across JMS vendors anymore
- locked on the used AMQP client library
>From those remarks I would say that:
- Migrating a pure JMS application on AMQP has some benefits as it
- There isn't any real benefit of using JMS support when developing a
new AMQP based application.
So, I agree with Rajith that JMS and the QPID API are not competing but
rather two different messaging approaches and that the Qpid API should
be the recommended approach to work at the AMQP level. Moreover, in an
ideal world we would eventually provide a TCK for our API of choice.
But, I would forget about defining a inter-language compatible API and
focus on Java only.
Arnaud
