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/

Reply via email to