RE: WSD Requirements: add a requirement about safe and idempotent characteristics

Walden,

You are perfectly right.

What I am looking for are two things. First, the overall change that occurs
to the system that consists of two nodes, one being the invoker of the
operation and the other being the performer. So I want to know if multiple
invocations of the operations have the same effect as one, and an idempotent
flag would describe just that.

The specific use case deals with how an application would use an operation
and how a server could provide a "safe" environment for the application.
From its perspective the application wants to do the operation (once) before
it can proceed to the next task. So it has to start at a state where the
operation is not performed and change to a state after it is performed.

The server could use a variety of mechanism to offer a safe environment. An
in-doubt situation occurs if a the server crashes and then restarts. It can
resolve that situation by recording the fact that the operation was
performed (persistence) or attempt to cancel it (transactions). If the
operation is marked as idempotent it does not need any of these mechanisms,
when it is in-doubt it will always retry the operation.

arkin
  -----Original Message-----
  From: www-ws-arch-request@w3.org [mailto:www-ws-arch-request@w3.org]On
Behalf Of Mathews, Walden
  Sent: Tuesday, December 03, 2002 1:38 PM
  To: 'Assaf Arkin'; www-ws-arch@w3.org
  Subject: RE: WSD Requirements: add a requirement about safe and idempotent
characteristics


  +1

  "Plus one", but in this case not to signify agreement, but rather to
correct
  your definition of 'idempotent'.  Idempotence is inductively defined as

      f(x) = f(f(x))

  which, by induction means that any number of applications of f has the
  same result as one.  So it's 'one' and 'many', not 'zero' and 'one'.

  You mean "safe" when you say "idempotent", and frankly, way way too many
  people on these lists fall into that same trap.

  Just My $.03

  Walden Mathews
    -----Original Message-----
    From: Assaf Arkin [mailto:arkin@intalio.com]
    Sent: Tuesday, December 03, 2002 3:17 PM
    To: www-ws-arch@w3.org
    Subject: RE: WSD Requirements: add a requirement about safe and
idempotent characteristics


    Just my $.02

    We are using WSDL to understand how to interact with a Web service when
it is utilized as part of a business process. A service would be used in
different ways depending on whether it is idempotent or not, transactional
or not, etc. In particular, if you are interacting with a transactional Web
service that exposes an idempotent operation you would not ask that
operation to participate in a transaction or persist the fact you performed
the operation on your side, since you can retry it without any side effects.

    There are other ways to mark an operation as idempotent, however putting
that in the WSDL abstract definition would help the tool understand how to
build the proper interaction. It would be extremely useful to see something
like that added to the WSDL abstract operation definition, regardless of
which transport protocol you use. In actual execution you might decide to
perform the operation over SMTP, TCP or a variety of other protocols.

    If we could conclude that GET is always used for idempotent operations
and POST is always used for non-idempotent operations than we could place a
restriction on the protocol bindings such that they comply with the type of
operation described at the abstract layer, since by definition the protocol
binding follows the abstract operation definition and supports it.

    Personally, I do not see such a clear cut division of labor between POST
and GET. And more specifically to Mark's point I do not see how DELETE is
idempotent if it removes a resource on the server. If there is a difference
between doing DELETE zero times and doing DELETE once, then by definition it
is not idempotent.

    As a very basic example let's consider a translation service that
converts an HTML document into PDF, or an insurance quoting service that
requires a complex data structure as input in order to provide a quote for a
policy. Such a service could be implemented using HTTP POST or SMTP, but is
idempotent.

    On the other hand, I could see a real-time stock quote retrieval service
that given a stock ticker gives you the current stock price. Since the
request is simple it could also be implemented using HTTP GET. However,
being real time means that the response should not be cached by a proxy
(which is easy to control using the cache control headers of HTTP). It also
means you get charged each time you retrieve a quote, so the service is
definitely not idempotent.

    regards,
    arkin
      -----Original Message-----
      From: www-ws-arch-request@w3.org [mailto:www-ws-arch-request@w3.org]On
Behalf Of Doug Bunting
      Sent: Tuesday, November 26, 2002 2:20 PM
      To: Mark Baker
      Cc: Ugo Corda; www-ws-arch@w3.org
      Subject: Re: WSD Requirements: add a requirement about safe and
idempotent characteristics


      No, we're going to recognize that all POST operations are not
necessarily not idempotent.  GET is in reality used for requests that are
both idempotent and able to be sent without additional information besides
HTTP headers.  POST is in reality used for requests that are not idempotent
or require additional information or were set up against a random site
developer's (possibly misguided) whim.

      That said, I'd agree knowing the HTTP method is enough to know whether
the response is cacheable using existing proxies.  I'm not entirely certain
how an idempotent attribute independent of the method helps the requester.
What would that software due with this proposed attribute?

      thanx,
          doug

      Mark Baker wrote:

Hi Ugo,

On Tue, Nov 26, 2002 at 11:26:52AM -0800, Ugo Corda wrote:
  I have the impression that Hugo wanted to also address cases where POST is
used instead of GET (because, for example, headers are to be specified), but
still the operation is idempotent. So just looking at the method would not
sufficient to tell whether the operation is idempotent or not.

Looking at the method will *always* be enough to know whether it's
idempotent or not.  POST is not idempotent, by definition.  PUT is
idempotent, as is GET and DELETE, also by definition.  They have
their own standalone meanings, and nothing in the body of the message
can change that.

(uh oh, are we going to have to get into the "HTTP isn't a transport
protocol" issue again? 8-)

MB