Re: Debating on the usefulness of supporting a) Stateful Web Service Instances b) Stateful Interaction

   From: "marco" <marco.adragna@kellogg.ox.ac.uk>
   Date: Thu, 19 Jun 2003 15:15:22 +0200

   All,
   I have been asked to move the discussion on stateful service instances
   and stateful interactions to this list.

   ...

   Web Service composition languages have already some notion of a) and b)
   Here we are talking of a) and b) in relation to a single non-composed
   web service.

   Today standard web services don't support:
   a) The concept of stateful service instance
   b) Stateful interaction 
   -  Object passing, neither by value nor by reference

   As a working definition of state of a software system  we could say that
   "Is a condition that captures history of the system and influence how
   the system behave in specific circumstances."[A.M. Davis - 1993 -
   Software requirements]
   A generic server supporting stateless interaction, process each message
   on its own. 
   If stateful interaction is supported, each message is interpreted in
   relation to a state, in a context. 

I understand what (a) is, but (b) seems more slippery.  Suppose we
have an interaction like this, betweeen a client C and a stateful
service S:

C->S: Open session
S->C: Session opened; session id = 999
C->S: For session 999, put xxx in shopping cart
S->C: For session 999, okay
C->S: For session 999, put yyy in shopping cart
S->C: For session 999, no good, yyy out of stock
...
C->S: Close session 999
S->C: Session 999 closed

Obviously, S is stateful, because it remembers what's in C's shopping
cart.  But are all the interactions that use session id 999
"stateful"?  Or did you mean to focus on cases where S gives C
something more bulky than a mere integer to refer to the current state
of the interaction?

-- 
                                             -- Drew McDermott

Received on Thursday, 19 June 2003 11:30:12 UTC