RE: Stateful Web Services...

Even your quotation of stateless interaction doesn't make it clear.  Roy
has said that a cookie with a session id is a stateless interaction to a
stateful service.  This differs from something like ftp in which the
connection contains part of the state.  One way that http scales better
than ftp is because http can tear down the connections because of the
stateless interactions, and connections are very costly to maintain open
for potentially large numbers of clients.  

Now as to what's going on at the plumbing level in tcp/ip stacks I
haven't a clue about.  Why ftp creating and keeping large #s of
connections open with state being embodied in the ftp/tcp connection is
soo much more costly and less scalable than an http stateless tcp
connection is a mystery to me.  Especially when software can do SSL
connections that can be fairly chatty and bandwidth consuming.  

Cheers,
Dave

> -----Original Message-----
> From: David Booth [mailto:dbooth@w3.org]
> Sent: Wednesday, November 03, 2004 3:14 PM
> To: Mark Baker
> Cc: David Orchard; www-ws@w3.org
> Subject: Re: Stateful Web Services...
> 
> Mark,
> 
> On Wed, 2004-11-03 at 14:15, Mark Baker wrote:
> . . .
> > Hold the phones!  Except for credit card info, which many people
would
> > probably before not be stored on the server anyhow, I can't imagine
a
> > scenario in which any of those things would need to be sent in each
> > request.  I would guess that you're confusing the different kinds of
> > state.
> 
> I think the problem is one of language, since I know David Orchard
> understands the difference you're describing.  We do not have clear
> enough language/terminology for identifying these two concepts and
> distinguishing between them.  I think this has been a major impediment
> to discussions around them, and to people's understanding of them.
> 
> > Stateless interaction is a constraint on connectors, not
> > components.
> 
> I personally think the term "stateless interaction" is misleading, and
I
> think that Roy Fielding's use of the term "stateless" or
"statelessness"
> in his thesis is unfortunate, because people who are not aware of his
> particular use of the term consistently misunderstand it.  In section
> 3.4.3 of his thesis he explains what he means:
>
http://www.ics.uci.edu/~fielding/pubs/dissertation/net_arch_styles.htm#s
ec
> _3_4_3
> [[
> Each request from client to server must contain all of the information
> necessary to understand the request, and cannot take advantage of any
> stored context on the server.
> ]]
> 
> I personally think the term "context-free" might have been a better
> choice.
> 
> > Said another way, it's fine to have a service remember
> > stuff (component state), like a wishlist or order history, but
what's
> > not fine is if a message's semantics are a function of that state,
> 
> That's a much clearer explanation.  I think the confusion comes up
when
> referring to the concept with a brief noun phrase like "stateless
> interaction".
> 
> I'm toying with the phrase "context-free message semantics" to refer
to
> this concept.  What do you (and others) think of this term?
> 
> (I am aware of the use of the term "context-free" in "context-free
> grammers", but I don't see that as a problem.)
> 
> 
> --
> 
> David Booth
> W3C Fellow / Hewlett-Packard

Received on Thursday, 4 November 2004 00:06:59 UTC