添加链接
link之家
链接快照平台
  • 输入网页链接,自动生成快照
  • 标签化管理网页链接

WSDL validation

The WS-I Validator can be used to check your WSDL definitions against the Basic Profile.

For more information about the WS-I Basic Profile refer to the WS-I, and in particular the WS-I Basic Profile document:
  • Web Services Interoperability Organization (WS-I)
  • WS-I deliverables index
  • You can use the WS-I Validator to check your WSDL definitions against the Basic Profile; see WS-I Basic Profile Version 1.1 .

    You can run the validator in either of the following ways:
    • 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.

      You can control the behavior of the validator by setting a compliance level for your profile.
      1. Select Preferences > Web services .
      2. Click Service Policies , and expand Profile Compliance .
      3. 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.

            The following terms refer to the three broad categories of WSDL definition:
            • 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"
            • The following are typical validation problems using the preceding terminology:
              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

              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 Window > Preferences > Integration Development > WSDL > Validation and select the WS-I BP 1.1: Allow SOAP/JMS as transport URI . By default strict WS-I validation is disabled.
              Web service interoperability is improved if you implement the following actions: