OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

wsia message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Subject: Re: [wsia] [wsrp][interfaces] Session issues

   I too am disappointed that we we may need to recognize HTTP session cookies in WSRP.  My message is meant to raise an issue that seems to force us into
doing so.  You speak of a layer the producer can build to avoid this.  Can you elaborate?  My understanding is the [existing] HTTP Session load balancing
is applied [transparently] before the producer receives the request.  So I don't understand how the producer can affect this.  Are you suggesting the
producer itself implement its own load balancing mechanism after the application servers?

Carsten Leue wrote:

> Mike - I'm a bit puzzled by this proposal to explicitly refer to HTTP
> session cookies in WSRP. My take is that we should
> DEFINITELY NOT DO IT for the following reasons:
> - WSRP is not tied to any programming language or runtime environment (as
> java or j2ee). So we must not incorporate details of one of them in the
> WSRP protocoll
> - even though we decided to first concentrate on SOAP via HTTP, WSRP must
> not make any assumptions specific to this transport. I would assume that
> there will also be services that communicate via RMI, DCOM or other
> protocols via WSRP. So our work must not be tied to specific protocoll
> features.
> I can follow your arguments for the load balancing issue. But in WSRP a
> consumer talks to a SOAP service not to a servlet. If the producer decides
> to map the SOAP call to a servlet invokation then the producer has to build
> a layer that allows for proper load balancing, this is not the task of
> What do the others think?
> Best regards
> Carsten Leue
> -------
> Dr. Carsten Leue
> Dept.8288, IBM Laboratory B÷blingen , Germany
> Tel.: +49-7031-16-4603, Fax: +49-7031-16-4401
> |---------+----------------------------->
> |         |           "MICHAEL.FREEDMAN"|
> |         |           <MICHAEL.FREEDMAN@|
> |         |           oracle.com>       |
> |         |                             |
> |         |           07/22/2002 11:21  |
> |         |           PM                |
> |---------+----------------------------->
>   >--------------------------------------------------------------------------------------------------------------------------------------------------|
>   |                                                                                                                                                  |
>   |       To:       wsrp-interfaces@lists.oasis-open.org, wsia@lists.oasis-open.org                                                                  |
>   |       cc:                                                                                                                                        |
>   |       Subject:  [wsia] [wsrp][interfaces] Session issues                                                                                         |
>   |                                                                                                                                                  |
>   |                                                                                                                                                  |
>   >--------------------------------------------------------------------------------------------------------------------------------------------------|
> Folks,
>    We need to reconsider our modeling of sessions.  Recent Application
> Servers rely on the HTTP session for load balancing.  In the J2EE servlet
> world, the servlet specification allows for load balancing of servlet
> applications based on the session cookie named JSessionID.  The semantics
> are as follows:  until a session is established (until there is a cookie)
> an application server can dispatch requests across VMs/Nodes as it sees
> fit.  Once a session is established, the specification requires that all
> concurrent requests be routed to the same node.  J2EE furthermore allows
> sessions to be replicated across nodes ensuring failover consistency.  In
> J2EE app servers it is only the servlet session that is replicated, hence
> it becomes the unit for reliably maintaining state across requests.
>    The significance is that for those of us wanting to run WSRP Portlets in
> a J2EE servlet environment we need to establish and transmit the HTTP
> servlet session cookie.  This impacts our protocol in the following way:
>     a) our private sessions must be attached to the servlet session so they
> can be properly replicated
>     b) the servlet session must be established before
> getMarkup/performAction to guarantee there are no race conditions -- i.e.
> two concurrent requests to the same producer can't properly create a single
> shared session.
>     Because of these conditions, I suggest we revert to the semantics we
> defined before the F2F.
>          sessionId, timeouthint = initSession();  The producer indicates in
> its meta data whether a session is required.  If required the consumer must
> call initSession() before any call that requires a sessionId.  The
> initSession() is called once for the group of portlets intended to be
> maintained within the session.
>          As for the other calls that receive sessionIds, we need to decide
> how to handle the timeout situation.  As the J2EE servlet environment
> requires all concurrent requests running in a session (using a session
> cookie) run in the same VM, it is safe for us to allow the producer to
> reestablish the session and return it.  However, I don't know what other
> non-Java environments do and since the producer must still deal with the
> hassle of concurrent session creation, I suggest all these other methods
> merely return exceptions indicating the session has expired.  The consumer
> must then recall initSession(), and retry the operation.  If one wants to
> optimize this we could redefine initSession() so a consumer could call it
> at anytime (with the current sessionId) -- and the producer either merely
> returns the current valid ID or creates a new one -- i.e. as the
> initSession returns a hint of how long the session is maintained between
> requests, the consumer can use this information to call initSession() when
> it thinks it might need to.
>    Finally, because the shared type session is being represented, I don't
> think we should model the private session in our protocol.  Having two
> sessions is confusing and awkward.  In addition because (at least in the
> J2EE environment), the private session must be maintained within the
> servlet (shared) session, the producer mapping will have to exist anyway --
> and so rather we should reduce the burden on the consumer in maintaining
> extra state.  The implication of all this is the consumer will now have to
> send an id to the producer that it can use as a key for its private session
> data.
>          -Mike-

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Powered by eList eXpress LLC