Übersicht über das Kanalmodell
Der Windows-Communication-Foundation-(WCF)-Kanalstapel ist ein gestapelter Kommunikationsstapel mit mindestens einem Kanal, der Nachrichten verarbeitet. Am unteren Ende des Stapels befindet sich ein Transportkanal, der für die Anpassung des Kanalstapels an den zugrunde liegenden Transport (z. B. TCP, HTTP, SMTP und andere Transportarten) zuständig ist. Kanäle stellen ein Programmiermodell auf niedriger Ebene zum Senden und Empfangen von Nachrichten bereit. Dieses Programmiermodell basiert auf mehreren Schnittstellen und anderen Typen, die gemeinsam als WCF-Kanalmodell bezeichnet werden. In diesem Thema werden Kanalformen, die Konstruktion eines grundlegenden Kanallisteners (dienstseitig) und einer Kanalfactory (clientseitig) behandelt.
Kanalstapel
WCF-Endpunkte kommunizieren mit der Welt mithilfe eines Kommunikationsstapels, der als Kanalstapel bezeichnet wird. Das folgende Diagramm vergleicht den Kanalstapel mit anderen Kommunikationsstapeln, z. B. TCP/IP.
Zunächst die Ähnlichkeiten: In beiden Fällen bietet jede Schicht des Stapels eine gewisse Abstraktion der Welt unterhalb der Schicht und stellt diese Abstraktion nur der direkt darüber liegenden Schicht zur Verfügung. Jede Schicht verwendet nur die Abstraktion der direkt darunter liegenden Schicht. Außerdem kommuniziert bei der Kommunikation von zwei Schichten in beiden Fällen jede Schicht mit der entsprechenden Schicht des anderen Stapels, d. h. die IP-Schicht kommuniziert mit der IP-Schicht und die TCP-Schicht mit der TCP-Schicht usw.
Und nun die Unterschiede: Während der TCP-Stapel konzipiert wurde, um eine Abstraktion des physischen Netzwerks zur Verfügung zu stellen, soll der Kanalstapel nicht nur eine Abstraktion darüber verfügbar machen, wie die Nachricht zugestellt wird, d. h. über den Transport, sondern auch eine Abstraktion anderer Funktionen schaffen, z. B. was die Nachricht enthält oder welches Protokoll für die Kommunikation verwendet wird, einschließlich des Transports, jedoch weit darüber hinausgehend. Ein zuverlässiges Sitzungsbindungselement ist Bestandteil des Kanalstapels, befindet sich jedoch nicht unterhalb der Transportschicht oder des Transports selbst. Diese Abstraktion wird dadurch erreicht, dass der untere Kanal im Stapel das zugrunde liegende Transportprotokoll an die Kanalstapelarchitektur anpassen muss und dann auf die Kanäle weiter oben im Stapel angewiesen ist, um Kommunikationsfunktionen wie Zuverlässigkeitsgarantien und Sicherheit bereitzustellen.
Nachrichten fließen als Message-Objekte durch den Kommunikationsstapel. Wie in der Abbildung oben gezeigt, wird der unterste Kanal als Transportkanal bezeichnet. Dieser Kanal ist für das Senden und Empfangen von Nachrichten zu und von anderen Seiten zuständig. Dazu gehört die Zuständigkeit für das Transformieren des Message-Objekts in und aus dem Format, das zur Kommunikation mit anderen Seiten verwendet wird. Oberhalb des Transportkanals kann eine beliebige Zahl von Protokollkanälen vorhanden sein, wobei jeder Kanal für die Bereitstellung einer Kommunikationsfunktion sowie für zuverlässige Zustellungsgarantien verantwortlich ist. Protokollkanäle sind für Nachrichten tätig, die in Form des Message-Objekts durch sie hindurchfließen. Normalerweise transformieren sie entweder die Nachricht, z. B. durch Hinzufügen von Headern oder Verschlüsseln des Nachrichtentexts, oder sie senden oder empfangen eigene Protokollkontrollnachrichten, z. B. Empfangsbestätigungen.
Kanalformen
Jeder Kanal implementiert eine oder mehrere Schnittstellen, die als Kanalformschnittstellen oder Kanalformen bezeichnet werden. Diese Kanalformen stellen kommunikationsorientierte Methoden wie Senden und Empfangen oder Anfordern und Antworten zur Verfügung, die der Kanal implementiert und der Benutzer des Kanals aufruft. Bei der Basis der Kanalformen handelt es sich um die IChannel Schnittstelle, bei der es sich um eine Schnittstelle handelt, die eine GetProperty<T>-Methode bereitstellt, welche als schichtweiser Mechanismus für den Zugriff auf beliebige Funktionen vorgesehen ist, die von Kanälen im Stapel verfügbar gemacht werden. Die fünf Kanalformen, die IChannel erweitern, sind:
Darüber hinaus besitzt jede dieser Formen eine Entsprechung, die System.ServiceModel.Channels.ISessionChannel<TSession> erweitert, um Sitzungen zu unterstützen. Diese lauten wie folgt:
Die Kanalformen sind einigen der grundlegenden Nachrichtenaustauschmuster, die von vorhandenen Transportprotokollen unterstützt werden, nachempfunden. So entspricht beispielsweise unidirektionales Messaging einem IInputChannel/IOutputChannel Paar, die Anforderungsantwort entspricht IRequestChannel/IReplyChannel Paaren und bidirektionale Duplexkommunikation entspricht IDuplexChannel (die sowohl IInputChannel als auch IOutputChannel erweitert).
Programmieren mit dem Kanalstapel
Kanalstapel werden i. d. R. mit einem Factorymuster erstellt, in dem eine Bindung den Kanalstapel erstellt. Auf der Senderseite wird eine Bindung zum Erstellen einer ChannelFactory verwendet, die wiederum einen Kanalstapel erstellt und einen Verweis auf den obersten Kanal im Stapel zurückgibt. Die Anwendung kann dann diesen Kanal verwenden, um Nachrichten zu senden. Weitere Informationen finden Sie unter Client Channel-Level Programmierung.
Auf der Empfängerseite wird eine Bindung verwendet, um einen IChannelListener zu erstellen, der eingehende Nachrichten abhört. Der IChannelListener stellt der abhörenden Anwendung Nachrichten zur Verfügung, indem ein Kanalstapel erstellt und der Anwendungsverweis an den oberen Kanal übergeben wird. Die Anwendung verwendet diesen Kanal dann zum Empfangen eingehender Nachrichten. Weitere Informationen finden Sie unter Client Channel-Level Programmierung.
Das Kanalobjektmodell
Das Kanalobjektmodell stellt die Kerngruppe von Schnittstellen dar, die zur Implementierung von Kanälen, Kanallistenern und Kanalfactorys erforderlich sind. Zur Erleichterung benutzerdefinierter Implementierungen werden auch einige Basisklassen zur Verfügung gestellt.
Kanallistener sind für die Abhörung eingehender Nachrichten und für die Zustellung dieser Nachrichten an die darüber liegende Schicht über Kanäle verantwortlich, die vom Kanallistener erstellt werden.
Kanalfactorys sind für das Erstellen von Kanälen zuständig, die zum Senden von Nachrichten und zum Schließen aller Kanäle, die sie beim Schließen der Kanalfactory erstellt haben, verwendet werden.
ICommunicationObject ist die Kernschnittstelle, die den grundlegenden Zustandsautomaten definiert, der alle Kommunikationsobjekte implementiert. CommunicationObject stellt eine Implementierung dieser Kernschnittstelle bereit, die andere Kanalklassen ableiten können, statt die Schnittstelle neu zu implementieren. Aber dies ist nicht erforderlich: Ein benutzerdefinierter Kanal kann ICommunicationObject direkt implementieren und nicht von CommunicationObject erben. Keine der Klassen in Abbildung 3 gilt als Teil des Kanalmodells. Sie sind Hilfen für Implementierer von benutzerdefinierten Kanälen, die Kanäle erstellen möchten.
In den folgenden Themen werden das Kanalobjektmodell sowie verschiedene Entwicklungsbereiche beschrieben, die die Erstellung benutzerdefinierter Kanäle unterstützen.
| Thema | Beschreibung |
|---|---|
| Dienst: Kanallistener und Kanäle | Beschreibt Kanallistener, die eingehende Kanäle in einer Dienstanwendung abhört. |
| Client: Kanalfactorys und Kanäle | Beschreibt Kanalfactorys, die Kanäle zur Herstellung einer Verbindung mit einer Dienstanwendung erstellen. |
| Grundlegendes zu Zustandsänderungen | Beschreibt, wie die System.ServiceModel.ICommunicationObject-Schnittstelle Zustandsänderungen in Kanälen modelliert. |
| Auswählen eines Nachrichtenaustauschmusters | Beschreibt die sechs grundlegenden Nachrichtenaustauschmuster, die Kanäle unterstützen können. |
| Behandeln von Ausnahmen und Fehlern | Beschreibt, wie Fehler und Ausnahmen in benutzerdefinierten Kanälen behandelt werden. |
| Konfiguration und Metadatenunterstützung | Beschreibt, wie die Verwendung von benutzerdefinierten Kanälen im Anwendungsmodell unterstützt wird und Metadaten mit Bindungen und Bindungselementen exportiert und importiert werden. |