OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsrf message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [wsrf] WSRF25 Proposed solution






Steve,
The resolution agreed on the telecon on 18 Oct was less sophisticated than
the solution you describe. From the minutes of 18 Oct:
   WSRF25. Add optional element qname to SetResourcePropertyRequestFailed
   fault to indicate the element that was being processed when the fault
   occurred. Add boolean attribute/elem to this fault to indicate whether
   NO changes were made. Absence of value indicates some changes may have
   occurred.

The resolution should equally have applied to all faults for
Set/Update/Insert/DeleteResourceProperty.
The spec already states "The fault message MUST also indicate whether the
effects of processing previous components were restored or not. " but does
not describe how the fault must indicate this.

I propose that each fault defined for these 4 WSRF-RP operations be
extended with an element containing:
   attribute to indicate whether NO changes were made. Absence of attribute
   same as value of false.
   optional child element containing the current value of the RP that
   failed
   optional child element containing the value to which the RP would have
   changed if the operation had been successful (the requested value).

Pseudo schema for fault extension element:

<wsrf-rp:FailedOnRP restored=true | false>
     <wsrf-rp:CurrentValue>{any}</wsrf-rp:CurrentValue> ?
     <wsrf-rp:RequestedValue>{any}</wsrf-rp:RequestedValue> ?
</wsrf-rp:FailedOnRP>

For example

<wsrf-rp:FailedOnRP restored=false>
     <wsrf-rp:CurrentValue>
       <tns:StorageCapability>
         <tns:DataRedundancyMax>42</tns:DataRedundancyMax>
       <tns:StorageCapability>
    </wsrf-rp:CurrentValue>
     <wsrf-rp:RequestedValue>
       <tns:StorageCapability>
         <tns:DataRedundancyMax>64</tns:DataRedundancyMax>
       <tns:StorageCapability>
    </wsrf-rp:RequestedValue>
</wsrf-rp:FailedOnRP>


Since restored=false, the state of the WS-Resource may be incoherent.


Regards,
Ian Robinson
STSM, WebSphere Messaging and Transactions Architect
IBM Hursley Lab, UK
ian_robinson@uk.ibm.com


                                                                       
             Steve Graham                                              
             <sggraham@us.ibm.                                         
             com>                                                       To
                                       wsrf@lists.oasis-open.org       
             25/10/2004 23:59                                           cc
                                                                       
                                                                   Subject
                                       [wsrf] WSRF25 Proposed solution 
                                                                       
                                                                       
                                                                       
                                                                       
                                                                       
                                                                       





Add to the fault descriptions in SetRP and the 3 InsertRP/UpdateRP and
DeleteRP message exchanges:

Add to the fault descriptions in SetRP and the 3 InsertRP/UpdateRP and
DeleteRP message exchanges:

For each ResourceProperty successfully modified by the request message, the
fault message MUST include an element of the following type (derived from
BaseFaultType) amongst its FaultCause child elements:

<wsrf-rp:SuccessfullyModifiedResourceProperties>
  <Timestamp>xsd:dateTime</Timestamp>
  <OriginatorReference>
     wsa:EndpointReferenceType
  </OriginatorReference> ?
  <ErrorCode dialect="anyURI">xsd:string</ErrorCode> ?
  <Description>xsd:string</Description> *
  <FaultCause>wsbf:BaseFault</FaultCause> *
</wsrf-rp:SuccessfullyModifiedResourceProperties>
The type of the SuccessfullyModifiedResourceProperties element is an
extension of the BaseFaultType defined in WS-BaseFaults. It is further
constrained as follows:
/wsrf-rp:SuccessfullyModifiedResourceProperties/ErrorCode
·        This element contains the QName of the resource property
/wsrf-rp:SuccessfullyModifiedResourceProperties/ErrorCode/@Dialect
·        This value MUST be the following URI, designating the error code
corresponds to a SuccessfullyModifiedResourceProperty
o
http://docs.oasis-open.org/wsrf/2004/06/wsrf-WS-ResourceProperties-1.2
/SuccessfullyModifiedResourceProperty

sgg note: the pseudo-schema of the BaseFault differs from the schema
definition of BaseFaultType. The schema definition of ErrorCode derives
from xsd:anyType
++++++++
Steve Graham
(919)254-0615 (T/L 444)
STSM, On Demand Architecture
Member, IBM Academy of Technology
<Soli Deo Gloria/>
++++++++



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]