Empfohlene Vorgehensweisen für das Hosten in Internetinformationsdiensten
In diesem Thema werden einige empfohlene Vorgehensweisen für das Hosten von Windows Communication Foundation (WCF)-Diensten beschrieben.
Implementieren von WCF-Diensten als DLLs
Durch die Implementierung eines WCF-Diensts als DLL, die im Verzeichnis "\bin" einer Webanwendung bereitgestellt wird, können Sie den Dienst außerhalb des Webanwendungsmodells wiederverwenden, z. B. in einer Testumgebung, die möglicherweise keine Internetinformationsdienste (Internet Information Services, IIS) bereitgestellt hat.
Diensthosts in IIS-gehosteten Anwendungen
Verwenden Sie nicht die imperativen Selbsthosting-APIs zum Erstellen von neuen Diensthosts, die bei Netzwerktransporten lauschen, die von der IIS-Hostumgebung systemseitig nicht unterstützt werden (z. B. IIS 6.0 zum Hosten von TCP-Diensten, weil die TCP-Kommunikation in IIS 6.0 systemseitig nicht unterstützt wird). Diese Vorgehensweise wird nicht empfohlen. Imperativ erstellte Diensthosts sind innerhalb der IIS-Hostumgebung nicht bekannt. Die Schwierigkeit liegt darin, dass Verarbeitungen, die von imperativ erstellten Diensten ausgeführt werden, von IIS bei der Ermittlung, ob der Hostanwendungspool im Leerlauf ist, nicht berücksichtigt werden. Das Ergebnis ist, dass Anwendungen, die über solche imperativ erstellten Diensthosts verfügen, sich in einer IIS-Hostumgebung befinden, die IIS-Hostprozesse aggressiv freigibt.
URIs und IIS-gehostete Endpunkte
Endpunkte für einen IIS-gehosteten Dienst sollten mit relativen URIs (Uniform Resource Identifier) statt mit absoluten Adressen konfiguriert werden. Dadurch wird sichergestellt, dass die Endpunktadresse innerhalb des Satzes von URI-Adressen liegt, die zur Hostanwendung gehören und dafür sorgen, dass die nachrichtenbasierte Aktivierung wie erwartet ausgeführt wird.
Zustandsverwaltung und Prozesswiederverwendung
Die IIS-Hostumgebung ist für Dienste optimiert, die keinen lokalen Zustand im Arbeitsspeicher speichern. IIS verwendet den Hostprozess als Reaktion auf verschiedene externe und interne Ereignisse wieder, was dazu führt, dass Daten, die ausschließlich im Arbeitsspeicher im flüchtigen Zustand gespeichert werden, verloren gehen. In IIS gehostete Dienste sollten ihren Status prozessextern speichern (beispielsweise in einer Datenbank) oder in einem speicherinternen Cache, der einfach wiederhergestellt werden kann, wenn ein Wiederverwendungsereignis für eine Anwendung eintritt.
Hinweis
Die Protokolle, die WCF für die Zuverlässigkeit und Sicherheit auf Nachrichtenebene verwendet, nutzen den flüchtigen speicherinternen Status. Zuverlässige WCF-Sitzungen und -Sicherheitssitzungen werden aufgrund von Anwendungswiederverwendungen möglicherweise unerwartet beendet. Von IIS gehostete Anwendungen, die diese Protokolle nutzen, sollten sich beim Korrelieren des Anwendungsschichtstatus entweder nach etwas anderem als dem von WCF bereitgestellten Sitzungsschlüssel richten (beispielsweise einem Anwendungsschichtkonstrukt oder einem benutzerdefinierten Korrelationsheader) oder die Wiederverwendung von IIS-Prozessen für die gehostete Anwendung deaktivieren.
Optimieren der Leistung in Szenarien der mittleren Ebene
Zum Erreichen von optimaler Leistung in einem Szenario der mittleren Ebene – einem Dienst, der als Reaktion auf eingehende Nachrichten andere Dienste aufruft – instanziieren Sie den WCF-Dienstclient für den Remotedienst einmal, und verwenden Sie ihn wieder in mehreren eingehenden Anforderungen. Im Vergleich zum Ausführen eines Dienstaufrufs für eine bereits vorhandene Clientinstanz ist die Instanziierung von WCF-Dienstclients ein aufwendiger Vorgang, und Szenarien der mittleren Ebene führen durch die anforderungsübergreifende Zwischenspeicherung von Remoteclients zu deutlichen Leistungssteigerungen. Weil WCF-Dienstclients threadsicher sind, muss der Zugriff auf einen Client nicht über mehrere Threads hinweg synchronisiert werden.
Szenarien der mittleren Ebene erzeugen außerdem Leistungssteigerungen durch Verwendung von asynchronen, von der svcutil /a-Option generierten APIs. Die Option /a bewirkt, dass das ServiceModel Metadata Utility-Tool (Svcutil.exe)BeginXXX/EndXXX-Methoden für jeden Dienstvorgang generiert. Dadurch wird es ermöglicht, potenziell zeitintensive Aufrufe von Remotediensten in Hintergrundthreads durchzuführen.
WCF in Szenarien mit mehreren Adressen oder mehreren Namen
Sie können WCF-Dienste innerhalb einer IIS-Webfarm bereitstellen, in der eine Gruppe von Computern einen gemeinsamen externen Namen (z. B. http://www.contoso.com) hat, aber durch verschiedene Hostnamen einzeln adressiert wird (z. B. könnte http://www.contoso.com den Datenverkehr an die zwei verschiedenen Computer http://machine1.internal.contoso.com und http://machine2.internal.contoso.com leiten). Dieses Bereitstellungsszenario wird von WCF vollständig unterstützt, erfordert aber eine spezielle Konfiguration der IIS-Website, die WCF-Dienste hostet, damit der richtige (externe) Hostname in den Metadaten des Diensts (Web Services Description Language) angezeigt wird.
Wenn Sie sicherstellen möchten, dass der richtige Hostname in den von WCF generierten Metadaten des Diensts angezeigt wird, konfigurieren Sie die Standardidentität für die IIS-Website, auf der WCF-Dienste gehostet werden, zur Verwendung eines expliziten Hostnamens. Beispiel: Computer, die sich innerhalb der Webfarm www.contoso.com befinden, sollten die IIS-Sitebindung „*:80:www.contoso.com“ für HTTP und „*:443:www.contoso.com“ für HTTPS verwenden.
Sie können IIS-Websitebindungen konfigurieren, indem Sie das IIS-Snap-In der Microsoft Management Console (MMC) verwenden.
Anwendungspools, die in unterschiedlichen Benutzerkontexten ausgeführt werden, überschreiben Assemblys anderer Konten im temporären Ordner.
Wenn Sie sicherstellen möchten, dass Anwendungspools, die in unterschiedlichen Benutzerkontexten ausgeführt werden, Assemblys aus anderen Konten im Ordner für temporäre ASP.NET-Dateien nicht überschreiben können, verwenden Sie unterschiedliche Identitäten und temporäre Ordner für unterschiedliche Anwendungen. Wenn Sie beispielsweise zwei virtuelle Anwendungen /Application1 und /Application2 haben, können Sie zwei Anwendungspools (A und B) mit zwei unterschiedlichen Identitäten erstellen. Der Anwendungspool A kann unter einer Benutzeridentität ausgeführt werden (user1), während der Anwendungspool B unter einer anderen Benutzeridentität (user2) ausgeführt wird. Konfigurieren Sie /Application1 zur Verwendung von A und /Application2 zur Verwendung von B.
In „Web.config“ können Sie den temporären Ordner mithilfe von <system.web/compilation/@tempFolder> konfigurieren. Für „/Application1“ kann es sich um „c:\tempForUser1“ und für „/Application2“ um „c:\tempForUser2“ handeln. Gewähren Sie den beiden Identitäten die entsprechende Schreibberechtigung für diese Ordner.
Dann kann user2 den Codegenerierungsordner für /application2 (unter c:\tempForUser1) nicht ändern.
Aktivieren der asynchronen Verarbeitung
Standardmäßig werden Nachrichten, die an einen von IIS 6.0 und früher gehosteten WCF-Dienst gesendet wurden, synchron verarbeitet. ASP.NET ruft WCF in seinem eigenen Thread (dem ASP.NET-Arbeitsthread) auf, und WCF verwendet einen anderen Thread zum Verarbeiten der Anforderung. WCF hält die Verbindung zum ASP.NET-Arbeitsthread aufrecht, bis die Verarbeitung abgeschlossen ist. Dies hat die synchrone Verarbeitung von Anforderungen zur Folge. Die asynchrone Verarbeitung von Anforderungen ermöglicht eine größere Skalierbarkeit, weil so die Anzahl der zur Verarbeitung einer Anforderung erforderlichen Threads reduziert wird. Während der Verarbeitung der Anforderung erhält WCF die Verbindung zum ASP.NET-Thread nicht aufrecht. Die Verwendung von asynchronem Verhalten wird für Computer mit IIS 6.0 nicht empfohlen, weil eingehende Anforderungen, durch die der Server Denial Of Service (DOS)-Angriffen ausgesetzt ist, dann nicht gedrosselt werden können. Ab IIS 7.0 wurde eine Drosselung gleichzeitiger Anforderungen eingeführt: [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ASP.NET\2.0.50727.0]"MaxConcurrentRequestsPerCpu. Aufgrund dieser neuen Drosselung kann die asynchrone Verarbeitung nun gefahrlos eingesetzt werden. In IIS 7.0 werden der asynchrone Handler und das Modul standardmäßig registriert. Wenn dies deaktiviert wurde, können Sie die asynchrone Verarbeitung von Anforderungen in der Datei Web.config der Anwendung manuell aktivieren. Die verwendeten Einstellungen richten sich nach Ihrer aspNetCompatibilityEnabled-Einstellung. Wenn aspNetCompatibilityEnabled auf false festgelegt ist, konfigurieren Sie System.ServiceModel.Activation.ServiceHttpModule wie im folgenden Konfigurationsausschnitt dargestellt.
<system.serviceModel>
<serviceHostingEnvironment aspNetCompatibilityEnabled="false" />
</system.serviceModel>
<system.webServer>
<modules>
<remove name="ServiceModel"/>
<add name="ServiceModel"
preCondition="integratedMode,runtimeVersionv2.0"
type="System.ServiceModel.Activation.ServiceHttpModule, System.ServiceModel,Version=3.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089"/>
</modules>
</system.webServer>
Wenn aspNetCompatibilityEnabled auf true festgelegt ist, konfigurieren Sie System.ServiceModel.Activation.ServiceHttpHandlerFactory wie im folgenden Konfigurationsausschnitt dargestellt.
<system.serviceModel>
<serviceHostingEnvironment aspNetCompatibilityEnabled="true" />
</system.serviceModel>
<system.webServer>
<handlers>
<clear/>
<add name="TestAsyncHttpHandler"
path="*.svc"
verb="*"
type="System.ServiceModel.Activation.ServiceHttpHandlerFactory, System.ServiceModel, Version=3.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089"
/>
</handlers>
</system.webServer>