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


Integration node implements existing web service interface

In this scenario, the integration node implements an existing web service interface. The WSDL for the web service already exists, and is imported to create a message set. A message flow based on this message set receives a request, then builds a response message by using data obtained from an existing non-Web-service application.

The diagram is described in the preceding text.

Key to symbols:

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

Possible uses

Design steps

  1. Import WSDL to create a message set containing definitions for the SOAP messages described by the WSDL.
  2. Adapt the message set for the required existing interface, possibly by importing an existing interface definition such as a C header file or COBOL copybook.
  3. 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 HTTP web service client provides information on a particular subject (stock prices or exchange rates, for example). You want to replace this service with an inhouse database lookup solution, but want to make no changes to the clients because these are widely deployed.

Typical message flow patterns are shown in the following examples. In each case the intermediate request node retrieves the information from the database:

  1. Using SOAPInput and SOAPReply nodes:
    The diagram shows a message flow that operates as a database lookup solution by using SOAPInput and SOAPReply nodes.
  2. Using HTTPInput and HTTPReply nodes:
    The diagram shows a message flow that operates as a database lookup solution by using HTTPInput and HTTPReply nodes.

In the flows above, the input node receives the web service request. Compute1 then retrieves the required information from the database and generates the required web service response by using this data. The response is returned to the client by the reply node. In the examples you can use Mapping nodes instead of Compute nodes.

Example 2

In this example, an existing application is exposed as a web service, but there is a constraint on the interface with the web service, because a widely distributed client already uses a similar service that is defined by an existing WSDL definition. The integration node offers the same interface to the client, this might be because the original service offers a different quality of service or is to be discontinued.

Typical message flow patterns are shown in the following examples. In each case the message flows receive the web service request and build the response by using data returned from the application over WebSphere® MQ.

  1. Using SOAPInput, SOAPReply and MQGet nodes:
    The diagram shows a message flow that is described in the surrounding text.
  2. Using HTTPInput, HTTPReply and MQGet nodes:
    The diagram shows a message flow that is described in the surrounding text.
  3. Using two message flows with SOAPInput, SOAPReply nodes:
    The diagram shows a message flow that is described in the surrounding text.
  4. Using two message flows with HTTPInput and HTTPReply nodes:
    The diagram shows a message flow that is described in the surrounding text.
The steps to develop the message flow are:
  1. Create a message model for the existing application interface, for example, by importing a C header file for the application.
  2. Import an existing WSDL definition for the client.
  3. Create a flow by using the message set to implement the web service interface and mediate with the existing application.
Message flows 1 and 2 show a synchronous call to the application by using MQOutput and MQGet nodes. You can set a timeout in the MQGet node, to allow for failure of the remote application. The request-reply translation is handled in a single transaction enabling simple rollback and recovery. However, each incoming request has to be fully processed and responded to before moving onto the next request. This behavior might affect performance if the application cannot respond quickly. The message flows shown in examples 3 and 4, show an asynchronous equivalent. In each case the first flow stops after sending the message to the application, and becomes available to handle further requests. However, this scenario requires a correlation context to be saved in the request flow, and restored in the reply flow. You can store the correlation context on a queue, then use an MQGet node in the reply flow to retrieve it. This flow design enables the requests to be dispatched to the application promptly, and replies to be returned in the order that they are received. In the examples you can use Mapping nodes instead of Compute nodes.

The use of the SOAP domain for these scenarios is preferred. For more information about choosing a domain for web services, see IBM Integration Bus and web services.

For more information about the asynchronous request-reply scenario, see How the MQGet node implements WebSphere MQ MQGet API calls.


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