Hosten in WAS (Windows Process Activation Service)
Der Windows-Prozessaktivierungsdienst (Windows Process Activation Service, WAS) verwaltet die Aktivierung und Lebensdauer der Workerprozesse, die Anwendungen enthalten, die WCF-Dienste (Windows Communication Foundation) hosten. Das WAS-Prozessmodell generalisiert das IIS 6.0-Prozessmodell für den HTTP-Server, indem die Abhängigkeit von HTTP entfernt wird. Auf diese Weise können WCF-Dienste HTTP- und Nicht-HTTP-Protokolle (z. B. Net.TCP) in einer Hostingumgebung verwenden, die nachrichtenbasierte Aktivierung unterstützt und die Möglichkeit bietet, eine große Anzahl von Anwendungen auf einem bestimmten Computer zu hosten.
Weitere Informationen zum Erstellen eines WCF-Diensts, der in der WAS-Hostingumgebung ausgeführt wird, finden Sie unter Vorgehensweise: 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 Arbeitselemente.
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.
Windows Server AppFabric stellt durch die Zusammenarbeit mit IIS 7.0 und dem Windows-Prozessaktivierungsdienst 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-Hostingfeatures 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/SecureEndpointnet.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.