W3C home > Mailing lists > Public > www-ws@w3.org > December 2004

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

From: Mark Baker <distobj@acm.org>
Date: Wed, 29 Dec 2004 22:29:00 -0500
To: Robert Mark Bram <relaxedrob@optusnet.com.au>
Cc: w3c-ws <www-ws@w3.org>
Message-ID: <20041230032900.GK3676@markbaker.ca>

On Thu, Dec 30, 2004 at 12:43:20PM +1100, Robert Mark Bram wrote:
> Hi Mark,
> 
> Thank you very much for the feedback. It is most appreciated!

My pleasure!

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

Right.  In architectural terms, of the three architectural elements
(connectors, components, and data), only data is necessarily stateful
(by definition).

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

No, because the semantics of the messages are independent of the
state of the connection.

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

FTP is stateful, but it isn't for that reason.  It's stateful because
state, e.g. authentication info, current working directory, binary vs.
ascii, etc.. is associated with those connections in such a way that it
affects the semantics of other messages sent via that connection.

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

If you mean "session" in the common use of the term, then yes, but that
wouldn't be a stateless interaction.

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

Sorry, I don't understand.

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

That isn't specific to stateful interactions.  There's a caveat with
stateless interactions - you don't want to use the numbers as state
references, such as if idempotency semantics were assumed by reusing
a number - but that doesn't seem to be required for what Geoff
describes, as I understand him.

Mark.
-- 
Mark Baker.   Ottawa, Ontario, CANADA.        http://www.markbaker.ca
Received on Thursday, 30 December 2004 03:29:20 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 3 July 2007 12:25:48 GMT