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

[Alan Kropp <akropp@epicentric.com>]

<AKropp>commentary...</AKropp> inline

-----Original Message-----
From: Alejandro Abdelnur [mailto:alejandro.abdelnur@sun.com]
Sent: Saturday, July 27, 2002 2:02 AM
To: interfaces
Subject: Re: [wsrp-interfaces] [wsrp][interfaces] Session issues



It seems this topic will one on the top of the charts the next 2 weeks.
As today I'm going on vacations for 2 weeks I wanted to express my opinion.

I agree with many of both Mikes comments.

I've splitted my comments in two sections, private/shared session and 
session management.

Talk/email you in 2 weeks.

Cheers.

Alejandro

---------------------------------------------------------------------
* Private/shared session

I think WSRP should model sessions between the consumer and the 
producer, not between the consumer and entities. Consumers and producers 
are at the same level in the stack. Consumers and entities are in 
different levels, entities are on level up. To me it seems odd having 
elements of different levels in the stack, on different sides of the 
communication to talk with each other (I'm picturing the OSI stack from 
my networking class in college).

<AKropp>
Yes, maybe from a strict layering approach this may seem unusual, but is
that alone a good reason to discard the per-entity session concept?  I think
a stronger argument could be made that the single shared session maps more
closely to the JSR168 session model, not to mention today's J2EE app
servers.  

That said, I think whether there's a single shared session that the Producer
partitions into per-entity (per-client?) "scopes", or there's a single
independent session for each of the Producer's entities, is semantically
equivalent, and perhaps more of an implementation detail.  In either case,
the Consumer request is re-connected to the proper state because it includes
a handle to the Producer session, and the Producer can use the context
conveyed in the request to narrow the scope further, if needed. 
</AKropp>

In other words, WSRP should model what we've been referring as shared 
sessions. This does not preclude simple producers, with just one entity 
to handle sessions with consumers, they would be shared session for a 
single entity (thus being private session because it is not being shared).

For a given client a consumer may need to maintain sessions with the 
producers hosting the entities the client is using. If more than one of 
the entities are hosted in the same producer, a single session between 
the consumer and the producer can be used for all the entities residing 
in the producer. Each call indicates what producer entity is being 
invoked. It's up to the producer to provide a shared context (or not) 
for all the entities that are called using the same session. Complex 
producer may implemen this sharing, simple producers may not.

Note that this is how HTTP manages a single sessions for different 
resources, a Cookie identifies the session and the URL identifies the 
resource.
---------------------------------------------------------------------
* Session management

I agree that we shouldn't expose HTTP or SOAP to WSRP, even if most (if 
not all) will be using HTTP and SOAP.

In my opinion, what we should do is to define the requirements the 
transport must fulfill. In the case of SOAP, it should be required that 
HTTP Cookies should be appropiately handled by the underlaying SOAP 
implementation. This wouldn't be a problem for many of the current SOAP 
implementations that are out there. This would take care of the 
mentioned load balancing issues. Also, other load balancing 
technologies, such as Resonate, use a similar mechanism (routing to 
different notes based on the value of a cookie).

<AKropp>
Is it realistic for us to state this requirement in the short (or even
medium) term?  It seems like we're saying WSRP 1.0 is unusable in a
load-balanced J2EE environment until SOAP implementers build HTTP
cookie-handling into their stacks.  We need to demonstrate WSRP 1.0
usability in an LB environment, and this where our proof-of-concept
implementation can show the way.  I thought Carsten alluded to a special
cookie handling layer as one possible implementation, in one of his
responses to Mike's message below...Carsten, any thoughts to share on that?
<AKropp>

A consumer would have to keep track of the different 'transport 
connections' for its different users. Or it could choose to pass the 
'transport connection' information all the way to the client not to keep 
state on it (I'm thinking SOAP and HTPT Cookies here).

Assuming we require the transport (SOAP) to manage sessions (Cookies). 
We do not need to have, in the WSRP protocol, the groupID going from the 
consumer to the producer or the session ID coming back to the consumer 
from the producer. Sessions are handled by the underlying transport.

<AKropp>
I don't see how we can make this requirement.  The protocol isn't even
necessarily tied to a SOAP implementation, it could be implemented on
something really bare-bones...it seems to me that exposing the session
handle in the WSRP interface is a small concession for better
interoperability.  Otherwise, we're pretty much saying here that it's not
possible to write a WSRP implementation on top of anything but J2EE.
</AKropp>

What we need to model appropiately, it is how a session is created 
between a consumer and a producer to avoid the concurrency problem (more 
than one simultaneous call from a consumer to the same producer on 
behalf of the same user when a session does not yet exist). I see a few 
  ways this could be done (some more elegant than others):

1) Entity metadata would indicate if the entity requires a session or 
not. The WSRP protocol a method so the consumer can tell the producer to 
create a session. the consumer should make this call before calling the 
entities in the producer.

2) Entity metadata would indicate if the entity requires a session or 
not. If there is not session between a consumer and a producer, the 
consumer must not parallelize the calls to different entities for the 
same user, it must make a call for one entity first and once that the 
call is completed (and the transport has established a session) it may 
proceed with parallel calls.

3) Using the call/fail mechanism discussed by email and in conference 
calls before the second face 2 face meeting.
---------------------------------------------------------------------



michael_hillerman@peoplesoft.com wrote:
> 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-
> 
> 
> 
> 
> 
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>



----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>