Ordre des messages
L'ordre des messages est important pour certaines applications de messagerie asynchrone ; en d'autres mots, il est vital d'utiliser les messages dans l'ordre dans lequel le fournisseur les envoie. Si ce type d'ordre est important pour votre application, vous devez en tenir compte lors de sa conception.
Par exemple, une application de messagerie qui traite les réservations de sièges peut être dotée de composants fournisseur et de composants destinataire. Un composant fournisseur envoie un message au composant destinataire lorsqu'une réservation est faite par un client. En cas d'annulation de la réservation, le fournisseur (ou un fournisseur différent) envoie un second message. En général, le composant destinataire doit traiter le premier message (celui de la réservation) avant de traiter le second message (celui qui annule la réservation).
Certaines applications utilisent un modèle synchrone (requête-réponse) où le fournisseur attend la réponse à un message avant d'envoyer le message qui suit. Dans ce type d'application, le destinataire contrôle l'ordre dans lequel il reçoit les messages et peut s'assurer qu'il s'agit du même ordre que celui utilisé par le ou les fournisseurs pour l'envoi. Les autres applications utilisent un modèle asynchrone (déclencher et oublier) où le fournisseur envoie des messages sans attendre de réponses. L'ordre est généralement conservé, même pour ce type d'application. En d'autres termes, un destinataire peut recevoir des messages dans l'ordre dans lequel le ou les fournisseurs les envoient, notamment lorsqu'il y a un délai d'attente important entre l'envoi des messages consécutifs. Lorsque vous concevez ce type d'application, vous devez toutefois tenir compte des facteurs qui peuvent perturber cet ordre.
L'ordre des messages est perturbé si votre application envoie des messages ayant des priorités différentes (les messages à priorité élevée peuvent surclasser ceux dont la priorité est plus faible) ou si votre application reçoit de manière explicite un message autre que le premier en indiquant des sélecteurs de messages. Le traitement parallèle et le traitement des erreurs ou des exceptions peuvent également avoir un impact sur l'ordre des messages.
Traitement parallèle
- Destinations multiples
- Lorsqu'un fournisseur envoie un message à une destination, puis envoie un deuxième message à une autre destination, il est possible que le second message arrive à destination avant le premier message. Ceci peut se produire si le fournisseur envoie les deux messages lors de la même transaction (la transaction garantit l'échec ou la réussite des deux envois ; elle ne garantit pas l'ordre de distribution). Si cela s'avère être un problème pour votre application, évitez d'utiliser plusieurs destinations.
- Plusieurs fournisseurs
- Lorsqu'un fournisseur envoie un message à une destination et qu'un autre fournisseur envoie un deuxième message à cette même destination, il est possible que le second message arrive à destination avant le premier message. Ceci peut se produire même si le deuxième fournisseur est synchronisé avec le premier, par exemple, s'il attend un signal du premier fournisseur avant d'envoyer son message (le second message). Ceci se produit également même si les fournisseurs sont transactionnels (une transaction complétée ne signifie pas que les messages arrivent à destination ; l'intégration de services peut d'abord compléter une transaction, puis distribuer les messages ultérieurement). Si cela s'avère être un problème pour votre application, évitez d'utiliser plusieurs fournisseurs. De même, évitez d'utiliser un seul fournisseur qui exécute plusieurs unités d'exécution parallèles.
- Plusieurs destinataires
- Lorsque deux messages arrivent à une destination de type file d'attente sur laquelle il existe plusieurs destinataires, il est possible qu'un destinataire reçoive le premier message et qu'un autre reçoive le second. Si les destinataires sont exécutés en parallèle, le destinataire qui reçoit le second message peut le traiter avant le destinataire qui reçoit le premier message. De plus, si un destinataire reçoit un message à l'aide d'une transaction puis annule cette transaction, le message est renvoyé à un autre destinataire ; pendant ce temps, cet autre destinataire peut avoir reçu et traité d'autres messages (messages envoyés ultérieurement). Si l'une de ces conditions s'avère être un problème pour votre application, évitez d'utiliser plusieurs destinataires. De même, n'autorisez pas plusieurs appels de beans gérés par message simultanés par noeud final (voir Configuration de la régulation de bean géré par message pour le fournisseur de messagerie par défaut). Vous pouvez également envisager l'utilisation d'un ordre strict des messages, voir Maintien d'un ordre strict des messages pour les destinations de bus.
- Mise en cluster et destinations partitionnées
- Lorsqu'une destination de type file d'attente est affectée à un membre de bus de cluster doté de plusieurs moteurs de messagerie, chacun de ces moteurs contient une partition de la destination (c'est-à-dire, un des points de file d'attente de la destination) ; l'intégration de services peut distribuer différents messages à plusieurs partitions pour cette destination. Bien que cette configuration puisse fournir une disponibilité, une évolutivité et un équilibrage de charge avancés, elle n'est généralement pas appropriée pour les applications où l'ordre des messages est important. L'intégration de services ne garantit pas l'ordre des messages envoyés aux diverses partitions d'une destination. De même, un moteur de messagerie peut échouer alors qu'il existe des messages sur la partition de la destination qu'il contient ; ces messages ne sont pas disponibles pour les destinataires jusqu'au redémarrage du moteur de messagerie. L'intégration de services peut toutefois poursuivre la distribution des messages plus récents sur d'autres partitions (dans des moteurs de messagerie différents) et les destinataires peuvent recevoir et traiter ces messages avant les messages plus anciens sur la partition du moteur de messagerie ayant échoué. Partage de la charge de travail avec les destinations de file d'attente fournit plus d'informations sur ce type de configuration et explique également comment utiliser l'option d'affinité des messages pour conserver l'ordre des messages entre un fournisseur et un destinataire d'un cluster (ne s'applique pas si le cluster se trouve sur un autre bus d'intégration de services).
- Publication et abonnement
- En ce qu'il s'agit de la messagerie de publication/d'abonnement, l'intégration de services ne garantit pas l'ordre des messages reçus par les différentes instances d'un abonnement, y compris les diverses instances d'un abonnement durable créé avec la propriété Partager les abonnements durables définie de sorte à autoriser le partage.
Erreurs et conditions d'exception
- Qualité de service
- La qualité de service d'un message détermine comment les erreurs et les conditions d'exception peuvent affecter la distribution du message (voir Niveaux de fiabilité des messages - Mode de livraison JMS et qualité de service de l'intégration de services. En fonction de la qualité de service, une erreur ou une condition d'exception peut faire que l'intégration de services distribue le message de manière fiable (une fois) ou de manière moins fiable (plusieurs fois ou jamais). Par exemple, avec la qualité de service de type rapide non persistante, il est possible que les séquences de messages soient distribuées à nouveau après un échec ; cependant, leur ordre sous-jacent est maintenu de sorte à ce que les messages arrivent dans la séquence : 1, 2, 3, 2, 3, 4. L'intégration de services ne garantit pas l'ordre des divers messages envoyés avec différentes qualités de service. Si cela s'avère être un problème pour votre application, sélectionnez une qualité de service appropriée et évitez d'utiliser plusieurs qualités de service pour les messages envoyés à la même destination.
- Destinations d'exception
- Dans certains scénarios d'échec, l'intégration de services peut distribuer un message à une destination d'exception ou distribuer un message à une destination, puis transférer ce message à une destination d'exception. L'intégration de services ne garantit pas l'ordre des messages qu'il envoie ou transfère vers une destination d'exception. Si cela s'avère être un problème pour votre application, vous pouvez configurer la destination pour ne pas avoir à utiliser une destination d'exception (voir Destinations d'exception). Si le fournisseur et la destination se trouvent dans des bus différents, vous pouvez configurer la ou les liaisons entre ces bus pour ne disposer d'aucune destination d'exception (voir Bus externes et Configuration d'un traitement de destination d'exception pour une liaison à un bus externe.
- Annulation d'une transaction
- La spécification d'activation d'un bean géré par message peut indiquer un délai entre les nouvelles tentatives des messages qui ont échoué. Ce délai permet la reprise de la condition ayant causé l'annulation avant que le même message ne dirige le bean géré par message à nouveau. Toutefois, alors qu'un message est retardé de la sorte, un autre message (ultérieur) peut diriger le bean géré par message (voirProtection d'une application MDB à partir d'incidents de ressource système). Si cela s'avère être un problème pour votre application, limitez le nombre maximal d'échecs séquentiels à un (voir Spécification d'activation JMS [Paramètres]) ou utilisez l'option d'ordre strict des messages, (voir Maintien d'un ordre strict des messages pour les destinations de bus).
- Résolution de transactions en attente de validation
- Au cours de la validation en deux étapes, une application peut être être défaillante lorsqu'une opération d'envoi ou de réception JMS est en attente. Dans ce cas, l'application peut redémarrer avant la résolution de l'état d'attente pour qu'un ou plusieurs messages soient "invisibles" lorsque l'application redémarre et soient "visibles" plus tard. Les autres messages de cette destination ne sont pas affectés. Une application consommatrice peut recevoir un message (message 2, par exemple) qui se trouve logiquement après un message "invisible" (message 1, par exemple). Ensuite, une fois la transaction en attente résolue, l'application reçoit le message qui était "invisible" (message 1). De cette façon, l'application peut recevoir et traiter les messages dans un ordre incorrect. Si cela s'avère être un problème pour votre application, utilisez utilisez l'option d'ordre strict des messages, voir Maintien d'un ordre strict des messages pour les destinations de bus.