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

> From: John J. Barton [mailto:John_Barton@hpl.hp.com] 
> 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. 
> 
> 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.

I am not speaking of state management strategies for the web in general
but about (XML) web services as expressed in the subject. To me, a XML
web service is a programmable service endpoint or, expressed more
broadly, some endpoint that processes and/or delivers structured and
typed (XML) data. 

It's not an interactive web-site and I believe that while the technology
set for XML web services and the interactive web is very similar, there
are vastly different rules for both spaces.

There are major differences:

Clients of Interactive Web sites typically "bind" to the next
page-handler using information contained on the "current" page. That
means that a server is capable of sending either cookies and/or
state-augmented URL to a client that the client MUST use for any further
processing, because that is the only endpoint information made available
to the client. The support for RFC2965 by all popular browsers is great
to rely on, but entirely optional and is an opt-out model for the user
agent.

Clients of XML web services typically bind to a service early, using
information contained in WSDL, other metadata format or endpooint
information made know to them through routing and referral services such
as UDDI, SOAP-RP/WS-Routing or WS-Referral. A client will therefore know
an endpoint from outside any established conversation. URL injection of
context information (very popular cookie alternative) is therefore not
an option. 

At the same time I have an issue with using transport dependent state
management mechanisms for XML web services as web service requests (even
if expected to complete synchronously) may be routed through different
protocols and the request may be routed on a different path than the
response's return path. Also, I don't see that the current definition of
RFC2965 as "optional" makes it a reliable basis for programmable
services.

Very critical, and my scenario explanation maybe wasn't clear enough
here, is that the cookie model does hardly work for cascaded services
even if they are strictly serialized and routed along the same route
back and forth. Cookies work if they are kept by the client. If a web
service client is, by itself, a web service server it may be stateless
and in that case may and should reestablish the communication context to
its downstream server for every request, with the downstream service's
client cookie falling victim to the service's statelessness when the
request has been handled. This can be fixed manually by enrolling the
cookie into the service-state, but I don't see a current web service
infrastructure that readily addresses this issue. 

What remains is a SOAP header based-solution that works without cookies
and/or URL injection. That is my point here.

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


A Cookie is some information that is pushed by the server. This header
is pushed by the client. Big difference.

I mandate that __the client__ must provide this information with every
request and that this information must be propagated to every web
service downstream within the call context. I am making state management
awareness mandatory for clients and not optional. I am saying that the
topmost client is probably the only instance that can detrmine the
boundaries of a logical call context. 

What I am proposing here is a client-controlled context that the server
MAY use to associate session information with.


Regards,
Clemens

----------------
Clemens Vasters
cofounder and CTO, newtelligence AG, Germany

MSDN Regional Director, Germany
clemensv@newtelligence.com
v-clevas@microsoft.com

Received on Wednesday, 23 January 2002 14:36:42 UTC