Accès aux services à l'aide d'un client

Les applications clientes doivent créer, configurer et utiliser des objets WCF de canal ou de client afin de communiquer avec des services. La rubrique Vue d'ensemble d'un client WCF fournit une vue d'ensemble des objets et des étapes nécessaires pour créer des objets de client et de canal de base, ainsi que des informations sur leur utilisation.

Cette rubrique fournit des informations détaillées sur certains aspects liés aux applications clientes et aux objets de client et de canal qui peuvent être utiles selon votre scénario.

Vue d'ensemble

Cette rubrique décrit le comportement et les problèmes liés aux éléments suivants :

• durées de vie de session et de canal ;
• gestion des exceptions ;
• présentation des problèmes de blocage ;
• initialisation de canaux de manière interactive.

Durées de vie de session et de canal

Les applications Windows Communication Foundation (WCF) incluent deux catégories de canaux : les canaux de datagramme et les canaux de session.

Un canal de datagramme est un canal dans lequel tous les messages sont sans corrélation. Avec un canal de datagramme, si une opération d'entrée ou de sortie échoue, l'opération suivante n'est en général pas affectée et le même canal peut être réutilisé. Pour cette raison, les canaux de datagramme ne subissent généralement pas de défaillance.

Les canaux de session, en revanche, sont des canaux avec une connexion à l'autre point de terminaison. Les messages dans une session d'un côté sont toujours en corrélation avec la même session de l'autre côté. De plus, les deux participants d'une session doivent s'entendre sur le fait que les spécifications de leur conversation ont été satisfaites pour que cette session soit considérée comme réussie. S'ils ne peuvent se mettre d'accord, le canal de session peut subir une défaillance.

Ouvrir des clients explicitement ou implicitement en appelant la première opération.

Remarque :

Le fait de tenter de détecter de manière explicite des canaux de session défaillants est en général inutile, car le moment où vous en êtes informé dépend de l'implémentation de session. Par exemple, étant donné que le System.ServiceModel.NetTcpBinding (avec la session fiable désactivée) est à la surface de la session de la connexion TCP, si vous écoutez l'événement System.ServiceModel.ICommunicationObject.Faulted sur le service ou le client, vous recevrez sans doute rapidement une notification en cas de panne réseau. Mais les sessions fiables (établies par des liaisons dans lesquelles le System.ServiceModel.Channels.ReliableSessionBindingElement est activé) sont conçues pour isoler les services des petites pannes réseau. Si la session peut être rétablie dans un délai raisonnable, la même liaison (configuré pour des sessions fiables) risque de ne subir une défaillance que longtemps après l'interruption.

La plupart des liaisons fournies par le système (qui exposent des canaux à la couche Application) utilisent des sessions par défaut, ce qui n'est pas le cas du System.ServiceModel.BasicHttpBinding. Pour plus d'informations, consultez Utilisation de sessions.

Utilisation correcte des sessions

Les sessions offrent un moyen de savoir si l'intégralité de l'échange de messages a été effectué et si les deux côtés l'ont considéré réussi. Il est recommandé qu'une application appelante ouvre le canal, l'utilise et le ferme à l'intérieur d'un bloc try. Si un canal de session est ouvert, que la méthode System.ServiceModel.ICommunicationObject.Close est appelée une fois et que cet appel est retourné avec succès, cela signifie que la session a réussi. Le terme « réussi » dans ce cas signifie que toutes les garanties de remise spécifiées par la liaison ont été satisfaites et que l'autre côté n'a pas appelé System.ServiceModel.ICommunicationObject.Abort sur le canal avant d'appeler Close.

La section suivante fournit un exemple de cette approche cliente.

Gestion des exceptions

La gestion des exceptions dans les applications clientes est simple. Si un canal est ouvert, utilisé et fermé à l'intérieur d'un bloc try, cela signifie que la conversation a réussi, à moins qu'une exception ne soit levée. En général, si une exception est levée, la conversation est abandonnée.

Remarque :
L'utilisation de l'instruction using (Using dans Visual Basic) n'est pas recommandée. Cela est dû au fait que la fin de l'instruction using peut provoquer des exceptions qui peuvent masquer d'autres exceptions dont vous devez avoir connaissance. Pour plus d'informations, consultez Avoiding Problems with the Using Statement.

L'exemple de code suivant illustre le modèle client recommandé à l'aide d'un bloc try/catch, et non de l'instruction using.

Remarque :
La vérification de la valeur de la propriété System.ServiceModel.ICommunicationObject.State est une condition de concurrence et n'est pas recommandée pour déterminer s'il faut réutiliser ou fermer un canal.

Les canaux de datagramme ne subissent jamais de défaillance, même si des exceptions se produisent lorsqu'ils sont fermés. De plus, les clients non-duplex qui ne parviennent pas à s'authentifier à l'aide d'une conversation sécurisée lèvent en général une exception System.ServiceModel.Security.MessageSecurityException. Toutefois, si le client duplex qui utilise une conversation sécurisée ne parvient pas à s'authentifier, il reçoit une exception System.TimeoutException.

Pour obtenir des informations plus complètes sur l'utilisation des informations d'erreur au niveau application, consultez Spécification et gestion des erreurs dans les contrats et les services. Expected Exceptions décrit les exceptions attendues et montre comment les gérer. Pour plus d'informations sur la façon de gérer les erreurs lors du développement de canaux, consultez Gestion des exceptions et des erreurs.

Blocage de client et performances

Lorsqu'une application appelle une opération demande-réponse de façon synchrone, le client se bloque jusqu'à ce qu'une valeur de retour soit reçue ou qu'une exception (par exemple System.TimeoutException) soit levée. Ce comportement est semblable au comportement local. Lorsqu'une application appelle de façon synchrone une opération sur un objet de client ou de canal WCF, le client n'est retourné que lorsque la couche de canal peut écrire les données sur le réseau ou lorsqu'une exception est levée. Et bien que le modèle d'échange de messages unidirectionnel (spécifié en marquant une opération avec System.ServiceModel.OperationContractAttribute.IsOneWay défini à true) puisse améliorer la capacité de réponse de certains clients, les opérations unidirectionnelles peuvent également subir un blocage, en fonction de la liaison et des messages qui ont déjà été envoyés. Les opérations unidirectionnelles concernent uniquement l'échange de messages, ni plus ni moins. Pour plus d'informations, consultez Services monodirectionnels.

Les grands segments de données peuvent ralentir le traitement client, quel que soit le modèle d'échange de messages. Pour comprendre comment gérer ces problèmes, consultez Données volumineuses et diffusion en continu.

Si votre application doit effectuer davantage de travail pendant qu'une opération se termine, vous devez créer une paire de méthodes asynchrones sur l'interface de contrat de service que votre client WCF implémente. La solution la plus simple consiste à utiliser le commutateur /async sur le ServiceModel Metadata Utility Tool (Svcutil.exe). Pour obtenir un exemple, consultez Comment : appeler des opérations de service WCF de façon asynchrone.

Pour plus d'informations sur l'augmentation des performances des clients, consultez Applications clientes de niveau intermédiaire.

Autoriser l'utilisateur à sélectionner des informations d'identification de manière dynamique

L'interface IInteractiveChannelInitializer permet aux applications d'afficher une interface utilisateur qui permet à l'utilisateur de choisir des informations d'identification avec lesquelles un canal est créé avant le démarrage des minuteries de délai d'attente.

Les développeurs d'applications peuvent utiliser un IInteractiveChannelInitializer inséré de deux façons. L'application cliente peut appeler System.ServiceModel.ClientBase.DisplayInitializationUI ou System.ServiceModel.IClientChannel.DisplayInitializationUI (ou une version asynchrone) avant d'ouvrir le canal (approche explicite) ou appeler la première opération (approche implicite).

Lors de l'utilisation de l'approche implicite, l'application doit appeler la première opération sur une extension ClientBase ou IClientChannel. Si elle appelle une autre opération que la première, une exception est levée.

Lors de l'utilisation de l'approche explicite, l'application doit exécuter les étapes suivantes, dans l'ordre :

1. Appeler System.ServiceModel.ClientBase.DisplayInitializationUI ou System.ServiceModel.IClientChannel.DisplayInitializationUI (ou une version asynchrone).
2. Lorsque les initialiseurs ont retourné, appeler la méthode Open sur l'objet IClientChannel ou sur l'objet IClientChannel retourné par la propriété System.ServiceModel.ClientBase.InnerChannel.
3. Appeler les opérations.

Il est recommandé que les applications de qualité de production contrôlent le processus d'interface utilisateur en adoptant l'approche explicite.

Les applications qui utilisent l'approche implicite appellent les initialiseurs d'interface utilisateur, mais si l'utilisateur de l'application ne répond pas avant la fin du délai d'attente d'envoi de la liaison, une exception est levée lorsque l'interface utilisateur retourne.

Voir aussi

Tâches

Comment : accéder aux services WCF avec des contrats unidirectionnels et demande-réponse
Comment : accéder aux services ayant un contrat duplex
Comment : accéder à un service WSE 3.0 avec un client WCF
Comment : utiliser la classe ChannelFactory
Comment : appeler des opérations de service WCF de façon asynchrone

Concepts

Services duplex
Applications clientes de niveau intermédiaire