Re: Stateless comms in the WSA

On Tue, Aug 06, 2002 at 06:04:14PM -0600, Champion, Mike wrote:
> Uhh, how did we get from "should SOAP message receivers work off the InfoSet
> or the PSVI?" to "Should web services communications be stateless?"  Sorry
> if I'm missing something ... bad cold ... my IQ is even lower than normal
> today :~)

Heh.  Sorry, I guess the pathways between my PSVI and stateless neurons
are well lubed. 8-)

It's the same issue.  Stateless means that all the information necessary
to understand the meaning of the message, is part of the message.  The
PSVI is an example of using information outside the message to effect
its meaning, so the use of it directly contravenes statelessness.

> Also, my Religious War early-warning detectors are blinking red.  The issues
> of how web applications should manage state, and the (lamentable ?) gap
> between REST theory and CGI-hacker practice, have been beaten to death in
> every imagineable forum over the last few years with no resolution that I
> know of. (Or if there is a resolution, someone might want to post a link so
> that we can all get up to speed).  

Sure.  I don't think we need to go too far into this.  I doubt there's
much of a disconnect.  I just think we need to pick one as an
architectural constraint, and to not do so is to not do our job.  Spec
designers can choose to ignore our choice as they see fit (hence my
suggestion for 'SHOULD use "MUST NOT"'), just as the Cookies RFC
happened with Roy's help, despite his views on the architectural misfit.
I don't see any inconsistency with doing this; lay out a coherent set of
architectural constraints, and people will ignore what they think they
need to (as we've seen 8-).

> Remember, there are several things we're trying to accomplish, and Best
> Practices recommendations are only one aspect.  State management in web
> services is obviously an important topic, but again let's try to focus on
> what we want to put in the WSA document:
>
> - Where does this go in the document?  Is there a section on "state
> management" or does this cut across the whole reference architecture?

With my proposed revised TOC, we could talk about it in the section on
connector elements.  Or we could create a new section that talks
about architectural constraints.

> - What are the implications for the reference architecture?  If it cuts
> across levels/modules, how do we describe it, or is this something that
> applications simply have to figure out without help from the web services
> protocol stack?
> 
> - What are the implications for future standards activities?  Does anyone
> think there should be a State Management Working Group, or that this should
> be addressed by another WG that we might spin off?

I think it's far too early to say.  Perhaps we could block in a "state
management facility" - which BTW, doesn't have to mean that the
stateless constraint is disregarded.

BTW, I think this should all wait until after the first version of the
document.

MB
-- 
Mark Baker, CTO, Idokorro Mobile (formerly Planetfred)
Ottawa, Ontario, CANADA.               distobj@acm.org
http://www.markbaker.ca        http://www.idokorro.com

Received on Tuesday, 6 August 2002 20:57:44 UTC