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

Hi,

I think semantics and state are different things.  You can have either without the other.  I think of state management as a generic mechanism that's currently missing from Web services since it's also missing from HTTP.  

So we probably need a new mechanism, perhaps something from BPEL, that just focuses on state management for shared information.

I do not see an analogy with EJBs since they are designed to reflect the classic three-tier model of TP monitors, which basically exists for the purpose of multiplexing clients or user connections into a smaller number of database connections.  There's a large bit of science on this, but the reason for separating the tiers is basically that you want to be able to size your system based on the number of concurrent transactions rather than the number of concurrent users.  This all does relate to sessions and state management, but Web services are architecturally more like CORBA, n-tiered, and probably a generic state management service is the way to go.

I'd say the architecture should reflect the fact that state management is necessary for certain use cases of Web services, such as security (i.e. multiple Web services sharing the same security context) or reliable messaging (i.e. multiple parties in a communcation sharing state about the communication), but not cite specific technology yet since there isn't any.

Eric

-----Original Message-----
From: Assaf Arkin [mailto:arkin@intalio.com]
Sent: Saturday, June 21, 2003 12:06 AM
To: Ugo Corda
Cc: www-ws-arch@w3.org
Subject: 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:

>>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?
>>    
>>
>
>Well, as Mike mentioned before, SOAP and WSDL do not have notion of state. So if we want to talk about state we have to move to a level above that. (You might want to call that a semantic view of what the service actually does). I used the BPEL Web service example because in that case you have a specific document (the process document written in the BPEL language) that tells you what the internals of the Web service (i.e. the business process) look like.
>  
>
What do we call the internals? Is it a 'service' but not a 'Web 
service', the 'service behind the service', the 'Web service whose 
definition is given by more than WSDL/SOAP', or something totally 
difference?

What if I have three layers. WSDL/SOAP is one layer that is stateless. 
Reliable messaging and single sign-on is another layer that is stateful. 
BPEL is another layer that is definitely stateful but more like the 
maintained state. In the EJB world we have stateless, stateful and 
entity beans. Do we have a similar analogy here?

arkin

>Ugo
>  
>

Received on Saturday, 21 June 2003 12:29:43 UTC