[rabbitmq-discuss] AMQP 1.0 Support
gsim at redhat.com
Fri Apr 20 21:26:35 BST 2012
On 04/20/2012 06:37 PM, Jason J. W. Williams wrote:
> Client libraries reflect the primitives present in the protocol, and
> thereby directly the difficulty or ease with which they can be used to
> build applications.
> 1.0 replaces useful out-of-the-box ready primitives like queues,
> exchanges and bindings with a "build-it-yourself" approach using
> nodes, links and filters.
That isn't the case.
Nodes are simply a more general concept covering queues or exchanges or
indeed other types of messaging endpoints.
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.
> 0.9.x gives us the equivalent of power
> tools, 1.0 instead makes you build the tools before you can ever get
No, you would get all the same tools from your broker.
> 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.
> Furthermore, any client library attempting to emulate
> queue/binding/exchange fabric primitives using 1.0 "bricks" would be
> doing so as a non-standard convention, one that would have to be
> adopted by other library writers in exactly the same way to afford the
> cross-platform capabilities that 0.9.x has from day one as a draft
The client library doesn't need to emulate that; it is brokers who will
provide the equivalent functionality.
>> It is certainly not limited to - or even focused on - integration with
>> non-AMQP brokers though it is deliberately less imposing in terms of a
>> broker implementations internal architecture to promote even wider adoption.
> Quoting from a JPMorgan preso on 1.0 as to the design goals:
> * Simplify wire protocol
> * Global Addressing
> * Create a model more easy to retro-fit to legacy
> * Extensible layered protocol
> All of these serve federation and integration (i.e. broker writers),
> not the app developer.
> THE reason nodes/links/filters became the new 1.0 primitives was
> precisely to enable easier federation with non-AMQP brokers.
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).
> Want to
> forward a message on to a federated broker? No problem, attach another
> link pointing to the federated broker with the right filter. 1.0
> exists to make life easier on broker implementers and integrators, not
> to help app developers/users. It puts the burden on the app developer
> to build up the actual primitive he wants. Again, ZMQ is a better 1.0
> than 1.0: it has similar primitives, is simpler, and doesn't pretend
> to be anything other than a transport erector set.
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.
> As an OASIS standard now, I foresee AMQP 1.0 continuing on it's trek
> to serve it's corporate masters/designers...which would be fine if it
> didn't throw app developers and their productivity to the wolves as
> 1.0 has done.
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 ;-)
More information about the rabbitmq-discuss