RE: Stateless comms in the WSA

Now comes the stateful/stateless debate...

I don't think the WSA should make a position on stateful versus stateless.

There's an *awful* lot of web sites out there that use HTTP Cookies to
contain state IDs that the server then uses to do stateful dispatching to.
Like Amazon.  I think that most people that believe in statelessness also
believe that cookies storing session IDs are bad.  I would really hate to
start precluding architectures that do work, even if they don't follow the
right "principles".

In the web, statelessness tends to make sense for a variety of reasons,
including:
- It's fairly easy to offload state to a client
- the state has a fairly small footprint
- users tend to interact with a fairly small number of sites - probably a
few thousand sites.  Combined with typical state size means that the overall
load on client isn't typically heavy.
- the interactions are generally client/server (two parties) with the client
being subordinate to the server.  And the pace of the interaction is always
at the clients control.  So it makes sense to tie the state location with
the entity performing the actions, especially when it's typically a human
using a browser.

These constraints often don't work in app to app integration though, such as
- there may be multiple connected applications.  Imagine app1->app2->app3.
Should app1 manage the state for app2 and app3's interactions?
- there may be a large number of concurrent interactions with large amounts
of state - shipping millions of interactions to a sender might not make
architectural sense
- the sender/receivers are typically peers (servers) of roughly equal
numbers, so it might not make sense to offload the state from one server to
another.
- security concerns about sending the state from one trust boundary to
another.
- the need to revalidate/regenerate the state at the receiver end may be far
more complicated than storing the state at the receiver.
- the interaction patterns may be asynchronous and much more complex than
simple request response.   Therefore senders and receivers may need to track
where they are in the interaction.

There are a number of reasons to choose stateless, and a number of reasons
to choose stateful.  I don't believe that the WSA should recommend one or
the other.

Cheers,
Dave

> -----Original Message-----
> From: www-ws-arch-request@w3.org [mailto:www-ws-arch-request@w3.org]On
> Behalf Of Cutler, Roger (RogerCutler)
> Sent: Tuesday, August 06, 2002 1:21 PM
> To: 'Mark Baker'; Champion, Mike
> Cc: www-ws-arch@w3.org
> Subject: RE: Stateless comms in the WSA
>
>
>
> I would be quite unhappy with "MUST NOT" in this context,
> although I agree
> with the general sentiment of discouraging this sort of thing.
>
> It seems to me that we can make significant progress by
> staying with the
> SHOULD's.  It appears to me that this is more consistent with
> what I see
> coming out of the TAG than a lot of MUST's.
>
> -----Original Message-----
> From: Mark Baker [mailto:distobj@acm.org]
> Sent: Tuesday, August 06, 2002 2:09 PM
> To: Champion, Mike
> Cc: www-ws-arch@w3.org
> Subject: Stateless comms in the WSA
>
>
>
> On Tue, Aug 06, 2002 at 01:44:51PM -0400, Champion, Mike wrote:
> > This is a very useful thread.  Picking up on Hal's point,
> I'd like to
> > see specific suggestions for what the WSA document should say about
> > this issue.
> >
> >
> > - What section should it be in?  Some sort of "General
> principles of
> > using XML in web services payloads maybe?"  Then we can talk about
> > SOAP's philosophy about DTDs and PIs, this general point about
> > potential security threats from the actions that schema processors
> > could perform?  We might also mention in this section that
> it is not
> > possible to use W3C DTDs or Schemas to fully validate an
> XML message
> > against the SOAP 1.1 or 1.2 specs because there is no way
> to disallow
> > processing instructions, Doctype references or DTD internal subsets
> > via any current schema language.
> >
> > - What is the implication for the architecture itself?  I'm
> not sure
> > ...does anyone think that this needs to be in the domain of
> any future
> > working group?
>
> Oh yes, most definitely.  Stateless communication is a key
> architectural
> constraint of the Web, and I've also heard many Web services
> people talk
> about its value too.
>
> > - What's the implication for Best Practice?  My personal,
> humble opinion
> is
> > something like "One MAY use W3C XML Schemas for validating
> the payload
> of
> > a web services message, but one SHOULD NOT rely on anything in the
> > PSVI that is not in the raw InfoSet representation."
>
> I'd say "MUST NOT", since to do so creates interoperability
> problems (or if
> we're giving direction to spec authors, 'SHOULD use "MUST
> NOT"' 8-).  Also,
> we should try to generalize it and use the PSVI, external
> entities, etc.  as
> examples.  There are other ways of doing the wrong thing
> here, and they're
> not all obvious.
>
> 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 18:12:42 UTC