Freigeben über

Exchange-Kontextprotokoll

In diesem Abschnitt wird das Kontextaustauschprotokoll beschrieben, das in der Windows Communication Foundation (WCF)-Version .NET Framework, Version 3.5, eingeführt wurde. Mit diesem Protokoll kann der Clientkanal einen von einem Dienst bereitgestellten Kontext akzeptieren und auf alle nachfolgenden Anforderungen auf diesen Dienst anwenden, der über dieselbe Clientkanalinstanz gesendet wurde. Die Implementierung des Kontextaustauschprotokolls kann einen der folgenden beiden Mechanismen verwenden, um den Kontext zwischen dem Server und dem Client zu verteilen: HTTP-Cookies oder ein SOAP-Header.

Das Kontextaustauschprotokoll wird in einer benutzerdefinierten Kanalebene implementiert. Der Kontext wird mithilfe der ContextMessageProperty-Eigenschaft von der Kanalebene an die Anwendungsebene (und umgekehrt) übermittelt. Für die Übertragung zwischen Endpunkten wird der Wert des Kontexts entweder als SOAP-Header auf kanalebene serialisiert oder in oder aus den Nachrichteneigenschaften konvertiert, die eine HTTP-Anforderung und -Antwort darstellen. Im zweiten Fall wird erwartet, das eine der zugrunde liegenden Kanalebenen die Eigenschaften der HTTP-Anforderungs- bzw. HTTP-Antwortnachrichten in bzw. aus HTTP-Cookies umwandelt. Die Wahl des Mechanismus, der zum Austauschen des Kontexts verwendet wird, erfolgt mithilfe der ContextExchangeMechanism Eigenschaft auf der ContextBindingElement. Gültige Werte sind HttpCookie und SoapHeader.

Auf dem Client kann eine Instanz eines Kanals in zwei Modi ausgeführt werden, basierend auf den Einstellungen der Kanaleigenschaft. Enabled

Modus 1: Kanalkontextverwaltung

Dies ist der Standardmodus, in dem Enabled auf true festgelegt ist. In diesem Modus steuert der Kontextkanal den Kontext und cacht ihn während seiner Lebensdauer. Kontext kann vom Kanal über kanaleigenschaft IContextManager abgerufen werden, indem die GetContext Methode aufgerufen wird. Der Kanal kann auch vorab mit einem bestimmten Kontext initialisiert werden, bevor er geöffnet wird, indem die SetContext Methode für die Kanaleigenschaft aufgerufen wird. Nachdem der Kanal mit Kontext initialisiert wurde, kann er nicht zurückgesetzt werden.

Es folgt eine Liste der Invarianten in diesem Modus:

  • Jeder Versuch, den Kontext mithilfe von SetContext zurückzusetzen, nachdem der Kanal geöffnet wurde, löst eine InvalidOperationException aus.

  • Jeder Versuch, den Kontext mittels ContextMessageProperty in einer ausgehenden Nachricht zu übertragen, wirft eine InvalidOperationException.

  • Wenn eine Nachricht vom Server mit einem bestimmten Kontext empfangen wird, wenn der Kanal bereits mit einem bestimmten Kontext initialisiert wurde, führt dies zu einem ProtocolException.

    Hinweis

    Es ist angemessen, einen anfänglichen Kontext vom Server nur zu empfangen, wenn der Kanal ohne einen expliziten Kontextsatz geöffnet wird.

  • Bei eingehenden Nachrichten hat ContextMessageProperty stets den Wert NULL.

Modus 2: Anwendungskontextverwaltung

Dies ist der Modus, wenn Enabled auf false gesetzt ist. In diesem Modus verwaltet der Kontextkanal den Kontext nicht. Die Anwendung ist dafür verantwortlich, den Kontext mithilfe des ContextMessageProperty abzurufen, zu verwalten und anzuwenden. Jeder Versuch, GetContext oder SetContext aufzurufen, führt zu einem InvalidOperationException.

Unabhängig vom ausgewählten Modus unterstützt die Clientkanalfactory die Nachrichtenaustauschmuster IRequestChannel, IRequestSessionChannel und IDuplexSessionChannel.

Bei dem Dienst ist eine Instanz des Kanals dafür verantwortlich, den vom Client bereitgestellten Kontext bei eingehenden Nachrichten in den ContextMessageProperty zu konvertieren. Auf die Nachrichteneigenschaft kann dann über die Anwendungsschicht oder andere Kanäle weiter oben im Aufrufstapel zugegriffen werden. Die Dienstkanäle ermöglichen es der Anwendungsschicht auch, einen neuen Kontextwert anzugeben, der an den Client weitergegeben werden soll, indem eine ContextMessageProperty an die Antwortnachricht angefügt wird. Diese Eigenschaft wird in den SOAP-Header oder HTTP-Cookie konvertiert, der den Kontext enthält, der von der Konfiguration der Bindung abhängt. Der Dienstkanallistener unterstützt die Nachrichtenaustauschmuster IReplyChannel, IReplySessionChannel und IReplySessionChannel.

Das Kontextaustauschprotokoll führt einen neuen wsc:Context SOAP-Header ein, der die Kontextinformationen darstellt, wenn HTTP-Cookies nicht zum Verteilen des Kontexts verwendet werden. Das Kontextheaderschema ermöglicht eine beliebige Anzahl untergeordneter Elemente mit jeweils einem Zeichenfolgenschlüssel und Zeichenfolgeninhalt. Im Folgenden sehen Sie ein Beispiel für einen Kontextheader.

<Context xmlns="http://schemas.microsoft.com/ws/2006/05/context">

<property name="myContext">context-2</property>

</Context>

Im HttpCookie Modus werden Cookies mithilfe des SetCookie Headers festgelegt. Der Cookiename lautet WscContext. Der Wert des Cookies ist die Base64-Codierung des wsc:Context Headers. Dieser Wert wird in Anführungszeichen eingeschlossen.

Der Wert des Kontexts muss während der Übermittlung aus den gleichen Gründen vor Veränderungen geschützt werden, aus denen WS-Adressierungsheader geschützt werden: Anhand des Headers wird ermittelt, an welchen Endpunkt im Dienst die Anforderung weitergeleitet werden soll. Der wsc:Context Header muss daher digital signiert oder signiert und verschlüsselt werden, entweder auf SOAP- oder Transportebene, wenn die Bindung Nachrichtenschutzfunktionen bietet. Wenn HTTP-Cookies verwendet werden, um Kontext zu verbreiten, sollten sie mithilfe der Transportsicherheit geschützt werden.

Dienstendpunkte, die Unterstützung für das Kontextaustauschprotokoll erfordern, können sie in der veröffentlichten Richtlinie explizit festlegen. Es wurden zwei neue Richtlinien assertionen eingeführt, um die Anforderung für den Client darzustellen, das Kontextaustauschprotokoll auf SOAP-Ebene zu unterstützen oder die HTTP-Cookieunterstützung zu aktivieren. Die Generierung dieser Assertionen in die Richtlinie für den Dienst wird wie folgt durch den Wert der ContextExchangeMechanism Eigenschaft gesteuert:

  • Für ContextSoapHeader, die folgende Assertion wird generiert:

    <IncludeContext
xmlns="http://schemas.microsoft.com/ws/2006/05/context"  
protectionLevel="Sign" />

  • Für HttpCookie, die folgende Assertion wird generiert:

    <HttpUseCookie xmlns="http://schemas.xmlsoap.org/soap/http"/>

Siehe auch

  • Last updated on