Re: Client APIs and AMQP 1.0 (was Re: Using the messenger API to connect to a server without sending or subscribing)
On 05/21/2014 02:10 PM, Ken Giusti wrote: I think of qpid::messaging as being a "traditional" client api. [...] Messenger, as an alternative, provides (or at least promises to provide) solutions to a lot of the issues a "traditional" API has left to the application implementation. Things like connection failover, message retries, Automatic failover and message retry *is* supported in qpid::messaging (it isn't yet in Messenger). credit scheduling, What is that exactly? Messenger::recv(N) essentially distributes N credits across however many incoming links there are, right? Whereas qpid::messaging allows capacity to be set per subscriber and maintains the window of credits accordingly. So is the key difference here that in one API the credit is controlled per-subscription whereas in the other it is controlled in aggregate. Where the number of receivers is larger than the number of messages the application is prepared to accept, dealing with the credit in aggregate and having it automatically (re)distributed as needed may indeed be useful. Of course the same feature could easily be built as a utility on top of something like qpid::messaging. routing, So by this we mean the fact that Messenger looks at the address 'to' field of the message, applies some optional rules to that, and then find or creates the link to send it over. This could of course also be built on top of qpid::messaging (or indeed JMS). and even client-side store are provided by Messenger. When you say 'are provided' you mean 'might be provided in the future'? Such features would probably feel cumbersome I don't think it is the 'features' that are cumbersome, it's the restrictions. to someone looking for a JMS-like API (and IMHO may be better off with qpid::messaging), but for those folks who may not be bound to a legacy application, Messenger offers some useful features. I've heard this sentiment in different ways quite a lot. I.e. qpid::messaging and JMS are 'legacy' approaches, are for people who aren't free to choose etc, whereas Messenger represents the future, the ideal if nothing holds you back etc. I don't go along with that view personally; I see nothing that really justifies it. It also seems to me to be quite counter to the notion that the APIs 'complement' each other, at least in my understanding of what that means[1]. I'm certainly not arguing that qpid::messaging is the ideal API either, or that there is only room for one API. I'm keen to see if we can improve the general situation and feel that some debate around the different visions that exist within the community would be helpful in enabling better collaboration on that goal. --Gordon. [1] complement, verb, /ˈkɒm.plɪ.ment/: "to make something else seem better or more attractive when combining with it" (from http://dictionary.cambridge.org)
Re: Client APIs and AMQP 1.0 (was Re: Using the messenger API to connect to a server without sending or subscribing)
Hi Gordon, - Original Message - > From: "Gordon Sim" > To: us...@qpid.apache.org > Cc: proton@qpid.apache.org > Sent: Monday, May 19, 2014 11:25:41 AM > Subject: Re: Client APIs and AMQP 1.0 (was Re: Using the messenger API to > connect to a server without sending or > subscribing) > > On 05/15/2014 01:44 PM, Ken Giusti wrote: > > 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. > > In what way do you think they complement each other? > I think you've touched on it below - they do differ primarily in style. But I think it goes beyond that. I think of qpid::messaging as being a "traditional" client api. It fits best in those scenarios where the application directly manages the connections (setup and fail-over), message sending/receiving, and credit. I suspect there's a lot of existing messaging systems that expect that kind of API, and will find qpid::messaging a better fit than Messenger. Messenger, as an alternative, provides (or at least promises to provide) solutions to a lot of the issues a "traditional" API has left to the application implementation. Things like connection failover, message retries, credit scheduling, routing, and even client-side store are provided by Messenger. Such features would probably feel cumbersome to someone looking for a JMS-like API (and IMHO may be better off with qpid::messaging), but for those folks who may not be bound to a legacy application, Messenger offers some useful features. > [...] > > 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 > > That sounds neat and tidy in theory. I suspect it is not so simple in > practice. > > > (example: connection oriented vs message oriented). > > I view that as more a question of 'style' than problem space. (I suspect > it also raises almost as many questions as it answers). > > The existence of alternatives is not itself inherently problematic. What > matters is how confident a prospective adopter feels when evaluating > options for AMQP and how easily he or she would succeed if AMQP were > embraced. It's not a question of eliminating choices, its a question of > improving the experience. > > [...] > > 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. > > I'm not sure what taking 'an active role in promoting' would mean, but I > confess it makes me nervous. For one thing the projects I linked to vary > widely in license, governance and maturity. > > On reflection and re-reading, my post was rather rushed and confused and > the list of links was perhaps a mistake. > > The central point I am trying to make, is that though there are a > variety of different *individual* initiatives, selecting an AMQP 1.0 > client one can have confidence in is still not easy and it seems to me > there is no real *collective* initiative to improve this. > Sadly, I have to agree. How do we (qpid) go about solving this? > > - > To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org > For additional commands, e-mail: users-h...@qpid.apache.org > > -- -K
Re: Client APIs and AMQP 1.0 (was Re: Using the messenger API to connect to a server without sending or subscribing)
On 05/15/2014 01:44 PM, Ken Giusti wrote: 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. In what way do you think they complement each other? [...] 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 That sounds neat and tidy in theory. I suspect it is not so simple in practice. (example: connection oriented vs message oriented). I view that as more a question of 'style' than problem space. (I suspect it also raises almost as many questions as it answers). The existence of alternatives is not itself inherently problematic. What matters is how confident a prospective adopter feels when evaluating options for AMQP and how easily he or she would succeed if AMQP were embraced. It's not a question of eliminating choices, its a question of improving the experience. [...] 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. I'm not sure what taking 'an active role in promoting' would mean, but I confess it makes me nervous. For one thing the projects I linked to vary widely in license, governance and maturity. On reflection and re-reading, my post was rather rushed and confused and the list of links was perhaps a mistake. The central point I am trying to make, is that though there are a variety of different *individual* initiatives, selecting an AMQP 1.0 client one can have confidence in is still not easy and it seems to me there is no real *collective* initiative to improve this.
Re: Client APIs and AMQP 1.0 (was Re: Using the messenger API to connect to a server without sending or subscribing)
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" > 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 acce
