RE: [wsia] RE: [wsrp] Sessions and Transient Entities

[Rex Brooks <rexb@starbourne.com>]

Title: RE: [wsia] RE: [wsrp] Sessions and Transient Entities

Excuse me for saying in advance that what follows is just my best understanding at present, and represents my opinion, not a statement of consensus even if it sounds like that's what I'm saying. It is just easier for me to make statements than to hem and haw around a point in order to find a very politically correct and inoffensive way to phrase things.

I thought that consumers asked for sessions from producers who provide portlets/entities, and it is the producer who gives a session a sessionID. As of now we have only defined a session to the extent that it is specific to a single producer to a single consumer to a single end-user. We haven't successfully approached consensus other than that AFAIK.

We have not yet adopted or reached consensus on how more than one producer's portlets can be included in some concept of a shared session. However...

A consumer can have as many portlets from as many producers as needed for an individual end-user and how it manages that operation is up to the consumer. I don't understand what the spec can do to make that easier or more manageable.  In the case of a number of producers in sequence the problem would get worse with each producer-consumer pairing.

Portlets from different producers don't need to know about each other unless we burden the specification with a process for doing so. That it would make some combinations of specific pairings easier to manage for some consumers is without doubt, but we need to weigh the cost to all.

Portlets from a single producer MAY know about each other at the discretion of the producer. The consumer MAY ask to know if portlets from a single producer have knowledge of each other in a session those portlets share from that producer, and it is up to the producer to allow the consumer to know whether those portlets share their state information within that kind of shared session. IMO portlets from different producers SHOULD NOT be required to share sessions.

Where 90 percent of the confusion over this issue has arisen is from the notion that a consumer creates a session, which we have held all along was a function of the producer because the producer has to manage its sessions and entities in order to return the correct portlet/entity to each consumer's requests and so gives it the sessionID for that purpose. The need for a consumer to have the ability through the specification to create a named session that combines portlets from more than one producer is the real sticking point, no matter how many ways you find to say it in different words.

I suspect my position on that is apparent. However, as always, I will go along with the consensus.

Ciao,

Rex

At 3:05 PM -0400 6/18/02, Eilon Reshef wrote:

> Can you elaborate on why you believe it is useful for
> the portlets not to know who they are sharing the state
> with?
> > -----Original Message-----
> > From: Carsten Leue [mailto:CLEUE@de.ibm.com]
> > Sent: Tuesday, June 18, 2002 2:20 PM
> > To: Eilon Reshef
> > Cc: 'Michael Freedman'; wsia@lists.oasis-open.org;
> > wsrp@lists.oasis-open.org
> > Subject: RE: [wsia] RE: [wsrp] Sessions and Transient
> > Entities
> >
> > Of course the portlets need to be
> > prepared. But the portlet would not know
> > with what other portlet is should share the session.
> > Only the consumer
> > knows this..
> >
> > Best regards
> > Carsten Leue
> > -------
> > Dr. Carsten Leue
> > Dept.8288, IBM Laboratory Böblingen ,
> > Germany
> > Tel.: +49-7031-16-4603, Fax:
> > +49-7031-16-4401
> >
> > |---------+----------------------------->
> > |        
> > |           Eilon
> > Reshef      |
> > |        
> > |          
> > <eilon.reshef@webc|
> > |        
> > |          
> > ollage.com>       |
> > |        
> > |                             |
> > |        
> > |          
> > 06/18/2002 06:36  |
> > |        
> > |          
> > AM                |
> > |        
> > |           Please
> > respond to |
> > |        
> > |           Eilon
> > Reshef      |
> > |        
> > |                             |
> > |---------+----------------------------->
> >  
> > >---------------------------------------------------------------------------------------------------------------------------------------------|
> >  
> > |                                                                                                                                             |
> >   |      
> > To:       Carsten
> > Leue/Germany/IBM@IBMDE                                                                                             
> > |
> >   |      
> > cc:       "'Michael Freedman'"
> > <Michael.Freedman@oracle.com>, wsia@lists.oasis-open.org,
> > wsrp@lists.oasis-open.org                   
> > |
> >   |      
> > Subject:  RE: [wsia] RE: [wsrp] Sessions and Transient
> > Entities                                                                       |
> >  
> > |                                                                                                                                             |
> >  
> > |                                                                                                                                             |
> >  
> > >---------------------------------------------------------------------------------------------------------------------------------------------|
> >
> > Can you please elaborate on this - what
> > would be a working scenario where a
> > Consumer decides to group portlets without the
> > portlets pre-programmed to
> > be shareable?
> >       -----Original
> > Message-----
> >       From: Carsten Leue
> > [mailto:CLEUE@de.ibm.com]
> >       Sent: Monday, June 17,
> > 2002 12:21 PM
> >       To: Eilon
> > Reshef
> >       Cc: 'Michael Freedman';
> > wsia@lists.oasis-open.org;
> >      
> > wsrp@lists.oasis-open.org
> >       Subject: Re: [wsia] RE:
> > [wsrp] Sessions and Transient Entities
> >
> >       Eilon
> > -
> >
> >       because the
> > consumer may want to decide which portlets to group
> >       together in
> >       a session. The producer
> > would not be able to do so.
> >
> >       Best
> > regards
> >       Carsten Leue
> >
> >      
> > -------
> >       Dr. Carsten
> > Leue
> >       Dept.8288, IBM
> > Laboratory Böblingen , Germany
> >       Tel.: +49-7031-16-4603,
> > Fax: +49-7031-16-4401
> >
> >      
> > |---------+----------------------------->
> >      
> > |        
> > |           Eilon
> > Reshef      |
> >      
> > |        
> > |          
> > <eilon.reshef@webc|
> >      
> > |        
> > |          
> > ollage.com>       |
> >      
> > |        
> > |                             |
> >      
> > |        
> > |          
> > 06/12/2002 02:49  |
> >      
> > |        
> > |          
> > AM                |
> >      
> > |        
> > |           Please
> > respond to |
> >      
> > |        
> > |           Eilon
> > Reshef      |
> >      
> > |        
> > |                             |
> >      
> > |---------+----------------------------->
> >        
> > >
> >      
> > ---------------------------------------------------------------------------------------------------------------------------------------------|
> >
> >        
> > |
> >       |
> >
> >        
> > |      
> > To:       "'Michael
> > Freedman'"
> >      
> > <Michael.Freedman@oracle.com>,
> > wsia@lists.oasis-open.org,
> >      
> > wsrp@lists.oasis-open.org                   
> > |
> >
> >        
> > |       cc:
> >       |
> >
> >        
> > |       Subject:  [wsia] RE: [wsrp]
> > Sessions and Transient Entities
> >       |
> >
> >        
> > |
> >       |
> >
> >        
> > |
> >       |
> >
> >        
> > >
> >      
> > ---------------------------------------------------------------------------------------------------------------------------------------------|
> >
> >       If a simple
> > group-id within the portlet UI takes care of the issue
> >       (which I
> >       agree with), why bother
> > to allow the Consumer to create and manage
> >       sessions
> >       explicitly (versus
> > implicit creation by the Producer)?
> >
> >       
> > -----Original Message-----
> >       From: Michael Freedman
> > [mailto:Michael.Freedman@oracle.com]
> >       Sent: Tuesday, June 11,
> > 2002 7:43 PM
> >       To:
> > wsia@lists.oasis-open.org; wsrp@lists.oasis-open.org
> >       Subject: Re: [wsrp]
> > Sessions and Transient Entities
> >
> >            
> > Eilon,
> >               I think your suggestion intermixes 2 different
> > concepts --
> >       that of
> >            
> > session identity and that of instance/entity identity. 
> > My
> >       scenario 1
> >            
> > concerns itself with how an instance/entity id can be used
> > to
> >      
> > segment
> >            
> > data within a session.  My scenario 2 concerns itself with
> > how
> >            
> > distinct sessions can be established/maintained.  I
> > suggested
> >       we
> >            
> > don't define a way for the producer to describe its
> > grouping
> >       rules.
> >            
> > Rather a consumer can choose to support grouping (via a
> >       mechanism
> > its
> >            
> > free to define) or leave it up to the consumer to handle
> >       internally
> >            
> > (via perference/configuration data).  So in my scenario 2,
> > a
> >       consumer
> >            
> > isn't responsible for separating the portlets into
> > different
> >            
> > sessions.  It merely is allowed to do so.  Portlets must
> > assume
> >       they
> >            
> > aren't running in such environments -- rather they must
> > assume
> >       they
> >            
> > run in a shared session world -- hence they need an ID to
> > do
> >       the
> >            
> > proper namespacing.  As the consumer doesn't know this
> > grouping
> >            
> > (because it doesn't implement grouping) the producer must
> >       provide its
> >            
> > own UI for getting these keys -- i.e. the producer must
> > provide
> >       a
> >            
> > configuration/personalization UI that allows a group key to
> > be
> >            
> > specified for each of its portlets -- it can then use this
> >      
> > "internal"
> >            
> > group id to key/separate data in the shared session.
> >
> >            
> > Just a long way of saying -- I don't buy your scenario 2. 
> > If
> >       the
> >            
> > consumer knows the grouping, I would rather the consumer
> >       maintain 2
> >            
> > discrete sessions as this allows it to continue to pass the
> >       entity id
> >             so
> > each entity can maintain entity specific data if necessary
> >       (i.e.
> >            
> > portlet A, B, B' in the same session/group -- B and B' can
> > keep
> >       their
> >            
> > data separate).  If the consumer doesn't know the grouping
> > then
> >       it
> >            
> > controls things just like scenario 1.  The producer is free
> > to
> >            
> > define/manage finer granularity as described above.
> >                  -Mike-
> >
> >            
> > Eilon Reshef wrote:
> >                    Mike,Per your
> > recent e-mails, I think that the approach
> >       makes
> >                   sense.The only thing that
> > concerns me is that we have two
> >                   different mechanisms to
> > handle what would seem to be a
> >       very
> >                   similar scenario.Scenario
> > 1: If there are two occurrences
> >       of a
> >                   single portlet on a page,
> > then as you described it the
> >       portlet
> >                   is responsible for
> > segregating the occurrence-specific
> >                   information, using an
> > additional key provided by the
> >                   portal.Scenario 2: If
> > there are two occurrences of a pair
> >       of
> >                   portlets, then suddenly
> > the portal is responsible for
> >                   segregating the two pairs
> > by placing them in two separate
> >                   sessions.(All, of course,
> > assuming that the portlets use
> >                   sessions)The idea of the
> > Consumer creating and managing
> >       the
> >                   segregation keys has the
> > scalability advantage that you
> >                   mentioned.Can't we use it
> > to handle both
> >      
> > scenarios?Namely:In
> >                   scenario 1, where there's
> > portlets A1 and A2, then the
> >       portal
> >                   sends a key "1"
> > when displaying A1 and a key "2" when
> >                   displaying A2. In
> > scenario 2, when there's portlet pairs
> >       <A1,
> >                   B1> and <A2,
> > B2>, then the portal sends a key "1" when
> >                   displaying A1 and B1 and
> > the key "2" when displaying A2
> >       and
> >                   B2.This would allow the
> > Producer to create and manage the
> >                   session id (and maybe
> > even create them only when needed,
> >                   instead of explicitly
> > creating them up-front as the
> >       current
> >                   draft suggests). The
> > Consumer only has to take into
> >       account
> >                   that it may receive (and
> > needs to re-send) a separate
> >       session
> >                   id for each one of the
> > keys.Eilon

--