qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Johnson, Eric" <Eric.John...@iona.com>
Subject RE: QPID/HermesJMS
Date Fri, 15 Sep 2006 19:12:43 GMT
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:rajith77@gmail.com]
> Sent: Friday, September 15, 2006 2:51 PM
> To: qpid-dev@incubator.apache.org
> Subject: Re: QPID/HermesJMS
> 
> Robert,
> 
> comments inline  and appreciate your interest.
> 
> Regards,
> 
> Rajith
> 
> On 9/15/06, Robert Greig <robert.j.greig@gmail.com> 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
> >


Mime
View raw message