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

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

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

What is common to these threads (leasing, event completion/failure notification) is that they allow failure to be addressed and I think we could use some of these idea in wsrp 2.0.

 

regards,

Andre

-----Original Message-----
From: Rex Brooks [mailto:rexb@starbourne.com]
Sent: 16 January 2004 14:57
To: Andre Kramer; wsrp-interfaces@lists.oasis-open.org
Subject: Re: [wsrp-interfaces] Leasing use cases and proposal for 2.0

Oh Grump!

You went and made me think! That's actually a compliment, sort of. I didn't actually need more reading material for this weekend, since I'm slogging my way through OWL and the new RDF specs. However, as with the eventing thing from MS, I have a nagging suspicion I can't actually get away with ignoring this, since "state" implies "eventing" and from a quick glance, I prefer "leasing" to "subscription."  We (web services in general and WSRP in particular) need a set of eyes and ears in the W3C XMLP WG, because "eventing" is part of their requirements, so we can either drive or not be run over by whatever gets done about asynchronous messaging in terms of practicality. Note: Event Source/Event Sink from the MS proposal is very likely to be left by the wayside in favor the XMLP concepts of "Sender"/"Receiver" including very WSRP-like concepts of "intermediaries" with "Initial Sender" and "Ultimate Receiver."

I didn't comment on the MS eventing proposal, but it was almost entirely couched in terms of dealing with faults, and little to no attention to any kind of consequential triggering or propagation of event notification messages, which as a set of absorbable features into whatever we adopt, is not necessarily as bad as I originally thought. I haven't looked at the ebXML mechanisms yet, and eventually will unless I can persuade someone else to do that. I just noted that it's there for now.

The OGSA paper is on my list for the weekend now. Page 23 in particular. Thanks a lot.

Ciao,

Rex

At 11:11 AM +0000 1/16/04, Andre Kramer wrote:

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.

-- 

Rex Brooks
GeoAddress: 1361-A Addison, Berkeley, CA, 94702 USA, Earth
W3Address: http://www.starbourne.com
Email: rexb@starbourne.com

Tel: 510-849-2309

Fax: By Request