Web services, WSDL and message flows

The term Web service here refers to an interface described by WSDL and accessible over one of the transports supported by the broker, generally HTTP, JMS or MQ.

For descriptions of the transports see:

WSDL

The logical part of a WSDL definition describes the format of the business messages to be exchanged and can be imported by the broker to create a message model at design time. (See Importing from WSDL).

The physical part of a WSDL definition describes the actual end-points for the service and the protocol used to exchange messages. The physical binding information is not imported at design time. You must implement the protocol and end-point details in a message flow, as follows:
  • Using the binding SOAP/HTTP, in which case you would implement a flow using HTTP nodes (HTTPInput and HTTPReply if a flow implements a Web service, or HTTPRequest if a flow invokes a Web service).
  • Using the binding SOAP/JMS, where you would implement a flow using JMS or MQ nodes.
  • You can configure message flows that receive input messages from clients using one transport, and interact with a Web service or legacy application using another.
  • You can propagate a message to more than one location – for instance the Web service response to be returned to a client by an HTTPReply node might first be sent to an auditing application using an MQOutput node (making any required adjustments to the message headers).

It is also possible to take an existing message model and generate a WSDL definition; in this case you must supply the physical binding information. (See Generating a Web Service Definition from a message set).

The WSDL bindings discussed here are specifically those supported directly by the WSDL Generator wizard:
  • SOAP/HTTP
  • SOAP/JMS
that is, those in which the message format used is SOAP, which can be parsed as XML in the MRM domain. However, note that the general definition of a Web service is broader than this and would allow message formats other than SOAP (for example XML-RPC) and transports other than HTTP or JMS (for example SMTP).
Your starting point is typically:
  • an existing message model which is to be exposed to a client (requiring WSDL generation)
  • an existing WSDL definition which will enable the broker to interact with a Web service (requiring WSDL import)

In both cases the broker will receive messages at runtime based on the WSDL which was generated or imported at design time.

(For more information on WSDL see Relationship of WSDL to Message Model and WSDL validation).

The scenarios

A broker message flow can:
  • invoke external Web services
  • implement a Web service
  • do both
If the broker needs to interact with an existing Web service:
A WSDL definition for that service can be imported into a message set using the new WSDL importer. The resulting message set contains message definitions which model the SOAP envelope and the content of the corresponding SOAP messages. A flow developer can use these definitions to validate and work with an incoming message – for example defining a mapping to transform a SOAP request message into a SOAP response message.
If the broker already has existing message definitions which are going to be used in a Web services context:
The broker can export those definitions as a WSDL file which may then be consumed by other toolkits such as .NET.
To import WSDL:
Use the new option on the New Message Definition File wizard, or use the command mqsicreatemsgsetsfromwsdl. (See Importing data structures)
To export WSDL:
Set up categories using the Message Category File Wizard and Message Category Editor (See Working with a message category file) and then invoking the WSDL Generator Wizard (See Generating a Web Service Definition from a message set).

The pages in this section give an overview of the main Web services technologies:

Related concepts
WebSphere MQ Web Services Transport
Generate WSDL
Message flows overview
Related tasks
Developing message flows
Deploying
Related reference
Built-in nodes