Partager via

Services WCF et ASP.NET

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

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

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

Capture d’écran montrant les services WCF et ASP .NET : état de partage.

Le runtime HTTP ASP.NET gère ASP.NET demandes, mais ne participe pas au traitement des requêtes destinées aux services WCF, même si ces services sont hébergés dans le même AppDomain que le contenu ASP.NET. Au lieu de cela, le modèle de service WCF intercepte les messages adressés aux services WCF et les route via la pile de transport/canal WCF.

Les résultats du modèle côte à côte sont les suivants :

  • ASP.NET et les services WCF peuvent partager l’état AppDomain. Étant donné que les deux frameworks 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, etc.).

  • Les services WCF se comportent de manière cohérente, indépendamment de l’environnement d’hébergement et du transport. Le runtime HTTP ASP.NET est intentionnellement couplé à l’environnement d’hébergement IIS/ASP.NET et à la communication HTTP. À l’inverse, WCF est conçu pour se comporter de manière cohérente entre les environnements d’hébergement (WCF se comporte de manière cohérente à la fois à l’intérieur et à l’extérieur d’IIS) et entre les transports (un service hébergé dans IIS 7.0 et ultérieur a un comportement cohérent sur tous les points de terminaison qu’il expose, même si certains de ces points de terminaison utilisent des protocoles autres que HTTP).

  • Dans un AppDomain, les fonctionnalités implémentées par le runtime HTTP s’appliquent à ASP.NET contenu, mais pas à WCF. De nombreuses fonctionnalités spécifiques à HTTP de la plateforme d’applications ASP.NET ne s’appliquent pas aux services WCF hébergés à l’intérieur d’un AppDomain qui contient ASP.NET contenu. Voici quelques 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 les fichiers : le modèle de sécurité WCF n’autorise pas la liste de contrôle d’accès (ACL) appliquée au fichier .svc du service lorsque vous décidez si une demande de service est autorisée.

    • Autorisation d’URL basée sur la configuration : de même, le modèle de sécurité WCF ne respecte pas les règles d’autorisation basées sur l’URL spécifiées dans l’élément de configuration d’autorisation< de >System.Web. Ces paramètres sont ignorés pour les requêtes WCF si un service réside dans un espace d’URL sécurisé par les règles d’autorisation d’URL d’ASP.NET.

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

    • ASP.NET impersonation : Par défaut, les requêtes WCF s'exécutent toujours sous l'identité de processus d'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 de ASP.NET contenu n’est pas affecté par la présence de WCF.

Les applications WCF qui nécessitent des fonctionnalités généralement fournies par le pipeline HTTP doivent envisager d’utiliser les équivalents WCF, qui sont indépendants de l’hôte et du transport :

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

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

Bien que le modèle WCF soit conçu pour se comporter de manière cohérente entre les environnements d’hébergement et les transports, il existe souvent des scénarios où une application ne nécessite pas ce degré de flexibilité. Le mode de compatibilité ASP.NET WCF convient aux scénarios qui ne nécessitent pas la possibilité d’héberger en dehors d’IIS ou de communiquer via des protocoles autres que HTTP, mais qui utilisent toutes les fonctionnalités de la plateforme d’applications 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 s’exécutant en mode de compatibilité ASP.NET participent entièrement au cycle de vie des requêtes HTTP ASP.NET. En mode de compatibilité, les services WCF utilisent le pipeline HTTP via une IHttpHandler implémentation, comme la façon dont les requêtes pour les pages ASPX et les services web ASMX sont gérées. Par conséquent, WCF se comporte de façon identique à ASMX en ce qui concerne les fonctionnalités de ASP.NET suivantes :

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

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

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

  • HttpModuleCollection extensibilité : étant donné que les services WCF s’exécutant en mode de compatibilité ASP.NET participent entièrement au cycle de vie des requêtes HTTP ASP.NET, tout module HTTP configuré dans le pipeline HTTP peut fonctionner sur les requêtes WCF avant et après l’appel de service.

  • Usurpation d'identité ASP.NET : les services WCF utilisent l'identité actuelle du thread ASP.NET usurpé, qui peut être différente de l'identité du processus IIS si l'usurpation d'identité ASP.NET a été activée pour l'application. Si l'usurpation d'identité ASP.NET et l'usurpation d'identité WCF sont toutes deux activées pour une opération de service spécifique, l'implémentation du service s'exécute finalement en utilisant l'identité obtenue via WCF.

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

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

Cette valeur est définie par défaut false si elle n’est pas spécifiée. La valeur de false indique que tous les services WCF s’exécutant dans l’application ne s’exécutent pas en mode de compatibilité ASP.NET.

Étant donné que ASP.NET mode de compatibilité implique la sémantique de traitement des demandes qui diffèrent fondamentalement de la valeur par défaut wcf, les implémentations de service individuelles ont la possibilité de contrôler s’ils s’exécutent à l’intérieur d’une application pour laquelle ASP.NET mode de compatibilité 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 montre comment le paramètre de mode de compatibilité à l’échelle de l’application interagit avec le niveau de support indiqué par le service individuel :

Paramètre mode de compatibilité à l’échelle de l’application [AspNetCompatibilityRequirementsMode]

Réglage		 Résultat observé
aspNetCompatibilityEnabled = « true » Required Le service s’active avec succès.
aspNetCompatibilityEnabled = « true » Allowed Le service s’active avec succès.
aspNetCompatibilityEnabled = « true » NotAllowed Une erreur d’activation se produit lorsque le service reçoit un message.
aspNetCompatibilityEnabled = « false » Required Une erreur d’activation se produit lorsque le service reçoit un message.
aspNetCompatibilityEnabled = « false » Allowed Le service s’active avec succès.
aspNetCompatibilityEnabled = « false » NotAllowed Le service s’active avec succès.

Remarque

IIS 7.0 et WAS permet aux services WCF de communiquer via des protocoles autres que HTTP. Toutefois, les services WCF s’exécutant dans des applications qui ont activé ASP.NET mode de compatibilité 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 et l’exemple de compatibilité ASP.NET .

Voir aussi