Asynchronous web service using WS-Addressing in webMethods

WS-Addressing in short

· a W3C standard for embedding addressing information in the SOAP message = less dependence on the transport protocol.
· Message identification via MessageID.
· Request-response matching via RelatesTo (very important for asynchronous scenarios; the synchronous case does not require this because it is tied to a single HTTP connection).
· Support for more complex message flows via ReplyTo and FaultTo.

To process responses asynchronously using WS-Addressing

· Ensure that the WS-Addressing policy you want to use is attached to the web service descriptor.
· While invoking the corresponding web service connector service, specify this response endpoint address as the value for ReplyTo and/or FaultTo address.

Example project

Create a new flow service named debugLog in designer. This service is to divide input1 by input2 and return the value as output. Below is the service input/output signature.

Create another flow service named debugLogResponse in designer. This service uses the output signature of debugLog as its input signature. We need this service to help creating mock service in SOAPUI.

Create another 2 flow services debugLogAdd and debugLogAddResponse similar to we have created above. The debugLogAdd service is to add input1 by input2 and return the value as output.

Now we should have 4 flow services in designer. Add them all into WS provider descriptor and then add Addressing as policy.

Import the WSDL that contains 4 operations in SOAPUI.

Create mock services which handle the web service response from webMethods asynchronously.

Enable WS-A configuration for debugLog web service in SOAPUI. Make sure you have ticked the checkbox of “Enable WS-A addressing” and “Generate MessageID”. The response is 2 which worked out as 4/2.

Receive response asynchronously. Use “Reply to” field in WS-addressing header to redirect the response to a call back endpoint. The client sends the request with an indication (ReplyTo header) that he wants the response to a third actor – the callback endpoint (mock service in this example). The server replies immediately with an HTTP 202 status which informs the client that the request has arrived and its processing has started. When the task is finished the server sends a request to the callback endpoint (listening at ReplyTo address). This is the response that the client expects. The response will be correlated with the corresponding request using the RelatesTo header.

Set reply to as http://localhost:8080/ which mock service is running on that port.

Check the response received by mock service.

We can also send back the SOAP Fault asynchronously by using Fault to field in WS-Address header. To capture SOAP Fault in mock service, you need to choose an operation to handle any incoming SOAP Fault. I choose debugLogResponse in my example.

Now we can change input 2 as zero to force an exception in flow service then a SOAP fault will be return as response.

Check mock service to find the SOAP Fault returned.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s