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


Help: OASIS Mailing Lists Help | MarkMail Help

wsia 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

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

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

  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
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
As written it implies a relationship with User transient information as
are claimed to be scoped to a user.  Whereas a session is scoped one-to-one
a user I don't believe persistent information is scoped one-to-one to a
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
differing concurrent user (sessions).  This seems to imply that the scope
"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
'activation' handle used in subsequent calls to identify the consumer.  How
we account for this with the createEntity (and other) APIs?  I 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.
so should we have a separate list parameter that allow the consumer to
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
the createEntity call to create/be tied to these subtypes -- hence need
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
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
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,

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
> suggest:
>       Session Information - This is carried opaquely in the interface as
>       "sessionID".
>       => goes away
>       Persistent Information - This is carried opaquely in the interface
>       a "handle".
> Rather than "Manifestation", I would propose using "Entity" to describe
> thing from which markup may be requested. I think it has the right level
> 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
> 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