Partager via

Guide du développeur Azure Service Bus JMS 2.0

  • Article

Ce guide contient des informations détaillées pour vous aider à bien communiquer avec Azure Service Bus à l’aide de l’API Java Message Service (JMS) 2.0.

En tant que développeur Java, si vous débutez avec Azure Service Bus, lisez les articles suivants.

Bien démarrer Concepts

Modèle de programmation JMS (Java Message Service)

Le modèle de programmation de l’API Java Message Service est illustré dans les sections suivantes :

Remarque

Le niveau Premium d’Azure Service Bus prend en charge JMS 1.1 et JMS 2.0.

Azure Service Bus niveau Standard prend en charge des fonctionnalités limitées de JMS 1.1. Pour plus d’informations, consultez cette documentation.

JMS : blocs de construction

Les blocs de construction ci-dessous sont disponibles pour communiquer avec l’application JMS.

Notes

Le guide ci-dessous est basé sur le Tutoriel Oracle Java EE 6 pour Java Message Service (JMS)

Nous vous recommandons de vous référer à ce tutoriel pour mieux comprendre le service JMS (Java Message Service).

Fabrique de connexion

L’objet de fabrique de connexion est utilisé par le client pour se connecter au fournisseur JMS. La fabrique de connexion encapsule un ensemble de paramètres de configuration de la connexion définis par l’administrateur.

Chaque fabrique de connexion est une instance de l’interface ConnectionFactory, QueueConnectionFactory ou TopicConnectionFactory.

Pour simplifier la connexion avec Azure Service Bus, ces interfaces sont implémentées respectivement par ServiceBusJmsConnectionFactory, ServiceBusJmsQueueConnectionFactory ou ServiceBusJmsTopicConnectionFactory.

Important

Les applications Java utilisant l’API JMS 2.0 peuvent se connecter à Azure Service Bus au moyen de la chaîne de connexion ou d’un TokenCredential pour tirer parti de l’authentification adossée à Microsoft Entra. Lorsque vous utilisez l’authentification adossée à Microsoft Entra, assurez-vous d’attribuer des rôles et des autorisations à l’identité au besoin.

Créez une identité managée affectée par le système dans Azure et utilisez-la pour créer un TokenCredential.

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

La fabrique de connexion peut ensuite être instanciée avec les paramètres ci-dessous.

  • Informations d’identification du jeton : Cela représente une information d’identification capable de fournir un jeton OAuth.
  • Host : le nom d’hôte de l’espace de noms Azure Service Bus niveau Premium.
  • Jeu de propriétés ServiceBusJmsConnectionFactorySettings comprenant
    • connectionIdleTimeoutMS : délai d’expiration de connexion inactive en millisecondes.
    • traceFrames : indicateur booléen permettant de collecter des frames de trace de protocole AMQP pour le débogage.
    • Autres paramètres de configuration

La fabrique peut être créée comme indiqué ci-après. Les informations d’identification du jeton et l’hôte sont des paramètres obligatoires, tandis que les autres propriétés sont facultatives.

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

Destination JMS

Une destination est l’objet qu’un client utilise pour spécifier la cible des messages qu’il génère et la source des messages qu’il consomme.

Les destinations sont mappées vers les entités dans les files d’attente (dans les scénarios point à point) et les rubriques (dans les scénarios publication-abonnement) d’Azure Service Bus.

Connexions

Une connexion encapsule une connexion virtuelle avec un fournisseur JMS. Avec Azure Service Bus, cela représente une connexion avec état entre l’application et Azure Service Bus par AMQP.

Une connexion est créée à partir de la fabrique de connexion comme indiqué dans l’exemple suivant :

Connection connection = factory.createConnection();

Sessions

Une session est un contexte à thread unique pour la production et la consommation de messages. La session peut être utilisée pour créer des messages, des producteurs et des consommateurs de messages, mais elle fournit également un contexte transactionnel pour permettre le regroupement d’envois et les réceptions dans une unité de travail atomique.

Une session peut être créée depuis l’objet de connexion comme indiqué dans l’exemple suivant :

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

Remarque

L’API JMS ne prend pas en charge la réception de messages à partir de files d’attente ou de rubriques Service Bus ayant des sessions de messagerie activées.

Modes de session

Une session peut être créée avec l’un des modes ci-dessous.

Modes de session Comportement
Session.AUTO_ACKNOWLEDGE Cette session accuse automatiquement réception d’un message par un client quand la session a été retournée avec succès à partir d’un appel pour recevoir ou quand l’écouteur de message que la session a appelé pour traiter le message est retourné avec succès.
Session.CLIENT_ACKNOWLEDGE Le client accuse réception d’un message consommé en appelant la méthode d’accusé de réception du message.
Session.DUPS_OK_ACKNOWLEDGE Ce mode d’accusé de réception demande à la session d’accuser réception de la remise des messages en différé.
Session.SESSION_TRANSACTED Cette valeur peut être passée en tant qu’argument à la méthode createSession(int sessionMode) sur l’objet de connexion pour spécifier que la session doit utiliser une transaction locale.

Quand le mode de session n’est pas spécifié, Session.AUTO_ACKNOWLEDGE est la valeur sélectionnée par défaut.

JMSContext

Notes

JMSContext est défini dans le cadre de la spécification JMS 2.0.

JMSContext combine les fonctionnalités fournies par l’objet de connexion et de session. Il peut être créé à partir de l’objet de fabrique de connexion.

JMSContext context = connectionFactory.createContext();

Modes JMSContext

Tout comme l’objet Session, JMSContext peut être créé avec les mêmes modes d’accusation de réception que ceux indiqués dans les Modes de session.

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

Quand le mode n’est pas spécifié, JMSContext.AUTO_ACKNOWLEDGE est la valeur sélectionnée par défaut.

Producteurs de messages JMS

Un producteur de messages est un objet créé à l’aide de JMSContext ou d’une session et utilisé pour envoyer des messages à une destination.

Elle peut être créée en tant qu’objet autonome comme indiqué dans l’exemple suivant :

JMSProducer producer = context.createProducer();

Ou créée au moment de l’exécution quand un message doit être envoyé.

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

Consommateurs de messages JMS

Un consommateur de messages est un objet créé par JMSContext ou une session et utilisé pour recevoir des messages envoyés à une destination. Elle peut être créée comme indiqué dans cet exemple :

JMSConsumer consumer = context.createConsumer(dest);

Réceptions synchrones via la méthode receive()

Le consommateur de messages fournit un moyen synchrone de recevoir des messages à partir de la destination via la méthode receive().

Si aucun argument/délai d’expiration n’est spécifié ou si un délai d’attente de « 0 » est spécifié, le consommateur se bloque indéfiniment sauf si le message arrive ou si la connexion est interrompue (selon ce qui se produit en premier).

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

Quand un argument positif différent de zéro est fourni, le consommateur se bloque jusqu’à ce que le retardateur expire.

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

Réceptions asynchrones avec les écouteurs de messages JMS

Un écouteur de messages est un objet utilisé pour la gestion asynchrone des messages sur une destination. Cela implémente l’interface MessageListener qui contient la méthode onMessage dans laquelle la logique métier spécifique doit se trouver.

Un objet écouteur de message doit être instancié et inscrit auprès d’un consommateur de messages spécifique à l’aide de la méthode setMessageListener.

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

Utilisation à partir de rubriques

Les consommateurs de messages JMS sont créés par rapport à une destination pouvant être une file d’attente ou une rubrique.

Les consommateurs sur les files d’attente sont simplement des objets côté client qui se trouvent dans le contexte de la session (et de la connexion) entre l’application cliente et Azure Service Bus.

En revanche, les consommateurs sur les rubriques ont 2 parties :

  • Un objet côté client qui réside dans le contexte de la session (ou JMSContext) et
  • Un abonnement qui est une entité sur Azure Service Bus.

Les abonnements sont documentés ici et peuvent figurer parmi les suivants :

  • Abonnements durables partagés
  • Abonnements non durables partagés
  • Abonnements durables non partagés
  • Abonnements non durables non partagés

Explorateurs de files d’attente JMS

L’API JMS fournit un objet QueueBrowser qui permet à l’application de parcourir les messages de la file d’attente et d’afficher les valeurs d’en-tête pour chaque message.

Un explorateur de file d’attente peut être créé à l’aide du JMSContext comme dans l’exemple suivant :

QueueBrowser browser = context.createBrowser(queue);

Remarque

L’API JMS ne fournit pas d’API permettant de parcourir une rubrique.

Cela est dû au fait que la rubrique elle-même ne stocke pas les messages. Dès que le message est envoyé à la rubrique, il est transféré aux abonnements appropriés.

Sélecteurs de messages JMS

Les sélecteurs de messages peuvent être utilisés par les applications réceptrices pour filtrer les messages reçus. Avec les sélecteurs de message, l’application de réception décharge la tâche de filtrage des messages au fournisseur JMS (dans ce cas, Azure Service Bus) au lieu de s’en charger elle-même.

Les sélecteurs peuvent être utilisés lors de la création de l’un des consommateurs ci-dessous :

  • Abonnement durable partagé
  • Abonnement durable non partagé
  • Abonnement non durable partagé
  • Abonnement non durable non partagé
  • Explorateur de files d’attente

Mappage entre une disposition AMQP et une opération Service Bus

Voici comment une disposition AMQP se traduit par une opération Service Bus :

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()

Résumé

Ce guide du développeur vous a présenté les différentes connexions possibles entre Azure Service Bus et les applications clientes Java utilisant Java Message Service (JMS).

Étapes suivantes

Pour obtenir plus d’informations sur Azure Service Bus et de détails sur les entités JMS (Java Message Service), consultez les articles suivants :