You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@servicemix.apache.org by Grant McDonald <gm...@infocomp.com> on 2006/09/19 05:15:25 UTC

SOAP 1.1 support

Guys,

Whilst using the soap support to integrate a legacy component into
servicemix I noticed that the SOAP 1.1 fault support does not appear to
strictly support the 1.1 fault specification as outlined in the fault schema
available at http://ftp.ibiblio.org/xml/books/xmljava/chapters/apb.html.
Given the schema the fault elements are all defined as living in the SOAP
envelope namespace (http://schemas.xmlsoap.org/soap/envelope/).  The problem
is that SoapMarshaler in servicemix-soap declares the faultcode,
faultstring, faultactor and faultdetail elements as having the default empty
namespace.  Am I missing something in the spec?  Should we be supporting
both qualified and unqualified fault elements for SOAP 1.1?

Additionally I was wondering what thoughts people had on the content of
normalised messages for SOAP faults?  Should all the fault elements
(including detail) be attached as JBI properties and the entire message as
the content?  The reason why I ask is that JBI properties are not readily
available from BPEL (using bpe) so it is an advantage to have the entire
SOAP fault available.  If people think this is advantageous I already have a
patch for this ;)

Regards,

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
   Grant McDonald
   Programmer
   InfoComp 
   Wollongong, Level 2, 63 Market St
   Phone: +61 (2) 4298 9118
   email: gmcdonald@infocomp.com
   www.infocomp.com 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~


Re: SOAP 1.1 support

Posted by Guillaume Nodet <gn...@gmail.com>.
The WS-I BP 1.1 mandates faults elements to be unqualified.
See [1] for more informations.  The corrected schema for
SOAP is available at [2].

I'd like to follow the directive in the JBI spec saying that
SOAP must stay on the binding side and should be
considered as a protocol.  I do understand the advantage
of having the whole faults in the payload, but the downside
is that if will be more difficult to interoperate with other
components that do not throw soap 1.1 wrapped faults.

Maybe, Alex or any other Ode team member could share
his view on that.  I don't think that using the wsdl 1.1 wrapped
message for faults will completely solve the problem.

[1] http://www.ws-i.org/Profiles/BasicProfile-1.1.html#SOAP_Fault_Namespace_Qualification
[2] http://ws-i.org/profiles/basic/1.1/soap-envelope-2004-01-21.xsd

On 9/19/06, Grant McDonald <gm...@infocomp.com> wrote:
> Guys,
>
> Whilst using the soap support to integrate a legacy component into
> servicemix I noticed that the SOAP 1.1 fault support does not appear to
> strictly support the 1.1 fault specification as outlined in the fault schema
> available at http://ftp.ibiblio.org/xml/books/xmljava/chapters/apb.html.
> Given the schema the fault elements are all defined as living in the SOAP
> envelope namespace (http://schemas.xmlsoap.org/soap/envelope/).  The problem
> is that SoapMarshaler in servicemix-soap declares the faultcode,
> faultstring, faultactor and faultdetail elements as having the default empty
> namespace.  Am I missing something in the spec?  Should we be supporting
> both qualified and unqualified fault elements for SOAP 1.1?
>
> Additionally I was wondering what thoughts people had on the content of
> normalised messages for SOAP faults?  Should all the fault elements
> (including detail) be attached as JBI properties and the entire message as
> the content?  The reason why I ask is that JBI properties are not readily
> available from BPEL (using bpe) so it is an advantage to have the entire
> SOAP fault available.  If people think this is advantageous I already have a
> patch for this ;)
>
> Regards,
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>    Grant McDonald
>    Programmer
>    InfoComp
>    Wollongong, Level 2, 63 Market St
>    Phone: +61 (2) 4298 9118
>    email: gmcdonald@infocomp.com
>    www.infocomp.com
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
>
>


-- 
Cheers,
Guillaume Nodet