RE: FW: Why web-style session state management doesn't work for web services, methinks

I can't see web services pushing the full context between sender and
receiver just to manage state.  Then the server/receiver is subject to the
whims of the sender, a key security consideration.  The receiver will want
to control the contents of the state, it's timeout, the # of them,
passivation to disk, etc.

Also, if you push the state management to the sender, all you've done is
move the problem of storing the bag of bits around.  The sender would have
to store the entire context of each receiver it's talking to.  The web model
especially works because it is optimized in this way (and in sooo many
others) to place minimal constraints upon the client and be robust in case
of malformed and/or numerous clients.

So the cookie model (opaque IDs controlled by receivers and returned to
senders) is a useful model for web service session management, methinks.  It
doesn't work for truly asynch services as the receiver may not be able to
get ID back to the sender - but it certainly works for HTTP interactions.
Presumably HTTP is the most common transport for web services.

Cheers,
Dave


> -----Original Message-----
> From: xml-dist-app-request@w3.org
> [mailto:xml-dist-app-request@w3.org]On
> Behalf Of John J. Barton
> Sent: Wednesday, January 23, 2002 10:34 AM
> To: Clemens Vasters; 'xml-dist-app'
> Subject: Re: FW: Why web-style session state management
> doesn't work for
> web services, methinks
>
>
> At 08:24 PM 1/18/2002 +0100, Clemens Vasters wrote:
> <snip>
> >----
> >
> >Now, thinking about this, I have come to the conclusion that the
> >web-style approach to state management using any of these three
> >techniques is (!) utter nonsense (!), because they are all based on a
> >completely wrong assumption. They still assume that the client is
> >completely dumb and just smart enough to push back an opaque
> value that
> >the server is providing. It is also based on the assumptions that the
> >transport is HTTP and that web service call sequences are never
> >cascading.
>
> Actually I think that dumb clients and the storage of opaque
> content in service offerings (downloaded web pages) by servers
> are key reasons for web technology success.  The approach prevents
> clients from being bound to one kind of web service and it allows
> servers to avoid maintaining session state by sending context back
> to the client.  The first advantage supports spontaneous interaction:
> I don't need a book-buying app to use Amazon.com and Amazon.com can
> sell software without a new distribution of their amazon app.  The
> second advantage aids scaling as servers avoid storing a zillion
> partial transactions.
>
> <more cut>
>
> >Therefore it's my current state of opinon, that a SOAP header is
> >required that defines the current call context and the context origin
> >that must be understood by all state managing services.
> >
> >To illustrate my point:
> >
> ><ctx:context contextId="uuid:0B4E71D0-5383-4db2-9BA5-EE17B7E46627"
> >              contextExpires="2001-18-01T23:00:00+01:00"
> >              soap:mustUnderstand="1"
> >
> xmlns:ctx="urn:schemas-newtelligence-com:soap:contexts"/>
>
> Looks like a cookie to me.
> ______________________________________________________
> John J. Barton          email:  John_Barton@hpl.hp.com
> http://www.hpl.hp.com/personal/John_Barton/index.htm
> MS 1U-17  Hewlett-Packard Labs
> 1501 Page Mill Road              phone: (650)-236-2888
> Palo Alto CA  94304-1126         FAX:   (650)-857-5100
>

Received on Wednesday, 23 January 2002 13:58:14 UTC