W3C home > Mailing lists > Public > public-soap-jms@w3.org > May 2010

ACTION-168 - Develop a more detailed proposal for issue 34

From: Peter Easton <peaston@progress.com>
Date: Mon, 24 May 2010 18:38:38 -0400
To: "public-soap-jms@w3.org" <public-soap-jms@w3.org>
Message-ID: <6F07B1E4CA74F3469AAA1DA148515F840146304993@PSCMAIL02.bedford.progress.com>
Background

"Issue 34 soap-jms xsd should define fault sub-code QName types" was raised and discussed at the 5/18/2010 meeting. It was pointed out that whilst sub-code type information could be added to the current schema section in the specification, the binding of JMS fault sub-codes to SOAP 1.1 faults leads to a subtle schema difference. In the SOAP/JMS specification, JMS fault sub-code is a sub-element of the SOAP 1.1 fault detail element. In this use-case the JMS fault sub-code may have textual content. In SOAP 1.2, JMS fault sub-code appears as the SOAP 1.2 subcode element. No textual content is allowed under the subcode in here.

A Wider Issue

A more general issue arises of whether our definition of the SOAP 1.1 fault binding should be changed. 

A number of Web-Services specifications already defined fault sub-codes. All WS-Security specifications, WS-RM and WS-A define sub-codes. But their binding approach to SOAP 1.1. differs from that of the current SOAP-JMS Spec. Their approach is that the SOAP 1.1 faultcode element contains a specification-defined fault QName.

Note that WS-I Profile 1.1 appears to support both styles, e.g.

"R1004 When an ENVELOPE contains a faultcode element, the content of that element SHOULD be either one of the fault codes defined in SOAP 1.1 (supplying additional information if necessary in the detail element), or a Qname whose namespace is controlled by the fault's  specifying authority(in that order of preference)."

And WS-I gives an example....

CORRECT: 
<soap:Fault xmlns:soap='http://schemas.xmlsoap.org/soap/envelope/'
            xmlns:c='http://example.org/faultcodes' >
  <faultcode>c:ProcessingError</faultcode>
  <faultstring>An error occured while processing the message
  </faultstring>
</soap:Fault>


Proposal

The following proposes that SOAP/JMS fault bindings for SOAP 1.1 be brought in line with the other specifications mentioned above.

For SOAP 1.1 faults, the faultcode element contains the SOAP/JMS fault sub-code. The faultstring element can contain some textual fault information.

For SOAP 1.2 faults, the current binding remains. The Fault/Code/Value is env:Sender (as defined in SOAP 1.2) and the Fault/Code/Subcode/Value is the SOAP/JMS fault sub-code. Fault/Reason/Text can contain some textual fault information.

Details

Rewrite SOAP 1.1 portion of Section 2.8 as follows:

The SOAP 1.1 specification does not support subcodes directly. In that scenario, the faultcode element should have a QName that matches the subcode for SOAP 1.2. The faultstring element can contain textual fault information. The same error as above, shown in SOAP 1.1:

Example: SOAP 1.1 Fault payload with the contentTypeMismatch subcode

<env:Envelope
     xmlns:env="http://schemas.xmlsoap.org/soap/envelope/">
   <env:Body>
       <env:Fault xmlns:soapjms="http://www.w3.org/2008/07/soap/bindings/JMS/">
           <faultcode>soapjms:contentTypeMismatch</faultcode>
           <faultstring> The content type of the JMS payload does
not match the XML</faultstring>
       </env:Fault>
   </env:Body>
</env:Envelope>

Add the following definitions to the SCHEMA section:

  <xs:simpleType name="FaultCodesType">
    <xs:restriction base="xs:QName">
      <xs:enumeration value="soapjms:contentTypeMismatch"/>
      <xs:enumeration value="soapjms:malformedRequestURI"/>
      <xs:enumeration value="soapjms:mismatchedSoapAction"/>
      <xs:enumeration value="soapjms:missingContentType"/>
      <xs:enumeration value="soapjms:missingRequestURI"/>
      <xs:enumeration value="soapjms:unrecognizedBindingVersion"/>
      <xs:enumeration value="soapjms:unsupportedJMSMessageFormat"/>
    </xs:restriction>
  </xs:simpleType>
Received on Monday, 24 May 2010 22:41:09 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Saturday, 18 December 2010 18:16:24 GMT