Title: Message
Mike,
Per the tension you mentioned, and your previous e-mail with the
"Container" interfaces (C1-C4).
This is a question that Rich referred to as "Heterogeneous versus
Homogeneous" services. The question is whether the "container" behavior should
be an explicit part of the interface (as you suggested in C1-C4 =
"heterogeneous") or can be implicit in the interface by providing different
"services" (in the WSDL sense), each representing a separate portlet type (=
"homogeneous").
Why do you feel that WSRP needs the heterogeneous service? Couldn't a
single container/server provide different services for different portlet types,
and use WSDL techniques (mainly, URL paths) to differentiate between the
different portlets?
Eilon
-----Original Message-----
From: Michael Freedman
[mailto:]
Sent: Thursday, May 23, 2002
5:51 PM
To: Gil Tayar
Cc: ;
Subject: Re: [wsrp][wsia][wsrp-wsia joint
interfaces][Draft Spec
0.43]createEntity/createTemplate/createPortlet
I don't
think we want to give up so quickly on this. As I think all calls (after
createEntity) need to be passed the entity handle -- and would find each to be
unnatural if we defined they took an optional "bind" key. Also, I don't
think entities are WSRP exclusive things. Rather I think the tension is
WSRP needs (generic) container model while many components will be happy
running as standalone services. Personally, I wonder if we will end up
with two APIs -- one for service simple and one for service container -- much
like I depict in the e-mail sent earlier describing different component types
needing to be modeled. Though containing by and large the same API the
difference is the need for createEntity and passing the return handle in all
subsequent operations -- i.e. getFragment, etc.
-Mike-
Gil Tayar wrote:
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
TayarWebCollage
