Message flow configuration with a WSDL file

You can use a WSDL file to configure message flows.

Message flows that work with web services typically use the SOAP nodes. For details about the SOAP nodes, see IBM Integration Bus and web services. You can change the operation mode of the SOAP nodes so that they act in gateway mode. In gateway mode, a WSDL file is not required to configure the nodes because they handle generic request and response and one-way SOAP messages that are not tied to a specific WSDL file.

You can create a web service in IBM Integration Bus in the following ways:
  • By importing a WSDL file.
  • By dragging a WSDL file onto a SOAP node to configure that node.
  • By specifying the WSDL file in the WSDL file name property of a SOAP node.
  • By defining a new interface with the New Integration Service wizard.

When you drag a WSDL file onto a SOAP node, the node properties are configured from the properties in the WSDL address URI. The transport properties on the SOAP node are populated according to the first binding imported from the WSDL file. Therefore, if the first imported binding describes a JMS transport, the JMS Transport properties are populated; if the first imported binding describes an HTTP transport, the HTTP Transport properties are populated. If you select another imported binding, the transport properties are populated accordingly. The portType appears differently depending on the transport selected.

The WSDL address element URI can exist in two different formats, W3C format, or IBM (deprecated) format. The format of the WSDL URI affects the names of the WSDL properties that the parser looks for to populate the SOAP node properties. For example, the JNDI context parameters table is not populated when you import an IBM-style WSDL because it does not support these properties in the WSDL address URI. The table is populated only if JNDI context parameters are present in a W3C-style WSDL. For details, see WSDL URI formats for JMS.

If you supply a service definition, endpoint properties are set automatically, but you can also set or override these properties manually.

Optionally, WSDL definitions can be split into multiple files. The typical arrangement is that a top-level service definition file imports a binding file, the binding file imports an interface file, and this interface file imports or includes schema definition files.

A WSDL portType (the logical WSDL interface) is not sufficient on its own to configure a SOAP node; a specific binding is required so that the SOAP payload is well-defined at run time.

A binding defines a use, which can be document (the default) or rpc. If the use is document, the SOAP payload is described by an XML Schema element in the WSDL. If the use is rpc, the SOAP payload is the WSDL operation name in a specified namespace.

If you drag a WSDL file onto a SOAP node from a shared library, the WSDL file name and Message model properties on the node specify the name of the shared library.

Configuring the SOAP nodes

The following nodes are configured explicitly by WSDL files:
The following nodes are configured implicitly by WSDL files, because they inherit the WSDL configuration of the node with which they are paired:

A SOAPReply node is always used with a SOAPInput node. For details of web service scenarios, see Web services scenarios.

A SOAPAsyncResponse node is always used with a SOAPAsyncRequest node, associated by the Unique Identifier property. For SOAP node usage patterns, see Web services scenarios.