qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gordon Sim <g...@redhat.com>
Subject Client APIs and AMQP 1.0 (was Re: Using the messenger API to connect to a server without sending or subscribing)
Date Tue, 13 May 2014 13:48:15 GMT
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://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/

To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org

View raw message