Utilisation de sessions

Dans les applications Windows Communication Foundation (WCF), une session met en corrélation un groupe de messages dans une conversation. Les sessions WCF sont différentes de l’objet de session disponible dans ASP.NET applications, prennent en charge différents comportements et sont contrôlées de différentes manières. Cette rubrique décrit les fonctionnalités que les sessions activent dans les applications WCF et comment les utiliser.

Sessions dans les applications Windows Communication Foundation

Lorsqu’un contrat de service spécifie qu’il nécessite une session, ce contrat spécifie que tous les appels (autrement dit, les échanges de messages sous-jacents qui prennent en charge les appels) doivent faire partie de la même conversation. Si un contrat spécifie qu’il autorise les sessions, mais n’en nécessite pas, les clients peuvent se connecter et établir une session ou non une session. Si la session se termine et qu’un message est envoyé via le même canal, une exception est générée.

Les sessions WCF ont les principales fonctionnalités conceptuelles suivantes :

• Ils sont lancés et arrêtés explicitement par l’application appelante (le client WCF).

• Les messages remis pendant une session sont traités dans l’ordre dans lequel ils sont reçus.

• Les sessions mettent en corrélation un groupe de messages dans une conversation. Différents types de corrélation sont possibles. Par exemple, un canal basé sur une session peut mettre en corrélation des messages basés sur une connexion réseau partagée, tandis qu’un autre canal basé sur une session peut mettre en corrélation des messages basés sur une balise partagée dans le corps du message. Les fonctionnalités qui peuvent être dérivées de la session dépendent de la nature de la corrélation.

• Il n’existe aucun magasin de données général associé à une session WCF.

Si vous connaissez la System.Web.SessionState.HttpSessionState classe dans ASP.NET applications et les fonctionnalités qu’elle fournit, vous pouvez remarquer les différences suivantes entre ce type de session et les sessions WCF :

• ASP.NET sessions sont toujours initiées par le serveur.

• ASP.NET sessions sont implicitement non ordonnées.

• ASP.NET sessions fournissent un mécanisme de stockage de données général entre les requêtes.

Cette rubrique décrit les ressources suivantes :

• Comportement d’exécution par défaut lors de l’utilisation de liaisons basées sur une session dans la couche de modèle de service.

• Les types de fonctionnalités fournies par les liaisons fournies par le système et basées sur les sessions WCF.

• Comment créer un contrat qui déclare une exigence de session.

• Comment comprendre et contrôler la création et l’arrêt de la session et la relation de la session à l’instance de service.

Comportement d’exécution par défaut à l’aide de sessions

Une liaison qui tente de lancer une session est appelée liaison basée sur une session . Les contrats de service spécifient qu’ils nécessitent, autorisent ou refusent des liaisons basées sur une session en définissant la ServiceContractAttribute.SessionMode propriété sur l’interface de contrat de service (ou classe) sur l’une des valeurs d’énumération System.ServiceModel.SessionMode . Par défaut, la valeur de cette propriété est Allowed, ce qui signifie que si un client utilise une liaison basée sur une session avec une implémentation de service WCF, le service établit et utilise la session fournie.

Lorsqu’un service WCF accepte une session cliente, les fonctionnalités suivantes sont activées par défaut :

1. Tous les appels entre un objet client WCF sont gérés par la même instance de service.

2. Différentes liaisons basées sur une session fournissent des fonctionnalités supplémentaires.

System-Provided Types de session

Une liaison basée sur une session prend en charge l’association par défaut d’une instance de service avec une session particulière. Toutefois, différentes liaisons basées sur une session prennent en charge différentes fonctionnalités en plus d’activer le contrôle d’instanciation basé sur la session décrit précédemment.

WCF fournit les types suivants de comportement d’application basé sur une session :

• Le System.ServiceModel.Channels.SecurityBindingElement prend en charge les sessions basées sur la sécurité, dans lesquelles les deux parties de la communication ont convenu d’une conversation sécurisée spécifique. Pour plus d’informations, consultez Sécurisation des services. Par exemple, la liaison System.ServiceModel.WSHttpBinding, qui offre la prise en charge des sessions de sécurité ainsi que des sessions fiables, utilise par défaut uniquement une session sécurisée qui chiffre et signe numériquement les messages.

• La liaison System.ServiceModel.NetTcpBinding prend en charge les sessions basées sur TCP/IP pour garantir que tous les messages sont corrélés par la connexion au niveau du socket.

• L’élément System.ServiceModel.Channels.ReliableSessionBindingElement , qui implémente la spécification de WS-ReliableMessaging, fournit la prise en charge des sessions fiables dans lesquelles les messages peuvent être configurés pour être remis dans l’ordre et exactement une fois, ce qui garantit que les messages sont reçus même lorsque les messages se déplacent sur plusieurs nœuds pendant la conversation. Pour plus d’informations, consultez Sessions fiables.

• La liaison System.ServiceModel.NetMsmqBinding fournit des sessions de datagramme MSMQ. Pour plus d’informations, consultez Files d’attente dans WCF.

La définition de la SessionMode propriété ne spécifie pas le type de session requis par le contrat, qu’elle n’en nécessite qu’une.

Création d’un contrat nécessitant une session

La création d’un contrat qui nécessite une session indique que le groupe d’opérations que le contrat de service déclare doit tous être exécuté dans la même session et que les messages doivent être remis dans l’ordre. Pour affirmer le niveau de prise en charge de session requis par un contrat de service, définissez la ServiceContractAttribute.SessionMode propriété sur votre interface ou classe de contrat de service sur la valeur de l’énumération System.ServiceModel.SessionMode pour spécifier si le contrat :

• Nécessite une session.

• Permet à un client d’établir une session.

• Interdit une session.

Toutefois, la définition de la SessionMode propriété ne spécifie pas le type de comportement basé sur la session dont le contrat a besoin. Il demande à WCF de confirmer au moment de l’exécution que la liaison configurée (qui crée le canal de communication) pour le service le fait, ne le fait pas, ou peut établir une session lors de l’implémentation d’un service. Une fois encore, la liaison peut satisfaire cette spécification avec tout type de comportement basé sur session choisi : sécurité, transport, fiable ou toute combinaison. Le comportement exact dépend de la System.ServiceModel.SessionMode valeur sélectionnée. Si la liaison configurée du service n'est pas conforme à la valeur SessionMode, une exception est levée. Les liaisons et les canaux créés prenant en charge ces sessions sont dits « basés sur session ».

Le contrat de service suivant spécifie que toutes les opérations dans le ICalculatorSession fichier doivent être échangées au sein d’une session. Aucune des opérations ne retourne une valeur à l’appelant, à l’exception de la Equals méthode. Toutefois, la Equals méthode ne prend aucun paramètre et, par conséquent, ne peut retourner qu’une valeur non nulle à l’intérieur d’une session dans laquelle les données ont déjà été passées aux autres opérations. Ce contrat requiert qu'une session fonctionne correctement. Sans session associée à un client spécifique, l’instance de service n’a aucun moyen de connaître les données précédentes envoyées par ce client.

[ServiceContract(Namespace="http://Microsoft.ServiceModel.Samples", SessionMode=SessionMode.Required)]
public interface ICalculatorSession
{
    [OperationContract(IsOneWay=true)]
    void Clear();
    [OperationContract(IsOneWay = true)]
    void AddTo(double n);
    [OperationContract(IsOneWay = true)]
    void SubtractFrom(double n);
    [OperationContract(IsOneWay = true)]
    void MultiplyBy(double n);
    [OperationContract(IsOneWay = true)]
    void DivideBy(double n);
    [OperationContract]
    double Equals();
}

<ServiceContract(Namespace:="http://Microsoft.ServiceModel.Samples", SessionMode:=SessionMode.Required)> _
Public Interface ICalculatorSession

    <OperationContract(IsOneWay:=True)> _
    Sub Clear()
    <OperationContract(IsOneWay:=True)> _
    Sub AddTo(ByVal n As Double)
    <OperationContract(IsOneWay:=True)> _
    Sub SubtractFrom(ByVal n As Double)
    <OperationContract(IsOneWay:=True)> _
    Sub MultiplyBy(ByVal n As Double)
    <OperationContract(IsOneWay:=True)> _
    Sub DivideBy(ByVal n As Double)
    <OperationContract()> _
    Function Equal() As Double
End Interface

Si un service autorise une session, une session est établie et utilisée si le client en lance un ; sinon, aucune session n’est établie.

Sessions et instances de service

Si vous utilisez le comportement d’instanciation par défaut dans WCF, tous les appels entre un objet client WCF sont gérés par la même instance de service. Par conséquent, au niveau de l’application, vous pouvez considérer une session comme activant le comportement de l’application similaire au comportement d’appel local. Par exemple, lorsque vous créez un objet local :

• Un constructeur est appelé.

• Tous les appels suivants effectués à la référence d’objet client WCF sont traités par la même instance d’objet.

• Un destructeur est appelé lorsque la référence d’objet est détruite.

Les sessions permettent un comportement similaire entre les clients et les services tant que le comportement d’instance de service par défaut est utilisé. Si un contrat de service nécessite ou prend en charge des sessions, une ou plusieurs opérations de contrat peuvent être marquées comme initialisant ou mettant fin à une session en définissant les propriétés IsInitiating et IsTerminating.

Les opérations de lancement sont celles qui doivent être appelées en tant que première opération d’une nouvelle session. Les opérations sans lancement ne peuvent être appelées qu’après qu’au moins une opération de lancement a été appelée. Vous pouvez par conséquent créer un type de constructeur de session pour votre service en déclarant des opérations d'initialisation conçues pour prendre l'entrée des clients appropriés au début de l'instance de service. (L’état est associé à la session, mais pas à l’objet de service.)

Les opérations d’arrêt, à l’inverse, sont celles qui doivent être appelées en tant que dernier message dans une session existante. Dans le cas par défaut, WCF recycle l’objet de service et son contexte après la session avec laquelle le service a été associé est fermé. Vous pouvez, par conséquent, créer un type de destructeur en déclarant les opérations de fin conçues pour exécuter une fonction appropriée à la fin de l'instance de service.

Par exemple, le ICalculatorSession contrat utilisé dans l’exemple précédent nécessite que l’objet client WCF appelle d’abord l’opération Clear avant toute autre opération et que la session avec cet objet client WCF doit se terminer lorsqu’elle appelle l’opération Equals . L’exemple de code suivant montre un contrat qui applique ces exigences. Clear doit être appelé en premier pour lancer une session, et cette session se termine lorsqu’elle Equals est appelée.

[ServiceContract(Namespace="http://Microsoft.ServiceModel.Samples", SessionMode=SessionMode.Required)]
public interface ICalculatorSession
{
    [OperationContract(IsOneWay=true, IsInitiating=true, IsTerminating=false)]
    void Clear();
    [OperationContract(IsOneWay = true, IsInitiating = false, IsTerminating = false)]
    void AddTo(double n);
    [OperationContract(IsOneWay = true, IsInitiating = false, IsTerminating = false)]
    void SubtractFrom(double n);
    [OperationContract(IsOneWay = true, IsInitiating = false, IsTerminating = false)]
    void MultiplyBy(double n);
    [OperationContract(IsOneWay = true, IsInitiating = false, IsTerminating = false)]
    void DivideBy(double n);
    [OperationContract(IsInitiating = false, IsTerminating = true)]
    double Equals();
}

<ServiceContract(Namespace:="http://Microsoft.ServiceModel.Samples", SessionMode:=SessionMode.Required)> _
Public Interface ICalculatorSession

    <OperationContract(IsOneWay:=True, IsInitiating:=True, IsTerminating:=False)> _
    Sub Clear()
    <OperationContract(IsOneWay:=True, IsInitiating:=False, IsTerminating:=False)> _
    Sub AddTo(ByVal n As Double)
    <OperationContract(IsOneWay:=True, IsInitiating:=False, IsTerminating:=False)> _
    Sub SubtractFrom(ByVal n As Double)
    <OperationContract(IsOneWay:=True, IsInitiating:=False, IsTerminating:=False)> _
    Sub MultiplyBy(ByVal n As Double)
    <OperationContract(IsOneWay:=True, IsInitiating:=False, IsTerminating:=False)> _
    Sub DivideBy(ByVal n As Double)
    <OperationContract(IsInitiating:=False, IsTerminating:=True)> _
    Function Equal() As Double
End Interface

Les services ne démarrent pas de sessions avec les clients. Dans les applications clientes WCF, une relation directe existe entre la durée de vie du canal basé sur la session et la durée de vie de la session elle-même. Par conséquent, les clients créent de nouvelles sessions en créant de nouveaux canaux basés sur des sessions et en supprimant les sessions existantes en fermant correctement les canaux basés sur les sessions. Un client démarre une session avec un point de terminaison de service en appelant l'une des méthodes suivantes :

• ICommunicationObject.Open sur le canal retourné par un appel à ChannelFactory<TChannel>.CreateChannel.

• ClientBase<TChannel>.Open sur l’objet client WCF généré par l’outil Utilitaire de métadonnées ServiceModel (Svcutil.exe).

• Opération de lancement sur l’un ou l’autre type d’objet client WCF (par défaut, toutes les opérations sont en cours de lancement). Lorsque la première opération est appelée, l’objet client WCF ouvre automatiquement le canal et lance une session.

Habituellement, un client termine une session avec un point de terminaison de service en appelant l'un des éléments suivants :

• ICommunicationObject.Close sur le canal retourné par un appel à ChannelFactory<TChannel>.CreateChannel.

• ClientBase<TChannel>.Close sur l’objet client WCF généré par Svcutil.exe.

• Une opération de fin sur l’un ou l’autre type d’objet client WCF (par défaut, aucune opération ne se termine ; le contrat doit spécifier explicitement une opération de fin). Lorsque la première opération est appelée, l’objet client WCF ouvre automatiquement le canal et lance une session.

Pour obtenir des exemples, consultez Comment : créer un service nécessitant des sessions, ainsi que les exemples de comportement et d’instanciation de service par défaut.

Pour plus d’informations sur les clients et les sessions, consultez Accès aux services à l’aide d’un client WCF.

Sessions Interagissent avec les paramètres InstanceContext

Il existe une interaction entre l’énumération SessionMode dans un contrat et la ServiceBehaviorAttribute.InstanceContextMode propriété, qui contrôle l’association entre les canaux et des objets de service spécifiques. Pour plus d’informations, consultez Sessions, instanciation et accès concurrentiel.

Partage d’objets InstanceContext

Vous pouvez également contrôler le canal ou l’appel basé sur la session associé à l’objet InstanceContext en effectuant cette association vous-même.

Sessions et diffusion en continu

Lorsque vous avez une grande quantité de données à transférer, le mode de transfert de streaming dans WCF est une alternative possible au comportement par défaut de la mise en mémoire tampon et du traitement des messages en mémoire dans leur intégralité. Vous pouvez obtenir un comportement inattendu lors de la diffusion en continu d’appels avec une liaison basée sur une session. Tous les appels en streaming passent par un canal unique (le canal de datagramme) qui ne prend pas en charge les sessions même si la liaison utilisée est configurée pour utiliser des sessions. Si plusieurs clients effectuent des appels de streaming vers le même objet de service sur une liaison basée sur une session, et que le mode d’accès concurrentiel de l’objet de service est défini sur 'single' et son mode de contexte d’instance est défini sur PerSession, tous les appels doivent passer par le canal de datagramme, ce qui signifie qu’un seul appel est traité à la fois. Un ou plusieurs clients peuvent ensuite échouer. Vous pouvez contourner ce problème en définissant l'objet InstanceContextMode du service sur PerCall ou définir la concurrence sur 'multiple'.

Voir aussi

• IsInitiating
• IsTerminating