In general, it works by having these parties pass around a common token so that each service endpoint can retrieve the appropriate state (associated with the common token). In your example, the common token is the Client id. I think the common token can be anything extractable from the incoming message.> 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).
Basically, you identify the caller by evaluating an XPATH expression against the incoming request, and lookup an existing service instance that has a matching value.
