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
