My view... In any sane development environment people who code in Java are going to want to code against JMS. That is THE standard for Java Messaging. What we want to be able to do is allow these people to progress to use features that are in AMQP but cannot be exposed purely through a JMS implementation. This implies to me that either you extend the JMS interfaces or you have your concrete implementation classes implement both the JMS interface and a non-overlapping set of extensions.
There is a case for having a lower level API which maps as closely as possible onto the AMQP classes and methods. There are two reasons for this. This API would be what the JMS laye uses under the covers. It will also be the API that hardcore AMQP fanatics :-) use ... >From and AMQP standards point of view I think that both this low level API and the extensions to JMS should be standardised to allow people to swap between AMQP clients (after all you may use Qpid for a while, and then discover that Rabbit have coded a client library that is 30% faster or added some very cool proprietary extension that you can only use via their API... in which case you shouldn't need to rewrite all the stuff that is vanilla AMQP). I do not particularly see the need for an API which is neither JMS that doesn't look exactly like the model layers of AMQP [that is the API need not expose all the 0-10 features for connection establishment, session maintenance etc... those are functions of the client library and shouldn't be exposed to the application programmer - For those familiar with AMQP 0-10 I think the API should provide hooks into all of Layer 4... with abstractions for the lower layers]. There is a genuine debate to be had about the technical design of the lower level API and the uses of interfaces vs. classes etc... My personal view on this is that we let the guys finish what they are working on now, and then review what it looks like when complete. -- Rob On 22/08/07, Martin Ritchie <[EMAIL PROTECTED]> wrote: > > On 22/08/07, Michael Arnoldus <[EMAIL PROTECTED]> wrote: > > Den 22/08/2007 kl. 19.08 skrev Martin Ritchie: > > > > > On 22/08/07, Rajith Attapattu <[EMAIL PROTECTED]> wrote: > > >>> > > >>> But not one that allows access to AMQP functionality. I don't see > > >>> why > > >>> the AMQP WG couldn't provide a set of Interfaces and a client lib > > >>> could then implement jmx.Session and amqp.Session. Then again I've > > >>> never had any exposure to CORBA to know what they did wrong. Is the > > >>> lesson simply never to provide an API? That seems a bit harsh. > > >>> > > >> > > >> Two reasons. > > >> Defining an API is time consuming and difficult given the no of > > >> languages we > > >> have. > > >> Also they differ from object oriented to procedural to functional. > > >> So obviously there will be different views on how best it should > > >> be done in > > >> a given language. > > >> I heard of client implementations in the following languages so far. > > >> java, c++, python, ruby, erlang? , javascript - and most like C > > >> and perl. > > > [not forgetting our own .NET :)] > > > > > > > > > > > >> The second reason is more political. > > >> I think it is a very difficult exercise to get agreement over the > > >> API from > > >> different vendors. > > >> Everybody will think their API is the best - atleast thats what > > >> happend with > > >> CORBA. > > >> http://portal.acm.org/citation.cfm? > > >> id=1142044&coll=GUIDE&dl=GUIDE&CFID=24831971&CFTOKEN=13722890&ret=1#F > > >> ulltext > > > > > > Isn't that why you need a standards body to lay down the > > > specification? Remove the vendors from the solution and allow the WG > > > to present the API much like Sun have done, IIRC. Vendors had > > > implemented JMS as it was being standardized and found it lacking so > > > the spec had to be updated. > > > > > > AMQP only defines the wire level protocol I'm not sure that will be > > > enough for global domination and the breaking down of the vendor > > > lock-in. I could of course imagine a world where vendors simply supply > > > brokers and everyone uses a qpid or other open source client library. > > > Some risk averse institutions may still not like the idea of using > > > OSS. They could be forced to use a vendor client that may have a > > > licence that prevents them easily changing brokers. > > > > > > I can understand the language issues with creating a _single_ client > > > API but still think you could do versions per language that are more > > > natural to each of the language styles. This is probably more of an > > > issue for languages that already have a large install base of > > > messaging products with an existing pervasive API. I'm thinking mainly > > > of Java/C++/.NET not sure how many messaging systems that currently > > > have an erlang or javascript client library. I'd also be thinking > > > about the openness of any of those APIs, i.e. IBMs XMS maybe widely > > > used in C++ but that doesn't mean I'd advocate creating a standardized > > > AMQP extension to it. I think Java and .NET are quite unique with > > > their messaging APIs given they are hardware agnostic their creators > > > have defined a messaging specification that in turn allows vendors to > > > create their own implementations. > > > > > > Perhaps this is a non-issue in the real world, but if current > > > messaging vendors are worried about AMQP then this could be the way > > > the maintain their hold of clients. > > > > > > just a thought. > > > -- > > > Martin Ritchie > > > > From my point of view it's very cool to stop the standards at the > > wire level protocol. That means several java API's can coexist, and > > people can use several brokers. Freedom increases. If two gropus > > within QPId can't agree it's actually possible to make two different > > java API's - or I can use the RabbitMQ java client against the QPid > > broker. This is perfect! > > I would like the ability to write my java app using AMQP with Qpid > then simply swap to use the RabbitMQ java client. If I can't do this > then I am locked in to the Qpid code base. Sure I can change broker > and the AMQP Spec ensures that it will work but I'm stuck with the > Qpid client unless I re-write. > > Is it just me that thinks this is an issue? In the real world does it > not matter? > > Anyway time to go home for me. > > > Regards, > > > > Michael Arnoldus > > > > > > > > > -- > Martin Ritchie >
