axis-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ricky Ho <r...@cisco.com>
Subject Re: Stateful Web Services
Date Thu, 16 Jan 2003 00:35:13 GMT
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 style="rpc" 
transport="http://schemas.xmlsoap.org/soap/http"/>
                 <sb:stateful maxlifespan="3600000" idletimeout="1800000"/>
                 <operation name="getBalance">
                         <sb:stateful/>
                         <soap:operation soapAction=""/>
                         <input>
                                 <soap:body use="encoded" 
encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"/>
                                 <sb:correlation xpath="//accountNo"/>
                         </input>
                         <output>
                                 <soap:body use="encoded" 
encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"/>
                         </output>
                 </operation>
                 <operation name="deposit">
                         <sb:stateful/>
                         <soap:operation soapAction=""/>
                         <input>
                                 <soap:body use="encoded" 
encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"/>
                                 <sb:correlation xpath="//accountId"/>
                         </input>
                         <output>
                                 <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" <riho@cisco.com>
>To: <axis-user@xml.apache.org>; <axis-user@xml.apache.org>
>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.

Mime
View raw message