WS-Reliability and WS-ReliableMessaging

David Chappell on WS-Reliability and WS-ReliableMessaging

Date:      Thu, 13 Mar 2003 23:18:38 -0500
From:      David Chappell <chappell@sonicsoftware.com>
To:        wsrm-TC <wsrm@lists.oasis-open.org>
Subject:   WS-Reliability and WS-ReliableMessaging

[Update 2005-04-19: The two specifications come closer together, at least in terms of hosting. BEA Systems, IBM, Microsoft, and TIBCO announced a decision to submit the "Web Services Reliable Messaging Protocol (WS-ReliableMessaging)" and "Web Services Reliable Messaging Policy Assertion (WS-RM Policy)" specifications to OASIS for further refinement and finalization as a Web services standard. Basic delivery assurances include AtMostOnce without duplication or error, AtLeastOnce, ExactlyOnce, and Messages delivered in the order they were sent. See details in "OASIS TC to Finalize WS-ReliableMessaging and WS-RM Policy Assertion Specifications."]

[March 13, 2005] I just read through the recently announced IBM/MS WS-ReliableMessaging spec and I have determined that its really not that different from WS-Reliability. For the most part, its one-for-one functionality-wise. Both specifications have things like and <AckRequested> tag, message ordering, and asynchronous processing. The recent press claims from the contributing vendors that WS-ReliableMessaging is better because it has ties to WS-Policy and WS-Security is not much more than hand-waving. Granted, it has sections in the spec for those things, but there's nothing there that's very profound. What WS-Reliability (and the rest of theworld) refer to as "SOAP Headers" are referred to as "WS-Policy Assertions" in WS-ReliableMessaging :). Granted, that's what WS-Policy is all about, but its all very subtle semantics. I 'm not saying that WS-Policy isn't a good idea for a set of specs, but at the moment it still needs to be considered proprietary. Also, the WS-Security section is a moderate set of recommendations for how things ought to be secure using WS-Security.

On the plus side for WS-ReliableMessaging, its got the notion of acknowledgement of a group sequence, where the acknowledgement message contains the high and low range of messages that have been acknowledged. There's a similar Fault mechanism. Pretty cool. WS-Reliability also has semantics and headers for dealing with groups and sequences but didn't do this group acknowledgement piece. We did all recognize that groups and sequences could get better but thought the current state was good enough foundation to form an OASIS Technical Committee and let the TC decide how to expand on it.

WS-ReliableMessaging has a mechanism for specifying a retry interval, with an exponential backoff on the retries. Its unclear why its something that would be set as a header by the sender although one could image it being there as information that the receiver might react to. WS-Reliability has a notion of send retries, yet refers to it as a "configurable option" and leaves it underspecified, but called out in the "issues" appendix.

Its also got something called an acknowledgement interval that is something the sender tells the receiver that its got a certain amount of time to acknowledge. While not explicitly stated, I could imagine this being used to batch up acknowledgements (I can't say if any of the authors imagined this).

These additional things are interesting, but don't add up to a superior messaging spec by any means. The WS-Reliability draft spec actually goes into more detail in some areas of message persistence semantics, and acknowledges that there is more work to be done there. It also explicitly calls out the need for duplicate elimination on the receiver side.

All this being said, the WS-RM TC's positioning on the state of the WS-Reliability spec shouldn't change. It has been the intent of the charter members all along to not dive deep into these issues, and wait for the formation of the TC to get the input from more people. The world only needs one of these specs, and I think this vendor fighting is only doing an injustice to the marketplace.

Dave

Sonic Software - Backbone of the Extended Enterprise

David Chappell <chappell@sonicsoftware.com> Office: (781)999-7099
Mobile: (617)510-6566
Vice President and Chief Technology Evangelist, Sonic Software
co-author,"Java Web Services", (O'Reilly 2002)
"The Java Message Service", (O'Reilly 2000)
"Professional ebXML Foundations", (Wrox 2001)

[Source: OASIS WSRM TC list archive]

Prepared by Robin Cover for The XML Cover Pages archive. See details in the news story: "New Web Services Specifications for Reliable Messaging and Addressing." Related references: (1) "OASIS Members Form Technical Committee for Web Services Reliable Messaging"; (2) "Reliable Messaging."

SEARCH Advanced Search ABOUT Site Map CP RSS Channel Contact Us Sponsoring CP About Our Sponsors NEWS Cover Stories Articles & Papers Press Releases CORE STANDARDS XML SGML Schemas XSL/XSLT/XPath XLink XML Query CSS SVG TECHNOLOGY REPORTS XML Applications General Apps Government Apps Academic Apps EVENTS LIBRARY Introductions FAQs Bibliography Technology and Society Semantics Tech Topics Software Related Standards Historic	WS-Reliability and WS-ReliableMessaging David Chappell on WS-Reliability and WS-ReliableMessaging Date: Thu, 13 Mar 2003 23:18:38 -0500 From: David Chappell <chappell@sonicsoftware.com> To: wsrm-TC <wsrm@lists.oasis-open.org> Subject: WS-Reliability and WS-ReliableMessaging [Update 2005-04-19: The two specifications come closer together, at least in terms of hosting. BEA Systems, IBM, Microsoft, and TIBCO announced a decision to submit the "Web Services Reliable Messaging Protocol (WS-ReliableMessaging)" and "Web Services Reliable Messaging Policy Assertion (WS-RM Policy)" specifications to OASIS for further refinement and finalization as a Web services standard. Basic delivery assurances include AtMostOnce without duplication or error, AtLeastOnce, ExactlyOnce, and Messages delivered in the order they were sent. See details in "OASIS TC to Finalize WS-ReliableMessaging and WS-RM Policy Assertion Specifications."] [March 13, 2005] I just read through the recently announced IBM/MS WS-ReliableMessaging spec and I have determined that its really not that different from WS-Reliability. For the most part, its one-for-one functionality-wise. Both specifications have things like and <AckRequested> tag, message ordering, and asynchronous processing. The recent press claims from the contributing vendors that WS-ReliableMessaging is better because it has ties to WS-Policy and WS-Security is not much more than hand-waving. Granted, it has sections in the spec for those things, but there's nothing there that's very profound. What WS-Reliability (and the rest of theworld) refer to as "SOAP Headers" are referred to as "WS-Policy Assertions" in WS-ReliableMessaging :). Granted, that's what WS-Policy is all about, but its all very subtle semantics. I 'm not saying that WS-Policy isn't a good idea for a set of specs, but at the moment it still needs to be considered proprietary. Also, the WS-Security section is a moderate set of recommendations for how things ought to be secure using WS-Security. On the plus side for WS-ReliableMessaging, its got the notion of acknowledgement of a group sequence, where the acknowledgement message contains the high and low range of messages that have been acknowledged. There's a similar Fault mechanism. Pretty cool. WS-Reliability also has semantics and headers for dealing with groups and sequences but didn't do this group acknowledgement piece. We did all recognize that groups and sequences could get better but thought the current state was good enough foundation to form an OASIS Technical Committee and let the TC decide how to expand on it. WS-ReliableMessaging has a mechanism for specifying a retry interval, with an exponential backoff on the retries. Its unclear why its something that would be set as a header by the sender although one could image it being there as information that the receiver might react to. WS-Reliability has a notion of send retries, yet refers to it as a "configurable option" and leaves it underspecified, but called out in the "issues" appendix. Its also got something called an acknowledgement interval that is something the sender tells the receiver that its got a certain amount of time to acknowledge. While not explicitly stated, I could imagine this being used to batch up acknowledgements (I can't say if any of the authors imagined this). These additional things are interesting, but don't add up to a superior messaging spec by any means. The WS-Reliability draft spec actually goes into more detail in some areas of message persistence semantics, and acknowledges that there is more work to be done there. It also explicitly calls out the need for duplicate elimination on the receiver side. All this being said, the WS-RM TC's positioning on the state of the WS-Reliability spec shouldn't change. It has been the intent of the charter members all along to not dive deep into these issues, and wait for the formation of the TC to get the input from more people. The world only needs one of these specs, and I think this vendor fighting is only doing an injustice to the marketplace. Dave Sonic Software - Backbone of the Extended Enterprise David Chappell <chappell@sonicsoftware.com> Office: (781)999-7099 Mobile: (617)510-6566 Vice President and Chief Technology Evangelist, Sonic Software co-author,"Java Web Services", (O'Reilly 2002) "The Java Message Service", (O'Reilly 2000) "Professional ebXML Foundations", (Wrox 2001) [Source: OASIS WSRM TC list archive] Prepared by Robin Cover for The XML Cover Pages archive. See details in the news story: "New Web Services Specifications for Reliable Messaging and Addressing." Related references: (1) "OASIS Members Form Technical Committee for Web Services Reliable Messaging"; (2) "Reliable Messaging."