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

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

Steve,

 

[How does the requestor know, for any given message, what the result will be, before the message is sent? ]

 

Is there a general answer to your question?

 

I thought the example demonstrated that there could be side effects that can produce results in a fairly unexpected manner even in just one property update. Why does this make Put different? With Fred's suggestion, I think that would be the most we could do anyways. Can we just go with that?

 

I have more examples of things like "calculated property values" that affect SetRP and SetMultipleRP much the same way, which I can provide.

 

I just don't see what makes Put so different that we're discussing this.

-- 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 5:19 PM
To: Sedukhin, Igor S
Cc: wsrf@lists.oasis-open.org
Subject: RE: [wsrf] resolving issue 72: clarification of PutResourcePropertiesDocument operation semantics

I guess I am lost. 
 I don't see how an "interpretation" can not result in implementation 
specific results.  I understand that the results are deterministic, but the 
requestor cannot tell a priori what the results are to be for any given message 
to PutRPDoc.  Further, there is a good chance that different 
implementations of PutRPDoc by different vendors will do different 
interpretations of the document (resulting in different results).  How does 
the requestor know, for any given message, what the result will be, before the 
message is sent? 

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/07/2005 04:48 PM

To	Steve Graham/Raleigh/IBM@IBMUS
cc	<wsrf@lists.oasis-open.org>
Subject	RE: [wsrf] resolving issue 72: clarification of PutResourcePropertiesDocument operation semantics

Actually that rule says nothing about the results being 
implementation specific what it says is the *interpretation* is what needs to be 
done is implementation specific (which it is anyways) and the results are very 
much specified. There is no statement there which says that results are 
implementation specific. 
  
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.

-- 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 4:38 PM
To: Sedukhin, Igor 
S
Cc: wsrf@lists.oasis-open.org
Subject: RE: [wsrf] 
resolving issue 72: clarification of PutResourcePropertiesDocument operation 
semantics


not 
everything is implementation specific.  I agree some things are, but we 
should not "just accept" that certain results will be implementation specific. 
 Side effects we can never cope with, stating that the actual results of 
PutRP document are implementation specific is not acceptable. 

>I think we're 
fine. 
-1 

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/07/2005 04:17 PM

To	Steve Graham/Raleigh/IBM@IBMUS
cc	<wsrf@lists.oasis-open.org>
Subject	RE: [wsrf] resolving issue 72: clarification of PutResourcePropertiesDocument operation semantics

It is always 
implementation specific. The client needs to understand (or guess :) the 
semantics of the implementation anyways. There is no such absolute knownledge 
that a temperature property is not settable and has this or the other effect. It 
is always relative to the client's understanding of what the implementation will 
actually do. However, what we provide is a MEP which takes care of some of the 
basic aspects of this interation and makes that, at least, interoeprable. I 
think we're fine.

-- 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 4:12 PM
To: Sedukhin, Igor 
S
Cc: wsrf@lists.oasis-open.org
Subject: RE: [wsrf] 
resolving issue 72: clarification of PutResourcePropertiesDocument operation 
semantics


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