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.