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!
Regards,
Michael Arnoldus
