qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ken Giusti <kgiu...@redhat.com>
Subject Re: Client APIs and AMQP 1.0 (was Re: Using the messenger API to connect to a server without sending or subscribing)
Date Thu, 15 May 2014 12:44:54 GMT
Hi Gordon,

My thoughts:

For Java client API I think JMS should be our primary focus.

I'm quite fond of qpid::messaging.  I would like to see us (QPID) continue to support this
api and evolve it.  For multi-language support, I think we should leverage swig as is done
by Messenger today.  However, I'd recommend that we provide only a direct mapping of the API
into the target language rather than create a more complex swig wrapper that tries to make
this API more "native" to the language.  I wouldn't prevent this if someone would like to
step up and own such an effort, but I think the additional testing and documentation of such
a layer would require a larger investment of developer resources than a simple direct swig

I'm also a big fan of the Messenger client API.  However, I think we should develop Messenger
as an alternative client API to qpid::messaging, focusing on use cases that are not necessarily
well covered by the existing qpid::messaging API.  I think they complement each other nicely.
 My biggest fear is that Messenger tries to become The One Client API for Every Problem, and
in the process actually becomes The Bloated Mess that Everyone Hates.  I think we'd be much
better off if we can separate the problem spaces these two client APIs attempt to address,
and clearly communicate these differences so that users can find the right API for their particular
use cases (example: connection oriented vs message oriented).

We should not promote Engine (in either flavor) as a _client_ api.  It requires way too much
familiarity with AMQP 1.0 and thus it has a learning curve that is not appropriate for a client
API.  We _should_ be promoting Engine as the AMQP 1.0 toolkit for building things like client
api's (and brokers, switches, services, etc), but definitely not a client API.  I'd even go
further and recommend splitting the Engine API into its own proper library separate from Messenger.

Finally, I think we should take an active role in promoting this new experimental, community-led
APIs that you mentioned.  To be clear, I'm not advocating that we (QPID) _support_ them, but
I think we should add links to them directly from our QPID web site, along side the links
to Messenger and qpid::messaging.  Of course, the web page should make it clear that these
are non-QPID projects, and users should contact the developers directly for fixes, questions,
etc.  The important thing about these efforts is that they have the potential to become The
Next Big Thing for some subset of the AMQP user base - think of them as 'incubator projects'.
 If one or more of them really take off, we could pursue having them become proper QPID sub
projects.  In other words, there's a potential for a real benefit from these that requires
a minimum effort from us (links on our web page).



----- Original Message -----
> From: "Gordon Sim" <gsim@redhat.com>
> To: users@qpid.apache.org
> Cc: proton@qpid.apache.org
> Sent: Tuesday, May 13, 2014 9:48:15 AM
> Subject: Client APIs and AMQP 1.0 (was Re: Using the messenger API to connect to a server
without sending or
> subscribing)
> 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/
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org


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

View raw message