OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsrm message

[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]