[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]