Protocole d'échange de contexte

Cette section décrit le protocole d’échange de contexte introduit dans Windows Communication Foundation (WCF) .NET Framework version 3.5. Ce protocole permet au canal client d’accepter un contexte fourni par un service et de l’appliquer à toutes les demandes suivantes à ce service envoyées sur la même instance de canal client. L’implémentation du protocole d’échange de contexte peut utiliser l’un des deux mécanismes suivants pour propager le contexte entre le serveur et le client : cookies HTTP ou en-tête SOAP.

Le protocole d’échange de contexte est implémenté dans une couche de canal personnalisée. Le canal communique le contexte à l’application et depuis celle-ci en utilisant une propriété ContextMessageProperty. Pour la transmission entre les points de terminaison, la valeur du contexte est sérialisée en tant qu’en-tête SOAP au niveau de la couche canal, ou convertie en ou à partir des propriétés de message qui représentent une requête et une réponse HTTP. Dans ce dernier cas, on s’attend à ce qu’une des couches de canal sous-jacentes convertit les propriétés de message de requête et de réponse HTTP vers et à partir des cookies HTTP, respectivement. Le choix du mécanisme utilisé pour échanger le contexte est effectué à l’aide de la ContextExchangeMechanism propriété sur le ContextBindingElement. Les valeurs valides sont HttpCookie ou SoapHeader.

Sur le client, une instance d’un canal peut fonctionner en deux modes en fonction des paramètres de la propriété du canal. Enabled

Mode 1 : Gestion du contexte du canal

Il s’agit du mode par défaut où Enabled est défini sur true. Dans ce mode, le canal de contexte gère le contexte et met en cache le contexte pendant sa durée de vie. Le contexte peut être récupéré à partir du canal via la propriété IContextManager en appelant la méthode GetContext. Le canal peut également être pré-initialisé avec un contexte spécifique avant d’être ouvert, en appelant la méthode SetContext sur la propriété du canal. Une fois le canal initialisé avec le contexte, il ne peut pas être réinitialisé.

Voici une liste d’invariants dans ce mode :

• Toute tentative de réinitialisation du contexte à l'aide de SetContext après l'ouverture du canal lève une InvalidOperationException.

• Toute tentative d’envoyer du contexte à l’aide du ContextMessageProperty dans un message sortant génère un InvalidOperationException.

• Si un message est reçu du serveur avec un contexte spécifique, lorsque le canal a déjà été initialisé avec un contexte spécifique, cela entraîne un ProtocolException.

  Remarque

  Il est approprié de recevoir un contexte initial du serveur uniquement si le canal est ouvert sans aucun contexte défini explicitement.

• Le ContextMessageProperty sur le message entrant est toujours null.

Mode 2 : Gestion du contexte d’application

Il s'agit du mode lorsque Enabled est réglé sur false. Dans ce mode, le canal de contexte ne gère pas le contexte. Il incombe à l’application de récupérer, de gérer et d’appliquer le contexte à l’aide du ContextMessageProperty. Toute tentative d'appel à GetContext ou SetContext aboutit à un InvalidOperationException.

Quel que soit le mode choisi, la fabrique de canaux client prend en charge les modèles d’échange de messages IRequestChannel, IRequestSessionChannel, et IDuplexSessionChannel.

Sur le service, une instance du canal est chargée de convertir le contexte fourni par le client sur les messages entrants vers le ContextMessageProperty. La propriété du message est ensuite accessible par la couche d'application ou par d'autres canaux plus haut dans la pile d'appels. Les canaux de service permettent également à la couche d'application de spécifier une nouvelle valeur de contexte à propager au client en attachant un ContextMessageProperty au message de réponse. Cette propriété est convertie en en-tête SOAP ou cookie HTTP qui contient le contexte, qui dépend de la configuration de la liaison. L'écouteur de canal de service prend en charge IReplyChannel, IReplySessionChannel et les modèles d'échange de messages IReplySessionChannel.

Le protocole d’échange de contexte introduit un nouvel wsc:Context en-tête SOAP pour représenter les informations de contexte lorsque les cookies HTTP ne sont pas utilisés pour propager le contexte. Le schéma d'en-tête de contexte permet un nombre illimité d'éléments enfants, chacun avec une clé de chaîne et un contenu de chaîne. Voici un exemple d’en-tête de contexte.

<Context xmlns="http://schemas.microsoft.com/ws/2006/05/context">

<property name="myContext">context-2</property>

</Context>

En mode HttpCookie, les cookies sont définis à l'aide de l'en-tête SetCookie. Le nom du cookie est WscContext. La valeur du cookie est l’encodage Base64 de l’en-tête wsc:Context . Cette valeur est placée entre guillemets.

La valeur du contexte doit être protégée contre la modification pendant le transit pour la même raison que les en-têtes WS-Addressing sont protégés : l'en-tête est utilisé pour déterminer vers quel service acheminer la demande. L’en-tête wsc:Context doit donc être signé numériquement ou signé et chiffré au niveau SOAP ou de transport lorsque la liaison offre une fonctionnalité de protection des messages. Lorsque les cookies HTTP sont utilisés pour propager le contexte, ils doivent être protégés à l’aide de la sécurité du transport.

Les points de terminaison de service qui nécessitent la prise en charge du protocole d’échange de contexte peuvent le rendre explicite dans la stratégie publiée. Deux nouvelles assertions de stratégie ont été introduites pour représenter la nécessité pour le client de prendre en charge le protocole d’échange de contexte au niveau SOAP ou d’activer la prise en charge des cookies HTTP. La génération de ces assertions dans la stratégie sur le service est contrôlée par la valeur de la ContextExchangeMechanism propriété comme suit :

• Pour ContextSoapHeader, l’assertion suivante est générée :

  <IncludeContext
  xmlns="http://schemas.microsoft.com/ws/2006/05/context"  
  protectionLevel="Sign" />  
  

• Pour HttpCookie, l’assertion suivante est générée :

  <HttpUseCookie xmlns="http://schemas.xmlsoap.org/soap/http"/>  
  

Voir aussi

• Guide d’interopérabilité des protocoles de services web