Scénarios de routage

Article
02/24/2025

Bien que le service de routage soit hautement personnalisable, il peut être difficile de concevoir une logique de routage efficace lors de la création d’une nouvelle configuration à partir de zéro. Toutefois, il existe plusieurs scénarios courants que la plupart des configurations de service de routage suivent. Bien que ces scénarios ne s’appliquent pas directement à votre configuration spécifique, comprendre comment le service de routage peut être configuré pour gérer ces scénarios vous aidera à comprendre le service de routage.

Scénarios courants

L’utilisation la plus simple du service de routage consiste à agréger plusieurs points de terminaison de destination pour réduire le nombre de points de terminaison exposés aux applications clientes, puis utiliser des filtres de messages pour acheminer chaque message vers la destination correcte. Les messages peuvent être routés en fonction des exigences de traitement logique ou physique, telles qu’un type de message qui doit être traité par un service spécifique, ou en fonction de besoins métier arbitraires tels que le traitement prioritaire des messages à partir d’une source spécifique. Le tableau suivant répertorie certains des scénarios courants et quand ils sont rencontrés :

Scénario	Utiliser quand
Contrôle de version du service	Vous devez prendre en charge plusieurs versions d’un service ou déployer un service mis à jour à l’avenir
Partitionnement des données de service	Vous devez partitionner un service sur plusieurs hôtes
Mise à jour dynamique	Vous devez reconfigurer dynamiquement la logique de routage au moment de l’exécution pour gérer la modification des déploiements de service
Multidiffusion	Vous devez envoyer un message à plusieurs points de terminaison
Passerelle de protocole	Vous recevez des messages sur un protocole de transport, et le point de terminaison de destination utilise un autre protocole
Gestion des erreurs	Vous devez fournir une résilience aux pannes réseau et aux défaillances de communication

Note

Bien que la plupart des scénarios présentés soient spécifiques à certains besoins métier ou exigences de traitement, la planification de la prise en charge des mises à jour dynamiques et de l’utilisation de la gestion des erreurs peut souvent être considérée comme des meilleures pratiques, car elles vous permettent de modifier la logique de routage au moment de l’exécution et de récupérer à partir de défaillances de réseau et de communication temporaires.

Contrôle de version du service

Lors de l’introduction d’une nouvelle version d’un service, vous devez souvent conserver la version précédente jusqu’à ce que tous les clients aient passé au nouveau service. Cela est particulièrement essentiel si le service est un processus de longue durée qui prend des jours, des semaines ou même des mois à se terminer. Cela nécessite généralement l’implémentation d’une nouvelle adresse de point de terminaison pour le nouveau service tout en conservant le point de terminaison d’origine pour la version précédente.

En utilisant le service de routage, vous pouvez exposer un point de terminaison pour recevoir des messages des applications clientes, puis router chaque message vers la version de service correcte en fonction du contenu du message. L’implémentation la plus simple implique l’ajout d’un en-tête personnalisé au message qui indique la version du service par laquelle le message doit être traité. Le service de routage peut utiliser XPathMessageFilter pour inspecter chaque message pour la présence de l’en-tête personnalisé et acheminer le message vers le point de terminaison de destination approprié.

Pour connaître les étapes utilisées pour créer une configuration de contrôle de version de service, consultez How To : Service Versioning.

Partitionnement des données de service

Lors de la conception d’un environnement distribué, il est souvent souhaitable de répartir la charge de traitement sur plusieurs ordinateurs afin de fournir une haute disponibilité, de réduire la charge de traitement sur des ordinateurs individuels ou de fournir des ressources dédiées pour un sous-ensemble spécifique de messages. Bien que le service de routage ne remplace pas une solution d’équilibrage de charge dédiée, sa capacité à effectuer un routage basé sur le contenu peut être utilisée pour acheminer des messages similaires à des destinations spécifiques. Par exemple, vous pouvez avoir besoin de traiter les messages d’un client spécifique séparément des messages reçus d’autres clients.

Pour connaître les étapes utilisées pour créer une configuration de partitionnement de données de service, consultez Guide pratique pour le partitionnement des données de service.

Routage dynamique

Il est souvent souhaitable de modifier la configuration de routage pour répondre aux besoins métier changeants, comme l’ajout d’un itinéraire à une version plus récente d’un service, la modification des critères de routage ou la modification du point de terminaison de destination un message spécifique vers lequel le filtre est acheminé. Le service de routage vous permet de procéder via l'RoutingExtension, ce qui vous permet de fournir une nouvelle configuration de routage à l'exécution. La nouvelle configuration prend effet immédiatement, mais affecte uniquement les nouvelles sessions traitées par le service de routage.

Pour connaître les étapes utilisées pour implémenter le routage dynamique, consultez Guide pratique pour mettre à jour dynamique.

Multidiffusion

Lors du routage des messages, vous acheminez généralement chaque message vers un point de terminaison de destination spécifique. Toutefois, vous devrez peut-être parfois acheminer une copie du message vers plusieurs points de terminaison de destination. Pour effectuer un routage multidiffusion, les conditions suivantes doivent être remplies :

La forme de canal ne doit pas être requête-réponse (bien qu'il puisse être unidirectionnel ou duplexe), car cela impose qu'une seule réponse puisse être reçue par l'application cliente en réponse à la demande.
Plusieurs filtres doivent retourner vrai lors de l’évaluation du message.

Si ces conditions sont remplies, chaque point de terminaison de destination associé à un filtre qui retourne true reçoit une copie du message.

Passerelle de protocole

Lors du routage des messages entre protocoles SOAP dissimilar, le service de routage utilise des API WCF pour convertir le message d’un protocole à l’autre. Cela se produit automatiquement lorsque les points de terminaison de service exposés par le service de routage utilisent un protocole différent de celui utilisé par le ou les points de terminaison clients vers lesquels les messages sont acheminés. Il est possible de désactiver ce comportement si les protocoles en cours d’utilisation ne sont pas standard ; toutefois, vous devez ensuite fournir votre propre code de pontage.

Gestion des erreurs

Dans un environnement distribué, il n’est pas rare de rencontrer des échecs de réseau ou de communication temporaires. Sans service intermédiaire tel que le service de routage, le fardeau de la gestion de ces défaillances se situe sur l’application cliente. Si l’application cliente n’inclut pas de logique spécifique pour réessayer en cas d’échecs réseau ou de communication et de connaissance d’autres emplacements, l’utilisateur peut rencontrer des scénarios où un message doit être envoyé plusieurs fois avant qu’il ne soit traité par le service de destination. Cela peut entraîner l’insatisfaction des clients avec l’application, car elle peut être perçue comme non fiable.

Le service de routage tente de remédier à ce scénario en fournissant des fonctionnalités robustes de gestion des erreurs pour les messages qui rencontrent des échecs liés au réseau ou aux communications. En créant une liste des points de terminaison de destination possibles et en associant cette liste à chaque filtre de messages, vous supprimez le point de défaillance unique encouru en n’ayant qu’une seule destination possible. En cas d’échec, le service de routage tente de remettre le message au point de terminaison suivant dans la liste tant que le message n’a pas été remis, qu’un échec de non-communication se produit ou que tous les points de terminaison ont été épuisés.

Pour connaître les étapes utilisées pour configurer la gestion des erreurs, consultez Guide pratique pour gérer les erreurs.