qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Johnson, Eric" <Eric.John...@iona.com>
Subject To extend or not (was RE: QPID/HermesJMS)
Date Mon, 18 Sep 2006 21:16:17 GMT
If everything is addressed using an extended JMS front end how
complicated does the JMS API become? At what point do the abstractions
required become too extreme? If implementing some of the basic use cases
pushes the extended JMS API too far then I'd think from a developer's
POV that would not be OK.

Are there any use cases that would currently create this situation?

You may not be able to predict every conceivable case, but you can
predict a lot of them.

> -----Original Message-----
> From: Robert Greig [mailto:robert.j.greig@gmail.com]
> Sent: Monday, September 18, 2006 5:04 PM
> To: qpid-dev@incubator.apache.org
> Subject: Re: QPID/HermesJMS
> > Two more use cases
> > --------------------------------
> > I want to do a SCA/AMQP Binding for Tuscany and I would want to
> the
> > protocol artifacts using a more intutive API and not JMS or an
> JMS.
> > There is also a JMS binding and if use the same interface then were
> the
> > differentiation factor?
> The differentiation would be that there is an "extended JMS" API for
> AMQ. So that API does not duplicate existing JMS concepts but adds
> AMQP concepts to it - for example, the immediate flag.
> > I also want to use AMQP as a protocol for Axis2. Now I really
> though
> > about this, but some of the unique features that AMQP offers maybe
> useful if
> > they can be accessed using a more natural API than through JMS.
> The idea is not that you would be limited to JMS "lowest common
> denominator" functionality but that you could exploit AMQP where
> appropriate but via the extra methods and classes exposed in
> conjunction with JMS.
> Or do you actually want to work at the protocol level? If so, we need
> to understand why the JMS API is deficient.
> RG

View raw message