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) |
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’sReplyTo
,AcksTo
andOffer/Endpoint
.R1102: The
AcksTo
,ReplyTo
andOffer/Endpoint
endpoint references in theCreateSequence
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
andEndpoint
endpoint references are identical before creating a sequence.
- The WCF Responder verifies that the URI portion of the
R1103: The
AcksTo
,ReplyTo
andOffer/Endpoint
endpoint references in theCreateSequence
message should have the same set of reference parameters.- WCF does not enforce, but assumes that reference parameters of the
AcksTo
,ReplyTo
andOffer/Endpoint
endpoint references onCreateSequence
are identical and uses reference parameters from theReplyTo
endpoint reference for acknowledgements and converse sequence messages.
- WCF does not enforce, but assumes that reference parameters of the
B1104: The WCF Initiator does not generate the optional
Expires
orOffer/Expires
element in theCreateSequence
message.B1105: When accessing the
CreateSequence
message, the WCF Responder uses theExpires
value in theCreateSequence
element as theExpires
value in theCreateSequenceResponse
element. Otherwise, the WCF Responder reads and ignores theExpires
andOffer/Expires
values.B1106: When accessing the
CreateSequenceResponse
message, the WCF Initiator reads the optionalExpires
value but does not use it.B1107: The WCF Initiator and Responder always generate the optional
IncompleteSequenceBehavior
element in theCreateSequence/Offer
andCreateSequenceResponse
elements.B1108: WCF uses only the
DiscardFollowingFirstGap
andNoDiscard
values in theIncompleteSequenceBehavior
element.- WS-ReliableMessaging utilizes the
Offer
mechanism to establish the two converse correlated sequences that form a session.
- WS-ReliableMessaging utilizes the
B1109: If
CreateSequence
contains anOffer
element, the one way WCF Responder rejects the offered sequence by responding with aCreateSequenceResponse
without anAccept
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 anOffer
element, the two-way WCF Responder rejects the offered sequence by responding with aCreateSequenceRefused
fault.R1112: When two converse sequences are established using the
Offer
mechanism, the[address]
property of theCreateSequenceResponse/Accept/AcksTo
endpoint reference must match the destination URI of theCreateSequence
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>
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>
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 theCloseSequence/CloseSequenceResponse
handshake.R1302: WCF validates that the
LastMsgNumber
element is consistent across allCloseSequence
andTerminateSequence
messages for a given sequence. This means thatLastMsgNumber
is either not present on allCloseSequence
andTerminateSequence
messages, or it is present and identical on allCloseSequence
andTerminateSequence
messages.B1303: When receiving a
TerminateSequence
message after theCloseSequence/CloseSequenceResponse
handshake, the Reliable Messaging destination responds with aTerminateSequenceResponse
message. Because the Reliable Messaging source has the final acknowledgement before sending theTerminateSequence
message, the Reliable Messaging destination knows without doubt that the sequence ends, and reclaims resources immediately.B1304: When receiving a
TerminateSequence
message prior to theCloseSequence/CloseSequenceResponse
handshake, the WCF Reliable Messaging destination responds with aTerminateSequenceResponse
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 theFaulted
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>
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>
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>
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, theSequenceAcknowledgement
header may be included in any application message transmitted to the intended recipient. The remote endpoint must be able to access a piggybackedSequenceAcknowledgement
header.B1602: WCF does not generate
SequenceAcknowledgement
headers that containNack
elements. WCF validates that eachNack
element contains a sequence number, but otherwise ignores theNack
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>
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>
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
orTerminateSequence
message is missing aMessageId
header.A
CreateSequence
,CloseSequence
orTerminateSequence
message is missing aReplyTo
header.A
CreateSequenceResponse
,CloseSequenceResponse
, orTerminateSequenceResponse
message is missing aRelatesTo
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 theCreateSequence
message.
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.
WCF supports the use of both SOAP 1.1 and SOAP 1.2 with WS-Reliable Messaging.
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 thewsse:SecurityTokenReference
element and thewsrm:UsesSequenceSTR
header.
An example of a UsesSequenceSTR
header.
<wsrm:UsesSequenceSTR></wsrm:UsesSequenceSTR>
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 awsrm:UsesSequenceSSL
header to a WCF Responder.
WCF supports two versions of WS-Policy: WS-Policy 1.2 and WS-Policy 1.5.
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 towsdl:binding
elements. WCF supports both attachments towsdl:binding
andwsdl:port
elements.B3002: WCF never generates the
wsp:Optional
tag.B3003: When accessing the
wsrmp:RMAssertion
WS-Policy Assertion, WCF ignores thewsp: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 WCF
ReliableSessionBindingElement
: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>
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 theSequenceAcknowledgement
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 theSequenceAcknowledgement
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 andxs:int
’smaxInclusive
value 214748364 inclusive.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
The following applies to all correlated requests and replies:
WCF ensures all application request messages bear a
ReplyTo
endpoint reference and aMessageId
.WCF applies the local endpoint reference as each application request message’s
ReplyTo
. The local endpoint reference is theCreateSequence
message’sReplyTo
for the Initiator and theCreateSequence
message’sTo
for the Responder.WCF ensures that incoming request messages bear a
MessageId
and aReplyTo
.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
andTo
headers followingwsa
request/reply correlation rules.