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

Good question.  As far as I know it's not a problem for CORBA, because it
already has a context passing mechanism, but more importantly because it is
a spec which implementers have to follow, rather than vice versa, which is
the case with respect here, since the transports are already defined and we
have to follow them.  We've run into the problem with JMS, however, because
of the freedom the spec gives JMS providers in handling header information
-- especially because the content of the information differs from one
provider to another, so you can't just do a get header, set header thing.
Moreover, there's some transport specific stuff in messaging not defined in
JMS headers as well.  This is why we've had to develop something similar
here for cross-transport hops in a messaging approach.

-----Original Message-----
From: Eugene Kuznetsov [mailto:eugene@datapower.com]
Sent: Wednesday, January 23, 2002 12:33 PM
To: Mullins, Chalon; 'David Orchard'; 'xml-dist-app'
Subject: RE: FW: Why web-style session state management doesn't work for
web services, methinks


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

That makes a lot of sense to me. Maintaining this session 
information across transport hops is hard, and it places 
an additional requirement on all transport bindings in 
existence now or developed in the future to provide 
"cookie" capability that maps to that of other transports. 

To approach this from a different direction and (on the 
larger question about multiple cascading requests), how
is all this different from CORBA object service contexts 
and RequestID's? other existing object/RPC contenxt-management
mechanisms? 



\\ Eugene Kuznetsov
\\ eugene@datapower.com
\\ DataPower Technology, Inc.

Received on Wednesday, 23 January 2002 16:26:56 UTC