Title: Message
Mike,
Along
the lines of Eilon's question, I'd like to have a better understanding as to
what the WSRP Producer Container is for. I confess to not
being well-informed on the motivation for introducing this concept in the
early interfaces/protocols discussions. My hope has been that it is
entirely a WSRP-specific construct, and therefore not something that needs to be
accounted for in the joint interface. But I'm not convinced one way or the
other, yet.
In the
interests of furthering this discussion, if you could run down the main points
behind the container, for both groups, I think it would be
beneficial.
I
think Mike's outline of the lifecycle interfaces from a "pure" WSRP perspective,
in relation to Gil's and Rich's latest rev of the joint interface specification,
represents the clearest illustration yet of the "gap" we need to close.
This is good progress.
Alan
-----Original Message-----
From: Eilon Reshef
[mailto:]
Sent: Thursday, May 23, 2002
3:36 PM
To: 'Michael Freedman'; 'Gil Tayar'
Cc:
;
Subject: RE:
[wsrp][wsia][wsrp-wsia joint interfaces][Draft Spec
0.43]createEntity/createTemplate/createPortlet
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
