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

Les applications clientes doivent créer, configurer et utiliser des objets client ou canal WCF pour communiquer avec les services. La rubrique Vue d’ensemble du client WCF fournit une vue d’ensemble des objets et étapes impliqués dans la création d’objets client et de canal de base et leur utilisation.

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

Aperçu

Cette rubrique décrit le comportement et les problèmes liés à :

• Durées de vie des canaux et des sessions.

• Gestion des exceptions.

• Comprendre les problèmes de blocage.

• Initialisation interactive des canaux.

Durées de vie des canaux et des sessions

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

Un canal de datagramme est un canal dans lequel tous les messages ne sont pas corrélés. Avec un canal de datagramme, si une opération d’entrée ou de sortie échoue, l’opération suivante n’est généralement pas affectée et le même canal peut être réutilisé. En raison de cela, les canaux de datagramme ne sont généralement pas défectueux.

Toutefois, les canaux avec session sont des canaux avec une connexion à l’autre point de terminaison. Les messages d’une session d’un côté sont toujours corrélés avec la même session de l’autre côté. En outre, les deux participants d’une session doivent accepter que les exigences de leur conversation aient été respectées pour que cette session soit considérée comme réussie. S’ils ne peuvent pas accepter, le canal avec session peut être défectueux.

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

La plupart des liaisons fournies par le système (qui exposent les canaux à la couche application) utilisent des sessions par défaut, mais pas.System.ServiceModel.BasicHttpBinding Pour plus d’informations, consultez Utilisation de sessions.

Utilisation appropriée des sessions

Les sessions fournissent un moyen de savoir si l’échange de messages entier est terminé et si les deux côtés l’ont considéré comme réussi. Il est recommandé qu’une application appelante ouvre le canal, l’utilise et ferme le canal à l’intérieur d’un bloc try. Si un canal de session est ouvert et que la ICommunicationObject.Close méthode est appelée une seule fois, et que cet appel retourne correctement, la session a réussi. La réussite dans ce cas signifie que toutes les garanties de remise spécifiées ont été remplies et que l’autre côté n’a pas appelé 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, la conversation a réussi, sauf si une exception est levée. En règle générale, si une exception est levée, la conversation est abandonnée.

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

using System;
using System.ServiceModel;
using System.ServiceModel.Channels;
using Microsoft.WCF.Documentation;

public class Client
{
  public static void Main()
  {
    // Picks up configuration from the config file.
    SampleServiceClient wcfClient = new SampleServiceClient();
    try
    {
      // Making calls.
      Console.WriteLine("Enter the greeting to send: ");
      string greeting = Console.ReadLine();
      Console.WriteLine("The service responded: " + wcfClient.SampleMethod(greeting));

      Console.WriteLine("Press ENTER to exit:");
      Console.ReadLine();

      // Done with service.
      wcfClient.Close();
      Console.WriteLine("Done!");
    }
    catch (TimeoutException timeProblem)
    {
      Console.WriteLine("The service operation timed out. " + timeProblem.Message);
      Console.ReadLine();
      wcfClient.Abort();
    }
    catch (FaultException<GreetingFault> greetingFault)
    {
      Console.WriteLine(greetingFault.Detail.Message);
      Console.ReadLine();
      wcfClient.Abort();
    }
    catch (FaultException unknownFault)
    {
      Console.WriteLine("An unknown exception was received. " + unknownFault.Message);
      Console.ReadLine();
      wcfClient.Abort();
    }
    catch (CommunicationException commProblem)
    {
      Console.WriteLine("There was a communication problem. " + commProblem.Message + commProblem.StackTrace);
      Console.ReadLine();
      wcfClient.Abort();
    }
  }
}

Imports System.ServiceModel
Imports System.ServiceModel.Channels
Imports Microsoft.WCF.Documentation

Public Class Client
    Public Shared Sub Main()
        ' Picks up configuration from the config file.
        Dim wcfClient As New SampleServiceClient()
        Try
            ' Making calls.
            Console.WriteLine("Enter the greeting to send: ")
            Dim greeting As String = Console.ReadLine()
            Console.WriteLine("The service responded: " & wcfClient.SampleMethod(greeting))

            Console.WriteLine("Press ENTER to exit:")
            Console.ReadLine()

            ' Done with service. 
            wcfClient.Close()
            Console.WriteLine("Done!")
        Catch timeProblem As TimeoutException
            Console.WriteLine("The service operation timed out. " & timeProblem.Message)
            Console.ReadLine()
            wcfClient.Abort()
        Catch greetingFault As FaultException(Of GreetingFault)
            Console.WriteLine(greetingFault.Detail.Message)
            Console.ReadLine()
            wcfClient.Abort()
        Catch unknownFault As FaultException
            Console.WriteLine("An unknown exception was received. " & unknownFault.Message)
            Console.ReadLine()
            wcfClient.Abort()
        Catch commProblem As CommunicationException
            Console.WriteLine("There was a communication problem. " & commProblem.Message + commProblem.StackTrace)
            Console.ReadLine()
            wcfClient.Abort()
        End Try
    End Sub
End Class

Les canaux datagrammes ne sont jamais défectueux même si des exceptions se produisent lorsqu’elles sont fermées. En outre, les clients non duplex qui ne parviennent pas à s’authentifier à l’aide d’une conversation sécurisée lèvent généralement un System.ServiceModel.Security.MessageSecurityException. Toutefois, si le client duplex utilisant une conversation sécurisée ne parvient pas à s’authentifier, le client reçoit un System.TimeoutException message à la place.

Pour plus d’informations complètes sur l’utilisation des informations d’erreur au niveau de l’application, consultez Spécification et gestion des erreurs dans les contrats et les services. Les exceptions attendues décrivent les exceptions attendues et montrent comment les gérer. Pour plus d’informations sur la gestion des erreurs lors du développement de canaux, consultez Gestion des exceptions et des erreurs.

Blocage et performances du client

Lorsqu’une application appelle de façon synchrone une opération de demande-réponse, le client bloque jusqu’à ce qu’une valeur de retour soit reçue ou qu’une exception (par exemple, a System.TimeoutException) soit levée. Ce comportement est similaire au comportement local. Lorsqu’une application appelle de façon synchrone une opération sur un objet ou un canal client WCF, le client ne retourne pas tant que la couche de canal ne peut pas écrire les données sur le réseau ou jusqu’à ce qu’une exception soit levée. Et bien que le modèle d’échange de messages unidirectionnel (spécifié en marquant une opération avec OperationContractAttribute.IsOneWay défini sur true) puisse rendre certains clients plus réactifs, les opérations unidirectionnelles peuvent également bloquer, 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, pas plus et moins. Pour plus d’informations, consultez One-Way Services.

Les blocs de données volumineux peuvent ralentir le traitement du client quel que soit le modèle d’échange de messages. Pour comprendre comment gérer ces problèmes, consultez Les données volumineuses et la 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 asynchrone sur l’interface de contrat de service que votre client WCF implémente. La méthode la plus simple consiste à utiliser le /async commutateur sur l’outil utilitaire de métadonnées ServiceModel (Svcutil.exe). Pour obtenir un exemple, consultez Comment : appeler des opérations de service de manière asynchrone.

Pour plus d’informations sur l’augmentation des performances du client, consultez Middle-Tier applications clientes.

Activation de l’utilisateur pour sélectionner des informations d’identification dynamiquement

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

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

Si vous utilisez l’approche implicite, l’application doit appeler la première opération sur une ClientBase<TChannel> ou IClientChannel une extension. S’il appelle quelque chose d’autre que la première opération, une exception est levée.

Si vous utilisez l’approche explicite, l’application doit effectuer les étapes suivantes dans l’ordre :

1. Appelez ou ClientBase<TChannel>.DisplayInitializationUIIClientChannel.DisplayInitializationUI (ou une version asynchrone).

2. Lorsque les initialiseurs ont retourné, appelez la Open méthode sur l’objet IClientChannel ou sur l’objet IClientChannel retourné par la ClientBase<TChannel>.InnerChannel propriété.

3. Appelez 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 pendant la période d’expiration d’envoi de la liaison, une exception est levée lorsque l’interface utilisateur retourne.

Voir aussi

• Duplex Services
• Comment faire : accéder aux services avec les contrats One-Way et Request-Reply
• Guide pratique pour accéder aux services avec un contrat Duplex
• Guide pratique pour accéder à un service WSE 3.0
• Guide pratique pour utiliser ChannelFactory
• Procédure : appeler des opérations de service WCF de façon asynchrone
• applications clientesMiddle-Tier