Martin Ritchie wrote:
Jonathan,
Are you suggesting writting a new Configuration API for the Java client?
Have you thought how the configuration can still be performed via JNDI?
I have mentioned this before on the list so will be brief (well that
was the aim). I really don't see any advantage to adding new a API (of
any sort) on the java side. Allowing 100% compliant JMS code to just
work with JNDI configuration changes for Qpid is the best thing we can
do for our users. If they have spent the time to write to the JMS API
and stay away from vendor locks then we should reward them by just
working. Asking them to rewrite some of their code when moving to a
product that is based on AMQP, which is attempting to fight against
the vendor lock ins in the messaging world, sends the wrong message.
If we start having vendor specific APIs in the Java space we totally
devalue the AMQP offering IMHO. Sure it is nice to give people options
but Java users should be encoraged to stick to the JMS API, that is
until AMQP define a API which can then be adopted across all AMQP
clients. I think the work that is being done to standardise the APIs
of the other language clients is to be commended and will surely be of
a great benefit to clients writing in those languages. However, I have
yet to hear a compelling reason to have non JMS API code on the java
side, even if it is just for configuration. That said, as long as you
can do everthing via JNDI that you can do via the new API then user
migration from other JMS products will not require code changes which
in the end is how we are going to win migrating Java users. If they
have to rewrite parts of their app then what happened is the open and
compatble standard messaging story we are trying to sell?
I think the specter of vendor specific APIs is being a bit misused here.
Your traditional vendor specific API has extra functionality that locks
the client into that vendor's broker. An API that allows access to AMQP
functionality that doesn't fit well into the JMS API (e.g. the
management aspects of AMQP) really isn't a "vendor specific API" and I
don't see how it devalues/defeats the purpose of AMQP.
Also, nobody is suggesting providing a competing way to do things that
can already be done through vanilla JMS. For example, the JMS API simply
doesn't address how to manage and/or configure brokers, and so anyone
migrating existing JMS code won't have to change anything regardless of
what we provide in this area.
--Rafael
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscr...@qpid.apache.org
