RE: [wsia] [wsrp-interfaces] Another case for explicit session creation?

Title: Message

Alan,

 

This raises other questions: what happens if the portlets store data in 
the session - does each portlet now have to make sure it doesn't step on other 
portlet's data in the session? And in terms of performance and fail-over, does 
it mean that all portlets now have to be served from the same physical server in 
a load-balanced cluster (because they are sharing the same 
session)?

 

All in all, I believe if we want to allow the portal to explicitly create 
a session for multiple portlets in this scenario, we would have to (1) define 
meta-data that tells the portal when this is doable and when not, and (2) extend 
this meta-data with run-time mechanism that relates to portlet groups (so a 
portlet may be willing to run with other portlets, but then not always share the 
same session).

 

Eilon

  

  
-----Original Message-----
From: Alan Kropp 
  [mailto:] 
Sent: Wednesday, August 07, 2002 
  12:07 PM
To: ' '; 
  ' '
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: ' '; 
  ' 
' 
  
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>