Building a simpler protocol (BERT-RPC or something with similar semantics) on top of a more complex one (AMQP, designed for complex pub-sub use cases) is sort-of backwards. It means you need to duplicate functionality that belongs at the lower layer, and drag along all kinds of extra baggage.
Instead, a message queue should ideally be built on top of a simpler RPC/message-passing protocol. One thing I dislike about AMQP and similar protocols is that they put too many aspects of the communication into one layer, making it harder to re-use portions of them for other purposes. I don't know if you've ever looked at the AMQP spec, but it's kind of a monster (a 280 page PDF file).
There's of course some overhead vs. a simple BERT-RPC to set up a broker (you can set up simple ones fast...), but that should be weighed against the gains you get.
And note that my curiosity/confusion also comes about because we are talking about a technology with a reliable software stack and money behind it (for example, RabbitMQ written in Erlang) vs. building a protocol from scratch. The situation is different if you are looking at equally mature technologies.
Comments
Building a simpler protocol (BERT-RPC or something with similar semantics) on top of a more complex one (AMQP, designed for complex pub-sub use cases) is sort-of backwards. It means you need to duplicate functionality that belongs at the lower layer, and drag along all kinds of extra baggage.
Instead, a message queue should ideally be built on top of a simpler RPC/message-passing protocol. One thing I dislike about AMQP and similar protocols is that they put too many aspects of the communication into one layer, making it harder to re-use portions of them for other purposes. I don't know if you've ever looked at the AMQP spec, but it's kind of a monster (a 280 page PDF file).
> duplicate functionality that belongs at the lower layer, and drag along all kinds of extra baggage
I'm just talking about sending messages not any kind of new protocol on top, for example http://code.google.com/p/py-amqplib/source/browse/demo/demo_...
There's of course some overhead vs. a simple BERT-RPC to set up a broker (you can set up simple ones fast...), but that should be weighed against the gains you get.
And note that my curiosity/confusion also comes about because we are talking about a technology with a reliable software stack and money behind it (for example, RabbitMQ written in Erlang) vs. building a protocol from scratch. The situation is different if you are looking at equally mature technologies.