[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [wsrm] WS-Reliability and WS-ReliableMessaging
I think David is of course referring to WS-ReliableMessaging. Please use this link to get a look: ftp://www6.software.ibm.com/software/developer/library/ws-reliablemessaging.pdf Thanks Joseph for the additional material. Regards, Eugene -----Original Message----- From: Chiusano Joseph [mailto:chiusano_joseph@bah.com] Sent: Freitag, 14. März 2003 12:05 To: David Chappell Cc: wsrm-TC Subject: Re: [wsrm] WS-Reliability and WS-ReliableMessaging Thank you to David for this great information. I would like to make a clarification that what David is referring to is actually called "Global XML Web Services Architecture", or GXA - not WS-ReliableMessaging. GXA is comprised of (currently) 14 specifications (including WS-Security), with at least 3 more anticipated. The specifications are actually authored by Microsoft, with co-authorship by IBM, Verisign, BEA Systems, RSA Security, and SAP (in various combinations). I am giving a presentation on GXA at a conference Monday here in Washington D.C. [1]. I've attached my presentation for our reference (an earlier version of it has already been publicly posted somewhere). I am also writing an article on GXA for an online publication, to be published within the coming weeks. I will send a URL to the article as soon as it appears. Kind Regards, Joe Chiusano Booz | Allen | Hamilton [1] http://www.egovos.org/ David Chappell wrote: > > 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) > --
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]