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

[Michael Freedman <Michael.Freedman@oracle.com>]

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>