Best Practices for C++ API

[techguy911]

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.  Is this the beginnings of a standardized API?  Does that mean using the client API is a good choice?

[Gordon Sim]

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.


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

[techguy911]

Thanks for the help!

I'll stick with the messaging API for now and try to handle everything with address strings.  If I need to find or create a C++ solution to managing the broker exchanges and queues, I'll post what I have here.