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

Re: Marking operations safe

From: Paul Denning <pauld@mitre.org>
Date: Fri, 27 Feb 2004 09:41:09 -0500
Message-Id: <6.0.0.22.0.20040227091843.01cfc050@localhost>
To: www-ws-desc@w3.org

At 04:37 AM 2004-02-27, Hugo Haas wrote:
>The safeness and idempotency of a Web service request are independent
>from the binding used, so it makes sense to express them at the
>operation level. Since an operation could involve any MEP, we need to
>specify that we are talking here about state from the service's point
>of view.

The SOAP 1.2 Web method feature [1] implies both safe and idempotent when 
the property value is GET.

Has WSDWG come up with a way to use the web method feature in WSDL?


I suppose there is probably a need to split "safe" and "idempotent" 
apart.  You can then assume web method feature (WMF) is GET if both safe 
and idempotent (but perhaps not).

Note that WMF could be POST, and the operation is both safe and 
idempotent.  POST is appropriate for other reasons [2] (for example, if 
SOAP header blocks are needed).

An interesting twist is when the service endpoint can be described with 
WMF=GET, but a pair of intermediaries (i1, i2) need to use SOAP header blocks.

         a.  sender ->GET -> i1 -> POST -> i2 -> GET -> receiver, or
         b.  sender -> POST -> i1 -> POST -> i2 -> GET -> receiver

In case (a), the sender's request could be based on the WSDL of the receiver.
In case (b), perhaps there is an internal policy that senders use a certain 
SOAP header block (e.g., WS-Security), so it would have to POST to the 
first intermediary.  The sender's request would need to use a different 
WSDL than that at the receiver.  Both would be safe and idempotent, but WMF 
would be different due to the need for SOAP header blocks from the sender.

[1] http://www.w3.org/TR/2003/REC-soap12-part2-20030624/#WebMethodFeature
[2] http://www.w3.org/TR/2003/REC-soap12-part2-20030624/#RPCResourceRetrieval

Paul
Received on Friday, 27 February 2004 09:41:13 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 5 February 2014 07:15:02 UTC