[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: [wsia-wsrp] [wsrp-interfaces] The case for hierarchical entities
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC