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