You can use the WS-I Validator to check your WSDL definitions against the Basic Profile; see WS-I Basic Profile Version 1.1.
- Manually against a specific .wsdl resource in
the workbench.
This option enables you to investigate and fix WS-I compliance problems; all validation issues are displayed as task list errors and warnings.
- Automatically, when WSDL is imported or generated.
You can import WSDL definitions by using the Message Model wizard.
- Select .
- Click Service Policies, and expand Profile Compliance.
- Select one of the following profiles:
- WS-I AP compliance level (WS-I Attachments Profile 1.0)
- WS-I SSBP compliance level (WS-I Simple SOAP Binding Profile 1.0)
- Select a compliance level:
- Select Suggest compliance to run the validator with errors treated as unrecoverable, but warnings only notified. This is the default setting.
- Select Require compliance to run the validator with errors and warnings treated as unrecoverable.
- Select Ignore compliance if you do not want to run the validator.
The AP selection applies automatically to the SSBP field, therefore Ignore is not explicitly selectable unless the AP selection is set to Ignore.
- document-literal means the combination style="document" and use="literal"
- rpc-literal means the combination style="rpc" and use="literal"
- rpc-encoded means the combination style="rpc" and use="encoded"
- Your WSDL is rpc-encoded
- WSDL with use="encoded" is not WS-I compliant
and can lead to operational problems because products of different
vendors can make different assumptions about the expected SOAP payload.
WS-I: (BP2406) The use attribute of a soapbind:body, soapbind:fault, soapbind:header, and soapbind:headerfault does not have the value of "literal".
- Your WSDL is document-literal, but one or more WSDL part definitions refer to XML Schema types.
- In document-literal WSDL, the SOAP body payload
is the XML Schema element that is referred to by the appropriate WSDL
part.
If a type is specified instead of an element, the SOAP payload is potentially ambiguous (the payload name is not defined) and interoperability problems are likely.
WS-I: (BP2012) A document-literal binding contains soapbind:body elements that refer to message part elements that do not have the element attribute.
- Your WSDL is rpc-literal or rpc-encoded, but one or more WSDL part definitions refer to XML Schema elements.
- In rpc-style WSDL, the SOAP body payload is the WSDL operation
name, and its children are the WSDL parts that are specified for that
operation.
If an element is specified instead of a type, the SOAP message payload is potentially ambiguous (the payload name might be the WSDL part name or the XML Schema element name), and interoperability problems are likely.
WS-I: (BP2013) An rpc-literal binding contains soapbind:body elements that refer to message part elements that do not have the type attribute.
- Your WSDL includes SOAP header, headerfault or fault definitions that refer to XML Schema types.
- In rpc-style WSDL, the SOAP body is correctly defined through
XML Schema types as described above.
SOAP headers and faults, however, do not correspond to an rpc function call in the same way as the body.
In particular, there is no concept of 'parameters' to a header or fault, and a header or fault must always be defined in terms of XML Schema elements to avoid potential ambiguity. Effectively, header and fault definitions in WSDL are always document-literal.
WS-I: (BP2113) The soapbind:header, soapbind:headerfault, or soapbind:fault elements refer to wsd:part elements that are not defined using only the "element" attribute.
- Your WSDL is rpc-literal or rpc-encoded, but no namespace was specified for an operation.
- In rpc-style WSDL, the SOAP message payload is the WSDL operation
name, qualified by a namespace that is specified as part of the WSDL
binding.
If no namespace is specified then the SOAP message payload is potentially ambiguous (the payload name might be in no namespace, or might default to use a different namespace, such as the target namespace of the WSDL definition) and interoperability problems are likely.
WS-I: (BP2020) An rpc-literal binding contains soapbind:body elements that either do not have a namespace attribute, or have a namespace attribute value that is not an absolute URI.
- Your WSDL includes a SOAP/JMS binding.
- If your WSDL uses a SOAP/JMS transport URI it is not WS-I compliant. An error is shown if strict WS-I validation is enabled. To disable strict WS-I validation, click and select the WS-I BP 1.1: Allow SOAP/JMS as transport URI. By default strict WS-I validation is disabled.
- Use document-style WSDL whenever possible.
- Use literal encoding, if rpc-style WSDL is necessary.
- Ensure that the WSDL operation definitions are qualified by a valid namespace attribute, if rpc-encoded WSDL must be used.
Last updated Friday, 21 July 2017