Hosten in WAS (Windows Process Activation Service)

Der Windows Process Activation Service (WAS) verwaltet die Aktivierung und Lebensdauer der Arbeitsprozesse, die Windows Communication Foundation (WCF)-Dienste hostende Anwendungen enthalten. Das WAS-Prozessmodell verallgemeinert das IIS 6.0-Prozessmodell für den HTTP-Server durch das Entfernen der Abhängigkeit von HTTP. Dies ermöglicht WCF-Diensten die Verwendung von HTTP- und Nicht-HTTP-Protokollen, beispielsweise Net.TCP, in einer Hostumgebung, die nachrichtenbasierte Aktivierung unterstützt und die Möglichkeit zum Hosten vieler Anwendungen auf einem bestimmten Computer bietet.

Weitere Informationen finden Sie unter zur Erstellung eines WCF-Diensts, der in der WAS-Hostumgebung ausgeführt wird, finden Sie unter Gewusst wie: Hosten eines WCF-Diensts in WAS.

Das WAS-Prozessmodell bietet verschiedene Funktionen, die ermöglichen, Anwendungen auf robustere, besser verwaltbare und ressourcenschonendere Weise zu hosten:

  • Nachrichtenbasierte Aktivierung von Anwendungen und Arbeitsprozessen. Anwendungen werden dynamisch gestartet und beendet, in Reaktion auf mithilfe von HTTP- und Nicht-HTTP-Netzwerkprotokollen eintreffende Arbeitsaufgaben.

  • Robustes Wiederverwenden von Anwendungen und Arbeitsprozessen, um den Systemzustand laufender Anwendungen aufrechtzuerhalten.

  • Zentralisierte Anwendungskonfiguration und -verwaltung.

  • Ermöglicht Anwendungen, die Vorteile des IIS-Prozessmodells zu nutzen, ohne dass der Bereitstellungsaufwand einer vollständigen IIS-Installation erforderlich wäre.

Weitere Informationen finden Sie unter die WAS-Funktionen finden Sie unter IIS 7.0 Beta: IIS 7.0 Web Administration.

Windows Server AppFabric stellt durch die Zusammenarbeit mit IIS 7.0 und dem Windows-Prozessaktivierungsdienst (WAS) eine vielseitige Anwendungshostingumgebung für NET4 WCF- und WF-Dienste bereit. Vorteile sind u. a. die Verwaltung von Prozesslebenszyklen, die Prozesswiederverwendung, freigegebenes Hosting, rascher Ausfallschutz, Verwaisen von Prozessen, die Aktivierung bei Bedarf und die Systemüberwachung. Ausführliche Informationen finden Sie unter AppFabric-Hostingfunktionen und AppFabric-Hostingkonzepte.

Elemente des WAS-Adressierungsmodells

Anwendungen besitzen Uniform Resource Identifier (URI)-Adressen. Diese stellen die Codeeinheiten dar, deren Lebensdauer und Ausführungsumgebung vom Server verwaltet werden. Eine einzelne WAS-Serverinstanz kann viele verschiedene Anwendungen beherbergen. Server fassen Anwendungen zu Sites genannten Gruppen zusammen. Innerhalb einer Site sind die Anwendungen entsprechend der Struktur der URIs, die als ihre externen Adressen dienen, hierarchisch angeordnet.

Anwendungsadressen bestehen aus zwei Teilen: einem Basis-URI-Präfix und einer anwendungsspezifischen, relativen Adresse (Pfad), die zusammen die externe Adresse einer Anwendung ergeben. Das Basis-URI-Präfix wird aus der Sitebindung erstellt und für alle Anwendungen innerhalb dieser Site verwendet. Diesem Basis-URI-Präfix (beispielsweise "net.tcp:\/\/localhost") werden dann anwendungsspezifische Pfadfragmente (beispielsweise "\/applicationOne") angefügt, wodurch ein vollständiger Anwendungs-URI entsteht.

In der folgenden Tabelle werden mehrere mögliche Adressierungsszenarien für WAS-Sites mit HTTP- und Nicht-HTTP-Sitebindungen gezeigt.

Szenario Sitebindungen Anwendungspfad Basis-URIs der Anwendung
Nur HTTP http: *:80:* \/appTwo http:\/\/localhost\/appTwo\/
Sowohl HTTP als auch Nicht-HTTP http: *:80:*

net.tcp: 808:*
\/appTwo http:\/\/localhost\/appTwo\/
net.tcp:\/\/localhost\/appTwo\/
Nur Nicht-HTTP net.pipe: * \/appThree net.pipe:\/\/appThree\/

Dienste und Ressourcen innerhalb einer Anwendung können ebenfalls adressiert werden. Innerhalb einer Anwendung werden Anwendungsressourcen mit zum Basisanwendungspfad relativen Adressen angesprochen. Nehmen Sie zum Beispiel an, eine Site auf einem Computer namens contoso.com verfügt über Sitebindungen sowohl für das HTTP- als auch das Net.TCP-Protokoll. Nehmen Sie weiter an, dass die Site eine Anwendung im Verzeichnis \/Billing enthält, die den Dienst GetOrders.svc verfügbar macht. Wenn dann der Dienst GetOrders.svc einen Endpunkt mit der relativen Adresse SecureEndpoint verfügbar macht, kann der Dienstendpunkt über die beiden folgenden URIs angesprochen werden:

http:\/\/contoso.com\/Billing\/GetOrders.svc\/SecureEndpoint
net.tcp:\/\/contoso.com\/Billing\/GetOrders.svc\/SecureEndpoint

Die WAS-Laufzeit

Anwendungen werden für die Zwecke der Adressierung und Verwaltung in Sites organisiert. Zur Laufzeit werden Anwendungen auch in Anwendungspools zusammengefasst. Ein Anwendungspool kann viele verschiedene Anwendungen vieler anderer Sites enthalten. Alle Anwendungen innerhalb eines Anwendungspools teilen sich einen Satz allgemeiner Laufzeiteigenschaften. Sie alle werden beispielsweise unter der gleichen Version der Common Language Runtime (CLR) ausgeführt und verwenden eine gemeinsame Prozessidentität. Jeder Anwendungspool entspricht einer Instanz eines Arbeitsprozesses (w3wp.exe). Jede innerhalb eines gemeinsamen Anwendungspools ausgeführte verwaltete Anwendung ist mittels einer CLR-AppDomain von anderen Anwendungen isoliert.

Siehe auch

WAS-Aktivierungsarchitektur
Konfigurieren von WAS zur Verwendung mit WCF
Gewusst wie: Installieren und Konfigurieren von WCF-Aktivierungskomponenten
Gewusst wie: Hosten eines WCF-Diensts in WAS
Windows Server AppFabric-Hostingfunktionen