Freigeben über

Entwicklerleitfaden für Azure Service Bus JMS 2.0

  • Artikel

Dieser Leitfaden bietet detaillierte Informationen zu einer erfolgreichen Kommunikation mit Azure Service Bus über die JMS 2.0-API (Java Message Service).

Wenn Sie Java-Entwickler sind, aber mit Azure Service Bus noch nicht vertraut, sollten Sie die folgenden Artikel lesen.

Erste Schritte Konzepte

JMS-Programmiermodell (Java Message Service)

In den folgenden Abschnitten wird das Programmiermodell mit Java Message Service-API vorgestellt:

Hinweis

Der Azure Service Bus-Premium-Tarif unterstützt JMS 1.1 und JMS 2.0.

Der Azure Service Bus-Standard-Tarif unterstützt eine eingeschränkte JMS 1.1-Funktionalität. Weitere Informationen finden Sie in dieser Dokumentation.

JMS: Bausteine

Die folgenden Bausteine stehen für die Kommunikation mit der JMS-Anwendung zur Verfügung.

Hinweis

Der folgende Leitfaden wurde aus dem Oracle Java EE 6-Tutorial für Java Message Service (JMS) übernommen und angepasst.

Zum besseren Verständnis des Java Message Service (JMS) wird die Lektüre dieses Tutorials empfohlen.

Verbindungsfactory

Das Verbindungsfactoryobjekt wird vom Client zur Herstellung der Verbindung mit dem JMS-Anbieter verwendet. Die Verbindungsfactory kapselt eine Reihe von Konfigurationsparametern für die Verbindung, die vom Administrator definiert werden.

Jede Verbindungsfactory ist eine Instanz der Schnittstellen ConnectionFactory, QueueConnectionFactory oder TopicConnectionFactory.

Um die Verbindung mit Azure Service Bus zu vereinfachen, werden diese Schnittstellen durch ServiceBusJmsConnectionFactory, ServiceBusJmsQueueConnectionFactory oder ServiceBusJmsTopicConnectionFactory implementiert.

Wichtig

Java-Anwendungen, die die JMS 2.0-API nutzen, können eine Verbindung mit Azure Service Bus herstellen, indem Sie die Verbindungszeichenfolge verwenden, oder indem Sie TokenCredential verwenden, um die von Microsoft Entra unterstützte Authentifizierung zu nutzen. Wenn Sie die von Microsoft Entra unterstützte Authentifizierung verwenden, müssen Sie der Identität die erforderlichen Rollen und Berechtigungen zuweisen.

Erstellen Sie eine systemseitig zugewiesene verwaltete Identität in Azure, und verwenden Sie diese Identität zum Erstellen von TokenCredential.

TokenCredential tokenCredential = new DefaultAzureCredentialBuilder().build();

Die Verbindungsfactory kann mit den folgenden Parametern instanziiert werden.

  • Token-Anmeldeinformationen – Stellt Anmeldeinformationen dar, die ein OAuth-Token bereitstellen können.
  • Host: Der Hostname des Namespace des Azure Service Bus Premium-Tarifs.
  • ServiceBusJmsConnectionFactorySettings-Eigenschaftenbehälter, der Folgendes enthält
    • connectionIdleTimeoutMS: Timeout für Leerlaufverbindungen in Millisekunden.
    • traceFrames: Boolesches Flag zum Erfassen von AMQP-Ablaufverfolgungsframes für das Debugging.
    • andere Konfigurationsparameter

Die Factory kann wie folgt erstellt werden. Die Tokenanmeldeinformationen und der Host sind erforderliche Parameter, aber die anderen Eigenschaften sind optional.

String host = "<YourNamespaceName>.servicebus.windows.net";
ConnectionFactory factory = new ServiceBusJmsConnectionFactory(tokenCredential, host, null);

JMS-Ziel

Ein Ziel (destination) ist ein Objekt, das von einem Client verwendet wird, um das Ziel der erzeugten Nachricht und die Quelle der genutzten Nachrichten anzugeben.

Ziele sind Entitäten in Azure Service Bus zugeordnet: Warteschlangen (in Punkt-zu-Punkt-Szenarien) und Themen (in Szenarien mit dem Muster „Veröffentlichen-Abonnieren“).

Verbindungen

Eine Verbindung kapselt eine virtuelle Verbindung mit einem JMS-Anbieter. Bei Azure Service Bus stellt dies eine zustandsbehaftete Verbindung zwischen der Anwendung und Azure Service Bus über AMQP dar.

Eine Verbindung wird wie im folgenden Beispiel dargestellt anhand der Verbindungsfactory erstellt:

Connection connection = factory.createConnection();

Sitzungen

Eine Sitzung ist ein Einzelthreadkontext zum Erstellen und Nutzen von Nachrichten. Sie kann zum Erstellen von Nachrichten sowie Nachrichtenproducern und -consumern verwendet werden, bietet aber auch einen Transaktionskontext, um Sende- und Empfangsvorgänge in eine atomische Arbeitseinheit zu gruppieren.

Eine Sitzung kann wie im folgenden Beispiel dargestellt anhand dem Verbindungsobjekt erstellt werden:

Session session = connection.createSession(false, Session.CLIENT_ACKNOWLEDGE);

Hinweis

Die JMS-API unterstützt das Empfangen von Nachrichten von Service Bus-Warteschlangen oder -Themen mit aktivierten Messagingsitzungen nicht.

Sitzungsmodi

Eine Sitzung kann in einem beliebigen der folgenden Modi erstellt werden.

Sitzungsmodi Verhalten
Session.AUTO_ACKNOWLEDGE Die Sitzung bestätigt automatisch den Empfang einer Nachricht durch den Client, wenn die Sitzung erfolgreich von einem Empfangsaufruf zurückgegeben wird oder wenn der von der Sitzung zum Verarbeiten der Nachricht aufgerufene Nachrichtenlistener erfolgreich zurückgegeben wird.
Session.CLIENT_ACKNOWLEDGE Der Client bestätigt eine genutzte Nachricht durch Aufrufen der Bestätigungsmethode der Nachricht.
Session.DUPS_OK_ACKNOWLEDGE Dieser Bestätigungsmodus weist die Sitzung an, die Übermittlung von Nachrichten verzögert zu bestätigen.
Session.SESSION_TRANSACTED Dieser Wert kann als Argument an die Methode „createSession(int sessionMode)“ im Verbindungsobjekt übergeben werden, um anzugeben, dass die Sitzung eine lokale Transaktion verwenden soll.

Wenn kein Sitzungsmodus angegeben ist, wird standardmäßig Session.AUTO_ACKNOWLEDGE ausgewählt.

JMSContext

Hinweis

JMSContext ist im Rahmen der JMS 2.0-Spezifikation definiert.

JMSContext kombiniert die Funktionen von Verbindungs- und Sitzungsobjekt. Dieser Kontext kann aus dem Verbindungsfactoryobjekt erstellt werden.

JMSContext context = connectionFactory.createContext();

JMSContext-Modi

Ebenso wie das Objekt für die Sitzung kann JMSContext mit denselben Bestätigungsmodi erstellt werden, wie unter Sitzungsmodi beschrieben.

JMSContext context = connectionFactory.createContext(JMSContext.AUTO_ACKNOWLEDGE);

Wenn kein Modus angegeben ist, wird standardmäßig JMSContext.AUTO_ACKNOWLEDGE ausgewählt.

JMS-Nachrichtenproducer

Ein Nachrichtenproducer ist ein Objekt, das mithilfe eines JMSContexts oder einer Sitzung erstellt und zum Senden von Nachrichten an ein Ziel verwendet wird.

Sie kann entweder als eigenständiges Objekt wie im folgenden Beispiel erstellt werden:

JMSProducer producer = context.createProducer();

Oder alternativ zur Laufzeit, wenn eine Nachricht gesendet werden muss.

context.createProducer().send(destination, message);

JMS-Nachrichtenconsumer

Ein Nachrichtenconsumer ist ein Objekt, das durch einen JMSContext oder eine Sitzung erstellt und zum Empfangen von an ein Ziel gesendeten Nachrichten verwendet wird. Sie kann wie in diesem Beispiel dargestellt erstellt werden:

JMSConsumer consumer = context.createConsumer(dest);

Synchrone Empfangsvorgänge per receive()-Methode

Der Nachrichtenconsumer bietet eine synchrone Möglichkeit zum Empfangen von Nachrichten vom Ziel über die receive()-Methode.

Wenn keine Argumente und kein Timeout festgelegt wurden oder der Timeoutwert 0 angegeben wurde, blockiert der Consumer so lange, bis die Nachricht eintrifft oder die Verbindung getrennt wird (je nachdem, welches Ereignis früher eintritt).

Message m = consumer.receive();
Message m = consumer.receive(0);

Wenn ein positives Argument ungleich 0 angegeben wird, blockiert der Consumer so lange, bis dieser Timer abgelaufen ist.

Message m = consumer.receive(1000); // time out after one second.

Asynchrone Empfangsvorgänge mit JMS-Nachrichtenlistenern

Ein Nachrichtenlistener ist ein Objekt, das zur asynchronen Verarbeitung von Nachrichten an einem Ziel verwendet wird. Sie implementiert die MessageListener-Schnittstelle, die die onMessage-Methode enthält, in der sich die spezifische Geschäftslogik befinden muss.

Ein Nachrichtenlistenerobjekt muss mithilfe der setMessageListener-Methode für einen bestimmten Nachrichtenconsumer instanziiert und registriert werden.

Listener myListener = new Listener();
consumer.setMessageListener(myListener);

Nutzen von Themen

JMS-Nachrichten-Consumer werden für ein Ziel erstellt, bei dem es sich um eine Warteschlange oder ein Thema handeln kann.

Consumer für Warteschlangen sind einfach clientseitige Objekte, die im Kontext der Sitzung (und der Verbindung) zwischen Clientanwendung und Azure Service Bus existieren.

Consumer für Themen bestehen jedoch aus zwei Teilen:

  • Ein clientseitiges Objekt, das im Kontext der Sitzung (oder von JMSContext) existiert
  • Ein Abonnement, das eine Entität in Azure Service Bus ist

Die Abonnements sind hier dokumentiert und können in einer der nachfolgenden Formen vorliegen:

  • Freigegebene dauerhafte Abonnements
  • Freigegebene nicht dauerhafte Abonnements
  • Nicht freigegebene dauerhafte Abonnements
  • Nicht freigegebene nicht dauerhafte Abonnements

JMS-Warteschlangenbrowser

Die JMS-API stellt ein QueueBrowser-Objekt bereit, das es der Anwendung ermöglicht, die Nachrichten in der Warteschlange zu durchsuchen und die Headerwerte jeder Nachricht anzuzeigen.

Ein Warteschlangenbrowser kann wie im folgenden Beispiel dargestellt mit dem JMSContext erstellt werden:

QueueBrowser browser = context.createBrowser(queue);

Hinweis

Die JMS-API stellt keine API zum Durchsuchen eines Themas bereit.

Das liegt daran, dass das Thema selbst die Nachrichten nicht speichert. Sobald eine Nachricht an ein Thema gesendet wird, wird sie an die jeweiligen Abonnements weitergeleitet.

JMS-Nachrichtenselektoren

Nachrichtenselektoren können von empfangenden Anwendungen zum Filtern der empfangenen Nachrichten verwendet werden. Mit Nachrichtenselektoren lagert die empfangende Anwendung das Filtern von Nachrichten an den JMS-Anbieter (in diesem Fall Azure Service Bus) aus, statt die Filterung selbst durchzuführen.

Selektoren können beim Erstellen der folgenden Consumer verwendet werden:

  • Freigegebene dauerhafte Abonnements
  • Nicht freigegebene dauerhafte Abonnements
  • Freigegebene nicht dauerhafte Abonnements
  • Nicht freigegebene nicht dauerhafte Abonnements
  • Warteschlangenbrowser

AMQP-Disposition und Service Bus-Vorgangszuordnung

Hier sehen Sie die Umwandlung einer AMQP-Disposition in einen Service Bus-Vorgang:

ACCEPTED = 1; -> Complete()
REJECTED = 2; -> DeadLetter()
RELEASED = 3; (just unlock the message in service bus, will then get redelivered)
MODIFIED_FAILED = 4; -> Abandon() which increases delivery count
MODIFIED_FAILED_UNDELIVERABLE = 5; -> Defer()

Zusammenfassung

In diesem Entwicklerleitfaden wurde veranschaulicht, wie Java-Clientanwendungen, die Java Message Service (JMS) verwenden, eine Verbindung mit Azure Service Bus herstellen können.

Nächste Schritte

Weitere Informationen zu Azure Service Bus und Details zu JMS-Entitäten (Java Message Service) finden Sie unter den folgenden Artikeln: