RE: Stateful Web Services...

I'm very surprised to see this comment from Savas -- I think he knows
better.  Yes the Grid community retracted OGSI, but it did not abandon the
effort to define a standard protocol for stateful web services.  Instead
OGSI was superseded by a set of proposed standards collectively called the
Web Services Resource Framework (WSRF).  The reasons for the change are
many-fold, but by no means do they imply that OGSI was a miserable failure.
Miserable failures do not have substantial follow on efforts based ona
substantial core of the original.  (For those interested in details, the
main differences between OGSI and WSRF are a) abandoning creating a special
version of wsdl using the extension mechanism in XML Schema, and b) a change
in packaging -- splitting one standard up into a set of standards.  Of
course, as you would expect the authors have also taken the opportunity to
clean up a number of smaller items, but these are what I would call the big
ones.)

I do not understand Savas' comment about scalability depending on not having
an assumption about the endpoint maintaining state.  Quite the opposite.
You cannot scale large systems if you have to assume all state has to be
transferred every time.  At least this is my experience, and I think we
build some pretty robust, scalable systems.  I would say that what you
really want to avoid is having to assume that you will always have to go to
the same endpoint because of dependence on state.  A mechanism that provides
for transference of information about how to get at that state does just
that.  If you go Savas's route you invent that for yourself.  If you follow
WSRF, you will be following a standard protocol for defining and
transferring that information.

That having been said -- I do not believe there are any off-the-shelf WSRF
implementations available.  The open source implementation from the Globus
Project (Globus v. 4) is set to go GA later this year.  So pragmatics may
make a WSRF based solution out of reach depending on the timing required.

Chalon Mullins
Technical Director, Infrastructure Strategy and Architecture
Charles Schwab & Co., Inc.
SF211MN-08-472
101 Montgomery St
San Francisco, CA 94104
phone:  (415) 667-1117


-----Original Message-----
From: www-ws-request@w3.org [mailto:www-ws-request@w3.org] On Behalf Of
Savas Parastatidis
Sent: Friday, October 29, 2004 2:44 AM
To: www-ws@w3.org
Subject: RE: Stateful Web Services...


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 17:58:05 UTC