qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "James Strachan" <james.strac...@gmail.com>
Subject Re: To extend or not (was RE: QPID/HermesJMS)
Date Tue, 19 Sep 2006 07:06:13 GMT
Its maybe worth making a list of all the things which folks feel AMQP
could do one day which might not fit into the JMS API. Then folks can
ponder on whether or not a new API is required & what actually are the
real use cases when one might wish to avoid the JMS spec

On the ActiveMQ project we've extended the JMS spec in many ways
together with writing JMS-like APIs in C# and C++...

and so far found that so far we've been able to stick within the JMS
API apart from a few simple extensions here and there such as

Also within the JMS spec you can bend things to add optional extensions such as

So I'd recommend you figure out what are the use cases are first
before making decisions on what APIs to build. You might also be
surprised how much you can bend the JMS API to do what you need ;)

On 9/18/06, Robert Greig <robert.j.greig@gmail.com> wrote:
> On 18/09/06, Johnson, Eric <Eric.Johnson@iona.com> wrote:
> > 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.
> Yes this is perhaps the key point. Unless what is being proposed is
> what I read into Gordon's comments (I don't want to put words in your
> mouth so let me know if I'm misrerepresenting you Gordon) which is a
> strictly protocol-level API.
> So far I think the "extended JMS" is quite simple although I am
> perhaps slightly biased :-)
> RG



View raw message