Subject: RE: [wsrp] Issue #32: PROPOSED RESOLUTION
sound reasonable. Again the question here: do we need metadata about the Producer lifetime management requirements? Mit freundlichen Gruessen / best regards, Richard Jacob ______________________________________________________ IBM Lab Boeblingen, Germany Dept.8288, WebSphere Portal Server Development WSRP Standardization Technical Lead Phone: ++49 7031 16-3469 - Fax: ++49 7031 16-4888 Email: mailto:firstname.lastname@example.org Rich Thompson <email@example.com m> To "WSRP" <firstname.lastname@example.org> 03/04/2005 08:16 cc PM Subject 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" <email@example.com> To 02/28/05 04:59 AM Rich Thompson/Watson/IBM@IBMUS, "WSRP" <firstname.lastname@example.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:email@example.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 <firstname.lastname@example.org > To Rich Thompson/Watson/IBM@IBMUS, 12/22/04 10:15 AM WSRP <email@example.com> 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:firstname.lastname@example.org] 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 <email@example.com> 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.