RE: [wsrp] Issue #32: PROPOSED RESOLUTION

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

02/28/05 04:59 AM

To

Rich Thompson/Watson/IBM@IBMUS,
"WSRP" <>

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

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

12/22/04 10:15 AM

To

Rich Thompson/Watson/IBM@IBMUS,
WSRP <>

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

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

12/21/2004 12:55 PM

 

To

WSRP <>

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.