Robert, comments inline and appreciate your interest.
Regards, Rajith On 9/15/06, Robert Greig <[EMAIL PROTECTED]> wrote:
> 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.
[RA] As AMQP evolves we *may* have functionality in AMQP that cannot be trivially expressed using a JMS client. So to make the full use of it we may need an AMQP API. I really don't see what harm it would cause if we have a seperate AMQP API? (other than the confusing factor which I dont' buy) Clear documentation is all we need to get rid of the confusion this might cause.
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?
[RA] Not at all. I was saying that JMS might be too simple to make use of the full power of AMQP. Or rather JMS might not expose the full power of AMQP as expected. If what people need is just JMS then it's fine, but if they need to go more deep into the protocol level how are we going to cater to them??
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.
[RA] SCA - Service Component Architecture. Bindings define how the the invocations are mapped from there native format to that expected by the SCA runtime and the target component. For example the native format might be a JMS message , AMQP message, SOAP message, JSON RPC, RMI ..etc We are trying to provide a AMQP binding for SCA (there is already a JMS binding). So we need to utilise the full power of AMQP to differentiate it from the JMS binding. So having a AMQP client API is going to make things very easy.
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.
[RA] Exactly, but why can't we have a clear seperation? Why can't we have a well defined AMQP client API and then implement JMS on top of it? Are there any technical reasons for not doing so? Can we achive a clear seperation?
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?
[RA] Robert why an extended JMS API? Why not we have our own client API which is much more natural to implement than trying to shape it upto the JMS messaging model. Why can't we write a JMS adapter on top of the AMQP API. Right now AMQP and JMS are mixed to gether and this much more confusing than having a clear seperation? Do u see any technical barriers as to why we can't have that kind of clear seperation? RG
