Freigeben über


Unterstützung von Advanced Message Queueing Protocol (AMQP) 1.0 in Service Bus

Der Azure Service Bus-Clouddienst verwendet AMQP 1.0 als Hauptkommunikationsmittel. In den letzten zehn Jahren hat Microsoft mit Partnern aus der Branche, sowohl Kunden als auch Lieferanten konkurrierender Nachrichtenbroker, AMQP entwickelt, wobei neue Erweiterungen im OASIS AMQP Technical Committee entwickelt wurden. AMQP 1.0 ist ein ISO- und IEC-Standard (ISO 19464:20149).

AMQP gibt Ihnen die Möglichkeit, plattformübergreifende Hybridanwendungen mit einem anbieter- und implementierungsneutralen, offenen Standardprotokoll zu erstellen. Sie können Anwendungen erstellen, deren Komponenten unter Verwendung unterschiedlicher Sprachen und Frameworks erstellt wurden und unter unterschiedlichen Betriebssystemen ausgeführt werden. Alle diese Komponenten können über Service Bus eine Verbindung herstellen und strukturierte Geschäftsnachrichten effizient und sicher nahtlos austauschen.

Einführung: Was ist AMQP 1.0 und warum ist es wichtig?

Traditionell nutzen nachrichtenorientierte Middlewareprodukte proprietäre Protokolle für die Kommunikation zwischen Clientanwendungen und Brokern. Dies bedeutet, dass Sie nach der Entscheidung für den Messagingbroker eines bestimmten Anbieters auch dessen Bibliotheken zur Anbindung der Clientanwendungen an den Broker verwenden müssen. Es bringt eine gewisse Anbieterabhängigkeit mit sich, da eine Portierung einer Anwendung auf ein anderes Produkt Codeänderungen an allen verbundenen Anwendungen erforderlich machen. In der Java-Community haben sprachspezifische API-Standards wie z. B. Java Message Service (JMS) und die Abstraktionen des Spring Frameworks diese Probleme etwas verringert, doch ihr Funktionsumfang ist schmal, und sie schließen Entwickler aus, die andere Sprachen verwenden.

Zudem ist es schwierig, Messagingbroker unterschiedlicher Anbieter zu kombinieren. In der Regel ist hierfür eine Überbrückung auf Anwendungsebene erforderlich, um Nachrichten von einem System in ein anderes zu übertragen und die jeweils proprietären Nachrichtenformate zu konvertieren. Dies ist eine häufig gestellte Anforderung, etwa um eine neue, vereinheitlichte Oberfläche für ältere, dezentrale Systeme bereitzustellen oder nach einem Unternehmenszusammenschluss die IT-Systeme zu integrieren. AMQP ermöglicht das direkte Herstellen von Verbindungen zwischen Brokern, z. B. die Verwendung von Routern wie Apache Qpid Dispatch Router oder brokernativen „Shovels“, wie z. B. die von RabbitMQ.

Die Softwarebranche ist äußerst schnelllebig, und neue Programmiersprachen und Anwendungsframeworks werden in einem manchmal verblüffenden Tempo eingeführt. Ganz ähnlich entwickeln sich die Anforderungen von IT-Systemen im Laufe der Zeit, und Entwickler möchten die Vorteile der neuesten Plattformfeatures nutzen. Manchmal jedoch unterstützt der gewählte Messaginganbieter diese Plattformen nicht. Wenn Messagingprotokolle proprietär sind, ist es nicht möglich, dass Dritte die Bibliotheken für diese neuen Plattformen bereitstellen. Daher müssen Sie Ansätze wie z. B. Gateways oder Bridges entwickeln, damit Sie das Messagingprodukt weiterhin verwenden können.

All diese Probleme waren der Grund für die Entwicklung von AMQP (Advanced Message Queuing Protocol) 1.0. Das Projekt wurde angestoßen von JP Morgan Chase, da dieses Unternehmen wie die meisten Finanzdienstleister nachrichtenorientierte Middleware in großem Umfang nutzt. Das Ziel war ganz einfach: ein Messagingprotokoll mit offenem Standard zu entwickeln, das die Erstellung nachrichtenbasierter Anwendungen aus Komponenten ermöglicht, die auf unterschiedlichen Sprachen, Frameworks und Betriebssystemen beruhen, um so die jeweils besten Komponenten verschiedenster Hersteller einsetzen zu können.

Technische Merkmale von AMQP 1.0

AMQP 1.0 ist ein effizientes, zuverlässiges Messagingprotokoll auf Wire-Ebene, mit dem Sie robuste und plattformübergreifende Messaginganwendungen erstellen können. Das Protokoll hat einen eindeutigen Zweck: die Mechanismen der sicheren, zuverlässigen und effizienten Nachrichtenübertragung zwischen zwei Parteien zu definieren. Die Nachrichten selbst werden mithilfe einer portierbaren Datendarstellung codiert, die den Austausch strukturierter Geschäftsnachrichten zwischen heterogenen Sendern und Empfängern bei voller Vertraulichkeit ermöglicht. Hier finden Sie eine Zusammenfassung der wichtigsten Merkmale:

  • Effizient: AMQP 1.0 ist ein verbindungsorientiertes Protokoll, das eine binäre Codierung für die Protokollanweisungen und die darüber übertragenen Geschäftsnachrichten nutzt. Es beinhaltetet ausgereifte Schemata zur Flusssteuerung, um die Auslastung von Netzwerk und angeschlossenen Komponenten zu maximieren. Vor diesem Hintergrund verfolgt das Protokoll das Ziel, ein Gleichgewicht zwischen Effizienz, Flexibilität und Interoperabilität zu gewährleisten.
  • Zuverlässig: Mit dem AMQP 1.0-Protokoll können Nachrichten mit Verlässlichkeitsgarantien unterschiedlicher Niveaus gesendet werden: von „Fire-and-Forget“ bis hin zu zuverlässiger, genau einmal bestätigter Lieferung.
  • Flexibel: AMQP 1.0 ist ein flexibles Protokoll, das zur Unterstützung unterschiedlicher Topologien genutzt werden kann. Ein und dasselbe Protokoll kann für die Kommunikation von Client zu Client, von Client zu Broker und von Broker zu Broker dienen.
  • Unabhängig vom Brokermodell: Die AMQP 1.0-Spezifikation stellt keine Anforderungen an das von einem Broker verwendete Messagingmodell. Vorhandene Messagingbroker können also ganz einfach um die Unterstützung von AMQP 1.0 erweitert werden.

AMQP 1.0 ist ein Standard (im wahrsten Sinne des Wortes)

AMQP 1.0 ist ein internationaler Standard, der von ISO und IEC gemäß ISO/IEC 19464:2014 genehmigt wurde.

Die Entwicklung von AMQP 1.0 wird seit 2008 von einer Kerngruppe aus über 20 Unternehmen – Technologielieferanten wie auch Endnutzern – vorangetrieben. In diesem Prozess haben die Abnehmerfirmen vermittelt, welche Anforderungen im echten Geschäftsleben auftreten, und die Technologieanbieter daraus ein entsprechend ausgelegtes Protokoll entwickelt. Während der Entwicklungszeit haben die Hersteller in Workshops die Interoperabilität ihrer Implementierungen gemeinsam überprüft.

Im Oktober 2011 ging die Entwicklungsarbeit an einen technischen Ausschuss der Organization for the Advancement of Structured Information Standards (OASIS) über; der OASIS AMQP 1.0-Standard wurde im Oktober 2012 veröffentlicht. Während der Entwicklung des Standards waren die folgenden Unternehmen im technischen Ausschuss vertreten:

  • Technologieanbieter: Axway Software, Huawei Technologies, IIT Software, INETCO Systems, Kaazing, Microsoft, Mitre Corporation, Primeton Technologies, Progress Software, Red Hat, SITA, Software AG, Solace Systems, VMware, WSO2, Zenika.
  • Abnehmerfirmen: Bank of America, Credit Suisse, Deutsche Börse, Goldman Sachs, JPMorgan Chase.

Die derzeitigen Vorsitzenden des OASIS AMQP Technical Committee repräsentieren Red Hat und Microsoft.

Zu den am häufigsten genannten Vorteilen offener Standards gehören:

  • Geringere Gefahr von Anbieterabhängigkeit
  • Interoperabilität
  • Breite Verfügbarkeit von Bibliotheken und Werkzeugen
  • Schutz vor Obsoleszenz
  • Verfügbarkeit qualifizierter Mitarbeiter
  • Geringeres und überschaubares Risiko

AMQP 1.0 und Service Bus

Durch die AMQP 1.0-Unterstützung in Azure Service Bus können Sie die Brokermessagingfunktionen für Warteschlangen und Veröffentlichungen/Abonnements von Service Bus mithilfe eines effizienten binären Protokolls auf unterschiedlichen Plattformen nutzen. Zudem können Sie Anwendungen erstellen, deren Komponenten mit einer Mischung aus Sprachen, Frameworks und Betriebssystemen erstellt wurden.

Die folgende Abbildung zeigt das Beispiel einer Bereitstellung, bei der auf Linux ausgeführte Java-Clients, die mit der Standard-Programmierschnittstelle Java Message Service (JMS) geschrieben wurden, und auf Windows ausgeführte .NET-Clients unter Verwendung von AMQP 1.0 Nachrichten über Service Bus austauschen.

Abbildung, die eine Service Bus-Instanz zeigt, die Nachrichten mit zwei Linux-Umgebungen und zwei Windows-Umgebungen austauscht.

Abbildung 1: Beispielszenario für eine Bereitstellung mit plattformübergreifender Nachrichtenübermittlung mittels Service Bus und AMQP 1.0

Alle unterstützten Service Bus-Clientbibliotheken, die über das Azure SDK verfügbar sind, verwenden AMQP 1.0.

Die Option AMQP-over-WebSockets-Protokoll wird über TCP-Port 443 wie die HTTP-/REST-API ausgeführt, ist aber ansonsten funktionell identisch mit einfachem AMQP. Diese Option weist eine höhere anfängliche Verbindungslatenz auf, weil zusätzliche Handshakeroundtrips auftreten und der Mehraufwand als Kompromisse bei der gemeinsamen Verwendung des HTTPS-Ports geringfügig größer ist. Wenn dieser Modus ausgewählt ist, ist TCP-Port 443 für die Kommunikation ausreichend. Mit den folgenden Optionen können Sie den AMQP-WebSockets-Modus auswählen.

Sprache Option
.NET (Azure.Messaging.ServiceBus) Erstellen Sie ServiceBusClient mithilfe eines Konstruktors, der ServiceBusClientOptions als Parameter akzeptiert. Legen Sie ServiceBusClientOptions.TransportType auf ServiceBusTransportType.AmqpWebSockets fest.
.NET (Microsoft.Azure.ServiceBus) Verwenden Sie beim Erstellen von Clientobjekten Konstruktoren, die TransportType, ServiceBusConnection oder ServiceBusConnectionStringBuilder als Parameter verwenden.

Legen Sie für das Konstrukt, das transportType als Parameter verwendet, den Parameter auf TransportType.AmqpWebSockets fest.

Legen Sie für den Konstruktor, der ServiceBusConnection als Parameter verwendet, ServiceBusConnection.TransportType auf TransportType.AmqpWebSockets fest.

Wenn Sie ServiceBusConnectionStringBuilder verwenden, nutzen Sie Konstruktoren, mit denen Sie die angeben transportType können.

Java (com.azure.messaging.servicebus) Legen Sie beim Erstellen von Clients ServiceBusClientBuilder.transportType auf AmqpTransportType.AMQP.AMQP_WEB_SOCKETS fest.
Java (com.microsoft.azure.servicebus) Legen Sie beim Erstellen von Clients transportType in com.microsoft.azure.servicebus.ClientSettings auf com.microsoft.azure.servicebus.primitives.TransportType.AMQP_WEB_SOCKETS fest.
JavaScript Verwenden Sie beim Erstellen Service Bus-Clientobjekten die Eigenschaft webSocketOptions in ServiceBusClientOptions.
Python Legen Sie beim Erstellen von Service Bus-Clients ServiceBusClient.transport_type auf TransportType.AmqpOverWebSocket fest.

Am 30. September 2026 werden die Azure Service Bus SDK-Bibliotheken „WindowsAzure.ServiceBus“, „Microsoft.Azure.ServiceBus“ und „com.microsoft.azure.servicebus“ eingestellt, da sie nicht den Azure SDK-Richtlinien entsprechen. Außerdem wird die Unterstützung des SBMP-Protokolls beendet, sodass Sie dieses Protokoll nach dem 30. September 2026 nicht mehr verwenden können. Migrieren Sie vor diesem Datum zu den neuesten Azure SDK-Bibliotheken, die wichtige Sicherheitsupdates und verbesserte Funktionen bieten.

Obwohl die älteren Bibliotheken noch über den 30. September 2026 hinaus verwendet werden können, erhalten sie keinen offiziellen Support und keine Updates mehr von Microsoft. Weitere Informationen finden Sie in der Ankündigung der Supporteinstellung.

Außerdem können Sie Service Bus von einem beliebigen AMQP 1.0-kompatiblen Protokollstapel aus verwenden:

Sprache Bibliothek
Java Apache Qpid Proton-J
C/C++ Azure uAMQP C, Apache Qpid Proton-C
Python Azure uAMQP für Python, Apache Qpid Proton Python)
PHP Azure uAMQP für PHP
Ruby Apache Qpid Proton Ruby
Go Azure Go AMQP, Apache Qpid Proton Go
C#/F#/VB AMQP .NET Lite, Apache NMS AMQP
JavaScript/Node Rhea

Zusammenfassung

  • AMQP 1.0 ist ein offenes, zuverlässiges Messagingprotokoll, mit dem Sie plattformübergreifende Hybridanwendungen erstellen können. AMQP 1.0 ist ein OASIS-Standard.

Nächste Schritte

Möchten Sie mehr erfahren? Nutzen Sie die folgenden Links: