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.
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.
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 following figure shows 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.
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.
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.
The route is as described above, with the differences below:
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.