Introduction au routage

Article
02/27/2011

Le service de routage fournit un intermédiaire SOAP générique connectable, capable de router des messages en fonction du contenu. Le service de routage vous permet de créer une logique de routage complexe et d'implémenter des scénarios, tels que l'agrégation de service, le contrôle des versions de service, le routage par priorité et en mode multidiffusion. Le service de routage fournit également une gestion des erreurs qui vous permet de définir des listes de points de terminaison de sauvegarde auxquels sont envoyés les messages en cas d'échec de l'envoi au point de terminaison de destination primaire.

Cette rubrique est destinée aux nouveaux utilisateurs du service de routage ; elle présente la configuration de base et l'hébergement du service de routage.

Configuration

Le service de routage est implémenté en tant que service WCF qui expose un ou plusieurs points de terminaison de service ; ceux-ci reçoivent les messages provenant d'applications clientes et les acheminent vers un ou plusieurs points de terminaison de destination. Le service fournit une classe RoutingBehavior, appliquée aux points de terminaison de service exposés par le service. Ce comportement permet de configurer différents aspects du fonctionnement du service. Pour simplifier la configuration dans le cadre de l'utilisation d'un fichier de configuration, les paramètres sont spécifiés dans le RoutingBehavior. Dans les scénarios basés sur du code, ces paramètres sont spécifiés dans le cadre d'un objet RoutingConfiguration, qui peut ensuite être transmis à un RoutingBehavior.

Au moment du démarrage, ce comportement ajoute aux points de terminaison clients la classe SoapProcessingBehavior, utilisée pour exécuter le traitement SOAP des messages. Cela permet au service de routage de transmettre des messages aux points de terminaison qui requièrent une version MessageVersion différente de celle du point de terminaison ayant reçu les messages. Le RoutingBehavior enregistre également une extension de service, la classe RoutingExtension, qui offre un point d'accès permettant de modifier la configuration du service de routage au moment de l'exécution.

La classe RoutingConfiguration offre un moyen cohérent de configurer et de mettre à jour la configuration du service de routage. Elle contient des paramètres qui agissent en tant que paramètres du service de routage et permet de configurer le RoutingBehavior, lorsque le service démarre ou lorsqu'il est transmis à la classe RoutingExtension, afin de modifier la configuration du routage au moment de l'exécution.

La logique de routage utilisée pour router les messages en fonction du contenu est définie en regroupant plusieurs objets MessageFilter dans des tables de filtres (objets MessageFilterTable). Les messages entrants sont évalués d'après les filtres de messages contenus dans la table de filtres et envoyés au point de terminaison de destination correspondant à chaque MessageFilter. La table de filtres à utiliser pour router les messages est spécifiée à l'aide du RoutingBehavior de la configuration, ou par code, à l'aide de l'objet RoutingConfiguration.

Définition des points de terminaison

La première chose à configurer n'est pas, comme vous pourriez le penser, de définir la logique de routage que vous utiliserez, mais de déterminer la forme des points de terminaison vers lesquels les messages seront routés. Le service de routage utilise des contrats définissant la forme des canaux qui permettent de recevoir et envoyer des messages ; par conséquent, la forme du canal d'entrée doit correspondre à celle du canal de sortie. Par exemple, si vous effectuez un routage vers des points de terminaison utilisant la forme de canal demande-réponse, vous devez utiliser un contrat compatible sur les points de terminaison entrants, comme l'interface IRequestReplyRouter.

Cela signifie que si vos points de terminaison de destination utilisent des contrats avec plusieurs modèles de communication (comme une combinaison d'opérations monodirectionnelles et bidirectionnelles), vous ne pouvez pas créer de point de terminaison de service unique qui puisse recevoir et router des messages vers tous les points de terminaison de destination. Vous devez déterminer les points de terminaison qui ont des formes compatibles et définir un ou plusieurs points de terminaison de service qui permettront de recevoir les messages devant être routés vers les points de terminaison de destination.

Remarque :
En cas d'utilisation de contrats spécifiant plusieurs modèles de communication (comme une combinaison d'opérations monodirectionnelles et bidirectionnelles), vous pouvez utiliser un contrat duplex au service de routage tel que l'interface IDuplexSessionRouter. Cependant, cela suppose que la liaison soit capable d'une communication duplex, ce qui n'est pas le cas dans tous les scénarios. Dans les scénarios où cela n'est pas possible, il faudra peut-être développer la communication en plusieurs points de terminaison ou modifier l'application.

En cas d'utilisation de contrats spécifiant plusieurs modèles de communication (comme une combinaison d'opérations monodirectionnelles et bidirectionnelles), vous pouvez utiliser un contrat duplex au service de routage tel que l'interface IDuplexSessionRouter. Cependant, cela suppose que la liaison soit capable d'une communication duplex, ce qui n'est pas le cas dans tous les scénarios. Dans les scénarios où cela n'est pas possible, il faudra peut-être développer la communication en plusieurs points de terminaison ou modifier l'application.

Pour plus d'informations sur les contrats de routage, consultez Contrats de routage.

Après avoir défini le point de terminaison de service, vous pouvez utiliser le RoutingBehavior pour associer un objet RoutingConfiguration spécifique au point de terminaison. Lorsque vous configurez le service de routage à l'aide d'un fichier de configuration, le RoutingBehavior permet de spécifier la table de filtres contenant la logique de routage utilisée pour traiter les messages reçus sur ce point de terminaison. Si vous configurez le service de routage par programme, vous pouvez spécifier la table de filtres à l'aide de l'objet RoutingConfiguration.

L'exemple suivant définit les points de terminaison clients et de service utilisés par le service de routage à la fois par programme et par un fichier de configuration.

<services>
      <!--ROUTING SERVICE -->
      <service behaviorConfiguration="routingData"
               name="System.ServiceModel.Routing.RoutingService">
        <host>
          <baseAddresses>
            <add baseAddress="https://localhost:8000/routingservice/router"/>
          </baseAddresses>
        </host>
        <!-- Define the service endpoints that are receive messages -->
        <endpoint address=""
                  binding="wsHttpBinding"
                  name="reqReplyEndpoint"
                  contract="System.ServiceModel.Routing.IRequestReplyRouter" />      </service>
    </services>
    <behaviors>
      <serviceBehaviors>
        <behavior name="routingData">
          <serviceMetadata httpGetEnabled="True"/>
          <!-- Add the RoutingBehavior and specify the Routing Table to use -->
          <routing filterTableName="routingTable1" />
        </behavior>
      </serviceBehaviors>
    </behaviors>
    <client>
    <!-- Define the client endpoint(s) to route messages to -->
      <endpoint name="CalculatorService"
                address="https://localhost:8000/servicemodelsamples/service"
                binding="wsHttpBinding" contract="*" />
    </client>

//set up some communication defaults
string clientAddress = "https://localhost:8000/servicemodelsamples/service";
string routerAddress = "https://localhost:8000/routingservice/router";
Binding routerBinding = new WSHttpBinding();
Binding clientBinding = new WSHttpBinding();
//add the endpoint the router uses to receive messages
serviceHost.AddServiceEndpoint(
     typeof(IRequestReplyRouter), 
     routerBinding, 
     routerAddress);
//create the client endpoint the router routes messages to
ContractDescription contract = ContractDescription.GetContract(
     typeof(IRequestReplyRouter));
ServiceEndpoint client = new ServiceEndpoint(
     contract, 
     clientBinding, 
     new EndpointAddress(clientAddress));
//create a new routing configuration object
RoutingConfiguration rc = new RoutingConfiguration();
….
rc.FilterTable.Add(new MatchAllMessageFilter(), endpointList);
//attach the behavior to the service host
serviceHost.Description.Behaviors.Add(
     new RoutingBehavior(rc));

Cet exemple configure le service de routage de manière à exposer un point de terminaison unique, avec pour adresse « https://localhost:8000/routingservice/router », utilisé pour recevoir les messages à router. Étant donné que les messages sont routés vers des points de terminaison demande-réponse, le point de terminaison de service utilise le contrat IRequestReplyRouter. Cette configuration définit également un point de terminaison client unique, « https://localhost:8000/servicemodelsample/service », vers lequel les messages sont routés. La table de filtres (non illustrée) nommée « routingTable1 » contient la logique de routage utilisée pour router les messages et est associée au point de terminaison de service à l'aide du RoutingBehavior (pour un fichier de configuration) ou de l'objet RoutingConfiguration (pour une configuration par programme).

Logique de routage

Pour définir la logique de routage utilisée pour router les messages, vous devez déterminer sur quelles données contenues dans les messages entrants il est possible d'agir de manière unique. Par exemple, si tous les points de terminaison de destination de votre routage partagent la même Action SOAP, la valeur de l'Action contenue dans le message ne constitue pas un bon indicateur du point de terminaison spécifique vers lequel le message doit être routé. Si vous devez router des messages uniquement vers un point de terminaison spécifique, vous devez appliquer un filtre sur des données qui identifient de manière unique le point de terminaison de destination vers lequel le message est routé.

Le service de routage fournit plusieurs implémentations de MessageFilter qui inspectent des valeurs spécifiques dans le message, telles que l'adresse, l'action, le nom du point de terminaison ou même une requête XPath. Si aucune de ces implémentations ne satisfait vos besoins, vous pouvez créer une implémentation de MessageFilter personnalisée. Pour plus d'informations sur les filtres de messages et une comparaison des implémentations utilisées par le service de routage, consultez Filtres de message et Choix d'un filtre.

Plusieurs filtres de message sont organisés en tables de filtres, qui associent chaque MessageFilter à un point de terminaison de destination. La table de filtres peut également être utilisée pour spécifier une liste de points de terminaison de sauvegarde auxquels, en cas d'échec de transmission, le service de routage tente d'envoyer le message.

Par défaut, tous les filtres de message d'une table de filtres sont évalués simultanément ; toutefois, vous pouvez spécifier une propriété Priority qui fait évaluer les filtres de messages dans un ordre spécifique. Les entrées de priorité plus élevée sont évaluées en premier et les filtres de message de priorité plus faible ne sont pas évalués si un résultat est trouvé à un niveau de priorité supérieur. Pour plus d'informations sur les tables de filtres, consultez Filtres de message.

Les exemples suivants utilisent l'objet MatchAllMessageFilter, qui prend tous les messages qui ont la valeur true. Ce MessageFilter est ajouté à la table de filtres « routingTable1 », qui associe le MessageFilter au point de terminaison client nommé « CalculatorService ». Le RoutingBehavior spécifie ensuite que cette table doit être utilisée pour router les messages traités par le point de terminaison de service.

<behaviors>
  <serviceBehaviors>
    <behavior name="routingData">
      <serviceMetadata httpGetEnabled="True"/>
      <!-- Add the RoutingBehavior and specify the Routing Table to use -->
      <routing filterTableName="routingTable1" />
    </behavior>
  </serviceBehaviors>
</behaviors>
<!--ROUTING SECTION -->
<routing>
  <filters>
    <filter name="MatchAllFilter1" filterType="MatchAll" />
  </filters>
  <filterTables>
    <table name="routingTable1">
      <filters>
        <add filterName="MatchAllFilter1" endpointName="CalculatorService" />
      </filters>
    </table>
  </filterTables>
</routing>

//create a new routing configuration object
RoutingConfiguration rc = new RoutingConfiguration();
//create the endpoint list that contains the endpoints to route to
//in this case we have only one
List<ServiceEndpoint> endpointList = new List<ServiceEndpoint>();
endpointList.Add(client);
//add a MatchAll filter to the Router's filter table
//map it to the endpoint list defined earlier
//when a message matches this filter, it is sent to the endpoint contained in the list
rc.FilterTable.Add(new MatchAllMessageFilter(), endpointList);

Remarque :
Par défaut, le service de routage évalue uniquement les en-têtes du message. Pour permettre aux filtres d'accéder au corps du message, vous devez attribuer à la propriété RouteOnHeadersOnly la valeur false.

Multidiffusion

Alors que de nombreuses configurations de service de routage utilisent une logique de filtre exclusive qui route les messages vers un seul point de terminaison spécifique, vous aurez peut-être besoin de router un message donné vers plusieurs points de terminaison de destination. Pour envoyer un message en mode multidiffusion à des destinations multiples, les conditions suivantes doivent être remplies :

La forme de canal ne doit pas être de type demande-réponse (bien qu'elle puisse être monodirectionnelle ou duplex), parce qu'une seule réponse peut être reçue par l'application cliente en réponse à la demande.
Plusieurs filtres doivent retourner une valeur true lors de l'évaluation du message.

Si ces conditions sont remplies, le message est routé vers tous les points de terminaison de tous les filtres qui doivent avoir la valeur true. L'exemple suivant définit une configuration de routage qui permet de router les messages vers les deux points de terminaison si l'adresse du point de terminaison dans le message est https://localhost:8000/routingservice/router/rounding.

<!--ROUTING SECTION -->
<routing>
  <filters>
    <filter name="MatchAllFilter1" filterType="MatchAll" />
    <filter name="RoundingFilter1" filterType="EndpointAddress"
            filterData="https://localhost:8000/routingservice/router/rounding" />
  </filters>
  <filterTables>
    <table name="routingTable1">
      <filters>
        <add filterName="MatchAllFilter1" endpointName="CalculatorService" />
        <add filterName="RoundingFilter1" endpointName="RoundingCalcService" />
      </filters>
    </table>
  </filterTables>
</routing>

rc.FilterTable.Add(new MatchAllMessageFilter(), calculatorEndpointList);
rc.FilterTable.Add(new EndpointAddressMessageFilter(new EndpointAddress(
    "https://localhost:8000/routingservice/router/rounding")),
    roundingCalcEndpointList);

Traitement SOAP

Pour prendre en charge le routage de messages entre des protocoles hétérogènes, le RoutingBehavior ajoute par défaut l'objet SoapProcessingBehavior à tous les points de terminaison clients vers lesquels les messages sont routés. Ce comportement crée automatiquement une version MessageVersion avant de router le message vers le point de terminaison, et de même crée une version MessageVersion compatible pour un éventuel document de réponse avant de le retourner à l'application cliente qui l'a demandé.

La procédure pour créer une version MessageVersion pour le message sortant est la suivante :

Traitement de la demande

Obtenez la version MessageVersion de la liaison sortante ou du canal sortant.
Obtenez le lecteur de corps du message d'origine.
Créez un nouveau message avec la même action, le même lecteur de corps et une nouvelle version MessageVersion.
Si Addressing ! = Addressing.None, copiez les en-têtes À, De, FaultTo, et RelatesTo dans le nouveau message.
Copiez toutes les propriétés du message dans le nouveau message.
Stockez le message de demande d'origine à utiliser lors du traitement de la réponse.
Retournez le nouveau message de demande.

Traitement de la réponse

Obtenez la version MessageVersion du message de demande d'origine.
Obtenez le lecteur de corps du message de réponse reçu.
Créez un nouveau message de réponse avec la même action, le même lecteur de corps et la version MessageVersion du message de demande d'origine.
Si Addressing ! = Addressing.None, copiez les en-têtes À, De, FaultTo, et RelatesTo dans le nouveau message.
Copiez les propriétés du message dans le nouveau message.
Retournez le nouveau message de réponse.

Par défaut, le SoapProcessingBehavior est automatiquement ajouté aux points de terminaison clients par l'objet RoutingBehavior, lorsque le service démarre ; toutefois, vous pouvez vérifier si le traitement SOAP est ajouté à tous les points de terminaison clients à l'aide de la propriété SoapProcessingEnabled. Vous pouvez également ajouter directement le comportement à un point de terminaison spécifique, au niveau duquel vous pouvez l'activer ou le désactiver, si un contrôle plus précis du traitement SOAP est nécessaire.

Remarque :
Si le traitement SOAP est désactivé pour un point de terminaison qui requiert une version MessageVersion différente de celle du message de demande d'origine, vous devez fournir un mécanisme personnalisé pour effectuer les modifications SOAP nécessaires avant d'envoyer le message au point de terminaison de destination.

Dans les exemples suivants, la propriété soapProcessingEnabled est utilisée pour empêcher le SoapProcessingBehavior d'être ajouté automatiquement à tous les points de terminaison clients.

<behaviors>
  <!--default routing service behavior definition-->
  <serviceBehaviors>
    <behavior name="routingConfiguration">
      <routing filterTableName="filterTable1" soapProcessingEnabled="false"/>
    </behavior>
  </serviceBehaviors>
</behaviors>

//create the default RoutingConfiguration
RoutingConfiguration rc = new RoutingConfiguration();
rc.SoapProcessingEnabled = false;

Configuration Dynamique

Lorsque vous ajoutez des points de terminaison clients supplémentaires, ou que vous devez modifier les filtres utilisés pour router les messages, vous devez pouvoir mettre la configuration à jour dynamiquement au moment de l'exécution afin d'éviter une interruption de service aux points de terminaison qui reçoivent actuellement des messages via le service de routage. Modifier un fichier de configuration ou le code de l'application hôte n'est pas toujours suffisant, car l'une ou l'autre méthode requiert le recyclage de l'application, ce qui signifierait la perte potentielle de tous les messages actuellement en transit et le risque d'un temps mort en attendant le redémarrage du service.

Vous ne pouvez modifier l'objet RoutingConfiguration que par programme. Alors que vous pouvez initialement configurer le service à l'aide d'un fichier de configuration, vous ne pouvez modifier la configuration au moment de l'exécution qu'en construisant un nouvel objet RoutingConfigution et en le transmettant en tant que paramètre à la méthode ApplyConfiguration exposée par l'extension du service RoutingExtension. Tous les messages actuellement en transit continuent d'être routés à l'aide de la configuration précédente, tandis que les messages reçus après l'appel à la méthode ApplyConfiguration utilisent la nouvelle configuration. L'exemple suivant montre la création d'une instance du service de routage, suivie d'une modification de la configuration.

RoutingConfiguration routingConfig = new RoutingConfiguration();
routingConfig.RouteOnHeadersOnly = true;
routingConfig.FilterTable.Add(new MatchAllMessageFilter(), endpointList);
RoutingBehavior routing = new RoutingBehavior(routingConfig);
routerHost.Description.Behaviors.Add(routing);
routerHost.Open();
// Construct a new RoutingConfiguration
RoutingConfiguration rc2 = new RoutingConfiguration();
ServiceEndpoint clientEndpoint = new ServiceEndpoint();
ServiceEndpoint clientEndpoint2 = new ServiceEndpoint();
// Add filters to the FilterTable in the new configuration
rc2.FilterTable.add(new MatchAllMessageFilter(),
       new List<ServiceEndpoint>() { clientEndpoint });
rc2.FilterTable.add(new MatchAllMessageFilter(),
       new List<ServiceEndpoint>() { clientEndpoint2 });
rc2.RouteOnHeadersOnly = false;
// Apply the new configuration to the Routing Service hosted in
routerHost.routerHost.Extensions.Find<RoutingExtension>().ApplyConfiguration(rc2);

Remarque :
Lorsque le service de routage est mis à jour de cette manière, seule la transmission d'une nouvelle configuration est possible. Il est impossible de modifier uniquement une sélection d'éléments de la configuration actuelle ni d'ajouter à celle-ci de nouvelles entrées ; vous devez créer et transmettre une nouvelle configuration qui remplace l'existante.

Remarque :
Toutes les sessions ouvertes à l'aide de la configuration précédente continuent à utiliser la configuration précédente. La nouvelle configuration est utilisée uniquement par les nouvelles sessions.

Gestion des erreurs

Si un objet CommunicationException est rencontré lors de la tentative d'envoi d'un message, une gestion des erreurs intervient. Ces exceptions indiquent en général qu'un problème s'est produit lors de la tentative de communication avec le point de terminaison client défini ; il peut s'agir d'une exception EndpointNotFoundException, ServerTooBusyException ou CommunicationObjectFaultedException. Le code de gestion des erreurs intercepte également l'envoi et tente de le reprendre lorsque se produit une exception TimeoutException, qui est une autre exception commune non dérivée de CommunicationException.

Lorsque l'une des exceptions précédentes se produit, le service de routage bascule sur une liste de points de terminaison de sauvegarde. Si tous les points de terminaison de sauvegarde échouent avec un échec de communication, ou si un point de terminaison retourne une exception indiquant une défaillance dans le service de destination, le service de routage retourne une erreur à l'application cliente.

Remarque :
Les fonctionnalités de gestion des erreurs capturent et gèrent des exceptions qui se produisent lors des tentatives d'envoi d'un message et de fermeture d'un canal. Le code de gestion des erreurs ne vise pas à détecter ni à gérer les exceptions créées par les points de terminaison de l'application avec lesquels il communique ; une exception FaultException levée par un service apparaît au service de routage comme un FaultMessage et est retransmise au client.

Les fonctionnalités de gestion des erreurs capturent et gèrent des exceptions qui se produisent lors des tentatives d'envoi d'un message et de fermeture d'un canal. Le code de gestion des erreurs ne vise pas à détecter ni à gérer les exceptions créées par les points de terminaison de l'application avec lesquels il communique ; une exception FaultException levée par un service apparaît au service de routage comme un FaultMessage et est retransmise au client.

Suivi d'exceptions

Lorsque l'envoi d'un message à un point de terminaison dans une liste échoue, le service de routage effectue un suivi des données d'exception résultantes et joint les détails de l'exception sous forme d'une propriété de message, nommée Exceptions. Cela conserve les données d'exception et autorise un accès utilisateur par programme via un inspecteur de message. Les données d'exception sont stockées par message dans un dictionnaire qui mappe le nom du point de terminaison aux détails de l'exception rencontrée lors de la tentative d'envoi d'un message à ce point.

Points de terminaison de sauvegarde

Chaque entrée de filtre dans la table de filtres peut éventuellement spécifier une liste de points de terminaison de sauvegarde, utilisés en cas de défaillance de la transmission lors de l'envoi au point de terminaison primaire. Si une telle défaillance se produit, le service de routage essaie de transmettre le message à la première entrée de la liste des points de terminaison de sauvegarde. Si cette tentative d'envoi rencontre également un échec de transmission, il essaie avec le point de terminaison de sauvegarde suivant sur la liste. Le service de routage continue à envoyer le message à chaque point de terminaison de la liste jusqu'à ce que le message soit correctement reçu, que tous les points de terminaison aient retourné un échec de transmission, ou qu'un point de terminaison retourne un autre échec que celui de la transmission.

Les exemples suivants configurent le service de routage de manière à utiliser une liste de sauvegarde.

<routing>
  <filters>
    <!-- Create a MatchAll filter that catches all messages -->
    <filter name="MatchAllFilter1" filterType="MatchAll" />
  </filters>
  <filterTables>
    <!-- Set up the Routing Service's Message Filter Table -->
    <filterTable name="filterTable1">
        <!-- Add an entry that maps the MatchAllMessageFilter to the dead destination -->
        <!-- If that endpoint is down, tell the Routing Service to try the endpoints -->
        <!-- Listed in the backupEndpointList -->
        <add filterName="MatchAllFilter1" endpointName="deadDestination" backupList="backupEndpointList"/>
    </filterTable>
  </filterTables>
  <!-- Create the backup endpoint list -->
  <backupLists>
    <!-- Add an endpoint list that contains the backup destinations -->
    <backupList name="backupEndpointList">
      <add endpointName="realDestination" />
      <add endpointName="backupDestination" />
    </backupList>
  </backupLists>
</routing>

//create the endpoint list that contains the service endpoints we want to route to
List<ServiceEndpoint> backupList = new List<ServiceEndpoint>();
//add the endpoints in the order that the Routing Service should contact them
//first add the endpoint that we know is down
//clearly, normally you wouldn't know that this endpoint was down by default
backupList.Add(fakeDestination);
//then add the real Destination endpoint
//the Routing Service attempts to send to this endpoint only if it 
//encounters a TimeOutException or CommunicationException when sending
//to the previous endpoint in the list.
backupList.Add(realDestination);
//add the backupDestination endpoint
//the Routing Service attempts to send to this endpoint only if it
//encounters a TimeOutException or CommunicationsException when sending
//to the previous endpoints in the list
backupList.Add(backupDestination);
//create the default RoutingConfiguration option            
RoutingConfiguration rc = new RoutingConfiguration();
//add a MatchAll filter to the Routing Configuration's filter table
//map it to the list of endpoints defined above
//when a message matches this filter, it is sent to the endpoints in the list in order
//if an endpoint is down or doesn't respond (which the first endpoint won't
//since the client doesn't exist), the Routing Service automatically moves the message
//to the next endpoint in the list and try again.
rc.FilterTable.Add(new MatchAllMessageFilter(), backupList);

Modèles d'erreurs pris en charge

Le tableau suivant décrit les modèles compatibles avec l'utilisation des listes de point de terminaison de sauvegarde, avec une description des détails de gestion des erreurs pour chaque modèle spécifique.

Modèle	Liste de sauvegarde prise en charge	Remarques
Monodirectionnel	Oui	Tente de renvoyer le message sur un point de terminaison de sauvegarde. Si ce message est en mode multidiffusion, seul le message sur le canal en échec est déplacé vers sa destination de sauvegarde.
Monodirectionnel	Non	Une exception est levée et la transaction est restaurée.
Monodirectionnel	Oui	Tente de renvoyer le message sur un point de terminaison de sauvegarde. Une fois le message correctement reçu, effectuez tous les contextes de réception. Si le message n'a pas été correctement reçu par un point de terminaison, n'effectuez pas le contexte de réception. Lorsque ce message est envoyé en mode multidiffusion, le contexte de réception n'est effectué que si le message a été correctement reçu par au moins un point de terminaison (primaire ou de sauvegarde). Si aucun des points de terminaison situés sur les chemins d'accès de multidiffusion ne reçoit correctement le message, n'effectuez pas le contexte de réception.
Monodirectionnel	Oui	Abandonnez la transaction précédente, créez une nouvelle transaction et renvoyez tous les messages. Les messages qui ont rencontré une erreur sont transmis à une destination de sauvegarde. Une fois créée une transaction dont toutes les transmissions ont réussi, effectuez les contextes de réception et validez la transaction.
Monodirectionnel	Oui	Tente de renvoyer le message sur un point de terminaison de sauvegarde. Dans un scénario de multidiffusion, seuls les messages qui se trouvent dans une session ayant rencontré une erreur ou dont la fin de session a échoué sont renvoyés aux destinations de sauvegarde.
Monodirectionnel	Non	Une exception est levée et la transaction est restaurée.
Monodirectionnel	Oui	Tente de renvoyer le message sur un point de terminaison de sauvegarde. Une fois tous les messages envoyés sans erreur, la session indique qu'il n'y a plus de messages, le service de routage ferme correctement tous les canaux de session sortante, tous les contextes de réception sont effectués et le canal de session entrante est fermé.
Monodirectionnel	Oui	Abandonnez la transaction actuelle et créez en une nouvelle. Renvoyez tous les messages précédents de la session. Une fois créée une transaction dont tous les messages ont été correctement envoyés et lorsque la session indique qu'il n'y a plus de messages, tous les canaux de session sortante sont fermés, les contextes de réception sont tous effectués avec la transaction, le canal de session entrante est fermé et la transaction est validée. Lorsque les sessions sont en mode multidiffusion, les messages qui n'ont eu aucune erreur sont renvoyés à la même destination qu'avant, et les messages qui ont rencontré une erreur sont envoyés aux destinations de sauvegarde.
Bidirectionnel	Oui	Envoyez à une destination de sauvegarde. Après qu'un canal a retourné un message de réponse, retournez la réponse au client d'origine.
Bidirectionnel	Oui	Envoyez tous les messages sur le canal à une destination de sauvegarde. Après qu'un canal a retourné un message de réponse, retournez la réponse au client d'origine.
Bidirectionnel	Non	Une exception est levée et la transaction est restaurée.
Bidirectionnel	Non	Une exception est levée et la transaction est restaurée.
Duplex	Non	La communication duplex sans session n'est pas prise en charge actuellement.
Duplex	Oui	Envoyez à une destination de sauvegarde.

Hébergement

Le service de routage étant implémenté en tant que service WCF, il doit être soit auto-hébergé dans une application, soit hébergé par les services IIS ou WAS. Il est préférable que le service de routage soit hébergé dans les services IIS ou WAS ou dans une application de service Windows afin de tirer parti des fonctionnalités de démarrage automatique et de gestion du cycle de vie, disponibles dans ces environnements d'hébergement.

L'exemple suivant montre l'hébergement du service de routage dans une application.

using (ServiceHost serviceHost =
                new ServiceHost(typeof(RoutingService)))

Pour héberger le service de routage dans les services IIS ou WAS, vous devez créer un fichier de service (.svc) ou utiliser une activation du service basée sur la configuration. Lorsque vous utilisez un fichier de service, vous devez spécifier un objet RoutingService à l'aide du paramètre du service. L'exemple suivant contient un exemple de fichier de service qui peut être utilisé pour héberger le service de routage avec les services IIS ou WAS.

<%@ ServiceHost Language="C#" Debug="true" Service="System.ServiceModel.Routing.RoutingService, 
     System.ServiceModel.Routing, version=4.0.0.0, Culture=neutral, 
     PublicKeyToken=31bf3856ad364e35" %>

Voir aussi

Concepts

Filtres de message
Contrats de routage
Choix d'un filtre

Partager via