WCF-Dienste und ASP.NET

In diesem Thema wird das parallele Hosten von Windows Communication Foundation (WCF)-Diensten in ASP.NET und das Hosten dieser Dienste im ASP.NET-Kompatibilitätsmodus erläutert.

Paralleles Hosten in WCF und in ASP.NET

In Internetinformationsdiensten (IIS) gehostete WCF-Dienste können mit ASPX-Seiten und ASMX-Webdiensten in einer einzelnen, gemeinsamen Anwendungsdomäne gespeichert sein. ASP.NET bietet sowohl für WCF als auch für die ASP.NET HTTP-Laufzeit allgemeine Infrastrukturdienste, wie etwa AppDomain-Verwaltung und dynamische Kompilierung. Die Standardkonfiguration für WCF ist die Parallelität mit ASP.NET.

Die ASP.NET HTTP-Laufzeit behandelt ASP.NET-Anforderungen, beteiligt sich jedoch nicht an der Bearbeitung von Anforderungen, die für WCF-Dienste bestimmt sind, auch wenn diese Dienste in der gleichen AppDomain wie der ASP.NET-Inhalt gehostet werden. Vielmehr fängt das WCF-Dienstmodell Nachrichten ab, die an WCF-Dienste gerichtet sind, und leitet sie durch den WCF-Transport-/Kanalstapel.

Die Ergebnisse des parallelen Modells sind folgende:

• ASP.NET- und WCF-Dienste können den AppDomain-Zustand gemeinsam verwenden. Da die beiden Frameworks in derselben AppDomain koexistieren können, kann WCF den AppDomain-Zustand zusammen mit ASP.NET verwenden (einschließlich statischen Variablen, Ereignissen usw.).

• WCF-Dienste verhalten sich unabhängig von Hostumgebung und Transport konsistent. Die ASP.NET-HTTP-Laufzeit ist absichtlich an IIS/ASP.NET-Hostumgebung und HTTP-Kommunikation gekoppelt. Umgekehrt ist WCF für konsistentes Verhalten in Hostumgebungen (WCF verhält sich innerhalb und außerhalb von IIS konsistent) und für Transporte konzipiert (ein in IIS 7.0 gehosteter Dienst zeigt für alle Endpunkte, die er bereitstellt, ein konsistentes Verhalten, auch wenn einige dieser Endpunkte andere Protokolle als HTTP verwenden).

• Innerhalb einer AppDomain gelten von der HTTP-Laufzeit implementierte Funktionen für den ASP.NET-Inhalt, aber nicht für WCF. Viele HTTP-spezifischen Funktionen der ASP.NET-Anwendungsplattform gelten nicht für WCF-Dienste, die in einer AppDomain gehostet werden, die ASP.NET-Inhalt enthält. Im Folgenden sind Beispiele für diese Funktionen aufgeführt:

  • HttpContext: Current ist immer NULL, wenn innerhalb eines WCF-Diensts darauf zugegriffen wird. Verwenden Sie stattdessen RequestContext.

  • Dateibasierte Autorisierung: Das WCF-Sicherheitsmodell lässt bei der Entscheidung, ob eine Dienstanforderung autorisiert ist, nicht zu, dass die Zugriffssteuerungsliste (Access Control List, ACL) für die SVC-Datei des Diensts übernommen wird.

  • Konfigurationsbasierte URL-Autorisierung: Entsprechend folgt das WCF-Sicherheitsmodell keinen URL-basierten Autorisierungsregeln, die im <authorization>-Konfigurationselement von System.Web angegeben sind. Diese Einstellungen werden für WCF-Anforderungen ignoriert, wenn sich ein Dienst in einem URL-Namespace befindet, der durch die Autorisierungsregeln von ASP.NET gesichert ist.

  • HttpModule-Erweiterbarkeit: Die als Host fungierende WCF-Infrastruktur fängt WCF-Anforderungen ab, wenn das PostAuthenticateRequest-Ereignis ausgelöst wird, und gibt die Verarbeitung nicht an die HTTP-Pipeline von ASP.NET zurück. Module, die für das Abfangen von Anforderungen in späteren Phasen der Pipeline codiert sind, fangen keine WCF-Anforderungen ab.

  • ASP.NET-Identitätswechsel: Standardmäßig laufen WCF-Anforderungen als IIS-Prozessidentität, auch wenn für ASP.NET Identitätswechsel mithilfe der Konfigurationsoption <identity impersonate=”true” /> von System.Web aktiviert sind.

Diese Einschränkungen gelten nur für in IIS gehostete WCF-Dienste. Das Verhalten des ASP.NET-Inhalts wird nicht durch das Vorhandensein von WCF beeinflusst.

Bei WCF-Anwendungen, die die Funktionalität benötigen, die traditionell von der HTTP-Pipeline geboten wird, sollte die Verwendung der WCF-Entsprechungen erwogen werden. Sie sind von Host und Transport unabhängig:

• OperationContext anstelle von HttpContext.

• ServiceAuthorizationBehavior statt der Datei-/URL-Autorisierung von ASP.NET.

• IDispatchMessageInspector oder benutzerdefinierte überlagerte Kanäle statt der HTTP-Module.

• Identitätswechsel für jeden Vorgang mit WCF statt des System.Web-Identitätswechsels.

Alternativ können Sie erwägen, die Dienste im ASP.NET Kompatibilitätsmodus von WCF auszuführen.

Hosten von WCF-Diensten im ASP.NET-Kompatibilitätsmodus

Zwar ist das WCF-Modell für konsistentes Verhalten in Hostumgebungen und für Transporte konzipiert, doch sind Szenarien häufig, in denen Anwendungen dieses Maß an Flexibilität nicht benötigen. Der ASP.NET-Kompatibilitätsmodus von WCF ist für Szenarien geeignet, in denen das Hosting außerhalb von IIS oder die Möglichkeit, mit anderen Protokollen als HTTP zu kommunizieren, nicht erforderlich ist, wohl aber die Verwendung aller Funktionen der ASP.NET-Webanwendungsplattform.

Im Unterschied zur standardmäßigen parallelen Konfiguration, bei der die WCF-Infrastruktur WCF-Nachrichten abfängt und sie von der HTTP-Pipeline wegleitet, nehmen im ASP.NET-Kompatibilitätsmodus ausgeführte WCF-Dienste voll am ASP.NET HTTP-Anforderungslebenszyklus teil. Im Kompatibilitätsmodus verwenden WCF-Dienste die HTTP-Pipeline über eine IHttpHandler-Implementierung, also auf ähnliche Weise, wie Anforderungen für ASPX-Seiten und ASMX-Webdienste behandelt werden. Im Ergebnis verhält sich WCF in Bezug auf die folgenden ASP.NET-Funktionen identisch mit ASMX:

• Im ASP.NET-Kompatibilitätsmodus laufende HttpContext: WCF-Dienste können auf Current und den zugehörigen Status zugreifen.

• Dateibasierte Autorisierung: Im ASP.NET-Kompatibilitätsmodus laufende WCF-Dienste können abgesichert werden, indem der SVC-Datei des Diensts Dateisystem-Zugriffssteuerungslisten angehängt werden.

• Konfigurierbare URL-Autorisierung: Die Autorisierungsregeln von ASP.NET werden für WCF-Anforderungen erzwungen, wenn der WCF-Dienst im ASP.NET-Kompatibilitätsmodus ausgeführt wird.

• HttpModuleCollection-Erweiterbarkeit: Weil im ASP.NET-Kompatibilitätsmodus ausgeführte WCF-Dienste voll am ASP.NET HTTP-Anforderungslebenszyklus teilnehmen, kann jedes in der HTTP-Pipeline konfigurierte HTTP-Modul mit WCF-Anforderungen vor und nach dem Dienstaufruf arbeiten.

• ASP.NET-Identitätswechsel: WCF-Dienste laufen unter der Identität, die der ASP.NET-Thread angenommen hat, und der sich von der IIS-Prozessidentität unterscheiden kann, wenn ASP.NET-Identitätswechsel für die Anwendung aktiviert wurde. Sind für einen bestimmten Dienstvorgang sowohl ASP.NET-Identitätswechsel als auch WCF-Identitätswechsel aktiviert, wird die Dienstimplementierung letztlich unter der Identität ausgeführt, die von WCF bezogen wurde.

Der ASP.NET-Kompatibilitätsmodus von WCF wird auf der Anwendungsebene über die folgende Konfiguration (in der Web.config-Datei der Anwendung) aktiviert:

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

Wenn keine Angabe erfolgt, lautet der Standardwert "false". Die Festlegung dieses Werts auf "true" zeigt an, dass alle in der Anwendung laufenden WCF-Dienste im ASP.NET-Kompatibilitätsmodus ausgeführt werden.

Da der ASP.NET-Kompatibilitätsmodus eine Semantik der Anforderungsverarbeitung impliziert, die grundlegend von der des WCF-Standards verschieden ist, haben die einzelnen Dienstimplementierungen die Möglichkeit zu steuern, ob sie innerhalb einer Anwendung laufen, für die der ASP.NET-Kompatibilitätsmodus aktiviert wurde. Dienste können das AspNetCompatibilityRequirementsAttribute verwenden, um anzugeben, ob sie den ASP.NET-Kompatibilitätsmodus unterstützen.

[AspNetCompatibilityRequirements(RequirementsMode = AspNetCompatibilityRequirementsMode.Required)]

public class CalculatorService : ICalculatorSession

{//Implement calculator service methods.}

In der folgenden Tabelle wird gezeigt, wie die Einstellung des anwendungsweiten Kompatibilitätsmodus mit der vom jeweiligen Dienst angegebenen Unterstützungsebene interagiert:

Anwendungsweite Einstellung des Kompatibilitätsmodus	[AspNetCompatibilityRequirementsMode] Einstellung	Beobachtetes Ergebnis
aspNetCompatibilityEnabled = "true"	Required	Dienst wird erfolgreich aktiviert.
aspNetCompatibilityEnabled = "true"	Allowed	Dienst wird erfolgreich aktiviert.
aspNetCompatibilityEnabled = "true"	NotAllowed	Ein Aktivierungsfehler tritt auf, wenn der Dienst eine Nachricht empfängt.
aspNetCompatibilityEnabled = "false"	Required	Ein Aktivierungsfehler tritt auf, wenn der Dienst eine Nachricht empfängt.
aspNetCompatibilityEnabled = "false"	Allowed	Dienst wird erfolgreich aktiviert.
aspNetCompatibilityEnabled = "false"	NotAllowed	Dienst wird erfolgreich aktiviert.

Hinweis:
IIS 7.0 und WAS ermöglichen WCF-Diensten, über andere Protokolle als HTTP zu kommunizieren. Allerdings dürfen WCF-Dienste, die in Anwendungen laufen, für die der ASP.NET-Kompatibilitätsmodus aktiviert ist, keine Nicht-HTTP-Endpunkte verfügbar machen. Eine solche Konfiguration generiert eine Aktivierungsausnahme, wenn der Dienst seine erste Nachricht empfängt.

Weitere Informationen über das Aktivieren des ASP.NET-Kompatibilitätsmodus für WCF-Dienste finden Sie unter AspNetCompatibilityRequirementsMode.

Siehe auch

Verweis

AspNetCompatibilityRequirementsAttribute

Weitere Ressourcen

Windows Server AppFabric-Hostingfunktionen