Re: Web Service Description and stateful services - (on the 'www-ws@w3.org' list) Debating on a) Stateful Web Service Instances b) Stateful Interaction - OGSI

I was hoping to have some feedback from architecture group members on
the www-ws@w3.org list.
In particular, in relation to OGSI spec: 
Is it appropriate for the web service community to support a)
or is that a wrong OO mindset that we should abandon?

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 services.

WSDL and SOAP don't support:
a) The concept of stateful service instance
b) Stateful interaction 
-  Object passing, neither by value nor by reference

I use the term "Stateful Web Service Instance" with a meaning compatible
with the following: "Grid services can maintain internal state for the
lifetime of the service. The existence of state distinguishes one
instance of a service from another that provides the same interface. We
use the term Grid service instance to refer to a particular
instantiation of a Grid service. " [6.1 The OGSA Service Model] 
In this meaning, the relation between a web service and its stateful
service instances vaguely resemble the one of a class and its objects.
If Stateful Service Instances are supported, issues such as lifetime
management and remote instance references must be taken into account. In
this meaning, "Stateful Web Service Instance" are today neither
pervasive nor standard.


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. 
A stateful software system can have stateless interactions. 
Today, a SOAP/WSDL Web Service might be considered a stateful software
system, that support only stateless interactions. 
On the other hand, a) and b) are often achieved in custom ways. (e.g.
OGSI)
b) might be achieved with other web service protocols that
are less "pervasive and standard" than SOAP and WSDL.
We are focusing on the hypothesis of supporting this features with SOAP
and/or WSDL.

Would it be appropriate for SOAP/WSDL to support a) and b) ?
Is it appropriate for the web service community to support a)
or is that a wrong OO mindset that we should abandon? 

Let me again remember that we are not talking about composition
languages,
that already have concepts that bear some resemblance with a) and b) 
(e.g. "business process instance" and "message correlation")

In this debate, I see the following main positions, please do suggest
others:

-ab:  a) and b) must never be performed, not even in custom ways. 

-a :  b) can be performed in custom ways, but not a)

 0 :  a) and b) can be performed, but only in custom ways

+b :  SOAP/WSDL should support b), but not a)

+ab:  SOAP/WSDL should support both a) and b)


Regards
Marco


PS:
I have not included a) but not b) positions, because I think that if
full a) support is provided, 
then a form of b) must exist. But one could debate on this too ;)











Marco Adragna
Kellogg College
Oxford University
marco.adragna@kellogg.ox.ac.uk
(Chief of R&D for Hit-Com.It)

Received on Friday, 20 June 2003 05:40:44 UTC