10

As I understood AMQP 0.9.1, the main benefit was that you could send and receive messages and configure your exchanges / bindings / queues in a broker-independent way, thus you were able to switch your broker implementation without too much headache.

Now, AMQP 1.0 only defines a wire-level protocol, so you actually have to know your broker specifics in order to implement most messaging patterns.

Then why would I favour a message broker that is AMQP compliant over one that is not?

If the broker implements AMQP 1.0, I'm still locked in with broker specific client code. With AMQP 0.9.1, I am theoretically broker independent but would most likely end up with RabbitMQ, since they seem to be the only ones to sincerely maintain the full support for AMQP 0.9.1.

flrnb
  • 836
  • 1
  • 7
  • 13

1 Answers1

5

Unfortunately, your concerns are very valid.

Pieter Hintjens has great post on that, claiming that "AMQP/1.0 will go down in history as a prime documented example of how to fail a standardization effort and hurt a lot of people in the process."

To your question: "why would I favour a message broker that is AMQP compliant over one that is not?" Definitely not because you get the option to change your message broker provider, as it is now not required. There are only two situations, I would think of favouring AMQP message broker:

1) You are already used to that and have that broker easily available

2) AMQP still brings the advantage of having clients available in multiple programming languages. But STOMP would serve here too.

Jan Vlcinsky
  • 42,725
  • 12
  • 101
  • 98
  • Whereas JMS provides a standard messaging API for the Java Platform, AMQP provides a standard messaging protocol across all platforms. AMQP does not provide a specification for an industry standard API. Rather, it provides a specification for an industry standard wire-level binary protocol to describe how the message should be structured and sent across the network. With AMQP, we can use whatever AMQP-compliant client library we want and any AMQP-compliant broker. As a result, messaging clients using AMQP are completely agnostic to which AMQP client API or AMQP message broker we are using. – java_geek Dec 15 '14 at 17:18
  • @java_geek While your comment sounds close to original intention, it does not seem to be correct in few places. AMQP 0.9.1 allowed what you describe (exchanging client and broker implementation and keep interoperability), but with 1.0 this is not always true, as broker can implement only part of what can be expected, so the option of replacing one broker by another is not always true. – Jan Vlcinsky Dec 15 '14 at 22:14