wsrf message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Re: [wsrf] RE: [wsn] Issue: TerminationTime property should allow Set/Update
- From: Rich Thompson <richt2@us.ibm.com>
- To: wsrf@lists.oasis-open.org
- Date: Tue, 30 Nov 2004 13:56:43 -0500
I have been recently trying to catch
up with all the threads/work happening with WSRF and had the following
statement stand out when reading the updated Resource Lifetime spec:
A WS-Resource MUST NOT allow the TerminationTime
resource property to be modified by a SetResourceProperties request message
as defined in [WS-ResourceProperties].
This raised the question I knew had
been discussed in a previous email thread (copied below), which I would
rephrase to "Why is this a resource property if the normal resource
property operations are disallowed in favor of a specialized operation?".
I think this question will be frequently raised by those who have not had
the benefit on participating in these discussions. I understand the issues
with a potentially chatty protocol if the semantics of SetTerminationTime
are followed using only the base resource property operations and the mismatch
between the semantics of SetTerminationTime and SetResourceProperties (i.e.
set to a value in the future relative to the supplied value vs. set to
the supplied value) and propose that a compromise is in order. I suggest
the above sentence be changed to:
A WS-Resource SHOULD NOT allow the TerminationTime
resource property to be modified by either a SetResourceProperties or UpdateResourceProperties
request message as defined in [WS-ResourceProperties]. If a WS-Resource
chooses to allow modification of
the TerminationTime resource property via the SetResourceProperties or
the UpdateResourceProperties request message, the WS-Resource MUST either
accept the TerminationTime value specified in the request or fault as normatively
described in [WS-ResourceProperties].
This allows the option of treating the
resource property in the standard way provided the WS-Resource is willing
to abide by the standard semantics with no impact on the semantics defined
by wsrf-rl.
Rich Thompson
OASIS WSRP TC Chair
P.S. In rereading this before hitting
send, I think I could be easily convinced to drop the first sentence as
it then just becomes a conformance requirement on those WS-Resources that
allow the TerminationTime property to be changed via a setResourceProperties
or UpdateResourceProperties request message. Do people think the spec should
be making a recommendation in this area or simply calling out the difference
in semantics and the resulting additional conformance issue involved when
the base property operations are supported?
Tom Maguire/Hawthorne/IBM@IBMUS
08/13/2004 04:28 PM
|
To
| "Murray, Bryan P."
<bryan.murray@hp.com>
|
cc
| wsrf@lists.oasis-open.org
|
Subject
| [wsrf] RE: [wsn] Issue: TerminationTime
property should allow Set/Update |
|
Ouch, the semantic of SetResourceProperties is to set the RP to the value
specified. Would you
say the behaviour was okay for non-monotonic changes or for other resource
properties? Can a
service just decide to put whatever value it feels like in an RP and return
a non-fault response?
Tom
"Murray, Bryan P." <bryan.murray@hp.com> wrote on 08/13/2004
01:41:25 PM:
> Why would you not allow setting the TerminationTime in the future
if you
> use Set/Update? It is entirely possible that the termination time
is
> modified from the value the client sent in the request, but so what?
If
> the client sets the time 1/2 hour in the future and sends this message
> every 15 minutes - what difference does it make if the client never
> knows that the service is changing this 1/2 hour to 20 minutes?
>
> Bryan
>
> -----Original Message-----
> From: Tom Maguire [mailto:tmaguire@us.ibm.com]
> Sent: Friday, August 13, 2004 8:59 AM
> To: Murray, Bryan P.
> Cc: wsn@lists.oasis-open.org
> Subject: Re: [wsn] Issue: TerminationTime property should allow
> Set/Update
>
>
>
>
>
> So I presume you told the developer that SetTerminationTime MAY set
the
> TerminationTime to a time in the future and that then requires the
> return of the new TerminationTime. This is different behavior
from the
> SetResourceProperties operation. I am intrigued though by the
notion of
> allowing SetResourceProperties on TerminationTime. I guess in
this case
> that the WS-Resource would be prohibited from setting the
> TerminationTime to a time in the future or if it wanted to do so it
> would be required to fault.
>
> Tom
>
>
> "Murray, Bryan P." <bryan.murray@hp.com> wrote on
08/13/2004 11:18:39
> AM:
>
> > I was approached by one of our developers regarding the
> > TerminationTime resource property in WS-ResourceLifetime. His
comments
> are as follows:
> >
> >
> > There is a "TerminationTime" resource property, in
addition to an
> > operation called "SetTerminationTime".
> >
> > To retrieve the value of the current termination time, you can
make a
> > "normal" WSRF-RP GetResourceProperty call and ask for
the
> > TerminationTime property - as dictated by the WS-RP spec.
> >
> > However, to set a new value, you MUST call the special
> > SetTerminationTime operation - the spec explicitly states, "A
> > WS-Resource MUST NOT allow the TerminationTime resource property
to be
>
> > modified by a SetResourceProperties request message as defined
by
> > WS-RP".
> >
> > I don't see why the need for this distinction?? It makes
implementors
>
> > have to deal with this special case with no apparent need for
it.
> >
> > Why can't the WSRF-RL spec rely on the setting capabilities of
WSRF-RP
>
> > just as it relies on the getting capabilities of WSRF-RP? Why
does it
>
> > use GetResourceProperty but not SetResourceProperties and instead
> > define its own special operation for setting the property? Seems
like
>
> > there is no real need for this special case - but yet it causes
> > implementors to have to write code for this "one-off"
- we have here a
>
> > required Resource Property that we must implement, but yet we
must
> > "disable" some of the generic WS-RP functionality for
this one
> resource property.
> >
> >
> > Bryan
> >
> > P.S. After I explained the reason for having the SetTerminationTime
> > operation, the developer agreed there was valid reason to have
the
> > operation, but still felt there was no reason to have to write
special
>
> > code to disable the ability to use Set to modify the property.
There
> > will be many clients that do not need to know exacly when the
> > termination time really is and will just periodically renew the
> > subscription until it is no longer needed.
>
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]