qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Fraser Adams <fraser.ad...@blueyonder.co.uk>
Subject Re: Client APIs and AMQP 1.0 (was Re: Using the messenger API to connect to a server without sending or subscribing)
Date Wed, 21 May 2014 18:32:32 GMT
I've tried to stay fairly neutral on this issue, but FWIW here's my 2P

I guess that I'm fairly agnostic about there being two APIs, provided 
there doesn't wind up being a competition, and that we stop at two :-)

Cards on the table I've come from a "traditional" connection oriented 
messaging background, so I've got more familiarity with 
JMS/qpid::messaging and that's where I'd naturally tend to gravitate, 
but equally I've started to warm to Messenger lately and  quite like 
that I don't need to care about connections/sessions, it seems quite a 
natural approach when there are lots of endpoints.

I think a lot of the difference does seem down to "style" and TBH that's 
fine, it's often more natural for a particular application to gravitate 
towards one style or another, so it's good to have the choice (as a 
rubbish analogy think synchronous and asynchronous IO they both let you 
do roughly the same thing, but sometimes it's more natural to do one 
thing over another).

I do find Messenger a bit frustrating too though, probably because it's 
a less familiar API and I don't really understand the nuances and I 
really think it could do with a lot more published examples - especially 
around trying to eke out the maximum throughput.

In many places I have a feeling that qpid::messaging is more complete, 
FWIW I think that Gordon has done a great job on that and on the AMQP 
1.0 support in qpidd. A place where qpid::messaging is *way* stronger 
than Messenger (unless it has changed since I looked a month or so back) 
is in the ability to set up complex subscriptions (so fancy link options 
enabling selectors, named subscription queues etc.) when I looked 
Messenger could only cope with basic subscriptions to named nodes (or #).

The place where I'm liking Messenger at the moment though is its 
"dependency lite" nature, I guess that the vision is to be light, 
portable and embeddable and I'm surprised that nobody has brought this 
aspect up in this debate. Ultimately when all is said and done that's 
probably the single most significant "compelling feature" of Messenger 
vice qpid::messaging Messenger was ground-up intended for this use-case. 
That's not to say that qpid::messaging couldn't fit in there (or be 
modified to do so) but that wasn't (I don't believe) one of the intended 
design goals.

I guess I'm slightly disappointed that the tone of this thread seems to 
be that it's something of a competition, I personally don't think this 
it should be and that each has a valid place. I think I'd prefer the 
energy to be spent making both as good as they can be :-)


On 21/05/14 15:48, Gordon Sim wrote:
> 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)
> ---------------------------------------------------------------------
> 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