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.
- 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
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.