Re: Stateful Web Services...

On Nov 3, 2004, at 6:14 PM, David Booth wrote:
> 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#sec_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.

Perhaps a little history is in order here. The first general discussion  
of stateful vs. stateless network services arose during the development  
of NFS in the early 1980s. Back then, people actually talked about all  
seven layers of the OSI reference model (how quaint), and the "state"  
that was "less" was "session state". The question on the table was,  
simply, should service requests be required to take place in the  
context of an explicitly-negotiated session, or not. The arguments pro  
and con were thrashed out fairly well (see below), and the conclusion  
was that NFS should be designed to be stateless. Roy's language cited  
above matches the historical usage pretty closely, with the  
understanding that "stored context" refers to session information. I  
can't see any good reason for creating a new term to replace one that  
has stood the test of (20 years) time.

Geoff

-------------

PS It's worth touching on a few of the arguments, since I think they  
are still relevant to the WS discussion. The language is that of file  
services; translate as appropriate.

PRO STATEFUL:
- Requests and responses can be more compact
- Requests can have sequence numbers, so that the server can detect  
duplicate and out-of-order requests. Thus requests need not be  
idempotent, and multiple-request interaction patterns can be validated
- Server resources can be allocated and released predictably, and new  
session requests can be denied if resources are not available
- Easy support for application-level requests that have natural  
"session semantics", such as file locking

CON STATEFUL:
- It is expensive to support large numbers of long-lived client  
sessions with intermittent requests, since session state must be  
maintained for each (and this is the most common use case)
- Server failure is expensive in terms of recovery unless sessions are  
persisted
- Replication and failover requires session state to be shared between  
servers - impractical
- Most "session protocols" are baroque/broke (e.g. RFC NetBIOS);  
roll-your-own is non-trivial

PRO STATELESS:
- No session protocol overhead - e.g. no protocol latency on first  
request
- Idempotency (required) makes the system robust in the face of many  
types of failures (partition, server outage, message duplication or  
re-ordering); just retry
- Compatible with UDP and TCP, and with minimal stacks
- Can support very large numbers of intermittent clients
- Server can manage resources (caches, etc.) aggressively, since loss  
of state does not break things
- Simplified server - no session state to persist, safe to reboot,  
natural extension to replicated (HA-NFS) service

CON STATELESS:
- Larger, more complex requests and responses
- Clients must use tricks such as manipulating application level state  
to coordinate certain complex operations (e.g. unlinking an open file)
- Idempotency can be very hard to get right, and sometimes compromises  
desired semantics (e.g. iterating through a potentially changing list)

Received on Thursday, 4 November 2004 05:19:39 UTC