WS-BaseFaults

WS-BaseFaults

Steve Tuecke

Globus Alliance @ Argonne

[email protected]

2WS-Resource Framework www.globus.org/wsrf

Motivation

WSDL request-response operations allow for zero or more “fault” messages

Allowing service requesters to automatically (without human intervention) understand and/or adapt to faults requires interface designers to define rich, structured fault messages

Standard fault messages encourage tooling that can assist interface designers, service implementers, and client implementers


Approach

Define base set of information that can appear in fault messages

Convention for how to extend this base fault type for more specialized faults◊ Refine the type of the fault◊ Add information relevant to that refined

fault type Convention for using these extended fault

element as WSDL 1.1 fault messages


BaseFault Element

<BaseFault> <-- type=BaseFaultType -->

<Timestamp>xsd:dateTime</Timestamp>

<OriginatorReference>

wsa:EndpointReferenceType

</OriginatorReference> ?

<ErrorCode dialect="anyURI">xsd:string</ErrorCode> ?

<Description>xsd:string</Description> *

<FaultCause>wsbf:BaseFault</FaultCause> *

</BaseFault>


BaseFaultType Fields (1)

Timestamp (required): Time at which the fault occurred

OriginatorReference (optional): WS-Addressing EndpointReference of the WS that generated the fault◊ Can omit if it is clearly implied◊ Useful particularly with FaultCause

ErrorCode (optional): String error code for supporting legacy fault reporting systems◊ @dialect: URI specifying context of string


BaseFaultType Fields (2)

Description (0..unbounded): Plain language description(s) of the fault◊ Use with xsi:lang

FaultCause (0..unbounded): BaseFault element(s) that describes the underlying cause of this fault.


Using BaseFaultType

For each distinct fault on WSDL operation

1. Define XSD complexType that extends BaseFaultType• Represents the fault’s distinct type• May not define any additional fields

2. Define XSD element with this extended fault type

3. Define WSDL message using this fault element

4. Define WSDL operation fault element using this messag


Example (1)

<wsdl:portType name=“ServiceGroupRegistration” …>

<wsdl:operation name="Add">

<wsdl:input name="AddRequest“ message="wssg:AddRequest"/>

<wsdl:output name="AddResponse"message="wssg:AddResponse"/>

<wsdl:fault name="UnsupportedMemberInterfaceFault"

message="wssg:UnsupportedMemberInterfaceFault"/>

<wsdl:fault name="AddRefusedFault"

message="wssg:AddRefusedFault"/>

</wsdl:operation>

</wsdl:portType>


Example (2)

<wsdl:message name="AddRefusedFault">

<wsdl:part name="AddRefusedFault"

element="wssg:AddRefusedFault" />

</wsdl:message>

<xsd:complexType name="AddRefusedFaultType">

<xsd:complexContent>

<xsd:extension base="wsbf:BaseFaultType"/>

</xsd:complexContent>

</xsd:complexType>

<xsd:element name="AddRefusedFault"

type="wssg:AddRefusedFaultType"/>


Example (3)

<xsd:complexType name=“ExceededMaxSizeFaultType">

<xsd:complexContent>

<xsd:extension base="wsbf:AddRefusedFaultType">

<xsd:sequence>

<xsd:element name=“maxSize”

type=“xsd:integer”\>

</xsd:sequence>

</xsd:extension>

</xsd:complexContent>

</xsd:complexType>

<xsd:element name=“ExceededMaxSizeFault"

type="wssg:ExceededMaxSizeFaultType"/>


Binding to JAX-RPC

Using XSD type extension to model fault type hierarchies results in appropriate Java object type hierarchies

Java exception catch blocks can match on this type hierarchy


Binding to SOAP

WS-BaseFaults only specifies what is done at WSDL 1.1 abstract interface (portType) level◊ Intended for defining service/application faults

Binding a fault message to SOAP is the purview of a WSDL binding definition◊ Use standard WSDL 1.1 SOAP 1.1 binding

Issue: Some redundancy between WS-BaseFault information and SOAP 1.2 faults◊ May want some changes to WS-BaseFaults for

WSDL 2.0 and its SOAP 1.2 binding

WS-BaseFaults

Documents

Transcript of WS-BaseFaults