Demande JMS et messagerie de réponse avec des membres du bus de cluster

Un modèle de messagerie JMS standard implique une application demandeuse qui envoie un message à une file d'attente JMS afin qu'il soit traité par un service de messagerie tel qu'un bean géré par message.

Lorsque l'application demandeuse envoie le message de demande, ce dernier identifie une autre file d'attente JMS à laquelle le service doit envoyer un message de réponse. Après l'envoi du message de demande, l'application demandeuse attend le message de réponse ou elle se connecte plus tard pour extraire ce message.

Figure 1. Modèle de messagerie JMS standard
Modèle de messagerie JMS standard
Le modèle de demande et de réponse implique les conditions suivantes :
  • L'application demandeuse peut identifier, dans le message demandeur, la destination du message de réponse définie par le service.
  • L'application demandeuse peut consommer le message de réponse depuis l'emplacement de réponse.
Une file d'attente JMS peut faire référence à une destination de bus d'intégration de services définie dans un membre de bus du serveur ou un membre du bus du cluster.
  • Si le membre du bus est un serveur (pouvant avoir un seul moteur de messagerie) ou un cluster avec un seul moteur de messagerie, une file d'attente JMS identifie un seul point de file d'attente du bus d'intégration de services.
  • Si le membre du bus est un cluster avec plusieurs moteurs de messagerie (généralement, pour fournir le partage de charge de travail ou l'évolutivité), une file d'attente JMS identifie plusieurs points de file d'attente, un sur chaque moteur de messagerie dans le bus du membre.
Figure 2. Destination de file d'attente de bus d'intégration de services définie sur un membre de bus de serveur d'applications
Destination de file d'attente de bus d'intégration de services définie sur un membre de bus de serveur d'applications.
Le comportement suivant est effectif par défaut :
  • Le point de file d'attente auquel une application envoie des messages ou duquel elle en reçoit est déterminé par le système de messagerie.
  • Au cours de sa durée de vie, un consommateur, un consommateur de messages JMS, en l'occurrence, consomme les messages d'un seul point de file d'attente.

Ce comportement de demande et de réponse permet d'envoyer un message de réponse à un point de file d'attente différent de celui dans lequel le demandeur l'attend. Il se peut donc que le message de réponse n'arrive pas à destination.

Figure 3. Une destination de file d'attente de bus d'intégration de services est définie dans un membre du bus du cluster avec deux moteurs de messagerie
Une destination de file d'attente de bus d'intégration de services définie dans un membre de bus avec deux moteurs de messagerie.

Tenez compte des avantages et des inconvénients de chacune des options et des exigences de l'application avant de choisir une option.

Récapitulatif

Utilisez la solution la plus simple qui répond aux besoins du scénario de demande/réponse. Exemple :
  • Si des messages de réponse ne sont requis qu'à la connexion de l'application demandeuse, utilisez des messages non persistants et des files d'attente temporaires. Par ailleurs, envisagez de spécifier le paramètre timeToLive de la demande initiale, si l'application demandeuse n'attend une réponse que pendant une certaine durée.
  • Si un seul point de file d'attente (et son moteur de messagerie) peut gérer tout le trafic des messages de réponse des applications demandeuses et qu'un membre de cluster avec plusieurs moteurs de messageries est nécessaire pour un autre trafic de messagerie (les messages de demande, par exemple), utilisez une destination d'alias de bus d'intégration de services pour limiter les messages à ce point de file d'attente.

Si nécessaire, vous pouvez combiner ces options pour obtenir la solution qui répond le mieux aux besoins de votre application et dont les performances et l'évolutivité sont les meilleures.

Par exemple, si les applications demandeuses reçoivent généralement leurs messages de réponse au cours de la connexion initiale, mais que dans certains cas (par exemple, lors d'un incident) elles doivent se reconnecter pour recevoir la réponse, vous pouvez adopter l'approche suivante :
  • Activez l'option scopeToLocalQP de la file d'attente JMS et autorisez l'application demandeuse à se connecter à l'un des moteurs de messagerie du membre de bus de cluster (ciblez la fabrique de connexions JMS sur le membre de bus). Cela permet d'équilibrer la charge de travail des connexions, mais les messages de réponse sont restreints au point de file d'attente local. Les messages de réponse peuvent donc être détectés en utilisant la même connexion pour recevoir la réponse que celle utilisée pour envoyer la demande.
  • Lors de la reconnexion à la suite d'un dysfonctionnement, activez l'option de partage des messages dans la file d'attente JMS pour que le message de réponse soit reçu depuis son emplacement, quel qu'il soit.

Cette approche permet un équilibrage dynamique de la charge de travail des applications demandeuses et minimise l'impact de la collecte des messages sur les performances en réduisant son utilisation aux scénarios d'incident.


Icône indiquant le type de rubrique Rubrique de concept



Icône d'horodatage Dernière mise à jour: last_date
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=cjt0020_
Nom du fichier : cjt0020_.html