[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
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:richard.jacob@de.ibm.com
Rich Thompson
<richt2@us.ibm.co
m> To
"WSRP" <wsrp@lists.oasis-open.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"
<andre.kramer@eu.citrix.com>
To
02/28/05 04:59 AM 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
>
To
Rich Thompson/Watson/IBM@IBMUS,
12/22/04 10:15 AM 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.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]