RE: Questions prompted by the publication of WS-ReliableMessaging

I think that companies working on WS-ReliableMessaging bodes well for the
widespread adoption of an sigle, open, RF, interoperable reliability
specification that architects well with other Web service specifications.  
 
What I'm really surprised by is the pushback that people are giving on the
possibility that ws-rm won't automatically go to the oasis ws-reliability
TC.   One of the biggest differences between the W3C and OASIS is that the
W3C has a community review process for new working groups.  The goal at the
W3C being to have a charter for a working group that all the W3C Members can
live with and is technically consistent with other works in progress.
Indeed, the work that the W3C Team and member companies do to come up with
such a charter and then the 4 week AC review period are the biggest
contributors to the length of time to form a Working Group, IMO.  OASIS has
no such intent or process.   
 
If you like forming WG's quickly, you can't ALSO want there to be consensus
in the industry around a single Working Group and it's charter.  Time to
market or consensus, pick one.  
 
Continuing the community review of charters a little further, TC's can
arbitrarily change their charter without a community review.  The IP issues
around changes in charters alone gives me the willies, like how the heck do
you do early IP disclosure if the charter can change???
 
Further, individual members of OASIS don't treat TC formation as a "first to
pole wins" wrt charters.  OASIS provides a place for like minded individuals
to do work.  It has no structure for insisting on consistency or
relationship between TCs or other groups.  Though such is certainly
permitted, pending whether the individuals choose to.  
 
Surely these differences in processes and their plus and minues have been
obvious for years now and people shouldn't be surprised by what can happen,
or that it automatically means something *bad* for Web services.  If people
have reservations about the OASIS process, then talking about it on w3c
ws-arch seems like it would need to get moved off of the w3c pretty fast.
I'm ok with talking about the impact of various processes on web services
architecture for a while, but it's probably something that needs to be
wrapped up quickly.  Finally, people seem to like the OASIS process as lots
of work is being done there.  
 
Cheers,
Dave

-----Original Message-----
From: www-ws-arch-request@w3.org [mailto:www-ws-arch-request@w3.org]
Sent: Saturday, March 15, 2003 2:34 PM
To: www-ws-arch-request@w3.org; www-ws-arch-request@w3.org; 'Ugo Corda';
www-ws-arch@w3.org
Subject: RE: Questions prompted by the publication of WS-ReliableMessaging


There are differences. The primary difference that I see (after a quick
glance) is that WS-ReliableMessaging relies on/works with WS-Policy and the
other GXA specifications. WS-Reliability is a standalone SOAP extension.
Also, WS-ReliableMessaging has defined Addressability separately (which
decouples asynchronicity from reliability). I think that
WS-ReliableMessaging and WS-Addressability are better, more flexible, more
thorough, more comprehensive specifications. Even so, the specs address
exactly the same problem space. 
 
The primary difference is political. The authors of WS-ReliableMessaging
have not signed up to participate in the WS-RM TC. I'm not sure that it's a
given that the authors will submit it to the WS-RM TC. I'd say that it bodes
badly for the standardization effort. 
 
Anne

-----Original Message-----
From: www-ws-arch-request@w3.org [mailto:www-ws-arch-request@w3.org]
Sent: Saturday, March 15, 2003 4:05 PM
To: www-ws-arch-request@w3.org; 'Ugo Corda'; www-ws-arch@w3.org
Subject: RE: Questions prompted by the publication of WS-ReliableMessaging


I agree with Ugo. Reading through the abstract it's obvious that we have two
specifications that solve the same problem. Is there a value in that?
 
I actually dug deeper into the specs and I can tell that there are some
differences. But most of us don't have the time to compare green apples to
red apples. It would have been much easier if someone could present a list
of the difference. If WS-ReliableMessaging does something better than WS-RM
then clearly it could be summarized in two pages and presented to the WS
community so we can judge.
 
Maybe they are so different that we need to have both. I don't see that, but
a more educated explanation would help. Maybe the changes are minor, in
which case such a comparison could help the OASIS TC in addressing the
problem of reliable messaging in a much better way.
 
Am I the only one interested in seeing such a comparison?
 
arkin

-----Original Message-----
From: www-ws-arch-request@w3.org [mailto:www-ws-arch-request@w3.org]
Sent: Saturday, March 15, 2003 12:46 PM
To: 'Ugo Corda'; www-ws-arch@w3.org
Subject: RE: Questions prompted by the publication of WS-ReliableMessaging


I suggest you need to read the specs slower rather than quicker :-)

-----Original Message-----
From: www-ws-arch-request@w3.org [mailto:www-ws-arch-request@w3.org]On
Behalf Of Ugo Corda
Sent: Saturday, March 15, 2003 12:44 PM
To: www-ws-arch@w3.org
Subject: Questions prompted by the publication of WS-ReliableMessaging



Probably most people in the group have had a chance by now to see this
week's announcement of the publication of WS-ReliableMessaging (see [1]).

After a quick reading of the spec, I have to say that I don't see any major
architectural/technical differences compared to the OASIS
WS-ReliableMessaging TC activity and its input document WS-Reliability (or
at least differences big enough to justify going a completely separate way).


I really hope that some WSA members whose companies published the new
reliability spec can help me clarify the previous point and provide some
architectural/technical rationale for the separate publication.

Thank you, 
Ugo 

P.S. No need to answer if the rationale for publication is a political one
(I can figure that out by myself ...). 

[1] http://xml.coverpages.org/ni2003-03-13-a.html
<http://xml.coverpages.org/ni2003-03-13-a.html>