Hi,
I think solving the problem at the SOAP level (using headers) or at the
HTTP level (using cookies) is looking at things in a limited way.
Ultimately statefulness requirements have to be described at a higher level
(e.g. in WSDL) and then bound to various protocol-specific mechanisms, so
if your port type with state happens to be using SOAP, then SOAP headers is
how the binding might choose to support that requirement of your abstract
interface. If instead you bind to XYZ protocol you might use something
else.
Nirmal.
"Steve Loughran"
<[EMAIL PROTECTED] To: <[EMAIL PROTECTED]>
om> cc:
Subject: Re: Stateful Web Services
01/15/2003 08:34
PM
Please respond to
axis-user
----- Original Message -----
From: "Ricky Ho" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Wednesday, January 15, 2003 16:35
Subject: Re: Stateful Web Services
> I think reinventing the idea of cookies at the SOAP header will solve the
> tight transport-level coupling issue you mention. However, the "session"
> model is still based on a "1-to-1" interaction model (in other words, the
> session id is only known by the TWO parties who are talking) doesn't fit
> well into a multi-party conversation. Think about the following ....
>
> 1) Client ---(sessionX)---> ServiceA ---(sessionY)---> ServiceB Lets
> say some stateC is stored under sessionY
> 2) Client ---(sessionZ)---> ServiceB There is no way for the client to
> access stateC here
I see: just like today's problems that stop cookies working across domains.
> So instead of using an "explicit" session id to represent the session, I
> like better the idea that the "session" can be derived from the message
> itself. In the previous example David gave, that means I look for the
> "bank account number" from the message to identify a session, regardless
of
> cookies or who is sending that. Yes, I'm talking about "session" in a
> broader context, not just a "login-session".
ok, so how do you identify the caller? does Client pass in a client guid,
then service A tells service B to create a session visible to that Client
Id
and the serviceA id it storees in its sessionX info? So when the client
starts up session Z it sends the same client info and everything falls into
place, (except for anonymity and session theft).
I can see that I need to look at the prior art here.
