- 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>
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 language? - What obligations does a client incur upon invocation of said method, in particular "safe" means they have a minimal semantic understanding. Cheers, Dave > -----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