Advanced Message Queuing Protocol

Das Advanced Message Queuing Protocol ( AMQP ) ist ein offener Standard für Anwendungsschichtprotokolle in nachrichtenorientierter Middleware . Die definierenden Merkmale von AMQP sind Nachrichtenorientierung, Queuing, Routing (einschließlich Punkt-zu-Punkt- und Publish-Subscribe-Routing ), Zuverlässigkeit und Sicherheit. ^{[ 1 ]}

AMQP legt das Verhalten von Messaging-Anbieter und -Client so fest, dass Implementierungen verschiedener Hersteller interoperabel sind , ähnlich wie SMTP , HTTP , FTP usw. interoperable Systeme geschaffen haben. Frühere Standardisierungen von Middleware erfolgten auf API-Ebene (z. B. JMS ) und konzentrierten sich auf die Standardisierung der Programmiererinteraktion mit verschiedenen Middleware-Implementierungen, anstatt die Interoperabilität zwischen mehreren Implementierungen zu gewährleisten. ^{[ 2 ]} Im Gegensatz zu JMS, das eine API und eine Reihe von Verhaltensweisen definiert, die eine Messaging-Implementierung bereitstellen muss, ist AMQP ein Protokoll auf Netzwerkebene . Ein solches Protokoll beschreibt das Format der Daten, die als Byte-Stream über das Netzwerk gesendet werden . Folglich kann jedes Tool, das Nachrichten in diesem Datenformat erstellen und interpretieren kann, unabhängig von der Implementierungssprache mit jedem anderen kompatiblen Tool interoperabel sein.

AMQP ist ein binäres Anwendungsschichtprotokoll, das eine Vielzahl von Messaging-Anwendungen und Kommunikationsmustern effizient unterstützt. Es bietet flussgesteuerte, ^{[ 3 ]} nachrichtenorientierte Kommunikation mit Zustellungsgarantien wie „ maximal einmal“ (jede Nachricht wird entweder genau einmal zugestellt oder nie), „ mindestens einmal“ (jede Nachricht wird sicher zugestellt, kann aber mehrfach zugestellt werden) und „ genau einmal “ (die Nachricht kommt immer sicher und genau einmal an) ^{[ 4 ]} sowie Authentifizierung und/oder Verschlüsselung basierend auf SASL und/oder TLS . ^{[ 5 ]} Es setzt ein zuverlässiges Transportprotokoll wie das Transmission Control Protocol (TCP) voraus. ^{[ 6 ]}

Die AMQP-Spezifikation ist in mehreren Schichten definiert: (i) einem Typsystem, (ii) einem symmetrischen, asynchronen Protokoll für die Übertragung von Nachrichten zwischen Prozessen, (iii) einem standardisierten, erweiterbaren Nachrichtenformat und (iv) einer Reihe standardisierter, aber erweiterbarer „Messaging-Funktionen“.

AMQP wurde 2003 von John O'Hara bei JPMorgan Chase in London ins Leben gerufen . ^{[ 1 ] [ 7 ]} AMQP war als gemeinschaftliches Open-Source-Projekt konzipiert. Der ursprüngliche Entwurf stammte von JPMorgan Chase und wurde von Mitte 2004 bis Mitte 2006 erstellt. Die iMatix Corporation wurde mit der Entwicklung eines C-Brokers und der Protokolldokumentation beauftragt. 2005 wandte sich JPMorgan Chase an weitere Unternehmen, um eine Arbeitsgruppe zu gründen, der Cisco Systems , IONA Technologies , iMatix, Red Hat und das Transaction Workflow Innovation Standards Team (TWIST) angehörten. Im selben Jahr ging JPMorgan Chase eine Partnerschaft mit Red Hat ein, um Apache Qpid zu entwickeln , zunächst in Java und kurz darauf in C++. Unabhängig davon wurde RabbitMQ von Rabbit Technologies in Erlang entwickelt , später folgten die Implementierungen von Microsoft und StormMQ.

Die Arbeitsgruppe wuchs auf 23 Unternehmen an, darunter Bank of America , Barclays , Cisco Systems, Credit Suisse , Deutsche Börse , Goldman Sachs , HCL Technologies Ltd , Progress Software , IIT Software , INETCO Systems Limited , Informatica (einschließlich 29 West), JPMorgan Chase, Microsoft Corporation , my-Channels, Novell , Red Hat , Software AG , Solace Systems , StormMQ, Tervela Inc. , TWIST Process Innovations ltd, VMware (das Rabbit Technologies übernommen hat) und WSO2 .

Im Jahr 2008 verfasste Pieter Hintjens , CEO und Chef-Softwareentwickler von iMatix, einen Artikel mit dem Titel „Was ist falsch an AMQP (und wie man es behebt)“ ^{[ 8 ]} und verteilte ihn an die Arbeitsgruppe, um auf ein drohendes Scheitern hinzuweisen, die von iMatix festgestellten Probleme aufzuzeigen und Lösungsansätze für die AMQP-Spezifikation vorzuschlagen. Zu diesem Zeitpunkt hatte iMatix bereits mit der Entwicklung von ZeroMQ begonnen . 2010 kündigte Hintjens an, dass iMatix die AMQP-Arbeitsgruppe verlassen und AMQP/1.0 zugunsten des deutlich einfacheren und schnelleren ZeroMQ nicht mehr unterstützen werde. ^{[ 9 ]}

Im August 2011 kündigte die AMQP-Arbeitsgruppe ihre Umstrukturierung zu einer OASIS- Mitgliedssektion an. ^{[ 10 ]}

AMQP 1.0 wurde am 30. Oktober 2011 von der AMQP-Arbeitsgruppe auf einer Konferenz in New York veröffentlicht. Im Rahmen dieser Veranstaltung demonstrierten Microsoft, Red Hat, VMware , Apache, INETCO und IIT Software Software, die das Protokoll ausführte, in einer Interoperabilitätsstudie. Am darauffolgenden Tag, dem 1. November 2011, wurde die Gründung eines OASIS Technical Committee ^{[ 11 ]} bekanntgegeben , um die Entwicklung dieser AMQP-Version 1.0 im internationalen Standardisierungsprozess voranzutreiben. Der erste Entwurf von OASIS wurde im Februar 2012 veröffentlicht ^{[ 12 ].} Die Änderungen gegenüber der von der Arbeitsgruppe veröffentlichten Version beschränkten sich auf Korrekturen zur Verbesserung der Verständlichkeit (keine funktionalen Änderungen). Der zweite Entwurf wurde am 20. Juni zur öffentlichen Begutachtung freigegeben (ebenfalls ohne funktionale Änderungen) ^{[ 13 ]} , und AMQP wurde am 31. Oktober 2012 als OASIS-Standard verabschiedet ^{[ 14 ].}

OASIS AMQP wurde im April 2014 als ISO/IEC-Norm zur Veröffentlichung freigegeben. ^{[ 15 ]} AMQP 1.0 wurde im Gemeinsamen Technischen Komitee für Informationstechnologie (JTC1) der Internationalen Organisation für Normung (ISO) und der Internationalen Elektrotechnischen Kommission (IEC) zur Abstimmung gebracht. Die freigegebene OASIS AMQP-Version trägt die Bezeichnung ISO/IEC 19464.

Frühere Versionen von AMQP waren 0-8 (Juni 2006), 0-9 (Dezember 2006), 0-10 (Februar 2008) ^{[ 16 ]} und 0-9-1 (November 2008). Diese früheren Versionen unterscheiden sich deutlich von der Spezifikation 1.0. ^{[ 17 ] [ 18 ]}

Obwohl AMQP ursprünglich aus der Finanzdienstleistungsbranche stammt, ist es allgemein auf eine breite Palette von Middleware- Problemen anwendbar.

AMQP definiert ein selbstbeschreibendes Kodierungsschema, das die interoperable Darstellung einer Vielzahl gängiger Datentypen ermöglicht. Es erlaubt zudem, typisierte Daten mit zusätzlichen Bedeutungen zu versehen ^{[ 19 ].} Beispielsweise könnte ein bestimmter String-Wert so annotiert werden, dass er als URL interpretiert werden kann . Ebenso könnte ein Map-Wert mit Schlüssel-Wert-Paaren für „Name“, „Adresse“ usw. als Repräsentation des Datentyps „Kunde“ annotiert werden.

Das Typsystem dient zur Definition eines Nachrichtenformats, das es ermöglicht, Standard- und erweiterte Metadaten auszudrücken und von verarbeitenden Entitäten verstehen zu lassen. Es wird außerdem verwendet, um die Kommunikationsprimitive zu definieren, über die Nachrichten zwischen solchen Entitäten ausgetauscht werden, d. h. die AMQP- Frame-Bodies .

Die grundlegende Dateneinheit in AMQP ist ein Frame . Es sind neun AMQP-Frame-Körper definiert, die zum Initiieren, Steuern und Beenden der Nachrichtenübertragung zwischen zwei Peers verwendet werden. Diese sind:

• (die Verbindung ) öffnen
• (die Sitzung ) beginnen
• Fügen Sie (den Link ) hinzu
• überweisen
• fließen
• Anordnung
• (die Verbindung ) trennen
• Ende (der Sitzung )
• schließen (die Verbindung )

Das Verbindungsprotokoll ist das Herzstück von AMQP.

Ein Attach- Frame-Body wird gesendet, um eine neue Verbindung herzustellen; ein Detach-Frame wird gesendet, um eine Verbindung zu trennen. Verbindungen können hergestellt werden, um Nachrichten zu empfangen oder zu senden.

Nachrichten werden über eine bestehende Verbindung mithilfe des Übertragungsrahmens gesendet . Nachrichten fließen auf einer Verbindung nur in eine Richtung.

Die Übertragungen unterliegen einem kreditbasierten Flusskontrollschema, das mithilfe von Flow- Frames verwaltet wird. Dies ermöglicht es einem Prozess, sich vor einer Überlastung durch ein zu großes Nachrichtenvolumen zu schützen oder, einfacher ausgedrückt, einem abonnierten Link zu ermöglichen, Nachrichten nach Bedarf abzurufen. ^{[ 20 ]}

Jede übertragene Nachricht muss letztendlich abgeschlossen werden . Der Abschluss stellt sicher, dass Sender und Empfänger sich über den Übertragungsstatus einigen und bietet somit Zuverlässigkeitsgarantien. Statusänderungen und der Abschluss einer Übertragung (oder mehrerer Übertragungen) werden zwischen den Teilnehmern mithilfe des Dispositions -Frames kommuniziert. Auf diese Weise lassen sich verschiedene Zuverlässigkeitsgarantien durchsetzen: höchstens einmal, mindestens einmal und genau einmal. ^{[ 21 ]}

Mehrere Verbindungen in beide Richtungen können zu einer Sitzung zusammengefasst werden . Eine Sitzung ist eine bidirektionale, sequentielle Kommunikation zwischen zwei Teilnehmern, die mit einem Begin- Frame beginnt und mit einem End- Frame beendet wird. Über eine Verbindung zwischen zwei Teilnehmern können mehrere Sitzungen gemultiplext werden, die jeweils logisch unabhängig sind. Verbindungen werden mit einem Open- Frame initiiert, in dem die Fähigkeiten des sendenden Teilnehmers ausgedrückt werden, und mit einem Close -Frame beendet.

AMQP definiert als die reine Nachricht den Teil der Nachricht, der von der sendenden Anwendung erstellt wird. Dieser Teil gilt als unveränderlich, da die Nachricht zwischen einem oder mehreren Prozessen übertragen wird.

Die Gewährleistung der Unveränderlichkeit der von der Anwendung gesendeten Nachricht ermöglicht die Ende-zu-Ende-Signatur und/oder -Verschlüsselung und stellt sicher, dass alle Integritätsprüfungen (z. B. Hashwerte oder Digests ) gültig bleiben. Die Nachricht kann während der Übertragung von Zwischenstellen annotiert werden; diese Annotationen bleiben jedoch von der unveränderlichen Originalnachricht getrennt . Annotationen können vor oder nach der Originalnachricht hinzugefügt werden.

Der Header ist ein Standardsatz von Zustellungshinweisen, die für eine Nachricht angefordert oder angegeben werden können und unter anderem Gültigkeitsdauer, Haltbarkeit und Priorität umfassen. ^{[ 22 ]}

Die eigentliche Nachricht ist strukturiert als eine optionale Liste von Standardeigenschaften (Nachrichten-ID, Benutzer-ID, Erstellungszeitpunkt, Antwort an, Betreff, Korrelations-ID, Gruppen-ID usw.), eine optionale Liste von anwendungsspezifischen Eigenschaften (d. h. erweiterten Eigenschaften) und ein Nachrichtentext, den AMQP als Anwendungsdaten bezeichnet. ^{[ 23 ]}

Eigenschaften und Annotationen werden im AMQP-Typsystem definiert. Die Anwendungsdaten können beliebige Formen und Kodierungen aufweisen. Eine Möglichkeit besteht darin, das AMQP-Typsystem zum Senden strukturierter, selbstbeschreibender Daten zu verwenden.

Das Link-Protokoll überträgt Nachrichten zwischen zwei Knoten , macht aber nur sehr wenige Annahmen darüber, was diese Knoten sind oder wie sie implementiert sind.

Eine wichtige Kategorie sind Knoten, die als Treffpunkt zwischen Sendern und Empfängern von Nachrichten dienen (z. B. Warteschlangen oder Themen ). Die AMQP-Spezifikation bezeichnet solche Knoten als Verteilungsknoten und kodifiziert einige gemeinsame Verhaltensweisen. ^{[ 24 ]}

Dies umfasst:

• einige Standardergebnisse für Übertragungen, durch die Empfänger von Nachrichten beispielsweise Nachrichten annehmen oder ablehnen können ^{[ 25 ].}
• ein Mechanismus zur Anzeige oder Anforderung eines der beiden grundlegenden Vertriebsmuster, konkurrierende und nicht konkurrierende Konsumenten, durch die Vertriebsmodi bewegen bzw. kopieren ^[ 26 ^{] .}
• die Möglichkeit, Knoten bei Bedarf zu erstellen, ^{[ 27 ] [ 28 ]} z. B. für temporäre Antwortwarteschlangen
• Die Fähigkeit, die Menge der für einen Empfänger relevanten Nachrichten durch Filter einzugrenzen ^{[ 29 ].}

Obwohl AMQP in einfachen Peer-to-Peer-Systemen eingesetzt werden kann, ermöglicht die Definition dieses Frameworks für Messaging-Funktionen zusätzlich die Interoperabilität mit Messaging-Vermittlern (Brokern, Bridges usw.) in größeren, komplexeren Messaging-Netzwerken. Das spezifizierte Framework deckt grundlegende Verhaltensweisen ab, lässt aber die Entwicklung von Erweiterungen zu, die weiter kodifiziert und standardisiert werden können.

• Apache Qpid , ein Open-Source -Projekt der Apache Foundation
• Apache ActiveMQ , ein Open-Source -Projekt der Apache Foundation
• Azure Event Hubs ^{[ 30 ] [ 31 ]}
• Azure Service Bus ^{[ 30 ] [ 32 ]}
• IBM MQ ^{[ 33 ] [ 34 ]}
• Solace PubSub+, ein Multi-Protokoll-Broker in Hardware, Software und Cloud ^{[ 35 ]}
• RabbitMQ , ein von VMware gefördertes Open-Source- Projekt , unterstützt AMQP 1.0 ab Version 4.0.

• JORAM , eine Java- Open-Source -Implementierung des OW2-Konsortiums .
• Apache Qpid unterstützt mehrere AMQP-Versionen ^{[ 36 ].}

AMQP-Protokoll Version 1.0 ist die aktuelle Spezifikationsversion. Sie konzentriert sich auf Kernfunktionen, die für die Interoperabilität im Internetmaßstab notwendig sind. Sie enthält weniger explizites Routing als frühere Versionen, da die Kernfunktionalität als erstes streng standardisiert wurde. Die Interoperabilität von AMQP 1.0 wurde umfassender mit mehr Implementierern getestet als bei früheren Versionen. ^{[ 37 ]}

Die AMQP-Website enthält die OASIS-Spezifikation für Version 1.0 .

Frühere Versionen von AMQP, die vor der Veröffentlichung von Version 1.0 erschienen sind (siehe oben: Versionsgeschichte) und sich deutlich von dieser unterscheiden, umfassen:

• AMQP 0-9-1 , für das Clients „für viele gängige Programmiersprachen und Plattformen“ verfügbar sind ^{[ 38 ].}
• AMQP 0-10

Diese offenen Protokollspezifikationen decken denselben oder einen ähnlichen Bereich wie AMQP ab:

• Streaming Text Oriented Messaging Protocol (STOMP), ein textbasiertes Protokoll, das bei Codehaus entwickelt wurde; verwendet die JMS-ähnliche Semantik von 'Ziel'.
• Extensible Messaging and Presence Protocol (XMPP), das Extensible Messaging and Presence Protocol.
• MQTT , ein leichtgewichtiges Publish-Subscribe-Protokoll.
• OpenWire, wie es von ActiveMQ verwendet wird .

Java Message Service (JMS) wird häufig mit AMQP verglichen. JMS ist jedoch eine API-Spezifikation (Teil der Java-EE -Spezifikation), die die Implementierung von Nachrichtenproduzenten und -konsumenten definiert. JMS garantiert keine Interoperabilität zwischen verschiedenen Implementierungen, und das verwendete JMS-konforme Messaging-System muss möglicherweise sowohl auf Client- als auch auf Serverseite bereitgestellt werden. AMQP hingegen ist eine Protokollspezifikation für die Netzwerkkommunikation. Theoretisch bietet AMQP Interoperabilität, da unterschiedliche AMQP-konforme Software auf Client- und Serverseite eingesetzt werden kann.

• Peer-to-Peer
• Nachrichtenwarteschlange
• Nachrichtenwarteschlangendienst
• Datenverteilungsdienst
• IBM MQ

• Offizielle Website
• Technisches Komitee von OASIS AMQP
• Überblick über AMQP und das AMQP-Modell (Version 0-9-1)
• OMG-Analyse von AMQP und Vergleich mit DDS-RTPS
• Google Tech Talk mit Video und Folien über RabbitMQ
• Präsentation von AMQP- und RestMS-Messaging auf der FOSDEM 2009
• Liste der AMQP-Clients