Troubleshooting
Problem
A business to business (B2B) Web service request using the SOAP encoding is failing because an encoding style other than http://schemas.xmlsoap.org/soap/encoding/ is specified in the WSDL but is not being serialized into the SOAP message sent by our server. This technote addresses what, if anything, can be done to get the encoding style added to the SOAP message.
Cause
In this WSDL excerpt, a custom encoding style is specified:
. . .
<wsdl:operation name="getQuote">
<wsdlsoap:operation soapAction="..."/>
<wsdl:input name="getQuoteRequest">
<wsdlsoap:body use="literal"
encodingStyle="http://some/sort/of/URI"/>
</wsdl:input>
<wsdl:output name="getQuoteResponse">
<wsdlsoap:body use="literal"
encodingStyle="http://some/sort/of/URI"/>
</wsdl:output>
</wsdl:operation>
. . .
This example XML payload failed with the "Encoding not supported: null" error because the SOAP encodingStyle attribute (that is, soapenv:encodingStyle="http://some/sort/of/URI") did not appear in the SOAP message.
<?xml version="1.0" encoding="UTF-8"?> <soapenv:Envelope
xmlns:soapenv=
"http://schemas.xmlsoap.org/soap/envelope/"
xmlns:soapenc=
"http://schemas.xmlsoap.org/soap/encoding/"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:xsi=
"http://www.w3.org/2001/XMLSchema-instance">
<soapenv:Header>
...
</soapenv:Header>
<soapenv:Body>
<getQuote xmlns="http://some/sort/of/URI">
<Quote>WZYX</Quote>
<Value>100.50</Value>
</getQuote>
</soapenv:Body>
</soapenv:Envelope>
<soapenv:Envelope
xmlns:SOAP="urn:schemas-xmlsoap-org:soap.v1"
soapenv:encodingStyle="http://some/sort/of/URI">
<soapenv:Body>
<soapenv:Fault>
<faultcode>300</faultcode>
<faultstring>Invalid Request</faultstring>
<runcode>1</runcode>
<detail xmlns="http://some/sort/of/URI">
<message>Encoding not supported: null</message>
<errortype>XMLError</errortype>
</detail>
</soapenv:Fault>
</soapenv:Body>
</soapenv:Envelope>
When manually adding the SOAP encodingStyle attribute, (such as
soapenv:encodingStyle="http://some/sort/of/URI") to the envelope and sending the payload by way of XML over HTTP, the request worked:
<?xml version="1.0" encoding="UTF-8"?>
<soapenv:Envelope
xmlns:soapenv="
http://schemas.xmlsoap.org/soap/envelope/"
soapenv:encodingStyle="http://some/sort/of/URI"
xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
...
</soapenv:Envelope>This raised the following user questions:
Does this mean that only RPC/Literal and Document/Literal are supported and all other encoding styles are filtered out (and the WebSphere runtime is enforcing the WS-I standard) or that there is a defect or limitation preventing the WSDL specified soapenv:encodingStyle= "http://some/sort/of/URI", from being included in the outbound SOAP message?
If WebSphere is enforcing WS-I, should it be? What is preventing the WSDL specified encoding style by the web service, though not WS-I conforming, from being passed in the message? Should this be considered a defect?
Resolving The Problem
WS-I (see Related Information) compliant Web services must employ the Document/Literal or RPC/Literal style and use, and they must not specify the encodingStyle attribute. Non WS-I compliant Web services can specify an encodingStyle attribute; however, only the standard SOAP encoding style from chapter 5 of the SOAP 1.1 specification, at http://schemas.xmlsoap.org/soap/encoding/, is supported by the WebSphere runtime. There is no encodingStyle for Literal in WS-I compliant web services.
WebSphere Application Server (WAS) version 5.0.2+ supports Document/Literal, RPC/Literal, and RPC/Encoded with the SOAP 1.1 encoding style, "http://schemas.xmlsoap.org/soap/encoding/". WAS does not support custom encoding styles and the custom de-serialization and serialization rules that would necessarily have to accompany such encoding styles. WAS, WebSphere® Studio Application Developer (WSAD) version 5.1.x and IBM® Rational® Application Developer (RAD) for WebSphere Software version 6.x encourage, but do not require, WS-I compliance.
Should WAS runtime be including the soapenv:encodingStyle in the outbound SOAP message?
This is not a problem that would ever get fixed, nor should it be treated as a feature extension request since it is totally outside of the scope of WS-I and is barely within the scope of WSDL 1.1 and SOAP 1.1.
This is made clear in Basic Profile Version 1.1 section "3.1.6 SOAP encodingStyle Attribute" and in the corresponding Basic Profile Version 1.0 section:
- 4.1.7 SOAP encodingStyle Attribute
The soap:encodingStyle attribute is used to indicate the use of a particular scheme in the encoding of data into XML. However, this introduces complexity, as this function can also be served by the use of XML Namespaces. As a result, the Profile prefers the use of literal, non-encoded XML.
R1005 A MESSAGE MUST NOT contain soap:encodingStyle attributes on any of the elements whose namespace name is "http://schemas.xmlsoap.org/soap/envelope/".
R1006 A MESSAGE MUST NOT contain soap:encodingStyle attributes on any element that is a child of soap:Body.
R1007 A MESSAGE described in an rpc-literal binding MUST NOT contain soap:encodingStyle attribute on any elements are grandchildren of soap:Body.
WAS v5.x and v6 are WS-I compliant. Apart from some exceptions documented in the WAS InfoCenters, the WAS runtime supports and encourages WS-I compliant Web services to help maximize interoperability of Web services across disparate computing platforms.
Additionally, SOAP 1.1 s4.1.1 and WSDL 1.1 s3.5 specify that whatever encodingStyles are declared in a WSDL's <soap:body> element should appear in the SOAP message at the level of the body element or higher. However, they also imply that whatever encodingStyle(s) are written in the WSDL and SOAP are of a kind that both the provider and requestor of the service understand and are capable of serializing and de-serializing. The WAS Web services engine only supports WS-I and RPC/Encoded with the SOAP encoding.Other encoding styles are not supported by the WAS engine.
Under what conditions, if any, should the WebSphere runtime be transmitting the same encodingStyle URIs in the SOAP message as are in the WSDL ?
The engine does not add the encodingStyle attributes for any encoding styles other than the standard SOAP chapter 5 encoding, http://schemas.xmlsoap.org/soap/encoding/. An application that must include a custom encodingStyle on a SOAP message may do so by building the raw SOAP message and transmitting it using JAX-RPC interfaces and implementation classes equipped with "SOAPElement" parameters as generated when the No data binding option is enabled.
The SOAP and WSDL specification state that the encodingStyle can be used with literal, but the exact meaning is not very clear. It seems to imply that encodingStyle, if present, can name a single particular encoding that must be obeyed by the sender of the message. Whether in the context of the literal or encoded use, the intent of an encodingStyle is that it is implemented by specific serialization and de-serialization rules in a runtime that understands the encodingStyle. Unless all parties in a Web service exchange understand the given encodingStyle, interoperability will be impaired, which justifies why the WS-I profiles do not permit the use of encodingStyle and favour non-encoded or "literal" use.
Provided WS-I conformance checking is enabled in the preferences, the WS-I WSDL and SOAP validators in WSAD and RAD will catch violations of the WS-I profiles and should help Web service application developers avoid using encodingStyle and other impediments to Web service interoperability.
The technote in Related Information: Web Services support for Schema/WSDL(s) containing optional JAX-RPC 1.0/1.1 XML Schema Types , is helpful in understanding some of the other related web services issues in the scope of WS-I and JAX-RPC 1.0, and has some discussion of
-noDataBinding.
Workaround:
Write a JAX-RPC Handler to insert the missing soapenv:encodingStyle attribute into the Envelope. See Related Information item: Web Service Handlers.
Conclusion:
WebSphere and Rational software products strategically support and endorse WS-I compliant Literal (non-encoded) Web services, and they support RPC SOAP encoded Web services for historical purposes. Other encodings are neither supported nor encouraged.
DISCLAIMER
All source code and/or binaries attached to this document are referred to here as "the Program". IBM is not providing program services of any kind for the Program. IBM is providing the Program on an "AS IS" basis without warranty of any kind. IBM WILL NOT BE LIABLE FOR ANY ACTUAL, DIRECT, SPECIAL, INCIDENTAL, OR INDIRECT DAMAGES OR FOR ANY ECONOMIC CONSEQUENTIAL DAMAGES (INCLUDING LOST PROFITS OR SAVINGS), EVEN IF IBM, OR ITS RESELLER, HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.
Related Information
Historical Number
23084 L6Q 000
Was this topic helpful?
Document Information
Modified date:
10 September 2020
UID
swg21217991