See information about the latest product version
Broker implements new Web service interface
In this scenario, the broker implements a new Web service interface. The WSDL for the Web service is generated from a message set and made available to clients. A message flow based on this WSDL and message set receives a request and then builds a response message by using data obtained from an existing non-Web-service application.
The following diagram shows a message set being created from an interface definition (for example, a header file) of an existing application that is not currently accessible as a Web service. A WSDL file is generated from the message set and exported for use by a Web service client. A message flow that uses the message set and WSDL is created to call the application. The message flow and message set are deployed to a broker, providing a Web service interface to the original application.

Key to symbols:

This scenario is sometimes referred to as a Web service facade. The design of the Web service interface typically involves some regrouping, restriction, or enhancement of the existing interface, and is not constrained by an existing WSDL definition.
Possible uses
- The broker provides a Web services interface to an existing application, optionally providing other mix-in capabilities such as auditing the requests made.
- Over time the implementation can be changed without affecting the interface presented to the Web services client.
Design steps
- Create a message set for the business messages, possibly by importing an existing interface definition such as a C header file or COBOL copybook.
- Generate a WSDL definition from the message set.
- Use a SOAP toolkit such as Rational® Application Developer to create a suitable Web services client based on the WSDL.
- Develop a message flow to implement the Web service.
At run time
Your message flow receives a Web service request, converts it into a form expected by the existing application and invokes the existing application. The response from the existing application is converted into a valid Web service response.
Example 1
In this example, an existing message flow is modified to provide a Web service. If the existing message flow models its data in a message set, a WSDL definition can be generated from that message set and made available to clients.
Most message flows that currently use WebSphere® MQ for input or output can be adapted to support Web services as a replacement or additional protocol.
- Using SOAPInput and SOAPReply nodes:
- Using HTTPInput and HTTPReply nodes:
If you use the SOAP domain, the logical tree shape will be different from the original domain and you will need to take account of this in the message flow. If you use the HTTP nodes with the original domain, the logical tree shape does not change. For information about choosing the domain, see WebSphere Message Broker and Web services.
- HTTP details
- If you use the HTTP nodes, you can configure the HTTPReply node to generate a set of default HTTP headers for the reply message sent to the client. Generating a set of default HTTP headers reduces the modifications that you must make to convert the message flow from one that processes WebSphere MQ messages to a flow that processes HTTP messages.
Example 2
In this example, a message flow is created to provide asynchronous access to a WebSphere MQ application.
- Using two message flows with SOAPInput and SOAPReply nodes:
- Using two message flows with HTTPInput and HTTPReply nodes:
In each case, the first message flow receives inbound requests from a Web service client. The Compute1 node transforms the request and an MQOutput node sends the modified request to the existing application.
In the second message flow, an MQInput node receives the response from the application. The Compute2 node then transforms the message and propagates it to a reply node that responds to the original Web service client.
The Compute1 node must also save some correlation information to be retrieved by the Compute2 node, ensuring that the replies from the WebSphere MQ application are returned to the client that sent the original request.
- HTTP details
Using HTTPInput and MQOutput nodes as the outbound message and MQInput and HTTPReply nodes as the response message:
One way to preserve the correlation information is for the Compute1 node to encode the correlation identifier in the outbound message. (Alternatively, the identifier can be stored in a database). The SOAPInput and HTTPInput nodes place the identifier as a field in the local environment tree and the Compute1 node can read and store this value. The location of the identifier differs between the SOAPInput and HTTPInput nodes, as described in the following sections.
SOAP nodes
The Compute2 node reads the SOAP reply identifier from the message and sets LocalEnvironment.Destination.SOAP.Reply.ReplyIdentifier by using this value. The SOAPReply node uses the reply identifier to ensure that the message reaches the correct HTTP client. In the ESQL module for the Compute1 node, include a code statement like the following statement:
In the ESQL module for the Compute2 node, include a code statement like the following statement:SET OutputRoot.XMLNS.A.MessageID = CAST(InputLocalEnvironment.Destination.SOAP.Reply.ReplyIdentifier AS CHARACTER);
SET OutputLocalEnvironment.Destination.SOAP.Reply.ReplyIdentifier = CAST(InputRoot.XMLNS.A.MessageID AS BLOB);
HTTP nodes
The Compute2 node reads the HTTP request identifier from the message and sets LocalEnvironment.Destination.HTTP.RequestIdentifier by using this value. The HTTPReply node uses the request identifier to ensure that the message reaches the correct HTTP client. In the ESQL module for the Compute1 node, include a code statement like the following statement:
In the ESQL module for the Compute2 node, include a code statement like the following statement:SET OutputRoot.XMLNS.A.MessageID = CAST(InputLocalEnvironment.Destination.HTTP.RequestIdentifier AS CHARACTER);
SET OutputLocalEnvironment.Destination.HTTP.RequestIdentifier = CAST(InputRoot.XMLNS.A.MessageID AS BLOB);