messagerie Request-Response

Dans un modèle de messages de type requête-réponse, le tiers expéditeur envoie un message de requête et le tiers destinataire renvoie un message de réponse. Il existe deux exemples types de traitement requête/réponse : l'interaction entre un navigateur et un serveur Web via l'adaptateur HTTP et le traitement du service Web à l'aide de l'adaptateur SOAP (Simple Object Access Protocol). Dans BizTalk Server, les messages de demande et de réponse sont gérés de manière classique de publication/d’abonnement. Ceci est important pour savoir à quel moment vous devez ajuster les performances d'une application BizTalk, parce qu'un système nécessitant un débit élevé peut être configuré autrement qu'un système requérant une faible latence pour chaque message individuel.

Lorsqu'un message est reçu par un adaptateur de réception de type requête/réponse, BizTalk Server publie le message demandé dans la base de données MessageBox. Ce message est ensuite reçu par l'abonné approprié qui correspond, sans doute, à une orchestration liée à un port de réception. Cet abonné formule un message de réponse et le publie dans la base de données MessageBox avec les propriétés qui ont provoqué son renvoi au port de réception duquel émane la requête. Enfin, le message de réponse est recueilli par le distributeur de la requête, à savoir l'adaptateur de réception qui a soumis la requête, et est renvoyé à l'application d'appel. Le diagramme ci-dessous fournit une représentation graphique détaillée de cette procédure.

Flux de messages de type requête/réponse reçu par l'adaptateur SOAP

1. L'adaptateur SOAP soumet des messages au Gestionnaire des points de terminaison.

2. Ce gestionnaire publie le message dans la base de données MessageBox.

3. L'orchestration, qui est liée au port de réception et qui dispose donc d'un abonnement au message, reçoit celui-ci et le traite.

4. L'orchestration envoie un message de réponse qui est publié dans la base de données MessageBox.

5. Le Gestionnaire des points de terminaison reçoit le message de réponse.

6. Il renvoie la réponse à l'adaptateur SOAP.

   Les implications de ce type de comportement sur les performances risquent de ne pas être suffisamment appréciées si l'implémentation interne n'est pas comprise. À l'origine, BizTalk Server est configuré pour des scénarios de débits élevés. Toutefois, il peut aussi être configuré pour un environnement avec de faibles débits et des besoins de latence peu élevée surtout dans des scénarios de requête/réponse. Plusieurs éléments doivent être pris en considération pour ce scénario. Tout d'abord, les abonnés trouvent des messages publiés via un mécanisme d'interrogation. Si l'intervalle d'interrogation est trop grand, les interactions de type requête/réponse risquent d'avoir une latence plus élevée que celle souhaitée.

   Notez que dans ce scénario, il y a deux abonnements à remplir : l’abonnement pour le message initial et celui pour le message de réponse, ce qui augmente l’impact de cet intervalle d’interrogation. Ensuite, les adaptateurs de réception sont configurés pour insérer des messages dans la base de données MessageBox par lots de taille variable. La plupart des adaptateurs vous permettent de configurer la taille de lot via l'interface de configuration type de l'adaptateur ou via des paramètres de BizTalk Server ou du Registre. Si le lot est trop volumineux, la latence des messages individuels peut être augmentée. Pour plus d’informations sur les caractéristiques de performances de BizTalk Server, consultez Planification des performances soutenues.

Voir aussi

Architecture d’exécution