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


Help: OASIS Mailing Lists Help | MarkMail Help

wsrp-interfaces message

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

Subject: RE: [wsrp-wsia] [wsrp-interfaces] The case for hierarchical entit ies

A somewhat related question is the one of the releaseHandles()
semantics of a producer being required to return more handles
in the reply than passed in by the request.
For example, releasing a consumerRegistration would delete all
entities created under that registration. If entities form
a hierarchy, should deleting a (non leaf) entity delete all
entities previously "cloned" form the deletee?

Also, having producers eagerly release dependent entities 
has performance and consistency implications in a 
distributed environment:

e.g. Consider, a request to create an entity in parallel 
under a registration with a parallel request to "release" 
the same registration. Should the create always fail? Or
could the new Entity be reported as "released" (and the 
create succeed?) ... We could serialize all creates and 
deletes in a central database, but allowing temporary 
"inconsistencies" could lead to more performant 

I believe Alan, below, is proposing that consumers take 
over more of the lifecycle management of entities. In this 
spirit, I would propose that release only schedules 
(unreachable) entities for deletion, so that a producer can 
lazily flush them from its persistent store and that consumers 
tell producers of all logically released entities. 
releaseHandles() would then be silent about its effects.

However, I think having consumers track hierarchical 
relationships between entities serious complicates the
model and would lead to unexpected behaviour (when a non
terminal entity is modified or deleted) and, as I think I
understood the intentions of other members of the 
JSR 168 expert group, JSR 168 implementations are more 
likely to take a "clone" approach than a live hierarchy.


PS. I the spirit of Mikes security comment for 
getDescription should releaseHandels also take a 
consumerContext arg? I had previously assumed that
all "handles" where unique unguessable identifiers
(consumerHandles must be but entity handles need 
not be).

-----Original Message-----
From: Alan Kropp [mailto:akropp@epicentric.com]
Sent: 13 August 2002 00:03
To: interfaces; wsrp-wsia
Subject: [wsrp-wsia] [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

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.


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