Re: Stateful Web Services...

On Tue, Nov 02, 2004 at 02:09:48PM -0800, David Orchard wrote:
> Exactly.  My company's literature says "can" and "where appropriate".
> Which is what I am saying.

Oh, then it seems we're actually in agreement!  I hope you'll forgive me
for not being able to conclude that from your previous claim though;

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

> Imagine if Amazon were built in a truly stateless manner.  The cost of
> sending the entire state of my interactions with amazon (my wishlists,
> previous orders, previous viewed, credit card info, etc.) to and from
> the client could be very high for large data sets.

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.  Stateless interaction is a constraint on connectors, not
components.  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, but
the message only references it rather than includes it by value.

Mark.
-- 
Mark Baker.   Ottawa, Ontario, CANADA.        http://www.markbaker.ca

Received on Wednesday, 3 November 2004 19:13:14 UTC