W3C home > Mailing lists > Public > www-ws-arch@w3.org > February 2004

RE: Safety and WSDL

From: David Orchard <dorchard@bea.com>
Date: Sat, 14 Feb 2004 20:11:41 -0800
To: "'Mark Baker'" <distobj@acm.org>
Cc: <www-ws-arch@w3.org>
Message-ID: <02b501c3f379$d12d38a0$6501a8c0@beasys.com>

Safety hits the 80/20 mark for a few things:
- Can a client use a "safe" method as a poor man's ping?  "getStatus" is a
great example of this.
- Can a client retry a "safe" method in the absence of any choreography
- What obligations does a client incur upon invocation of said method, in
particular "safe" means they have a minimal semantic understanding.


> -----Original Message-----
> From: Mark Baker [mailto:distobj@acm.org]
> Sent: Saturday, February 14, 2004 7:55 PM
> To: David Orchard
> Cc: www-ws-arch@w3.org
> Subject: Safety and WSDL
> On Sat, Feb 14, 2004 at 05:20:32PM -0800, David Orchard wrote:
> > I strongly disagree that there isn't experience in the web
> architecture wrt
> > "safe" operations.  In fact, I'd argue that the web architecture is
> > completely dependent upon GET being "safe".
> Yup.  The Web wouldn't work at all if GET could not be assumed safe.
> >  Because it's safe, it can be
> > the default method used to retrieve a representation given
> a URI.  So we
> > have the entire web to show as experience wrt safe
> operations.  People want
> > the same facilities that GET offers but in a more protocol
> neutral manner.
> Well, the experience we have with GET and safety is that it's valuable
> to have a means for permitting untrusted parties to share information
> safely.  But is it still needed when the parties are trusted, as they
> need to be with SOA/Web-services?
> Or, put another way, are you going to invoke the
> "JwerijErjkjdf" method
> just because you know it's safe?  No, of course not.  You going to
> invoke it because you need it to do what it's defined to do.
> Safety can
> be communicated when you learn what that is (presumably via some human
> processable specification published by the service provider).
> Mark.
Received on Saturday, 14 February 2004 23:11:17 UTC

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