On 04/28/2014 10:21 PM, Gordon Sim wrote:
On 04/23/2014 05:17 PM, Fraser Adams wrote:
BTW I wouldn't want to come across as favouring proton Messenger or
qpid::messaging over the other, as I said previously they are peer APIs
with different advantages and disadvantages,
I'd certainly agree they both have different disadvantages :-) The
picture faced by users looking for AMQP 1.0 clients is still confusing
and suboptimal.
To elaborate a little more, here is my summary of the current AMQP 1.0
client choices. I think this is a topic that would benefit from some
(more) discussion and debate.
If you are using java the most obvious option is JMS, the one well
established API in messaging! It will be even better when the new
implementation with JMS 2 support comes along, bring simplification as
well as new features such as proper asynchronous publishing. Any
confusion here is really transitory.
If JMS doesn't fit for whatever reason, chances are the next option
considered will be proton, messenger or engine, available in different
languages: proton-j, proton-c and swigged versions of proton-c. An
increasing number of different things use proton to provide AMQP 1.0
support in one way or another.
I do think the inclusion of the two APIs in the same library continues
to be a source of confusion. Whatever the original or ultimate vision
is, they are at present quite different things. I also feel that by
being coupled together, both are held back a little from pursuing their
own distinctive goals.
The engine has been used relatively successfully in qpid::messaging,
qpidd and dispatch router already. The java variant has been used by
ActiveMQ and HornetQ and by the ongoing JMS work. It's reasonably
complete in terms of providing access to most aspects of the protocol,
though perhaps there are more additions/simplifications to the API (such
as the recent addition of events). It's pretty flexible but requires
more work than the user of a typical messaging library might expect.
Messenger is a message-oriented API where the library takes care of
connection and link management. The message-oriented nature hides the
differences between accepting incoming connections and making outgoing
connections, in theory allowing applications to support either direct
connections or intermediated/ brokered connections without any code
changes. It also - in theory - makes handling connection failure simpler
and takes it out of the hands of the application entirely. At present
this isn't true of course. There is no reconnect functionality built in
yet, nor does the API allow the application to reliably detect and
handle disconnection itself. Personally though, while I'm intrigued by
the notion of a message-oriented API, I'm not yet convinced by this
incarnation and the 'simple but powerful' billing.
Then there is qpid::messaging, the API that was designed specifically
with the transition to AMQP 1.0 in mind. Though there are still some
gaps - lack of transactions for example - its getting reasonably solid
now. The main drawback with the API is around non-blocking use. That
could be addressed if there was sufficient interest (I did some
prototyping a long time ago[1]). Integration into an existing event loop
isn't possible at present either.
The address syntax has also been a bit of a failure. For 1.0 I think it
is much simpler, without the need for the various x-bindings etc, but
could still be made simpler and clearer. There is also the
Qpid.Messaging .NET wrapper for qpid::messaging and some swigged
qpid::messaging clients. The pure python version doesn't support 1.0 and
there has been some further divergence of the c++ implementation from
this. The lack of appealing (to me) python support is a bee in my bonnet
at present.
There are also some new developments and/or experiments in various stages:
Chuck has built initial AMQP 1.0 support for NMS, the .NET API in the
ActiveMQ project. Andrew Stitcher has been working on something similar
for CMS (the c++ equivalent). It will be interesting to see if there is
any demand for these.
Fraser has been working on a javascript cross-compilation of proton
messenger. Also on the subject of javascript:
https://github.com/pofallon/node-qpid and the recently announced mqlight
node client: https://www.ibmdw.net/messaging/mq-light/node-js-api/. Both
of these use proton in some way. I haven't yet had a chance to dig into
any of these in earnest
Darryl has been exploring an eventful ruby API built on proton:
https://github.com/mcpierce/eventful-qpid-proton, again I've not yet had
a chance to look at this.
On the python side and interesting development is pyngus
(https://github.com/kgiusti/pyngus,
https://pypi.python.org/pypi/pyngus), developed by Ken. This is a
callback based python wrapper around the proton engine. I used this when
doing some work with Ken around AMQP 1.0 support in OpenStack's
messaging library and found it nice to work with. I think there is more
that could be done here as well. As I mentioned above, I don't really
like any of the alternatives for python at this point, and to me that is
a big gap.
This is already longer than intended and I've only summarised what's
there! Any other choices I've missed? Anyone else have opinions on the
existing options and/or directions for new development? If you were to
advise someone using language X on which API to pick, what would say? If
you are using one or more of these APIs, what is your opinion of them?
[1] https://reviews.apache.org/r/1687/
