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

It's very important to us that this protocol not be overly dependent on
features/facilities of a particular transport.  We are already looking at
cases, for example, where we might have a single service that connects over
HTTP to another service for a source of information, and replies over MQ.
We need solutions that will not only work on multiple transports, but
interoperate across transports.

No -- you don't need to push the full context around, but you don't have to
do you, as long as there is a standard way to pass around the information
needed to retrieve the context.  This is how we use cookies at present for
our purely HTTP based services.  So, I think this is really about how you
can provide the right context to a client, so it can pass it back to you so
you can reconstitute the correct state of the conversation.

If this is handled in the transport binding, I guess that's OK -- as long as
it's clear how to handle the cross transport hop scenario noted above.  In
similar cases involving messaging here, however, we have found the idea of
including context inside the message envelope useful for just this reason.

-----Original Message-----
From: David Orchard [mailto:david.orchard@bea.com]
Sent: Wednesday, January 23, 2002 10:54 AM
To: 'xml-dist-app'
Subject: 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 14:18:21 UTC