Re: Stateful Web Services...

First, thanks Chalon for initiating this very good conversation.

Second, I need to weigh in a little on some of the comments related to the 
transition from OGSI -> WSRF (as an author on both, I have some insight 
here).

OGSI->WSRF was motivated by a combination of things.  Most importantly, it 
was the aggressive use of WSDL and XSD that was a major motivator for the 
shift to WSRF.  An observer should note that most/all of the concepts in 
OGSI migrated to WSRF in some form.  The syntactical representations of 
these concepts in WSRF (in particular the use of WSDL 1.1 (not GWSDL), the 
more conventional use of XSD, the use of WS-Addressing) were made in order 
to rehost the statefulness concepts in OGSI onto a platform that was more 
in line with the "state of the art" (excuse the pun) of Web services.

Although some may claim that the conversion of terminology from 'stateful 
services' to 'resource' reflected in the transition from OGSI to WSRF was 
somehow profound, I fail to see it.  For the most part, this transition of 
terminology was minor in comparison to the other conversions that happened 
from OGSI to WSRF (syntactical reorientation, factoring of the 
specifications etc.).  Some folks get hung up on the distinction between 
'stateful services' and 'resources', but I don't.  The types of problems 
we are addressing with WSRF are the same as those with OGSI.

Finally, a direct comment on Mark's point:
>Well, I personally feel that the Grid community has made a mistake by
>so fully embracing stateful comms with WS-RF.  YMMV, of course. 8-)

Two major thoughts here:
a) the Grid community is lining up with the systems management community 
(eg OASIS WSDM) to represent system resources (in the systems management 
sense) using the same technologies.  In this way, the part of the Grid 
"stack" that manipulates system resources, can do so in such a way as 
systems management applications do.  This alignment was a major motivating 
factor in transitioning from OGSI to WSRF.  Net/Net, Grid apps can 
leverage the investment resource providers do in instrumenting their 
resources to present a WSRF interface.

b) Not all parts of the Grid application stack will use WSRF.  The layers 
that are closest aligned to the system resources will likely use WSRF for 
compatibility reasons with the resource instrumentation.  Besides that 
Grid applications that wish to deal with their own stateful resources in 
an open standard way will choose WSRF.  Those Grid applications that don't 
have a major component of state will use little or no WSRF.

sgg
++++++++
Steve Graham
(919)254-0615 (T/L 444)
STSM, On Demand Architecture
Member, IBM Academy of Technology
<Soli Deo Gloria/>
++++++++




Mark Baker <distobj@acm.org> 
10/29/2004 04:30 PM

To
"Mullins, Chalon" <Chalon.Mullins@schwab.com>
cc
"'Savas Parastatidis'" <Savas.Parastatidis@newcastle.ac.uk>, 
www-ws@w3.org, Ian Foster <foster@mcs.anl.gov>, Carl Kesselman 
<carl@ISI.EDU>, Steve Graham/Raleigh/IBM@IBMUS, Steve Tuecke 
<tuecke@mcs.anl.gov>
Subject
Re: Stateful Web Services...






Hi again,

On Fri, Oct 29, 2004 at 12:50:07PM -0700, Mullins, Chalon wrote:
> <MB> In my experience with scaling Web servers, what gets in the way is
> exactly the mechanism you describe there; "storing it on the back end,
> and passing information about how to get at it".  By doing that, you
> prevent the server from freeing up resources as it needs, and end up
> requiring hacks like distributed garbage collection, and/or just
> throwing more and more server resources at the problem.
> 
> <CM>  Exactly!  We get the benefit that we can scale our applications by
> adding or taking away servers without impacting clients, but, as things
> stand, we have to take care of these issues ourselves.

Ok, sure, but I claim that stateful apps have to upgrade much more often
since they're maintaining state which isn't present for stateless apps
(since it's all in the messages).

>  I would draw a
> different conclusion, though:  this is exactly why a standard way of
> handling the inherent statefulness of the problem in a stateless 
protocol is
> key -- then the server can understand what's going and free up 
resources,
> etc.  Not surprising that the Grid Community, which runs up against this
> problem all the time, would be the one pushing the standard solution.

Well, I personally feel that the Grid community has made a mistake by
so fully embracing stateful comms with WS-RF.  YMMV, of course. 8-)

> <MB> I think you'd be surprised what you could handle.  Most of the
> interesting work on scalable services over the past 10 years or so
> has been done with Web servers.
> 
> <CM> Interesting claim, but I'm not sure what backs it up.  I think 
you're
> dismissing some really fascinating things that have been done, for 
example,
> in the mainframe space.  BTW -- we are always testing the limits of what 
we
> can handle.

No, I'm not too familiar with mainframes.  I should have stated that
most of the *published* work on scalability of network based services
has been regarding Web server scalability; "interesting" is, of
course, subjective. 8-)

But if you had any pointers handy to the work you're referring to, I'd
love to have a look.  TIA!

> <MB> There could very well be some scenarios for which that doesn't make
> sense, but in my experience stateless should always be your first choice
> unless there's a darned good reason not to use it.
> 
> <CM> Well, I agree about going "stateless," but as the dialog that 
started
> this point explained, I think we have differences over just what that 
means.
> As far as whether we really do have a scenario that doesn't fit, I'm
> comfortable that we have.  And we may just have to disagree on that 
point.

Yes, it seems so! 8-)

Cheers,

Mark.
-- 
Mark Baker.   Ottawa, Ontario, CANADA.        http://www.markbaker.ca