RE: [wsrp][wsia][wsrp-wsia joint interfaces][Draft Spec 0.43]createEntity/createTemplate/createPortlet

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