Version 1.1 - docs oasis open - Oasis

docs.oasis.open.org

Version 1.1 - docs oasis open - Oasis

123456789101112131415161718192021222324252627282930313233343536373839Web Services Reliable Messaging (WS-ReliableMessaging) Version 1.1Committee Draft 0829 March 2007Specification URIs:This Version:http://docs.oasis-open.org/ws-rx/wsrm/200702/wsrm-1.1-spec-cd-08.pdfhttp://docs.oasis-open.org/ws-rx/wsrm/200702/wsrm-1.1-spec-cd-08.htmlhttp://docs.oasis-open.org/ws-rx/wsrm/200702/wsrm-1.1-spec-cd-08.docPrevious Version:http://docs.oasis-open.org/ws-rx/wsrm/200702/wsrm-1.1-spec-cd-07.pdfhttp://docs.oasis-open.org/ws-rx/wsrm/200702/wsrm-1.1-spec-cd-07.htmlhttp://docs.oasis-open.org/ws-rx/wsrm/200702/wsrm-1.1-spec-cd-07.docLatest Version:http://docs.oasis-open.org/ws-rx/wsrm/v1.1/wsrm.pdfhttp://docs.oasis-open.org/ws-rx/wsrm/v1.1/wsrm.htmlhttp://docs.oasis-open.org/ws-rx/wsrm/v1.1/wsrm.docTechnical Committee:OASIS Web Services Reliable Exchange (WS-RX) TCChairs:Paul Fremantle Sanjay Patil Editors:Doug Davis, IBM Anish Karmarkar, Oracle Gilbert Pilz, BEA Steve Winkler, SAP Ümit Yalçinalp, SAP Related Work:This specification replaces or supercedes: WS-ReliableMessaging v1.0Declared XML Namespaces:http://docs.oasis-open.org/ws-rx/wsrm/200702Abstract:This specification (WS-ReliableMessaging) describes a protocol that allows messages to betransferred reliably between nodes implementing this protocol in the presence of softwarecomponent, system, or network failures. The protocol is described in this specification in atransport-independent manner allowing it to be implemented using different network technologies.To support interoperable Web services, a SOAP binding is defined within this specification.wsrm-1.1-spec-cd-08 29 March 2007Copyright © OASIS® 1993–2007. All Rights Reserved. OASIS trademark, IPR and other policies apply. Page 1 of 62


404142434445464748495051525354555657585960616263The protocol defined in this specification depends upon other Web services specifications for theidentification of service endpoint addresses and policies. How these are identified and retrievedare detailed within those specifications and are out of scope for this document.By using the XML [XML], SOAP [SOAP 1.1], [SOAP 1.2] and WSDL [WSDL 1.1] extensibilitymodel, SOAP-based and WSDL-based specifications are designed to be composed with eachother to define a rich Web services environment. As such, WS-ReliableMessaging by itself doesnot define all the features required for a complete messaging solution. WS-ReliableMessaging isa building block that is used in conjunction with other specifications and application-specificprotocols to accommodate a wide variety of requirements and scenarios related to the operationof distributed Web services.Status:This document was last revised or approved by the WS-RX Technical Committee on the abovedate. The level of approval is also listed above. Check the "Latest Version" or "Latest ApprovedVersion" location noted above for possible later revisions of this document.Technical Committee members should send comments on this specification to the TechnicalCommittee's email list. Others should send comments to the Technical Committee by using the"Send A Comment" button on the Technical Committee's web page at http://www.oasisopen.org/committees/ws-rx/.For information on whether any patents have been disclosed that may be essential toimplementing this specification, and any offers of patent licensing terms, please refer to theIntellectual Property Rights section of the Technical Committee web page (http://www.oasisopen.org/committees/ws-rx/ipr.php).The non-normative errata page for this specification is located at http://www.oasisopen.org/committees/ws-rx/.wsrm-1.1-spec-cd-08 29 March 2007Copyright © OASIS® 1993–2007. All Rights Reserved. OASIS trademark, IPR and other policies apply. Page 2 of 62


646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108NoticesCopyright © OASIS® 1993–2007. All Rights Reserved. OASIS trademark, IPR and other policies apply.All capitalized terms in the following text have the meanings assigned to them in the OASIS IntellectualProperty Rights Policy (the "OASIS IPR Policy"). The full Policy may be found at the OASIS website.This document and translations of it may be copied and furnished to others, and derivative works thatcomment on or otherwise explain it or assist in its implementation may be prepared, copied, published,and distributed, in whole or in part, without restriction of any kind, provided that the above copyright noticeand this section are included on all such copies and derivative works. However, this document itself maynot be modified in any way, including by removing the copyright notice or references to OASIS, except asneeded for the purpose of developing any document or deliverable produced by an OASIS TechnicalCommittee (in which case the rules applicable to copyrights, as set forth in the OASIS IPR Policy, must befollowed) or as required to translate it into languages other than English.The limited permissions granted above are perpetual and will not be revoked by OASIS or its successorsor assigns.This document and the information contained herein is provided on an "AS IS" basis and OASISDISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANYWARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANYOWNERSHIP RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR APARTICULAR PURPOSE.OASIS requests that any OASIS Party or any other party that believes it has patent claims that wouldnecessarily be infringed by implementations of this OASIS Committee Specification or OASIS Standard, tonotify OASIS TC Administrator and provide an indication of its willingness to grant patent licenses to suchpatent claims in a manner consistent with the IPR Mode of the OASIS Technical Committee that producedthis specification.OASIS invites any party to contact the OASIS TC Administrator if it is aware of a claim of ownership of anypatent claims that would necessarily be infringed by implementations of this specification by a patentholder that is not willing to provide a license to such patent claims in a manner consistent with the IPRMode of the OASIS Technical Committee that produced this specification. OASIS may include such claimson its website, but disclaims any obligation to do so.OASIS takes no position regarding the validity or scope of any intellectual property or other rights thatmight be claimed to pertain to the implementation or use of the technology described in this document orthe extent to which any license under such rights might or might not be available; neither does it representthat it has made any effort to identify any such rights. Information on OASIS' procedures with respect torights in any document or deliverable produced by an OASIS Technical Committee can be found on theOASIS website. Copies of claims of rights made available for publication and any assurances of licensesto be made available, or the result of an attempt made to obtain a general license or permission for theuse of such proprietary rights by implementers or users of this OASIS Committee Specification or OASISStandard, can be obtained from the OASIS TC Administrator. OASIS makes no representation that anyinformation or list of intellectual property rights will at any time be complete, or that any claims in such listare, in fact, Essential Claims.The name "OASIS", WS-ReliableMessaging, WSRM and WS-RX are trademarks of OASIS, the ownerand developer of this specification, and should be used only to refer to the organization and its officialoutputs. OASIS welcomes reference to, and implementation and use of, specifications, while reserving theright to enforce its marks against misleading uses. Please see http://www.oasisopen.org/who/trademark.phpfor above guidance.wsrm-1.1-spec-cd-08 29 March 2007Copyright © OASIS® 1993–2007. All Rights Reserved. OASIS trademark, IPR and other policies apply. Page 3 of 62


109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144Table of Contents1 Introduction ...................................................................................................................................... 61.1 Terminology ................................................................................................................................... 61.2 Normative References .................................................................................................................... 71.3 Non-Normative References............................................................................................................. 71.4 Namespace .................................................................................................................................... 81.5 Conformance .................................................................................................................................. 92 Reliable Messaging Model ............................................................................................................. 102.1 Glossary ....................................................................................................................................... 112.2 Protocol Preconditions .................................................................................................................. 122.3 Protocol Invariants ........................................................................................................................ 122.4 Delivery Assurances ..................................................................................................................... 122.5 Example Message Exchange ........................................................................................................ 133 RM Protocol Elements .................................................................................................................... 163.1 Considerations on the Use of Extensibility Points .......................................................................... 163.2 Considerations on the Use of "Piggy-Backing" .............................................................................. 163.3 Composition with WS-Addressing ................................................................................................. 163.4 Sequence Creation ....................................................................................................................... 173.5 Closing A Sequence ..................................................................................................................... 213.6 Sequence Termination .................................................................................................................. 233.7 Sequences ................................................................................................................................... 253.8 Request Acknowledgement .......................................................................................................... 263.9 Sequence Acknowledgement ........................................................................................................ 274 Faults ............................................................................................................................................. 304.1 SequenceFault Element................................................................................................................ 314.2 Sequence Terminated .................................................................................................................. 324.3 Unknown Sequence...................................................................................................................... 324.4 Invalid Acknowledgement ............................................................................................................. 334.5 Message Number Rollover ........................................................................................................... 334.6 Create Sequence Refused ............................................................................................................ 344.7 Sequence Closed ......................................................................................................................... 344.8 WSRM Required........................................................................................................................... 355 Security Threats and Countermeasures .......................................................................................... 365.1 Threats and Countermeasures ..................................................................................................... 365.2 Security Solutions and Technologies ............................................................................................ 386 Securing Sequences ...................................................................................................................... 41wsrm-1.1-spec-cd-08 29 March 2007Copyright © OASIS® 1993–2007. All Rights Reserved. OASIS trademark, IPR and other policies apply. Page 4 of 62


1451461471481491501511521531541551561576.1 Securing Sequences Using WS-Security ...................................................................................... 416.2 Securing Sequences Using SSL/TLS ............................................................................................ 42Appendix A. Schema .............................................................................................................................. 44Appendix B. WSDL ................................................................................................................................. 49Appendix C. Message Examples ............................................................................................................ 51Appendix C.1 Create Sequence.......................................................................................................... 51Appendix C.2 Initial Transmission ....................................................................................................... 51Appendix C.3 First Acknowledgement ................................................................................................ 53Appendix C.4 Retransmission ............................................................................................................. 53Appendix C.5 Termination .................................................................................................................. 54Appendix D. State Tables ....................................................................................................................... 56Appendix E. Acknowledgments ............................................................................................................... 61wsrm-1.1-spec-cd-08 29 March 2007Copyright © OASIS® 1993–2007. All Rights Reserved. OASIS trademark, IPR and other policies apply. Page 5 of 62


1581591601611621631641651661671681691701711721 IntroductionIt is often a requirement for two Web services that wish to communicate to do so reliably in the presenceof software component, system, or network failures. The primary goal of this specification is to create amodular mechanism for reliable transfer of messages. It defines a messaging protocol to identify, track,and manage the reliable transfer of messages between a source and a destination. It also defines aSOAP binding that is required for interoperability. Additional bindings can be defined.This mechanism is extensible allowing additional functionality, such as security, to be tightly integrated.This specification integrates with and complements the WS-Security [WS-Security], WS-Policy [WS-Policy], and other Web services specifications. Combined, these allow for a broad range of reliable,secure messaging options.1.1 TerminologyThe keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULDNOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as describedin RFC 2119 [KEYWORDS].This specification uses the following syntax to define normative outlines for messages:173174175176177178179180181182183184185The syntax appears as an XML instance, but values in italics indicate data types instead ofvalues.Characters are appended to elements and attributes to indicate cardinality:o "?" (0 or 1)o "*" (0 or more)o "+" (1 or more)The character "|" is used to indicate a choice between alternatives.The characters "[" and "]" are used to indicate that contained items are to be treated as a groupwith respect to cardinality or choice.An ellipsis (i.e. "...") indicates a point of extensibility that allows other child or attribute contentspecified in this document. Additional children elements and/or attributes MAY be added at theindicated extension points but they MUST NOT contradict the semantics of the parent and/orowner, respectively. If an extension is not recognized it SHOULD be ignored.186187188189190 XML namespace prefixes (see section 1.4) are used to indicate the namespace of the elementbeing defined.Elements and Attributes defined by this specification are referred to in the text of this document usingXPath 1.0 [XPath_10] expressions. Extensibility points are referred to using an extended version of thissyntax:191192193194195196An element extensibility point is referred to using {any} in place of the element name. Thisindicates that any element name can be used, from any namespace other than the wsrm:namespace.An attribute extensibility point is referred to using @{any} in place of the attribute name. Thisindicates that any attribute name can be used, from any namespace other than the wsrm:namespace.wsrm-1.1-spec-cd-08 29 March 2007Copyright © OASIS® 1993–2007. All Rights Reserved. OASIS trademark, IPR and other policies apply. Page 6 of 62


1971981992002012022032042052062072082092102112122132142152162172182192202212222232242252262272282292302312322332342352362372382392402412422432441.2 Normative References[KEYWORDS] S. Bradner, “Key words for use in RFCs to Indicate Requirement Levels,” RFC2119, Harvard University, March 1997http://www.ietf.org/rfc/rfc2119.txt[WS-RM Policy] OASIS WS-RX Technical Committee Draft, "Web Services Reliable MessagingPolicy Assertion( WS-RM Policy)," March 2007http://docs.oasis-open.org/ws-rx/wsrmp/v1.1/wsrmp.pdf[SOAP 1.1] W3C Note, "SOAP: Simple Object Access Protocol 1.1," 08 May 2000.http://www.w3.org/TR/2000/NOTE-SOAP-20000508/[SOAP 1.2] W3C Recommendation, "SOAP Version 1.2 Part 1: Messaging Framework" June2003.http://www.w3.org/TR/2003/REC-soap12-part1-20030624/[URI]T. Berners-Lee, R. Fielding, L. Masinter, "Uniform Resource Identifiers (URI):Generic Syntax," RFC 3986, MIT/LCS, U.C. Irvine, Xerox Corporation, January2005.http://ietf.org/rfc/rfc3986[UUID]P. Leach, M. Mealling, R. Salz, "A Universally Unique IDentifier (UUID) URNNamespace," RFC 4122, Microsoft, Refactored Networks - LLC, DataPowerTechnology Inc, July 2005http://www.ietf.org/rfc/rfc4122.txt[XML]W3C Recommendation, "Extensible Markup Language (XML) 1.0 (FourthEdition)", September 2006.http://www.w3.org/TR/REC-xml/[XML-ns] W3C Recommendation, "Namespaces in XML," 14 January 1999.http://www.w3.org/TR/1999/REC-xml-names-19990114/[XML-Schema Part1] W3C Recommendation, "XML Schema Part 1: Structures," October 2004.http://www.w3.org/TR/xmlschema-1/[XML-Schema Part2] W3C Recommendation, "XML Schema Part 2: Datatypes," October 2004.http://www.w3.org/TR/xmlschema-2/[XPATH 1.0] W3C Recommendation, "XML Path Language (XPath) Version 1.0," 16November 1999.http://www.w3.org/TR/xpath[WSDL 1.1] W3C Note, "Web Services Description Language (WSDL 1.1)," 15 March 2001.http://www.w3.org/TR/2001/NOTE-wsdl-20010315[WS-Addressing] W3C Recommendation, “Web Services Addressing 1.0 – Core,” May 2006.http://www.w3.org/TR/2006/REC-ws-addr-core-20060509/W3C Recommendation, “Web Services Addressing 1.0 – SOAP Binding,” May2006http://www.w3.org/TR/2006/REC-ws-addr-soap-20060509/1.3 Non-Normative References[BSP 1.0] WS-I Working Group Draft. "Basic Security Profile Version 1.0," August 2006http://www.ws-i.org/Profiles/BasicSecurityProfile-1.0.html[RDDL 2.0] Jonathan Borden, Tim Bray, eds. “Resource Directory Description Language(RDDL) 2.0,” January 2004http://www.openhealth.org/RDDL/20040118/rddl-20040118.html[RFC 2617] J. Franks, P. Hallam-Baker, J. Hostetler, S. Lawrence, P. Leach, A. Loutonen, L.Stewart, "HTTP Authentication: Basic and Digest Access Authentication," Junewsrm-1.1-spec-cd-08 29 March 2007Copyright © OASIS® 1993–2007. All Rights Reserved. OASIS trademark, IPR and other policies apply. Page 7 of 62


2452462472482492502512522532542552562572582592602612622632642652662672682692702712722732742752762772782792802812822832842852862872882892902911999.http://www.ietf.org/rfc/rfc2617.txt[RFC 4346] T. Dierks, E. Rescorla, "The Transport Layer Security (TLS) Protocol Version1.1," April 2006.http://www.ietf.org/rfc/rfc4346.txt[WS-Policy] W3C Member Submission "Web Services Policy 1.2 - Framework", April 2006http://www.w3.org/Submission/2006/SUBM-WS-Policy-20060425/W3C Candidate Recommendation, "Web Services Policy 1.5 - Framework,"February 2007.http://www.w3.org/TR/2007/CR-ws-policy-20070228[WS-PolicyAttachment] W3C Member Submission "Web Services Policy 1.2 - Attachment", April2006http://www.w3.org/Submission/2006/SUBM-WS-PolicyAttachment-20060425/W3C Candidate Recommendation, "Web Services Policy 1.5 - Attachment,"February 2007.http://www.w3.org/TR/2007/CR-ws-policy-attach-20070228[WS-Security] Anthony Nadalin, Chris Kaler, Phillip Hallam-Baker, Ronald Monzillo, eds. "OASISWeb Services Security: SOAP Message Security 1.0 (WS-Security 2004)",OASIS Standard 200401, March 2004.http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-messagesecurity-1.0.pdfAnthony Nadalin, Chris Kaler, Phillip Hallam-Baker, Ronald Monzillo, eds. "OASISWeb Services Se-curity: SOAP Message Security 1.1 (WS-Security 2004)",OASIS Standard 200602, February 2006.http://docs.oasis-open.org/wss/v1.1/wss-v1.1-spec-os-SOAPMessageSecurity.pdf[RTTM]V. Jacobson, R. Braden, D. Borman, "TCP Extensions for High Performance",RFC 1323, May 1992.http://www.rfc-editor.org/rfc/rfc1323.txt[SecurityPolicy] G. Della-Libra, et. al. "Web Services Security Policy Language (WS-SecurityPolicy)", July 2005http://specs.xmlsoap.org/ws/2005/07/securitypolicy/ws-securitypolicy.pdf[SecureConversation] S. Anderson, et al, "Web Services Secure Conversation Language (WS-SecureConversation)," February 2005.http://schemas.xmlsoap.org/ws/2004/04/sc/[Trust] S. Anderson, et al, "Web Services Trust Language (WS-Trust)," February 2005.http://schemas.xmlsoap.org/ws/2005/02/trust1.4 NamespaceThe XML namespace [XML-ns] URI that MUST be used by implementations of this specification is:http://docs.oasis-open.org/ws-rx/wsrm/200702Dereferencing the above URI will produce the Resource Directory Description Language [RDDL 2.0]document that describes this namespace.Table 1 lists the XML namespaces that are used in this specification. The choice of any namespace prefixis arbitrary and not semantically significant.Table 1PrefixNamespacewsrm-1.1-spec-cd-08 29 March 2007Copyright © OASIS® 1993–2007. All Rights Reserved. OASIS trademark, IPR and other policies apply. Page 8 of 62


292293294295296297298299300301S (Either SOAP 1.1 or 1.2)S11 http://schemas.xmlsoap.org/soap/envelope/S12 http://www.w3.org/2003/05/soap-envelopewsrm http://docs.oasis-open.org/ws-rx/wsrm/200702wsa http://www.w3.org/2005/08/addressingwsam http://www.w3.org/2007/02/addressing/metadatawsse http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsdxs http://www.w3.org/2001/XMLSchemaThe normative schema for WS-ReliableMessaging can be found linked from the namespace documentthat is located at the namespace URI specified above.All sections explicitly noted as examples are informational and are not to be considered normative.1.5 ConformanceAn implementation is not conformant with this specification if it fails to satisfy one or more of the MUST orREQUIRED level requirements defined herein. A SOAP Node MUST NOT use the XML namespaceidentifier for this specification (listed in section 1.4) within SOAP Envelopes unless it is conformant withthis specification.Normative text within this specification takes precedence over normative outlines, which in turn takeprecedence over the XML Schema [XML Schema Part 1, Part 2] descriptions.wsrm-1.1-spec-cd-08 29 March 2007Copyright © OASIS® 1993–2007. All Rights Reserved. OASIS trademark, IPR and other policies apply. Page 9 of 62


Initial SenderUltimate ReceiverApplicationSourceApplicationDestinationSendDeliverRM SourceTransmitAcknowledgeRM DestinationReceiveScope of RM Protocol328Figure 1: Reliable Messaging Model3293303313323333343353363373383393403413423433443453463473483493503513522.1 GlossaryThe following definitions are used throughout this specification:Accept: The act of qualifying a message by the RM Destination such that it becomes eligible for Deliveryand acknowledgement.Acknowledgement: The communication from the RM Destination to the RM Source indicating thesuccessful receipt of a message.Acknowledgement Message: A message containing a SequenceAcknowledgement header block.Acknowledgement Messages may or may not contain a SOAP body.Acknowledgement Request: A message containing an AckRequested header. AcknowledgementRequests may or may not contain a SOAP body.Application Destination: The Endpoint to which a message is Delivered.Application Source: The Endpoint that Sends a message.Back-channel: When the underlying transport provides a mechanism to return a transport-protocolspecific response, capable of carrying a SOAP message, without initiating a new connection, thisspecification refers to this mechanism as a back-channel.Deliver: The act of transferring responsibility for a message from the RM Destination to the ApplicationDestination.Endpoint: As defined in the WS-Addressing specification [WS-Addressing]; a Web service Endpoint is a(referenceable) entity, processor, or resource to which Web service messages can be addressed.Endpoint references (EPRs) convey the information needed to address a Web service Endpoint.Receive: The act of reading a message from a network connection and accepting it.RM Destination: The Endpoint that Receives messages Transmitted reliably from an RM Source.RM Protocol Header Block: One of Sequence, SequenceAcknowledgement, or AckRequested.RM Source: The Endpoint that Transmits messages reliably to an RM Destination.wsrm-1.1-spec-cd-08 29 March 2007Copyright © OASIS® 1993–2007. All Rights Reserved. OASIS trademark, IPR and other policies apply. Page 11 of 62


353354355356357358359360361362Send: The act of transferring a message from the Application Source to the RM Source for reliabletransfer.Sequence Lifecycle Message: A message that contains one of: CreateSequence,CreateSequenceResponse, CloseSequence, CloseSequenceResponse, TerminateSequence,TerminateSequenceResponse as the child element of the SOAP body element.Sequence Traffic Message: A message containing a Sequence header block.Transmit: The act of writing a message to a network connection.2.2 Protocol PreconditionsThe correct operation of the protocol requires that a number of preconditions MUST be established prior tothe processing of the initial sequenced message:363364365366367368369For any single message exchange the RM Source MUST have an endpoint reference thatuniquely identifies the RM Destination Endpoint.The RM Source MUST have successfully created a Sequence with the RM Destination.The RM Source MUST be capable of formulating messages that adhere to the RM Destination'spolicies.If a secure exchange of messages is REQUIRED, then the RM Source and RM Destination MUSThave a security context.3703712.3 Protocol InvariantsDuring the lifetime of a Sequence, the following invariants are REQUIRED for correctness:372373374375376377378379380381382383The RM Source MUST assign each message within a Sequence a message number (definedbelow) beginning at 1 and increasing by exactly 1 for each subsequent message. These numbersMUST be assigned in the same order in which messages are sent by the Application Source.Within every Acknowledgement Message it issues, the RM Destination MUST include one ormore AcknowledgementRange child elements that contain, in their collective ranges, themessage number of every message accepted by the RM Destination. The RM Destination MUSTexclude, in the AcknowledgementRange elements, the message numbers of any messages ithas not accepted. If no messages have been received the RM Destination MUST return Noneinstead of an AcknowledgementRange(s). The RM Destination MAY transmit a Nack for aspecific message or messages instead of an AcknowledgementRange(s).While the Sequence is not closed or terminated, the RM Source SHOULD retransmitunacknowledged messages.3843853863873883893903912.4 Delivery AssurancesThis section defines a number of Delivery Assurance assertions, which can be supported by RM Sourcesand RM Destinations. These assertions can be specified as policy assertions using the WS-Policyframework [WS-Policy]. For details on this see the WSRM Policy specification [WS-RM Policy].AtLeastOnceEach message is to be delivered at least once, or else an error MUST be raised by the RMSource and/or RM Destination. The requirement on an RM Source is that it SHOULD retrytransmission of every message sent by the Application Source until it receives anwsrm-1.1-spec-cd-08 29 March 2007Copyright © OASIS® 1993–2007. All Rights Reserved. OASIS trademark, IPR and other policies apply. Page 12 of 62


392393394395396397398399400401402403404405406407408409410411412413414415416417418419420421422acknowledgement from the RM Destination. The requirement on the RM Destination is that itSHOULD retry the transfer to the Application Destination of any message that it accepts from theRM Source, until that message has been successfully delivered. There is no requirement for theRM Destination to apply duplicate message filtering.AtMostOnceEach message is to be delivered at most once. The RM Source MAY retry transmission ofunacknowledged messages, but is NOT REQUIRED to do so. The requirement on the RMDestination is that it MUST filter out duplicate messages, i.e. that it MUST NOT deliver a duplicateof a message that has already been delivered.ExactlyOnceEach message is to be delivered exactly once; if a message cannot be delivered then an errorMUST be raised by the RM Source and/or RM Destination. The requirement on an RM Source isthat it SHOULD retry transmission of every message sent by the Application Source until itreceives an acknowledgement from the RM Destination. The requirement on the RM Destinationis that it SHOULD retry the transfer to the Application Destination of any message that it acceptsfrom the RM Source until that message has been successfully delivered, and that it MUST NOTdeliver a duplicate of a message that has already been delivered.InOrderMessages from each individual sequence are to be delivered in the same order they have beensent by the Application Source. The requirement on an RM Source is that it MUST ensure that theordinal position of each message in the sequence (as indicated by a message sequence number)is consistent with the order in which the messages have been sent from the Application Source.The requirement on the RM Destination is that it MUST deliver received messages for eachsequence in the order indicated by the message numbering. This DeliveryAssurance can be usedin combination with any of the AtLeastOnce, AtMostOnce or ExactlyOnce assertions, and therequirements of those assertions MUST also be met. In particular if the AtLeastOnce orExactlyOnce assertion applies and the RM Destination detects a gap in the sequence then theRM Destination MUST NOT deliver any subsequent messages from that sequence until themissing messages are received or until the sequence is closed.2.5 Example Message ExchangeFigure 2 illustrates a possible message exchange between two reliable messaging Endpoints A and B.wsrm-1.1-spec-cd-08 29 March 2007Copyright © OASIS® 1993–2007. All Rights Reserved. OASIS trademark, IPR and other policies apply. Page 13 of 62


EndpointAReliable Messaging ProtocolEndpointBEstablish Protocol PreconditionsCreateSequence()CreateSequenceResponse( Identifier=http://fabrikam123.com/abc )Sequence( Identifier = http://fabrikam123.com/abc, MessageNumber = 1 )Sequence( Identifier = http://fabrikam123.com/abc, MessageNumber = 2 )XSequence( Identifier = http://fabrikam123.com/abc, MessageNumber = 3, AckRequested )SequenceAcknowledgement( Identifier = http://fabrikam123.com/abc,AcknowledgementRange = 1,3 )Sequence( Identifier = http://fabrikam123.com/abc,MessageNumber = 2, AckRequested)SequenceAcknowledgement( Identifier = http://fabrikam123.com/abc,AcknowledgementRange = 1...3 )TerminateSequence( Identifier = http://fabrikam123.com/abc )TerminateSequenceResponse( Identifier=http://fabrikam123.com/abc,LastMsgNumber=3 )423424425426427428429430431432433434435436437438439440Figure 2: The WS-ReliableMessaging Protocol1. The protocol preconditions are established. These include policy exchange, endpoint resolution,and establishing trust.2. The RM Source requests creation of a new Sequence.3. The RM Destination creates a new Sequence and returns its unique identifier.4. The RM Source begins Transmitting messages in the Sequence beginning with MessageNumber1. In the figure above, the RM Source sends 3 messages in the Sequence.5. The 2 nd message in the Sequence is lost in transit.6. The 3 rd message is the last in this Sequence and the RM Source includes an AckRequestedheader to ensure that it gets a timely SequenceAcknowledgement for the Sequence.7. The RM Destination acknowledges receipt of message numbers 1 and 3 as a result of receivingthe RM Source's AckRequested header.8. The RM Source retransmits the unacknowledged message with MessageNumber 2. This is a newmessage from the perspective of the underlying transport, but it has the same Sequence Identifierand MessageNumber so the RM Destination can recognize it as a duplicate of the earliermessage, in case the original and retransmitted messages are both Received. The RM Sourceincludes an AckRequested header in the retransmitted message so the RM Destination willexpedite an acknowledgement.wsrm-1.1-spec-cd-08 29 March 2007Copyright © OASIS® 1993–2007. All Rights Reserved. OASIS trademark, IPR and other policies apply. Page 14 of 62


4414424434444454464474484494504514524534544554564574584594604614624639. The RM Destination Receives the second transmission of the message with MessageNumber 2and acknowledges receipt of message numbers 1, 2, and 3.10. The RM Source Receives this Acknowledgement and sends a TerminateSequence message tothe RM Destination indicating that the Sequence is completed. The TerminateSequence messageindicates that message number 3 was the last message in the Sequence. The RM Destinationthen reclaims any resources associated with the Sequence.11. The RM Destination Receives the TerminateSequence message indicating that the RM Sourcewill not be sending any more messages. The RM Destination sends aTerminateSequenceResponse message to the RM Source and reclaims any resourcesassociated with the Sequence.The RM Source will expect to Receive Acknowledgements from the RM Destination during the course of amessage exchange at occasions described in section 3 below. Should an Acknowledgement not beReceived in a timely fashion, the RM Source MUST re-transmit the message since either the message orthe associated Acknowledgement might have been lost. Since the nature and dynamic characteristics ofthe underlying transport and potential intermediaries are unknown in the general case, the timing of retransmissionscannot be specified. Additionally, over-aggressive re-transmissions have beendemonstrated to cause transport or intermediary flooding which are counterproductive to the intention ofproviding a reliable exchange of messages. Consequently, implementers are encouraged to utilizeadaptive mechanisms that dynamically adjust re-transmission time and the back-off intervals that areappropriate to the nature of the transports and intermediaries envisioned. For the case of TCP/IPtransports, a mechanism similar to that described as RTTM in RFC 1323 [RTTM] SHOULD be considered.Now that the basic model has been outlined, the details of the elements used in this protocol are nowprovided in section 3.wsrm-1.1-spec-cd-08 29 March 2007Copyright © OASIS® 1993–2007. All Rights Reserved. OASIS trademark, IPR and other policies apply. Page 15 of 62


4644654664674684694704714724734744754764774784794804814824834844854864874884894904914924934944954964974984993 RM Protocol ElementsThe following sub-sections define the various RM protocol elements, and prescribe their usage by aconformant implementations.3.1 Considerations on the Use of Extensibility PointsThe following protocol elements define extensibility points at various places. Implementations MAY addchild elements and/or attributes at the indicated extension points but MUST NOT contradict the semanticsof the parent and/or owner, respectively. If a receiver does not recognize an extension, the receiverSHOULD ignore the extension.3.2 Considerations on the Use of "Piggy-Backing"Some RM Protocol Header Blocks may be added to messages that are targeted to the same Endpoint towhich those headers are to be sent (a concept often referred to as "piggy-backing"), thus saving theoverhead of an additional message exchange. Reference parameters MUST be considered whendetermining whether two EPRs are targeted to the same Endpoint. The determination of if and when aHeader Block will be piggy-backed onto another message is made by the entity (RM Source or RMDestination) that is sending the header. In order to ensure optimal and successful processing of RMSequences, endpoints that receive RM-related messages SHOULD be prepared to process RM ProtocolHeader Blocks that are included in any message it receives. See the sections that define each RMProtocol Header Block to know which ones may be considered for piggy-backing.3.3 Composition with WS-AddressingWhen the RM protocol, defined in this specification, is composed with the WS-Addressing specification,the following rules prescribe the constraints on the value of the wsa:Action header:1. When an Endpoint generates a message that carries an RM protocol element, that is defined inthe following sections, in the body of a SOAP envelope that Endpoint MUST include in thatenvelope a wsa:Action SOAP header block whose value is an IRI that is a concatenation of theWS-RM namespace URI, followed by a "/", followed by the value of the local name of the childelement of the SOAP body . For example, for a Sequence creation request message as describedin section 3.4 below, the value of the wsa:Action IRI would be:http://docs.oasis-open.org/ws-rx/wsrm/200702/CreateSequence2. When an Endpoint generates an Acknowledgement Message that has no element content in theSOAP body, then the value of the wsa:Action IRI MUST be:http://docs.oasis-open.org/ws-rx/wsrm/200702/SequenceAcknowledgement3. When an Endpoint generates an Acknowledgement Request that has no element content in theSOAP body, then the value of the wsa:Action IRI MUST be:http://docs.oasis-open.org/ws-rx/wsrm/200702/AckRequested4. When an Endpoint generates an RM fault as defined in section 4 below, the value of thewsa:Action IRI MUST be as defined in section 4 below.wsrm-1.1-spec-cd-08 29 March 2007Copyright © OASIS® 1993–2007. All Rights Reserved. OASIS trademark, IPR and other policies apply. Page 16 of 62


5005015025035045055065075085095105115125135145155165175185195205215225235245255265275285295305315325335345355365375385395405415425435445455463.4 Sequence CreationThe RM Source MUST request creation of an outbound Sequence by sending a CreateSequenceelement in the body of a message to the RM Destination which in turn responds either with a messagecontaining CreateSequenceResponse or a CreateSequenceRefused fault. The RM Source MAYinclude an offer to create an inbound Sequence within the CreateSequence message. This offer iseither accepted or rejected by the RM Destination in the CreateSequenceResponse message.The SOAP version used for the CreateSequence message SHOULD be used for all subsequentmessages in or for that Sequence, sent by either the RM Source or the RM Destination.The following exemplar defines the CreateSequence syntax: wsa:EndpointReferenceType xs:duration ? xs:anyURI wsa:EndpointReferenceType xs:duration ?wsrm:IncompleteSequenceBehaviorType ?... ?...The following describes the content model of the CreateSequence element./wsrm:CreateSequenceThis element requests creation of a new Sequence between the RM Source that sends it, and theRM Destination to which it is sent. The RM Source MUST NOT send this element as a headerblock. The RM Destination MUST respond either with a CreateSequenceResponse responsemessage or a CreateSequenceRefused fault./wsrm:CreateSequence/wsrm:AcksToThe RM Source MUST include this element in any CreateSequence message it sends. Thiselement is of type wsa:EndpointReferenceType (as specified by WS-Addressing). It specifiesthe endpoint reference to which messages containing SequenceAcknowledgement headerblocks and faults related to the created Sequence are to be sent, unless otherwise noted in thisspecification (for example, see section 3.5).Implementations MUST NOT use an endpoint reference in the AcksTo element that would preventthe sending of Sequence Acknowledgements back to the RM Source. For example, using the WS-Addressing "http://www.w3.org/2005/08/addressing/none" IRI would make it impossible for the RMDestination to ever send Sequence Acknowledgements./wsrm:CreateSequence/wsrm:ExpiresThis element, if present, of type xs:duration specifies the RM Source's requested duration forthe Sequence. The RM Destination MAY either accept the requested duration or assign a lesservalue of its choosing. A value of "PT0S" indicates that the Sequence will never expire. Absence ofthe element indicates an implied value of "PT0S"./wsrm:CreateSequence/wsrm:Expires/@{any}This is an extensibility mechanism to allow additional attributes, based on schemas, to be addedto the element.wsrm-1.1-spec-cd-08 29 March 2007Copyright © OASIS® 1993–2007. All Rights Reserved. OASIS trademark, IPR and other policies apply. Page 17 of 62


547548549550551552553554555556557558559560561562563564565566567568569570571572573574575576577578579580581582583584585586587588589590/wsrm:CreateSequence/wsrm:OfferThis element, if present, enables an RM Source to offer a corresponding Sequence for the reliableexchange of messages Transmitted from RM Destination to RM Source./wsrm:CreateSequence/wsrm:Offer/wsrm:IdentifierThe RM Source MUST set the value of this element to an absolute URI (conformant withRFC3986 [URI]) that uniquely identifies the offered Sequence./wsrm:CreateSequence/wsrm:Offer/wsrm:Identifier/@{any}This is an extensibility mechanism to allow additional attributes, based on schemas, to be addedto the element./wsrm:CreateSequence/wsrm:Offer/wsrm:EndpointAn RM Source MUST include this element, of type wsa:EndpointReferenceType (asspecified by WS-Addressing). This element specifies the endpoint reference to which SequenceLifecycle Messages, Acknowledgement Requests, and fault messages related to the offeredSequence are to be sent.Implementations MUST NOT use an endpoint reference in the Endpoint element that wouldprevent the sending of Sequence Lifecycle Message, etc. For example, using the WS-Addressing"http://www.w3.org/2005/08/addressing/none" IRI would make it impossible for the RM Destinationto ever send Sequence Lifecycle Messages (e.g. TerminateSequence) to the RM Source forthe Offered Sequence.The Offer of an Endpoint containing the "http://www.w3.org/2005/08/addressing/anonymous" IRIas its address is problematic due to the inability of a source to connect to this address and retryunacknowledged messages (as described in section 2.3). Note that this specification does notdefine any mechanisms for providing this assurance. In the absence of an extension thataddresses this issue, an RM Destination MUST NOT accept (via the/wsrm:CreateSequenceResponse/wsrm:Accept element described below) an Offer thatcontains the "http://www.w3.org/2005/08/addressing/anonymous" IRI as its address./wsrm:CreateSequence/wsrm:Offer/wsrm:ExpiresThis element, if present, of type xs:duration specifies the duration for the offered Sequence. Avalue of "PT0S" indicates that the offered Sequence will never expire. Absence of the elementindicates an implied value of "PT0S"./wsrm:CreateSequence/wsrm:Offer/wsrm:Expires/@{any}This is an extensibility mechanism to allow additional attributes, based on schemas, to be addedto the element./wsrm:CreateSequence/wsrm:Offer/wsrm:IncompleteSequenceBehaviorThis element, if present, specifies the behavior that the destination will exhibit upon the closure ortermination of an incomplete Sequence. For the purposes of defining the values used, the term"discard" refers to behavior equivalent to the Application Destination never processing a particularmessage.A value of “DiscardEntireSequence” indicates that the entire Sequence MUST be discarded if theSequence is closed, or terminated, when there are one or more gaps in the finalSequenceAcknowledgement.A value of “DiscardFollowingFirstGap” indicates that messages in the Sequence beyond the firstgap MUST be discarded when there are one or more gaps in the finalSequenceAcknowledgement.wsrm-1.1-spec-cd-08 29 March 2007Copyright © OASIS® 1993–2007. All Rights Reserved. OASIS trademark, IPR and other policies apply. Page 18 of 62


591592593594595596597598599600601602603604605606607608609610611612613614615616617618619620621622623624625626627628629630631632633634635The default value of “NoDiscard” indicates that no acknowledged messages in the Sequence willbe discarded./wsrm:CreateSequence/wsrm:Offer/{any}This is an extensibility mechanism to allow different (extensible) types of information, based on aschema, to be passed./wsrm:CreateSequence/wsrm:Offer/@{any}This is an extensibility mechanism to allow additional attributes, based on schemas, to be addedto the element./wsrm:CreateSequence/{any}This is an extensibility mechanism to allow different (extensible) types of information, based on aschema, to be passed./wsrm:CreateSequence/@{any}This is an extensibility mechanism to allow additional attributes, based on schemas, to be addedto the element.A CreateSequenceResponse is sent in the body of a response message by an RM Destination inresponse to receipt of a CreateSequence request message. It carries the Identifier of the createdSequence and indicates that the RM Source can begin sending messages in the context of the identifiedSequence.The following exemplar defines the CreateSequenceResponse syntax: xs:anyURI xs:duration ?wsrm:IncompleteSequenceBehaviorType ? wsa:EndpointReferenceType ... ?...The following describes the content model of the CreateSequenceResponse element./wsrm:CreateSequenceResponseThis element is sent in the body of the response message in response to a CreateSequencerequest message. It indicates that the RM Destination has created a new Sequence at therequest of the RM Source. The RM Destination MUST NOT send this element as a header block./wsrm:CreateSequenceResponse/wsrm:IdentifierThe RM Destination MUST include this element within any CreateSequenceResponse message itsends. The RM Destination MUST set the value of this element to the absolute URI (conformantwith RFC3986) that uniquely identifies the Sequence that has been created by the RMDestination./wsrm:CreateSequenceResponse/wsrm:Identifier/@{any}This is an extensibility mechanism to allow additional attributes, based on schemas, to be addedto the element./wsrm:CreateSequenceResponse/wsrm:Expireswsrm-1.1-spec-cd-08 29 March 2007Copyright © OASIS® 1993–2007. All Rights Reserved. OASIS trademark, IPR and other policies apply. Page 19 of 62


636637638639640641642643644645646647648649650651652653654655656657658659660661662663664665666667668669670671672673674675676677678679This element, if present, of type xs:duration accepts or refines the RM Source's requestedduration for the Sequence. It specifies the amount of time after which any resources associatedwith the Sequence SHOULD be reclaimed thus causing the Sequence to be silently terminated. Atthe RM Destination this duration is measured from a point proximate to Sequence creation and atthe RM Source this duration is measured from a point approximate to the successful processing ofthe CreateSequenceResponse. A value of "PT0S" indicates that the Sequence will neverexpire. Absence of the element indicates an implied value of "PT0S". The RM Destination MUSTset the value of this element to be equal to or less than the value requested by the RM Source inthe corresponding CreateSequence message./wsrm:CreateSequenceResponse/wsrm:Expires/@{any}This is an extensibility mechanism to allow additional attributes, based on schemas, to be addedto the element./wsrm:CreateSequenceResponse/wsrm:IncompleteSequenceBehaviorThis element, if present, specifies the behavior that the destination will exhibit upon the closure ortermination of an incomplete Sequence. For the purposes of defining the values used, the term"discard" refers to behavior equivalent to the Application Destination never processing a particularmessage.A value of “DiscardEntireSequence” indicates that the entire Sequence MUST be discarded if theSequence is closed, or terminated, when there are one or more gaps in the finalSequenceAcknowledgement.A value of “DiscardFollowingFirstGap” indicates that messages in the Sequence beyond the firstgap MUST be discarded when there are one or more gaps in the finalSequenceAcknowledgement.The default value of “NoDiscard” indicates that no acknowledged messages in the Sequence willbe discarded./wsrm:CreateSequenceResponse/wsrm:AcceptThis element, if present, enables an RM Destination to accept the offer of a correspondingSequence for the reliable exchange of messages Transmitted from RM Destination to RM Source.Note: If a CreateSequenceResponse is returned without a child Accept in response to aCreateSequence that did contain a child Offer, then the RM Source MAY immediately reclaimany resources associated with the unused offered Sequence./wsrm:CreateSequenceResponse/wsrm:Accept/wsrm:AcksToThe RM Destination MUST include this element, of type wsa:EndpointReferenceType (asspecified by WS-Addressing). It specifies the endpoint reference to which messages containingSequenceAcknowledgement header blocks and faults related to the created Sequence are tobe sent, unless otherwise noted in this specification (for example, see section3.5).Implementations MUST NOT use an endpoint reference in the AcksTo element that would preventthe sending of Sequence Acknowledgements back to the RM Source. For example, using the WS-Addressing "http://www.w3.org/2005/08/addressing/none" IRI would make it impossible for the RMDestination to ever send Sequence Acknowledgements./wsrm:CreateSequenceResponse/wsrm:Accept/{any}This is an extensibility mechanism to allow different (extensible) types of information, based on aschema, to be passed./wsrm:CreateSequenceResponse/wsrm:Accept/@{any}wsrm-1.1-spec-cd-08 29 March 2007Copyright © OASIS® 1993–2007. All Rights Reserved. OASIS trademark, IPR and other policies apply. Page 20 of 62


680681682683684685686687688689690691692693694695696697698699700701702703704705706707708709710711712713714715716717718719720721722723724725This is an extensibility mechanism to allow additional attributes, based on schemas, to be addedto the element./wsrm:CreateSequenceResponse/{any}This is an extensibility mechanism to allow different (extensible) types of information, based on aschema, to be passed./wsrm:CreateSequenceResponse/@{any}This is an extensibility mechanism to allow additional attributes, based on schemas, to be addedto the element.3.5 Closing A SequenceThere are times during the use of an RM Sequence that the RM Source or RM Destination will wish todiscontinue using a Sequence. Simply terminating the Sequence discards the state managed by the RMDestination, leaving the RM Source unaware of the final ranges of messages that were successfullytransferred to the RM Destination. To ensure that the Sequence ends with a known final state either theRM Source or RM Destination MAY choose to close the Sequence before terminating it.If the RM Source wishes to close the Sequence, then it sends a CloseSequence element, in the body ofa message, to the RM Destination. This message indicates that the RM Destination MUST NOT acceptany new messages for the specified Sequence, other than those already accepted at the time theCloseSequence element is interpreted by the RM Destination. Upon receipt of this message, orsubsequent to the RM Destination closing the Sequence of its own volition, the RM Destination MUSTinclude a final SequenceAcknowledgement (within which the RM Destination MUST include the Finalelement) header block on any messages associated with the Sequence destined to the RM Source,including the CloseSequenceResponse message or on any Sequence fault Transmitted to the RMSource.To allow the RM Destination to determine if it has received all of the messages in a Sequence, the RMSource SHOULD include the LastMsgNumber element in any CloseSequence messages it sends. TheRM Destination can use this information, for example, to implement the behavior indicated by/wsrm:CreateSequenceResponse/wsrm:IncompleteSequenceBehavior. The value of theLastMsgNumber element MUST be the same in all the CloseSequence messages for the closingSequence.If the RM Destination decides to close a Sequence of its own volition, it MAY inform the RM Source of thisevent by sending a CloseSequence element, in the body of a message, to the AcksTo EPR of thatSequence. The RM Destination MUST include a final SequenceAcknowledgement (within which the RMDestination MUST include the Final element) header block in this message and any subsequentmessages associated with the Sequence destined to the RM Source.While the RM Destination MUST NOT accept any new messages for the specified Sequence it MUST stillprocess Sequence Lifecyle Messages and Acknowledgement Requests. For example, it MUST respond toAckRequested, TerminateSequence as well as CloseSequence messages. Note, subsequentCloseSequence messages have no effect on the state of the Sequence.In the case where the RM Destination wishes to discontinue use of a Sequence it is RECOMMENDEDthat it close the Sequence. Please see Final and the SequenceClosed fault. Whenever possible theSequenceClosed fault SHOULD be used in place of the SequenceTerminated fault to allow the RMSource to still Receive Acknowledgements.The following exemplar defines the CloseSequence syntax: xs:anyURI wsrm:MessageNumberType ?wsrm-1.1-spec-cd-08 29 March 2007Copyright © OASIS® 1993–2007. All Rights Reserved. OASIS trademark, IPR and other policies apply. Page 21 of 62


726727728729730731732733734735736737738739740741742743744745746747748749750751752753754755756757758759760761762763764765766767...The following describes the content model of the CloseSequence element./wsrm:CloseSequenceThis element MAY be sent by an RM Source to indicate that the RM Destination MUST NOTaccept any new messages for this Sequence This element MAY also be sent by an RMDestination to indicate that it will not accept any new messages for this Sequence./wsrm:CloseSequence/wsrm:IdentifierThe RM Source or RM Destination MUST include this element in any CloseSequence messages itsends. The RM Source or RM Destination MUST set the value of this element to the absolute URI(conformant with RFC3986) of the closing Sequence./wsrm:CloseSequence/wsrm:LastMessageNumberThe RM Source SHOULD include this element in any CloseSequence message it sends. TheLastMsgNumber element specifies the highest assigned message number of all the SequenceTraffic Messages for the closing Sequence./wsrm:CloseSequence/wsrm:Identifier/@{any}This is an extensibility mechanism to allow additional attributes, based on schemas, to be addedto the element./wsrm:CloseSequence/{any}This is an extensibility mechanism to allow different (extensible) types of information, based on aschema, to be passed./wsrm:CloseSequence/@{any}This is an extensibility mechanism to allow additional attributes, based on schemas, to be addedto the element.A CloseSequenceResponse is sent in the body of a message in response to receipt of aCloseSequence request message. It indicates that the responder has closed the Sequence.The following exemplar defines the CloseSequenceResponse syntax: xs:anyURI ...The following describes the content model of the CloseSequenceResponse element./wsrm:CloseSequenceResponseThis element is sent in the body of a message in response to receipt of a CloseSequencerequest message. It indicates that the responder has closed the Sequence./wsrm:CloseSequenceResponse/wsrm:IdentifierThe responder (RM Source or RM Destination) MUST include this element in anyCloseSequenceResponse message it sends. The responder MUST set the value of thiselement to the absolute URI (conformant with RFC3986) of the closing Sequence./wsrm:CloseSequenceResponse/wsrm:Identifier/@{any}This is an extensibility mechanism to allow additional attributes, based on schemas, to be addedto the element.wsrm-1.1-spec-cd-08 29 March 2007Copyright © OASIS® 1993–2007. All Rights Reserved. OASIS trademark, IPR and other policies apply. Page 22 of 62


768769770771772773774775776777778779780781782783784785786787788789790791792793794795796797798799800801802803804805806807808809810811812/wsrm:CloseSequenceResponse/{any}This is an extensibility mechanism to allow different (extensible) types of information, based on aschema, to be passed./wsrm:CloseSequenceResponse/@{any}This is an extensibility mechanism to allow additional attributes, based on schemas, to be addedto the element.3.6 Sequence TerminationWhen the RM Source has completed its use of the Sequence it sends a TerminateSequence element,in the body of a message, to the RM Destination to indicate that the Sequence is complete and that it willnot be sending any further messages related to the Sequence. The RM Destination can safely reclaim anyresources associated with the Sequence upon receipt of the TerminateSequence message. Undernormal usage the RM Source will complete its use of the Sequence when all of the messages in theSequence have been acknowledged. However, the RM Source is free to Terminate or Close a Sequenceat any time regardless of the acknowledgement state of the messages.To allow the RM Destination to determine if it has received all of the messages in a Sequence, the RMSource SHOULD include the LastMsgNumber element in any TerminateSequence messages it sends.The RM Destination can use this information, for example, to implement the behavior indicated by/wsrm:CreateSequenceResponse/wsrm:IncompleteSequenceBehavior. The value of theLastMsgNumber element in the TerminateSequence message MUST be equal to the value of theLastMsgNumber element in any CloseSequence message(s) sent by the RM Source for the sameSequence.If the RM Destination decides to terminate a Sequence of its own volition, it MAY inform the RM Source ofthis event by sending a TerminateSequence element, in the body of a message, to the AcksTo EPR forthat Sequence. The RM Destination MUST include a final SequenceAcknowledgement (within whichthe RM Destination MUST include the Final element) header block in this message.The following exemplar defines the TerminateSequence syntax: xs:anyURI wsrm:MessageNumberType ?...The following describes the content model of the TerminateSequence element./wsrm:TerminateSequenceThis element MAY be sent by an RM Source to indicate it has completed its use of the Sequence.It indicates that the RM Destination can safely reclaim any resources related to the identifiedSequence. The RM Source MUST NOT send this element as a header block. The RM SourceMAY retransmit this element. Once this element is sent, other than this element, the RM SourceMUST NOT send any additional message to the RM Destination referencing this Sequence.This element MAY also be sent by the RM Destination to indicate that it has unilaterallyterminated the Sequence. Upon sending this message the RM Destination MUST NOT acceptany additional messages (with the exception of the correspondingTerminateSequenceResponse) for this Sequence. Upon receipt of a TerminateSequencethe RM Source MUST NOT send any additional messages (with the exception of thecorresponding TerminateSequenceResponse) for this Sequence./wsrm:TerminateSequence/wsrm:Identifierwsrm-1.1-spec-cd-08 29 March 2007Copyright © OASIS® 1993–2007. All Rights Reserved. OASIS trademark, IPR and other policies apply. Page 23 of 62


813814815816817818819820821822823824825826827828829830831832833834835836837838839840841842843844845846847848849850851852853The RM Source or RM Destination MUST include this element in any TerminateSequencemessage it sends. The RM Source or RM Destination MUST set the value of this element to theabsolute URI (conformant with RFC3986) of the terminating Sequence./wsrm:TerminateSequence/wsrm:LastMsgNumberThe RM Source SHOULD include this element in any TerminateSequence message it sends. TheLastMsgNumber element specifies the highest assigned message number of all the SequenceTraffic Messages for the terminating Sequence./wsrm:TerminateSequence/wsrm:Identifier/@{any}This is an extensibility mechanism to allow additional attributes, based on schemas, to be addedto the element./wsrm:TerminateSequence/{any}This is an extensibility mechanism to allow different (extensible) types of information, based on aschema, to be passed./wsrm:TerminateSequence/@{any}This is an extensibility mechanism to allow additional attributes, based on schemas, to be addedto the element.A TerminateSequenceResponse is sent in the body of a message in response to receipt of aTerminateSequence request message. It indicates that responder has terminated the Sequence.The following exemplar defines the TerminateSequenceResponse syntax: xs:anyURI ...The following describes the content model of the TerminateSequence element./wsrm:TerminateSequenceResponseThis element is sent in the body of a message in response to receipt of a TerminateSequencerequest message. It indicates that the responder has terminated the Sequence. The responderMUST NOT send this element as a header block./wsrm:TerminateSequenceResponse/wsrm:IdentifierThe responder (RM Source or RM Destination) MUST include this element in anyTerminateSequenceResponse message it sends. The responder MUST set the value of thiselement to the absolute URI (conformant with RFC3986) of the terminating Sequence./wsrm:TerminateSequenceResponse/wsrm:Identifier/@{any}This is an extensibility mechanism to allow additional attributes, based on schemas, to be addedto the element./wsrm:TerminateSequenceResponse/{any}This is an extensibility mechanism to allow different (extensible) types of information, based on aschema, to be passed./wsrm:TerminateSequenceResponse/@{any}This is an extensibility mechanism to allow additional attributes, based on schemas, to be addedto the element.wsrm-1.1-spec-cd-08 29 March 2007Copyright © OASIS® 1993–2007. All Rights Reserved. OASIS trademark, IPR and other policies apply. Page 24 of 62


854855856857858859860861862863864865866867868869870871872873874875876877878879880881882883884885886887888889890891892893894895896On receipt of a TerminateSequence message the receiver (RM Source or RM Destination) MUSTrespond with a corresponding TerminateSequenceResponse message or generate a faultUnknownSequenceFault if the Sequence is not known.3.7 SequencesThe RM protocol uses a Sequence header block to track and manage the reliable transfer of messages.The RM Source MUST include a Sequence header block in all messages for which reliable transfer isREQUIRED. The RM Source MUST identify Sequences with unique Identifier elements and the RMSource MUST assign each message within a Sequence a MessageNumber element that increments by 1from an initial value of 1. These values are contained within a Sequence header block accompanyingeach message being transferred in the context of a Sequence.The RM Source MUST NOT include more than one Sequence header block in any message.A following exemplar defines its syntax: xs:anyURI wsrm:MessageNumberType ...The following describes the content model of the Sequence header block./wsrm:SequenceThis protocol element associates the message in which it is contained with a previouslyestablished RM Sequence. It contains the Sequence's unique identifier and the containingmessage's ordinal position within that Sequence. The RM Destination MUST understand theSequence header block. The RM Source MUST assign a mustUnderstand attribute with avalue 1/true (from the namespace corresponding to the version of SOAP to which the SequenceSOAP header block is bound) to the Sequence header block element./wsrm:Sequence/wsrm:IdentifierAn RM Source that includes a Sequence header block in a SOAP envelope MUST include thiselement in that header block. The RM Source MUST set the value of this element to the absoluteURI (conformant with RFC3986) that uniquely identifies the Sequence./wsrm:Sequence/wsrm:Identifier/@{any}This is an extensibility mechanism to allow additional attributes, based on schemas, to be addedto the element./wsrm:Sequence/wsrm:MessageNumberThe RM Source MUST include this element within any Sequence headers it creates. This elementis of type MessageNumberType. It represents the ordinal position of the message within aSequence. Sequence message numbers start at 1 and monotonically increase by 1 throughoutthe Sequence. See section 4.5 for Message Number Rollover fault./wsrm:Sequence/{any}This is an extensibility mechanism to allow different (extensible) types of information, based on aschema, to be passed./wsrm:Sequence/@{any}This is an extensibility mechanism to allow additional attributes, based on schemas, to be addedto the element.wsrm-1.1-spec-cd-08 29 March 2007Copyright © OASIS® 1993–2007. All Rights Reserved. OASIS trademark, IPR and other policies apply. Page 25 of 62


897898899900901902903904905906907908909910911912913914915916917918919920921922923924925926927928929930931932933934935936937938The following example illustrates a Sequence header block.http://example.com/abc103.8 Request AcknowledgementThe purpose of the AckRequested header block is to signal to the RM Destination that the RM Source isrequesting that a SequenceAcknowledgement be sent.The RM Source MAY request an Acknowledgement Message from the RM Destination at any time byindependently transmitting an AckRequested header block (i.e. as a header of a SOAP envelope with anempty body). Alternatively the RM Source MAY include an AckRequested header block in any messagetargeted to the RM Destination. The RM Destination SHOULD process AckRequested header blocksthat are included in any message it receives. If a non-mustUnderstand fault occurs when processing anAckRequested header block that was piggy-backed, a fault MUST be generated, but the processing ofthe original message MUST NOT be affected.An RM Destination that Receives a message that contains an AckRequested header block MUST senda message containing a SequenceAcknowledgement header block to the AcksTo endpoint reference(see section 3.4) for a known Sequence or else generate an UnknownSequence fault. It isRECOMMENDED that the RM Destination return a AcknowledgementRange or None element insteadof a Nack element (see section 3.9).The following exemplar defines its syntax: xs:anyURI ...The following describes the content model of the AckRequested header block./wsrm:AckRequestedThis element requests an Acknowledgement for the identified Sequence./wsrm:AckRequested/wsrm:IdentifierAn RM Source that includes an AckRequested header block in a SOAP envelope MUST includethis element in that header block. The RM Source MUST set the value of this element to theabsolute URI, (conformant with RFC3986), that uniquely identifies the Sequence to which therequest applies./wsrm:AckRequested/wsrm:Identifier/@{any}This is an extensibility mechanism to allow additional attributes, based on schemas, to be addedto the element./wsrm:AckRequested/{any}This is an extensibility mechanism to allow different (extensible) types of information, based on aschema, to be passed./wsrm:AckRequested/@{any}This is an extensibility mechanism to allow additional attributes, based on schemas, to be addedto the element.wsrm-1.1-spec-cd-08 29 March 2007Copyright © OASIS® 1993–2007. All Rights Reserved. OASIS trademark, IPR and other policies apply. Page 26 of 62


9399409419429439449459469479489499509519529539549559569579589599609619629639649659669679689699709719729739749759769779789799809819829839843.9 Sequence AcknowledgementThe RM Destination informs the RM Source of successful message receipt using aSequenceAcknowledgement header block. Acknowledgements can be explicitly requested using theAckRequested directive (see section 3.8).The RM Destination MAY Transmit the SequenceAcknowledgement header block independently (i.e. asa header of a SOAP envelope with an empty body). Alternatively, an RM Destination MAY include aSequenceAcknowledgement header block on any SOAP envelope targeted to the endpoint referencedby the AcksTo EPR. The RM Source SHOULD process SequenceAcknowledgement header blocks thatare included in any message it receives. If a non-mustUnderstand fault occurs when processing aSequenceAcknowledgement header that was piggy-backed, a fault MUST be generated, but theprocessing of the original message MUST NOT be affected.During creation of a Sequence the RM Source MAY specify the WS-Addressing anonymous IRI as theaddress of the AcksTo EPR for that Sequence. When the RM Source specifies the WS-Addressinganonymous IRI as the address of the AcksTo EPR, the RM Destination MUST Transmit anySequenceAcknowledgement headers for the created Sequence in a SOAP envelope to be Transmittedon the protocol binding-specific back-channel. Such a channel is provided by the context of a Receivedmessage containing a SOAP envelope that contains a Sequence header block and/or an AckRequestedheader block for that same Sequence identifier. When the RM Destination receives an AckRequestedheader, and the AckTo EPR for that sequence is the WS-Addressing anonymous IRI, the RM DestinationSHOULD respond on the protocol binding-specific back-channel provided by the Received messagecontaining the AckRequested header block.The following exemplar defines its syntax: xs:anyURI [ [ [ +| ] ? ]| wsrm:MessageNumberType + ]...The following describes the content model of the SequenceAcknowledgement header block./wsrm:SequenceAcknowledgementThis element contains the Sequence Acknowledgement information./wsrm:SequenceAcknowledgement/wsrm:IdentifierAn RM Destination that includes a SequenceAcknowledgement header block in a SOAPenvelope MUST include this element in that header block. The RM Destination MUST set thevalue of this element to the absolute URI (conformant with RFC3986) that uniquely identifies theSequence. The RM Destination MUST NOT include multiple SequenceAcknowledgementheader blocks that share the same value for Identifier within the same SOAP envelope./wsrm:SequenceAcknowledgement/wsrm:Identifier/@{any}This is an extensibility mechanism to allow additional attributes, based on schemas, to be addedto the element./wsrm:SequenceAcknowledgement/wsrm:AcknowledgementRangewsrm-1.1-spec-cd-08 29 March 2007Copyright © OASIS® 1993–2007. All Rights Reserved. OASIS trademark, IPR and other policies apply. Page 27 of 62


985986987988989990991992993994995996997998999100010011002100310041005100610071008100910101011101210131014101510161017101810191020102110221023102410251026102710281029The RM Destination MAY include one or more instances of this element within aSequenceAcknowledgement header block. It contains a range of Sequence message numberssuccessfully accepted by the RM Destination. The ranges MUST NOT overlap. The RMDestination MUST NOT include this element if a sibling Nack or None element is also present asa child of SequenceAcknowledgement./wsrm:SequenceAcknowledgement/wsrm:AcknowledgementRange/@UpperThe RM Destination MUST set the value of this attribute equal to the message number of thehighest contiguous message in a Sequence range accepted by the RM Destination./wsrm:SequenceAcknowledgement/wsrm:AcknowledgementRange/@LowerThe RM Destination MUST set the value of this attribute equal to the message number of thelowest contiguous message in a Sequence range accepted by the RM Destination./wsrm:SequenceAcknowledgement/wsrm:AcknowledgementRange/@{any}This is an extensibility mechanism to allow additional attributes, based on schemas, to be addedto the element./wsrm:SequenceAcknowledgement/wsrm:NoneThe RM Destination MUST include this element within a SequenceAcknowledgement headerblock if the RM Destination has not accepted any messages for the specified Sequence. The RMDestination MUST NOT include this element if a sibling AcknowledgementRange or Nackelement is also present as a child of the SequenceAcknowledgement./wsrm:SequenceAcknowledgement/wsrm:FinalThe RM Destination MAY include this element within a SequenceAcknowledgement headerblock. This element indicates that the RM Destination is not receiving new messages for thespecified Sequence. The RM Source can be assured that the ranges of messages acknowledgedby this SequenceAcknowledgement header block will not change in the future. The RMDestination MUST include this element when the Sequence is closed. The RM Destination MUSTNOT include this element when sending a Nack; it can only be used when sendingAcknowledgementRange elements or a None./wsrm:SequenceAcknowledgement/wsrm:NackThe RM Destination MAY include this element within a SequenceAcknowledgement headerblock. If used, the RM Destination MUST set the value of this element to a MessageNumberTyperepresenting the MessageNumber of an unreceived message in a Sequence. The RM DestinationMUST NOT include a Nack element if a sibling AcknowledgementRange or None element isalso present as a child of SequenceAcknowledgement. Upon the receipt of a Nack, an RMSource SHOULD retransmit the message identified by the Nack. The RM Destination MUST NOTissue a SequenceAcknowledgement containing a Nack for a message that it has previouslyacknowledged within an AcknowledgementRange. The RM Source SHOULD ignore aSequenceAcknowledgement containing a Nack for a message that has previously beenacknowledged within an AcknowledgementRange./wsrm:SequenceAcknowledgement/{any}This is an extensibility mechanism to allow different (extensible) types of information, based on aschema, to be passed./wsrm:SequenceAcknowledgement/@{any}This is an extensibility mechanism to allow additional attributes, based on schemas, to be addedto the element.The following examples illustrate SequenceAcknowledgement elements:wsrm-1.1-spec-cd-08 29 March 2007Copyright © OASIS® 1993–2007. All Rights Reserved. OASIS trademark, IPR and other policies apply. Page 28 of 62


103010311032103310341035103610371038103910401041104210431044104510461047Message numbers 1...10 inclusive in a Sequence have been accepted by the RM Destination.http://example.com/abcMessage numbers 1..2, 4..6, and 8..10 inclusive in a Sequence have been accepted by the RMDestination, messages 3 and 7 have not been accepted.http://example.com/abcMessage number 3 in a Sequence has not been accepted by the RM Destination.http://example.com/abc3wsrm-1.1-spec-cd-08 29 March 2007Copyright © OASIS® 1993–2007. All Rights Reserved. OASIS trademark, IPR and other policies apply. Page 29 of 62


10481049105010511052105310541055105610571058105910601061106210631064106510661067106810691070107110721073107410751076107710781079108010811082108310841085108610871088108910904 FaultsFaults for the CreateSequence message exchange are treated as defined in WS-Addressing. CreateSequence Refused is a possible fault reply for this operation. Unknown Sequence is a fault generated byEndpoints when messages carrying RM header blocks targeted at unrecognized or terminated Sequencesare detected. WSRMRequired is a fault generated by an RM Destination that requires the use of WS-RMon a Received message that did not use the protocol. All other faults in this section relate to knownSequences. Destinations that generate faults related to known sequences SHOULD transmit those faults.If transmitted, such faults MUST be transmitted to the same [destination] as Acknowledgement messages.Entities that generate WS-ReliableMessaging faults MUST include as the [action] property the default faultaction IRI defined below. The value from the W3C Recommendation is below for informational purposes:http://docs.oasis-open.org/ws-rx/wsrm/200702/faultThe faults defined in this section are generated if the condition stated in the preamble is met. Faulthandling rules are defined in section 6 of WS-Addressing SOAP Binding.The definitions of faults use the following properties:[Code] The fault code.[Subcode] The fault subcode.[Reason] The English language reason element.[Detail] The detail element(s). If absent, no detail element is defined for the fault. If more than one detailelement is defined for a fault, implementations MUST include the elements in the order that they arespecified.Entities that generate WS-ReliableMessaging faults MUST set the [Code] property to either "Sender" or"Receiver". These properties are serialized into text XML as follows:SOAP Version Sender ReceiverSOAP 1.1 S11:Client S11:ServerSOAP 1.2 S:Sender S:ReceiverThe properties above bind to a SOAP 1.2 fault as follows:http://docs.oasis-open.org/ws-rx/wsrm/200702/fault [Code] [Subcode] [Reason] [Detail]wsrm-1.1-spec-cd-08 29 March 2007Copyright © OASIS® 1993–2007. All Rights Reserved. OASIS trademark, IPR and other policies apply. Page 30 of 62


1091109210931094109510961097109810991100110111021103110411051106110711081109111011111112111311141115111611171118111911201121112211231124112511261127112811291130113111321133113411351136113711381139...The properties above bind to a SOAP 1.1 fault as follows when the fault is triggered by processing an RMheader block: wsrm:FaultCodes [Detail] ... [Code] [Reason] The properties bind to a SOAP 1.1 fault as follows when the fault is generated as a result of processing aCreateSequence request message: [Subcode] [Reason] 4.1 SequenceFault ElementThe purpose of the SequenceFault element is to carry the specific details of a fault generated during thereliable messaging specific processing of a message belonging to a Sequence. WS-ReliableMessagingnodes MUST use the SequenceFault container only in conjunction with the SOAP 1.1 fault mechanism.WS-ReliableMessaging nodes MUST NOT use the SequenceFault container in conjunction with theSOAP 1.2 binding.The following exemplar defines its syntax: wsrm:FaultCode ... ?...The following describes the content model of the SequenceFault element./wsrm:SequenceFaultThis is the element containing Sequence fault information for WS-ReliableMessaging/wsrm:SequenceFault/wsrm:FaultCodewsrm-1.1-spec-cd-08 29 March 2007Copyright © OASIS® 1993–2007. All Rights Reserved. OASIS trademark, IPR and other policies apply. Page 31 of 62


114011411142114311441145114611471148114911501151115211531154115511561157115811591160116111621163WS-ReliableMessaging nodes that generate a SequenceFault MUST set the value of thiselement to a qualified name from the set of faults [Subcodes] defined below./wsrm:SequenceFault/wsrm:DetailThis element, if present, carries application specific error information related to the fault beingdescribed./wsrm:SequenceFault/wsrm:Detail/{any}The application specific error information related to the fault being described./wsrm:SequenceFault/wsrm:Detail/@{any}The application specific error information related to the fault being described./wsrm:SequenceFault/{any}This is an extensibility mechanism to allow different (extensible) types of information, based on aschema, to be passed./wsrm:SequenceFault/@{any}This is an extensibility mechanism to allow additional attributes, based on schemas, to be addedto the element.4.2 Sequence TerminatedThe Endpoint that generates this fault SHOULD make every reasonable effort to notify the correspondingEndpoint of this decision.Properties:[Code] Sender or Receiver[Subcode] wsrm:SequenceTerminated[Reason] The Sequence has been terminated due to an unrecoverable error.[Detail] xs:anyURI Generated by Condition Action UponGenerationAction Upon ReceiptRM Source or RMDestination.Encountering anunrecoverable conditionor detection of violationof the protocol.Sequence termination.MUST terminate theSequence if nototherwise terminated.11641165116611674.3 Unknown SequenceProperties:[Code] Sender[Subcode] wsrm:UnknownSequencewsrm-1.1-spec-cd-08 29 March 2007Copyright © OASIS® 1993–2007. All Rights Reserved. OASIS trademark, IPR and other policies apply. Page 32 of 62


116811691170[Reason] The value of wsrm:Identifier is not a known Sequence identifier.[Detail] xs:anyURI Generated by Condition Action UponGenerationAction Upon ReceiptRM Source or RMDestination.In response to amessage containing anunknown or terminatedSequence identifier.None.MUST terminate theSequence if nototherwise terminated.117111721173117411751176117711784.4 Invalid AcknowledgementAn example of when this fault is generated is when a message is Received by the RM Source containinga SequenceAcknowledgement covering messages that have not been sent.[Code] Sender[Subcode] wsrm:InvalidAcknowledgement[Reason] The SequenceAcknowledgement violates the cumulative Acknowledgement invariant.[Detail] ... Generated by Condition Action UponGenerationAction Upon ReceiptRM Source.In response to aSequenceAcknowledgement that violate theinvariants stated in 2.3or any of therequirements in 3.9about valid combinationsof AckRange, Nack andNone in a singleSequenceAcknowledgement element or withrespect to alreadyReceived suchelements.Unspecified.Unspecified.117911801181118211834.5 Message Number RolloverIf the condition listed below is reached, the RM Destination MUST generate this fault.Properties:[Code] Sender[Subcode] wsrm:MessageNumberRolloverwsrm-1.1-spec-cd-08 29 March 2007Copyright © OASIS® 1993–2007. All Rights Reserved. OASIS trademark, IPR and other policies apply. Page 33 of 62


1184118511861187[Reason] The maximum value for wsrm:MessageNumber has been exceeded.[Detail] xs:anyURI wsrm:MessageNumberType Generated by Condition Action UponGenerationAction Upon ReceiptRM Destination.Message number in/wsrm:Sequence/wsrm:MessageNumber ofa Received messageexceeds the internallimitations of an RMDestination or reachesthe maximum value of9,223,372,036,854,775,807.RM DestinationSHOULD continue toaccept undeliveredmessages until theSequence is closed orterminated.RM Source SHOULDcontinue to retransmitundelivered messagesuntil the Sequence isclosed or terminated.11881189119011911192119311944.6 Create Sequence RefusedProperties:[Code] Sender or Receiver[Subcode] wsrm:CreateSequenceRefused[Reason] The Create Sequence request has been refused by the RM Destination.[Detail]xs:anyGenerated by Condition Action UponGenerationAction Upon ReceiptRM Destination.In response to aCreateSequencemessage when the RMDestination does notwish to create a newSequence.Unspecified.Sequence terminated.11951196119711981199120012014.7 Sequence ClosedThis fault is generated by an RM Destination to indicate that the specified Sequence has been closed.This fault MUST be generated when an RM Destination is asked to accept a message for a Sequence thatis closed.Properties:[Code] Sender[Subcode] wsrm:SequenceClosedwsrm-1.1-spec-cd-08 29 March 2007Copyright © OASIS® 1993–2007. All Rights Reserved. OASIS trademark, IPR and other policies apply. Page 34 of 62


120212031204[Reason] The Sequence is closed and cannot accept new messages.[Detail] xs:anyURI Generated by Condition Action UponGenerationAction Upon ReceiptRM Destination.In response to amessage that belongs toa Sequence that isalready closed.Unspecified.Sequence closed.1205120612071208120912101211121212134.8 WSRM RequiredIf an RM Destination requires the use of WS-RM, this fault is generated when it Receives an incomingmessage that did not use this protocol.Properties:[Code] Sender[Subcode] wsrm:WSRMRequired[Reason] The RM Destination requires the use of WSRM.[Detail]xs:anywsrm-1.1-spec-cd-08 29 March 2007Copyright © OASIS® 1993–2007. All Rights Reserved. OASIS trademark, IPR and other policies apply. Page 35 of 62


12141215121612171218121912201221122212231224122512261227122812291230123112321233123412351236123712381239124012411242124312441245124612471248124912501251125212535 Security Threats and CountermeasuresThis specification considers two sets of security requirements, those of the applications that use the WS-RM protocol and those of the protocol itself.This specification makes no assumptions about the security requirements of the applications that use WS-RM. However, once those requirements have been satisfied within a given operational context, theaddition of WS-RM to this operational context should not undermine the fulfillment of those requirements;the use of WS-RM should not create additional attack vectors within an otherwise secure system.There are many other security concerns that one may need to consider when implementing or using thisprotocol. The material below should not be considered as a "check list". Implementers and users of thisprotocol are urged to perform a security analysis to determine their particular threat profile and theappropriate responses to those threats.Implementers are also advised that there is a core tension between security and reliable messaging thatcan be problematic if not addressed by implementations; one aspect of security is to prevent messagereplay but one of the invariants of this protocol is to resend messages until they are acknowledged.Consequently, if the security sub-system processes a message but a failure occurs before the reliablemessaging sub-system Receives that message, then it is possible (and likely) that the security sub-systemwill treat subsequent copies as replays and discard them. At the same time, the reliable messaging subsystemwill likely continue to expect and even solicit the missing message(s). Care should be taken toavoid and prevent this condition.5.1 Threats and CountermeasuresThe primary security requirement of this protocol is to protect the specified semantics and protocolinvariants against various threats. The following sections describe several threats to the integrity andoperation of this protocol and provide some general outlines of countermeasures to those threats.Implementers and users of this protocol should keep in mind that all threats are not necessarily applicableto all operational contexts.5.1.1 Integrity ThreatsIn general, any mechanism which allows an attacker to alter the information in a Sequence TrafficMessage, Sequence Lifecycle Message, Acknowledgement Messages, Acknowledgement Request, orSequence-related fault, or which allows an attacker to alter the correlation of a RM Protocol Header Blockto its intended message represents a threat to the WS-RM protocol.For example, if an attacker is able to swap Sequence headers on messages in transit between the RMSource and RM Destination then they have undermined the implementation's ability to guarantee the firstinvariant described in section 2.3. The result is that there is no way of guaranteeing that messages will beDelivered to the Application Destination in the same order that they were sent by the Application Source.5.1.1.1 CountermeasuresIntegrity threats are generally countered via the use of digital signatures some level of the communicationprotocol stack. Note that, in order to counter header swapping attacks, the signature SHOULD includeboth the SOAP body and any relevant SOAP headers (e.g. Sequence header). Because some headers(AckRequested, SequenceAcknowledgement) are independent of the body of the SOAP message in whichthey occur, implementations MUST allow for signatures that cover only these headers.wsrm-1.1-spec-cd-08 29 March 2007Copyright © OASIS® 1993–2007. All Rights Reserved. OASIS trademark, IPR and other policies apply. Page 36 of 62


12541255125612571258125912601261126212631264126512661267126812691270127112721273127412751276127712781279128012811282128312841285128612871288128912901291129212931294129512965.1.2 Resource Consumption ThreatsThe creation of a Sequence with an RM Destination consumes various resources on the systems used toimplement that RM Destination. These resources can include network connections, database tables,message queues, etc. This behavior can be exploited to conduct denial of service attacks against an RMDestination. For example, a simple attack is to repeatedly send CreateSequence messages to an RMDestination. Another attack is to create a Sequence for a service that is known to require in-ordermessage Delivery and use this Sequence to send a stream of very large messages to that service, makingsure to omit message number “1” from that stream.5.1.2.1 CountermeasuresThere are a number of countermeasures against the described resource consumption threats. Thetechnique advocated by this specification is for the RM Destination to restrict the ability to create aSequence to a specific set of entities/principals. This reduces the number of potential attackers and, insome cases, allows the identity of any attackers to be determined.The ability to restrict Sequence creation depends, in turn, upon the RM Destination's ability to identify andauthenticate the RM Source that issued the CreateSequence message.5.1.3 Sequence Spoofing ThreatsSequence spoofing is a class of threats in which the attacker uses knowledge of the Identifier for aparticular Sequence to forge Sequence Lifecycle or Traffic Messages. For example the attacker creates afake TerminateSequence message that references the target Sequence and sends this message to theappropriate RM Destination. Some sequence spoofing attacks also require up-to-date knowledge of thecurrent MessageNumber for their target Sequence.In general any Sequence Lifecycle Message, RM Protocol Header Block, or sequence-correlated SOAPfault (e.g. InvalidAcknowledgement) can be used by someone with knowledge of the Sequence identifierto attack the Sequence. These attacks are “two-way” in that an attacker may choose to target the RMSource by, for example, inserting a fake SequenceAcknowledgement header into a message that it sendsto the AcksTo EPR of an RM Source.5.1.3.1 Sequence HijackingSequence hijacking is a specific case of a sequence spoofing attack. The attacker attempts to injectSequence Traffic Messages into an existing Sequence by inserting fake Sequence headers into thosemessages.Note that “sequence hijacking” should not be equated with “security session hijacking”. Although aSequence may be bound to some form of a security session in order to counter the threats described inthis section, applications MUST NOT rely on WS-RM-related information to make determinations aboutthe identity of the entity that created a message; applications SHOULD rely only upon information that isestablished by the security infrastructure to make such determinations. Failure to observe this rulecreates, among other problems, a situation in which the absence of WS-RM may deprive an application ofthe ability to authenticate its peers even though the necessary security processing has taken place.5.1.3.2 CountermeasuresThere are a number of countermeasures against sequence spoofing threats. The technique advocated bythis specification is to consider the Sequence to be a shared resource that is jointly owned by the RMSource that initiated its creation (i.e. that sent the CreateSequence message) and the RM Destination thatserves as its terminus (i.e. that sent the CreateSequenceResponse message). To counter sequencespoofing attempts the RM Destination SHOULD ensure that every message or fault that it Receives thatwsrm-1.1-spec-cd-08 29 March 2007Copyright © OASIS® 1993–2007. All Rights Reserved. OASIS trademark, IPR and other policies apply. Page 37 of 62


129712981299130013011302130313041305130613071308130913101311131213131314131513161317131813191320132113221323132413251326132713281329133013311332133313341335133613371338refers to a particular Sequence originated from the RM Source that jointly owns the referenced Sequence.For its part the RM Source SHOULD ensure that every message or fault that it Receives that refers to aparticular Sequence originated from the RM Destination that jointly owns the referenced Sequence.For the RM Destination to be able to identify its sequence peer it MUST be able to identify andauthenticate the entity that sent the CreateSequence message. Similarly for the RM Source to identify itssequence peer it MUST be able to identify and authenticate the entity that sent theCreateSequenceResponse message. For either the RM Destination or the RM Source to determine if amessage was sent by its sequence peer it MUST be able to identify and authenticate the initiator of thatmessage and, if necessary, correlate this identity with the sequence peer identity established at sequencecreation time.5.2 Security Solutions and TechnologiesThe security threats described in the previous sections are neither new nor unique. The solutions thathave been developed to secure other SOAP-based protocols can be used to secure WS-RM as well. Thissection maps the facilities provided by common web services security solutions against countermeasuresdescribed in the previous sections.Before continuing this discussion, however, some examination of the underlying requirements of thepreviously described countermeasures is necessary. Specifically it should be noted that the techniquedescribed in section 5.1.2.1 has two components. Firstly, the RM Destination identifies and authenticatesthe issuer of a CreateSequence message. Secondly, the RM Destination performs an authorization checkagainst this authenticated identity and determines if the RM Source is permitted to create Sequences withthe RM Destination. Since the facilities for performing this authorization check (runtime infrastructure,policy frameworks, etc.) lie completely within the domain of individual implementations, any discussion ofsuch facilities is considered to be beyond the scope of this specification.5.2.1 Transport Layer SecurityThis section describes how the facilities provided by SSL/TLS [RFC 4346] can be used to implement thecountermeasures described in the previous sections. The use of SSL/TLS is subject to the constraintsdefined in section 4 of the Basic Security Profile 1.0 [BSP 1.0].The description provided here is general in nature and is not intended to serve as a complete definition onthe use of SSL/TLS to protect WS-RM. In order to interoperate implementations need to agree on thechoice of features as well as the manner in which they will be used. The mechanisms described in theWeb Services Security Policy Language [SecurityPolicy] MAY be used by services to describe therequirements and constraints of the use of SSL/TLS.5.2.1.1 ModelThe basic model for using SSL/TLS is as follows:1. The RM Source establishes an SSL/TLS session with the RM Destination.2. The RM Source uses this SSL/TLS session to send a CreateSequence message to the RMDestination.3. The RM Destination establishes an SSL/TLS session with the RM Source and sends anasynchronous CreateSequenceResponse using this session. Alternately it may respond with asynchronous CreateSequenceResponse using the session established in (1).4. For the lifetime of the Sequence the RM Source uses the SSL/TLS session from (1) to Transmitany and all messages or faults that refer to that Sequence.wsrm-1.1-spec-cd-08 29 March 2007Copyright © OASIS® 1993–2007. All Rights Reserved. OASIS trademark, IPR and other policies apply. Page 38 of 62


13391340134113421343134413451346134713481349135013515. For the lifetime of the Sequence the RM Destination either uses the SSL/TLS session establishedin (3) to Transmit any and all messages or faults that refer to that Sequence or, for synchronousexchanges, the RM Destination uses the SSL/TLS session established in (1).5.2.1.2 Countermeasure ImplementationUsed in its simplest fashion (without relying upon any authentication mechanisms), SSL/TLS provides thenecessary integrity qualities to counter the threats described in section 5.1.1. Note, however, that thenature of SSL/TLS limits the scope of this integrity protection to a single transport level session. IfSSL/TLS is the only mechanism used to provide integrity, any intermediaries between the RM Source andthe RM Destination MUST be trusted to preserve the integrity of the messages that flow through them.As noted, the technique described in sections 5.1.2.1 involves the use of authentication. This specificationadvocates either of two mechanisms for authenticating entities using SSL/TLS. In both of these methodsthe SSL/TLS server (the party accepting the SSL/TLS connection) authenticates itself to the SSL/TLSclient using an X.509 certificate that is exchanged during the SSL/TLS handshake.1352135313541355135613571358HTTP Basic Authentication: This method of authentication presupposes that a SOAP/HTTPbinding is being used as part of the protocol stack beneath WS-RM. Subsequent to theestablishment of the SSL/TLS session, the sending party authenticates itself to the receiving partyusing HTTP Basic Authentication [RFC 2617]. For example, a RM Source might authenticate itselfto a RM Destination (e.g. when transmitting a Sequence Traffic Message) using BasicAuth.Similarly the RM Destination might authenticate itself to the RM Source (e.g. when sending anAcknowledgement) using BasicAuth.13591360136113621363136413651366136713681369137013711372137313741375137613771378137913801381138213831384 SSL/TLS Client Authentication: In this method of authentication, the party initiating theconnection authenticates itself to the party accepting the connection using an X.509 certificatethat is exchanged during the SSL/TLS handshake.To implement the countermeasures described in section 5.1.2.1 the RM Source must authenticate itselfusing one the above mechanisms. The authenticated identity can then be used to determine if the RMSource is authorized to create a Sequence with the RM Destination.This specification advocates implementing the countermeasures described in section 5.1.3.2 by requiringan RM node's Sequence peer to be equivalent to their SSL/TLS session peer. This allows theauthorization decisions described in section 5.1.3.2 to be based on SSL/TLS session identity rather thanon authentication information. For example, an RM Destination can determine that a Sequence TrafficMessage rightfully belongs to its referenced Sequence if that message arrived over the same SSL/TLSsession that was used to carry the CreateSequence message for that Sequence. Note that requiring aone-to-one relationship between SSL/TLS session peer and Sequence peer constrains the lifetime of aSSL/TLS-protected Sequence to be less than or equal to the lifetime of the SSL/TLS session that is usedto protect that Sequence.This specification does not preclude the use of other methods of using SSL/TLS to implement thecountermeasures (such as associating specific authentication information with a Sequence) although suchmethods are not covered by this document.Issues specific to the life-cycle management of SSL/TLS sessions (such as the resumption of a SSL/TLSsession) are outside the scope of this specification.5.2.2 SOAP Message SecurityThe mechanisms described in WS-Security may be used in various ways to implement thecountermeasures described in the previous sections. This specification advocates using the protocoldescribed by WS-SecureConversation [SecureConversation] (optionally in conjunction with WS-Trust[Trust]) as a mechanism for protecting Sequences. The use of WS-Security (as an underlying componentof WS-SecureConversation) is subject to the constraints defined in the Basic Security Profile 1.0.wsrm-1.1-spec-cd-08 29 March 2007Copyright © OASIS® 1993–2007. All Rights Reserved. OASIS trademark, IPR and other policies apply. Page 39 of 62


1385138613871388138913901391139213931394139513961397139813991400140114021403140414051406140714081409141014111412141314141415141614171418141914201421142214231424The description provided here is general in nature and is not intended to serve as a complete definition onthe use of WS-SecureConversation/WS-Trust to protect WS-RM. In order to interoperate implementationsneed to agree on the choice of features as well as the manner in which they will be used. Themechanisms described in the Web Services Security Policy Language MAY be used by services todescribe the requirements and constraints of the use of WS-SecureConversation.5.2.2.1 ModelThe basic model for using WS-SecureConversation is as follows:1 The RM Source and the RM Destination create a WS-SecureConversation security context. Thismay involve the participation of third parties such as a security token service. The tokensexchanged may contain authentication claims (e.g. X.509 certificates or Kerberos servicetickets).2 During the CreateSequence exchange, the RM Source SHOULD explicitly identify the securitycontext that will be used to protect the Sequence. This is done so that, in cases where theCreateSequence message is signed by more than one security context, the RM Source canindicate which security context should be used to protect the newly created Sequence.3 For the lifetime of the Sequence the RM Source and the RM Destination use the session key(s)associated with the security context to sign (as defined by WS-Security) at least the body andany relevant WS-RM-defined headers of any and all messages or faults that refer to thatSequence.5.2.2.2 Countermeasure ImplementationWithout relying upon any authentication information, the per-message signatures provide the necessaryintegrity qualities to counter the threats described in section 5.1.1.To implement the countermeasures described in section 5.1.2.1 some mutually agreed upon form ofauthentication claims must be provided by the RM Source to the RM Destination during the establishmentof the Security Context. These claims can then be used to determine if the RM Source is authorized tocreate a Sequence with the RM Destination.This specification advocates implementing the countermeasures described in section 5.1.3.2 by requiringan RM node's Sequence peer to be equivalent to their security context session peer. This allows theauthorization decisions described in section 5.1.3.2 to be based on the identity of the message's securitycontext rather than on any authentication claims that may have been established during security contextinitiation. Note that other methods of using WS-SecureConversation to implement the countermeasures(such as associating specific authentication claims to a Sequence) are possible but not covered by thisdocument.As with transport security, the requisite equivalence of a security context peer with a Sequence peer limitsthe lifetime of a Sequence to the lifetime of the protecting security context. Unlike transport security, theassociation between a Sequence and its protecting security context cannot always be establishedimplicitly at Sequence creation time. This is due to the fact that the CreateSequence andCreateSequenceResponse messages may be signed by more than one security context.Issues specific to the life-cycle management of WS-SecureConversation security contexts (such asamending or renewing contexts) are outside the scope of this specification.wsrm-1.1-spec-cd-08 29 March 2007Copyright © OASIS® 1993–2007. All Rights Reserved. OASIS trademark, IPR and other policies apply. Page 40 of 62


14251426142714281429143014311432143314341435143614371438143914401441144214431444144514461447144814491450145114521453145414551456145714581459146014611462146314641465146614671468146914706 Securing SequencesAs noted in section 5, the RM Source and RM Destination should be able to protect their sharedSequences against the threat of Sequence Spoofing attacks. There are a number of OPTIONAL means ofachieving this objective depending upon the underlying security infrastructure.6.1 Securing Sequences Using WS-SecurityOne mechanism for protecting a Sequence is to include a security token using awsse:SecurityTokenReference element from WS-Security (see section 9 in WS-SecureConversation) in the CreateSequence element. This establishes an association between thecreated (and, if present, offered) Sequence(s) and the referenced security token, such that the RM Sourceand Destination MUST use the security token as the basis for authorization of all subsequent interactionsrelated to the Sequence(s). The wsse:SecurityTokenReference explicitly identifies the token asthere may be more than one token on a CreateSequence message or inferred from the communicationcontext (e.g. transport protection).It is RECOMMENDED that a message independent referencing mechanism be used to identify the token,if the token being referenced supports such mechanism.The following exemplar defines the CreateSequence syntax when extended to include awsse:SecurityTokenReference: wsa:EndpointReferenceType xs:duration ? xs:anyURI wsa:EndpointReferenceType xs:duration ?wsrm:IncompleteSequenceBehaviorType ?... ?...... ?...The following describes the content model of the additional CreateSequence elements./wsrm:CreateSequence/wsse:SecurityTokenReferenceThis element uses the extensibility mechanism defined for the CreateSequence element(defined in section 3.4) to communicate an explicit reference to the security token, using awsse:SecurityTokenReference as documented in WS-Security, that the RM Source andDestination MUST use to authorize messages for the created (and, if present, the offered)Sequence(s). All subsequent messages related to the created (and, if present, the offered)Sequence(s) MUST demonstrate proof-of-possession of the secret associated with the token(e.g., by using or deriving from a private or secret key).When a RM Source transmits a CreateSequence that has been extended to include awsse:SecurityTokenReference it SHOULD ensure that the RM Destination both understands andwsrm-1.1-spec-cd-08 29 March 2007Copyright © OASIS® 1993–2007. All Rights Reserved. OASIS trademark, IPR and other policies apply. Page 41 of 62


14711472147314741475147614771478147914801481148214831484148514861487148814891490149114921493149414951496149714981499150015011502150315041505150615071508150915101511151215131514151515161517will conform to the requirements listed above. In order to achieve this, the RM Source SHOULD includethe UsesSequenceSTR element as a SOAP header block within the CreateSequence message. Thiselement MUST include a soap:mustUnderstand attribute with a value of „true‟. Thus the RM Sourcecan be assured that a RM Destination that responds with a CreateSequenceResponse understandsand conforms with the requirements listed above. Note that an RM Destination understanding this headerdoes not mean that it has processed and understood any WS-Security headers, the fault behavior definedin WS-Security still applies.The following exemplar defines the UsesSequenceSTR syntax:The following describes the content model of the UsesSequenceSTR header block./wsrm:UsesSequenceSTRThis element SHOULD be included as a SOAP header block in CreateSequence messages thatuse the extensibility mechanism described above in this section. The soap:mustUnderstandattribute value MUST be „true‟. The receiving RM Destination MUST understand and correctlyimplement the extension described above or else generate a soap:MustUnderstand fault, thusaborting the requested Sequence creation.The following is an example of a CreateSequence message using thewsse:SecurityTokenReference extension and the UsesSequenceSTR header block:......http://Business456.com/serviceA/789...6.2 Securing Sequences Using SSL/TLSOne mechanism for protecting a Sequence is to bind the Sequence to the underlying SSL/TLS session(s).The RM Source indicates to the RM Destination that a Sequence is to be bound to the underlyingSSL/TLS session(s) via the UsesSequenceSSL header block. If the RM Source wishes to bind aSequence to the underlying SSL/TLS sessions(s) it MUST include the UsesSequenceSSL element as aSOAP header block within the CreateSequence message.The following exemplar defines the UsesSequenceSSL syntax:The following describes the content model of the UsesSequenceSSL header block./wsrm:UsesSequenceSSLThe RM Source MAY include this element as a SOAP header block of a CreateSequencemessage to indicate to the RM Destination that the resulting Sequence is to be bound to thewsrm-1.1-spec-cd-08 29 March 2007Copyright © OASIS® 1993–2007. All Rights Reserved. OASIS trademark, IPR and other policies apply. Page 42 of 62


151815191520152115221523152415251526SSL/TLS session that was used to carry the CreateSequence message. If included, the RMSource MUST mark this header with a soap:mustUnderstand attribute with a value of „true‟.The receiving RM Destination MUST understand and correctly implement the functionalitydescribed in section 5.2.1 or else generate a soap:MustUnderstand fault, thus aborting therequested Sequence creation.Note that the inclusion of the above header by the RM Source implies that all Sequence-relatedinformation (Sequence Lifecycle or Acknowledgment messages or Sequence-related faults) flowing fromthe RM Destination to the RM Source will be bound to the SSL/TLS session that is used to carry theCreateSequenceResponse message.wsrm-1.1-spec-cd-08 29 March 2007Copyright © OASIS® 1993–2007. All Rights Reserved. OASIS trademark, IPR and other policies apply. Page 43 of 62


15271528152915301531153215331534153515361537153815391540154115421543154415451546154715481549155015511552155315541555155615571558155915601561156215631564156515661567156815691570157115721573157415751576157715781579158015811582Appendix A. SchemaThe normative schema that is defined for WS-ReliableMessaging using [XML-Schema Part1] and [XML-Schema Part2] is located at:http://docs.oasis-open.org/ws-rx/wsrm/200702/wsrm-1.1-schema-200702.xsdThe following copy is provided for reference.


1583158415851586158715881589159015911592159315941595159615971598159916001601160216031604160516061607160816091610161116121613161416151616161716181619162016211622162316241625162616271628162916301631163216331634163516361637163816391640164116421643164416451646maxOccurs="unbounded"/>This type is for elements whose [children] is an anyURI and can havearbitrary attributes.


1647164816491650165116521653165416551656165716581659166016611662166316641665166616671668166916701671167216731674167516761677167816791680168116821683168416851686168716881689169016911692169316941695169616971698169917001701170217031704170517061707170817091710maxOccurs="unbounded"/>It is the authors intent that this extensibility be used totransfer a Security Token Reference as defined in WS-Security.


1711171217131714171517161717171817191720172117221723172417251726172717281729173017311732173317341735173617371738173917401741174217431744174517461747174817491750175117521753175417551756175717581759176017611762176317641765176617671768176917701771177217731774maxOccurs="unbounded"/>wsrm-1.1-spec-cd-08 29 March 2007Copyright © OASIS® 1993–2007. All Rights Reserved. OASIS trademark, IPR and other policies apply. Page 47 of 62


1775177617771778177917801781178217831784178517861787wsrm-1.1-spec-cd-08 29 March 2007Copyright © OASIS® 1993–2007. All Rights Reserved. OASIS trademark, IPR and other policies apply. Page 48 of 62


178817891790179117921793179417951796179717981799180018011802180318041805180618071808180918101811181218131814181518161817181818191820182118221823182418251826182718281829183018311832183318341835183618371838183918401841Appendix B. WSDLThis WSDL describes the WS-RM protocol from the point of view of an RM Destination. In the case wherean endpoint acts both as an RM Destination and an RM Source, note that additional messages may bepresent in exchanges with that endpoint.Also note that this WSDL is intended to describe the internal structure of the WS-RM protocol, and will notgenerally appear in a description of a WS-RM-capable Web service. See WS-RM Policy [WS-RM Policy]for a higher-level mechanism to indicate that WS-RM is engaged.The normative WSDL 1.1 definition for WS-ReliableMessaging is located at:http://docs.oasis-open.org/ws-rx/wsrm/200702/wsrm-1.1-wsdl-200702.wsdlThe following non-normative copy is provided for reference.


18421843184418451846184718481849185018511852185318541855185618571858185918601861wsam:Action="http://docs.oasis-open.org/wsrx/wsrm/200702/CreateSequenceResponse"/>wsrm-1.1-spec-cd-08 29 March 2007Copyright © OASIS® 1993–2007. All Rights Reserved. OASIS trademark, IPR and other policies apply. Page 50 of 62


18621863186418651866186718681869187018711872187318741875187618771878187918801881188218831884188518861887188818891890189118921893189418951896189718981899190019011902190319041905190619071908190919101911Appendix C. Message ExamplesAppendix C.1 Create SequenceCreate Sequencehttp://Business456.com/guid/0baaf88d-483b-4ecf-a6d8-a7c2eb546817http://example.com/serviceB/123http://docs.oasis-open.org/wsrx/wsrm/200702/CreateSequencehttp://Business456.com/serviceA/789http://Business456.com/serviceA/789Create Sequence Responsehttp://Business456.com/serviceA/789http://Business456.com/guid/0baaf88d-483b-4ecf-a6d8a7c2eb546817http://docs.oasis-open.org/ws-rx/wsrm/200702/CreateSequenceResponsehttp://Business456.com/RM/ABCAppendix C.2 Initial TransmissionThe following example WS-ReliableMessaging headers illustrate the message exchange in the abovefigure. The three messages have the following headers; the third message is identified as the lastmessage in the Sequence:wsrm-1.1-spec-cd-08 29 March 2007Copyright © OASIS® 1993–2007. All Rights Reserved. OASIS trademark, IPR and other policies apply. Page 51 of 62


191219131914191519161917191819191920192119221923192419251926192719281929193019311932193319341935193619371938193919401941194219431944194519461947194819491950195119521953195419551956195719581959196019611962196319641965196619671968196919701971Message 1http://Business456.com/guid/71e0654e-5ce8-477b-bb9d-34f05cfcbc9ehttp://example.com/serviceB/123http://Business456.com/serviceA/789http://example.com/serviceB/123/requesthttp://Business456.com/RM/ABC1Message 2http://Business456.com/guid/daa7d0b2-c8e0-476e-a9a4-d164154e38dehttp://example.com/serviceB/123http://Business456.com/serviceA/789http://example.com/serviceB/123/requesthttp://Business456.com/RM/ABC2Message 3http://Business456.com/guid/0baaf88d-483b-4ecf-a6d8-a7c2eb546819http://example.com/serviceB/123http://Business456.com/serviceA/789http://example.com/serviceB/123/requestwsrm-1.1-spec-cd-08 29 March 2007Copyright © OASIS® 1993–2007. All Rights Reserved. OASIS trademark, IPR and other policies apply. Page 52 of 62


1972197319741975197619771978197919801981198219831984198519861987198819891990199119921993199419951996199719981999200020012002200320042005200620072008200920102011201220132014201520162017201820192020202120222023202420252026http://Business456.com/RM/ABC3http://Business456.com/RM/ABCAppendix C.3 First AcknowledgementMessage number 2 has not been accepted by the RM Destination due to some transmission error so itresponds with an Acknowledgement for messages 1 and 3:http://example.com/guid/0baaf88d-483b-4ecf-a6d8-a7c2eb546810http://Business456.com/serviceA/789http://example.com/serviceB/123http://docs.oasis-open.org/ws-rx/wsrm/200702/SequenceAcknowledgementhttp://Business456.com/RM/ABCAppendix C.4 RetransmissionThe RM Sourcediscovers that message number 2 was not accepted so it resends the message andrequests an Acknowledgement:http://Business456.com/guid/daa7d0b2-c8e0-476e-a9a4-d164154e38dehttp://example.com/serviceB/123http://Business456.com/serviceA/789http://example.com/serviceB/123/requestwsrm-1.1-spec-cd-08 29 March 2007Copyright © OASIS® 1993–2007. All Rights Reserved. OASIS trademark, IPR and other policies apply. Page 53 of 62


2027202820292030203120322033203420352036203720382039204020412042204320442045204620472048204920502051205220532054205520562057205820592060206120622063206420652066206720682069207020712072207320742075207620772078207920802081208220832084http://Business456.com/RM/ABC2http://Business456.com/RM/ABCAppendix C.5 TerminationThe RM Destination now responds with an Acknowledgement for the complete Sequence which can thenbe terminated:http://example.com/guid/0baaf88d-483b-4ecf-a6d8-a7c2eb546811http://Business456.com/serviceA/789http://example.com/serviceB/123http://docs.oasis-open.org/ws-rx/wsrm/200702/SequenceAcknowledgementhttp://Business456.com/RM/ABCTerminate Sequencehttp://Business456.com/guid/0baaf88d-483b-4ecf-a6d8-a7c2eb546812http://example.com/serviceB/123http://docs.oasis-open.org/ws-rx/wsrm/200702/TerminateSequencehttp://Business456.com/serviceA/789http://Business456.com/RM/ABC 3 wsrm-1.1-spec-cd-08 29 March 2007Copyright © OASIS® 1993–2007. All Rights Reserved. OASIS trademark, IPR and other policies apply. Page 54 of 62


2085208620872088208920902091209220932094209520962097209820992100210121022103210421052106210721082109211021112112Terminate Sequence Responsehttp://Business456.com/guid/0baaf88d-483b-4ecf-a6d8-a7c2eb546813http://example.com/serviceA/789http://docs.oasis-open.org/ws-rx/wsrm/200702/TerminateSequenceResponsehttp://Business456.com/guid/0baaf88d-483b-4ecf-a6d8-a7c2eb546812http://Business456.com/serviceA/789http://Business456.com/RM/ABCwsrm-1.1-spec-cd-08 29 March 2007Copyright © OASIS® 1993–2007. All Rights Reserved. OASIS trademark, IPR and other policies apply. Page 55 of 62


21132114211521162117Appendix D. State TablesThis appendix specifies the non-normative state transition tables for RM Source and RM Destination.The state tables describe the lifetime of a sequence in both the RM Source and the RM DestinationLegend:The first column of these tables contains the motivating event and has the following format:Event 2118Event name[source]2119Where:{ref}2120212121222123212421252126Event Name: indicates the name of the event. Event Names surrounded by “” are optional asdescribed by the specification.[source]: indicates the source of the event; one of:o [msg] a Received messageo [int]: an internal event such as the firing of a timero [app]: the applicationo [unspec]: the source is unspecified2127Each event / state combination cell in the tables in this appendix has the following format:State NameAction to take[next state]{ref}212821292130213121322133Where:action to take: indicates that the state machine performs the following action. Actions surroundedby “” are optional as described by the specification. “Xmit” is used as a short form for the word“Transmit”[next state]: indicates the state to which the state machine will advance upon the performance ofthe action. For ease of reading the next state “same” indicates that the state does not change.2134213521362137213821392140 {ref} is a reference to the document section describing the behavior in this cell“N/A” in a cell indicates a state / event combination self-inconsistent with the state machine; should theseconditions occur, it would indicate an implementation error. A blank cell indicates that the behavior is notdescribed in this specification and does not indicate normal protocol operation. Implementations MAYgenerate a Sequence Terminated fault (see section 4.2) in these circumstances. Robust implementationsMUST be able to operate in a stable manner despite the occurrence of unspecified event / statecombinations.wsrm-1.1-spec-cd-08 29 March 2007Copyright © OASIS® 1993–2007. All Rights Reserved. OASIS trademark, IPR and other policies apply. Page 56 of 62


2141Table 1 RM Source Sequence State Transition TableEventsSequence StatesNone Creating Created Closing Closed TerminatingCreate Sequence[unspec]{3.4}Create SequenceResponse[msg]{3.4)Create SequenceRefused Fault[msg]{3.4}Xmit CreateSequence[Creating]{3.4}N/A N/A N/A N/A N/AProcessCreateSequenceResponse[Created]{3.4}No action[None]{4.6}Send message[app]{2.1}N/A N/A Xmit message[Same]{2}No action[Same]{2}N/AN/ARetransmit of unack’dmessage[int]N/A N/A Xmit message[Same]{2.3}Xmit message[Same]{2.3}N/AN/ASeqAck (non-final)[msg]{3.9}GenerateUnknownSequenceFault[Same]{4.3}GenerateUnknownSequenceFault[Same]{4.3}Process Ackranges[Same]{3.9}Process Ackranges[Same]{3.9}Process Ackranges[Same]{3.9}Process Ackranges[Same]{3.9}Nack[msg]{3.9)GenerateUnknownSequenceFault[Same]{4.3}GenerateUnknownSequenceFault[Same]{4.3}[Same]{3.9}[Same]{3.9}No action[Same]No action[Same]Message NumberRollover Fault[msg]GenerateUnknownSequenceFault[Same]{4.3}GenerateUnknownSequenceFault[Same]{4.3}No action[Rollover]No action[Same]No action[Same]No action[Same]CloseSequence[msg]{3.5}GenerateUnknownSequenceFault[Same]{4.3}GenerateUnknownSequenceFault[Same]{4.3}XmitCloseSequenceResponse[Closed]{3.5}XmitCloseSequenceResponse[Closed]{3.5}XmitCloseSequenceResponse[Closed]{3.5}GenerateUnknownSequence Fault[Same]{4.3}[int]{3.5}N/AXmit CloseSequence[Closing]{3.5}N/A N/A N/AClose SequenceResponse[msg]{3.5}GenerateUnknownSequenceFault[Same]{4.3}GenerateUnknownSequenceFault[Same]{4.3}No action[Closed]{3.5}No action[Same]{3.5}No action[Same]{3.5}wsrm-1.1-spec-cd-08 29 March 2007Copyright © OASIS® 1993–2007. All Rights Reserved. OASIS trademark, IPR and other policies apply. Page 57 of 62


EventsSequence StatesNone Creating Created Closing Closed TerminatingSeqAck (final)[msg]{3.9}GenerateUnknownSequenceFault[Same]{4.3}GenerateUnknownSequenceFault[Same]{4.3}Process Ackranges[Closed]{3.9}Process Ackranges[Closed]{3.9}Process Ackranges[Same]Process Ackranges[Same]Sequence ClosedFault[msg]{4.7}GenerateUnknownSequenceFault[Same]{4.3}GenerateUnknownSequenceFault[Same]{4.3}No action[Closed]{4.7}No action[Closed]{4.7}No action[Same]No action[Same]Unknown SequenceFault[msg]{4.3}TerminateSequence[None]{4.3}TerminateSequence[None]{4.3}TerminateSequence[None]{4.3}TerminateSequence[None]{4.3}SequenceTerminated Fault[msg]{4.2}N/ATerminateSequence[None]{4.2}TerminateSequence[None]{4.2}TerminateSequence[None]{4.2}TerminateSequence[None]{4.2}TerminateSequence[msg]{3.6}GenerateUnknownSequenceFault[Same]{4.3}GenerateUnknownSequenceFault[Same]{4.3}Xmit TerminateSequenceResponse[None]{3.6}Xmit TerminateSequenceResponse[None]{3.6}Xmit TerminateSequenceResponse[None]{3.6}GenerateUnknownSequence Fault[Same]{4.3}TerminateSequence[int]N/ANo action[None]{unspec}Xmit TerminateSequence[Terminating]Xmit TerminateSequence[Terminating]Xmit TerminateSequence[Terminating]N/ATerminateSequenceResponse[msg]GenerateUnknownSequenceFault[Same]{4.3}GenerateUnknownSequenceFault[Same]{4.3}TerminateSequence[None]{3.6}Expires exceeded[int]N/ATerminateSequence[None]{3.7}TerminateSequence[None]{3.7}TerminateSequence[None]{3.7}TerminateSequence[None]{3.7}TerminateSequence[None]{3.7}InvalidAcknowledgement[msg]{4.4]GenerateUnknownSequenceFault[Same]{4.3}GenerateUnknownSequenceFault[Same]{4.3}Generate InvalidAcknowledgement Fault[Same]{4.4}Generate InvalidAcknowledgement Fault[Same]{4.4}Generate InvalidAcknowledgement Fault[Same]{4.4}Generate InvalidAcknowledgement Fault[Same]{4.4}2142Table 2 RM Destination Sequence State Transition TableEventsSequence StatesNone Created Closed TerminatingCreateSequence(successful)[msg/int]{3.4}Xmit Create SequenceResponse[Created]{3.4}N/AN/Awsrm-1.1-spec-cd-08 29 March 2007Copyright © OASIS® 1993–2007. All Rights Reserved. OASIS trademark, IPR and other policies apply. Page 58 of 62


EventsSequence StatesNone Created Closed TerminatingCreateSequence(unsuccessful)[msg/int]{3.4}Generate CreateSequence Refused Fault[None]{3.4}N/AN/AMessage (with messagenumber within range)[msg]Generate UnknownSequence Fault[Same]{4.3}Accept Message;[Same]Generate SequenceClosed Fault (withSeqAck+Final)[Same]{3.5}Generate SequenceTerminated Fault[Same]{4.2}Message (with messagenumber outside of range)[msg]Generate UnknownSequence Fault[Same]{4.3}Xmit Message NumberRollover Fault[Same]{3.7}{4.5}Generate SequenceClosed Fault (withSeqAck+Final)[Same]{3.5}Generate SequenceTerminated Fault[Same]{4.2}[msg]{3.8}Generate Unknown SeqFault[Same]{4.3}Xmit SeqAck[Same]{3.8}Xmit SeqAck+Final[Same]{3.9}Generate SequenceTerminated Fault[Same]{4.2}CloseSequence[msg]{3.5}Generate UnknownSequence Fault[Same]{4.3}Xmit CloseSequenceResponse withSeqAck+Final[Closed]{3.5}Xmit CloseSequenceResponse withSeqAck+Final[Closed]{3.5}Generate SequenceTerminated Fault[Same]{4.2}[int]Xmit CloseSequencewith SeqAck+Final[Closed]{3.5}Xmit CloseSequencewith SeqAck+Final[Same]{3.5}CloseSequenceResponse[msg]{3.5}Generate UnknownSequence Fault[Same]{4.3}No Action[Closed]{3.5}Generate SequenceTerminated Fault[Same]{4.2}TerminateSequence[msg]{3.6)Generate UnknownSequence Fault[Same]{4.3}Xmit TerminateSequence Response[None]{3.6}Xmit TerminateSequence Response[None]{3.6}Xmit TerminateSequence Response[None]{3.6}[int]XmitTerminateSequencewith SeqAck+Final[Terminating]{3.6}XmitTerminateSequencewith SeqAck+Final[Terminating]{3.6}XmitTerminateSequencewith SeqAck+Final[Terminating]{3.6}TerminateSequenceResponse[msg]Generate UnknownSequence Fault[Same]{4.3}Terminate Sequence[None]UnknownSequence Fault[msg]{4.3}Terminate Sequence[None]{4.3}Terminate Sequence[None]{4.3}Terminate Sequence[None]{4.3}SequenceTerminated Fault[msg]{4.2}Terminate Sequence[None]{4.2}Terminate Sequence[None]{4.2}Terminate Sequence[None]{4.3}Invalid AcknowledgementFault[msg]{4.4}N/AExpires exceeded[int]N/ATerminate Sequence[None]Terminate Sequence[None]wsrm-1.1-spec-cd-08 29 March 2007Copyright © OASIS® 1993–2007. All Rights Reserved. OASIS trademark, IPR and other policies apply. Page 59 of 62


EventsSequence StatesNone Created Closed Terminating{3.4} {3.4}[int]{3.9}N/AXmit SeqAck[Same]{3.9}Xmit SeqAck+Final[Same]{3.9}Non WSRM message whenWSRM required[msg]{4.8}GenerateWSRMRequired Fault[Same]{4.8}GenerateWSRMRequired Fault[Same]{4.8}GenerateWSRMRequired Fault[Same]{4.8}wsrm-1.1-spec-cd-08 29 March 2007Copyright © OASIS® 1993–2007. All Rights Reserved. OASIS trademark, IPR and other policies apply. Page 60 of 62


21432144214521462147214821492150215121522153215421552156215721692170217121722173217421752176217721782179218021812182218321972198219922002201220222032204220522062207220822092210221122122213221422152216Appendix E. AcknowledgmentsThis document is based on initial contribution to OASIS WS-RX Technical Committee by the followingauthors:Ruslan Bilorusets, BEA2158 Amelia Lewis, TIBCO SoftwareDon Box, Microsoft2159 Rodney Limprecht, MicrosoftLuis Felipe Cabrera, Microsoft 2160 Steve Lucco, MicrosoftDoug Davis, IBM2161 Don Mullen, TIBCO SoftwareDonald Ferguson, IBM2162 Anthony Nadalin, IBMChristopher Ferris, IBM2163 Mark Nottingham, BEATom Freund. IBM2164 David Orchard, BEAMary Ann Hondo, IBM2165 Jamie Roots, IBMJohn Ibbotson, IBM2166 Shivajee Samdarshi, TIBCO SoftwareLei Jin, BEA2167 John Shewchuk, MicrosoftChris Kaler, Microsoft2168 Tony Storey, IBMDavid Langworthy-Editor, MicrosoftThe following individuals have provided invaluable input into the initial contribution:Keith Ballinger, Microsoft2184 David Ingham, MicrosoftStefan Batres, Microsoft2185 Gopal Kakivaya, MicrosoftRebecca Bergersen, Iona2186 Johannes Klein, MicrosoftAllen Brown, Microsoft2187 Frank Leymann, IBMMichael Conner, IBM2188 Martin Nally, IBMGeorge Copeland, Microsoft2189 Peter Niblett, IBMFrancisco Curbera, IBM2190 Jeffrey Schlimmer, MicrosoftPaul Fremantle, IBM2191 James Snell, IBMSteve Graham, IBM2192 Keith Stobie, MicrosoftPat Helland, Microsoft2193 Satish Thatte, MicrosoftRick Hill, Microsoft2194 Stephen Todd, IBMScott Hinkelman, IBM2195 Sanjiva Weerawarana, IBMTim Holloway, IBM2196 Roger Wolter, MicrosoftEfim Hudis, MicrosoftThe following individuals were members of the committee during the development of this specification:Abbie Barbir, Nortel2217 Robert Freund, HitachiCharlton Barreto, Adobe2218 Peter Furniss, EreborStefan Batres, Microsoft2219 Marc Goodner, MicrosoftHamid Ben Malek, Fujitsu2220 Alastair Green, ChoreologyAndreas Bjarlestam, Ericsson 2221 Mike Grogan, SunToufic Boubez, Layer 72222 Ondrej Hrebicek, MicrosoftDoug Bunting, Sun2223 Kazunori Iwasa, FujitsuLloyd Burch, Novell2224 Chamikara Jayalath, WSO2Steve Carter, Novell2225 Lei Jin, BEAMartin Chapman, Oracle2226 Ian Jones, BTplcDave Chappell, Sonic2227 Anish Karmarkar, OraclePaul Cotton, Microsoft2228 Paul Knight, NortelGlen Daniels, Sonic2229 Dan Leshchiner, TibcoDoug Davis, IBM2230 Mark Little, JBossBlake Dournaee, Intel2231 Lily Liu, webMethodsJacques Durand, Fujitsu2232 Matt Lovett, IBMColleen Evans, Microsoft2233 Ashok Malhotra, OracleChristopher Ferris, IBM2234 Jonathan Marsh, MicrosoftPaul Fremantle, WSO22235 Daniel Millwood, IBMwsrm-1.1-spec-cd-08 29 March 2007Copyright © OASIS® 1993–2007. All Rights Reserved. OASIS trademark, IPR and other policies apply. Page 61 of 62


223622372238223922402241224222432244224522462257Jeff Mischkinsky, OracleNilo Mitra, EricssonPeter Niblett, IBMDuane Nickull, AdobeEisaku Nishiyama, HitachiDave Orchard, BEAChouthri Palanisamy, NECSanjay Patil, SAPGilbert Pilz, BEAMartin Raepple, SAPEric Rajkovic, Oracle2247224822492250225122522253225422552256Stefan Rossmanith, SAPTom Rutt, FujitsuRich Salz, IBMShivajee Samdarshi, TibcoVladimir Videlov, SAPClaus von Riegen, SAPPete Wenzel, SunSteve Winkler, SAPÜmit Yalçinalp, SAPNobuyuki Yamamoto, Hitachiwsrm-1.1-spec-cd-08 29 March 2007Copyright © OASIS® 1993–2007. All Rights Reserved. OASIS trademark, IPR and other policies apply. Page 62 of 62

More magazines by this user
Similar magazines