[wsrp-wsia] [wsia-wsrp] [wsrp-interfaces] The case for hierarchicalentities

[Alan Kropp <akropp@epicentric.com>]

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