See information about the latest product version
Broker implements existing Web service interface
In this scenario, the broker 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 broker provides a Web service implementation with a different quality of service from existing implementations.
- The broker 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 broker 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:
- 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.
The use of the SOAP domain for these scenarios is preferred. For more information about choosing a domain for Web services, see WebSphere Message Broker and Web services.
For more information about the asynchronous request-reply scenario, see A request-response scenario that uses an MQGet node.
You can view information about samples only when you use the information center that is integrated with the WebSphere Message Broker Toolkit or the online information center. You can run samples only when you use the information center that is integrated with the WebSphere Message Broker Toolkit.