wsrf message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: RE: [wsrf] resolving issue 72: clarification ofPutResourcePropertiesDocument operation semantics
- From: Steve Graham <sggraham@us.ibm.com>
- To: "Sedukhin, Igor S" <Igor.Sedukhin@ca.com>
- Date: Fri, 7 Jan 2005 16:11:41 -0500
yes, good example.
However, the semantics of SetRP on temperature
are clear, client expects the fault. From what I understood of your
proposal, it is implemntation specific what exactly happens to the temperature.
++++++++
Steve Graham
(919)254-0615 (T/L 444)
STSM, IBM Software Group, Web services and SOA
Member, IBM Academy of Technology
<Soli Deo Gloria/>
++++++++
"Sedukhin, Igor S"
<Igor.Sedukhin@ca.com>
01/07/2005 03:50 PM
|
To
| Steve Graham/Raleigh/IBM@IBMUS
|
cc
| <wsrf@lists.oasis-open.org>
|
Subject
| RE: [wsrf] resolving issue
72: clarification of PutResourcePropertiesDocument operation semantics |
|
Steve, like I said, the same concern
is true of any property update.
Say I have
<myCrazyThermometer>
<temperature>...</temperature>
<message>...</messaage>
*
</myCrazyThermometer>
The client does SetRP(<temperature>X</temperature>).
My impl sends a fault, but also records a message that someone tried to
update the temperature. So that is the side effect.
Now I got the RP doc which may
be very surpising to the client. The client may not have intended this
effect of the SetRP operation, but will have to live with it anyways.
<myCrazyThermometer>
<temperature>Y</temperature>
</message>Client A tried
to update! Bad client! Kill him!</message>
</myCrazyTehrmometer>
-- Igor
Sedukhin ..
(igor.sedukhin@ca.com)
-- (631)
342-4325 ..
1 CA Plaza, Islandia, NY
11749
From: Steve Graham [mailto:sggraham@us.ibm.com]
Sent: Friday, January 07, 2005 3:39 PM
To: Sedukhin, Igor S
Cc: wsrf@lists.oasis-open.org
Subject: RE: [wsrf] resolving issue 72: clarification of PutResourcePropertiesDocument
operation semantics
"Sedukhin, Igor S" <Igor.Sedukhin@ca.com> wrote on 01/07/2005
03:27:38 PM:
> Steve,
>
> I don't think it is as scary as you describe. First of all any MEP
that changes
> values may result in unitended behaviour in that when the fault occurs
e.g. an
> exception in the implementation code, there is no "undo"
and the state of the
> resource properties document MAY be undetermined.
True, but at least the behavior of the web service, independent of implementation
issues is known a priori. If I try to do a SetResourceProperties
MEP on an RP that
is read only, I know it will fault, this is part of the definition. However,
from
what I read, if I do a PutRPDoc including some Read-only properties, the
provider may
make certain changes but not all, it may update everything, including read-only
properties
(as a surprise to all concerned) or it may update some properties, not
others, etc. etc.
My point is that with a MEP that does change state like this, we cannot
be so flexible
with the semantics.
> That aside, I believe that
> particular rule of this MEP is interoperable:
> A. it says that Put MUST contain an XML Schema valid
RP doc, so the client
> knows what to do
> B. unless a fault was returned, the client unambiguously
knows what happened at
> the WS-Resource end: the new document is either exactly the same as
the one
> submitted or different in which case the new one is returned.
But the client may still be surprised that certain values did change when
the client
expected them to stay the same.
>
> I guess you refer to the case when a client intends to update something,
but it
> does not get updated or something else that was not intended is updated
(side
> effects). However, that is true of any form of update.
>
> -- Igor Sedukhin .. (igor.sedukhin@ca.com)
> -- (631) 342-4325 .. 1 CA Plaza, Islandia, NY 11749
>
>
> From: Steve Graham [mailto:sggraham@us.ibm.com]
> Sent: Friday, January 07, 2005 8:32 AM
> To: Sedukhin, Igor S
> Cc: wsrf@lists.oasis-open.org
> Subject: Re: [wsrf] resolving issue 72: clarification of
> PutResourcePropertiesDocument operation semantics
>
> Hi Igor:
> Thanks for clarifying your position on PutRP doc.
> My concerns remain about the vagueness of the semantics of this, and
hence my
> continued concern about adding this MEP. In particular,
> >rule 1.B: the WS-Resource implementation is free to interpret
the resource
> properties document contained in the Put request in any way it deems
necessary for
> >the update to occur.
>
> The freedom for an implementation to interpret the request in which
ever way it
> seems best strikes me as a HUGE interoperability threat. How
is a requestor to
> figure out what the actual interpretation might be? Further,
given this is a MEP
> that potentially changes values in the WS-Resource, we must treat
this MEP
> carefully, it might be difficult or impossible for the requestor to
"undo" the
> results, if it later deems that the implementation interpreted the
request in a
> "surprising" way.
>
> sgg
> ++++++++
> Steve Graham
> (919)254-0615 (T/L 444)
> STSM, IBM Software Group, Web services and SOA
> Member, IBM Academy of Technology
> <Soli Deo Gloria/>
> ++++++++
>
>
>
> "Sedukhin, Igor S" <Igor.Sedukhin@ca.com>
> 01/06/2005 11:57 PM
>
> To
>
> <wsrf@lists.oasis-open.org>
>
> cc
>
> Subject
>
> [wsrf] resolving issue 72: clarification of PutResourcePropertiesDocument
operationsemantics
>
>
>
>
> Responding to my AI [(Igor) Put forward a proposal to resolve issue
72 - how this
> would be done with respect to the semantics issues etc.]
>
> I suggest to define the following semantics for the PutResourcePropertiesDocument
> operation. The words are precise, so may not be easy to read. Let
me know if this
> needs further clarifications or not.
> rule 1: a resource properties document SHOULD be contained in the
Put request, in
> which case the WS-Resource implementation MUST interpret the request
as an update
> of the resource properties document.
> rule 1.A: the resource properties document contained in the Put request
MUST be XML
> Schema valid.
> rule 1.B: the WS-Resource implementation is free to interpret the
resource
> properties document contained in the Put request in any way it deems
necessary for
> the update to occur.
> rule 1.B.I: if the resource properties document maintaned by the WS-Resource
after
> update is XML Infoset identical to the resource properties document
contained in
> the Put request, then response MUST contain nothing.
> rule 1.B.II: if the resource properties document maintaned by the
WS-Resource after
> update is not XML Infoset identical to the resource properties document
contained
> in the Put request, then response MUST contain the updated resource
properties document.
> rule 3: in principle any document MAY be contained in the Put request,
in which
> case the WS-Resource implementation MAY find sufficient information
in the request
> to interpret it as an update of the resource properties document.
The response then
> MUST contain the updated resource properties document. This behaviour
is
> implementation specific.
> Note that rule 3 is covering the case where the resource properties
document
> submitted in Put request in not XML Schema valid (e.g. a partial document
with some
> required properties omitted). The rule 1.B.I is covering the case
where the
> document is valid, but may fill the values that are assigned by the
WS-Resource
> implementation e.g. IDs, static values, default values, calculated
values,
> transient values, etc. Either way it is up to the implementation to
interpret Put,
> however, I believe, it is sufficiently interoperable if the client
can count on
> these rules to be in effect.
> -- Igor Sedukhin .. (igor.sedukhin@ca.com)
> -- (631) 342-4325 .. 1 CA Plaza, Islandia, NY 11749
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]