RE: [wsrp][wsia][wsrp-wsia joint interfaces][Draft Spec0.43]Terminology

Title: Message

Since the issue of a cross-portlet session seems to be useful, but we 
don't want to create our API around it, one thought is as 
follows:

- Define a pre-defined property that the portal can send to the portlet 
that uniquely identifies the <portal, user> or <portal, portal 
session> combination. 

- The portlet then can use this information to return the same session 
across multiple portlets if needed

- This would guarantee the same session-id from the portlet service 
perspective, but still be completely transparent the portal and to our 
API.

 

Eilon

  

  
-----Original Message-----
From: Carsten Leue 
  [mailto:] 
Sent: Friday, May 24, 2002 11:08 
  AM
To: Michael Freedman
Cc: Rich Thompson; 
  ; 
Subject: Re: 
  [wsrp][wsia][wsrp-wsia joint interfaces][Draft Spec 
  0.43]Terminology

  
Mike - my assumption when making the statement below was that 
  there was a 
N:1 mapping between portlet session and 
  remote instance that results from 
the following 
  scenario: there exists one user session between the client 
(browser) and the consuming portal. The portal creates subsessions for 
  each 
portlet within this user session make it possible 
  for the portlets to write 
something into this session 
  without having to worry about other portlets 
using the 
  same user session. This subsession is what I call a portlet 
session. This portlet session is then directly associated with the 
  portlet 
and therefore with the remote instance handle, 
  what makes up a N:1 
relationship between portlet 
  sessions and instance handles. To express this 
user 
  session to the remote service the consumer could call createSession or 
  
take an implicitely generated session handle. This handle 
  would them imply 
the instance handle and make an 
  explicit handle obsolete. 
From our latest discussions 
  I realize that this concept is maybe to 
restrictive as 
  it does not account for session sharing between portlets (of 
course the user session would be shared but the portlet only sees 
  its 
subsession). I am not sure if we really need such 
  a session sharing in the 
first WSRP draft as it 
  introduces potential synchronization problems, but 
we 
  may want to not forbid it by restricting the interfaces. 
So I withdraw my last comment that a session should imply the 
  instance. 

  
Best regards 
Carsten Leue 

  
------- 
Dr. Carsten Leue 
  
Dept.8288, IBM Laboratory B鐽lingen , Germany 
  
Tel.: +49-7031-16-4603, Fax: +49-7031-16-4401 
  

  
|---------+-----------------------------> 
|         
  |           Michael 
  Freedman  | 
|         
  |           
  <Michael.Freedman@| 
|         
  |           
  oracle.com>       | 
|         
  |                             
  | 
|         
  |           05/23/2002 
  11:19  | 
|         
  |           
  PM                
  | 
|         
  |           Please respond 
  to | 
|         
  |           Michael 
  Freedman  | 
|         
  |                             
  | 
|---------+-----------------------------> 
  
  
  >---------------------------------------------------------------------------------------------------------------------------------------------|

  
  
  |                                                                                                                                             
  |

  
  |       
  To:       Carsten 
  Leue/Germany/IBM@IBMDE                                                                                              
  |

  
  |       
  cc:       Rich Thompson/Watson/IBM@IBMUS, 
  , 
                                          
  |

  
  |       Subject:  
  Re: [wsrp][wsia][wsrp-wsia joint interfaces][Draft Spec 
  0.43]Terminology                                                    
  |

  
  
  |                                                                                                                                             
  |

  
  
  |                                                                                                                                             
  |

  
  
  >---------------------------------------------------------------------------------------------------------------------------------------------|

  
I have been and continue to be "confused" by this notion that 
  the session 
implies the instance.  I had a short 
  conversation with Rich after Tuesday 
call in which my 
  confusion became apparent -- however I have been unable to 
turn the corner. 

  
My point of view comes from the web model.  A session 
  scopes a user's 
transient information within a 
  server/application across all components of 
the 
  
server/application.  I.e. If a portal user has two 
  portlets from the same 
portlet service on a page they 
  run in the same session (note the scoping 
isn't 
  limited to the page -- rather its the client which is the portal). 
  
Therefore I expect sessions to be orthogonal to 
  instances.  In fact I 
expect (because consumers 
  may concurrently send multiple requests to 
multiple 
  instances within the same service) that consumers will need to 
  
explicitly request a session be created prior to doing any 
  instance 
operations. I.e. even the createEntity() call 
  needs to take a sessionId. 

  
Rich mentioned something about this still being modeled by the 
  session per 
instance case if the producer views 
  sessions in a tree.  Thus there may be 
one 
  internal session onto which these external sessions are mapped.  
  Though 
I imagine this could be done it seems to 
  complicate the service/portlet 
implementation 
  significantly -- I wouldn't want to write a portlet in such 
a world without someone building the basic container for me.  Nor 
  would I 
want to map it back to the web world (aka 
  servlets). 

  
Is my confusion stemming from having a web point of view vs. a 
  distributed 
object view?  Or is there confusion 
  because I view portlets/instances as 
entities 
  contained by the service vs. being a services themselves? 
     -Mike- 

  
Carsten Leue wrote: 

  
> Mike - I am concerned about your proposition to pass both 
  the session and 
> instance handle to markup and 
  action calls. Wouldn't the session imply 
the 
  
> instance? 
> 
> Best regards 
> Carsten Leue 
  
> 
> ------- 
> Dr. Carsten Leue 
> Dept.8288, IBM 
  Laboratory B鐽lingen , Germany 
> Tel.: 
  +49-7031-16-4603, Fax: +49-7031-16-4401 
> 
  
> |---------+-----------------------------> 
  
> |         
  |           Michael 
  Freedman  | 
> 
  |         
  |           
  <Michael.Freedman@| 
> 
  |         
  |           
  oracle.com>       | 
> |         
  |                             
  | 
> 
  |         
  |           05/23/2002 
  12:53  | 
> 
  |         
  |           
  AM                
  | 
> 
  |         
  |           Please respond 
  to | 
> 
  |         
  |           Michael 
  Freedman  | 
> 
  |         
  |                             
  | 
> 
  |---------+-----------------------------> 
>   > 
---------------------------------------------------------------------------------------------------------------------------------------------|

  
>   | 
| 
>   |       
  To:       Rich Thompson 
  <> 
| 
>   |       
  cc:       , 
   
| 
>   |       Subject:  
  Re: [wsrp][wsia][wsrp-wsia joint interfaces][Draft 
Spec 
  0.43]Terminology                                                    
  | 
>   | 
| 
  
>   | 
| 
>   > 
---------------------------------------------------------------------------------------------------------------------------------------------|

  
> 
> Rich, 
>   I like your terminology much better.  I have done 
  a quick review of 
Gil's 
> 
  updated document and here are a few initial comments: 
> 
> 1) I agree we should ignore the 
  shared transient information "type". 
> 2) I think 
  the specification should recognize the per consumer scope.  I 
  
> understand a producer will be able to manage this scope 
  transparently 
once 
> 
  we 
> add a registration handle but I don't think 
  that just because it can be 
> inferred from the 
  model we should ignore it (from the spec/description). 
> 3) The definition of the "persistent information" type needs to 
  be 
> tightened. 
> As 
  written it implies a relationship with User transient information as 
  
> both 
> are claimed to be 
  scoped to a user.  Whereas a session is scoped 
one-to-one 
> to 
> 
  a user I don't believe persistent information is scoped one-to-one to a 
  
> user. 
> Rather I believe we 
  have discussed situations where the mapping is 1 to 
N. 
> I.e. the producer may be asked to 
  operate on the sample persistent entity 
> 
  for 
> differing concurrent user (sessions).  
  This seems to imply that the scope 
> of 
  
> "persistent information" is whatever the consumer 
  chooses it to be. 
> 
> On 
  the operations themselves: 
> 1) createEntity (aka 
  createTemplate). In WSRP we have discussed requiring 
> consumers register with a producer to "activate" it.  
  Registration 
returns 
> 
  an 
> 'activation' handle used in subsequent calls 
  to identify the consumer. 
How 
> can 
> we account for this with the 
  createEntity (and other) APIs?  I really, 
> 
  really, 
> really, don't want this to be an property 
  value.  Also what is the actual 
> intent of 
  these property lists?  Gil implies they are persistence 
presets. 
> If 
> 
  so should we have a separate list parameter that allow the consumer to 
  
> further 
> qualify the Entity 
  being created?  I.e. in WSRP portlets aren't the 
direct 
> producer -- they are 
  managed/contained by the producer.  We will want to 
> use 
> the createEntity call to 
  create/be tied to these subtypes -- hence need 
> 
  someway 
> to qualify it in the call.  Finally, 
  are we assuming the service never 
> wants to 
  
> programmatically authorize this operation?  If not, 
  don't we need to pass 
> User 
> identity and roles as well? 
> 
  
> 2) destroyEntity (aka destroyTemplate).  Since we 
  seem to want to support 
> creating new entities 
  from existing one's do we want to support cascading 
> delete?  If not we likely should support bulk deletes. [Note: 
  should we 
> consider bulk create as well for 
  import/export/publish purposes?]  As 
with 
  
> create entity the consumer ID should be passed. 
  
> 
> 3) Gil's description 
  implies session must be created as these handles are 
> passed to subsequent calls.  Your usage is more 
  ambiguous.  Do we intend 
> that 
  
> Entity handle and session ID will be passed as separate 
  parameters to 
> subsequent calls?  I hope 
  so.  Also we may need to begin drilling into 
the 
> issues related  to 
  detecting/dealing with session timeout and 
reacquisition 
> sooner rather then 
  later. 
>    'nough for now, 
  
>        -Mike- 
  
> 
> Rich Thompson wrote: 
  
> 
> > Presuming the 2nd case 
  to get dropped relative to the previous set of 
> 
  > emails, I would propose this section call out how we will refer to 
  
these 
> > things throughout the 
  remainder of the document/API. In particular, I 
> 
  would 
> > suggest: 
> 
  >       Session Information - This is carried 
  opaquely in the interface 
as 
> a 
> 
  >       "sessionID". 
> >       => goes away 
  
> >       Persistent 
  Information - This is carried opaquely in the 
interface 
> as 
> 
  >       a "handle". 
> > 
> > Rather than 
  "Manifestation", I would propose using "Entity" to describe 
> the 
> > thing from which markup may 
  be requested. I think it has the right 
level 
  
> of 
> > opacity (Consumer 
  has no idea what kind of entity it is) while carrying 
> > appropriate semantics (a thing that may be interacted with). 
  Using 
these 
> > terms, 
  there was also an open question at the end of our last call 
> related 
> > to whether there were 
  both persistent and transient entities ... 
> 
  > 
> > If we are going to support explicit 
  lifecycle for both of these, I 
would 
> > propose: 
> >    
  handle   createEntity(handle, propertyValues) 
> >    sessionID   createSession(handle, 
  propertyValues) 
> > 
> 
  > ---------------------------------------------------------------- 
  
> > 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> 
  

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