Services WCF et ASP.NET

Cette rubrique présente les services Windows Communication Foundation (WCF) d'hébergement côte à côte avec ASP.NET et leur hébergement en mode de compatibilité ASP.NET.

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

Les services WCF hébergés dans les services IIS (Internet Information Services) peuvent être localisés avec les pages.ASPX et les services Web ASMX dans un domaine d'application unique et commun. ASP.NET fournit des services d'infrastructure communs tels que la gestion AppDomain et la compilation dynamique pour WCF et l'exécution d'ASP.NET http à la fois. La configuration par défaut de 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/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 AppDomain. Parce que les deux infrastructures peuvent coexister dans le même AppDomain, WCF peut également partager l'état 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 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 à 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 lorsqu'il est accédé à partir d'un service WCF. Utilisez plutôt RequestContext.

  • 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 d'URL basée sur la configuration : de la même façon, le modèle de sécurité WCF n'adhère pas à toutes les règles d'autorisation basées sur URL spécifiées 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 WCF 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 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 : parce que 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, 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 par défaut "false" si non spécifiée. Définir cette valeur sur "true" 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.

[AspNetCompatibilityRequirements(RequirementsMode = AspNetCompatibilityRequirementsMode.Required)]

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 :

Remarque :
IIS 7.0 et WAS autorisent la communication des services WCF sur des protocoles autres que HTTP. Toutefois, les services WCF qui s'exécutent dans les applications qui ont activé le mode de compatibilité ASP.NET ne sont pas autorisés à exposer des points de terminaison non-HTTP. Une telle configuration génère une exception d'activation lorsque le service reçoit son premier message.

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

Voir aussi

Référence

AspNetCompatibilityRequirementsAttribute

Autres ressources

Fonctionnalités d'hébergement de Windows Server AppFabric