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

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

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>