[wsrp-interfaces] Leasing use cases and proposal for 2.0

[Andre Kramer <andre.kramer@eu.citrix.com>]

Title: [wsrp-interfaces] Leasing use cases and proposal for 2.0

State maintenance using a "leasing" concept:
[10] Cary G. Gray and David R. Cheriton. Leases: An Efficient Fault-Tolerant Mechanism for Distributed File Cache Consistency. In Proceedings of the 12th ACM Symposium on Operating Systems Principles, December 3-6, 1989, pages 202-210.

or lifetime management through timeout based renewal mechanisms (explicit operations or implicit through use) is a very common way to manage state in the presence of failures in distributed systems (Java's Jini, Microsoft's .NET Remoting). In fact, we already use implicit leases and "soft state" via WSRP 1.0 Session Handles and possibly (at the implementation level) cookie-based Application Server http Sessions.

However, consumer registrations and portlets lifetimes are currently only scoped by explicit deletion (deregister and destroyPortlets operations). This leads to resource reclamation problems in several scenarios:

If a consumer goes down and never recovers, a producer may be unable to reclaim registrations and portlet handles and associated resources. And doing so would probably require administrator intervention: consumer admin to report or confirm failure and producer admin to manually delete all registrations held by a consumer (portlets may then be garbage collected simply).

If a consumer represents a "virtual organization" then WSRP handles may be forwarded to fairly autonomous consumer entities but created centrally in the organizational domain (delegated administration) and they may even be shared between several semi-independent entities at any one time. Handle destruction then becomes a fairly difficult distributed garbage collection problem.

Our clone on write mechanism could also easily lead to handle leakage bugs or errors (say if a consumer crashes or does not get a performBlockingInteraction response  due to network failure). How does a producer know that the consumer has received the reply from a "clonePortlet" operation? Should it drop the handle if no getMarkup on the new handle after some time? What if the consumer is staching away handles for later future use?

Furthermore, significant confusion exists over the requirements on what to do when a deregister() or destroyPortlets() operations fails at the network level, even in WSRP 1.0. The consumer should re-try at a later time but for how long? What if the producer is down for some length of time and the consumer gives up before the producer comes back?

Producers could just unilaterally destroy handles when not used for some extended period of time (and I suspect some 1.0 systems will want to do this) but we have no standard way to advertise this fact, or the nominal expiry period, through producer meta-data. That would be the minimum useful addition we could make to address the above scenarios. A consumer must then periodically make use of some operations to keep alive handles.

However, rather than invent our own leasing concept, an alternative approach would be to view WSRP registration and portlet handles as OGSA (www.ggf.org) Grid Service handles (resolvable to grid service instance references through which a standard (OGSI) "Grid Service Interface" (SOAP/WSDL based) can be invoked). This interface features the following operations:

requestTerminationAfter() - i.e. not before some (possibly infinite) time period
requestTerminationBefore() - i.e. not after some (possibly infinite) time period

The currently set terminationTime is available as grid service data (similar to our WSRP properties).

see: http://www.ggf.org/ogsi-wg
https://forge.gridforum.org/projects/ogsi-wg/document/Final_OGSI_Specification_V1.0/en/1

A consumer and producer would have to agree that our handles represent Grid Service Handles (GSHs) and handle values (the strings) must be resolvable to Grid service references (a WSDL doc typically) by some agreed mechanism (using a Grid "HandleResolver" which seems to be an underspecified area of the current Grid specifications :-(.

A consumer can then resolve a WSRP handle (think of this as casting the handle to a wsdl stub / proxy for a GridService portType) and negotiate a leasing contract with a producer. Note that, handles need not be backed by full grid service "objects" but can be emulated by a container, so we add little cost and that the Grid specs allow the lifetime of one handle to scope another (as would be the case for our portlet handle scoped by a registration). We could make a portlet grid service reference its "parent" producer grid service to ease discovery etc.

For further motivation (of lease based lifetime management) from the Grid see: http://www.globus.org/research/papers/ogsa.pdf section 6.3.

regards,
Andre

PS OGSI could also be used for portlet properties / metadata and (asynchronous) notifications.