[rabbitmq-discuss] AMQP 1.0 Support

[Martin Sustrik]

Hi Jason, Gordon,

Interesting discussion.

I think Jason has a point in that AMQP/1.0 has deliberately dropped to 
"model" part of spec (i.e. exchanges/queues/bindings) which was the real 
meat of the protocol.

I have no idea what the reasons were. In any case it dumbs down the 
protocol to the extent where it becomes an ugly version of TCP built on 
top of TCP.

I have to disagree though that ZeroMQ/Crossroads did a similar thing. 
Instead of dropping the AMQP model, my goal was to refine it, remove 
weird cases (like broadcasting messages to multiple queues, then 
load-balancing them to the consumers) and make the concepts implicitly 
contained in AMQP model, like request/reply, publish/subscribe etc. even 
more explicit.

Martin

On 20/04/12 19:37, Jason J. W. Williams wrote:
> Hi Gordon
>
>>
>> I don't think it is.
>
> We'll have to disagree. RedHat is one of a couple corporate members of
> the WG that were largely responsible for pushing the shift in
> direction to what became 1.0, and 1.0 serves those interests.
>
>> An app developer in my view would generally be using an AMQP library, rather
>> than implementing the protocol directly, and I can't see how that would be
>> made any more difficult (if anything for a certain class of users at least I
>> think it would be more intuitive).
>
> 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. 0.9.x gives us the equivalent of power
> tools, 1.0 instead makes you build the tools before you can ever get
> going. 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.
>
> 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.
>
>
>> 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. 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.
>
>
> 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.
>
> -J
> _______________________________________________
> rabbitmq-discuss mailing list
> rabbitmq-discuss at lists.rabbitmq.com
> https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss