Re: Stateful Web Services...

David,

| I think the problem is one of language...

Absolutely, it begins there.

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

Yes, but the term was already in use years before Roy
wrote the thesis.  I remember hearing it in the early 90's.

| I personally think the term "context-free" might have been a better
| choice.

Well, context in this case is state, so I think  you are
back where you started.  The interaction would never be context
free.  The context must exist for the parties to coordinate.

["Stateless" is a contraction of "stateless server", and the "state"
in "stateless" is a contraction of "conversational state".  So if you
know where the term comes from, it's okay.  Sort of.]
  
| 
| > 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".

That is certainly confusing, but the underlying concepts are not
that clear either, and there's a bigger problem there, I think, in terms
of understanding scaleability tradeoffs.

Here's a stateful interaction:

C: How much is a ticket from NYC to Boston on the 20th?
S: $50.
C: How much is it round trip?

The "stateless server" principle says that for the server to be able
to answer the client's second question, it has to sacrifice some
ability to service larger numbers of clients.

However, if instead of the above, the client posts an incomplete
order for a ticket, the server creates a resource
from that, and the client can then complete the order via reference
to that resource, you technically have a "stateless interaction",
but the burden on the server is essentially the same.  I.e., it does
not know how long to hold the incomplete order, it must hold
one for each client that behaves this way, etc.

In other words, how does the model really change when we
simply give some conversational state a "promotion"?  Could be
this is what Dave is referring to when he says "it depends".  I
don't like that answer much, but nor do I like the idea that if we
call it component state instead of connector state, somehow the
bits are smaller.

Walden

Received on Wednesday, 3 November 2004 23:56:09 UTC