Broker calls existing Web service

In this scenario, the broker invokes an existing Web service implementation.

The diagram shows a Web service's associated WSDL file that is imported into a message set. The message set is deployed to a flow in a broker.

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.

Possible uses

Design steps

  1. Import WSDL to create a message set containing definitions for the SOAP messages described by the WSDL.
  2. Create a message flow to invoke the Web service. If the Web service transport is HTTP, then an HTTPrequest node would be used. If the Web service transport is JMS then appropriate JMS or WebSphere MQ nodes would be used.

Runtime

Your message flow creates an appropriately formatted Web service request, invokes the Web service, and parses the Web service response.

Example 1

In this example the broker acts as an intermediary to the Web service.

  1. Create a message flow with nodes: HTTPInput, HTTPRequest, and HTTPReply.
  2. The Web service client generates a Web service request. This is directed to the HTTPInput node by the broker.
  3. The message flow processes the message in some way.
  4. The HTTPRequest node sends a request to the original Web service and receives the response.
  5. The flow generates a Web service response and puts it to the HTTPReply node. The response might be based in full or in part on the response received by the HTTPRequest node.
  6. The broker sends the response to the Web service client.

If another application enabled for WebSphere MQ required the information in a different format then the message flow could arrange for the message to be propagated first to an MQOutput node for transmission to this application before continuing on to the end of the flow and the HTTPReply node which sends the expected Web service response. Appropriate Compute nodes would be required to transform the message (if required) and to manipulate the message headers (e.g. adding an MQMD header).

Example 2

In this example the broker provides auditing for a Web service.

  1. You design a message flow that includes an HTTPInput node connected to a Warehouse node.
  2. The input message received from the Web service client is stored in the database by the Warehouse node.
  3. The Warehouse node passes the message on to an HTTPRequest node, which interacts with the Web service.
  4. When the response is received, the HTTPRequest node propagates the response to the HTTPReply node.
  5. The HTTPReply node generates the response for the Web service client.

Example 3

The WebSphere MQ flow interacts with a Web service
You design a WebSphere MQ message flow that accesses a Web service across an HTTP connection. For example, you create a message flow that supports a process for the Human Resource department of your company. The process must retrieve employee ID numbers and enhance the message with this information. Employee IDs are maintained in the company's employee directory which is accessed through a Web service.
This represents a message flow with nodes MQInput, Compute1, HTTPRequest, Compute2, MQOutput. The HTTPRequest node interacts with the Corporate Directory Server across an HTTP connection.

In this scenario, you typically clear the Replace input message with Web service response check box in the HTTPRequest node properties, and place the response from the corporate directory server in a temporary location in the message tree specified in the Response message location in tree property in the same node. In Compute2, you code ESQL to unpack the result, and augment the final message as appropriate.

Example 4

The message flow acts as a Web service intermediary
You design a message flow that interacts with a Web service that has updated its interface on behalf of Web service clients that are not aware of the new interface. This new message flow allows older clients to access the server using the new interfaces without updating their own interfaces.
This represents a message flow with nodes HTTPInput, Compute1, HTTPRequest, Compute2, HTTPReply. The HTTPRequest node interacts with the Corporate Directory Server across an HTTP connection.

Code ESQL in Compute1 to map the client request to a server request, and in Compute2 to map the server response to the client reply. You could define these request, reply, and response messages in the MRM domain to simplify the transformation from one format to another.

You can configure the HTTPRequest node to generate HTTP headers from the headers that are received by the HTTPInput node, which allows for cookies and other application-specific headers to be passed through. The HTTPReply node can provide an equivalent task to extract headers from the response from the Web service to return to the originating client. If you want this to be done, select the appropriate Generate default HTTP headers from..... check box on both the HTTPRequest and HTTPReply nodes.

In most scenarios, the original request is of no value, and you need only the response from the service to be able to generate the client reply message. If so, select the property Replace input message with Web service response on the HTTPRequest node. If you do want to preserve any data from the input request, you can store this in the LocalEnvironment in Compute1 and retrieve it in Compute2 for inclusion in the reply.

Related concepts
Web services, WSDL and message flows
Broker implements new Web service interface
Broker implements existing Web service interface
Broker implements non-web-service interface to new Web service