About the WSRR Connectivity sample

The WSRR Connectivity sample is based on a scenario where a business wishes to use the WebSphere Service Registry and Repository to dynamically choose the WebService to be invoked at runtime. Whilst the sample demonstrates the use of the EndpointLookup node to retrieve wsdl files from the Service Registry to invoke a WebService, it should be noted that the Service Registry can also store other types of documents that can be retrieved using the RegistryLookup node. Although the two nodes are used to retrieve different types of documents from the Service Registry, the configuration of both nodes is the same and the user should gain sufficient knowledge from this sample to be able to also use the RegistryLookup node.

The following figure shows the architecture of using WSRR connectivity within a message flow.

A screen capture of WSRR connectivity architecture.

The WSRR Connectivity sample demonstrates the following tasks:


The web service is simple, DemoCustomer services accept updateCustomer requests and return updateCustomerResponse messages.  A common ESB and Registry requirement is to facilitate service invocation where two or more versions of the same service exist.  The ESB must be able to invoke the appropriate service based on the request.  The Registry must be able to accommodate multiple services such that they may be discovered and used.   In this sample, two versions of DemoCustomer WebService will exist, both implemented using message flows running in WMB. Version 1.0 is called when the static EndpointLookup node properties are used, version 2.0 is called when the input SOAP message contains runtime over-ride information.

The messages

Three input messages are supplied for running the WSRR Connectivity sample: a SOAP message that will be sent to the WebService retrieved from the Service Registry, and a message that will over-ride the static EndpointLookup node properties to retrieve a newer version of the WebService from the Service Registry, thus enabling the user to choose which version of the WebService they wish to invoke at runtime. Thirdly, an input message that does not retrieve a matching wsdl document from the Service Registry, therefore no WebService is invoked and the message is propagated to the "No Match" terminal.

The SOAP message to call the WebService determined by the static EndpointLookup node properties (ie version 1.0) as follows:

<?xml version="1.0" encoding="UTF-8"?>
<soapenv:Envelope 	xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
  <soapenv:Body>
    <Request>
      <Verb>UpdateCustomer</Verb>
      <Data>
        <Customer>ABC</Customer>
      </Data>
    </Request>
  </soapenv:Body>
</soapenv:Envelope>

The SOAP message to call the WebService determined by the runtime over-rides (ie version 2.0). The message is the same as the previous message, but with the addition of the 'Version' tag which will be used at runtime to retrieve version 2.0 of the wsdl from the Service Registry:

<?xml version="1.0" encoding="UTF-8"?>
<soapenv:Envelope 	xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
  <soapenv:Body>
    <Request>
      <Version>2.0</Version>
      <Verb>UpdateCustomer</Verb>
      <Data>
        <Customer>ABC</Customer>
      </Data>
    </Request>
  </soapenv:Body>
</soapenv:Envelope>

The SOAP message with a Version property that does not match any documents in the Service Registry.

<?xml version="1.0" encoding="UTF-8"?>
<soapenv:Envelope 	xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
  <soapenv:Body>
    <Request>
      <Version>3.0</Version>
      <Verb>UpdateCustomer</Verb>
      <Data>
        <Customer>ABC</Customer>
      </Data>
    </Request>
  </soapenv:Body>
</soapenv:Envelope>

The message flows

The following figure shows the main message flow.

A screen capture of the main message flow.

Node type Node name
MQInput WSRR_IN
MQOutput WSRR_OUT
Compute SetVersion, InformFailure, InformWSResult, InformNoMatch
EndpointLookup Endpoint Lookup One
SOAP Request SOAP Request

The following figure shows the WebService flow. Note there are two versions of this WebService flow. The subtle difference between the two is the compute node which returns a different response to show which version has been invoked.

A screen capture of the Web Service flow.

Node type Node name
SOAPInput SOAP DempCustomer
Compute Create WS Response
SOAP Reply SOAP Reply

For more information, read about the nodes in the WSSR Connectivity sample's message flows [TODO: FIX THIS LINK] in the WebSphere Message Broker documentation.

The route taken by the first (static Version) message

When you put the first message on the input queue, the message travels through the nodes as described below. If any of the queues have been disabled, the message will not be able to follow this path.

In the main message flow:

  1. WSRR.IN : The node gets the input message from the input queue.
  2. SetVersion : This compute node over-rides the "Version" property. As there is no "Version" tag in this message, nothing is replaced in the Local Environment and therefore the static "Version" property in the EndpointLookup node is used to retrieve version 1.0 of the wsdl from the Service Registry.
  3. EndpointLookupOne : This is the EndpointLookup node that connects to the Service Registry and retrieves the requested wsdl document (version 1.0 as defined in the EndpointLookup node configuration). The message is propagated to one of the three wired nodes as determined by the successful (or otherwise) retrieval of a matching wsdl document from the Service Registry. Because the EndpointLookup node is configured to retrieve only "One" matching wsdl document, there is no need to follow this node with a compute node. If the EndpointLookup node is configured to retrieve "All" matching wsdl documents, the user should follow this node with a compute node to interrogate the retrieved documents to decide which one should be sent to the SOAPRequest node (as shown in the architecture figure above).
  4. InformFailure : The message is propagated to this node if WebSphere Message Broker encounters errors either connecting to or while connected to the Service Registry.
  5. SOAPRequest : The message is propagated to this node if the EndpointLookup node could successfully retrieve the requested wsdl document from the Service Registry. The node sends the SOAP message to the Web Service determined by the endpoint in the wsdl.
  6. InformWSResult : Upon successful invocation of the Web Service, this node converts the HTTP headers in the message to MQMD headers in order to propagate the response to the MQ Output node.
  7. InformNoMatch : The message is propagated to this node if the Service Registry could not find a matching wsdl document.
  8. WSRR.OUT : The node puts the message on the WSRR.OUT output queue.

In the Web Service flow:

  1. SOAPDemoCustomerMB : The SOAP Input node receives the SOAP message from the main message flow.
  2. Compute : A response is generated.
  3. SOAP Reply : The response is sent back to the calling application - in our case, the message is sent back to the SOAPRequst node.

The route taken by the second (runtime Version) message

The route is as described above, with the differences below:

The route taken by the third (no match) message

The route is as described above, with the differences below:

The requirement in this sample is to read a message and connect to the Service Registry to retrieve a wsdl document. If a match is found, invoke the relevant Web Service, and write the message on another queue. If no match is found, write the "No match" message to the queue.

For more information, read about point to some docs here [TODO: FIX THIS LINK] in the WebSphere Message Broker documentation.

Back to sample home