Services WCF et ASP.NET

Cette rubrique décrit l’hébergement de services Windows Communication Foundation (WCF) côte à côte avec ASP.NET en mode de compatibilité ASP.NET.

Hébergement de WCF côte à côte avec ASP.NET

Des services WCS hébergés dans les services IIS (Internet Information Services) peuvent se trouver avec des pages .ASPX et des services web ASMX à l’intérieur d’un même domaine d’application commun. ASP.NET fournit des services d’infrastructure, tels que la gestion et la compilation dynamique d’AppDomain, communs pour WCF et le runtime HTTP d’ASP.NET. La configuration par défaut pour WCF est côte à côte avec ASP.NET.

L’exécution d’ASP.NET HTTP gère des demandes ASP.NET mais ne participe pas au traitement des demandes destinées aux services WCF, bien que ces services soient hébergés dans le même AppDomain que le contenu ASP.NET. À la place, le modèle de service WCF intercepte les messages adressés aux services WCF, et les route à travers le transport/la pile de canaux de WCF.

Les résultats du modèle côte à côte est le suivant :

• ASP.NET et les services WCF peuvent partager l’état d’AppDomain. Parce que les deux infrastructures peuvent coexister dans le même AppDomain, WCF peut également partager l’état d’AppDomain avec ASP.NET (y compris les variables statiques, les événements et ainsi de suite).

• Les services WCF se comportent de façon cohérente, indépendamment de l’environnement d’hébergement et du transport. L'exécution d'ASP.NET HTTP est intentionnellement associée à l'environnement d'hébergement de IIS/ASP.NET et à la communication HTTP. Inversement, WCF est conçu pour se comporter de façon cohérente à travers les environnements d’hébergement (WCF se comporte de façon cohérente à la fois à l’intérieur et en dehors d’IIS) et à travers le transport (un service hébergé dans IIS 7.0 et version ultérieure a un comportement cohérent à travers tous les points de terminaison qu’il expose, même si quelques-uns de ces points utilisent des protocoles autres que HTTP).

• Dans un AppDomain, les fonctionnalités implémentées par l’exécution de HTTP s’appliquent au contenu ASP.NET mais pas à WCF. De nombreuses fonctionnalités de la plate-forme d’application ASP.NET spécifiques de HTTP ne s’appliquent pas aux services WCF hébergés dans un AppDomain qui contient le contenu ASP.NET. Voici des exemples de ces fonctionnalités :

  • HttpContext : Current est toujours null en cas d’accès à partir d’un service WCF. Utilisez RequestContext à la place.

  • Autorisation basée sur des fichiers : le modèle de sécurité WCF n’autorise pas l’application de la liste de contrôle d’accès (ACL, Access Control List) au fichier .svc du service lorsqu’il faut décider si une demande de service est autorisée.

  • Autorisation URL basée sur la configuration : de la même façon, le modèle de sécurité WCF n’adhère à aucune règle d’autorisation basée sur la configuration spécifiée dans l’élément de configuration <authorization> de System.Web. Ces paramètres sont ignorés pour les demandes WCF si un service réside dans un espace d’URL sécurisé par les règles d’autorisation d’URL de ASP.NET.

  • Extensibilité HttpModule : l’infrastructure d’hébergement de WCF intercepte les demandes WCF lorsque l’événement PostAuthenticateRequest est déclenché et ne retourne pas de traitement au pipeline de ASP.NET HTTP. Les modules encodés pour intercepter des demandes aux étapes ultérieures du pipeline n’interceptent pas les demandes WCF.

  • Emprunt d’identité ASP.NET : par défaut, les demandes WCF s’exécutent toujours comme l’identité de processus IIS, même si ASP.NET est configuré pour activer l’emprunt d’identité à l’aide de l’option de configuration <identity impersonate=”true” /> de System.Web.

Ces restrictions s’appliquent uniquement aux services WCF hébergés dans l’application IIS. Le comportement du contenu ASP.NET n’est pas affecté par la présence de WCF.

Les applications WCF qui requièrent les fonctionnalités traditionnellement fournies par le pipeline HTTP doivent envisager d’utiliser les équivalents indépendants de l’hôte et du transport :

• OperationContext plutôt que HttpContext.

• ServiceAuthorizationBehavior au lieu de l'autorisation de fichier/URL de ASP.NET.

• IDispatchMessageInspector ou des canaux en couche personnalisés au lieu des modules HTTP.

• Emprunt d’identité pour chaque opération à l’aide de WCF au lieu de l’emprunt d’identité System.Web.

Vous pouvez également envisager d’exécuter vos services en mode de compatibilité ASP.NET de WCF.

Hébergement des services WCF en mode de compatibilité ASP.NET

Bien que le modèle WCF soit conçu pour se comporter de façon cohérente à travers les environnements d’hébergement et les transports, souvent, dans certains scénarios, une application ne requiert pas ce degré de souplesse. Le mode de compatibilité ASP.NET de WCF est approprié pour les scénarios qui ne requièrent pas d’hébergement en dehors d’IIS ni de communication sur des protocoles autres que HTTP, mais qui utilisent toutes les fonctionnalités de la plate-forme d’application Web ASP.NET.

Contrairement à la configuration côte à côte par défaut, où l’infrastructure d’hébergement WCF intercepte les messages WCF et les route hors du pipeline HTTP, les services WCF qui s’exécutent en mode de compatibilité ASP.NET participent pleinement au cycle de vie de la demande HTTP ASP.NET. En mode de compatibilité, les services WCF utilisent le pipeline HTTP à travers une implémentation de IHttpHandler, semblable à la façon dont sont gérées les demandes pour les pages ASPX et les services Web ASMX. En conséquence, WCF se comporte de façon identique à ASMX en ce qui concerne fonctionnalités ASP.NET suivantes :

• HttpContext : les services WCF qui s’exécutent en mode de compatibilité ASP.NET peuvent accéder à Current et à son état associé.

• Autorisation basée sur des fichiers : les services WCF qui s’exécutent en mode de compatibilité ASP.NET peuvent être sécurisés en joignant des listes de contrôle d’accès de système de fichiers (ACL) au fichier .svc du service.

• Autorisation d’URL configurable : les règles d’autorisation d’URL de ASP.NET sont appliquées pour les demandes WCF lorsque le service WCF s’exécute en mode de compatibilité ASP.NET.

• Extensibilité HttpModuleCollection : les services WCF qui s’exécutent en mode de compatibilité ASP.NET participant pleinement au cycle de vie de la demande HTTP ASP.NET, tout module HTTP configuré dans le pipeline HTTP est en mesure de fonctionner sur les demandes WCF à la fois avant et après l’appel du service.

• Emprunt d’identité ASP.NET : les services WCF s’exécutent avec l’identité actuelle du thread qui a emprunté l’identité de ASP.NET ; celle-ci peut être différente de l’identité du processus IIS si l’emprunt d’identité ASP.NET a été activé pour l’application. Si l’emprunt d’identité ASP.NET et l’emprunt d’identité WCF sont activés à la fois pour une opération de service particulière, l’implémentation du service s’exécute finalement à l’aide de l’identité obtenue de WCF.

Le mode de compatibilité ASP.NET de WCF est activé au niveau de l’application à travers la configuration suivante (localisée dans le fichier Web.config de l’application) :

<system.serviceModel>
    <serviceHostingEnvironment aspNetCompatibilityEnabled="true" />
</system.serviceModel>

Cette valeur est false par défaut. La valeur false indique que tous les services WCF qui s’exécutent dans l’application s’exécutent en mode de compatibilité ASP.NET.

Parce que le mode de compatibilité ASP.NET implique des sémantiques de traitement de la demande fondamentalement différentes de la valeur par défaut de WCF, les implémentations de service individuelles peuvent contrôler si elles s’exécutent dans une application pour laquelle le mode de compatibilité ASP.NET a été activé. Les services peuvent utiliser AspNetCompatibilityRequirementsAttribute pour indiquer s'ils prennent en charge le mode de compatibilité ASP.NET. La valeur par défaut de cet attribut est Allowed.

[AspNetCompatibilityRequirements(RequirementsMode = AspNetCompatibilityRequirementsMode.Allowed)]
public class CalculatorService : ICalculatorSession
{//Implement calculator service methods.}

Le tableau suivant illustre comment le paramètre de mode de compatibilité défini au niveau de l'application interagit avec le niveau de prise en charge déclaré du service :

Pour plus d’informations sur l’activation du mode de compatibilité ASP.NET pour les services WCF, consultez AspNetCompatibilityRequirementsMode et l’échantillon ASP.NET Compatibility.

Voir aussi

• AspNetCompatibilityRequirementsAttribute
• Fonctionnalités d’hébergement de Windows Server AppFabric