WCF-Dienste und ASP.NET
In diesem Thema wird das parallele Hosten von WCF-Diensten (Windows Communication Foundation) mit ASP.NET und Hosten dieser Dienste im ASP.NET-Kompatibilitätsmodus erläutert.
Paralleles Hosten von WCF mit ASP.NET
In Internetinformationsdiensten (IIS) gehostete WCF-Dienste können mit ASPX-Seiten und ASMX-Webdiensten in einer einzelnen, gemeinsamen Anwendungsdomäne untergebracht werden. ASP.NET bietet sowohl für WCF als auch für die ASP.NET HTTP-Runtime 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-Runtime 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 derselben 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 statischer Variablen, Ereignisse 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 und höher 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-Runtime 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 URL-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 werden WCF-Anforderungen als IIS-Prozessidentität ausgeführt, 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-Hostinginfrastruktur 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:
HttpContext: Im ASP.NET-Kompatibilitätsmodus laufende 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 aktuellen 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 Datei „Web.config“ der Anwendung) aktiviert:
<system.serviceModel>
<serviceHostingEnvironment aspNetCompatibilityEnabled="true" />
</system.serviceModel>
Wenn keine Angabe erfolgt, lautet der Standardwert false. Die Festlegung dieses Werts auf false zeigt an, dass alle in der Anwendung ausgeführten WCF-Dienste nicht im ASP.NET-Kompatibilitätsmodus ausgeführt werden.
Da der ASP.NET-Kompatibilitätsmodus eine Semantik der Anforderungsverarbeitung impliziert, die sich grundlegend von der des WCF-Standards unterscheidet, 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. Der Standardwert für dieses Attribut ist Allowed.
[AspNetCompatibilityRequirements(RequirementsMode = AspNetCompatibilityRequirementsMode.Allowed)]
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 und im Beispiel ASP.NET-Kompatibilität.