Re: [wsrp-wsia] [wsia-wsrp] [wsrp-interfaces] The case forhierarchical entities

[Alejandro Abdelnur <alejandro.abdelnur@sun.com>]

Alan,

JSR168 does not define entity templates. It may mention them as an 
example, just that.

Regards.

Alejandro

Alan Kropp wrote:
 > There is a standing decision as of the F2F that entities will *not* be
 > hierarchical.  Entity creation is really "cloning", and there is no 
explicit
 > relationship between the cloned entity, and the new one.
 >
 > This is problematic because entity hierarchy is a pretty common 
requirement
 > among portals.
 >
 > For example, JSR 168 has the concept of portlet entity templates. 
JSR 168
 > leaves it up to the portal vendor to implement these or not, but a common
 > implementation will be to support hierarchical entities, such that
 > preference settings on the template can be "inherited" by dependent
 > entities.  For example, a portal admin might create an e-mail portlet
 > entity, configure it to point to a particular e-mail server, then 
provide it
 > as a template for users to create their own e-mail portlet entities. 
   When
 > the admin changes the e-mail server property, it needs to change for all
 > users.
 >
 > If WSRP entities are not hierarchical, it will be difficult for a 
portal to
 > implement for WSRP the same sort of templating that its regular portlets
 > have.  WSRP services could become second-class citizens, as they would be
 > inherently difficult to administer in the same way as local portlets.
 >
 > If the TC does not want to support entity relationships, there may be an
 > alternative.  The Consumer could manage the hierarchy it needs for its
 > portlet configurations.   In the e-mail example above, the Consumer would
 > remember which end user created entities were created from the "parent"
 > e-mail entity, and explicitly change the e-mail server property on all of
 > them.   For Consumers like this, that manage all of the entity state, I
 > don't believe it makes sense for them to create entities at all:  the
 > Consumer can use one entity for all its users, and provide the correct
 > configuration for each, perhaps at the beginning of the session 
(provided we
 > agree that explicit session creation is required, and I am arguing 
strongly
 > in favor of that as well).
 >
 > BTW, just to avoid any potential confusion, I'd like to note that support
 > for hierarchical *entities* does not imply the need for hierarchical
 > *properties*.  Properties can be a flat list of name-value pairs.
 >
 > Alan
 >
 > ----------------------------------------------------------------
 > To subscribe or unsubscribe from this elist use the subscription
 > manager: <http://lists.oasis-open.org/ob/adm.pl>