WebSphere Message Brokers
File: ac34540_
Writer: Jane Brockbank

Concept topic

This build: July 31, 2007 21:20:20

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 an existing application, whose definition file is imported to a message set. A WSDL file is generated from the message set. The message set is deployed to a flow in a broker. The flow interacts at runtime with the original existing application and the Web service client.

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 is sometimes referred to as a Web service facade. The design of the Web service interface will typically involve some regrouping, restriction or enhancement of the existing interface, and is not constrained by an existing WSDL definition.

Possible uses

The broker provides a Web services interface to an existing application, optionally providing other mix-in capabilities such as auditing the requests made.

Over time the implementation can be changed without affecting the interface presented to the Web services client.

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 tooling 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, HTTPReply.

You can model the input message in the MRM domain and generate WSDL from the model, or you could 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. This 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 must save HTTP state information that is retrieved by the second 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, MQOutput. The second has MQInput, Compute2, 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 could 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 Compute1 can read and store this value.

The second message flow receives the reply message and transforms it back into the client message format. Compute2 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 Compute1, include a statement like this:

SET OutputRoot.XMLNS.A.MessageID =    
			CAST(InputLocalEnvironment.Destination.HTTP.RequestIdentifier AS CHARACTER);

In the ESQL module for Compute2, code a statement like this:

SET OutputLocalEnvironment.Destination.HTTP.RequestIdentifier =     
			CAST(InputRoot.XMLNS.A.MessageID AS BLOB);
Related concepts
Web services, WSDL and 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, 2007Copyright IBM Corporation 1999, 2007. All Rights Reserved.
This build: July 31, 2007 21:20:20

ac34540_ This topic's URL is: