MHonArc v2.5.2 -->
wsia message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [Elist Home]
Subject: Re: [wsia] [wsrp][interfaces] Session issues
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
WSRP.
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