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