[rabbitmq-discuss] AMQP 1.0 Support
Jason J. W. Williams
jasonjwwilliams at gmail.com
Fri Apr 20 21:58:56 BST 2012
> Nodes are simply a more general concept covering queues or exchanges or
> indeed other types of messaging endpoints.
My point exactly..."build your own out of our primitives".
> Links are simply subscriptions (i.e. an indication of a desire to receive
> from a give queue/node) expanded to include an analogous concept for
> indicating the desire/intention to send to a given queue/node. That is
> useful for flow control and can enable faster routing decisions.
> The same basic patterns - direct communication through shared queue,
> pub-sub, request-response - are all supported.
It is not the totally async model 0.9 has where publishers don't have
to understand where their messages might end up due to exchanges. It's
up to both publisher and consumer nodes to build the elaborate
interconnections between them to emulate queues/exchange/bindings.
> No, you would get all the same tools from your broker.
No, but no point in arguing in circles.
>> In this regard, 1.0 and ZeroMQ have a lot in common and of the
>> two ZeroMQ is frankly the better choice. The point to having a broker
>> is provide those messaging power tools so you can focus on your
> And that is still the case. Brokers can provide exactly the same queueing
> and routing capabilities.
....once you build it...
> The client library doesn't need to emulate that; it is brokers who will
> provide the equivalent functionality.
....once the client library tells the broker how to build an
equivalent set of nodes, links, and filters to create a queues,
exchanges and bindings. Since this is up to the client, this is
exactly what I was saying about replicating 0.9 primitives being by
convention of the library.
> No, the abstractions were generalised to be less prescriptive about the
> internals of a broker and to make the model simpler (e.g. no need to
> explicitly declare subscription queues for standard pub-sub pattern, let the
> broker do that for you) and more consistent (e.g. eliminate the need for
> clumsy workarounds like the default-exchange).
That's a new spin on what I've been hearing from those involved
directly for 2 years.
> ZMQ does not have similar primitives. The primitives in AMQP 1.0 focus on
> reliable, flow controlled transfer of well defined message formats all of
> which are deliberately not addressed by ZeroMQ.
ZMQ does offer reliable transfer and it's primitives are very similar.
It does also offer basic flow control.
> As you say, we'll have to disagree. I am confident that app developers will
> be very productive on 1.0, but time will tell as they say ;-)
Yes we will have to. I'm sure they'll be productive to the level of
WS-* and OASIS' other stable of technologies...
More information about the rabbitmq-discuss