W3C home > Mailing lists > Public > www-ws@w3.org > March 2003

Re: atomic services with no effects or outputs

From: Drew McDermott <drew.mcdermott@yale.edu>
Date: Mon, 31 Mar 2003 08:32:04 -0500 (EST)
Message-Id: <200303311332.h2VDVtC15011@pantheon-po04.its.yale.edu>
To: mits1@cs.umbc.edu
CC: www-ws@w3.org

   Date: Fri, 21 Mar 2003 16:31:25 -0500
   From: Mithun Sheshagiri <mits1@cs.umbc.edu>


   If a service does not indicate a change of state (i.e., if it does not 
   have i/e) then how can someone who discovers the service use it (say for 
   composition). Something does change when the service is executed but the 
   service does not reveal it. I would like to draw an analogy between such 
   services with methods that have return type "void". Take the example of 
   a program that implements a counter. The increment method in this 
   program returns void after incrementing the counter. I further name the 
   method foo. If I advertise this method as a web service how will one use 
   it since he/she has no idea about its internal workings. But if I return 
   a message (add an effect/output) that says "Counter_Incremented" then 
   won't it be much easier to comprehend what the service does (assuming 
   there is a Genie that maps Counter_Incremented to an my concept of 
   counter increment)..
   What I make out of this is that as long as I don't provide an output or 
   effect, only I, as the writer of the program can use it. By describing 
   the effect, I describe the service to the extent that someone else might 
   be able to use it.
   Do I make any sense or have I completely lost it.

You're absolutely correct.  The reason why process models tend to be a
bit anemic in this respect is that it's difficult to agree on a
standard vocabulary for describing arbitrary effects.  Actually, the
same is true for messages, but here we can pretend we have a standard
vocabulary when we've standardized SOAP.  What's still missing is a
vocabulary at the "task" level, as opposed to the "data structure"

                                             -- Drew McDermott
Received on Monday, 31 March 2003 08:32:05 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:37:08 UTC