Zuverlässiges Messaging-Protokoll, Version 1.0

  • Artikel

In diesem Thema werden WCF-Implementierungsdetails (Windows Communication Foundation) für das WS-ReliableMessaging-Protokoll in der Version 1.0 vom Februar 2005 beschrieben, die für die Interoperation mithilfe des HTTP-Transports erforderlich sind. WCF orientiert sich an der WS-Reliable Messaging-Spezifikation mit den in diesem Thema erläuterten Einschränkungen und Klarstellungen. Beachten Sie, dass das zuverlässige WS-Messaging-Protokoll in der Version 1.0 ab WinFX implementiert ist.

Das WS-ReliableMessaging-Protokoll vom Februar 2005 ist in WCF durch das ReliableSessionBindingElement implementiert.

Der Einfachheit halber verwendet dieses Thema die folgenden Rollen:

  • Initiator: der Client, der die Erstellung der zuverlässigen WS-Messaging-Sequenz initiiert

  • Beantworter: der Dienst, der die Anforderungen des Initiators empfängt

In diesem Dokument werden die in der folgenden Tabelle aufgeführten Präfixe und Namespaces verwendet.

Präfix Namespace
wsrm http://schemas.xmlsoap.org/ws/2005/02/rm
netrm http://schemas.microsoft.com/ws/2006/05/rm
s http://www.w3.org/2003/05/soap-envelope
wsa http://schemas.xmlsoap.org/ws/2005/08/addressing
wsse http://docs.oasis-open.org/wss/2004/01/oasis-200401-wssecurity-secext-1.0.xsd

Nachrichten

Sequenzeinrichtungsnachrichten

WCF implementiert CreateSequence- und CreateSequenceResponse-Nachrichten, um eine zuverlässige Nachrichtensequenz einzurichten. Die folgenden Einschränkungen gelten:

  • B1101: Der WCF-Initiator generiert nicht das optionale Expires-Element in der CreateSequence-Nachricht oder, in den Fällen, in denen die CreateSequence-Nachricht ein Offer-Element enthält, das optionale Expires-Element im Offer-Element.

  • B1102: Beim Zugreifen auf die CreateSequence-Nachricht sendet und empfängt der WCFResponder beide Expires-Elemente, wenn sie vorhanden sind, verwendet ihre Werte jedoch nicht.

Zuverlässiges WS-Messaging führt den Offer-Mechanismus ein, um zwei umgekehrt korrelierende Sequenzen einzurichten, die eine Sitzung bilden.

  • R1103: Wenn CreateSequence ein Offer-Element enthält, muss der zuverlässige Messaging-Beantworter entweder die Sequenz akzeptieren und mit CreateSequenceResponse antworten (enthält ein wsrm:Accept-Element), wodurch die zwei umgekehrt korrelierenden Sequenzen gebildet werden, oder er muss die CreateSequence-Anforderung zurückweisen.

  • R1104: SequenceAcknowledgement und die in umgekehrter Sequenz fließenden Anwendungsnachrichten müssen an den ReplyTo-Endpunktverweis der CreateSequence gesendet werden.

  • R1105: AcksTo- und ReplyTo-Endpunktverweise in der CreateSequence müssen Adresswerte aufweisen, die sich oktettweise entsprechen.

    Der WCF-Beantworter überprüft, ob die URI-Teile von AcksTo- und ReplyTo-EPRs identisch sind, bevor die Sequenz erstellt wird.

  • R1106: AcksTo- und ReplyTo-Endpunktverweise in der CreateSequence sollten den gleichen Satz von Verweisparametern aufweisen.

    WCF geht davon aus, dass die Verweisparameter von AcksTo und ReplyTo in CreateSequence identisch sind, erzwingt dies jedoch nicht, und verwendet die Verweisparameter von dem ReplyTo Endpunktverweis für Bestätigungen und Nachrichten umgekehrter Sequenz.

  • R1107: Wenn mithilfe des Offer-Mechanismus zwei umgekehrte Sequenzen eingerichtet sind, müssen SequenceAcknowledgement und die in umgekehrter Sequenz fließenden Anwendungsnachrichten an den ReplyTo-Endpunktverweis der CreateSequence gesendet werden.

  • R1108: Wenn mithilfe des Offer-Mechanismus zwei umgekehrte Sequenzen eingerichtet sind, muss die [address]-Eigenschaft des wsrm:AcksTo-Endpunktverweises, ein dem wsrm:Accept-Element von CreateSequenceResponse untergeordnetes Element, mit dem Ziel-URI von CreateSequence byteweise übereinstimmen.

  • R1109: Wenn mithilfe des Offer-Mechanismus zwei umgekehrte Sequenzen eingerichtet sind, müssen die vom Initiator gesendeten Nachrichten und die vom Beantworter gesendeten Bestätigungen der Nachrichten an den gleichen Endpunktverweis gesendet werden.

    WCF verwendet zuverlässiges WS-Messaging, um zuverlässige Sitzungen zwischen dem Initiator und dem Beantworter einzurichten. Die Implementierung von zuverlässigem WS-Messaging in WCF bietet zuverlässige Sitzungen für unidirektionale, Anforderung-Antwort- und Vollduplex-Nachrichtenmuster. Der Offer-Mechanismus von zuverlässigem WS-Messaging für CreateSequence/CreateSequenceResponse ermöglicht es Ihnen, zwei umgekehrt korrelierte Sequenzen zu erstellen, und bietet ein für alle Nachrichtenendpunkte geeignetes Sitzungsprotokoll. Da WCF die Sicherheit solcher Sitzungen sowie den End-to-End-Schutz der Sitzungsintegrität garantiert, kann sichergestellt werden, dass alle an den gleichen Teilnehmer gerichteten Nachrichten am gleichen Ziel ankommen. Dies lässt auch Piggyback-Übertragung von Sequenzbestätigungen auf Anwendungsnachrichten zu. Deshalb gelten die Einschränkungen R1104, R1105 und R1108 für WCF.

Ein Beispiel für eine CreateSequence-Nachricht.

<s:Envelope>
  <s:Header>
    <a:Action s:mustUnderstand="1">
      http://schemas.xmlsoap.org/ws/2005/02/rm/CreateSequence
    </a:Action>
    <a:ReplyTo>
      <a:Address>
         http://Business456.com/clientA
      </a:Address>
    </a:ReplyTo>
    <a:MessageID>
      urn:uuid:addabbbf-60cb-44d3-8c5b-9e0841629a36
    </a:MessageID>
    <a:To s:mustUnderstand="1">
      http://Business456.com/clientA
    </a:To>
  </s:Header>
  <s:Body>
    <wsrm:CreateSequence>
      <wsrm:AcksTo>
       <wsa:Address>
         http://Business456.com/clientA
       </wsa:Address>
     </wsrm:AcksTo>
     <wsrm:Offer>
      <wsrm:Identifier>
        urn:uuid:0afb8d36-bf26-4776-b8cf-8c91fddb5496
      </wsrm:Identifier>
     </wsrm:Offer>
   </wsrm:CreateSequence>
  </s:Body>
</s:Envelope>

Ein Beispiel für eine CreateSequenceResponse-Nachricht.

<s:Envelope>
  <s:Header>
    <a:Action s:mustUnderstand="1">
      http://schemas.xmlsoap.org/ws/2005/02/rm/CreateSequenceResponse
    </a:Action>
    <a:RelatesTo>
      urn:uuid:addabbbf-60cb-44d3-8c5b-9e0841629a36
    </a:RelatesTo>
    <a:To s:mustUnderstand="1">
      http://Business456.com/clientA
    </a:To>
  </s:Header>
  <s:Body>
   <wsrm:CreateSequenceResponse>
    <Identifier>
     urn:uuid:eea0a36c-b38a-43e8-8c76-2fabe2d76386
    </Identifier>
    <Accept>
    <AcksTo>
      <a:Address>
        http://BusinessABC.com/serviceA
      </a:Address>
    </AcksTo>
    </Accept>
   </wsrm:CreateSequenceResponse>
  </s:Body>
</s:Envelope>

Sequenz

Die folgende Liste enthält die Einschränkungen, die für Sequenzen gelten:

  • B1201: WCF generiert und verwendet nur Sequenznummern, die den maximalen inklusiven Wert von xs:long, also 9223372036854775807 nicht überschreiten.

  • B1202:WCF erzeugt immer eine leere letzte Nachricht mit dem Aktions-URI von http://schemas.xmlsoap.org/ws/2005/02/rm/LastMessage.

  • B1203: WCF empfängt und liefert eine Nachricht mit einem Sequenzheader, der ein LastMessage-Element enthält, solange der Aktions-URI nicht http://schemas.xmlsoap.org/ws/2005/02/rm/LastMessage ist.

Ein Beispiel für einen Sequenzheader.

<wsrm:Sequence>
  <wsrm:Identifier>
    urn:uuid:addabbbf-60cb-44d3-8c5b-9e0841629a36
  </wsrm:Identifier>
  <wsrm:MessageNumber>
    10
  </wsrm:MessageNumber>
  <wsrm:LastMessage/>
 </wsrm:Sequence>

AckRequested-Header

WCF verwendet den AckRequested-Header als Keep-alive-Mechanismus. WCF generiert nicht das optionale MessageNumber-Element. Wird eine Nachricht mit einem AckRequested-Header empfangen, der das MessageNumber-Element enthält, ignoriert WCF den Wert des MessageNumber-Elements, wie im folgenden Beispiel gezeigt:

<wsrm:AckRequested>
  <wsrm:Identifier>
    urn:uuid:addabbbf-60cb-44d3-8c5b-9e0841629a36
  </wsrm:Identifier>
</wsrm:AckRequested>

SequenceAcknowledgement-Header

WCF verwendet den Piggyback-Mechanismus für die im WS-ReliableMessaging bereitgestellten Sequenzbestätigungen.

  • R1401: Wenn mithilfe des Offer-Mechanismus zwei umgekehrte Sequenzen erstellt werden, kann der SequenceAcknowledgement-Header in jede an den vorgesehenen Empfänger gesendete Anwendungsnachricht aufgenommen werden.

  • B1402: Wenn WCF vor dem Empfang von Sequenznachrichten eine Bestätigung erzeugen muss (z. B. um eine AckRequested-Nachricht zu erfüllen), erzeugt WCF einen SequenceAcknowledgement-Header, der den Bereich 0-0 enthält, wie im folgenden Beispiel gezeigt.

    <wsrm:SequenceAcknowledgement>
  <wsrm:Identifier>
    urn:uuid:addabbbf-60cb-44d3-8c5b-9e0841629a36
  </wsrm:Identifier>
  <wsrm:AcknowledgementRange Upper="0" Lower="0"/>
</wsrm:SequenceAcknowledgement>

  • B1403: WCF generiert keine SequenceAcknowledgement-Header, die ein Nack-Element enthalten, unterstützt jedoch Nack-Elemente.

WS-ReliableMessaging-Fehler

Die folgende Liste enthält die Einschränkungen, die für die WCF-Implementierung der WS-ReliableMessaging-Fehler gelten.

  • B1501: WCF generiert keine MessageNumberRollover-Fehler.

  • B1502: Ein WCF-Endpunkt kann CreateSequenceRefused-Fehler generieren, wie in der Spezifikation beschrieben.

  • B1503:Wenn der Dienstendpunkt seine Verbindungsgrenze erreicht und keine weiteren Verbindungen verarbeiten kann, generiert WCF den zusätzlichen CreateSequenceRefused-Fehlersubcode netrm:ConnectionLimitReached, wie im folgenden Beispiel gezeigt.

    <s:Envelope>
  <s:Header>
    <wsa:Action>
      http://schemas.xmlsoap.org/ws/2005/08/addressing/fault
    </wsa:Action>
  </s:Header>
  <s:Body>
    <s:Fault>
      <s:Code>
        <s:Value>
          s:Receiver
        </s:Value>
        <s:Subcode>
          <s:Value>
            wsrm:CreateSequenceRefused
          </s:Value>
          <s:Subcode>
            <s:Value>
              netrm:ConnectionLimitReached
            </s:Value>
          </s:Subcode>
        </s:Subcode>
      </s:Code>
      <s:Reason>
        <s:Text xml:lang="en">
          [Reason]
        </s:Text>
      </s:Reason>
    </s:Fault>
  </s:Body>
</s:Envelope>

WS-Adressierungsfehler

Da zuverlässiges WS-Messaging WS-Adressierung verwendet, kann die WCF-Implementierung von zuverlässigem WS-Messaging WS-Adressierungsfehler generieren. In diesem Abschnitt werden die WS-Adressierungsfehler erläutert, die WCF explizit auf der Ebene des zuverlässigen WS-Messaging generiert.

  • B1601:WCF generiert den Fehler "Nachrichtenadressierungs-Header erforderlich", wenn eine der folgenden Bedingungen eintritt:

    • Eine Nachricht hat keinen Sequence-Header und keinen Action-Header.

    • Eine CreateSequence-Nachricht hat keinen MessageId-Header.

    • Eine CreateSequence-Nachricht hat keinen ReplyTo-Header.

  • B1602:WCF generiert den Fehler „Aktion wird nicht unterstützt“ als Antwort auf eine Nachricht, die keinen Sequence-Header besitzt und einen Action-Header hat, der nicht der WS-ReliableMessaging-Spezifikation entspricht:

  • B1603:WCF generiert den Fehler "Endpunkt nicht verfügbar", um anzugeben, dass der Endpunkt die Sequenz basierend auf einer Untersuchung der Adressheader der CreateSequence-Nachricht nicht verarbeitet.

Protokollkomposition

Komposition mit WS-Adressierung

WCF unterstützt zwei Versionen der WS-Adressierung: WS-Adressierung 2004/08 [WS-ADDR] und die Empfehlungen für W3C die WS-Adressierung 1.0 [WS-WS-ADDR-CORE] und [WS-ADDR-SOAP].

Zwar erwähnt die WS-ReliableMessaging-Spezifikation nur die WS-Adressierung 2004/08, schränkt jedoch die verwendete Version der WS-Adressierung nicht ein. Die folgende Liste enthält die Einschränkungen, die für WCF gelten:

  • R2101:Sowohl WS-Adressierung 2004/08 als auch WS-Adressierung 1.0 können mit zuverlässigem WS-Messaging verwendet werden.

  • R2102:Für eine gegebene zuverlässige WS-Messaging-Sequenz oder ein gegebenes Paar umgekehrter Sequenzen, die mithilfe des wsrm:Offer-Mechanismus miteinander korreliert wurden, darf nur eine einzige Version der WS-Adressierung verwendet werden.

Komposition mit SOAP

WCF unterstützt die Verwendung sowohl von SOAP 1.1 als auch von SOAP 1.2 mit zuverlässigem WS-Messaging.

Komposition mit WS-Sicherheit und WS-SecureConversation

WCF bietet Schutz für die zuverlässigen WS-Messaging-Sequenzen durch die Verwendung einer sicheren Transportmethode (HTTPS), die Erstellung mit WS-Sicherheit und die Erstellung mit WS-Secure Conversation. Die folgende Liste enthält die Einschränkungen, die für WCF gelten:

  • R2301:Damit die Integrität einer WS-ReliableMessaging-Sequenz sowie die Integrität und Vertraulichkeit einzelner Nachrichten sichergestellt ist, muss WS-Secure Conversation für WCF verwendet werden.

  • R2302:EineWS-Secure Conversation-Sitzung muss vor der Erstellung von zuverlässigen WS-Messaging-Sequenzen eingerichtet werden.

  • R2303: Wenn die Lebensdauer einer zuverlässigen WS-Messaging-Sequenz die Lebensdauer der WS-Secure Conversation-Sitzung überschreitet, muss das mithilfe von WS-Secure Conversation eingerichtete SecurityContextToken unter Verwendung der entsprechenden WS-Secure Conversation Renewal-Bindung erneuert werden.

  • B2304:Die zuverlässige WS-Messaging-Sequenz bzw. das Paar korrelierter umgekehrter Sequenzen ist immer an eine einzelne WS-SecureConversation-Sitzung gebunden.

    Die WCF-Quelle generiert das wsse:SecurityTokenReference-Element im Abschnitt Elementerweiterbarkeit der CreateSequence-Nachricht.

  • R2305:Wenn WS-Secure Conversation zur Erstellung verwendet wird, muss eine CreateSequence-Nachricht das wsse:SecurityTokenReference-Element enthalten.

Zuverlässige WS-Messaging WS-Richtlinienassertion

WCF verwendet die WS-Richtlinienassertion wsrm:RMAssertion des zuverlässigen WS-Messaging, um die Fähigkeiten von Endpunkten zu beschreiben. Die folgende Liste enthält die Einschränkungen, die für WCF gelten:

  • B3001: WCF fügt die wsrm:RMAssertion-WS-Policy-Assertion an wsdl:binding-Elemente an. WCF unterstützt das Anfügen an wsdl:binding-Elemente sowie an wsdl:port-Elemente.

  • B3002: WCF unterstützt die folgenden optionalen Eigenschaften der zuverlässigen WS-Messaging-Assertion und ermöglicht ihre Steuerung über das von WCFReliableMessagingBindingElement:

    • wsrm:InactivityTimeout

    • wsrm:AcknowledgementInterval

    Im Folgenden finden Sie ein Beispiel.

    <wsrm:RMAssertion>
  <wsrm:InactivityTimeout Milliseconds="600000" />
  <wsrm:AcknowledgementInterval Milliseconds="200" />
</wsrm:RMAssertion>

Zuverlässige WS-Messaging-Erweiterung zur Ablaufsteuerung

WCF verwendet die Erweiterbarkeit des zuverlässigen WS-Messaging, um optional eine bessere Steuerung des Sequenznachrichtenflusses zu ermöglichen.

Die Flusssteuerung wird durch Festlegen der ReliableSessionBindingElement.FlowControlEnabled-Eigenschaft auf true aktiviert. Die folgende Liste enthält die Einschränkungen, die für WCF gelten:

  • B4001: Wenn die zuverlässige Messaging-Ablaufsteuerung aktiviert ist, generiert WCF ein netrm:BufferRemaining-Element in der Elementerweiterbarkeit des SequenceAcknowledgement-Headers.

  • B4002: Wenn die zuverlässige Messaging-Ablaufsteuerung aktiviert ist, erfordert kein netrm:BufferRemaining-Element im SequenceAcknowledgement-Header, wie im folgenden Beispiel zu sehen.

    <wsrm:SequenceAcknowledgement>
  <wsrm:Identifier>
    http://fabrikam123.com/abc
  </wsrm:Identifier>
  <wsrm:AcknowledgementRange Upper="1" Lower="1"/>
  <netrm:BufferRemaining>
    8
  </netrm:BufferRemaining>
</wsrm:SequenceAcknowledgement>

  • B4003: WCF verwendet netrm:BufferRemaining, um anzugeben, wie viele neue Nachrichten das zuverlässige Messaging-Ziel puffern kann.

  • B4004:Der zuverlässige WCF Messaging-Dienst schränkt die Anzahl der übertragenen Nachrichten ein, wenn die zuverlässige Messaging-Zielanwendung die Nachrichten nicht schnell genug empfangen kann. Das zuverlässige Messaging-Ziel puffert Nachrichten, und der Wert des Elements sinkt auf 0.

  • B4005: WCF generiert netrm:BufferRemaining-Ganzzahlwerte zwischen 0 und 4096 einschließlich und liest Ganzzahlwerte zwischen 0 und dem maxInclusive-Wert von xs:int (214748364) einschließlich.

Nachrichtenaustauschmuster

In diesem Abschnitt wird das Verhalten von WCF bei Verwendung von WS-ReliableMessaging für verschiedene Nachrichtenaustauschmuster beschrieben. Für jedes Nachrichtenaustauschmuster werden die folgenden zwei Bereitstellungsszenarios erläutert:

  • Nicht adressierbarer Initiator: Der Initiator befindet sich hinter einer Firewall, der Beantworter kann Nachrichten an den Initiator nur über HTTP-Antworten zustellen.

  • Adressierbarer Initiator: Sowohl an den Initiator als auch den Beantworter können HTTP-Anforderungen gesendet werden, d. h., es können zwei entgegengesetzte HTTP-Verbindungen eingerichtet werden.

Unidirektionaler, nicht adressierbarer Initiator

Bindung

WCF stellt ein unidirektionales Nachrichtenaustauschmuster unter Verwendung einer Sequenz über einen HTTP-Kanal bereit. WCF verwendet die HTTP-Anforderungen, um alle Nachrichten vom RMS zum RMD zu übertragen, und die HTTP-Antworten, um alle Nachrichten vom RMD zum RMS zu übertragen.

CreateSequence-Austausch

Der WCF-Initiator generiert eine CreateSequence-Nachricht ohne Angebot. Der WCF-Beantworter stellt vor dem Erstellen einer Sequenz sicher, dass die CreateSequence-Nachricht kein Angebot aufweist. Der -Beantworter antwortet mit einer CreateSequence-Nachricht auf die CreateSequenceResponse-Anforderung.

SequenceAcknowledgement

Der WCF-Initiator erstellt Bestätigungen als Antwort auf alle Nachrichten mit Ausnahme von CreateSequence-Nachrichten und Fehlernachrichten. Der WCF-Beantworter generiert eine eigenständige Bestätigung in der Antwort auf Sequenzen und auf AckRequested-Nachrichten.

TerminateSequence-Nachricht

WCF behandelt TerminateSequence als unidirektionalen Vorgang, was bedeutet, dass die HTTP-Antwort einen leeren Textbereich und den HTTP-Statuscode 202 hat.

Unidirektionaler, adressierbarer Initiator

Bindung

WCF bietet ein unidirektionales Nachrichtenaustauschmuster unter Verwendung eines eingehenden und eines ausgehenden HTTP-Kanals. WCF verwendet HTTP-Anforderungen zur Übertragung aller Nachrichten. Alle HTTP-Antworten haben einen leeren Textbereich und den HTTP-Statuscode 202.

CreateSequence-Austausch

Der WCF-Initiator generiert eine CreateSequence-Nachricht ohne Angebot. Der WCF-Beantworter stellt vor dem Erstellen einer Sequenz sicher, dass die CreateSequence-Nachricht kein Angebot aufweist. DerWCF -Beantworter sendet die CreateSequenceResponse-Nachricht über eine HTTP-Anforderung, die mit dem ReplyTo-Endpunktverweis adressiert wird.

Adressierbarer Duplex-Initiator

Bindung

WCF bietet ein vollständig asynchrones bidirektionales Nachrichtenaustauschmuster unter Verwendung zweier Sequenzen über einen eingehenden und einen ausgehenden HTTP-Kanal. WCF verwendet HTTP-Anforderungen zur Übertragung aller Nachrichten. Alle HTTP-Antworten haben einen leeren Textbereich und den HTTP-Statuscode 202.

CreateSequence-Austausch

Der WCF-Initiator generiert eine CreateSequence-Nachricht mit Angebot. Der WCF-Beantworter stellt vor dem Erstellen einer Sequenz sicher, dass die CreateSequence-Nachricht ein Angebot aufweist. WCF sendet die CreateSequenceResponse über die HTTP-Anfrage, die an die CreateSequence-Endpunktreferenz derReplyTo adressiert ist.

Sequenzlebensdauer

WCF behandelt die zwei Sequenzen als eine Vollduplexsitzung.

Nach dem Generieren eines Fehlers für eine Sequenz erwartet WCF, dass der Remoteendpunkt einen Fehler für beide Sequenzen auslöst. Nach dem Lesen eines Fehlers, der zum Fehlschlagen einer Sequenz führt, löst WCF einen Fehler für beide Sequenzen aus.

WCF kann seine ausgehende Sequenz schließen und damit fortfahren, Nachrichten in seiner eingehenden Sequenz zu verarbeiten. Umgekehrt kann WCF auch das Schließen der eingehenden Sequenz durchführen und weiter Nachrichten in seiner ausgehenden Sequenz senden.

Nicht adressierbarer Anforderung-Antwort-Initiator

Bindung

WCF bietet ein unidirektionales Anforderung-Antwort-Nachrichtenaustauschmuster unter Verwendung zweier Sequenzen über einen HTTP-Kanal. WCF verwendet HTTP-Anforderungen, um Anforderungssequenznachrichten zu übertragen, und HTTP-Antworten, um Antwortsequenznachrichten zu übertragen.

CreateSequence-Austausch

Der WCF-Initiator generiert eine CreateSequence-Nachricht mit Angebot. Der WCF-Beantworter stellt vor dem Erstellen einer Sequenz sicher, dass die CreateSequence-Nachricht ein Angebot aufweist. Der -Beantworter antwortet mit einer CreateSequence-Nachricht auf die CreateSequenceResponse-Anforderung.

Unidirektionale Nachricht

Um ein unidirektionales Nachrichtenaustauschprotokoll erfolgreich durchzuführen, überträgt der WCF-Initiator eine Anforderungssequenznachricht in der HTTP-Anforderung und empfängt eine eigenständige SequenceAcknowledgement-Nachricht in der HTTP-Antwort. Die SequenceAcknowledgement-Nachricht muss die Nachrichtenübertragung bestätigen.

Der WCF-Beantworter kann mit einer Bestätigung, einem Fehler oder einer Antwort mit leerem Textbereich und dem HTTP-Statuscode 202 auf die Anforderung reagieren.

Bidirektionale Nachrichten

Zum erfolgreichen Ausführen eines bidirektionalen Nachrichtenaustauschprotokolls überträgt der WCF-Initiator eine Anforderungssequenznachricht in der HTTP-Anforderung und empfängt eine Antwortsequenznachricht in der HTTP-Antwort. Die Antwort muss eine SequenceAcknowledgement enthalten, die die Übertragung der Anforderungssequenznachricht bestätigt.

Der WCF-Beantworter kann mit einer Anwendungsantwort, einem Fehler oder einer Antwort mit leerem Textbereich und dem HTTP-Statuscode 202 auf die Anforderung reagieren.

Aufgrund des Vorhandenseins unidirektionaler Nachrichten und des zeitlichen Ablaufs von Anwendungsantworten verfügen die Sequenznummern der Anforderungssequenznachricht und der Antwortsequenznachricht über keine Korrelation.

Wiederholen von Antworten

WCF nutzt die HTTP-Anforderung-Antwort-Korrelation für das bidirektionale Nachrichtenaustauschprotokoll. Daher wiederholt der WCF-Initiator eine Anforderungssequenznachricht auch dann weiter, wenn die Anforderungssequenznachricht bestätigt wird. Er hört erst dann auf, wenn die HTTP-Antwort eine Bestätigung, eine Benutzernachricht oder einen Fehler enthält. Der WCF-Beantworter wiederholt die Antworten auf den HTTP-Anforderungsabschnitt der Anforderung, mit der die Antwort korreliert ist.

LastMessage-Austausch

Der WCF-Initiator generiert und überträgt eine letzte Nachricht ohne Text auf den HTTP-Anforderungsabschnitt. WCF erfordert eine Antwort, ignoriert jedoch diese Antwortnachricht. Der WCF-Beantworter reagiert auf die letzte Anforderungssequenznachricht ohne Text mit einer letzten Antwortsequenznachricht ohne Text.

Wenn der WCF-Beantworter eine letzte Nachricht empfängt, in der der Aktions-URI nicht http://schemas.xmlsoap.org/ws/2005/02/rm/LastMessage ist, antwortet WCF mit einer letzten Nachricht. Im Fall eines bidirektionalen Nachrichtenaustauschprotokolls enthält die letzte Nachricht die Anwendungsnachricht, im Falle eines unidirektionalen Nachrichtenaustauschprotokolls ist die letzte Nachricht leer.

Der WCF-Beantworter benötigt keine Bestätigung für die letzte Antwortsequenznachricht ohne Text.

TerminateSequence-Austausch

Wenn alle Anforderungen eine gültige Antwort erhalten haben, generiert und überträgt derWCF -Initiator die TerminateSequence-Nachricht der Anforderungssequenz auf den HTTP-Anforderungsabschnitt. WCF erfordert eine Antwort, ignoriert jedoch diese Antwortnachricht. Der -Beantworter reagiert auf die TerminateSequence-Nachricht der Anforderungssequenz mit einer TerminateSequence-Nachricht der Antwortsequenz.

In einer normalen Abschlusssequenz enthalten beide TerminateSequence-Nachrichten einen vollständigen Bereich von SequenceAcknowledgement.

Adressierbarer Anforderung/Antwort-Initiator

Bindung

WCF bietet ein Anforderung-Antwort-Nachrichtenaustauschmuster unter Verwendung zweier Sequenzen über einen eingehenden und einen ausgehenden HTTP-Kanal. WCF verwendet HTTP-Anforderungen zur Übertragung aller Nachrichten. Alle HTTP-Antworten haben einen leeren Textbereich und den HTTP-Statuscode 202.

CreateSequence-Austausch

Der WCF-Initiator generiert eine CreateSequence-Nachricht mit Angebot. Der WCF-Beantworter stellt vor dem Erstellen einer Sequenz sicher, dass die CreateSequence-Nachricht ein Angebot aufweist. WCF sendet die CreateSequenceResponse über die HTTP-Anfrage, die an die CreateSequence-Endpunktreferenz derReplyTo adressiert ist.

Anforderung/Antwort-Korrelation

Der WCF-Initiator stellt sicher, dass alle Anwendungsanforderungsnachrichten eine MessageId und einen ReplyTo-Endpunktverweis enthalten. Der WCF-Initiator wendet den CreateSequence-Endpunktverweis der ReplyTo-Nachricht für jede Anwendungsanforderungsnachricht an. Der WCF-Beantworter erfordert, dass alle Anwendungsanforderungsnachrichten eine MessageId und einen ReplyTo-Endpunktverweis enthalten. Der WCF-Beantworter stellt sicher, dass die URIs der Endpunktverweise der CreateSequence-Nachrichten und aller Anwendungsanforderungsnachrichten identisch sind.