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.
dispatch-example.tgz
Description: application/compressed-tar
--------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
