OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

wsia message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

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

Title: Message
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.
-----Original Message-----
From: Rich Thompson [mailto:richt2@us.ibm.com]
Sent: Thursday, May 23, 2002 7:59 AM
To: wsia@lists.oasis-open.org; wsrp@lists.oasis-open.org
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:       wsia@lists.oasis-open.org, wsrp@lists.oasis-open.org      
                      lage.com>                cc:                                                                 
                                               Subject:  RE: [wsrp][wsia][wsrp-wsia joint interfaces][Draft Spec   
                      05/23/2002 04:16          0.43]crea      teEntity/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
> suggest:
>       Session Information - This is carried opaquely in the interface as
>       "sessionID".
>       => goes away
>       Persistent Information - This is carried opaquely in the interface
>       a "handle".
> Rather than "Manifestation", I would propose using "Entity" to describe
> thing from which markup may be requested. I think it has the right level
> 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
> 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, 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
> qualify the Entity being created?  I.e. in WSRP portlets aren't the
> producer -- they are managed/contained by the producer.  We will want to
> the createEntity call to create/be tied to these subtypes -- hence need
> 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
> 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
> create entity the consumer ID should be passed.
Eilon wrote (and I condense...):
> Would you find the following, radically simplified, suggestion for an
> 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
> 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
> 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]

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

To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Powered by eList eXpress LLC