I totaly agree that JMS is "the messaging API" for Java. However the goal of AMQP is not be another JMS implementation. We have a much more ambitious goal. Don't we ???
Yes, AMQP is not just "another JMS implementation". However I don't see how other goals of the project such as wide interoperability imply that we have two Java APIs.
If somebody is interested in working with AMQP (without being bothered with JMS, now I maybe too optimistic here ) then they should be able to do it easily.
Why would anyone be "bothered" with JMS? Are you arguing that JMS is too complex? I thought the problem was that JMS is too much of a common denominator and we want to expose more advanced functionality that AMQP supports?
Besdies we are pushing for a SCA/AMQP binding. There is also a SCA/JMS binding. So where is differentiation factor if just only have a JMS client?
Can you expand on this point? I don't know much about SCA.
I don't buy the argument that users are going to get confused. This is how I would position it. AMQP is a messaging protocol, JMS is not, it's just and API. Since JMS is "the messaging API" for java we have implemented JMS using AMQP. But that doesn't mean that AMQP doesn't deserve to have a client API of it's own.
We have gone well beyond JMS in our implementation. I don't think the question is whether we should not implement any functionality not defined in the JMS specification, but how we go about exposing that functionality.
Remember, AMQP is not just java, any language can implement it, so if there is a c++ client that publish a message, we should have a java client that can fully utilise the power of AMQP without being limited to JMS simply bcos thats how we choose to expose it.
I fully agree. As I said above, we should not limit ourselves to JMS. My question for you is: what functionality do you think we cannot expose over an "extended JMS" API? RG
