On 23/04/14 16:12, Rafael Schloming wrote:
On Wed, Apr 23, 2014 at 10:51 AM, Chris White1 <[email protected]>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 [email protected] 'cause you'll likely
get quite a good cross-section of the Qpid community looking at it.
Best regards,
Frase
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
