[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
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, [email protected] |
> | 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>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC