I think that a JMS API implemented on top of a native AMQP API would make for a clean separation. If I wanted to develop a JMS application, I could do so using just the plain JMS API. If I wanted/need the AMQP specific functionality I could use that API. Would that also provide for the case where I've inherited a JMS app and need to add some of the AMQP functionality? Would it be possible to access the underlying AMQP objects from the JMS objects?
> -----Original Message----- > From: Rajith Attapattu [mailto:[EMAIL PROTECTED] > Sent: Friday, September 15, 2006 2:51 PM > To: [email protected] > Subject: Re: QPID/HermesJMS > > 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 > >
