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 mapping.

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).

thanks,

-K




----- Original Message -----
> From: "Gordon Sim" <g...@redhat.com>
> To: us...@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-unsubscr...@qpid.apache.org
> For additional commands, e-mail: users-h...@qpid.apache.org
> 
> 

-- 
-K

Reply via email to