RE: [wsrp] Issue #32: PROPOSED RESOLUTION

[Rich Thompson <richt2@us.ibm.com>]

1. Add a Lifetime parameter to register,
modifyRegistration, clonePortlet, copyPortlets and exportPortlets operations.
2. Define semantics that the presence
of a Lifetime parameter on these requests indicates:
     a. The Consumer
prefers the returned resource be leased
     b. The supplied
Lifetime value indicate what the Consumer would otherwise supply in a subsequent
setxxxLifetime invocation
3. Define semantics that the absence
of a Lifetime parameter on these requests (other than modifyRegistration)
indicates the Consumer prefer the resource not be leased. For modifyRegistration,
the absence of a Lifetime parameter indicates the Consumer is not requesting
a change to the lease expiry on the registration resource.

Rich

"Andre Kramer" <andre.kramer@eu.citrix.com>

02/28/05 04:59 AM

To	Rich Thompson/Watson/IBM@IBMUS, "WSRP" <wsrp@lists.oasis-open.org>
cc
Subject	RE: [wsrp] Issue #32: Pass requestedLifetime to relevant operations

If we do add this optimization,
then we should document that the consumer supplying such an (optional)
lifetime value to a factory operation may cause the producer to initiate
leasing in a manner that assumes active consumer involvement in lifetime
management (rather than rely on consumer explicit destroys). I still think
the actual policy will be largely driven by the producer side (and typically
the registration the consumer has with the producer) so that supplying
a lifetime value to the factory has low value (i.e. likely to be overruled
by the producer policy) but could usefully guide the producer in deciding
whether or not the consumer will be active in managing the lifecycle.
 
Regards,
Andre

---

From: Rich Thompson [mailto:richt2@us.ibm.com]
Sent: 25 February 2005 20:43
To: WSRP
Subject: RE: [wsrp] Issue #32: Pass requestedLifetime to relevant operations
 

I had agreed to look through the wsrf/wsn repositories to locate their
current draft spec versions related to lifetime issues. 

Basically, wsrf (Web ServicesResource Framework) stays away from questions
regarding factories that might produce resource though wsrf-rl does deal
with the lifetime characteristics of resources. There are a few other standards
that are seeking to leverage wsrf, one of which is wsn (Web Services Notification).
The subscribe factory from wsn does take an InitialTerminationTime as an
input parameter. This was the resolved factory issue I recalled which has
semantics equivalent to our issue #32.

The basic discussion thread leading up to the wsn resolution to include
this parameter was: 
 1. It optimizes the common situation when a resource is created of a Consumer
wanting a different lifetime than the Producer is willing to give.
 2. The Producer is free to not honor the request much as it can on requests
sent to setLifetime. 

To these I think we could add the presence of such a parameter carrying
the semantics of the Consumer preferring the new portlet to be managed
on a lease basis. 

The most recent specs I refer to are located at:
  http://docs.oasis-open.org/wsrf/2004/11/wsrf-WS-ResourceLifetime-1.2-draft-04.pdf
  http://docs.oasis-open.org/wsn/2004/06/wsn-WS-BaseNotification-1.2-draft-03.pdf

Rich

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

12/22/04 10:15 AM

To	Rich Thompson/Watson/IBM@IBMUS, WSRP <wsrp@lists.oasis-open.org>
cc
Subject	RE: [wsrp] Issue #32: Pass requestedLifetime to relevant opreatio        ns

 

One thing to keep in mind is that producers may not particularly respect consumer requests and consumers adjusting is more likely when the termination time nears (so as to be favorably viewed by the resource maintainer). Therefore, I did not include a requestedLifetime in all operations.
 
Regards,
Andre
 

 

---

From: Rich Thompson [mailto:richt2@us.ibm.com] 
Sent: 22 December 2004 03:09
To: WSRP
Subject: Re: [wsrp] Issue #32: Pass requestedLifetime to relevant opreations
  

I believe this was one where you were the source :}

The reasoning is that if the Consumer doesn't have a chance to request
a particular lifetime, there will be an additional network round trip just
to do an initial setup. 

This is one where I could easily be convinced either way. Draft 04 has
it that the Consumer discovers that the Producer is using scheduled destruction
by the appearance of a lifetime in the reply. I suspect Consumers would
then add this as a resource to manage relative to the renewal of the lease
and therefore not incur an additional roundtrip. The flip side is that
if the Producer is using leased resources (Consumer should be able to tell
by support for the respective portTypes), why shouldn't the Consumer get
a chance to indicate its preference for the initial timeout?


Rich

Michael Freedman <Michael.Freedman@oracle.com>

12/21/2004 12:55 PM

 

To	WSRP <wsrp@lists.oasis-open.org>
cc
Subject	Re: [wsrp] Issue #32: Pass requestedLifetime to relevant opreations

 

 

Why?

Rich Thompson wrote:

Issue # 32
Spec section:
SubCommittee: Interfaces
Owner: Andre
Description: Operations expected to return a Lifetime should also take one as input. This would affect register, modifyRegistration, clonePortlet, exportPortlets, copyPortlets.