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

Re: Stateful Web Services...

From: Mark Baker <distobj@acm.org>
Date: Fri, 29 Oct 2004 15:12:51 -0400
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 <sggraham@us.ibm.com>, Steve Tuecke <tuecke@mcs.anl.gov>
Message-ID: <20041029191251.GB14710@markbaker.ca>


On Fri, Oct 29, 2004 at 11:15:32AM -0700, Mullins, Chalon wrote:
> Mark,
> That's not transferring "all" state.

I'm not sure what you mean by "all".  What I'm talking about is
transferring all data which is required in order to understand the
semantics of the message; no shared context allowed.

>  Every solution I have seen mentioned
> here deals with the issue of large amounts of state by storing it on the
> back end, and passing information about how to get at it -- maybe a key,
> maybe something else.  I stick by my statement -- what gets in the way of
> scalability is affinity to a particular endpoint.

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.

> If I had to transfer all the balances and positions for my customers each
> time so that I could value a portfolio, I would never be able to handle the
> hundreds of thousands of concurrent users we do every day.

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.

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.

Mark Baker.   Ottawa, Ontario, CANADA.        http://www.markbaker.ca
Received on Friday, 29 October 2004 19:10:57 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 23:05:15 UTC