W3C home > Mailing lists > Public > www-ws@w3.org > October 2004

Re: Stateful Web Services...

From: Francesco Furfari <francesco.furfari@isti.cnr.it>
Date: Fri, 29 Oct 2004 14:25:48 +0200
To: Savas Parastatidis <Savas.Parastatidis@newcastle.ac.uk>
Cc: www-ws@w3.org
Message-id: <418236CC.1020702@isti.cnr.it>

I'm a very beginner to be aware of  the success or failure of  OGSI 
initiative, anyway my previous mail was referred to
WSResource Framework  that uses the reference Properties of 
WS-Addressing in a conventional way to represent  stateful resources.
So it seems aligned to your position ...
My disappoint was mainly referred to problems encontered in moving from 
Axis to JWSDP ...
It is incongruous I use WS to be interoperable but if I change WS Engine
on the same (Java) platform I have to modify (no so much of course) my code.

>Stateful Web Services at the architectural level (i.e. we design our system with the assumption that conversation state is maintained and exposed) leads to other problems too that relate to garbage collection, concurrency, etc.
>  
>
Yes, I'm interested to understand how, by a XML based approach, we can 
solve all these problems
 improving interoperabilty . How much cost all that? is it really suitable?

ciao
francesco

Savas Parastatidis wrote:

>OGSI was the Grid community's attempt to model at the architectural level stateful services and that failed miserably. Please note that no one can restrict an implementation of a Web Service to maintain conversation-specific state. However, experience tells us that scalability and loose coupling are easier if we don't make the assumption that the endpoint to which we are talking maintains state that is related to our conversation. Every message sent should have enough information in it for the receiving service to reconstruct the state machine of the interaction (e.g. use of context information like WS-Context, or ReferenceProperties/ReferenceParameters from WS-Addressing). The Web mostly works in this way (e.g. cookies).
>
>What the above means is that you can farm the processing of receiving messages by using and backend datastore. Look at how session management can be done for web applications by application servers.
>
>Stateful Web Services at the architectural level (i.e. we design our system with the assumption that conversation state is maintained and exposed) leads to other problems too that relate to garbage collection, concurrency, etc.
>
>Just few thoughts.
>--
>Savas Parastatidis
>http://savas.parastatidis.name
> 
>  
>
>>-----Original Message-----
>>From: www-ws-request@w3.org [mailto:www-ws-request@w3.org] On Behalf Of
>>Francesco Furfari
>>Sent: 28 October 2004 15:43
>>To: hf0722x@protecting.net
>>Cc: www-ws@w3.org
>>Subject: Re: Stateful Web Services...
>>
>>
>>I'm just starting to study the work around grid services. Ian Foster et
>>Al in
>>"Modeling Stateful Resources with Web Services"  says :
>>"... it is desiderable to represent such relationships between Web
>>Services and state explicitily and in a standard manner,..."
>>If I remember well in Axis to activate the session mechanism you have to
>>use SESSION_MAINTAIN_PROPERTY.
>>Changing WS engine, with  JWSDP (1.3) for instance, you have to manage
>>the session by yourself ...
>>So,  in my opinion, web services are simply managed software that expose
>>service interfaces in a standard machine-processable format
>>and we could  improve interoperability if the standardization process
>>concerns the state rapresentation too.
>>
>>ciao
>>francesco
>>
>>
>>
>>Harald Fuchs wrote:
>>
>>    
>>
>>>In article <07b501c4bc28$d7c37080$2203a8c0@critical.pt>,
>>>Cristóvão Bento <cbento@criticalsoftware.com> writes:
>>>
>>>
>>>
>>>      
>>>
>>>>Although there is one last thing that is confusing me. A Web Service
>>>>life is controled by a Web Server like for example Tomcat. When a
>>>>request arrives, the class that implements the request is
>>>>dynamically loaded and the request is executed. When the request
>>>>ends the class is deallocated. This means this class cannot maintain
>>>>its internal state. Any kind of data that was kept by it is garbage
>>>>collected.
>>>>
>>>>
>>>>        
>>>>
>>>Nobody sys that you need something like Tomcat to implement a web
>>>service.  A small Perl script, started by inetd, would do likewise.
>>>
>>>If you want to maintain state, you need two things:
>>>1. A stable "backend" where you can store state, independent of the
>>>  lifetime of the code implementing the web service
>>>2. A way to identify the requestor for whom you want to maintain
>>>  state, something like a cookie.
>>>
>>>
>>>
>>>
>>>
>>>
>>>      
>>>
>>
>>
>>    
>>
>
>
>
>
>  
>
Received on Friday, 29 October 2004 12:26:36 GMT

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