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

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsrp-interfaces message

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


Subject: RE: [wsia] [wsrp-interfaces] Another case for explicit session cr eation?


My reply to Alan seems to have been bounced (as I'm not on wsai).
Basically, this Portal use case may argue for separating the 
http session management from the WSRP level session?

Rely to Alan:
-----------------------------------------------------------------
I do think this is a use case that is worth more consideration. 
On high latency networks, an extra round trip to establish a 
session, however, seems a high cost. Instead, the Portal consumer 
should normally use only one http 1.1 connection until it 
receives a session from the producer (i.e. it can send 
multiple getMarkup requests back-to-back on one SOAP client). 
A session is established once the consumer receives a session 
identifier (cookie) in the first reply. Once such a http session 
is established, the consumer can freely use multiple http 1.1. 
connections (but needs to include the right http session 
identifier / cookie on each http request).

Having a "batch" request mode, allowing multiple "getMarkup" 
requests in one SOAP request would help force the consumer 
to do the above but, as previously discussed, is not really
needed? The number of request to fire off on the first 
connection before waiting for a reply needs to be configurable. 
For high speed / high latency (e.g. satellite) it may be best 
to just send all.

I believe the producer should be free to implement its own 
session management and may very well use one http session / 
one cookie *per consumer to producer connection* with
connections on a *per Portal user* basis. This would be 
hidden from the Portal portlet proxy (if it actually 
compared cookie values it may find two entities have a 
common http session id) and from the Portlet entity 
which would only see its private session data. The producer 
would use the entity handle to partition the state objects 
(http session) referenced by the http session identifier 
(cookie).

The consumer would only be encouraged to use the right cookie 
value, associated with an entity by the http session identifier 
returned by the producer, and should avoid using a connection
with a different http cookie value than the one a getMarkup
request (for a user & entity combination) was previously 
made on.

The above is not meant to be prescriptive in any way but
aims to try to identify guidelines for http session management
for consumer Portals for "private" portlet sessions. 
Those shared sessions are quite another beast altogether ;-)

regards,
Andre 

-----Original Message-----
From: Rich Thompson [mailto:richt2@us.ibm.com]
Sent: 08 August 2002 13:16
To: wsia@lists.oasis-open.org; wsrp-interfaces@lists.oasis-open.org
Subject: Re: [wsia] [wsrp-interfaces] Another case for explicit session
creati on?



We do have to be careful about violating the current design also. This
essentially changes the session concept away from the current private
session to a shared session. The discussions on the telecons have settled
for providing an initEnvironment() type of operation that would allow any
such shared session initilization. One thought being explored is whether
having this as a separate portType would be a very clean way for a Producer
to indicate whether such an invocation is useful.


 

                      Alan Kropp

                      <akropp@epicentri        To:
"'wsia@lists.oasis-open.org '" <wsia@lists.oasis-open.org>,     
                      c.com>
"'wsrp-interfaces@lists.oasis-open.org '"                                
 
<wsrp-interfaces@lists.oasis-open.org>                                   
                      08/07/2002 12:06         cc:

                      PM                       Subject:  [wsia]
[wsrp-interfaces] Another case for explicit session      
                                                creati   on?

 

 

 




Not sure this went through the first time..

-----Original Message-----
From: Alan Kropp
Sent: Tuesday, August 06, 2002 11:49 PM
To: 'wsia@lists.oasis-open.org '; 'wsrp-interfaces@lists.oasis-open.org
'
Subject: [wsia] [wsrp-interfaces] Another case for explicit session
creation?


I'd like to open another thread for the explicit session creation question.

In the standard portal situation, end users configure their own aggregate
views or "pages" of the available portlet services.  When an end user first
accesses their customized page, the portal needs to ask each of the
portlets
on the page to render their markup, assembles the page, and then presents
it
to the user.

Consider for the sake of argument that a theoretical page is composed of
five portlets, all of them remote portlets served by a single Producer.
The
portal has already created and configured the necessary entities.

In the portal startup case, the portal will send five individual requests
to
this Producer, each of them targetted at a different entity.  As there are
no sessions in effect yet, the Producer in turn creates a session for each
entity, and passes back the handle in the individual getMarkup response.

It would be more efficient for the portal, however, if there was just one
session created by the Producer, grouping all of the entities into a single
session.  Otherwise, the portal must now map the end user's request scope,
which in the standard http case is a single http session, to multiple
Producer sessions, and it must be certain to put the correct session ID
into
the performInteraction/getMarkup for each entity.

The portal could explicitly request a Producer session ahead of any calls
to
getMarkup, and pass this sessionID to getMarkup for all of that Producer's
entities.

----------------------------------------------------------------
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>


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


Powered by eList eXpress LLC