Fonctionnalités de simplification WCF

Cette rubrique décrit les nouvelles fonctionnalités qui simplifient l’écriture d’applications WCF.

gRPC comme alternative à WCF

gRPC est une infrastructure RPC moderne qui est une alternative populaire à WCF. gRPC est basé sur HTTP/2, qui offre un certain nombre d’avantages par rapport à WCF, notamment :

• Performances : gRPC est beaucoup plus efficace que WCF, en particulier pour les connexions longues.
• Scalabilité : gRPC est conçu pour s’adapter à un grand nombre de clients et de serveurs.
• Sécurité : gRPC prend en charge divers mécanismes de sécurité, notamment TLS et l’authentification.
• Multiplateforme : gRPC est neutre sur la plateforme et peut être utilisé avec divers langages de programmation.

Pour plus d’informations sur le développement ou la migration d’applications WCF vers gRPC, consultez :

• Pourquoi nous recommandons gRPC pour les développeurs WCF
• Comparaison de WCF à gRPC
• Présentation de gRPC pour les développeurs WCF

Fichiers de configuration générés simplifiés

Lorsque vous ajoutez une référence de service dans Visual Studio ou utilisez l’outil SvcUtil.exe un fichier de configuration client est généré. Dans les versions précédentes de WCF, ces fichiers de configuration contenaient la valeur de chaque propriété de liaison, même si sa valeur est la valeur par défaut. Dans WCF 4.5, les fichiers de configuration générés contiennent uniquement les propriétés de liaison définies sur une valeur non par défaut.

Voici un exemple de fichier de configuration généré par WCF 3.0.

<?xml version="1.0" encoding="utf-8"?>
<configuration>
    <system.serviceModel>
        <bindings>
            <basicHttpBinding>
                <binding name="BasicHttpBinding_IService1" closeTimeout="00:01:00"
                    openTimeout="00:01:00" receiveTimeout="00:10:00" sendTimeout="00:01:00"
                    allowCookies="false" bypassProxyOnLocal="false"
                    hostNameComparisonMode="StrongWildcard" maxBufferSize="65536"
                    maxBufferPoolSize="524288" maxReceivedMessageSize="65536"
                    messageEncoding="Text" textEncoding="utf-8" transferMode="Buffered"
                    useDefaultWebProxy="true">
                    <readerQuotas maxDepth="32" maxStringContentLength="8192"
                        maxArrayLength="16384" maxBytesPerRead="4096"
                        maxNameTableCharCount="16384" />
                    <security mode="None">
                        <transport clientCredentialType="None" proxyCredentialType="None"
                            realm="" />
                        <message clientCredentialType="UserName" algorithmSuite="Default" />
                    </security>
                </binding>
            </basicHttpBinding>
        </bindings>
        <client>
            <endpoint address="http://localhost:36906/Service1.svc" binding="basicHttpBinding"
                bindingConfiguration="BasicHttpBinding_IService1" contract="IService1"
                name="BasicHttpBinding_IService1" />
        </client>
    </system.serviceModel>
</configuration>

Voici un exemple du même fichier de configuration généré par WCF 4.5.

<?xml version="1.0" encoding="utf-8"?>
<configuration>
    <system.serviceModel>
        <bindings>
            <basicHttpBinding>
                <binding name="BasicHttpBinding_IService1" />
            </basicHttpBinding>
        </bindings>
        <client>
            <endpoint address="http://localhost:36906/Service1.svc" binding="basicHttpBinding"
                bindingConfiguration="BasicHttpBinding_IService1" contract="IService1"
                name="BasicHttpBinding_IService1" />
        </client>
    </system.serviceModel>
</configuration>

Contract-First Développement

WCF prend désormais en charge le développement axé sur les contrats. L’outil svcutil.exe a un commutateur /serviceContract qui vous permet de générer des contrats de service et de données à partir d’un document WSDL.

Ajouter une référence de service à partir d’un projet de sous-ensemble portable

Les projets de sous-ensemble portable permettent aux programmeurs d’assembly .NET de conserver une arborescence source unique et de créer un système tout en prenant en charge plusieurs implémentations .NET (bureau, Silverlight, Windows Phone et Xbox). Les projets de sous-ensemble portable référencent uniquement les bibliothèques portables .NET qui sont des assemblys qui peuvent être utilisés sur n’importe quelle implémentation .NET. L’expérience du développeur est la même que l’ajout d’une référence de service au sein d’une autre application cliente WCF. Pour plus d’informations, consultez Ajouter une référence de service dans un projet de sous-ensemble portable.

ASP.NET mode de compatibilité par défaut modifié

WCF fournit ASP.NET mode de compatibilité pour accorder aux développeurs un accès complet aux fonctionnalités du pipeline HTTP ASP.NET lors de l’écriture de services WCF. Pour utiliser ce mode, vous devez définir l’attribut aspNetCompatibilityEnabled sur true dans la <section serviceHostingEnvironment> de web.config. En outre, tout service de ce appDomain doit avoir la RequirementsMode propriété sur sa AspNetCompatibilityRequirementsAttribute valeur définie Allowed ou Required. Par défaut, AspNetCompatibilityRequirementsAttribute est maintenant défini sur Allowed, et le modèle d’application de service WCF par défaut définit l’attribut aspNetCompatibilityEnabled sur true. Pour plus d’informations, consultez Nouveautés de Windows Communication Foundation 4.5 et services WCF et ASP.NET.

Améliorations apportées à la diffusion en continu

• La nouvelle prise en charge de la diffusion en continu asynchrone a été ajoutée à WCF. Pour activer la diffusion en continu asynchrone, ajoutez le comportement de point de terminaison DispatcherSynchronizationBehavior à l’hôte de service et affectez à sa propriété AsynchronousSendEnabled la valeur true. Cela peut bénéficier de l’extensibilité lorsqu’un service envoie des messages diffusés en continu à plusieurs clients qui lisent lentement. WCF ne bloque plus un thread par client et libère le thread pour le service d’un autre client.

• Suppression des limitations relatives à la mise en mémoire tampon des messages lorsqu’un service est hébergé par IIS. Dans les versions précédentes de WCF, lors de la réception d’un message pour un service hébergé par IIS qui utilisait le transfert de messages par diffusion continue, ASP.NET mettait en mémoire tampon l’intégralité du message avant de l’envoyer à WCF. Cela entraînerait une grande consommation de mémoire. Cette mise en mémoire tampon a été supprimée dans .NET Framework 4.5 et les services WCF hébergés par IIS peuvent commencer à traiter le flux entrant avant la réception du message entier, ce qui permet la diffusion en continu réelle. Cela permet à WCF de répondre immédiatement aux messages et d’améliorer les performances. En outre, vous n’avez plus besoin de spécifier de valeur pour maxRequestLength, la limite de taille ASP.NET sur les demandes entrantes. Si cette propriété est définie, elle est ignorée. Pour plus d’informations concernant maxRequestLength, consultez l’élément de configuration <httpRuntime>. Vous devrez toujours configurer le maxAllowedContentLength, pour plus d’informations, voir Limites des requêtes IIS.

Nouveaux paramètres par défaut de transport

Le tableau suivant décrit les paramètres qui ont changé et où trouver des informations supplémentaires.

XmlDictionaryReaderQuotas

XmlDictionaryReaderQuotas contient des valeurs de quota configurables pour les lecteurs de dictionnaire XML qui limitent la quantité de mémoire utilisée par un encodeur lors de la création d’un message. Bien que ces quotas soient configurables, les valeurs par défaut ont changé pour réduire la possibilité qu’un développeur doit les définir explicitement. Le quota MaxReceivedMessageSize n’a pas été modifié afin de pouvoir continuer à limiter la consommation de mémoire et vous éviter d’avoir à gérer la complexité du paramètre XmlDictionaryReaderQuotas. Le tableau suivant présente les quotas, leurs nouvelles valeurs par défaut et une brève explication de ce que chaque quota est utilisé.

Validation de la configuration WCF

Dans le cadre du processus de génération dans Visual Studio, les fichiers de configuration WCF sont désormais validés. Une liste d’erreurs de validation ou d’avertissements s’affiche dans Visual Studio si la validation échoue.

Info-bulles de l'éditeur XML

Pour aider les développeurs de services WCF nouveaux et existants à configurer leurs services, l’éditeur XML visual Studio fournit désormais des info-bulles pour chaque élément de configuration et ses propriétés qui font partie du fichier de configuration de service.

Améliorations de BasicHttpBinding

1. Permet à un seul point de terminaison WCF de répondre à différents modes d’authentification.

2. Permet de contrôler les paramètres de sécurité d’un service WCF par IIS