Azure Service Bus vereinfacht Messagingszenarien in Unternehmen, indem es die vertraute Semantik von Warteschlangen- und Themenabonnements über das branchenweite AMQP-Protokoll (Advanced Message Queueing Protocol) nutzt. Kunden profitieren von einem vollständig verwalteten PaaS-Angebot (Platform as a Service) mit weitreichenden Integrationen in Azure-Dienste, die einen Messaging-Broker mit hohem Durchsatz, zuverlässige Latenz bei gleichzeitig hoher Verfügbarkeit, sicheres Design und Skalierbarkeit für ein erstklassiges Erlebnis bieten. Unser Ziel ist es, Azure Service Bus für Kundenworkloads auf den meisten Anwendungsstapeln und Ökosystemen anzubieten.

Passend zu unserer Vision geben wir heute die Preview für Java Message Service (JMS) 2.0 over AMQP in Azure Service Bus Premium Tier bekannt. Damit versetzen wir unsere Kunden in die Lage, mit ihren Java- und Spring-Workloads nahtlos auf Azure umzusteigen. Gleichzeitig helfen wir ihnen, ihren Anwendungsstapel mit „Best-in-Class“-Unternehmensmessaging in der Cloud zu modernisieren.

Wenn Unternehmenskunden ihre Workloads nach Azure verlagern möchten, können sie bei dieser Gelegenheit auch ihre Anwendungsstapel unter Nutzung cloudnativer Azure-Angebote modernisieren. Diese Methode eignet sich vor allem für Komponenten auf der Datenebene, durch die Daten gespeichert oder verschoben werden. Der Vorteil: Aus einem gehosteten IaaS-Setup (Infrastructure as a Service) wird ein eher cloudnatives PaaS-Setup.

Bei Datenbanken und Datenspeichern hat die Einrichtung standardisierter APIs und Protokolle den Weg für eine nahtlose Migration geebnet, bei der die Anwendung agnostisch gegenüber dem tatsächlichen Anbieter oder der Implementierung dieser standardisierten API ist. So können die Anwendungen mit äußerst geringen oder nur konfigurationsbedingten Codeänderungen von ihrem derzeitigen On-Premises-Anbieter zum vollständig verwalteten PaaS-Angebot von Azure wechseln und das erwartete Verhalten erzielen.

Das Unternehmensmessaging-Ökosystem war im Vergleich zum Datenökosystem bis zur letzten Standardisierung des AMQP 1.0-Protokolls im Jahr 2011 weitgehend fragmentiert. Dies führte zu einem konsistenten Verhalten aller Enterprise Message Broker, was durch die Protokollimplementierung gewährleistet wird. Dies führte jedoch noch immer nicht zu einem standardisierten API-Vertrag, wodurch die Fragmentierung im Bereich des Unternehmensmessagings weiter anhielt.

Die Java Enterprise-Community (nach Erweiterung auch Spring-Community) hat mit der Spezifikation Java Message Service (JMS 1.1 und 2.0) einige Fortschritte zur Standardisierung der API gemacht, die von Hersteller- und Verbraucheranwendungen für die Interaktion mit einem Enterprise Messaging Broker verwendet wird. Die Apache QPID-Community förderte dies durch die Implementierung der JMS-API-Spezifikation über AMQP. QPID-JMS, ob eigenständig oder als Teil des Spring JMS-Pakets, ist für die meisten Unternehmenskunden, die mit einer Vielzahl von Message-Brokern zusammenarbeiten, der De-facto-Standard der JMS-Implementierung.

Vorhandene Anwendungen mit Azure Service Bus over AMQP verbinden

Mit der Featureliste, die mit dieser Preview unterstützt wird (die volle Parität ist zum Zeitpunkt der allgemeinen Verfügbarkeit geplant), unterstützt Azure Service Bus alle Java Message Service API-Verträge, sodass Kunden ihre bestehenden Anwendungen zu Azure migrieren können, ohne die Anwendung umprogrammieren zu müssen. Im Folgenden finden Sie eine Liste der derzeit unterstützten JMS-Features:

• Warteschlangen
• Themen
• Temporäre Warteschlangen
• Temporäre Themen
• Abonnements
  • Freigegebene dauerhafte Abonnements
  • Freigegebene nicht dauerhafte Abonnements
  • Nicht freigegebene dauerhafte Abonnements
  • Nicht freigegebene nicht dauerhafte Abonnements
• QueueBrowser
• TopicBrowser
• Automatische Erstellung aller oben genannten Entitäten (sofern diese nicht bereits vorhanden sind)
• Nachrichtenselektoren
• Senden von Nachrichten mit Übermittlungsverzögerung (geplante Nachrichten)

Nahtlose Migration vom lokalen oder von IaaS gehosteten JMS-Anbietern zu Azure Service Bus

Um eine bestehende JMS-basierte Anwendung mit Azure Service Bus zu verbinden, fügen Sie einfach Azure Service Bus JMS Maven-Palet oder den Azure Service Bus-Starter für den Spring-Bootvorgang zur Datei „pom.xml“ der Anwendung hinzu, und nehmen Sie die Azure Service Bus-Verbindungszeichenfolge in die Konfigurationsparameter auf.

Wenn wie oben gezeigt nur der Code der Konfiguration geändert wird, können die Kunden ihre Geschäftslogik gegenüber dem Message Broker agnostisch halten und jede Herstellerbindung vermeiden.
  

Einfache Preisstruktur, leicht verwendbare Bereitstellungen und skalierbare Ressourcenzuordnung

Durch die Nutzung der JMS-Unterstützung von Azure Service Bus sparen Kunden jetzt den Aufwand für die Lizenzbeschaffung, da sie Enterprise Messaging Broker auf ihrer eigenen IaaS Compute-Einheit verwalten, das Kostenmanagement mit einem Festpreis pro Messagingeinheit vereinfachen und die automatische Skalierung der Bereitstellung nach oben und unten nutzen, um Schwankungen in Workloads auszugleichen.

Integration in andere Azure-Angebote zur weiteren Modernisierung von Anwendungsstapeln

Sie können die Azure Service Bus-Integration auch mit anderen Azure-Angeboten nutzen, um den Anwendungsstapel zu modernisieren und zu vereinfachen. Im Folgenden finden Sie einige Möglichkeiten.

1. Azure Logic Apps Verwenden Sie Azure Logic Apps-Connectors für Azure Service Bus, um verschiedene wichtige Geschäftsworkflows durch ein einfaches serverloses Pay-As-You-Go-Angebot mit geringem Programmieraufwand zu ersetzen.
2. Azure Functions Nutzen Sie Azure Functions-Trigger für Azure Service Bus, um kundenspezifische Anwendungen durch ein einfaches, serverloses PaaS-Angebot zu ersetzen, das nach dem Pay-as-you-go-Prinzip funktioniert.
3. Azure Monitor und Warnungen Verwenden Sie Azure Monitor und Warnungen, um die Metriken für den Azure Service Bus-Namespace, die Warteschlange, die Themen und die Abonnementebene im Blick zu behalten.
4. Azure KeyVault Nutzen Sie die Integration mit Azure KeyVault, um die Daten im Namespace mit einem vom Kunden verwalteten Schlüssel zu verschlüsseln.
5. Virtuelle Netzwerke und private Endpunkte Gewährleisten Sie unter Verwendung von VNET-Dienstendpunkten den sicheren Zugriff auf Azure Service Bus. Stellen Sie über eine Adresse, die über private Endpunkte in Ihrem privaten Netzwerk gehostet wird, eine Verbindung mit einem cloudgehosteten Dienst her.

Jetzt einsteigen

Beginnen Sie noch heute mit der Bereitstellung eines Service Bus-Namespace mit JMS-Features und der Migration Ihrer bestehenden Java- und Spring-Anwendungen von Apache ActiveMQ auf Service Bus.