Редактиране

Споделяне чрез

Reliable Messaging Protocol version 1.1

  • Статия

This topic covers Windows Communication Foundation (WCF) implementation details for the WS-ReliableMessaging February 2007 (version 1.1) protocol necessary for interoperation using the HTTP transport. WCF follows the WS-ReliableMessaging specification with the constraints and clarifications explained in this topic. Note that the WS-ReliableMessaging version 1.1 protocol is implemented starting with .NET Framework 3.5.

The WS-ReliableMessaging February 2007 protocol is implemented in WCF by the ReliableSessionBindingElement.

For convenience, the topic uses the following roles:

  • Initiator: The client that initiates WS-Reliable Message sequence creation.

  • Responder: The service that receives the initiator's requests.

This document uses the prefixes and namespaces in the following table.

Prefix Namespace
wsrm http://docs.oasis-open.org/ws-rx/wsrm/200702
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
wsrmp http://docs.oasis-open.org/ws-rx/wsrmp/200702
netrmp http://schemas.microsoft.com/ws-rx/wsrmp/200702
wsp (Either WS-Policy 1.2 or WS-Policy 1.5)

Messaging

Sequence Creation

WCF implements CreateSequence and CreateSequenceResponse messages to establish a reliable messaging sequence. The following constraints apply:

  • B1101: The WCF Initiator uses the same endpoint reference as the CreateSequence message’s ReplyTo, AcksTo and Offer/Endpoint.

  • R1102: The AcksTo, ReplyTo and Offer/Endpoint endpoint references in the CreateSequence message must have address values with identical string representations such that they match the octet-wise.

    • The WCF Responder verifies that the URI portion of the AcksTo, ReplyTo and Endpoint endpoint references are identical before creating a sequence.

  • R1103: The AcksTo, ReplyTo and Offer/Endpoint endpoint references in the CreateSequence message should have the same set of reference parameters.

    • WCF does not enforce, but assumes that reference parameters of the AcksTo, ReplyTo and Offer/Endpoint endpoint references on CreateSequence are identical and uses reference parameters from the ReplyTo endpoint reference for acknowledgements and converse sequence messages.

  • B1104: The WCF Initiator does not generate the optional Expires or Offer/Expires element in the CreateSequence message.

  • B1105: When accessing the CreateSequence message, the WCF Responder uses the Expires value in the CreateSequence element as the Expires value in the CreateSequenceResponse element. Otherwise, the WCF Responder reads and ignores the Expires and Offer/Expires values.

  • B1106: When accessing the CreateSequenceResponse message, the WCF Initiator reads the optional Expires value but does not use it.

  • B1107: The WCF Initiator and Responder always generate the optional IncompleteSequenceBehavior element in the CreateSequence/Offer and CreateSequenceResponse elements.

  • B1108: WCF uses only the DiscardFollowingFirstGap and NoDiscard values in the IncompleteSequenceBehavior element.

    • WS-ReliableMessaging utilizes the Offer mechanism to establish the two converse correlated sequences that form a session.

  • B1109: If CreateSequence contains an Offer element, the one way WCF Responder rejects the offered sequence by responding with a CreateSequenceResponse without an Accept element.

  • B1110: If a Reliable Messaging Responder rejects the offered sequence, the WCF Initiator faults the newly established sequence.

  • B1111: If CreateSequence does not contain an Offer element, the two-way WCF Responder rejects the offered sequence by responding with a CreateSequenceRefused fault.

  • R1112: When two converse sequences are established using the Offer mechanism, the [address] property of the CreateSequenceResponse/Accept/AcksTo endpoint reference must match the destination URI of the CreateSequence message byte for byte.

  • R1113: When two converse sequences are established using the Offer mechanism, all messages on both sequences flowing from the Initiator to the Responder must be sent to the same endpoint reference.

WCF uses WS-ReliableMessaging to establish reliable sessions between the Initiator and the Responder. The WCF WS-ReliableMessaging implementation provides a reliable session for one-way, request-reply and full duplex messaging patterns. The WS-ReliableMessaging Offer mechanism on CreateSequence and CreateSequenceResponse lets you establish two correlated converse sequences and provides a session protocol that is suitable for all message endpoints. Because WCF provides a security guarantee for such a session including end-to-end protection for session integrity, it is practical to ensure that messages intended for the same party arrive at the same destination. This also allows "piggy-backing" of sequence acknowledgements on application messages. Therefore, constraints R1102, R1112, and R1113 apply to WCF.

An example of a CreateSequence message.

<s:Envelope>
  <s:Header>
    <wsa:Action s:mustUnderstand="1">http://docs.oasis-open.org/ws-rx/wsrm/200702/CreateSequence</wsa:Action>
    <wsa:MessageID>urn:uuid:949cca61-8813-42ff-ab33-18d9e3fa82fa</wsa:MessageID>
    <wsa:ReplyTo>
        <wsa:Address>http://Business456.com/clientA</wsa:Address>
    </wsa:ReplyTo>
    <wsa:To s:mustUnderstand="1">http://BusinessABC.com/serviceA</wsa: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:066b4730-fc82-458a-a5c1-210be4fb4e4e</wsrm:Identifier>
        <wsrm:Endpoint>
          <wsa:Address>http://Business456.com/clientA</wsa:Address>
        </wsrm:Endpoint>
        <wsrm:IncompleteSequenceBehavior>DiscardFollowingFirstGap</wsrm:IncompleteSequenceBehavior>
      </wsrm:Offer>
    </wsrm:CreateSequence>
  </s:Body>
</s:Envelope>

An example of a CreateSequenceResponse message.

<s:Envelope>
  <s:Header>
    <wsa:Action s:mustUnderstand="1">http://docs.oasis-open.org/ws-rx/wsrm/200702/CreateSequenceResponse</wsa:Action>
    <wsa:RelatesTo>urn:uuid:949cca61-8813-42ff-ab33-18d9e3fa82fa</wsa:RelatesTo>
    <wsa:To s:mustUnderstand="1">http://Business456.com/clientA</wsa:To>
  </s:Header>
  <s:Body>
    <wsrm:CreateSequenceResponse>
      <wsrm:Identifier>urn:uuid:656652b8-9af2-4e94-9d07-2dc21c05ed27</wsrm:Identifier>
      <wsrm:IncompleteSequenceBehavior>DiscardFollowingFirstGap</wsrm:IncompleteSequenceBehavior>
      <wsrm:Accept>
        <wsrm:AcksTo>
          <wsa:Address>http://BusinessABC.com/serviceA</wsa:Address>
        </wsrm:AcksTo>
      </wsrm:Accept>
    </wsrm:CreateSequenceResponse>
  </s:Body>
</s:Envelope>

Closing a Sequence

WCF uses the CloseSequence and CloseSequenceResponse messages for a Reliable Messaging source-initiated shutdown. The WCF Reliable Messaging destination does not initiate shutdown and the WCF Reliable Messaging source does not support a Reliable Messaging destination-initiated shutdown. The following constraints apply:

  • B1201: The WCF Reliable Messaging source always sends a CloseSequence message to shut down the sequence.

  • B1202: The Reliable Messaging source waits for acknowledgement of the full range of sequence messages before sending the CloseSequence message.

  • B1203: The Reliable Messaging source always includes the optional LastMsgNumber element unless the sequence does not contain messages.

  • R1204: The Reliable Messaging destination must not initiate shutdown by sending a CloseSequence message.

  • B1205: Upon receiving a CloseSequence message, the WCF Reliable Messaging source considers the sequence incomplete and sends a fault.

An example of a CloseSequence message.

<s:Envelope>
  <s:Header>
    <wsa:Action s:mustUnderstand="1">http://docs.oasis-open.org/ws-rx/wsrm/200702/CloseSequence</wsa:Action>
    <wsa:MessageID>urn:uuid:6ce1d4c3-e1c1-474f-a8c9-4210e37f7877</wsa:MessageID>
    <wsa:ReplyTo>
      <wsa:Address>http://Business456.com/clientA</wsa:Address>
    </wsa:ReplyTo>
    <wsa:To s:mustUnderstand="1">http://BusinessABC.com/serviceA</wsa:To>
  </s:Header>
  <s:Body>
    <wsrm:CloseSequence>
      <wsrm:Identifier>urn:uuid:656652b8-9af2-4e94-9d07-2dc21c05ed27</wsrm:Identifier>
      <wsrm:LastMsgNumber>30</wsrm:LastMsgNumber>
    </wsrm:CloseSequence>
  </s:Body>
</s:Envelope>

Example CloseSequenceResponse message:

<s:Envelope>
  <s:Header>
    <wsrm:SequenceAcknowledgement>
      <wsrm:Identifier>urn:uuid:656652b8-9af2-4e94-9d07-2dc21c05ed27</wsrm:Identifier>
      <wsrm:AcknowledgementRange Lower="1" Upper="30"></wsrm:AcknowledgementRange>
      <wsrm:Final></wsrm:Final>
      <netrm:BufferRemaining>8</netrm:BufferRemaining>
    </wsrm:SequenceAcknowledgement>
    <wsa:Action s:mustUnderstand="1">http://docs.oasis-open.org/ws-rx/wsrm/200702/CloseSequenceResponse</wsa:Action>
    <wsa:RelatesTo>urn:uuid:6ce1d4c3-e1c1-474f-a8c9-4210e37f7877</wsa:RelatesTo>
    <wsa:To s:mustUnderstand="1">http://Business456.com/clientA</wsa:To>
  </s:Header>
  <s:Body>
    <wsrm:CloseSequenceResponse>
      <wsrm:Identifier>urn:uuid:656652b8-9af2-4e94-9d07-2dc21c05ed27</wsrm:Identifier>
    </wsrm:CloseSequenceResponse>
  </s:Body>
</s:Envelope>

Sequence Termination

WCF primarily uses the TerminateSequence/TerminateSequenceResponse handshake after completing the CloseSequence/CloseSequenceResponse handshake. The WCF Reliable Messaging destination does not initiate termination and the Reliable Messaging source does not support a Reliable Messaging destination-initiated termination. The following constraints apply:

  • B1301: The WCF Initiator only sends the TerminateSequence message after the successful completion of the CloseSequence/CloseSequenceResponse handshake.

  • R1302: WCF validates that the LastMsgNumber element is consistent across all CloseSequence and TerminateSequence messages for a given sequence. This means that LastMsgNumber is either not present on all CloseSequence and TerminateSequence messages, or it is present and identical on all CloseSequence and TerminateSequence messages.

  • B1303: When receiving a TerminateSequence message after the CloseSequence/CloseSequenceResponse handshake, the Reliable Messaging destination responds with a TerminateSequenceResponse message. Because the Reliable Messaging source has the final acknowledgement before sending the TerminateSequence message, the Reliable Messaging destination knows without doubt that the sequence ends, and reclaims resources immediately.

  • B1304: When receiving a TerminateSequence message prior to the CloseSequence/CloseSequenceResponse handshake, the WCF Reliable Messaging destination responds with a TerminateSequenceResponse message. If the Reliable Messaging destination determines that there are no inconsistencies in the sequence, the Reliable Messaging destination waits for an application destination-specified time before reclaiming resources, to allow the client the chance to receive the final acknowledgement. Otherwise, the Reliable Messaging destination reclaims resources immediately and indicates to the application destination that the sequence ends with doubt by raising the Faulted event.

An example of a TerminateSequence message.

<s:Envelope>
  <s:Header>
    <wsa:Action s:mustUnderstand="1">http://docs.oasis-open.org/ws-rx/wsrm/200702/TerminateSequence</wsa:Action>
    <wsa:MessageID>urn:uuid:3597a398-4f3c-40f4-9335-8f1515572fdf</wsa:MessageID>
    <wsa:ReplyTo>
      <wsa:Address>http://Business456.com/clientA</wsa:Address>
    </wsa:ReplyTo>
    <wsa:To s:mustUnderstand="1">http://BusinessABC.com/serviceA</wsa:To>
  </s:Header>
  <s:Body>
    <wsrm:TerminateSequence>
      <wsrm:Identifier>urn:uuid:656652b8-9af2-4e94-9d07-2dc21c05ed27</wsrm:Identifier>
      <wsrm:LastMsgNumber>30</wsrm:LastMsgNumber>
      </wsrm:TerminateSequence>
  </s:Body>
</s:Envelope>

Example TerminateSequenceResponse message:

<s:Envelope>
  <s:Header>
    <wsrm:SequenceAcknowledgement>
      <wsrm:Identifier>urn:uuid:656652b8-9af2-4e94-9d07-2dc21c05ed27</wsrm:Identifier>
      <wsrm:AcknowledgementRange Lower="1" Upper="30"></wsrm:AcknowledgementRange>
      <wsrm:Final></wsrm:Final>
      <netrm:BufferRemaining>8</netrm:BufferRemaining>
    </wsrm:SequenceAcknowledgement>
    <wsa:Action s:mustUnderstand="1">http://docs.oasis-open.org/ws-rx/wsrm/200702/TerminateSequenceResponse</wsa:Action>
    <wsa:RelatesTo>urn:uuid:3597a398-4f3c-40f4-9335-8f1515572fdf</wsa:RelatesTo>
    <wsa:To s:mustUnderstand="1">://Business456.com/clientA</wsa:To>
  </s:Header>
  <s:Body>
    <wsrm:TerminateSequenceResponse>
      <wsrm:Identifier>urn:uuid:656652b8-9af2-4e94-9d07-2dc21c05ed27</wsrm:Identifier>
    </wsrm:TerminateSequenceResponse>
  </s:Body>
</s:Envelope>

Sequences

The following is a list of constraints that apply to sequences:

  • B1401:WCF generates and accesses sequence numbers no higher than xs:long’s maximum inclusive value, 9223372036854775807.

An example of a Sequence header.

<wsrm:Sequence s:mustUnderstand="1">
  <wsrm:Identifier>urn:uuid:656652b8-9af2-4e94-9d07-2dc21c05ed27</wsrm:Identifier>
  <wsrm:MessageNumber>1</wsrm:MessageNumber>
</wsrm:Sequence>

Request Acknowledgement

WCF uses the AckRequested header as a keep-alive mechanism.

An example of an AckRequested header.

<wsrm:AckRequested>
  <wsrm:Identifier>urn:uuid:656652b8-9af2-4e94-9d07-2dc21c05ed27</wsrm:Identifier>
</wsrm:AckRequested>

SequenceAcknowledgement

WCF uses a "piggy-back" mechanism for sequence acknowledgements provided in WS-Reliable Messaging. The following constraints apply:

  • R1601: When two converse sequences are established using the Offer mechanism, the SequenceAcknowledgement header may be included in any application message transmitted to the intended recipient. The remote endpoint must be able to access a piggybacked SequenceAcknowledgement header.

  • B1602: WCF does not generate SequenceAcknowledgement headers that contain Nack elements. WCF validates that each Nack element contains a sequence number, but otherwise ignores the Nack element and value.

An example of a SequenceAcknowledgement header.

<wsrm:SequenceAcknowledgement>
  <wsrm:Identifier>urn:uuid:656652b8-9af2-4e94-9d07-2dc21c05ed27</wsrm:Identifier>
  <wsrm:AcknowledgementRange Lower="1" Upper="1"></wsrm:AcknowledgementRange>
</wsrm:SequenceAcknowledgement>

WS-ReliableMessaging Faults

The following is a list of constraints that apply to the WCF implementation of WS-ReliableMessaging faults. The following constraints apply:

  • B1701: WCF does not generate MessageNumberRollover faults.

  • B1702: Over SOAP 1.2, when the service endpoint reaches its connection limit and cannot process new connections, WCF generates a nested CreateSequenceRefused fault subcode, netrm:ConnectionLimitReached, as shown in the following example.

<s:Envelope>
  <s:Header>
    <wsa:Action>http://docs.oasis-open.org/ws-rx/wsrm/200702/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">Server 'http://BusinessABC.com/serviceA' is too busy to process this request. Try again later.</s:Text>
      </s:Reason>
    </s:Fault>
  </s:Body>
</s:Envelope>

WS-Addressing Faults

Because WS-ReliableMessaging uses WS-Addressing, the WCF WS-ReliableMessaging implementation may generate and transmit WS-Addressing faults. This section covers the WS-Addressing faults that WCF explicitly generates and transmits at the WS-ReliableMessaging layer:

  • B1801:WCF generates and transmits the Message Addressing Header Required fault when one of the following is true:

    • A CreateSequence, CloseSequence or TerminateSequence message is missing a MessageId header.

    • A CreateSequence, CloseSequence or TerminateSequence message is missing a ReplyTo header.

    • A CreateSequenceResponse, CloseSequenceResponse, or TerminateSequenceResponse message is missing a RelatesTo header.

  • B1802:WCF generates and transmits the Endpoint Unavailable fault to indicate there is no endpoint listening that can process the sequence based on examination of the addressing headers in the CreateSequence message.

Protocol Composition

Composition with WS-Addressing

WCF supports two versions of WS-Addressing: WS-Addressing 2004/08 [WS-ADDR] and W3C WS-Addressing 1.0 Recommendations [WS-ADDR-CORE] and [WS-ADDR-SOAP].

While the WS-ReliableMessaging specification mentions only WS-Addressing 2004/08, it does not restrict the WS-Addressing version to be used. The following is a list of constraints that apply to WCF:

  • R2101: Both WS-Addressing 2004/08 and WS-Addressing 1.0 can be used with WS-Reliable Messaging.

  • R2102: A single version of WS-Addressing must be used throughout a given WS-ReliableMessaging sequence or a pair of converse sequences correlated by using the Offer mechanism.

Composition with SOAP

WCF supports the use of both SOAP 1.1 and SOAP 1.2 with WS-Reliable Messaging.

Composition with WS-Security and WS-SecureConversation

WCF provides protection for WS-ReliableMessaging sequences by using secure Transport (HTTPS), composition with WS-Security, and composition with WS-Secure Conversation. The WS-ReliableMessaging 1.1 protocol, WS-Security 1.1 and WS-Secure Conversation 1.3 protocol should be used together. The following is a list of constraints that apply to WCF:

  • R2301: To protect the integrity of a WS-ReliableMessaging sequence in addition to the integrity and confidentiality of individual messages, WCF requires that WS-Secure Conversation must be used.

  • R2302:AWS-Secure Conversation session must be established prior to establishing WS-ReliableMessaging sequence(s).

  • R2303: If the WS-ReliableMessaging sequence lifetime exceeds the WS-Secure Conversation session’s lifetime, the SecurityContextToken established by using WS-Secure Conversation must be renewed by using the corresponding WS-Secure Conversation Renewal binding.

  • B2304:WS-ReliableMessaging sequence or a pair of correlated converse sequences are always bound to a single WS-SecureConversation session.

  • R2305: When composed with WS-Secure Conversation, the WCF responder requires that the CreateSequence message contain the wsse:SecurityTokenReference element and the wsrm:UsesSequenceSTR header.

An example of a UsesSequenceSTR header.

<wsrm:UsesSequenceSTR></wsrm:UsesSequenceSTR>

Composition with SSL/TLS sessions

WCF does not support composition with SSL/TLS sessions:

  • B2401: WCF does not generate the wsrm:UsesSequenceSSL header.

  • R2402: A Reliable Messaging Initiator must not send a CreateSequence message with a wsrm:UsesSequenceSSL header to a WCF Responder.

Composition with WS-Policy

WCF supports two versions of WS-Policy: WS-Policy 1.2 and WS-Policy 1.5.

WS-ReliableMessaging WS-Policy Assertion

WCF uses WS-ReliableMessaging WS-Policy Assertion wsrm:RMAssertion to describe endpoints capabilities. The following is a list of constraints that apply to WCF:

  • B3001: WCF attaches wsrmn:RMAssertion WS-Policy Assertion to wsdl:binding elements. WCF supports both attachments to wsdl:binding and wsdl:port elements.

  • B3002: WCF never generates the wsp:Optional tag.

  • B3003: When accessing the wsrmp:RMAssertion WS-Policy Assertion, WCF ignores the wsp:Optional tag and treats the WS-RM policy as mandatory.

  • R3004: Because WCF does not compose with SSL/TLS sessions, WCF does not accept policy that specifies wsrmp:SequenceTransportSecurity.

  • B3005: WCF always generates the wsrmp:DeliveryAssurance element.

  • B3006: WCF always specifies the wsrmp:ExactlyOnce delivery assurance.

  • B3007: WCF generates and reads the following properties of the WS-ReliableMessaging assertion and provides control over them on the WCFReliableSessionBindingElement:

    • netrmp:InactivityTimeout

    • netrmp:AcknowledgementInterval

    An example of a RMAssertion.

    <wsrmp:RMAssertion>
  <wsp:Policy>
    <wsrmp:SequenceSTR/>
    <wsrmp:DeliveryAssurance>
      <wsp:Policy>
        <wsrmp:ExactlyOnce/>
        <wsrmp:InOrder/>
      </wsp:Policy>
    </wsrmp:DeliveryAssurance>
  </wsp:Policy>
  <netrmp:InactivityTimeout Milliseconds="600000"/>
  <netrmp:AcknowledgementInterval Milliseconds="200"/>
</wsrmp:RMAssertion>

Flow Control WS-ReliableMessaging Extension

WCF uses WS-ReliableMessaging extensibility to provide optional additional tighter control over sequence message flow.

Flow control is enabled by setting the ReliableSessionBindingElement.FlowControlEnabled property to true. The following is a list of constraints that apply to WCF:

  • B4001: When Reliable Messaging Flow Control is enabled, WCF generates a netrm:BufferRemaining element in the element extensibility of the SequenceAcknowledgement header, as shown in the following example.

    <wsrm:SequenceAcknowledgement>
  <wsrm:Identifier>urn:uuid:656652b8-9af2-4e94-9d07-2dc21c05ed27</wsrm:Identifier>
  <wsrm:AcknowledgementRange Upper="1" Lower="1"/>
  <netrm:BufferRemaining>8</netrm:BufferRemaining>
</wsrm:SequenceAcknowledgement>

  • B4002: Even when Reliable Messaging Flow Control is enabled, WCF does not require a netrm:BufferRemaining element in the SequenceAcknowledgement header.

  • B4003: WCF Reliable Messaging Destination uses netrm:BufferRemaining to indicate how many new messages it can buffer.

  • B4004:When Reliable Messaging Flow Control is enabled, the WCF Reliable Messaging Source uses the value of netrm:BufferRemaining to throttle message transmission.

  • B4005: WCF generates netrm:BufferRemaining integer values between 0 and 4096 inclusive, and reads integer values between 0 and xs:int’s maxInclusive value 214748364 inclusive.

Message Exchange Patterns

This section describes WCF's behavior when WS-ReliableMessaging is used for different Message Exchange Patterns. For each Message Exchange Pattern the following two deployments scenarios are considered:

  • Non-Addressable Initiator: Initiator is behind a firewall; Responder can deliver messages to the Initiator only on HTTP responses.

  • Addressable Initiator: Initiator and Responder both can be sent HTTP requests; in other words, two converse HTTP connections can be established.

One-way, Non-addressable Initiator

Binding

WCF provides a one-way message exchange pattern using one sequence over one HTTP channel. WCF uses HTTP requests to transmit all messages from the Initiator to the Responder and HTTP responses to transmit all messages from the Responder to the Initiator.

CreateSequence Exchange

The WCF Initiator transmits a CreateSequence message with no Offer element on an HTTP request and expects the CreateSequenceResponse message on the HTTP response. The WCF Responder creates a sequence and transmits the CreateSequenceResponse message with no Accept element on the HTTP response.

SequenceAcknowledgement

The WCF Initiator processes acknowledgements on the reply of all messages except the CreateSequence message and fault messages. The WCF Responder always transmits a stand-alone acknowledgement on the HTTP response to all sequence and AckRequested messages.

CloseSequence Exchange

The WCF Initiator transmits a CloseSequence message on an HTTP request and expects the CreateSequenceResponse message on the HTTP response. The WCF Responder transmits the CloseSequenceResponse message on the HTTP response.

TerminateSequence Exchange

The WCF Initiator transmits a TerminateSequence message on an HTTP request and expects the TerminateSequenceResponse message on the HTTP response. The WCF Responder transmits the TerminateSequenceResponse message on the HTTP response.

One Way, Addressable Initiator

Binding

WCF provides a one-way message exchange pattern using one sequence over one inbound and one outbound HTTP channel. WCF uses the HTTP requests to transmit all messages. All HTTP responses have an empty body and HTTP 202 status code.

CreateSequence Exchange

The WCF Initiator transmits a CreateSequence message with no Offer element on an HTTP request. The WCF Responder creates a sequence and transmits the CreateSequenceResponse message with no Accept element on an HTTP request.

Duplex, Addressable Initiator

Binding

WCF provides a fully-asynchronous, two-way message exchange pattern using two sequences over one inbound and one outbound HTTP channel. This message exchange pattern can be mixed with the Request/Reply, Addressable Initiator message exchange pattern in a limited way. WCF uses HTTP requests to transmit all messages. All HTTP responses have an empty body and HTTP 202 status code.

CreateSequence Exchange

The WCF Initiator transmits a CreateSequence message with an Offer element on an HTTP request. The WCF Responder ensures that the CreateSequence has an Offer element, then creates a sequence and transmits the CreateSequenceResponse message with an Accept element.

Sequence Lifetime

WCF treats the two sequences as one fully-duplex session.

Upon generating a fault that faults one sequence, WCF expects the remote endpoint to fault both sequences. Upon reading a fault that faults one sequence, WCF faults both sequences.

WCF can close its outbound sequence and continue to process messages on its inbound sequence. Conversely, WCF can process the close of the inbound sequence and continue to send messages on its outbound sequence.

Request-Reply and One-Way, Non-Addressable Initiator

Binding

WCF provides a one-way and request-reply message exchange pattern using two sequences over one HTTP channel. WCF uses HTTP requests to transmit all messages from the Initiator to the Responder and HTTP responses to transmit all messages from the Responder to the Initiator.

CreateSequence Exchange

The WCF Initiator transmits a CreateSequence message with an Offer element on an HTTP request and expects the CreateSequenceResponse message on the HTTP response. The WCF Responder creates a sequence and transmits the CreateSequenceResponse message with an Accept element on the HTTP response.

One-way Message

To complete a one-way message exchange successfully, the WCF Initiator transmits a request sequence message on the HTTP request and receives a standalone SequenceAcknowledgement message on the HTTP response. The SequenceAcknowledgement must acknowledge the message transmitted.

The WCF Responder may reply to the request with an acknowledgement, a fault, or a response with an empty body and HTTP 202 status code.

Two Way Messages

To complete a two way message exchange protocol successfully, the WCF Initiator transmits a request sequence message on the HTTP request and receives a reply sequence message on the HTTP response. The response must carry a SequenceAcknowledgement acknowledging the request sequence message transmitted.

The WCF Responder may reply to the request with an application reply, a fault or a response with an empty body and HTTP 202 status code.

Because of the presence of one-way messages and the timing of application replies, the request sequence message’s sequence number and the response message’s sequence number have no correlation.

Retrying Replies

WCF relies on HTTP request-reply correlation for two-way message exchange protocol correlation. Because of this, the WCF Initiator does not stop retrying a request sequence message when the request sequence message is acknowledged but rather when the HTTP response carries a SequenceAcknowledgement, application reply, or fault. The WCF Responder retries replies on the HTTP response of the request to which the reply is correlated.

CloseSequence Exchange

After receiving all reply sequence messages and acknowledgements for all one way request sequence messages, the WCF Initiator transmits a CloseSequence message for the request sequence on an HTTP request and expects the CloseSequenceResponse on the HTTP response.

Closing the request sequence implicitly closes the reply sequence. This means the WCF Initiator includes the reply sequence’s Final SequenceAcknowledgement on the CloseSequence message and the reply sequence does not have a CloseSequence exchange.

The WCF Responder ensures all replies are acknowledged and transmits the CloseSequenceResponse message on the HTTP response.

TerminateSequence Exchange

After receiving the CloseSequenceResponse message, the WCF Initiator transmits a TerminateSequence message for the request sequence on an HTTP request and expects the TerminateSequenceResponse on the HTTP response.

Like the CloseSequence exchange, terminating the request sequence implicitly terminates the reply sequence. This means the WCF Initiator includes the reply sequence’s final SequenceAcknowledgement on the TerminateSequence message and the reply sequence does not have a TerminateSequence exchange.

The WCF Responder transmits the TerminateSequenceResponse message on the HTTP response.

Request/Reply, Addressable Initiator

Binding

WCF provides a request-reply message exchange pattern using two sequences over one inbound and one outbound HTTP channel. This message exchange pattern can be mixed with the Duplex, Addressable Initiator message exchange pattern in a limited way. WCF uses the HTTP requests to transmit all messages. All HTTP responses have an empty body and HTTP 202 status code.

CreateSequence Exchange

The WCF Initiator transmits a CreateSequence message with an Offer element on an HTTP request. The WCF Responder ensures that the CreateSequence has an Offer element then creates a sequence and transmits the CreateSequenceResponse message with an Accept element.

Request/Reply Correlation

The following applies to all correlated requests and replies:

  • WCF ensures all application request messages bear a ReplyTo endpoint reference and a MessageId.

  • WCF applies the local endpoint reference as each application request message’s ReplyTo. The local endpoint reference is the CreateSequence message’s ReplyTo for the Initiator and the CreateSequence message’s To for the Responder.

  • WCF ensures that incoming request messages bear a MessageId and a ReplyTo.

  • WCF ensures the ReplyTo endpoint reference’s URI of all application request messages match the local endpoint reference as defined earlier.

  • WCF ensures that all replies bear the correct RelatesTo and To headers following wsa request/reply correlation rules.