Applications clientes de niveau intermédiaire
Cette rubrique traite des différents problèmes spécifiques aux applications clientes de niveau intermédiaire qui utilisent Windows Communication Foundation (WCF).
Augmenter les performances du client de niveau intermédiaire
Comparée aux technologies de communications précédentes, telles que les services Web qui utilisent ASP.NET, la création d’une instance cliente WCF peut être plus complexe en raison du grand nombre de fonctionnalités WCF. Par exemple, lorsqu'un objet ChannelFactory<TChannel> est ouvert, il peut établir une session sécurisée avec le service, procédure qui augmente le temps de démarrage pour l'instance cliente. En général, ces fonctionnalités supplémentaires affectent peu les applications clientes étant donné que le client WCF effectue plusieurs appels, puis se ferme.
Cependant, les applications clientes de niveau intermédiaire peuvent créer rapidement de nombreux objets clients WCF et, en conséquence, nécessitent des exigences d’initialisation plus nombreuses. Il existe deux approches principales pour accroître les performances des applications de niveau intermédiaire lors d'un appel des services :
Mettre en cache l'objet client WCF et le réutiliser pour les appels suivants le cas échéant.
Créer un objet ChannelFactory<TChannel> puis l'utiliser pour créer des nouveaux objets de canal de client WCF pour chaque appel.
Les problèmes à prendre en compte lors de l'utilisation de ces approches sont les suivants :
Si le service maintient un état spécifique au client en utilisant une session, vous ne pouvez pas réutiliser le client WCF de niveau intermédiaire avec des demandes au niveau de plusieurs clients parce que l'état du service est lié à celui du client de niveau intermédiaire.
Si le service doit exécuter l'authentification sur la base de chaque client, vous devez créer un client pour chaque requête entrante sur le niveau intermédiaire au lieu de réutiliser le client WCF de niveau intermédiaire (ou l'objet de canal de client WCF) parce que les informations d'identification du client du niveau intermédiaire ne peuvent pas être modifiées après la création du client WCF (ou de ChannelFactory<TChannel>).
Si les canaux et les clients créés par les canaux sont thread-safe, ils peuvent ne pas prendre en charge l'écriture simultanée de plusieurs messages sur la transmission. Si vous envoyez des messages volumineux, notamment pour la diffusion en continu, l'opération d'envoi peut bloquer l'exécution d'une autre opération d'envoi. Cette situation entraîne deux types de problèmes : un manque d'accès concurrentiel et le risque d'interblocage si le flux de contrôle retourne au service par l'intermédiaire du canal (autrement dit, le client partagé appelle un service dont le chemin d'accès au code entraîne un rappel au client partagé). Cela est vrai indépendamment du type de client WCF que vous réutilisez.
Vous devez traiter les canaux défaillants, que vous partagiez ou non le canal. Toutefois, lorsque les canaux sont réutilisés, un canal défaillant peut faire échouer plusieurs opérations de demande ou d'envoi en attente.
Pour obtenir un exemple qui illustre les meilleures pratiques permettant de réutiliser un client pour des demandes multiples, consultez Liaison de données dans un client ASP.NET.
De plus, vous pouvez augmenter les performances de démarrage pour les clients qui utilisent des types de données sérialisables à l'aide de XmlSerializer pour générer et compiler le code de sérialisation pour ces types de données au moment de l'exécution qui peuvent ralentir les performances de démarrage. L'Outil utilitaire de métadonnées ServiceModel Metadata Utility Tool (Svcutil.exe) peut améliorer les performances de démarrage de ces applications en générant le code de sérialisation nécessaire à partir des assemblys compilés pour l'application. Pour plus d’informations, consultez Procédure : améliorer le temps de démarrage des applications clientes WCF à l'aide de XmlSerializer.