Re: [wsrm] WS-Reliability and WS-ReliableMessaging

[Chiusano Joseph <chiusano_joseph@bah.com>]

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)
> --

GXA Presentation.ppt

begin:vcard 
n:Chiusano;Joseph
tel;work:(703) 902-6923
x-mozilla-html:FALSE
url:www.bah.com
org:Booz | Allen | Hamilton;IT Digital Strategies Team
adr:;;8283 Greensboro Drive;McLean;VA;22012;
version:2.1
email;internet:chiusano_joseph@bah.com
title:Senior Consultant
fn:Joseph M. Chiusano
end:vcard