On 04/26/2011 10:33 PM, David Hawthorne wrote:
Interesting. This would be good data to have in the docs for the address
string format, along with some more examples for topic exchanges. Maybe in
this case I should use the old client API for declaring the exchange, queue,
and binding, and then subscribe to it with the messaging API. That's hideous,
but it'll work.
I don't mean for the rest of this to be a rant, but if you're looking for
feedback on the new API, here it is.
We always appreciate feedback, so thanks for taking the time to give it!
I found it confusing and difficult to use the new messaging API is because it has new terminology for existing concepts (e.g. node, link, subject, x-declare, x-bindings) that I already understood, as well as the difficulty I had in trying to figure out exactly what the node and link concepts represented. The fact that they represent different concepts (based on inferences from your explanation) is only more confusing. At first glance the messaging API looks really sweet and easy to use, but after digging into it, it's actually harder to figure out and use than the old client API. This goes all the way down to the fact that I skipped over the x-declare and x-bindings bits of the documentation because of the "x-" in their names; I thought they referred to special xml magic. The fact that I can specify exclusive flags at more than one place in the addressing scheme tells me it's broken. There should be one way to do things and it should make sense, and the user shouldn't
have to dig down into the unit test code or the API source code to figure it
out.
I'm sorry that it has been confusing to use. Believe me I totally
understand the frustration that causes!
We haven't done enough to explain the motivations for messaging API and
the addressing in particular and that has contributed to the confusion
(particularly I suspect for those who used the old API previously).
There were a few goals for the messaging API. One was to create a
stable, protocol version independent API/ABI with a view to allowing
simple transition to AMQP 1.0 (but also taking the view that unnecessary
coupling to the protocol details could and should be avoided in many
cases). Another was to make the API simpler, particularly for users who
didn't care too much about the underlying protocol details. (Another was
to align the APIs across different languages, at least conceptually).
In general the messaging API is concerned with controlling the message
flows in and out of a process. The address is deliberately defined in
stringified form to make it easy for that to be changed without changing
the application code. The assumption here is that the logic for
controlling messaging inflow and outflow is largely independent of the
sources and targets of those messages. We felt this strengthened the
decoupling that is a characteristic of messaging applications.
It is not an API for configuring the broker or creating queues etc.
Obviously some use cases require some dynamic creation and this should
be easy (the common cases we saw were temporary queues and 'subscription
queues' for topics).
We recognised however that there would be cases we hadn't envisaged.
Cases perhaps where existing AMQP 0-10 functionality was being used
directly. That is where the more esoteric addressing options came in.
We also recognise that full featured configuration/management of the
broker is often needed via programmatic means. Our approach to that has
been to layer that on top of the messaging API. As of the 0.10 release
of Qpid you can create and delete exchanges, queues and bindings by
sending a map message of the correct format to a special address. You
can also retrieve lists of exchanges, queues and bindings this way.
We did try to explain the concepts around addressing, and the AMQP 0-10
specific mapping, in the programmers guide[1] (sections 2.4 and 2.16 in
particular), but it still needs a lot of work. Any suggestions on what
changes would make the most difference would be appreciated.
[1] http://qpid.apache.org/books/0.8/Programming-In-Apache-Qpid/html/
Using the addressing API to create a queue on a topic exchange would have been
very, very easy if it looked like this:
qpid::messaging::Connection connection;
connection.open("localhost", 5673);
qpid::messaging::Receiver receiver = connection.createReceiver("/vhost; exchange: {
name: 'test', type: topic, durable: false, passive: false, auto-delete: true }, queue: {
name: 'all_foo', passive: false, durable: false, auto-delete: true, exclusive: false,
bindings: [ { exchange: 'test', routing_key: 'foo.#' } ] }");
qpid::messaging::Message message;
while (receiver->getMessage(message, timeout))
messages_received++;
The envisaged common case was simply wanting to 'subscribe' to a given
topic. The address in that case would just be 'exchange/foo.#'.
Your case, where you want to dynamically create and bind a shared queue
on demand was not one we had considered to be a particularly common
pattern. We may have got that wrong and I'd be keen to hear more on the
reason for that design, particularly why the shared queue should be
created on the fly and why it is being shared. Where there are useful,
generally applicable patterns, we would want to support those in a
simple manner in the address syntax.
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:[email protected]
