Configuring message flows by using a WSDL

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 create a Web service in IBM Integration Bus by importing a WSDL or by defining a new interface, using the New Integration Service wizard. For more information, see Developing integration solutions by using integration services and Creating a solution based on WSDL or XSD files. Alternatively, you can configure SOAP nodes by dragging a WSDL from your workspace onto the node, or by specifying the WSDL using the WSDL file name property on the node.

You can change the operation mode of the SOAP nodes so that they act in gateway mode. In gateway mode, a WSDL is not required to configure the nodes because they handle generic request/response and one-way SOAP messages that are not tied to a specific WSDL. For more details, see Gateway operation mode for SOAP nodes.

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.