[rabbitmq-discuss] AMQP 1.0 Support

[Gordon Sim]

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
> going.

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
> application.

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
> standard.

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
> brokers
> * 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 ;-)

--Gordon.