RE: Stateful Web Services...

Thanks, Mark, for your careful reply.

We're getting a little clearer, but not any closer to agreement.  Comments
below -- formatting was getting to be a problem, so I've used an <MB> tag
for your comments, Mark, and <CM> tag for mine.  I've also elided content
from messages previous to your last one.

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: Mark Baker [mailto:distobj@acm.org] 
Sent: Friday, October 29, 2004 12:13 PM
To: Mullins, Chalon
Cc: 'Savas Parastatidis'; www-ws@w3.org; Ian Foster; Carl Kesselman; Steve
Graham; Steve Tuecke
Subject: Re: Stateful Web Services...

Hi,

On Fri, Oct 29, 2004 at 11:15:32AM -0700, Mullins, Chalon wrote:

<MB>  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.

<CM> I just don't know how to translate these terms into a practical meaning
-- I know of no context free way to share semantics, but then maybe I've
read too much (later) Wittgenstein  8<).  At any rate, I think the next
point is really the key.

<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.  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.

<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.

<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.

Received on Friday, 29 October 2004 19:50:49 UTC