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++... http://activemq.org/site/features.html http://activemq.org/site/cross-language-clients.html 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 http://activemq.org/site/jms-streams.html Also within the JMS spec you can bend things to add optional extensions such as http://activemq.org/site/structured-message-properties-and-mapmessages.html http://activemq.org/site/virtual-destinations.html 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 <[EMAIL PROTECTED]> wrote:
On 18/09/06, Johnson, Eric <[EMAIL PROTECTED]> 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
-- James ------- http://radio.weblogs.com/0112098/
