Hostingdienste

Zur Aktivierung muss der Dienst in einer Laufzeitumgebung gehostet werden, die ihn erstellt und seinen Kontext sowie seine Lebensdauer steuert. WCF-Dienste (Windows Communication Foundation) können in jedem Windows-Prozess ausgeführt werden, der verwalteten Code unterstützt.

WCF stellt ein einheitliches Programmiermodell zum Erstellen von dienstorientierten Anwendungen bereit. Dieses Programmiermodell bleibt konsistent und ist von der Laufzeitumgebung unabhängig, in der der Dienst bereitgestellt wird. In der Praxis bedeutet das, dass der Code für Dienste relativ unabhängig von der Hostingoption ist.

Die Hostingoptionen reichen von einfachen Konsolenanwendungen bis zu Serverumgebungen, z. B. ein Windows-Dienst, der in einem Arbeitsprozess unter Internetinformationsdiensten (IIS) oder Windows Activation Service (WAS) ausgeführt wird. Entwickler wählen die Hostumgebung aus, die die Bereitstellungsanforderungen des Diensts erfüllt. Diese Anforderungen können von der Plattform, auf der die Anwendung bereitgestellt wird, dem Transportprotokoll, mit dem Nachrichten gesendet und empfangen werden müssen, dem Typ der Prozesswiederverwendung oder anderen Prozessverwaltungsfunktionen, die zur Sicherstellung adäquater Verfügbarkeit erforderlich sind, anderen Verwaltungsanforderungen oder Anforderungen bezüglich der Zuverlässigkeit abhängig sein. Im nächsten Abschnitt erhalten Sie Informationen und Hinweise zu Hostingoptionen.

Hostingoptionen

Selbsthosting in einer verwalteten Anwendung

WCF-Dienste können in jeder verwalteten Anwendung gehostet werden. Dies ist die flexibelste Option, da hier die wenigste Infrastruktur bereitzustellen ist. Sie betten den Code für den Dienst in den verwalteten Anwendungscode ein und erstellen und öffnen dann eine Instanz von ServiceHost , um den Dienst zur Verfügung zu stellen. Weitere Informationen finden Sie unter Vorgehensweise: Hosten eines WCF-Diensts in einer verwalteten Anwendung.

Diese Option ermöglicht zwei gängige Szenarien: WCF-Dienste, die in einer Konsolenanwendung ausgeführt werden, und Rich Client-Anwendungen, wie die auf WPF (Windows Presentation Foundation) oder Windows Forms (WinForms) basierenden Anwendungen. Einen WCF-Dienst in einer Konsolenanwendung zu hosten, ist in der Regel während der Entwicklungsphase der Anwendung nützlich. Die Anwendung lässt sich dann einfach debuggen. Ablaufverfolgungsinformationen über die Anwendung lassen sich leichter ermitteln, um herauszufinden, was intern in der Anwendung vor sich geht. Zudem lässt sich die Anwendung dann einfacher an andere Speicherorte kopieren. Diese Hostingoption erleichtert es Rich Client-Anwendungen, wie WPF- und WinForms-Anwendungen, mit der Außenwelt zu kommunizieren. Ein Beispiel dafür ist ein Peer-to-Peer-Kollaborationsclient, der WPF als Benutzeroberfläche nutzt und darüber hinaus als Host für einen WCF-Dienst fungiert, der anderen Clients ermöglicht, eine Verbindung mit ihm herzustellen und Daten auszutauschen.

Verwaltete Windows-Dienste

Diese Hostingoption besteht in der Registrierung der Anwendungsdomäne (AppDomain), die einen WCF-Dienst als verwalteten Windows-Dienst (früher NT-Dienst genannt) hostet, sodass die Prozesslebensdauer des Diensts vom Dienststeuerungs-Manager (Service Control Manager, SCM) für Windows gesteuert wird. Wie bei der Selbsthosting-Option muss auch bei diesem Typ von Hostumgebung ein Teil des Hostingcodes Bestandteil des Anwendungscodes sein. Der Dienst wird sowohl als Windows-Dienst als auch als WCF-Dienst implementiert, indem er von der ServiceBase-Klasse und von einer WCF-Dienstvertragsschnittstelle abgeleitet wird. Die ServiceHost -Instanz wird erstellt, mit einer überschriebenen OnStart(String[]) -Methode geöffnet und mit einer überschriebenen OnStop() -Methode geschlossen. Außerdem muss eine Installerklasse implementiert werden, die von Installer abgeleitet ist, damit das Programm mit dem Tool Installutil.exe als Windows-Dienst installiert werden kann. Weitere Informationen finden Sie unter Vorgehensweise: Hosten eines WCF-Diensts in einem verwalteten Windows-Dienst. Das Szenario, das durch die Hostingoption des verwalteten Windows-Diensts ermöglicht wird, besteht in einem WCF-Dienst mit langer Laufzeit, der außerhalb der Internetinformationsdienste (IIS) in einer sicheren, nicht nachrichtenaktivierten Umgebung gehostet wird. Die Lebensdauer des Diensts wird stattdessen vom Betriebssystem gesteuert. Diese Hostingoption ist in allen Windows-Versionen verfügbar.

Internetinformationsdienste (IIS)

Die IIS-Hostingoption ist in ASP.NET integriert und nutzt die Features dieser Technologie, beispielsweise die Prozesswiederverwendung, das Herunterfahren bei Leerlauf, die Prozessüberwachung und die nachrichtenbasierte Aktivierung. Unter den Betriebssystemen Windows XP und Windows Server 2003 ist dies die bevorzugte Lösung für das Hosten von Webdienstanwendungen, die stets verfügbar und weitgehend skalierbar sein müssen. IIS bietet zudem die integrierte Verwaltbarkeit, die Kunden von einem Serverprodukt für Unternehmen erwarten. Diese Hostingoption erfordert, dass IIS korrekt konfiguriert wurde, jedoch muss keinerlei Hostcode für die Anwendung geschrieben werden. Weitere Informationen zum Konfigurieren von IIS-Hosting für einen WCF-Dienst finden Sie unter Vorgehensweise: Hosten eines WCF-Diensts in IIS.

Von IIS gehostete Dienste nur den HTTP-Transport verwenden. Mit der Implementierung in IIS 5.1 wurden einige Einschränkungen in Windows XP eingeführt. Durch die nachrichtenbasierte Aktivierung, die von IIS 5.1 unter Windows XP für einen WCF-Dienst bereitgestellt wird, werden alle anderen selbst gehosteten WCF-Dienste auf demselben Computer daran gehindert, Port 80 für die Kommunikation zu verwenden. WCF-Dienste können im gleichen AppDomain-/Anwendungspool-/Workerprozess wie andere Anwendungen ausgeführt werden, wenn sie von IIS 6.0 unter Windows Server 2003 gehostet werden. Weil jedoch sowohl WCF als auch IIS 6.0 den HTTP-Stapel (HTTP.sys) des Kernelmodus verwenden, kann IIS 6.0 im Gegensatz zu IIS 5.1 den Port 80 mit anderen selbstgehosteten WCF-Diensten, die auf demselben Computer ausgeführt werden, gemeinsam nutzen.

Windows Process Activation Service (WAS)

Der Windows-Prozessaktivierungsdienst (Windows Process Activation Service, WAS) ist der neue Prozessaktivierungsmechanismus für Windows Server 2008, der auch unter Windows Vista verfügbar ist. In WAS wurden das bekannte IIS 6.0-Prozessmodell (Anwendungspools und nachrichtenbasierte Prozessaktivierung) und Hostingfunktionen (z. B. schneller Ausfallschutz, Systemüberwachung und Wiederverwendung) beibehalten, jedoch wurde die Abhängigkeit von HTTP aus der Aktivierungsarchitektur getilgt. IIS 7.0 nutzt WAS zur nachrichtenbasierten Aktivierung über HTTP. Zusätzliche WCF-Komponenten sind in WAS integrierbar, um die nachrichtenbasierte Aktivierung mit anderen von WCF unterstützten Protokollen zu ermöglichen, wie TCP, MSMQ und Named Pipes. Dies ermöglicht es Anwendungen, die mit Kommunikationsprotokollen arbeiten, die IIS-Features zu nutzen, die nur für HTTP-basierte Anwendungen verfügbar waren, beispielsweise die Prozesswiederverwendung, den schnellen Fehlerschutz und das gemeinsame Konfigurationssystem.

Diese Hostingoption erfordert, dass WAS korrekt konfiguriert wurde, jedoch muss keinerlei Hostcode für die Anwendung geschrieben werden. Weitere Informationen zum Konfigurieren von WAS-Hosting finden Sie unter Vorgehensweise: Hosten eines WCF-Diensts in WAS.

Auswählen einer Hostumgebung

In der folgenden Tabelle werden einige wichtige Vorteile und Szenarien im Zusammenhang mit den verschiedenen Hostingoptionen zusammengefasst.

Hostumgebung Häufige Szenarios Hauptvorteile und Einschränkungen
Verwaltete Anwendung ("Selbsthosting") - Während der Entwicklung verwendete Konsolenanwendungen
- Rich Client-Anwendungen für WinForm und WPF, die auf Dienste zugreifen
- Flexibel
- Einfach bereitzustellen
- Keine Unternehmenslösung für Dienste
Windows-Dienste (früher als NT-Dienste bezeichnet) - Ein WCF-Dienst mit langer Laufzeit, der außerhalb von IIS gehostet wird - Dienstprozesslebensdauer vom Betriebssystem gesteuert, nicht nachrichtenaktiviert
- Von allen Windows-Versionen unterstützt
- Sichere Umgebung
IIS 5.1, IIS 6.0 - Paralleles Ausführen eines WCF-Diensts und von ASP.NET-Inhalten im Internet mithilfe des HTTP-Protokolls - Prozesswiederverwendung
- Herunterfahren bei Leerlauf
- Prozessüberwachung
- Nachrichtenbasierte Aktivierung
- Nur HTTP
Windows Process Activation Service (WAS) - Ausführen eines WCF-Diensts im Internet unter Verwendung verschiedener Transportprotokolle, ohne IIS zu installieren - IIS nicht erforderlich
- Prozesswiederverwendung
- Herunterfahren bei Leerlauf
- Prozessüberwachung
- Nachrichtenbasierte Aktivierung
- Funktioniert mit HTTP, TCP, Named Pipes und MSMQ
IIS 7.0 - Ausführen eines WCF-Diensts mit ASP.NET-Inhalten
- Ausführen eines WCF-Diensts im Internet unter Verwendung verschiedener Transportprotokolle
- Vorteile von WAS
- Integration in ASP.NET- und IIS-Inhalte

Die Wahl der Hostumgebung hängt von der Windows-Version ab, unter der der Dienst bereitgestellt wird, den für die Übermittlung von Nachrichten erforderlichen Transportprotokollen und der erforderlichen Art der Prozess- und Anwendungsdomänenwiederverwendung. In der folgenden Tabelle werden die Daten zu diesen Anforderungen zusammengefasst.

Hostumgebung Plattformverfügbarkeit Unterstützte Transportprotokolle Prozess- und AppDomain-Wiederverwendung
Verwaltete Anwendungen ("Selbsthosting") Windows XP, Windows Server 2003, Windows Vista,

Windows Server 2008
HTTP,

net.tcp,

net.pipe,

net.msmq
Nein
Windows-Dienste (früher als NT-Dienste bezeichnet) Windows XP, Windows Server 2003, Windows Vista,

Windows Server 2008
HTTP,

net.tcp,

net.pipe,

net.msmq
Nein
IIS 5,1 Windows XP HTTP Ja
IIS 6.0 Windows Server 2003 HTTP Ja
Windows Process Activation Service (WAS) Windows Vista, Windows Server 2008 HTTP,

net.tcp,

net.pipe,

net.msmq
Ja

Sie müssen unbedingt beachten, dass die Sicherheit gefährdet wird, wenn ein Dienst oder eine Erweiterung auf einem nicht vertrauenswürdigen Host ausgeführt wird. Beachten Sie zudem, dass eine Anwendung sicherstellen muss, dass der Benutzer bzw. die Benutzerin nicht abgemeldet wird, wenn ein Diensthost (ServiceHost) mit Identitätswechsel geöffnet wird, indem beispielsweise die Windows-Identität (WindowsIdentity) des Benutzers bzw. der Benutzerin zwischengespeichert wird.

Siehe auch