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

Ugo Corda wrote:

>That's not the way I read it. The process instance can very well be keeping track of previous requests from that particular client (e.g. by storing previous messages in internal variables) and be basing future actions on those previous requests. This would be equivalent in Chris' example to the case where "the server were implemented such that it *had* to remember which map the client had previously retrieved to make sense of the invocation to get more information about some coordinates on the map".
>  
>
That was my first interpretation of Chris's e-mail, but having read it 
again he did point out that a service would typically have a "maintained 
state" and may be stateful or stateless. So I ignored the maintained 
state. Of course I may have incorrectly labeled the process instance as 
maintained state where it should have been session context. That's open 
to interpretation.

My interpretation is as follows: user -> client -> server -> engine. Not 
great terminology, but just a way to avoid using the word service.

A server is stateful if the server retains a state and associates it 
with the client,  A server is stateless if it does not do so. If the 
engine maintains a state and associates it with the user, then the 
server is stateless. The engine is not, neither is the user. In the BPEL 
case the state is maintained by the engine on behalf of the user, as a 
way to guarantee long term persistence. If the client goes up in smoke 
and the user decides to use a different client, or the server is 
overloaded and the request gets forwarded to another server, you would 
still have an interaction with the correct process instance.

Now, most of the Web servers I use on a daily basis have a user 
association and a client association. The client association is usually 
a solution to the sign-on problem, and you can't escape that in many 
cases even if you use machine-to-machine protocols. But it's the user 
association that actually references the maintained state and the one 
that uses correlation. The bank account number that allows me to access 
my bank account from any number of clients (browsers, machines, etc). 
The FedEx tracking number that allows me to track a package (a state I 
created) from any browser in the world. And so forth.

The BPEL correlation model is similar to the FedEx model, it lets you 
get back to the maintained state from any client in the world as long as 
you can correctly identify it. Though an implementation may choose to do 
so, there's no client affinity simply because it would fail quickly if 
you end up with a long lasting interaction and can't keep using the same 
client.


The question that needs to be clarified is 'what is the service'. Is it 
the client-server that Roy is talking about and WSDL alludes to? Or is 
it the engine behind the server that has maintained state and so 
recognizes the client and is stateful. What's your take?

arkin

>>If I am thinking in terms of the business service being offered then it 
>>is stateful. The service being offered is the process, the process has a 
>>maintained state and interaction with the process is often (not always, 
>>but often enough) a stateful interaction. So the service for which WSDL 
>>has a service definition is actually a stateful service.
>>    
>>
>
>That's exactly what I was referring to, i.e. the BPEL process offered as a Web service.
>
>Ugo
>  
>

Received on Friday, 20 June 2003 23:27:19 UTC