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

Re: Web Service Description and stateful services

From: Assaf Arkin <arkin@intalio.com>
Date: Tue, 20 May 2003 09:26:25 -0700
Message-ID: <3ECA5731.2040803@intalio.com>
To: Savas Parastatidis <Savas.Parastatidis@newcastle.ac.uk>
CC: www-ws-arch@w3.org

IMO the Web service as a Web service - whatever that elusive definition 
is - should be stateless. But in a lot of cases there would be a state 
behind it and it would be accessed by referencing that state. Think of 
your trusty bank teller. He/she/it is stateless, you can go to any 
teller that is available or use an ATM machine to access your account. 
But there's some state that you would always reference by giving an 
account number before performing any transaction. And the notion of 
providing an account information to carry out a transaction is part of 
the interface definition of all tellers.

How state is maintained is totally up to the service, different 
implementations may do so in different means. But how the state is 
referenced when interacting with the service is part of the service 
definition. There needs to be some part of the interface that is 
consistently used across operations to identify state, and if that value 
is different, it means you are interacting with the same service but in 
different states (e.g. withdrawing money from different accounts while 
using the same or different tellers).

Definitely the notion of state reference as being part of the interface 
of a stateless service should be mentioned in the WSA document. Where we 
put these definitions is a different issue. A model that uses 
correlations that are specified as part of the interface is present in 
both BPEL and WSCI and both do it pretty much the same way. Since this 
is something we care about in choreographies it becomes part of the 
choreography language and something that is also used by some execution 
languages (and quite a lot in the processes I've seen).

But I think that definition lives somewhere inbetween regular WSDL 
interfaces and choreographies since it can be used by services that are 
not choreographed. The teller example is a good one, there's no strict 
choreography saying you need to deposit and withdraw in some order, just 
that all the operations you do in any order and any number of times, 
need to be correlated the same way. So there's justification to bring it 
into WSDL or maybe create an extension to WSDL that can be used on its 
own and by a choreography language, depending on use case. Incidentally, 
both WSCI and BPEL define this as an extension of WSDL by taking 
advantage of extension elements.

arkin

Savas Parastatidis wrote:

>>But whether WSD or WSCHOR eventually looks into this, I *do* think
>>    
>>
>that we
>  
>
>>need to have concepts/relationships that describe how a Web service
>>maintains its state.  This is obviously tied up with the more abstract
>>discussions we've had over the role of "statelessness" in the Web
>>architecture.
>>
>>    
>>
>
>Surely, the way a Web service maintains its state must be an
>implementation detail. How do we refer to/address that state and whether
>there is value in providing a standard way for
>creating/modifying/accessing it should be the topic of discussion, but
>in the appropriate WGs.
>
>.savas.
>
>  
>
Received on Tuesday, 20 May 2003 12:29:24 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 3 July 2007 12:25:19 GMT