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

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsrp message

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


Subject: 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:cleue@de.ibm.com]
Sent: Friday, May 24, 2002 11:08 AM
To: Michael Freedman
Cc: Rich Thompson; wsia@lists.oasis-open.org; wsrp@lists.oasis-open.org
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÷blingen , 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, wsia@lists.oasis-open.org, wsrp@lists.oasis-open.org                                        |

  |       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÷blingen , 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 <richt2@us.ibm.com>
|
>   |       cc:       wsia@lists.oasis-open.org, wsrp@lists.oasis-open.org
|
>   |       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>



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


Powered by eList eXpress LLC