Marking operations safe

As per the action item I took over from Philippe,

  2004-01-30: Philippe to draft a note for the group around safe

please find below a proposal presenting options to indicate
operation's properties.

-=- Background -=-

I found the following discussions in the mailing list:

  New issue: Representing safe operations

  Marking WSDL operations as "safe", in scope requirement?

  30 Jan 2004 WS Description FTF: Flagging an operation as 'safe'

Additionally, there were the following discussions in the Web Services
Architecture Working Group:

  WSD Requirements: add a requirement about safe and idempotent characteristics

-=- Discussion -=-

Operations can have side-effects (updating a data in a database,
ordering a DVD, etc.). When they do not, those operations are called
safe. Safeness may not be the only characteristics of an operation
that one may want to advertize. One may also want to indicate whether
the operation is idempotent. Those concepts are defined in the Web
Services Glossary[1].

The motivations for flagging a Web services interaction as safe or
idempotent include the following:

- a safe operation is cachable; it may be serializable as an HTTP GET
  (or even HEAD) request; if so, the request can take advantage of the
  Web infrastructure such as caches.

- a toolkit could make the choice of using an HTTP GET or SOAP GET
  binding for such operations (e.g. GetStockQuote) if there where
  marked as such.

- knowing that an operation is safe or idempotent can allow poor-man's
  message reliability, or message reliability optimizations: safe and
  idempotent operations can be repeated without additional
  side-effects, and therefore this eliminates the problem of ensuring
  that a message is received only once.

- it would help developers to align their deployed Web services with
  the "URIs, Addressability, and the use of HTTP GET and POST" TAG

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.

Based on this, below are two proposals to express safeness at in WSDL

-=- 1. Introducing a side-effect property to Interface Operation -=-

This would be expressed using an attribute information item, and could
take different values:

	Safe operation

	Idempotent operation


     <operation name="GetStockQuote" pattern=""
       <input message="tns:gsqReq"/>
       <output message="tns:gsqResp"/>

-=- 2. Introducing a side-effect features -=-

We could define a side-effect WSDL feature:

This feature would only be applied to an interface operation, as it
doesn't make sense to apply it at the binding level. This feature
would have one property:

The possible values are the same as above:

	Safe operation

	Idempotent operation


     <operation name="GetStockQuote" pattern="">
       <feature uri=''
       <property name=''>
       <input message="tns:gsqReq"/>
       <output message="tns:gsqResp"/>



Hugo Haas - W3C -

Received on Friday, 27 February 2004 08:56:02 UTC