- From: Drew McDermott <drew.mcdermott@yale.edu>
- Date: Thu, 19 Jun 2003 11:28:47 -0400 (EDT)
- To: marco.adragna@kellogg.ox.ac.uk
- CC: www-ws@w3.org, Savas.Parastatidis@newcastle.ac.uk, umit.yalcinalp@oracle.com, jim.webber@arjuna.com, sggraham@us.ibm.com, ksankar@cisco.com
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