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

[Alan Kropp <akropp@epicentric.com>]

I'll second Andre's misgivings about releaseHandles().  Here's my spin on
it...

In the present interface for releaseHandles, what is the rationale behind
returning successfully released handles?   I believe the thinking is that
the producer can tell the consumer of any dependent entities that have been
released.  But are there actually any cases where the consumer doesn't know
what the dependent entities are?  If not, it seems like the method should
instead throw an exception containing handles that have _failed_ to be
released.   This seems like a more straightforward way of letting the
Consumer handle errors.
 
If for some reason we _do_ need to return successfully released handles, the
Consumer should release its own consumer context in a method distinct from
the releaseHandles that it uses to release entities.  Reasons:
1  The Consumer, over time, may have created millions of entities on that
Producer.  That's too much data to return in the array of released
sub-handles that releaseHandles returns.
2  The Consumer is terminating its relationship with the Producer and
doesn't care what sub-handles are released or not.

Alan


-----Original Message-----
From: Andre Kramer [mailto:andre.kramer@eu.citrix.com]
Sent: Tuesday, August 13, 2002 7:25 AM
To: 'Alan Kropp'; interfaces; wsrp-wsia
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 
implementations.

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.

Regards,
Andre

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
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>