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
