Hi Fred:
What I was pushing at was something
like this , if we do have this (which I am not very keen on) that has this
level of implementation variability, then there needs to be some sort of
policy assertion to clarify for the requestor what to expect before it
sends the PutRPDoc message.
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/>
++++++++
Fred Carter <>
01/07/2005 04:34 PM
Please respond to
fred.carter
To
"Sedukhin, Igor S"
<>
cc
Steve Graham/Raleigh/IBM@IBMUS,
Subject
Re: [wsrf] resolving issue
72: clarification of PutResourcePropertiesDocument operation semantics
In general, if this is all a big deal, why not deal with
it like pretty much all other computer instructions do: have an option.
In Windows/Macintosh/whatever, if I copy a folder/directory over top of
another, pop-op boxes may appear which say words to the effect "you've
already got a file named foo, do ya wanna stop, overwrite this one,
or overwrite them all." Or if there are files that are readonly,
not owned by me, munged beyond words, etc. Similarly, at CLI land,
if I remove things, I get "override permission XXX?" type questions
left & right.
Why not just offer an option of front? Default is to fault if somethings
are not writeable by the sender (or by anyone), but allow an option to
"silently ignore" such situations. changeWhatYouCan=true
or whatever. :-) It might return some status "some junk changed",
depending upon how silent one wished to be...
Suggestion offered. No strong opinion one way or the other. But
it seems like a reasonable compromise... Not without precedence in
system services, certainly not in UI's.
/fred
Thus quoth Sedukhin, Igor S (~ 1/7/2005 1:17 PM ~)...
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 .. ()
-- (631) 342-4325 .. 1 CA Plaza, Islandia, NY 11749
_____
From: Steve Graham [mailto:]
Sent: Friday, January 07, 2005 4:12 PM
To: Sedukhin, Igor S
Cc:
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" <>
01/07/2005 03:50 PM
To
Steve Graham/Raleigh/IBM@IBMUS
cc
<>
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 .. (
<mailto:>
)
-- (631) 342-4325 .. 1 CA Plaza, Islandia, NY 11749
_____
From: Steve Graham [mailto:]
Sent: Friday, January 07, 2005 3:39 PM
To: Sedukhin, Igor S
Cc:
Subject: RE: [wsrf] resolving issue 72: clarification of
PutResourcePropertiesDocument operation semantics
"Sedukhin, Igor S" <>
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 .. ()
-- (631) 342-4325 .. 1 CA Plaza, Islandia, NY 11749
From: Steve Graham [mailto:]
Sent: Friday, January 07, 2005 8:32 AM
To: Sedukhin, Igor S
Cc:
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" <>
01/06/2005 11:57 PM
To
<>
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 .. ()
-- (631) 342-4325 .. 1 CA Plaza, Islandia, NY 11749
--
Fred Carter / AmberPoint, Inc.
mailto:
tel:+1.510.433.6525 fax:+1.510.663.6301
