Re: Web Services and Distributed Object Systems: a Difference in State.

Hi Mark,

Thank you very much for the feedback. It is most appreciated!

> I think a point of confusion remains in this article.  I agree that
> Roy's terminology in his dissertation is a little bit confusing, but
> where he refers to "client-stateless-server" (that you reference),
> the "stateless" part there isn't an adjective for the noun "server",
> it refers to the connector.  It's true that stateless servers, by
> definition, can only participate in stateless exchanges, but the
> converse isn't true

This is a most interesting distinction that I had not taken into account 
thus far. There are three components in a networked application that may 
or may not have some notion of state: client, service and connector 
(communication mechanism).

HTTP is a stateless connector. But doesn't HTTP 1.1 include persistent 
connections? This must introduce some idea of state.

FTP is an example of a stateful connector since it defines messages 
specifically to open and close connections.

> a server with state can still participate in
> stateless message exchanges.  It just can't have *session* state, aka
> state which can be referenced by messages for the purpose of
> affecting the semantics of those messages.

This still confuses me. What about web applications where the HTTP message 
has a header containing a session ID; isn't this an example of a stateful 
server whose messages reference state?

Or is it the case that when you say "can't have *session* state" you are 
referring to "session state" as being messages whose type changes (as in 
FTP) as opposed to changing content (as in HTTP).

> Regarding "stateless clients", I don't think that's what you mean to
> be discussing.  AFAIK, the only "stateless client" architectural styles
> are "remote session" styles like telnet or VNC where session state is
> *entirely* on the server.  What you appear to be describing in those
> two sections are styles where the state of any session is split between
> client and server.

Good point. I shall correct this.

> I disagree with your summation of the tradeoffs of stateless vs.
> stateful when you say "a stateful server [...] is more amenable to
> message sequences i.e. application level protocols.".

Can you elaborate further on this?

In that section of the article I meant to refer to this message in the 
"Stateful Web Services" thread:
http://lists.w3.org/Archives/Public/www-ws/2004Nov/0018.html
(I have just corrected the link).

In the "PRO STATEFUL" list I found:
- 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

Regards,

Rob
:)

-- 
Robert Mark Bram
http://phd.netcomp.monash.edu.au/RobertMarkBram/default.asp
B.Comp.(Systems Development/Business Systems)
B.Net.Comp.(Hons)
Doctor of Philosophy Student

School of Network Computing
Faculty of Information Technology
Monash University
Peninsula Campus
McMahons Rd
Frankston, VIC 3199
AUSTRALIA

Received on Thursday, 30 December 2004 01:43:11 UTC