No Copyright Claimed Web Services Reliability Options A Comparison of Web Services Reliable Messaging Specifications OASIS WSRM TC

No Copyright Claimed Acknowledgement We thank the OASIS board of directors for this opportunity to respond to the IBM presentation made during the OASIS Web Services Reliable Infrastructure Symposium We thank all of the contributors who have provided comment or otherwise made their mark on the WS- Reliability Specification

No Copyright Claimed Reliable Delivery Choices At the moment there exist two WS options Proprietary: –IBM/BEA/Microsoft/Tibco authored WS- ReliableMessaging (“WS-RM”) Non Proprietary: –OASIS WSRM TC developed WS-Reliability (“WS-R”)

No Copyright Claimed Motivations for a Reliable Transport Underlying communications mechanism variety –High bandwidth, low latency, low short-term latency variance (Wired or Optical TCP/IP) –High latency variance, variable path delays (some grid architectures) –Wireless cdma and other (mobile devices) –Other “non traditional” mechanisms Growing potential for message loss, and message re- ordering Large Multi-message Web Services business interactions not adequately protected by lower level TCP characteristics

No Copyright Claimed Mechanisms Needed to Resolve: Guaranteed delivery –Unambiguous responsibility transfer from sender to receiver. Duplicate elimination –Retransmissions caused by loss of acknowledgement or other causes should not effect transmission integrity Message re-ordering –Messages offered to consumer in the order sent by producer to offset variable path length or retransmission after message loss Grouping –Associate collections of related messages into a coherent unit

No Copyright Claimed WS-R Use Cases Supported Request-Response (business message exchange) Polled receiver (firewall or device constraints) Long running group (logging model) Lightweight devices (cell phone and smaller) All are supported by WS-R with a common protocol respectful of implementation choices and resources Unclear how WS-RM supports many of these cases

No Copyright Claimed Benefits of WS-R over WS-RM No group establishment exchange –Reduced latency on every group No “nack” (negative acknowledgement) –Hazardous if used for missing messages in a sequence and could lead to congested network failure No reliance on external policy protocol to establish sender and receiver options –WS-R is self contained, more complete, and lighter weight –WS-R makes no assumptions of other pre-requisite protocols No reliance on proprietary addressing protocols WS-R supports a broad range of implementations with selectable quality of service

No Copyright Claimed Specific responses to IBM’s assertions During the Symposium there was not an adequate time provided to respond to IBM’s assertions. Each of the following slides responds to an assertion made during the IBM Presentation. WS-R has been open for public comment, and the TC has extended the comment period to include those made at the symposium. IBM has been welcome to participate from the beginnings of this effort and is still welcome should it desire constructive participation.

No Copyright Claimed IBM’s Assertion: Two Schemas and namespaces are unnecessary Agreed –WS-RM Spec will be edited to simply state that mustUnderstand attribute MUST be present

No Copyright Claimed IBM’s Assertion: Why are Soap Faults not used for RM-Fault? SOAP fault model does not provide for batching of faults Although possible to send a SOAP fault in an HTTP request, it is unusual to send a Fault in a request Allows piggy-backing fault on business messages.

No Copyright Claimed IBM’s Assertion: Ack on delivery causes delay All reliability contracts end at “Delivery” Delivery is defined as the point that the receiver has accepted responsibility for the message and potentially made it available to the application or some other consumer. Ack on Receipt vs Ack on delivery: message could be lost between receipt and delivery. How will the sender know it has not been delivered while still under reliability contract? Ack on Delivery: in most cases no delay between receipt and delivery. Even so, delay in Ack sending will only cause unnecessary resending if the resend policy not well tuned. In progress: Editorial updates to show delivery target can be more than just “application” (queuing, handler, database, etc.).

No Copyright Claimed IBM’s Assertion: Unclear if WS-R composes with WS-Addressing or WS-MD. Endpoint is represented as a uri TC desires composability with many other mechanisms, however the TC will not specify a proprietary mechanism nor will it specify one mechanism at the exclusion of others. WS-MD is being reviewed as a possibility, but that spec is new although promising. The TC will review the spec for extensibility in this regard.

No Copyright Claimed IBM’s Assertion: Persistence model precludes use on devices lacking non-volatile storage Both WS-R and WS-RM require equivalent levels of state storage during operation. Implementation references to persistent storage will be clarified. Although it is the intent that WS-R’s “ack on acceptance of responsibility” could imply some form of persistence in a truly reliable implementation, applications not requiring reliability across power failure events do not need to persist messages. If appropriate to the application, non-volatile storage is not required and if not implemented, reliability degrades to level consistent with WS-RM

No Copyright Claimed IBM’s Assertion: Mandatory expiry time requires synchronization of clocks Message expiry time is useful for garbage collection purposes and provides a mechanism to define when a message is “stale” Defines the limits of effort Lack of clock synchronization unless gross will not cause protocol problems. Recommendation is that expiry time be set large enough to allow for expected clock skews. Receiver implementations may safely extend message expiry time if the application desires local policy for garbage collection. Inspection of several other “WS” specifications demonstrates that explicit datetime is commonly used Application determined expiry time permits application flexibility and resource reclamation based on application need.

No Copyright Claimed IBM’s Assertion: WS-R has too big a “THUNK” factor WS-R does not use 8 point type ;-) Compared to WS-RM, WS-R is a more self-contained specification and does not include by reference many other specifications required for correct operation. Including the page count of the referenced specifications grows the WS-RM 28 (Microsoft version) - 40 (IBM version) pages claimed to over 117. THUNK is non-normative This is a silly issue. The spec needs to be big enough to be complete.

No Copyright Claimed IBM’s Assertion: WS-R is a complex spec with many occurrences of the word “if” Many of the uses of the word “if” are included in implementation guidance which will be moved to a non- normative companion document. A description of bits-on-the-wire alone does not adequately describe end point behavior. Many uses of the word “if” are included in detailed termination and error recovery discussions, an area we think is underspecified in WS-RM We expect many interoperable and independent implementations rather than just a few making exposition more important. If the word “if” is used in a manner to more completely explain or specify, then it is well used.

No Copyright Claimed IBM’s Assertion: Spec does not state that receiver must ack all delivered messages with each ack indication Required for the status-polling use case, acknowledgments are deferred until polled This is not supported by WS-RM. Acknowledgements can be on all members of the group The TC will clarify the language.

No Copyright Claimed IBM’s Assertion: Unnecessary implementation details in spec Several correspondents expressed appreciation for implementation guidance. The TC will segregate implementation guidance from “normative” specification producing a shorter spec document, however, implementation guidance will remain available.

No Copyright Claimed Conclusion We thank all participant for their input and efforts in the creation of WS-R We thank Chris Ferris for his comments Web Services future depends on commodity open specifications free of entanglements Imagine the drag that would have occurred if TCP/IP required a license. If Web Services implementations are constrained by license, FUD, or proprietary ownership its acceptance will be severely damaged We admonish you to make Web Services a commons enjoyable by all.