Note
Access to this page requires authorization. You can try signing in or changing directories.
Access to this page requires authorization. You can try changing directories.
See the diagram named WCF use cases in section 2.5.3.1.
Goal: A web client is guaranteed to consume data in the same order in which it requested the data.
Context of Use: A web client requires that the order in which it consumes data be the same as the order in which it requested the data.
Primary Actor: The primary actor is a web client.
Supporting Actors: The supporting actors are as follows:
Web service: Provides the remote application that the web client consumes.
RM Source: Helps the sender by assuring that the message is sent reliably to the client.
RM Destination: Makes sure that all the messages are received and notifies the RM Source about the missing message.
Preconditions: Preconditions are defined in [WSRM1-1] section 2.2.
Minimal Guarantees: The Web service receives the messages from the web client in the requested order.
Success Guarantee: The web client consumes all messages from the Web service in the requested order. The Web service receives all messages from the web client in the same order that they were sent.
Trigger: A web client is required to send messages reliably.
Main Success Scenario:
The web client submits a sequence of messages to the RM Source for reliable delivery.
The RM Source requests the creation of an outbound Sequence by sending a <CreateSequence> element in the body of a message to the RM Destination.
The RM Destination responds with a <CreateSequenceResponse> element in the body of a message to the RM Destination by returning a globally unique identifier (GUID).
The RM Source forwards messages that are sent by the web client with a <Sequence> element header block, which contains the sequence number of the message.
The RM Destination informs the RM Source of successful message receipt by using a <SequenceAcknowledgement> element header block. The RM Destination delivers the message to the Web service.
The RM Source sends the last message by adding a <LastMessage> element in the Sequence header to indicate the RM Destination that this is the last message in sequence. The RM Destination responds with the acknowledgment of the last message.
After receiving the acknowledgment of the last message, the RM Source sends a <TerminateSequence> element in the body of a message to the RM Destination to indicate that the Sequence is complete.
Variant:
Because the infrastructure might be unreliable, the following scenario shows how lost messages are retransmitted. The RM Source requests creation of a new Sequence.
The RM Destination creates a Sequence by returning a globally unique identifier (GUID).
The RM Source begins sending messages beginning with message number 1.
The RM Source includes a <LastMessage> element token to the last message in the sequence.
The message number n is lost in transit.
The RM Destination acknowledges receipt of message numbers 1 to n-1 and the messages after the nth message.
The RM Source retransmits the nth message. This message is a new message on the underlying transport, but it has the same sequence identifier and message number so that the RM Destination can recognize it as equivalent to the earlier message, in case both are received.
The RM Destination receives the second transmission of the message with MessageNumber n and acknowledges receipt of message numbers 1 to last.
The RM Source receives this acknowledgment and sends a <TerminateSequence> element message to the RM Destination indicating that the sequence is completed and reclaims any resources that are associated with the Sequence.
The RM Destination receives the <TerminateSequence> element message indicating that the RM Source does not send any more messages and reclaims any resources that are associated with the Sequence.