W3C home > Mailing lists > Public > www-ws-arch@w3.org > August 2002

Re: Champions for Draft-status requirements? / D-AC017

From: Geoff Arnold <Geoff.Arnold@Sun.COM>
Date: Tue, 27 Aug 2002 15:59:59 -0400
To: www-ws-arch@w3.org
Message-id: <90EE36C4-B9F7-11D6-8830-000393991304@sun.com>

A couple of comments on D-AC017.

It seems to me that there is a slight disconnect between the
critical success factor and some of the requirements. D-AR017.1
addresses "common business functions" fairly generically, but
D-AR017.2-4 dive straight into technological requirements
which, while attractive from a "distributed computing best
practices" standpoint, are not clearly related to "common
business functions".

[I'm about to do something that I generally deplore: criticize
a draft text without offering an alternative. My excuse is that
I have not read the prior discussion of this CSF, and so
I would prefer to see if I've understood things correctly
*before* I offer some text.]

To be internally self-consistent, I think that D-AC017
needs to be revised so that the various AR's explicitly
address the AC's "common business functions". Thus instead of
reliable messaging, sequence numbers, and transactions it
would seem more logical to talk about advertising, requiring,
negotiating and selecting explicit quality of service factors
such as verifiable delivery and acknowledgment, non-repudiation,
and so forth. (This would also remove a slight ambiguity
between "support" and "require" in the existing language.)

I suspect that the lack of enthusiasm for D-AC017 may stem
from a feeling that in order to support it one would
have to accept some responsibility for fixing it....


On Tuesday, August 27, 2002, at 03:24  PM, Cutler, Roger (RogerCutler) 

> Mike has asked me to repeat, or refer to, my previous posting on 
> D-AC017
> (http://lists.w3.org/Archives/Public/www-ws-arch/2002Aug/0229.html).  
> The
> bottom line is that my reading of the "sense of the workgroup" is that
> D-AC017 as a whole should probably go away.  HOWEVER, if this happens 
> there
> would be no mention whatsoever in the requirements doc of reliable 
> messaging
> and I think that would be a "VERY BAD THING".  So I am proposing 
> replacing
> D-AC017 with some statement that says something about reliable 
> messaging
> which might appear on its own or under another heading (like perhaps 
> AC-006,
> "security" --> "security and reliability" ??).
> Here is D-AC017:
> D-AC017 provides guidance for the development of the Web services
> infrastructure needed to implement common business functions in a
> standards-based environment.
> D-AR017.1 The Web services Architecture must support common business
> functions, to the extent that those functions are defined in similar
> methodologies such as EDI.
> D-AR017.2 The Web services Architecture must support reliable 
> messaging and
> routing.
> D-AR017.3 The Web services Architecture must support unique message 
> IDs and
> message sequencing.
> D-AR017.4 The Web services Architecture must support reliable 
> transaction
> processing.
> Copying from the previous posting:
> 1 - I believe that I was the champion of this Critical Success Factor.
> 2 - I recall that I got a chance to make a case for the AC and, 
> although the
> general idea that web services should do something along these lines is
> popular, there was very little positive response for these specific 
> AC's.  I
> believe that the feeling was that they are stated in a way that does 
> not
> mesh well with other requirements and that the objectives are really 
> covered
> in the Usage Cases.
> 3 - Since there was talk on the last con-call of "for-sure" getting the
> requirements finished at the F2F, and there was support for the 
> concept of
> "if we can't agree drop it" -- or something along these lines -- I 
> think
> that there is a good chance that all of D-AC017 is headed for oblivion.
> My personal reaction, as the "champion", is that I still like D-AC017
> because it accurately and succinctly expresses what my personal major
> success criterion is for the WG.  However, I feel that I had my chance 
> to
> make my case, was listened to and did not obviously convince anybody.  
> Under
> those circumstances I am hardly likely to object to it being dropped, 
> and in
> fact I would propose it myself.
> Soooo -- one thing I am saying is:  IF YOU REALLY LIKE D-AC017 YOU'D 
> But there is another potential issue that I think may be much more
> important.  As the requirement document stands, D-AC017 is the ONLY 
> place
> that mentions "reliable messaging".  If it is dropped ... well, I don't
> think that it is reasonable for the requirements not to mention 
> reliable
> messaging at all.  I believe that it has been very commonly expressed 
> by
> many people in many forums that the two most important issues that 
> need to
> be resolved in order to use web services in business settings are 
> getting
> agreement on how to handle security and reliable messaging.  I think 
> that
> reliable messaging MUST be mentioned somehow or the WG will lose 
> essential
> credibility.
> If D-AC017 is dropped I would be, if it's the best we can do, 
> satisfied with
> something like, "The working group MUST address the issue of reliable
> messaging", which would leave open such deeply unsatisfying solutions 
> as,
> "Reliable messaging is not possible," or "Reliable messaging is not a 
> part
> of web services architecture" -- but I really don't think that we can 
> just
> not mention it at all.
> -----Original Message-----
> From: Champion, Mike [mailto:Mike.Champion@SoftwareAG-USA.com]
> Sent: Thursday, August 22, 2002 2:32 PM
> To: www-ws-arch@w3.org
> Subject: Champions for Draft-status requirements?
> [snip]
> It looks like there are 4 goals with draft status, and
> three of those have CSF's with draft status associated
> with them: D-AC001, D-AC016, D-AC017, and D-AC018.
> Also, AC006 is agreed on, but some of its CSFs are
> still in draft status.
> It would be nice to have volunteers to take these
> on.  I would expect it to take about one hour for each
> to dig through the archives, look at the votes and
> comments, and propose a sensible resolution.
> [snip]
Received on Tuesday, 27 August 2002 16:00:00 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 23:05:36 UTC