Section 10.4. Processing Model
|
10.4. Processing ModelThe WS-Reliable Messaging specification defines an abstract model for the protocol and four distinct roles: Application Source and RM Source on the sending endpoint, and Application Destination and RM Destination at the receiving endpoint. The Application Source role is typically played by the application code running on the endpoint from which messages are to be delivered reliably. It initiates the protocol by sending a message (logically) to the RM Source, which then assumes responsibility for transmittingand possibly retransmittingthe message to the destination role at the receiving endpoint. The RM Source is also responsible for processing any SequenceAcknowledgement messages from the RM Destination and taking appropriate action. The RM Destination role at the receiving endpoint receives messages (re)transmitted by the RM Source role at the sending endpoint. It is responsible for acknowledging receipt of the message and (logically) delivering the message to the Application Destination role, which is typically played by the application code that runs on the receiving endpoint. The RM Destination role is responsible for affecting the quality of service associated with the Delivery Assurance policy specified for the receiving endpoint. Figure 10-1 demonstrates this model. Figure 10-1. Reliable Messaging model. This model is like that of the TCP protocol. The WS-Reliable Messaging protocol is limited in its scope to the RM Source and RM Destination roles at either endpoint. Aside from the assurances that the RM Destination observes to fulfill the specified delivery assurances (At-Most-Once, At-Least-Once, Exactly-Once, and Ordered), the Application Source role can only be certain that the message has been reliably delivered to the RM Destination role at the receiving endpoint. If the application code at the Application Source role needs to have some sort of application-level acknowledgement that the message was actually processed, the WS-Reliable Messaging protocol is inadequate for the task. An application-specific acknowledgement message is required, such as a PurchaseOrderAck as an application-level acknowledgement/response to a submitted PurchaseOrder. Note, however, that this separation of concerns is important. Examine the previous example in light of this separation of concerns. Consider that a PurchaseOrderAck message sent in response to a PurchaseOrder submission message might take upward of 24 hours to process in the use case, where the receiving partner processes its received PurchaseOrders in a batch window once a day. Waiting 24 hours for some indication that a PurchaseOrder has been lost in transit between the sending and receiving endpoints can have serious consequences for the business partner that makes the request. It can even lead to loss of revenue when order fulfillment is time-sensitive. Clearly, relying exclusively on the application-level acknowledgement as an indicator that the message was successfully transmitted is not an ideal situation for all use cases. Leveraging an infrastructure-level (or, more precisely, a middleware-level) acknowledgement, decoupled from the application-level processing of the message, as the indicator of successful transmission of a message enables the sending endpoint to respond more quickly to failed transmission attempts. The failed message transmission can be retried until its receipt has been acknowledged. The receiving software can take the necessary steps to ensure that the message is eventually delivered to the application by means of a persistent store or message queue that the receiving application accesses when it is ready and able. This model is highly effective at mitigating the issues discussed earlier in the "Motivation for Reliable Messaging" section. The ensuing sections discuss how the WS-Reliable Messaging protocol realizes this model. 10.4.1. Sequence LifecycleAn RM Sequence has a well-defined lifecycle. It begins with the RM Source requesting the creation of a new Sequence of the RM Destination using the CreateSequence operation. The following example demonstrates the CreateSequence message. <?xml version="1.0" encoding="UTF-8"?> <soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope" xmlns:wsrm="http://schemas.xmlsoap.org/ws/2005/02/rm" xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/08/addressing"> <soap:Header> <wsa:MessageID> http://example.com/guid/0baaf88d-483b-4ecf-a6d8-a7c2eb546817 </wsa:MessageID> <wsa:To>http://example.com/service/B</wsa:To> <wsa:Action> http://schemas.xmlsoap.org/ws/2005/02/rm/CreateSequence </wsa:Action> <wsa:ReplyTo> <wsa:Address>http://example.com/service/A</wsa:Address> </wsa:ReplyTo> </soap:Header> <soap:Body> <wsrm:CreateSequence> <wsrm:AcksTo> <wsa:Address>http://example.com/service/A</wsa:Address> </wsrm:AcksTo> </wsrm:CreateSequence> </soap:Body> </soap:Envelope> The CreateSequence element has a single required child element, the AcksTo, which indicates the WS-Addressing endpoint to which SequenceAcknowledgement messages are to be delivered. Upon receipt of the CreateSequence message, the RM Destination responds by creating a new Sequence, assigning it a unique identifier, and by returning a CreateSequenceResponse message, containing the Sequence's identifier, to the RM Source. The following example demonstrates a CreateSequenceResponse message. <?xml version="1.0" encoding="UTF-8"?> <soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope" xmlns:wsrm="http://schemas.xmlsoap.org/ws/2005/02/rm" xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/08/addressing"> <soap:Header> <wsa:MessageID> http://example.com.com/guid/0baaf88d-483b-4ecf-a6d8- a7c2eb546818 </wsa:MessageID> <wsa:To>http://example.com/service/A</wsa:To> <wsa:RelatesTo> http://example.com/guid/0baaf88d-483b-4ecf-a6d8a7c2eb546817 </wsa:RelatesTo> <wsa:Action> http://schemas.xmlsoap.org/ws/2005/02/rm/CreateSequenceResponse </wsa:Action> </soap:Header> <soap:Body> <wsrm:CreateSequenceResponse> <wsrm:Identifier>http://example.com/RM/ABC</wsrm:Identifier> </wsrm:CreateSequenceResponse> </soap:Body> </soap:Envelope> The Sequence then transmits messages between the RM Source and the RM Destination. When all of the messages in a Sequence have been transmitted and successfully acknowledged, the Sequence is terminated. Upon receipt of the SequenceAcknowledgement that acknowledges the entire range of messages in the Sequence, the RM Source sends a TerminateSequence one-way message to the RM Destination. Upon receipt of the TerminateSequence message, the RM Destination is free to reclaim any resources that are associated with the Sequence. It can do so because it can be assured that the RM Source has received the final SequenceAcknowledgement message covering the full range of messages in the Sequence and will be sending no further messages in the Sequence. If the RM Destination receives any subsequent messages in the Sequence, it can be assured that these messages must have been caught in the network and can be safely discarded without action. In fact, if the RM Destination receives any message belonging to a Sequence about which it has no knowledge, it can safely discard the message without taking action because it can assume that the message belongs to a Sequence that has been terminated. If the RM Destination does not receive the TerminateSequence message, it may preserve the state associated with the Sequence until the Sequence expiry duration expires so that it can respond with a retransmission of the final SequenceAcknowledgement message if any subsequent messages for the Sequence are received. 10.4.2. Basic SyntaxThe WS-Reliable Messaging specification defines four SOAP header elements: Sequence, SequenceFault, SequenceAcknowledgement, and AckRequested. In addition, a companion specification, WS-RM Policy Assertion, defines a set of domain-specific policy assertions, to be used in context of WS-Policy and WS-Policy Attachments for purposes of specifying the quality of service details related to a Sequence. The sections that follow explore each of the syntax elements in detail. 10.4.3. Sequence ElementThe core element of the WS-Reliable Messaging protocol is the Sequence element. Each message within a Sequence between sending and receiving endpoints must include a Sequence SOAP header element. The following is an example of a SOAP message containing a Sequence header that initiates a new Sequence and establishes the initial expiration date for the Sequence: <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/08/addressing" xmlns:wsrm="http://schemas.xmlsoap.org/ws/2005/02/rm"> <soap:Header> <rm:Sequence> <rm:Identifier> 20030818-11010001-0500@example.com </rm:Identifier> <rm:MessageNumber>1</rm:MessageNumber> </rm:Sequence> </soap:Header> <soap:Body> ... </soap:Body> </soap:Envelope> The Sequence element has three child elements: Identifier, MessageNumber, and LastMessage. The Identifier and MessageNumber elements must be present in each Sequence element. The Identifier element is the unique identifier of the Sequence. The same value must be present on each message in a Sequence. The MessageNumber element carries a positive integer that represents the message's position within a Sequence. The LastMessage element is included only on the last message in a Sequence. It signals to the receiving endpoint that this message is the last in the Sequence. In addition, you can extend the Sequence element so that it can carry additional attributes and elements from foreign namespaces. This allows the Sequence element to be composed in several ways, some of which the authors of the WS-Reliable Messaging specification might not have anticipated. A Sequence can be short-lived or long-running. It can have as few as one message or as many as 18,446,744,073,709,551,615 messages. Therefore, you can leverage the protocol for a wide variety of use cases. Partners who exchange relatively few messages at infrequent intervals might choose to establish a new Sequence for each burst of activity, whereas partners who have long-term relationships with frequent exchanges of messages might choose to do so under the context of a single Sequence. In either case, the protocol is always the same. A Sequence can apply to all of the messages traveling in a particular direction (for example, from sender to receiver) in a portType/interface, to messages traveling in a particular direction within selected operations in a portType/interface, or to particular input or output messages traveling in a particular direction. Technically, a Sequence can apply to all traffic traveling in a particular direction between two endpoints, regardless of whether they have been described as a single portType/interface. 10.4.4. SequenceAcknowledgement ElementMessages within a Sequence are acknowledged by a receiving endpoint by means of the SequenceAcknowledgement SOAP header element. As previously mentioned, the SequenceAcknowledgement SOAP header element contains acknowledgement information about all of the messages in a Sequence. It does this by means of a set of one or more child AcknowledgementRange elements, each of which carries an upper and lower bound of contiguous messages that have been received within a Sequence. Technically, the correctness of the protocol can be accomplished by virtue of the receiving endpoint sending just one acknowledgement message with a SequenceAcknowledgement element in response to the receipt of a message that has a Sequence element with the LastMessage element present. Of course, waiting until all the messages within a Sequence have been received before sending an acknowledgement message might be impractical in many, if not most, circumstances. As you will soon see in the section titled "10.4.8 Policy Assertions," a receiving endpoint is typically configured with a maximum interval between acknowledgement messages using the AcknowledgementInterval policy assertion. A sending endpoint then expects to receive an acknowledgement message within the specified AcknowledgmentInterval after transmitting a message. Failure to receive a SequenceAcknowledgement message within the specified time interval might indicate a problem at the receiving endpoint and result in a retransmission attempt for any unacknowledged messages. The following is an example of a SequenceAcknowledgement element that acknowledges receipt of messages 1 through 10. <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" xmlns:wsrm="http://schemas.xmlsoap.org/ws/2005/02/rm"> <soap:Header> ... <rm:SequenceAcknowledgment> <rm:Identifier> 20030818-11010001-0500@example.com </rm:Identifier> <rm:AcknowledgmentRange Upper="10" Lower="1"/> </rm:SequenceAcknowledgment> </soap:Header> <soap:Body> ... </soap:Body> </soap:Envelope> Next is an example of a SOAP message that contains a SequenceAcknowledgement SOAP header element. This element indicates that it has not received the third message in a Sequence that has five messages (as perceived from the receiving endpoint's perspective). Note that the SequenceAcknowledgement element has two AcknowledgementRange child elements: one that acknowledges receipt of messages 1 and 2, and a second that acknowledges receipt of messages 4 and 5. <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" xmlns:wsrm="http://schemas.xmlsoap.org/ws/2005/02/rm"> <soap:Header> <rm:SequenceAcknowledgment> <rm:Identifier> 20030818-11010001-0500@example.com </rm:Identifier> <rm:AcknowledgmentRange Upper="2" Lower="1"/> <rm:AcknowledgmentRange Upper="5" Lower="4"/> </rm:SequenceAcknowledgment> </soap:Header> <soap:Body> ... </soap:Body> </soap:Envelope> The sending endpoint that received such a SequenceAcknowledgement would determine that message 3 needed to be retransmitted until the sending endpoint received a message carrying a SequenceAcknowledgement SOAP header element indicating that the receiving endpoint had, in fact, received message 3. <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" xmlns:wsrm="http://schemas.xmlsoap.org/ws/2005/02/rm"> <soap:Header> ... <rm:SequenceAcknowledgment> <rm:Identifier>20030818-11010001- 0500@example.com</rm:Identifier> <rm:AcknowledgmentRange Upper="5" Lower="1"/> </rm:SequenceAcknowledgment> </soap:Header> <soap:Body> ... </soap:Body> </soap:Envelope> 10.4.5. AckRequested ElementThe third SOAP header element defined by the WS-Reliable Messaging specification is the AckRequested element. A sending endpoint might include an AckRequested SOAP header element in a message as a means of asking the receiving endpoint to send an acknowledgement message immediately instead of waiting for the acknowledgement interval to expire. The following SOAP message is an example of use of the AckRequested element. <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" xmlns:wsa="http://schemas.xmlsoap.org/ws/2003/03/addressing" xmlns:wsrm="http://schemas.xmlsoap.org/ws/2005/02/rm" xmlns:wsu="http://schemas.xmlsoap.org/ws/2002/07/utility"> <soap:Header> ... <rm:Sequence> <rm:Identifier>20030818-11010001- 0500@example.com</rm:Identifier> <rm:MessageNumber>1</rm:MessageNumber> </rm:Sequence> <rm:AckRequested/> </soap:Header> <soap:Body> ... </soap:Body> </soap:Envelope> 10.4.6. SequenceFault ElementThe fourth and final SOAP header element defined in the WS-Reliable Messaging specification is SequenceFault. It carries fault detail information related to the processing of the Sequence, SequenceAcknowledgement, and AckRequested SOAP header elements. The fault information is carried as a SOAP header element because faults that are related to the processing of SOAP header elements must also be conveyed as SOAP header elements per the SOAP specification(s). The SequenceFault element has two required child elements: Identifier, to identify the Sequence to which the fault applies, and FaultCode, to carry the qualified name (QName) of one of the fault codes defined in the WS-Reliable Messaging specification. It might also have one or more AcknowledgementRange child elements if the fault was generated in response to processing a SequenceAcknowledgement. In addition, the specification provides for extensibility of the SequenceFault element by means of an XML Schema wildcard element. The following is an example of a SOAP message carrying a SequenceFault SOAP header element. It indicates that the Sequence has been refused because of insufficient resources at the RM Destination to allocate a new Sequence. <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" xmlns:wsrm="http://schemas.xmlsoap.org/ws/2005/02/rm" xmlns:wsu="http://schemas.xmlsoap.org/ws/2002/07/utility"> <soap:Header> <rm:SequenceFault> <rm:FaultCode>rm:SequenceRefused</rm:FaultCode> </rm:SequenceFault> </soap:Header> <soap:Body> <soap:Fault> <faultcode>soap:Server</faultcode> <faultstring> insufficient resources for new Sequence. </faultstring> </soap:Fault> </soap:Body> </soap:Envelope> 10.4.7. Delivery Semantics SupportedThe WS-Reliable Messaging protocol is an At-Least-Once protocol. That means that each message will be delivered to the RM Destination at least once in the correct operation of the protocol. This base enables the RM Destination to offer the full spectrum of delivery assurances to the Application Destination, ranging from At-Most-Once to At-Least-Once and Exactly-Once to Ordered. For instance, the RM Destination could maintain a limited buffer for messages received and discard duplicates and the oldest undelivered messages in the buffer as new messages are received within a Sequence after the buffer size is exceeded. That would provide At-Most-Once delivery semantics to the Application Destination. Alternatively, the RM Destination could be implemented such that it did not check for and discard duplicate messages, thus providing At-Least-Once delivery semantics to the Application Destination. The RM Destination could apply Exactly-Once delivery semantics by applying duplicate detection to the At-Least-Once semantics. The RM Destination could provide "Ordered" delivery semantics by ensuring that it buffered those messages that have gaps in the Sequence until messages are received that fill those gaps before delivering the messages to the Application Destination. Ultimately, it is the RM Destination's responsibility to fulfill the delivery assurance requirements of the Application Destination. This simplifies the protocol and increases the potential for interoperability. 10.4.8. Policy AssertionsThe companion WS-RM Policy Assertion specification defines a policy assertion that is intended for use in the context of WS-Policy and WS-Policy Attachments. The policy assertion is aimed at enabling endpoints that participate in the WS-Reliable Messaging protocol either to specify their requirements or to indicate the protocol's observed behavior to a prospective partner. 10.4.9. Inactivity TimeoutThis assertion property specifies (in milliseconds) a period of inactivity for a Sequence. If during this duration an endpoint has received no application or control messages, the endpoint MAY consider the Sequence to have been terminated due to inactivity. <rm:InactivityTimeout Milliseconds="86400000"/> 10.4.10. Retransmission IntervalA ReliableMessaging source may optionally specify a base retransmission interval for a sequence. If no acknowledgement has been received for a given message within that interval, the source will retransmit the message. The retransmission interval may be modified at the discretion of the source during the lifetime of the sequence. This assertion property does not alter the formulation of messages as transmitted, only the timing of their transmission. The sequence may optionally specify that the interval will be adjusted using the commonly known exponential backoff algorithm. <rm:BaseRetransmissionInterval Milliseconds="3000"/> <rm:ExponentialBackoff/> 10.4.11. Acknowledgement IntervalAcknowledgements can be sent on return messages or sent stand alone. In the case where a return message is not available with which to send an acknowledgement, a ReliableMessaging Destination may wait for the duration of the acknowledgement interval before sending a stand alone acknowledgement. If there are no unacknowledged messages, the ReliableMessaging Destination may choose not to send an acknowledgement. This assertion property does not alter the formulation of messages or acknowledgements as transmitted. Its purpose is to communicate the timing of acknowledgements so that the source may be tuned appropriately. It does not alter the meaning of the <AckRequested> directive. <rm:AcknowledgementInterval Milliseconds="1000"/> 10.4.12. Basic WS-Reliable Messaging ProfileGiven that the policy assertion properties that comprise timing considerations can be arranged into any number of possible combinations, the authors of the WS-Reliable Messaging specification have defined a base timing profile that is intended to help promote interoperability. The specifics of this profile are as follows: <wsp:Policy> <rm:RMAssertion> <rm:BaseRetransmissionInterval Milliseconds="3000"/> <rm:ExponentialBackoff/> <rm:InactivityTimeout Milliseconds="86400000"/> <rm:AcknowledgementInterval Milliseconds="1000"/> </rm:RMAssertion> </wsp:Policy> The authors have assigned this profile the following URI designation: http://schemas.xmlsoap.org/ws/2005/02/rm/baseTimingProfile.xml Therefore, you can reference it using a WS-Policy Attachment PolicyReference. |
|
![Web Services Platform Architecture(c) SOAP, WSDL, WS-Policy, WS-Addressing, WS-BP[. .. ] More](/icons/blank_book.jpg "Web Services Platform Architecture(c) SOAP, WSDL, WS-Policy, WS-Addressing, WS-BP[. .. ] More"){kind=icon}
EAN: N/A
Pages: 176