- From: Assaf Arkin <arkin@intalio.com>
- Date: Tue, 20 May 2003 09:26:25 -0700
- 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 UTC