Title: Message
Rich,
How about leaving "support" for the persistent thingy in the joint
subcommittee, i.e.:
handle = createTransientThingy(persistentThingy,
propertyValues);
but deferring the discussion on how the persistentThingy is
created and managed to the larger WSRP committee, i.e.,
drop
handle = createPersistentThingy(...); (=Entity/Template/WSRP
instance)
It seems to me that:
1. Those calls may be more complex (i.e., Mike's suggestions for
inheritance, etc.).
2. Those calls may need to be mapped to a different service (WSDL-wise),
since they deal with a design/development environment.
Eilon
-----Original Message-----
From: Rich Thompson
[mailto:]
Sent: Thursday, May 23, 2002 7:59
AM
To: ;
Subject: RE: [wsrp][wsia][wsrp-wsia joint
interfaces][Draft Spec 0.43]crea
teEntity/createTemplate/createPortlet
The problem with dropping this from the joint interface is
that it ignores
R702 & E904 from the WSIA
requirements document. These arose out of the use
cases finding the persisting & reuse of information to be quite
valuable.
Gil
Tayar
<Gil.Tayar@webcol
To: ,
lage.com>
cc:
Subject: RE: [wsrp][wsia][wsrp-wsia joint interfaces][Draft
Spec
05/23/2002 04:16
0.43]crea
teEntity/createTemplate/createPortlet
AM
In the interest of sanity and progress, I have broken up
Rich's, Michael's,
Monica's and Eilon's emails into
four subjects - "Shared Transient
Information",
"Persistent Information Scope",
"createEntity/createTemplate/createPortlet", "session and entity
handles",
and "Property lists".
This email will deal with
createEntity/createTemplate/createPortlet, and
the
relevant quotes from the emails and my reply to them:
Rich 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)
Michael wrote:
> 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.
Eilon wrote (and I condense...):
[...]
> Would you find the following,
radically simplified, suggestion for an
operation
> name intrusive:
> createPortlet
> Along those lines, a
portal would call the operation createPortlet, would
get back a
> (persistent) portletID and then
(optionally) call createSession with the
portletID.
[...]
>
2. The ability to create a persistent key seems to be only under the
scope of
> WSRP and not under
WSIA. WSIA supports a persistent key to create
sessions and
> to subsequent operations, but
wouldn't probably deal with how they are
created
> and management (with all the
associated issues that are well described
in
Mike's
> latest summary). Hence, the motivation to
use a portal-specific name.
So now Gil writes:
It seems that
Michael, Eilon, and myself believe that the
createEntity/Template/Portlet operation is particular to WSRP (Rich, I
even
remember adding the "templateKey" thingie as a
shot in the dark to where
WSRP is going - it seems the
shot missed!).
I suggest then, dropping this from the
joint interface subcommitee, and
leaving it in the
hands of the WSRP. Having said that, we must be able to
support some type of connection between the template/entity/portlet and
the
"session handle", so what I propose is that the
createSession/Instance
operation (outlined above) will
accept an unspecified "bindingKey", i.e.:
sessionHandle/ID = createSession/Instance(bindingKey).
The "bindingKey" will be an opaque string to be defined either by the
WSIA
service, or defined by specs above WSIA (i.e.
WSRP). One can argue that
this is similar to JDBC's
"connection URL" (in getConnection) which is an
opaque
string specified when "connecting". WSRP could also use it to
specify the "sub-service/portlet" of the container, if WSRP decides to
go
the heterogenous.
My suggestion is to drop the createEntity/Template/Portlet,
and leave:
sessionHandle = createSession(bindingKey) [bindingKey is an
opaqueString,
which will be used in the future by WSRP
binding specifications]
getMarkup/performAction....(sessionHandle, ...) [i.e. all operations
within
the session will receive the
sessionHandle]
destroySession(sessionHandle)
And, as Michael suggested, resolve timeout and implict session
creation and
deletion issues ASAP.
(I specifically dropped the "propertyList" arguments as they
are not the
issue here, but that doesn't mean that I
don't support them).
Gil Tayar
WebCollage
----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the
subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>
