RE: Stateful Web Services...

Stateless targets a particular style of interaction.  It's typically
where:
- there's a small # of services with large #s of users
- the service doesn't really care whether the client calls back or not
- the state exchanged is fairly small
- the message exchange pattern is fairly low in volume (not multiple per
second invokes from a given client).

Arguably, stateless works for human kinds of interactions: lots of
people filling out shopping carts over the course of minutes.

If these, and other, kinds of constraints aren't true, then the service
will probably be stateful.  Almost all b2b and eai interactions and even
most shopping carts are stateful.

We can absolutely scale stateful or stateless.  My company makes
software that can do stateful invokes with a margin of error to
stateless invokes.  The argument that "stateful" can't scale has been
proven incorrect.

Stateful vs stateless is really a question of trade-offs of desired
properties that the service provider makes, and scale is not one of
them. 

Dave

> -----Original Message-----
> From: [email protected] [mailto:[email protected]] On Behalf
Of
> Mark Baker
> Sent: Friday, October 29, 2004 11:14 AM
> To: Mullins, Chalon
> Cc: 'Savas Parastatidis'; [email protected]; Ian Foster; Carl Kesselman;
Steve
> Graham; Steve Tuecke
> Subject: Re: Stateful Web Services...
> 
> 
> On Fri, Oct 29, 2004 at 08:30:31AM -0700, Mullins, Chalon wrote:
> > You cannot scale large systems if you have to assume all state has
to be
> > transferred every time.
> 
> Actually, the opposite is true.  The largest information systems we
> humans have built have been stateless.  The Web (at least the bulk of
it
> which doesn't use cookies) is perhaps the best example, but email
would
> be another one.
> 
> See;
> 
>
http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm#s
ec
> _5_1_3
> 
> Mark.
> --
> Mark Baker.   Ottawa, Ontario, CANADA.        http://www.markbaker.ca