[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsrf] ISSUE : setResourceProperties atomicity
We specifically rejected burning in policy like this to the WSRF
operations. At the time, we said that any such policy regarding atomicity,
observability of updates, concurrency, etc, would either be provided by, or
reconciled with the transaction specifications. In addition, if such policy
were to be defined, above and beyond what is defined in the WS-Transaction
specs, we said this would/could be generally applicable to any operation
and not exclusively relevent to set resource properties. Might want to go
back and read the state paper to get more insight on this.
Jeffrey Frey
IBM Distinguished Engineer
OnDemand System Architecture and Design
Phone: 845-435-3067 Tie: 8-295-3067 Cell: 914-456-6556
Notes: Jeffrey Frey/Poughkeepsie/IBM@IBMUS
Internet: jafrey@us.ibm.com
Steve
Graham/Raleigh/IB
M@IBMUS To
"Glen Daniels"
10/29/2004 09:16 <gdaniels@sonicsoftware.com>
AM cc
wsrf@lists.oasis-open.org
Subject
Re: [wsrf] ISSUE :
setResourceProperties atomicity
Are you suggesting 1) and 2) in your email are alternatives or
complementary?
I don't see the purpose of having an attribute on the operation. Maybe I
don't understand your suggestion. Would this be a decoration of the wsdl
operation? Why would the policy assertion of
<wsrf-rp-pol:SetResourcePropertiesAtomicity>true</wsrf-rp-pol:SetResourcePropertiesAtomicity>
alone be sufficient?
++++++++
Steve Graham
(919)254-0615 (T/L 444)
STSM, On Demand Architecture
Member, IBM Academy of Technology
<Soli Deo Gloria/>
++++++++
"Glen Daniels"
<gdaniels@sonicsoftware.com>
To
10/28/2004 08:23 PM <wsrf@lists.oasis-open.
org>
cc
Subject
[wsrf] ISSUE :
setResourceProperties
atomicity
I'm sitting here at the WS-Notification meeting, and the following topic
has just come up.
The atomicity of setResourceProperties() in WSRP is currently undefined
(I can't get to the current spec right now (no net) to point at a
particular section, sorry). An implementation is free to either do them
all at once, guaranteeing atomicity, or to do them one at a time, so
that some of them might have worked and others did not at the end of the
invocation. In other words, it's a QoS issue as to whether a given
implementation decides to do it one way or the other.
This seems like a fine thing, except that apparently there is not yet a
plan for either a) a metadata/policy assertion which indicates a given
resource will do setResourceProperties in an atomic (or not) way, or b)
a way to indicate in a given setResourceProperties() invocation that the
requester requires atomicity. I would like to raise an issue that both
of these things should be specified in WSRP.
In particular, I'm suggesting that the group:
1) Define a normative way to indicate in metadata that a resource will
do atomic setResourceProperties() invocations (this is basically a
boolean element with a well known QName)
2) Define a boolean "atomic" flag/attribue on the
setResourceProperties() operation, the semantics of which indicate that
a successful result means ALL sets were done, and a failed result means
NO sets were done.
IMHO, without this stuff, the usefulness of a single set operation for
multiple resource properties is severely restricted.
--Glen
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]