1 / 12

WS-BaseFaults

WS-BaseFaults. Steve Tuecke Globus Alliance @ Argonne tuecke@mcs.anl.gov. Motivation. WSDL request-response operations allow for zero or more “fault” messages

wiley
Download Presentation

WS-BaseFaults

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. WS-BaseFaults Steve Tuecke Globus Alliance @ Argonne tuecke@mcs.anl.gov

  2. 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

  3. 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

  4. 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>

  5. 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

  6. 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.

  7. Using BaseFaultType • For each distinct fault on WSDL operation • Define XSD complexType that extends BaseFaultType • Represents the fault’s distinct type • May not define any additional fields • Define XSD element with this extended fault type • Define WSDL message using this fault element • Define WSDL operation fault element using this messag

  8. 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>

  9. 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"/>

  10. 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"/>

  11. 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

  12. 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

More Related