Re: Stateful Web Services

Ricky Ho Wed, 15 Jan 2003 16:35:21 -0800

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

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

Back to the Bank Account example, something like this ...

<?xml version="1.0"?>
<definitions .... xmlns:sb="www.xyz.com/stateful-behavior">
        <message .../>
        <portType name="BankAccountPT">

        .....
        </portType>
        <binding name="BankAccountBinding" type="BankAccountPT">

<soap:binding transport="http://schemas.xmlsoap.org/soap/http"/>

<sb:stateful maxlifespan="3600000" idletimeout="1800000"/>

<sb:stateful/>

<soap:operation soapAction=""/>

<input>

<soap:body use="encoded" encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"/>

<sb:correlation xpath="//accountNo"/>

</input>

<soap:body use="encoded" encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"/>

</output>

</operation>

<sb:stateful/>

<soap:operation soapAction=""/>

<input>

<soap:body use="encoded" encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"/>

<sb:correlation xpath="//accountId"/>

</input>

<soap:body use="encoded" encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"/>

</output>

</operation>
</binding>
</definitions>

Rgds, Ricky

At 03:12 PM 1/15/2003 -0800, Steve Loughran wrote:

----- Original Message -----
From: "Ricky Ho" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Wednesday, January 15, 2003 14:13
Subject: RE: Stateful Web Services

> Most Java-based SOAP engine (over HTTP) implementation leverages the
> Servlet model which allows you to specify whether the service
> implementation object is "request", or "session", or "application" scope.
>
> But there is no industry standards around this, and there is no way to
> communicate this stateful behavior in any standardized way. Some
companies
> (I think BEA is one) proposed a SOAP header structure to do the equivalent
> of cookies, but I don't see a wide adoption there, the closest one I've
> seen is the "correlation set" idea (actually more powerful than the
session
> model) in BPEL4WS.

I think one of the many GXA specs coming from the sea-tac conurbation
include some session header info, at least I recall Don box hinting at it
some time last october.

The weakness of cookies is they are transport specific and very dependent
upon implementations of HTTP, some particular weak implementations
(java.net.HttpUrlConnection) handle cookies badly (it used to let you set >1
cookie, but them someone fixed it in 1.3 to stop you doing that).

but I like them as they are simple, integrate well with the server, and
integrate with load balancing level seven routers, things like ArrowPoints
that make sure that requests to a cluster go back to the previous server,
provided it is still happy.

I dont see any soap header aware routers around, and given the lack of a
standard header that isnt surprising, ignoring the details of how hard it
would be to buffer and route inbound messages without actually parsing bits
of them.

Re: Stateful Web Services

Reply via email to