qpid-proton mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Fraser Adams <fraser.ad...@blueyonder.co.uk>
Subject Re: Using the messenger API to connect to a server without sending or subscribing
Date Wed, 23 Apr 2014 16:17:52 GMT
On 23/04/14 16:12, Rafael Schloming wrote:
> On Wed, Apr 23, 2014 at 10:51 AM, Chris White1 <Chris.White@uk.ibm.com>wrote:
>
>> Hi all
>>
>> Thanks for the informative and very helpful responses.
>>
>> We did look at qpid:Messaging but this seems to be separate from the
>> qpid-proton library, and there is a concern that the is no Java API and
>> some of the function we require is missing. Our server backend is built on
>> the qpid-proton library so ideally we would like our client API to also be
>> built using qpid-proton library function.
>>
>> As an aside, why is the qpid::messaging alternative API part of qpid
>> rather than the qpid-proton package? Is there a specific reason why it
>> wasn't built on top of the qpid-proton engine?
>>
> The qpid::messaging API actually predates proton. It was originally
> implemented over the 0-10 version of the protocol. The 1.0 implementation
> does in fact use the proton engine, however the dependencies make it
> difficult to separate from the cpp broker.
>

I think that there's a good argument for making a lot of core Qpid 
behaviour a lot more modular so that qpid::messaging can be more easily 
packaged separately from the broker. I've cross-posted to the user list, 
as I said earlier the main Qpid user list has quite a wide audience.

To be fair the reason for the coupling that exists is just how things 
ended up getting developed and there is work being put in to make Qpid 
as a whole much more modular. Indeed arguably that's why Proton emerged 
as a separate sub-project, as has the dispatch router and the new AMQP 
1.0 JMS client. There's a lot more that could likely be done over time, 
one of which is likely greater decoupling of qpid::messaging.

Indeed a lot of the broker features for both the C++ and Java broker 
could potentially be fairly generically used in more general AMQP 1.0 
containers, TBH there hasn't been much discussion on that sort of thing 
yet, but I suspect refactoring could yield some reusable components.

TBH I'd say the biggest gotcha with qpid::messaging is the boost 
dependency, interaction between boost versions is a regular source of 
pain :-) a key part of Proton has been to aggressively minimise 
dependencies, which is often a big plus.

BTW Re "there is a concern that the is no Java API" there is, it's 
called JMS :-) so the idea behind qpid::messaging is that is provides a 
pretty close C++ approximation to the JMS API, so basically the Java 
equivalent of the qpid::messaging API is the Qpid JMS client, if you see 
what I mean.

You should take a look through http://qpid.apache.org/


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, but I'd definitely 
recommend posting queries to users@qpid.apache.org 'cause you'll likely 
get quite a good cross-section of the Qpid community looking at it.

Best regards,
Frase






Mime
View raw message