RE: [wsrf] resolving issue 72: clarification of PutResourcePropertiesDocument operation semantics

["Sedukhin, Igor S" <Igor.Sedukhin@ca.com>]

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