Wie ich AMQP 0.9.1 verstand, war der Hauptvorteil, dass Sie Nachrichten senden und empfangen und Ihre Vermittlungen / Bindungen / Warteschlangen auf maklerunabhängige Weise konfigurieren konnten, so dass Sie Ihre Vermittlerimplementierung ohne zu viele Kopfschmerzen wechseln konnten .
Nun definiert AMQP 1.0 nur ein Protokoll auf Wire-Level-Ebene. Sie müssen also Ihre Broker-Details kennen, um die meisten Messaging-Muster implementieren zu können.
Warum würde ich dann einen Message-Broker bevorzugen, der AMQP-konform ist, gegenüber einem, der das nicht tut?
Wenn der Broker AMQP 1.0 implementiert, bin ich immer noch mit dem Broker-spezifischen Client-Code verbunden. Mit AMQP 0.9.1 bin ich theoretisch maklerunabhängig, würde aber höchstwahrscheinlich mit RabbitMQ enden, da sie die einzigen sind, die aufrichtig die volle Unterstützung für AMQP 0.9.1 aufrechterhalten.
Leider sind Ihre Bedenken sehr berechtigt.
Pieter Hintjens hat einen großartigen Beitrag dazu und behauptet, dass "AMQP / 1.0 in die Geschichte eingehen wird, als ein Paradebeispiel für wie man bei einer Standardisierungsbemühung versagt und dabei viele Menschen verletzt. "
Auf Ihre Frage: "Warum würde ich einen Message-Broker bevorzugen, der AMQP-konform ist, gegenüber einem, der das nicht tut?" Definitiv nicht, weil Sie die Möglichkeit haben, Ihren Message-Broker-Provider zu ändern, da dieser jetzt nicht benötigt wird. Es gibt nur zwei Situationen, ich würde AMQP Message Broker bevorzugen:
1) Sie sind bereits daran gewöhnt und haben diesen Broker leicht verfügbar
2) AMQP bietet immer noch den Vorteil, dass Clients in mehreren Programmiersprachen verfügbar sind. Aber STOMP würde auch hier dienen.