[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [wsrm] WS-Reliability and WS-ReliableMessaging
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) --
begin:vcard n:Chappell;Dave tel;cell:617-510-6566 tel;work:781-999-7099 x-mozilla-html:FALSE url:www.sonicsoftware.com org:Sonic Software Corp. <BR><BR><a href="http://www.sonicsoftware.com/products/sonicmq/index.ssp"><img src="http://www.sonicsoftware.com/web/global/graphics/banner.gif"></a><BR><BR><A HREF="http://www.sonicsoftware.com/products/sonicxq.htm">Read about SonicXQ</A> - the first product to deliver <br>on the promise of the enterprise service bus.<BR> adr:;;14 Oak Park;Bedford;MA;01730;USA version:2.1 email;internet:chappell@sonicsoftware.com title:vice president & chief technology evangelist<a href="http://www.oreillynet.com/weblogs/author/207">[weblog]</a> fn:Dave Chappell end:vcard
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]