In this scenario, the integration node 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 an integration node, 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.
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.
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.
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 IBM Integration Bus and web services.
In this example, a message flow is created to provide asynchronous access to a WebSphere MQ application.
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.
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
SET OutputRoot.XMLNS.A.MessageID =
CAST(InputLocalEnvironment.Destination.SOAP.Reply.ReplyIdentifier AS CHARACTER);
In
the ESQL module for the Compute2 node, include a code statement like
the following statement: SET OutputLocalEnvironment.Destination.SOAP.Reply.ReplyIdentifier =
CAST(InputRoot.XMLNS.A.MessageID AS BLOB);
HTTP nodes
SET OutputRoot.XMLNS.A.MessageID =
CAST(InputLocalEnvironment.Destination.HTTP.RequestIdentifier AS CHARACTER);
In
the ESQL module for the Compute2 node, include a code statement like
the following statement: SET OutputLocalEnvironment.Destination.HTTP.RequestIdentifier =
CAST(InputRoot.XMLNS.A.MessageID AS BLOB);