Principe

Il s'agit d'un échange de messages où un message porte la question et un autre la réponse.

Ces messages sont véhiculés dans des canaux dédiés.

La mise en oeuvre de canaux permet de couper la consommation de ces messages sans perturber les systèmes mis en jeu. C'est pour une raison de flexibilité dans l'exploitation qu'il est obligatoire d'avoir 1 file de messages Reply par système (Consumer).

Schéma EIP

Vision sans Middleware

Ce pattern met en oeuvre 3 EIP:

• Request-Reply: pour les appels asynchrones avec une réponse associée
• reply channel: pour router dynamiquement la réponse vers la bonne file.
• correlation identifier: pour identifier de manière unique chaque message.

Vision avec Middleware

Il convient de prendre en compte que le Middleware (ESB, MOM, API, etc) route ces messages et virtualise les consommateurs et producteurs. Il est donc l'élément central et obligatoire.

Le pattern Smart Proxy offre le moyen de garder ces files de réponses par consommateur tout en gardant un contrôle sur les messages.

L'adresse de retour fournit au Provider est remplacée par celle du bus. La réelle vers le Consumer concernée est stockée dans l'attente de la réponse.

Les messages retour sont interceptés et transformés conformément aux rôles de l'ESB.  

Identifiant de corrélation

Un identifiant est une clée unique. Il a pour objectifs de permettre:

1. aux consommateur d'associer un ou plusieurs messages à un contexte d'exécution.
2. un suivi des messages dans plusieurs files ou plusieurs protocoles.

Celui-ci doit être positionné dans l'entête du message par l'émetteur (Consumer A et B). Les ID mis en jeu sont alors du périmètre de l'émetteur.

Il est préférable d'utiliser générateur de Message ID pour chaque Consumer.

L'ESB positionne lui aussi un ID technique de flux.