Re: Stateful Web Services...

Mullins, Chalon wrote:

>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.
>
>  
>
Just a note: the Web services community has been working to standardize 
a generic session model for the Web services environment: this is 
WS-Context being standardized in OASIS. It supports late-binding and 
dynamic session association and the full range of conversational models 
from ephemeral to long-lived (days, weeks, years) conversations. It 
supports correlation with backend state managed by middleware 
infrastructure, but does not require this model. The model builds on 
what we've learned from distributed object, web sessions, and message 
oriented systems to allow users to build flexible protocols or 
application solutions.

><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 20:09:04 UTC