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
