RE: [wsrp-interfaces] [wsrp][interfaces] Session issues

[michael_hillerman@peoplesoft.com]

The issue of maintaining the session cookie for load balancing is really a
symptom of a larger issue that we need to examine.  The WSRP Consumer must
act as a broker between a WSRP Client and multiple Producers providing
services that may be specific for the Client.  Therefore, the Consumer must
maintain the semantic integrity of the transport protocol that it is
brokering between the Client and the Producer.  In other words, the
Consumer is acting as a Client to the Producers on behalf of the true
Client.  If the transport protocol allows data members to be passed between
its client and server and those data members are expected to be returned on
subsequent communications, then the WSRP Consumer must ensure that it's
Consumers honor the transport protocol's requirements as it brokers between
the Client and the Producer.

Why is this important?  Any transport protocol that enables stateful scope
between communications on the server must pass some kind of identifier to
the client and expect it to be returned to the server on subsequent
communications.    The HTTP session cookie is one example, but I suspect
(although I don't know this for certain) that other transport protocols
that enable cross communication scope on the server will have something
similar.  In addition to scope identifiers, the runtime systems that are
hosting producers may use additional data members at the transport protocol
level for other purposes.  One example in the HTTP world is a single signon
product that relies on a cookie to be set on the User Agent and returned to
all servers on the same domain.

For HTTP superficially, the WSRP Consumer must act as an HTTP User Agent on
behalf of the WSRP Client and it must insure the integrity of the HTTP
communications between the User Agent and the Producer.  For example:

*  Client A logs into Consumer 1.
*  Consumer 1 retrieves markup for an Entity from Producer 1.
*  In doing so Producer 1 set an HTTP cookie for whatever reason (session
cookie, SSO cookie, or something else we have not anticipated)
*  Consumer 1 returns page to Client.
* Client A performs an action on Producer 1's Entity.
* Consumer 1 must pass the cookie back to Producer 1 on the HTTP
communications for performAction and getMarkup.

Now let's complicate this a bit:

*  Client A logs into Consumer 1.
*  Consumer 1 retrieves markup for an Entity from Producer 1 on behalf of
Client A.
*  In doing so Producer 1 sets the HTTP cookie "X " for whatever reason
(session cookie, SSO cookie, or something else we have not anticipated)
*  Consumer 1 returns page to Client.
*  Client B logs into Consumer 1.
*  Consumer 1 retrieves markup for an Entity from Producer 1 on behalf of
Client B.
*  In doing so Producer 1 sets the  HTTP cookie "Y" for whatever reason
(session cookie, SSO cookie, or something else we have not anticipated)
*  Consumer 1 returns page to Client.
* Client A performs an action on Producer 1's Entity.
* Consumer 1 must pass cookie "X", but not cookie "Y", back to Producer 1
on the HTTP communications for performAction and getMarkup.

The WSRP protocol needs to be clear about the transport protocol
requirements of the Consumer as it acts as a client to the Producers server
on behalf of the WSRP Client.  I don't think it needs to specify what the
specific requirements of each transport protocol, but rather is must be
clear that the Consumer must maintain the semantic integrity of the
transport protocol communications it is brokering between the WSRP Client
and Producer.

An alternative view is that the WSRP Consumer is not brokering the
transport protocol.  Instead the communication between the Client and the
Consumer is independent of the communication between the Consumer and the
Producer.  While cleaner, this seems very impractical to me.  The existing
infrastructure to support web application developers (things like web app
servers, load balancers and single signon products) is already in place in
mass and should be leveragable by WSRP Producers.  Otherwise adoption of
the WSRP standard will be delayed until these infrastructure pieces are in
place for "pure" SOAP web services.

- Mike


Subject: [wsrp-interfaces] Re: [wsia] [wsrp][interfaces] Session issues
      From: Carsten Leue <CLEUE@de.ibm.com>
      To: "MICHAEL.FREEDMAN" <MICHAEL.FREEDMAN@oracle.com>
      Date: Tue, 23 Jul 2002 13:19:02 +0200


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-