Partager via

Guide du développeur JMS 2.0 pour Azure Service Bus

Ce guide contient des informations détaillées pour vous aider à 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, envisagez de lire les articles suivants.

Mise en route Les concepts

Modèle de programmation Java Message Service (JMS)

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

Remarque

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

Azure Service Bus - Le niveau Standard prend en charge des fonctionnalités JMS 1.1 limitées. Pour plus d’informations, reportez-vous à cette documentation.

JMS - Blocs de construction

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

Remarque

Le guide ci-dessous a été adapté à partir du didacticiel Oracle Java EE 6 pour Java Message Service (JMS)

Il est recommandé de faire référence à ce tutoriel pour mieux comprendre le service de messages Java (JMS).

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 via ServiceBusJmsConnectionFactory, ServiceBusJmsQueueConnectionFactoryou ServiceBusJmsTopicConnectionFactory respectivement.

Important

Les applications Java utilisant l’API JMS 2.0 peuvent se connecter à Azure Service Bus en utilisant la chaîne de connexion ou en utilisant un TokenCredential pour tirer parti de l'authentification prise en charge par Microsoft Entra. Lors de l’utilisation de l’authentification sauvegardée par Microsoft Entra, veillez à attribuer des rôles et des autorisations à l’identité en fonction des besoins.

Créez une identité managée affectée par le système sur Azure et utilisez cette identité 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.
  • Hôte : nom d’hôte de l’espace de noms de niveau Premium Azure Service Bus.
  • Conteneur des propriétés ServiceBusJmsConnectionFactorySettings comprenant
    • connectionIdleTimeoutMS : délai d’inactivité de la connexion 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é ici. Les informations d’identification et l’hôte du jeton sont des paramètres requis, mais 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 produit 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();

Séances

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

Une session peut être créée à partir de l’objet de connexion, comme illustré 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 avec les 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 Connection pour spécifier que la session doit utiliser une transaction locale.

Lorsque le mode session n’est pas spécifié, le Session.AUTO_ACKNOWLEDGE est sélectionné par défaut.

JMSContext

Remarque

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

Lorsque le mode n’est pas spécifié, la JMSContext.AUTO_ACKNOWLEDGE est choisie par défaut.

Producteurs de messages JMS

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

Il peut être créé en tant qu’objet autonome comme illustré dans l’exemple suivant :

JMSProducer producer = context.createProducer();

Ou créé lors de l’exécution lorsqu’un message doit être envoyé.

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

Consommateurs de messages JMS

Un consommateur de messages est un objet créé par un JMSContext ou une session et utilisé pour recevoir des messages envoyés à une destination. Il peut être créé comme illustré 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 de la destination via la receive() méthode.

Si aucun argument/délai d’expiration n’est spécifié ou qu’un délai d’expiration de « 0 » est spécifié, le consommateur se bloque indéfiniment, sauf si le message arrive, ou si la connexion est interrompue (le cas échéant).

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

Lorsqu’un argument positif non nul est fourni, le consommateur bloque jusqu’à ce que le minuteur expire.

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

Réceptions asynchrones avec les écouteurs de messages JMS

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

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 vivent 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 :

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

Les abonnements sont documentés ici et peuvent être l’un des 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 QueueBrowser objet qui permet à l’application de parcourir les messages dans la file d’attente et d’afficher les valeurs d’en-tête pour chaque message.

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

QueueBrowser browser = context.createBrowser(queue);

Remarque

L’API JMS ne fournit pas d’API pour 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 applications de réception peuvent utiliser des sélecteurs de messages pour filtrer les messages reçus. Avec les sélecteurs de messages, l’application de réception décharge le travail de filtrage des messages vers le fournisseur JMS (dans ce cas, Azure Service Bus) au lieu de prendre cette responsabilité 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é
  • Consommateur de file d’attente
  • Navigateur de file d’attente

Remarque

Les sélecteurs Service Bus ne prennent pas en charge les mots clés SQL « LIKE » et « BETWEEN ».

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 a présenté comment les applications clientes Java utilisant Java Message Service (JMS) peuvent se connecter à Azure Service Bus.

Étapes suivantes

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