Broker implements new Web service interface

In this Web service scenario, the broker provides a Web service interface to an existing non-Web-service application.

The diagram shows a message set being created from an interface definition (for example, a header file) of an existing application which 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 using the message set and WSDL is created to invoke the application. The message flow and message set are deployed to a broker, providing a Web service interface to the original application.

Key to symbols:

This diagram describes the symbols used in the other diagrams, and is not described here because those diagrams each 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.

Runtime

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

An existing CICS® application has a COBOL copybook interface.

  1. Import the COBOL copybook to create a message model.
  2. Create a message flow with nodes: HTTPInput, HTTPReply and CICS.
  3. Use the HTTPInput and HTTPReply nodes to provide the Web service facade.
  4. Use the CICS node to invoke the original CICS implementation.

Example 2

The message flow is invoked as a Web service
You modify the design of an existing message flow to interact with Web service clients across HTTP. The existing message flow takes a well-defined input message, and the client can use WSDL exported from the WebSphere® Message Broker tools in invoking the message flow.

Most message flows that currently use WebSphere MQ for input or output can be adapted to use HTTP as a replacement or additional protocol.

This represents a message flow with nodes HTTPInput, Compute1, DataUpdate, Compute2, and HTTPReply.

You can model the input message in the MRM domain and generate WSDL from the model, or you can process a generic XMLNS domain message. If you have defined the message in the MRM domain, you can configure the HTTPInput node to validate the input message. The node generates an exception if the message does not conform to the model.

You can configure the HTTPReply node to generate a set of default HTTP headers for the reply message sent to the client. Generate 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 3

The message flow provides access to a WebSphere MQ application
You design two message flows that receive requests from and send replies to Web service clients, and interact with an existing WebSphere MQ application that has not been adapted to communicate across HTTP.

The first message flow receives inbound requests from Web service clients in an HTTPInput node. It includes a Compute node to transform the request in some way and an MQOutput node to send the modified request to the WebSphere MQ application.

The second message flow receives the response from that application in an MQInput node. The message is passed to a Compute node that transforms the message and propagates it to an HTTPReply node that sends it as a reply to the original Web service client.

Although the transformations completed by each Compute node might be trivial, the ESQL code in the first Compute node must save HTTP state information that is retrieved by the second Compute node to ensure that the replies from the WebSphere MQ application are returned to the client that sent the original request.

This represents two message flows; the first has nodes HTTPInput, Compute1, and MQOutput. The second has MQInput, Compute2, and HTTPReply. The MQOutput node that ends the first flow puts a message to a WebSphere MQ queue serviced by an existing application, which puts its responses to the input queue serviced by the MQInput node that starts the second flow.

The first message flow receives the message, does whatever transformations are needed, and encodes the HTTP request identifier in the outbound message. (The request identifier can also be stored in a database if you prefer). The HTTPInput node provides the request identifier as a field in the LocalEnvironment tree called Destination.HTTP.RequestIdentifier and the Compute1 node can read and store this value.

The second message flow receives the reply message and transforms it back into the client message format. The Compute2 node reads the HTTP request identifier from the message, and sets LocalEnvironment.Destination.HTTP.RequestIdentifier using this value. The HTTPReply node uses the request identifier to ensure that the message reaches the correct HTTP client.

The implementation of this scenario requires correct handling of the MQMD. Messages that come into a message flow across HTTP must have an MQMD added before they are sent to an MQOutput node. Also, any messages coming in across WebSphere MQ must have the MQMD removed before being sent into an HTTPReply or HTTPRequest node (unless including an MQMD in the HTTP stream is desired).

In the ESQL module for the Compute1 node, include a code statement similar to 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 similar to the following statement:

SET OutputLocalEnvironment.Destination.HTTP.RequestIdentifier =     
			CAST(InputRoot.XMLNS.A.MessageID AS BLOB);
Related concepts
XML domain message flows
Broker calls existing Web service
Broker implements existing Web service interface
Broker implements non-Web-service interface to new Web service
Notices | Trademarks | Downloads | Library | Support | Feedback

Copyright IBM Corporation 1999, 2009Copyright IBM Corporation 1999, 2009.
Last updated : 2009-01-07 15:20:39

ac34540_