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.

- 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.
- 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.

- 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.

- Utilisation d'une file d'attente temporaire comme file d'attente de réponse.
- Utilisation d'un alias d'intégration de services sectorisé pour limiter les messages à un seul point de file d'attente.
- Restriction des messages de réponse au point de file d'attente local pour l'application demandeuse.
- Configurez le demandeur pour consommer les messages de tous les points de file d'attente simultanément.
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
- 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.
- 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.