De nombreuses entreprises sont tous les jours confrontés aux problèmes d’intégration. Les applications doivent en permanence échanger des informations en temps réel : un site de e-commerce transmet une commande à un système de paiement, une banque valide une transaction avant de répondre au client, une plateforme de streaming envoie une confirmation d’abonnement après un clic. Dans de nombreuses situations, un acquittement technique doit être envoyé pour indiquer la prise en charge d’une demande en attendant le traitement effectif. Cet acquittement technique envoyé instantanément à la réception de la demande rend de facto l’échangé à la fois ordonné et synchrone.
Pour coordonner ces échanges, il existe des mécanismes de messagerie qui garantissent que les données circulent de façon fiable et ordonnée. Parmi ces mécanismes, JMS (Java Message Service) est un standard largement utilisé dans les grandes entreprises.
Avec TIBCO BusinessWorks (BW5 et BW6), les développeurs disposent de nombreuses activités prêtes à l’emploi pour construire des scénarios de communication synchrone (je pose une question et j’attends la réponse) ou asynchrone (j’envoie une information sans attendre de retour immédiat).
Dans cet article, nous allons nous concentrer sur les flux JMS synchrones, qui permettent de mettre en place des échanges synchrones entre deux applications : un émetteur envoie une requête, un récepteur la traite, puis répond. Vous allez découvrir 3 scénarios possibles dans TIBCO BW5 et dans quels contextes vous pouvez les utiliser.
Introduction
lorsque vous mettez en place une architecture d’intégration d’applications d’entreprise, les échanges de données doivent être fiables, rapides et sécurisés. Le standard JMS (Java Message Service) est l’un des piliers de cette communication asynchrone et synchrone.
Avec TIBCO ActiveMatrix BusinessWorks 5 (BW5), plusieurs activités JMS sont disponibles pour implémenter facilement des scénarios de Request/Reply (synchrone) ou de Publish/Subscribe (asynchrone).
Dans cet article, nous allons explorer en détail les activités :
- JMS Queue Sender
- JMS Queue Requestor
- Get JMS Queue Message
- Wait for JMS Queue Message
- Reply To JMS Message
et voir comment les combiner pour créer des flux JMS synchrones performants.
Les principales activités JMS dans TIBCO BW5
Avant de voir différents patterns, rappelons le rôle des principales activités JMS dans BW5 :
- JMS Queue Sender : envoie un message dans une file JMS.
- JMS Queue Requestor : envoie un message et attend la réponse (pattern synchrone standard).
- Get JMS Queue Message : récupère un message d’une file via polling, avec possibilité de Message Selector.
- Wait for JMS Queue Message : attend passivement un message spécifique, corrélé via une clé.
- Reply To JMS Message : envoie la réponse vers la destination spécifiée dans JMSReplyTo.
Les flux JMS synchrones en TIBCO BW5
Un flux synchrone correspond à un échange request/reply :
- Le client envoie une requête.
- Le serveur la traite.
- Une réponse est renvoyée au client qui reste bloqué en attente.
Sur TIBCO BW5, au moins trois combinaisons sont possibles pour implémenter ce modèle.
JMS Queue Requestor / JMS Queue Receiver + Reply To JMS Message
- Émetteur : JMS Queue Requestor publie dans une RequestQueue et attend la réponse sur une queue temporaire (TempQueue).
- Récepteur : lit la RequestQueue, traite le message et utilise l’activité Reply To JMS Message pour renvoyer la réponse dans une queue temporaire créé lors de l’envoi du message. Cette queue est créée automatiquement et gérée par TIBCO ESB.
- Gestion des files : une seule file d’envoi et des files temporaires pour la réception des messages de réponse.
Avantages : simple, fiable, pas de Message Selector nécessaire. La corrélation entre les messages est automatiquement gérée par TIBCO à condition de ne pas utiliser le champs replyToDestination. A la place il faut laisser TIBCO générer et gérer la queue de retour pour chaque traitement.
Limites : peu flexible (la queue de réponse est imposée par le mécanisme JMS, même si finalement transparente pour les participants). Elle peut être modifiée, mais le mécanisme synchrone va fonctionner correctement uniquement si le replyToDestination utilise une queue unique pour chaque job. Raison pour la quelle c’est plus simple de laisser TIBCO utiliser les files temporaires.
Mise en œuvre
Dans le processus producteur, il faut ajouter une activité « JMS Queue Requestor » avec une configuration minimale. C’est à dire au niveau de la configuration des données d’entrée (Input), renseignez uniquement « destinationQueue » et « Body » avec respectivement le nom de la file JMS d’envoi de messages et le contenu à envoyer.
Dans le processus consommateur, on aura besoin d’une activité « JMS Queue Receiver » et d’une activité « Reply to JMS Message ». La première activité va lire le message envoyé par le producteur, la 2° activité va répondre au message. Tout ce que vous avez à faire c’est de renseigner le body du message à envoyer. La corrélation est gérée par les files temporaires.
Vous pouvez remarquer que l’émetteur et le récepteur partagent la même file JMS pour chaque message échangé.
Vous comprenez donc que pour chaque message envoyé, il y a une fille une fille temporaire qui est créée automatiquement pour la réception du message réponse.
Exécution de la requête.
Exécution de la réponse.
JMS Queue Sender+Wait for JMS Queue Message / JMS Queue Receiver + JMS Queue Sender
- Émetteur : envoie une requête via « JMS Queue Sender », puis attend la réponse via « Wait for JMS Queue Message » sur une ResponseQueue.
- Récepteur : lit la RequestQueue, traite et renvoie la réponse dans la ResponseQueue en recopiant le JMSCorrelationID.
- Gestion des files : une file d’envoi et une file de réponse dédiée.
Mise en œuvre
Dans le process producteur, ajouter une activité « JMS Queue Sender » avec une configuration minimale et une activité « Wait for JMS Queue Message ». Dans la première activité, configurez le nom de la file de destination, puis le corps du message (Body) à envoyer. Si vous n’utilisez pas d’identifiant personnalisé, vous n’avez besoin de configurer rien d’autre.
Si vous souhaitez utiliser un votre propre identifiant unique, vous devez configurer le JMSCorrelationID avec votre identifiant unique. C’est cet identifiant qui fera le lien entre le producteur et le consommateur.
Configurerez la 2° activité en renseignant en input la clé pour filtrer les messages. Dans l’exemple ci dessous, c’est le MessageID.
A noter que rien ne vous empêche de configurer la valeur de « key » avec votre propre identifiant de corrélation personnalisé.
Dans l’onglet « Message Event », configurez la valeur de « candidate Event Key » avec le correlationID du JMS. Cette configuration permet de faire le lien avec la valeur de « key » dans l’onglet l’input. Donc considérez que l’input c’est la clé et le « candidate event » est la valeur de la clé « key ».
Dans le process consommateur, vous avez 2 configurations possibles:
- Si vous n’avez pas personnalisé et renseigné le JMSCorrelationID, alors vous devez mapper l’entrée de JMS Queue Sender avec la valeur de JMSMessageID issue de votre JMS Queue Sender.
- Si vous avez configuré JMSCorrelationID avec un identifiant unique, alors vous devez mapper l’entrée de JMS Queue Sender avec la valeur de JMSCorrelationID issue de votre JMS Queue Sender.
Exécution de la requête
Exécution de la réponse
Avantages : permet de séparer la file des demandes de celle des réponses.
Inconvénient : Cette solution implique 4 activités JMS contrairement à la première solution où on avait besoin que de 3 activités JMS. De plus, vous devez gérer la corrélation entre les messages afin de sélectionner dans la file de réponse le message qui correspond à la requête.
JMS Queue Sender + Get JMS Queue Message / JMS Queue Receiver + JMS Queue Sender
Ce pattern est similaire au précédent, à la différence que l’activité Wait for JMS Queue Message est remplacée par Get JMS Queue Message. La configuration est également identique avec les 2 options déjà présentées. Sur l’activité Get JMS Queue Message, il faut configurer le sélecteur en input. Pas besoin d’ajouter une configuration supplémentaire dans « Message Selector ».
- Émetteur : envoie une requête via JMS Queue Sender, puis interroge la ResponseQueue avec Get JMS Queue Message et un selector sur JMSCorrelationID.
- Récepteur : consomme la RequestQueue et publie la réponse dans ResponseQueue.
Avantages : permet de séparer la file des demandes de celle des réponses.
Limites : fonctionnement par polling, moins performant dans un environnement ultra exigent en terme de temps de réponse.
Producteur
Consommateur
Comparaison des patterns JMS synchrones
| Pattern | Activités côté émetteur | Activités côté récepteur | Queue réponse | Selector | Avantages | Limites |
|---|---|---|---|---|---|---|
| Requestor ↔ ReplyTo | JMS Queue Requestor | JMS Queue Receiver+ Reply To JMS Message | queues temporaires | Non | Simple, évite les collisions | Peu flexible |
| Sender ↔ Wait for JMS Queue Message | JMS Queue Sender + Wait for JMS Queue Message | JMS Queue Queue Receiver + JMS Queue Sender | queue de requête + queue de réponse | Oui (dynamique) | Mutualisation multi-clients | Gestion d’un sélecteur |
| Sender ↔ Get JMS Queue Message | JMS Queue Sender + Get JMS Queue Message | JMS Queue Receiver + JMS Queue Sender | queue de requête + queue de réponse | Oui (dynamique) | Contrôle du timeout | Gestion d’un sélecteur |
Conclusion : choisir le bon pattern JMS
Les activités JMS de TIBCO BW5 offrent plusieurs manières de créer un échange synchrone entre différentes applications qui échangent des messages via JMS.
En fonction de votre besoin et de vos exigences, choisissez l’une des 3 solutions présentées dans ce tutoriel afin de garantir la fiabilité des vos traitements.
La maîtrise de ces patterns JMS est essentielle pour concevoir des flux robustes dans une architecture d’entreprise.
Pour aller plus loin, consultez nos autres artciles.
