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#Fulltext 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
