qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gordon Sim <g...@redhat.com>
Subject Re: Best Practices for C++ API
Date Thu, 19 Apr 2012 16:25:38 GMT
On 04/19/2012 04:47 PM, techguy911 wrote:
> I have read that the preferred API to use for C++ is messaging (not client).
> The client API has all the good stuff for creating exchanges, queues,
> binding queues, setting queue options, and async message reception.  I want
> to stay as compliant as possible with the AMQP 0.10 and 1.0 standards for
> future compatibility.
>
> What is the best way to approach a new project where I have to:
> * programatically create exchanges, queues, set queue options, bind, etc
> * send and receive messages (async or callback preferred)
> * stay compliant with AMQP standards (Communicate with different brokers and
> publisher/subscribers)
> * Use an API this is not going away or is going to be standardized in the
> future
>
> With some searching, I found some new things happening with the client API,
> there's some new namespaces called qpid::client::Session_0_10:: and other
> 0_10 items.

Those are not new namespaces, they have been there from the start.

> Is this the beginnings of a standardized API?  Does that mean
> using the client API is a good choice?

No, I would not advise that.  The problem with the qpid::client API is 
that the API is tied very tightly to the 0-10 version of the protocol. 
It is also more complicated to use than is really necessary.

The qpid::messaging API was introduced to address that problem. It is 
explicitly designed to allow simple transition to AMQP 1.0 without 
having to rewrite your applications. This doesn't affect compliance with 
the protocol.

It is fairly simple to build a push-style message dispatch on top of the 
pull-style qpid::messaging API. I have attached a simple example of what 
that might look like. The code is not complex and can be easily adapted.

There are a couple of options in creating queues and exchanges and 
binding them together.

The messaging API implementation can automatically create and bind 
subscription queues (e.g. for pub-sub patterns). Customisation of queue 
options can be quite easily achieved using the addressing syntax for the 
messaging API[1][2], which can also be used to create exchanges or 
shared queues on demand.

Where you have a need for more complex programmatic broker 
configuration, you can use QMF (the Qpid Management Framework), which is 
a simple message-based management protocol for controlling the broker. 
This runs over standard AMQP, but the message formats are Qpid specific.

As a last resort you can of course use the old qpid::client API to 
directly use the set of commands defined in AMQP 0-10 for declaring and 
binding queues and exchanges. Note however that there are no analogous 
commands in AMQP 1.0 however[3]. If you do pick this approach I would 
strongly recommend that as far as possible you limit the code that uses 
this API; i.e. keep configuration code separate from the general 
messaging code if at all possible. That will enable you to benefit from 
ongoing development (which will be in the qpid::messaging API) and 
transition to AMQP 1.0.

[1] http://qpid.apache.org/books/0.16/Programming-In-Apache-Qpid/
[2] https://cwiki.apache.org/confluence/display/qpid/Addressing+Examples
[3] The QMF based approach will be required on AMQP 1.0; there has been 
work on a standard management protocol for AMQP 1.0 but that is still in 
relatively early stages. It is highly likely that any such standard 
would be based on a similar approach to QMF, though perhaps with a 
different schema and different message formats.

Mime
View raw message