Rules-Driven WCF Router

Un routeur SOAP est un intermédiaire qui transfère des messages SOAP d'un client à un point de terminaison d'application en fonction d'un ensemble de règles. Cet exemple crée un routeur SOAP à l'aide de Windows Communication Foundation (WCF).

Remarque :
Cet exemple requiert l'installation de .NET Framework version 3.5 pour être généré et exécuté. Visual Studio 2008 est nécessaire pour l'ouverture des fichiers projet et solution.

Le routeur utilise le moteur de règles Windows Workflow Foundation (WF) afin d'implémenter la fonctionnalité de routeur principal qui indique où transférer les messages concernés. Cet exemple illustre deux procédures clés : utilisation de Windows Workflow Foundation et de WCF dans une application, et utilisation du moteur de règles Windows Workflow Foundation en dehors d'un workflow (c'est-à-dire de manière "autonome").

Remarque :
Pour connaître ces règles, consultez External RuleSet Toolkit, exemple.

Remarque :
Pour plus d'informations sur les aspects WCF du routeur, consultez la documentation relative à l'exemple WCF Intermediary Router. Cet exemple remplace la fonctionnalité de routeur dans l'exemple Intermediary Router par une fonctionnalité basée sur les règles.

L'exemple se compose de quatre projets : service de calculatrice, service d'écho, routeur et client. Dans cet exemple, les services de calculatrice et d'écho sont des services WCF standard qui sont définis, respectivement, dans les fichiers Calculator.cs et EchoService.cs.

Le service de routeur utilise l'extensibilité WCF pour traiter les messages et d'autres comportements, tels que la gestion de modèles de transport (datagramme/session, demande-réponse/duplex).

Le fichier source RouterTable.cs définit la classe qui utilise le moteur de règles WF afin de déterminer où transférer les messages reçus du client. Chaque fois qu'il reçoit un message, le routeur appelle la méthode RouterTable.SelectDestination() pour obtenir l'adresse de point de terminaison à laquelle transférer le message, en fonction de son contenu.

À ce stade, RouterTable.cs exécute le RuleSet SelectDestination figurant dans Selectdestination.Rules afin de déterminer vers quel point de terminaison (service de calculatrice ou service d'écho) transférer le message.

Pour comprendre ou modifier le RuleSet SelectDestination, vous devez l'ouvrir à l'aide de l'exemple External RuleSet Toolkit (voir External RuleSet Toolkit, exemple) figurant dans le Kit de développement logiciel du .NET Framework version 3.5.

Pour ouvrir le RuleSet SelectDestination

1. Démarrez l'application External RuleSet Toolkit, exemple.

2. Dans le menu Données, cliquez sur Importer.

3. Dans la boîte de dialogue Ouvrir un fichier, sélectionnez router\SelectDestination.rules.

4. Dans l'outil RuleSet editor, cliquez sur le RuleSet SelectDestination.

5. Dans la boîte de dialogue Workflow/Type Selection, cliquez sur Parcourir.

6. Dans la boîte de dialogue Ouvrir un fichier, accédez au dossier router/bins, puis cliquez sur WCF_Router.Router.exe.

7. Dans la section des types contenus de la boîte de dialogue Workflow/Type Selection, cliquez sur RoutingTable, puis cliquez sur OK.

8. Dans l'application de trousse à outils RuleSet externe, développez SelectDestination, cliquez sur Version 1.0, puis sur Règles de Modification.

9. Lorsqu'il est ouvert dans External RuleSet Toolkit, le RuleSet SelectDestination apparaît tel qu'il est présenté dans l'illustration suivante.

RuleSet SelectDestination de External RuleSet Toolkit

Le RuleSet SelectDestination contient six règles. Chacune de ces règles est présentée et expliquée ci-dessous par ordre décroissant d'importance.

1. Initialize variables : initialise les variables de la classe RouterTable afin que les autres règles puissent les utiliser.
2. CalculatorService : vérifie si les messages répondent aux critères de transfert vers CalculatorService (les messages doivent contenir l'en-tête "calculator"). Si tel est le cas, le point de terminaison CalculatorService est ajouté à la liste des points de terminaison vers lesquels ces messages peuvent être transférés.
3. EchoService : vérifie si les messages respectent les critères de transfert vers EchoService (les messages doivent contenir l'en-tête d'action http://microsoft.servicemodel.samples/iechoservice/echo). Si tel est le cas, le point de terminaison EchoService est ajouté à la liste des points de terminaison vers lesquels ces messages peuvent être transférés.
4. No matches : vérifie si les messages ne peuvent être transférés vers aucun point de terminaison. Si la valeur de cette règle est true, cette condition est enregistrée sur la console.
5. One match : vérifie si les messages peuvent être transférés vers un seul point de terminaison. Si la valeur de cette règle est true, les messages sont transférés vers ce point de terminaison.
6. Multiple match : vérifie si les messages peuvent être transférés vers plusieurs points de terminaison. Si la valeur de cette règle est true, les messages sont transférés vers l'un de ces points de terminaison, lequel est sélectionné de manière aléatoire.

Remarque : ce RuleSet utilise une fonctionnalité du .NET Framework 3.5 pour les règles Windows Workflow Foundation, à savoir la fonctionnalité permettant d'utiliser le mot clé new pour appeler les constructeurs de classes. Par exemple, lorsqu'un message respecte les critères de la règle CalculatorService, celle-ci ajoute une nouvelle EndpointAddress à la liste d'adresses possibles.

Lorsque vous exécutez l'exemple, les demandes et réponses d'opération s'affichent dans la fenêtre de console du client. 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 générer et exécuter l'exemple

1. Pour exécuter l'exemple dans une configuration à un ou plusieurs ordinateurs, conformez-vous aux instructions figurant dans la rubrique Running the Windows Communication Foundation Samples en prenant en compte les exceptions suivantes :

   • 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.
   • Dans une configuration à plusieurs ordinateurs, les modifications suivantes doivent être apportées aux quatre fichiers de configuration :
   • Modifiez la ligne 21 du fichier App.config pour CalculatorService et EchoService. Le nom d'hôte réel de l'intermédiaire doit remplacer le nom d'hôte localhost.
   • Modifiez la ligne 16 du fichier App.config du routeur. Remplacez les deux adresses (séparées par '|') par le nom d'hôte de EchoService et CalculatorService, respectivement.
   • Modifiez les lignes 5 et 7 du fichier App.config du client. Le nom d'hôte réel de l'intermédiaire doit remplacer le nom d'hôte localhost.
   • Vous pouvez également exécuter l'ServiceModel Metadata Utility Tool (Svcutil.exe) sur les deux services d'application (une fois ceux-ci mis à jour pour utiliser l'adresse correcte) et régénérer les fichiers App.config.

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

   Remarque :
   Les points de terminaison d'application EchoService et CalculatorService utilisent l'adresse du routeur.

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

   Remarque :
   Si Client.exe et Router.exe sont sur des ordinateurs distincts, 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.

Voir aussi

Tâches

External RuleSet Toolkit, exemple

Autres ressources

Intermediary Router

Envoyer des commentaires sur cette rubrique à Microsoft.