RE: [RTF] AC019 proposal to WSA WG

Well, it seems to me that "reliability solution" is a little vague and that
"reliable messaging" is what people really want.  I don't see why you see
the requirement of reliable messaging somehow imposing a given solution to
the requirement.  Perhaps the requirement is difficult or impossible to
satisfy fully, which along with defining partial solutions would be one
interesting result.  Or perhaps there is more than one way to satisfy it,
each with tradeoffs.  Or perhaps satisfying it has some inevitable negative
consequences, which is another interesting result.

I may be mistaken, but I am gathering that you are claiming that the last
alternative above is the case.  Wouldn't it be more productive either to
suggest alternative solutions to the requirement itself, or document the
limitations imposed by satisfying it, than to resist the requirement itself?

I see a strong need for reliable messaging, but I am also extremely
interested in understanding the circumstances it is appropriate to use it in
and the consequences of using it.

-----Original Message-----
From: Mark Baker [mailto:distobj@acm.org] 
Sent: Wednesday, July 10, 2002 8:52 AM
To: www-ws-arch@w3.org
Cc: www-ws-arch@w3.org
Subject: Re: [RTF] AC019 proposal to WSA WG



Hi Roger,

On Tue, Jul 09, 2002 at 10:13:41PM -0700, Cutler, Roger (RogerCutler) wrote:
> I honestly do not understand this discussion.  Is there some 
> fundamental disconnect here?  If so, what would get people talking 
> about the same issues?

I think there is a fundamental disconnect here.  But ...

> I sort of thought that the requirements for web services, and thus the 
> architecture, are supposed to be driven by usage cases and scenarios.

I agree completely!

>   It
> seems to me that there are numerous usage cases and scenarios that 
> illustrate the importance of reliable messaging mechanisms that are 
> widely agreed upon so that one may expect all the parties of a 
> transaction to deal with this messaging issue in a compatible and 
> mutually understood manner.  I personally think that this requirement 
> is EXTREMELY important, right up there with the security issues.  I 
> don't see how web services can successfully be used in realistic 
> business situations without well understood and agreed upon solutions 
> in both areas.

I absolutely agree that a reliability solution is required.  I just disagree
that reliable messaging is suitable in all cases.  On the Web, it's a very
costly and unnecessary means of achieving reliability.

> Frankly, if the best the REST approach can do is say that the 
> application programmer can deal with 404's, I don't really have a lot 
> of desire to hear much of anything else about REST.

I don't understand.  404 is not an aspect of unreliability, it's something
that happens when a Web service provider screws up (primarily, there are
other valid reasons for a 404).  The only possible way to resolve it is to
place a requirement on Web services providers, not the architecture.
Something like;

"Web services providers MUST always ensure that their published Web services
be found.  This includes declaring when they've been retired, or when
they've relocated."

Do we really want to do that?  IMO, not supporting a 404 solution won't make
the problem go away, it will just make the error non-standardized so that
you have no idea why your request didn't work.  I consider that a bad thing.

>  But surely that is not where this
> discussion has to be, is it?  Is there some way of restating, or 
> possibly understanding in a different way, the legitimate concerns on 
> both sides of the controversy in such a way that they are not so 
> mutually incompatible?

Yes, I've been trying to get at this.  I've been proposing what I feel is a
legitimately compromise.  Let me rephrase it;

"will support a reliability solution befitting the chosen architectural
style"

How's that?

MB
-- 
Mark Baker, CTO, Idokorro Mobile (formerly Planetfred)
Ottawa, Ontario, CANADA.               distobj@acm.org
http://www.markbaker.ca        http://www.idokorro.com

Received on Wednesday, 10 July 2002 10:37:00 UTC