On 09/25/2010 09:52 AM, Robin Palotai wrote:
From what I can see this far, qpid::client is a low-level API directly
using AMQP style, while qpid::messaging is a higher level API which
tries to hide AMQP. Some of the differences I found (maybe not right,
but don't have any better):
- messaging uses terms "queue" and "topic", where "topic" is not a topic
exchange, but these are used as in Java JMS
- messaging therefore has to translate there terms to AMQP terms, which
could be fine-tuned using address strings, but these are not too
documented as I can see
- messaging has a nicer receiver API, and has non-blocking
Receiver.fetch() for retrieving messages. Maybe it uses a separate
thread, but that is not apparent from the docs. Also, when I try to
support it with a timeout, it never returns.
- client is more straight-forward, you can use the well-known AMQP style
methods to declare exchanges, queues, bindings.
- with client, I'm not sure if non-blocking message polling is possible,
maybe you need a custom thread for that.
(above refers to C++ API)
QPID seems to be in active development, maybe that is why documentation
seems to be lagging behind what actually is available. Possibly using
the client API is on the safer side right now.
Yes, Qpid is certainly in active development, and to date users have
only had the client API.
The creation of the messaging API was undertaken for a few reasons which
might be useful to enumerate here.
Though some aspects of the older, AMQP 0-10 specific APIs were
straight-forward, the details depended on a fairly complete knowledge of
the protocol. There were common tasks that we tried to expose more
simply through utilities but the abstraction was not complete and still
ended up requiring a lot of detailed knowledge. (In c++ for example the
SubscriptionSettings seemed to causes a lot of confusion; in python the
details of acknowledgement in general came up often in questions).
The messaging API aimed to manage the details of the protocol required
for particular messaging interactions and also to provide consistency
across languages which had been missing.
It was also explicitly intended to be independent of any specific
protocol version, preventing details of a specific protocol version from
becoming baked into applications and thus allowing easy transition to
later versions.
The higher level abstraction also made it possible to more seamlessly
include richer features such as the automatic reconnection and message
replay.
In c++, it was also intended to be implemented such that we could have a
stable ABI as well (again something that was harder with the old API).
This API is now stable on trunk and would be my recommended approach
from the next release (end of October) onwards.
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:[email protected]
