Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
Der Windows-Prozessaktivierungsdienst (WAS) verwaltet die Aktivierung und Lebensdauer der Arbeitsprozesse, die Anwendungen enthalten, die Windows Communication Foundation (WCF)-Dienste 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 sowohl HTTP- als auch Nicht-HTTP-Protokolle wie Net.TCP in einer Hostingumgebung verwenden, die die nachrichtenbasierte Aktivierung unterstützt, und bietet die Möglichkeit, 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 How to: Host a WCF Service in WAS.
Das WAS-Prozessmodell bietet mehrere Features, mit denen Anwendungen so gehostet werden können, dass sie robuster, verwaltbarer sind und Ressourcen effizient nutzen:
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 Recycling von Anwendungen und Arbeitsprozessen, um die Integrität der ausgeführten Anwendungen aufrechtzuerhalten.
Zentrale Anwendungskonfiguration und -verwaltung.
Ermöglicht Anwendungen die Nutzung des IIS-Prozessmodells, ohne dass der Bereitstellungsbedarf einer vollständigen IIS-Installation erforderlich ist. Windows Server AppFabric arbeitet mit IIS 7.0 und dem Windows Process Activation Service (WAS) zusammen, um eine umfassende Anwendungshostingumgebung für NET4 WCF- und WF-Dienste bereitzustellen. 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 Hosting Features und AppFabric Hosting Concepts.
Elemente des WAS-Adressierungsmodells
Anwendungen verfügen über URI-Adressen (Uniform Resource Identifier), bei denen es sich um Codeeinheiten handelt, deren Lebensdauer und Ausführungsumgebung vom Server verwaltet werden. Eine einzelne WAS-Serverinstanz kann viele verschiedene Anwendungen beherbergen. Server organisiert Anwendungen in Gruppen namens Sites. Innerhalb einer Website werden Anwendungen hierarchisch angeordnet, die die Struktur der URIs widerspiegeln, die als externe Adressen dienen.
Anwendungsadressen verfügen über zwei Teile: ein Basis-URI-Präfix und eine anwendungsspezifische relative Adresse (Pfad), die die externe Adresse für eine Anwendung bereitstellen, wenn sie zusammengefügt wird. Das Basis-URI-Präfix wird aus der Websitebindung erstellt und für alle Anwendungen unter der Website verwendet. Anwendungsadressen werden erstellt, indem anwendungsspezifische Pfadfragmente (z. B. "/applicationOne") genommen und an das Basis-URI-Präfix (z. B. "net.tcp://localhost") angehängt werden, um den vollständigen Anwendungs-URI zu erzielen.
In der folgenden Tabelle sind mehrere mögliche Adressierungsszenarien für WAS-Websites mit HTTP- und Nicht-HTTP-Websitebindungen dargestellt.
| Szenario | Sitebindungen | Anwendungspfad | Basisanwendungs-URIs |
|---|---|---|---|
| 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 relativ zum Basisanwendungspfad adressiert. Gehen Sie beispielsweise davon aus, dass eine Website auf einem Computernamen contoso.com Websitebindungen sowohl für die HTTP- als auch für die Net.TCP-Protokolle enthält. Gehen Sie auch davon aus, dass die Website eine Anwendung enthält, die sich in /Billing befindet, die einen Dienst bei GetOrders.svc verfügbar macht. Wenn der GetOrders.svc-Dienst einen Endpunkt mit einer relativen Adresse von SecureEndpoint verfügbar macht, wird der Dienstendpunkt dann an den folgenden beiden URIs verfügbar gemacht:
http://contoso.com/Billing/GetOrders.svc/SecureEndpointnet.tcp://contoso.com/Billing/GetOrders.svc/SecureEndpoint
Die WAS-Laufzeit
Anwendungen werden zu Adressierungs- und Verwaltungszwecken in Websites organisiert. Zur Laufzeit werden Anwendungen auch in Anwendungspools gruppiert. Ein Anwendungspool kann viele verschiedene Anwendungen von vielen verschiedenen Standorten enthalten. Alle Anwendungen innerhalb eines Anwendungspools teilen einen gemeinsamen Satz von Laufzeitmerkmalen. Beispielsweise werden sie alle unter derselben Version der Common Language Runtime (CLR) ausgeführt, und sie alle teilen eine gemeinsame Prozessidentität. Jeder Anwendungspool entspricht einer Instanz eines Arbeitsprozesses (w3wp.exe). Jede verwaltete Anwendung, die innerhalb eines freigegebenen Anwendungspools ausgeführt wird, ist über eine CLR-AppDomain von anderen Anwendungen isoliert.