IBM Integration Bus, Version 10.0.0.9 Operating Systems: AIX, HP-Itanium, Linux, Solaris, Windows, z/OS


Integration node implements new web service interface

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.

The diagram is described in the surrounding text.

Key to symbols:

This diagram describes the symbols that are used in the other diagrams, which are not described here because the diagrams have their own descriptions.

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

Design steps

  1. Create a message set for the business messages, possibly by importing an existing interface definition such as a C header file or COBOL copybook.
  2. Generate a WSDL definition from the message set.
  3. Use a SOAP toolkit such as Rational® Application Developer to create a suitable web services client based on the WSDL.
  4. 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.

The following are typical message flow patterns. In each case the input and reply nodes replace or complement the original MQInput and MQOutput nodes. The main part of the flow is understood to do some useful processing.
  • Using SOAPInput and SOAPReply nodes:
    The diagram shows a message flow that provides a web service by using SOAPInput and SOAPReply nodes.
  • Using HTTPInput and HTTPReply nodes:
    The diagram shows a message flow that provides a web service by 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 IBM Integration Bus 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.

The following are typical message flow patterns. In each case the flow receives the web service request and build the response by using data returned from the application over WebSphere MQ.
  • Using two message flows with SOAPInput and SOAPReply nodes:
    The diagram shows two message flows that provides asynchronous access to a WebSphere MQ application by using SOAPInput and SOAPReply nodes.
  • Using two message flows with HTTPInput and HTTPReply nodes:
    The diagram shows two message flows that provides asynchronous access to a WebSphere MQ application by using 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:

The diagram shows how you can use 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:
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

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:
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);

ac34540_.htm | Last updated 2017-07-17 12:44:45