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 Mon, 18 Sep 2006 19:38:58 GMT

Alan has a very good point or two or three.
Perhaps this is a juncture where laying out a clear set of use cases for
the API layer is appropriate. From this a more grounded technical
discussion of the best approach can be had.
Can the JMS APIs be extended to effectively cover the use cases?
Would extending the JMS API result in unacceptable inefficiency during
execution, unacceptable complexity in the API, or an
unacceptable/unworkable level of abstraction between API and function?
Do developers need/want a new messaging API? Can they be convinced to
use it?

>From a documentation stand point both approaches can be handled. An
extended JMS API makes for less pages, but if the API gets to convoluted
it makes for a mess. The separate Qpid API means more pages but a
cleaner separation. 

> -----Original Message-----
> From: Alan Conway [mailto:aconway@redhat.com]
> Sent: Monday, September 18, 2006 11:21 AM
> To: qpid-dev@incubator.apache.org
> Subject: Re: QPID/HermesJMS
> 
> It seems to me that regardless what happens there *will* be a JMS API
> and there *will* be a Qpid API. The JMS layer has to call on
something!
> 
> The question is whether there is real value in documenting  multiple
> ways for users to do the same thing in Qpid. I don't know the answer,
> but I'd like to see some concrete examples of where people feel the
JMS
> API is inadequate, inefficient or just repulsive, and how we could do
> such a better job in Qpid that people would find it worth their while
to
> learn a new API and write code they'll never be able to port to
another
> JMS implementation. I'm  not saying it can't be the case! I'm just
> curious about the innovations people have in mind for Qpid's API.
> 
> Cheers,
> Alan.
> 
> On Mon, 2006-09-18 at 11:06 +0100, Gordon Sim wrote:
> > Steven Shaw wrote:
> > > On 15/09/06, Robert Greig <robert.j.greig@gmail.com> wrote:
> > >> I think we agree that we need to expose functionality that goes
> beyond
> > >> JMS. The question is whether we can do this though extension
points
> to
> > >> JMS or whether we need a separate API.
> > >
> > > Perhaps both.
> >
> > I agree with this view.  The different ways of exposing
functionality
> > need not be mutually exclusive.
> >
> > Support at the 'protocol' level makes it easier for the full
flexibility
> > of AMQP to be exploited in perhaps unanticipated ways.
> >
> > As an example, pulled out the air, imagine a particular use case
wants
> > to set up a single queue with several bindings. Rather that trying
to
> > anticipate all these sorts of usage patterns from the start a more
> > directly exposed protocol layer would make these easy to compose
from
> > the protocols own building blocks.
> >
> > However JMS is clearly the first choice for the vast majority of
> > messaging based systems written in java, so allowing these system to
> > exploit the protocol through API extensions or configurable
semantics or
> > mappings is also going to be important.



Mime
View raw message