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.

Key to symbols:

Possible uses
- The integration node provides a web service implementation with a different
quality of service from existing implementations.
- The integration node provides a migration strategy for the existing implementation.
Design steps
- Import WSDL to create a message set containing definitions for
the SOAP messages described by the WSDL.
- 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.
- 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:
- Using SOAPInput and SOAPReply nodes:
- 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.
- Using SOAPInput, SOAPReply and MQGet nodes:
- Using HTTPInput, HTTPReply and MQGet nodes:
- Using two message flows with SOAPInput,
SOAPReply nodes:
- Using two message flows with HTTPInput
and HTTPReply nodes:
The steps to develop the message flow are:
- Create a message model for the existing application interface, for example,
by importing a C header file for the application.
- Import an existing WSDL definition for the client.
- 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.