On 23/04/14 16:12, Rafael Schloming wrote:
On Wed, Apr 23, 2014 at 10:51 AM, Chris White1 <chris.wh...@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 us...@qpid.apache.org 'cause you'll likely get quite a good cross-section of the Qpid community looking at it.

Best regards,
Frase





Reply via email to