Partager via

Intermediary Router

  • Article

Cet exemple montre comment implémenter un service qui fournit des fonctionnalités de routage de base utiles dans les configurations réseau dans lesquelles les services ne peuvent pas être directement accessibles par les clients. Il ne s'agit pas d'un exemple de routeur efficace, évolutif et doté d'une multitude de fonctionnalités.

ms751497.note(fr-fr,VS.90).gifRemarque :
La procédure d'installation ainsi que les instructions de génération relatives à cet exemple figurent à la fin de cette rubrique.

Dans un scénario de communication classique impliquant des intermédiaires SOAP, un message envoyé par un client traverse un ou plusieurs autres services avant d'atteindre sa destination finale, à savoir le service qui traite réellement le message et fournit une réponse, si celle-ci est attendue. Un intermédiaire SOAP effectue différentes actions sur le message qui le traverse. Par exemple, un intermédiaire de mise en cache retourne une réponse mise en cache au message, ce qui évite au service d'avoir à traiter de nouveau la demande. Un intermédiaire d'équilibrage de charge utilise un algorithme du tourniquet (round-robin) pour envoyer le message à l'un des nombreux services potentiels. Un intermédiaire de validation de schéma envoie uniquement les messages totalement conformes au protocole XSD du contrat et, éventuellement, à d'autres protocoles. L'intermédiaire développé pour cet exemple est chargé de router des messages vers un service approprié en fonction du contenu et des en-têtes du message.

Pour plus d'informations sur les messages SOAP, consultez XML Web Service Wire Formats.

Dans cet exemple, deux services d'application sont déployés pour traiter les demandes du client : un service de calculatrice et un service d'écho. Les points de terminaison d'application des services sont uniquement accessibles à partir du réseau interne. Les points de terminaison d'échange de métadonnées (MEX) du service sont accessibles publiquement. Le routeur SOAP fait partie du réseau interne et toutes les demandes de l'application provenant de l'extérieur du réseau interne doivent le traverser.

Le client a été créé en exécutant Service Model Metadata Utility Tool (Svcutil.exe) sur les deux services afin de générer deux fichiers de code (un client pour chaque service) ; un fichier de configuration tel que Svcutil.exe fusionne les informations de configuration du deuxième service dans le fichier de configuration existant créé lors de l'exécution de Svcutil.exe sur le premier service. Le langage WSDL (Web Services Description Language) fourni par chaque service contient l'adresse de l'intermédiaire SOAP au lieu de l'adresse du service réel. Cela évite au client d'avoir à modifier le fichier de configuration ou à connaître l'adresse de l'intermédiaire SOAP.

En outre, le service de routeur dans cet exemple est configuré avec deux points de terminaison : l'un qui écoute les messages codés en texte à l'aide de HTTP pour SOAP 1.2, et l'autre qui écoute les messages codés en binaire à l'aide de TCP pour SOAP 1.2. Le WSDL de chaque service d'application utilise la bonne adresse de point de terminaison sur le routeur. Le routeur inclut également des informations de routage dans la section appSettings du fichier de configuration qui contient les propriétés suivantes :

  • prefixes et namespaces : permettent de mettre à jour le XmlNamespaceManager par défaut dans WCF afin qu'il puisse résoudre les préfixes se trouvant dans les XPaths du routeur.
  • xpath et epr : permettent d'ajouter des entrées à la table de routage qui mappe XPaths à EPRs.

Le routeur utilise la classe XpathMessageFilterTable (XPathFilterTable<T>), où "T" est un EndpointAddress qui stocke les entrées de routage que l'utilisateur fournit. Lorsqu'un message est reçu, le routeur appelle la méthode MatchMultiple qui passe une instance Message et récupère un EndpointAddress auquel il transmet le message.

EchoService et CalculatorService utilisent tous deux la propriété ListenUri pour définir l'URI sur lequel le point de terminaison écoute. L'adresse fournie à l'intérieur de la déclaration de point de terminaison correspond à l'adresse du point de terminaison du routeur capable de transmettre les messages du service. Il s'agit de l'adresse qui apparaît dans le WSDL du service et de l'adresse qui correspond à l'en-tête To WS-Addressing de chaque message entrant. Toutefois, l'adresse fournie par la propriété ListenUri est l'adresse d'écoute physique réelle du point de terminaison qui est uniquement utilisée par le transport.

WCF fournit un autre comportement généralement utilisé dans des scénarios d'intermédiaire SOAP que cet exemple n'utilise pas  : le comportement de canal ClientViaBehavior. ClientViaBehavior permet aux clients de spécifier l'URI pour lequel le canal de transport doit être créé. Si un comportement de ce type existe dans la collection de comportements sur un point de terminaison client, le transport utilise l'URI qu'il fournit, tandis que toutes les autres couches du canal dans la pile utilisent le EndpointAddress fourni au moment de la construction de ChannelFactory. Ce EndpointAddress devient également l'en-tête To WS-Addressing. L'exemple de code suivant indique comment ce comportement est utilisé.

ChannelFactory<IContract> factory = new ChannelFactory<IContract>(new EndpointAddress("http://hostname/service"));
factory.Endpoint.Behaviors.Add(new ClientViaBehavior(new Uri("http://hostname/intermediary")));
IContract channel = factory.CreateChannel();

Une autre fonctionnalité WCF utilisée avec les intermédiaires SOAP est la propriété AddressFilter. AddressFilter permet à WCF d'accepter uniquement les messages qui correspondent à un filtre spécifique. Si les méthodes du contrat de service utilisent "*" comme Action, seule l'adresse est vérifiée. Cet exemple n'utilise pas cette fonctionnalité car l'adresse est toujours correcte. Le routeur accepte les messages du client car les en-têtes To correspondent à son adresse de point de terminaison, et les services acceptent les messages qui leur sont transmis car l'en-tête To correspond à l'adresse logique de leur point de terminaison.

Le fichier Contracts.cs de l'exemple définit les quatre interfaces suivantes, à raison d'une pour chaque modèle de transport :

  • ISimplexDatagramRouter. Cette interface est requise pour accepter des messages sur les canaux de datagramme simplex. Ajoutez un point de terminaison à l'aide de cette interface si vous attendez des messages sur les canaux HTTP unidirectionnels, ou les canaux TCP et NamedPipe unidirectionnels.
  • IRequestReplyDatagramRouter. Cette interface est requise pour accepter des messages sur les canaux de datagramme demande-réponse. Utilisez-la pour les messages sur un canal HTTP bidirectionnel.
  • ISimplexSessionRouter. Cette interface doit accepter des messages sur les canaux de session simplex. Utilisez-la pour les canaux TCP simplex et NamedPipe simplex.
  • IDuplexSessionRouter. Cette interface concerne les canaux de session duplex. Utilisez-la pour les canaux TCP duplex et NamedPipe duplex.

RouterBinding fournit un exemple de liaison WCF que vous pouvez créer pour prendre en charge votre intermédiaire SOAP. Il vous permet de spécifier les paramètres les plus courants requis dans ce scénario et garantit que seuls les éléments de liaison réellement nécessaires sont ajoutés. La prise en charge de configuration de base est également présentée.

Cet exemple n'utilise pas d'hébergement Web car il s'appuie sur des transports autres que HTTP. L'activation TCP est actuellement uniquement disponible sur Windows Vista et IIS 7.0.

Lorsque vous exécutez l'exemple, les demandes et réponses d'opération s'affichent dans la fenêtre de console cliente. Appuyez sur ENTER dans la fenêtre du client pour l'arrêter.

Echo("Is anyone there?") returned: Is anyone there?
Add(5) returned: 5
Add(-3) returned: 2

Pour configurer, générer et exécuter l'exemple

  1. Pour générer l'édition C#, C++ ou Visual Basic .NET de la solution, suivez les instructions indiquées dans Génération des exemples Windows Communication Foundation.

  2. Pour exécuter l'exemple dans une configuration à un ou plusieurs ordinateurs, suivez les instructions indiquées dans Exécution des exemples Windows Communication Foundation avec les exceptions suivantes.

    1. Dans les configurations à un ou plusieurs ordinateurs, quatre projets et quatre fichiers exécutables sont requis : un pour le client, un pour le routeur SOAP et un pour chaque service d'application.
    2. Dans une configuration à plusieurs ordinateurs, les modifications suivantes doivent être apportées aux quatre fichiers de configuration.
      Le fichier App.config de CalculatorService et EchoService doit être modifié en ligne 21. Le nom d'hôte réel de l'intermédiaire doit remplacer le nom d'hôte localhost.
      Le fichier App.config du routeur doit être modifié en ligne 15. Les deux adresses (séparées par '|') doivent être remplacées par le nom d'hôte de EchoService et CalculatorService, respectivement.
      Le fichier App.config du client doit être modifié en lignes 5 et 7. Le nom d'hôte réel de l'intermédiaire doit remplacer le nom d'hôte localhost.
      Vous pouvez également utiliser Service Model Metadata Utility Tool (Svcutil.exe) sur les deux services d'application (une fois ceux-ci mis à jour pour utiliser l'adresse appropriée) et régénérer les fichiers App.config.

  3. Assurez-vous que Router, EchoService et CalculatorService s'exécutent tous avant de démarrer le client. Chacun des trois services impriment les adresses de point de terminaison sur lesquelles ils écoutent au démarrage.

    ms751497.note(fr-fr,VS.90).gifRemarque :
    Le point de terminaison d'application de EchoService et CalculatorService utilise l'adresse du routeur.

  4. Exécutez le client. Le client contacte d'abord EchoService, et ensuite CalculatorService. Router imprime les actions WS-Addressing des messages qu'il transmet, dans les deux sens.

    ms751497.note(fr-fr,VS.90).gifRemarque :
    Si Client.exe et Router.exe sont sur des ordinateurs séparés, supprimez les marques de commentaire de la section <identity/> dans Client.exe.config, et affectez au nom d'utilisateur principal celui de l'utilisateur qui exécute Router.exe.

Send comments about this topic to Microsoft.
© 2007 Microsoft Corporation. All rights reserved.