Nouveautés dans Windows Communication Foundation
Cette rubrique présente les nouvelles fonctionnalités de Windows Communication Foundation (WCF).
Activation basée sur la configuration
Généralement, lorsque vous hébergez un service Windows Communication Foundation (WCF) dans les services IIS (Internet Information Services) ou WAS (Windows Process Activation Service), vous devez fournir un fichier .svc. Le fichier .svc contient le nom du service et une fabrique hôte de service personnalisée facultative. Ce fichier supplémentaire facilite encore la gestion. Grâce à la fonctionnalité d'activation basée sur la configuration, le fichier .svc et, par conséquent, les surcharges associées ne sont plus indispensables. Pour plus d'informations, consultez Activation basée sur la configuration dans les services IIS et WAS, Configuration-Based Activation.
Intégration de System.Web.Routing
Lorsque vous hébergez un service Windows Communication Foundation (WCF) dans IIS, vous placez un fichier .svc dans le répertoire virtuel. Ce fichier .svc spécifie la fabrique hôte de service à utiliser ainsi que la classe qui implémente le service. Lorsque vous faites des demandes au service, vous spécifiez le fichier .svc dans l'URI, par exemple: https://contoso.com/EmployeeServce.svc. Pour les programmeurs qui écrivent des services REST, ce type d'URI n'est pas optimal. Les URI des services REST spécifient une ressource spécifique et n'ont généralement pas d'extension. La fonctionnalité d'intégration de System.Web.Routing vous permet d'héberger un service WCF qui répond aux URI sans extension. Pour plus d'informations, consultez Intégration de System.Web.Routing, Exemple SystemWebRouting Integration.
Prise en charge de plusieurs liaisons IIS par site
Lorsque vous hébergez un service Windows Communication Foundation (WCF) dans Internet Information Services (IIS) 7.0, vous souhaitez peut-être fournir plusieurs adresses de base utilisant le même protocole sur le même site. Cela permet au même service de répondre à plusieurs URI différents. C'est utile lorsque vous souhaitez héberger un service qui écoute sur https://www.contoso.com et https://contoso.com. Il est également utile de créer un service qui a une adresse de base pour les utilisateurs internes et une autre adresse de base pour les utilisateurs externes. Pour plus d'informations, consultez Prise en charge de plusieurs liaisons de site IIS,
Service de routage
Le service de routage est un intermédiaire SOAP générique qui agit en tant que routeur de messages. La fonctionnalité principale du service de routage est la possibilité de router des messages en fonction du contenu des messages ; un message peut ainsi être envoyé à un point de terminaison client en fonction d'une valeur située à l'intérieur du message, soit dans l'en-tête, soit dans le corps du message. Pour plus d'informations, consultez Routage, Services de routage .
Prise en charge de WS-Discovery
La fonctionnalité de découverte de service permet aux applications clientes de découvrir les adresses du service au moment de l'exécution, de manière dynamique et interopérable, à l'aide de WS-Discovery. La spécification de WS-Discovery présente les modèles d'échange de messages (MEP) nécessaires pour effectuer une découverte légère des services, à la fois par multidiffusion (ad hoc) et monodiffusion (utilisation d'une ressource réseau). Pour plus d'informations, consultez Découverte WCF, Découverte (exemples).
Points de terminaison standard
Les points de terminaison standard sont des points de terminaison prédéfinis dont une ou plusieurs propriétés (adresse, liaison, contrat) sont fixes. Par exemple, tous les points de terminaison d'échange de métadonnées spécifient IMetadataExchange comme leur contrat, donc le développeur n'a pas à spécifier de contrat. Le point de terminaison MEX standard a, par conséquent, un contrat fixe IMetadataExchange. Pour plus d'informations, consultez Points de terminaison standard, .
Services de workflow
Grâce à l'introduction d'un jeu d'activités de messagerie, implémenter des workflows qui envoient et reçoivent des données n'a jamais été aussi simple. Ces activités de messagerie vous permettent de réaliser des modèles complexes d'échange de messages qui vont plus loin que l'appel traditionnel de méthodes envoyer/recevoir ou de style RPC. Pour plus d'informations, consultez Services de workflow, Services, Services.
Attribut de la version cible de .Net Framework
L'attribut de la version cible de .Net Framework est utilisé pour spécifier la version de .NET Framework ciblée par une application hébergée dans les services IIS ou WAS. Il vous permet de générer des applications qui ciblent .NET Framework 2.0, 3.5 ou 4, à l'aide de Visual Studio. Il s'agit d'un attribut défini dans une balise <compilation> dans le fichier Web.config d'une application, comme le montre l'exemple suivant.
<compilation debug="false"
targetFramework="4.0">
<assemblies>
<add assembly="System.Core, Version=3.5.0.0, Culture=neutral, PublicKeyToken=B77A5C561934E089"/>
<add assembly="System.Xml.Linq, Version=3.5.0.0, Culture=neutral, PublicKeyToken=B77A5C561934E089"/>
<add assembly="System.Web.Extensions, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35"/>
<add assembly="System.Data.DataSetExtensions, Version=3.5.0.0, Culture=neutral, PublicKeyToken=B77A5C561934E089"/>
</assemblies>
</compilation>
Lorsqu'une application hébergée dans les services IIS ou WAS cible une version du .NET Framework qui n'est pas installée, une exception est levée indiquant le problème. Si le moniker de la version cible de .Net Framework n'est pas spécifié dans le fichier Web.config de l'application, la valeur est déduite à partir de la version du pool d'applications configurée dans IIS.
En raison de cette nouvelle fonctionnalité, si vous essayez d'héberger un service WCF écrit avec le .NET Framework 3.5 sur un ordinateur qui exécute le .NET Framework 4, vous risquez d'obtenir une exception ProtocolException avec le texte suivant :
Exception non gérée : System.ServiceModel.ProtocolException : le type de contenu text/html; charset=utf-8 du message de réponse ne correspond pas au type de contenu de la liaison (application/soap+xml; charset=utf-8). Lors de l'utilisation d'un encodeur personnalisé, assurez-vous que la méthode IsContentTypeSupported est implémentée correctement. Les 1024 premiers octets de la réponse étaient : '<html> <head> <title>Le domaine d'application ou le pool d'applications exécute actuellement la version 4 ou une version ultérieure du .NET Framework. Cela peut se produire si les paramètres IIS ont été définis sur la version 4.0 ou ultérieure pour cette application Web, ou si vous utilisez la version 4.0 ou ultérieure du serveur de développement Web ASP.NET. L'élément <compilation> dans le fichier Web.config de cette application Web ne contient pas l'attribut 'targetFrameworkMoniker' requis pour cette version du .NET Framework (par exemple, '<compilation targetFrameworkMoniker=".NETFramework,Version=v4.0">'). Mettez à jour le fichier Web.config avec cet attribut ou configurez l'application Web pour utiliser une version différente du .NET Framework.</title>..
Cette erreur se produit parce que le domaine d'application, dans lequel s'exécute IIS, exécute .NET Framework 4 alors que le service WCF s'attend à fonctionner sous .NET Framework 3.5. Pour plus d'informations sur le sujet suivant la manière de résoudre ce problème, consultez Procédure : héberger un service WCF écrit avec le .NET Framework 3.5 dans IIS s'exécutant sous le .NET Framework 4.
WCF REST
Mise en cache
Le .NET Framework 4 vous permet de tirer parti du mécanisme de mise en cache déclaratif, déjà disponible dans ASP.NET, dans vos services WCF REST. Cela vous permet de mettre en cache les réponses provenant de vos opérations de service WCF REST. Lorsqu'un utilisateur envoie un HTTP GET à votre service qui est configuré pour la mise en cache, ASP.NET renvoie la réponse mise en cache et la méthode de service n'est pas appelée. Lorsque le cache expire, au prochain envoi d'un HTTP GET par un utilisateur, votre méthode de service est appelée et la réponse est encore une fois mise en cache.
Le .NET Framework 4 vous permet également d'implémenter une mise en cache HTTP GET conditionnelle. Dans les scénarios REST, un HTTP GET conditionnel est souvent utilisé par les services pour implémenter une mise en cache HTTP intelligente, comme décrit dans HTTP Specification (en anglais). Pour plus d'informations, consultez Prise en charge de la mise en cache pour les services HTTP Web WCF, Caching and Automatic Help Page.
Prise en charge de formats
Le modèle de programmation HTTP Web WCF vous permet de déterminer dynamiquement le meilleur format dans lequel une opération de service peut retourner sa réponse. Les réponses peuvent être automatiquement définies au format XML et JSON en fonction de l'en-tête d'acceptation. Des API d'assistance ont été ajoutées pour définir par programmation le format d'une opération. Pour plus d'informations, consultez Mise en forme HTTP Web WCF, Automatic Format Selection, Advanced Format Selection.
Gestion des erreurs HTTP REST
La gestion des erreurs HTTP Web WCF vous permet de retourner des erreurs provenant des services WCF REST qui spécifient un code d'état HTTP et de retourner les détails d'une erreur en utilisant le même format que l'opération (par exemple, XML ou JSON). Pour plus d'informations, consultez Gestion des erreurs HTTP Web WCF, .
Fonctionnalités de déploiement
La configuration nécessaire pour exécuter un service a été simplifiée et de nouveaux points de terminaison standard ont été introduits pour faciliter encore plus la configuration du service. Pour plus d'informations sur le sujet suivant la nouvelle configuration simplifiée, consultez Configuration simplifiée. Pour plus d'informations sur le sujet suivant les points de terminaison standard, consultez Points de terminaison standard.
Lorsque vous hébergez un service Windows Communication Foundation (WCF) dans IIS, vous placez un fichier .svc dans le répertoire virtuel. Ce fichier .svc spécifie la fabrique hôte de service à utiliser ainsi que la classe qui implémente le service. Lorsque vous faites des demandes au service, vous spécifiez le fichier .svc dans l'URI, par exemple: https://contoso.com/EmployeeServce.svc. Pour les programmeurs qui écrivent des services REST, ce type d'URI n'est pas optimal. Les URI des services REST spécifient une ressource spécifique et n'ont généralement pas d'extension. La fonctionnalité d'intégration de System.Web.Routing vous permet d'héberger un service WCF REST qui répond aux URI sans extension. Pour plus d'informations, consultez Intégration de System.Web.Routing.
JavaScript entre domaines
JSON Padding (JSONP) est un mécanisme qui active la prise en charge de scripts inter-sites dans les navigateurs Web. JSONP repose sur la capacité des navigateurs Web à charger des scripts à partir d'un site différent de celui d'où a été extrait le document chargé en cours. Le mécanisme fonctionne en remplissant la charge utile du format JSON par un nom de fonction de rappel défini par l'utilisateur, par exemple :
callback({ “a” = \“b\” });
Dans l'exemple ci-dessus la charge utile JSON, {“a” = \”b\”}, est encapsulée dans un appel de fonction, callback. La fonction de rappel doit déjà être définie dans la page Web actuelle. Le type de contenu d'une réponse JSONP est « application/javascript ». Pour plus d'informations, consultez JSONP.
Page d'aide du service WCF REST
.NET Framework version 4 fournit une page d'aide automatique pour les services WCF REST. Cette page d'aide contient une description de chaque opération, des formats de demande et de réponse, ainsi que des schémas. Pour plus d'informations, consultez Page d'aide du service HTTP Web WCF, Caching and Automatic Help Page.