WS-Reliable Messaging with WSO2 WSAS - II

This is the part two of my previous post on WS-Reliable messaging with WSO2 WSAS - 1
I'd suggest you to follow the steps given in there before proceeding with this.

We looked at how WSO2 WSAS and WSO2 Mercury module are used in one-way (IN-ONLY) message interaction in reliable manner. In this post I'll explain the procedure to do the same with Request Reply(IN-OUT) messaging system using single transport channel.

Step 1

Follow the step 1 - Service Configuration and step 2 - Generate stubs of part one of this post with the service implementation class given below.

package org.wso2.wsas.service;
public class MercuryService{

//Twoway messaging
public int Add(int a, int b){

try {
Thread.sleep(3000);
} catch (InterruptedException e) {
e.printStackTrace();
}
return a+b;
}
}

Note that I inserted a Thread.sleep() in service to wait ~3 seconds before returning results so that we may have enough time to block the transport channel when testing reliable message transmission.

Step 2

If you have followed the step 1 and step 2 exactly as given in part 1 of this post by just replacing service impl. class with the above, you should be able to continue with the client as given below.

Open your IDE and write the following client to invoke service with RM.
Make sure to add jars in WSAS_HOME/lib and the generated client stub jar to your class path in order to compile the client.

public class RequestReplyAnnonClient{

public static void main(String args[])throws AxisFault{

ConfigurationContext cc = ConfigurationContextFactory.createConfigurationContextFromFileSystem
("C:\\RM\\client-repo"+"C:\\RM\\client-repo\\conf\\axis2.xml");

MercuryServiceStub stub = new MercuryServiceStub(cc);
MercuryServiceStub.Add request = new MercuryServiceStub.Add();
request.setA(12);
request.setB(8);

stub._getServiceClient().engageModule("Mercury");

for (int i = 0; i < 29; i++) {
try {
//Two-way invocation
MercuryServiceStub.AddResponse response = stub.Add(request); System.out.println(response.get_return());
} catch (RemoteException e) {
e.printStackTrace();
} try
{
Thread.sleep(1000);
} catch (InterruptedException e) {
e.printStackTrace();
}
}
// Setting the last message stub._getServiceClient().getOptions().setProperty("MercuryLastMessage", Constants.VALUE_TRUE);
try {
MercuryServiceStub.AddResponse response = stub.Add(request); System.out.println(response.get_return());
} catch (RemoteException e) {
e.printStackTrace();
} try
{ Thread.sleep(1000);
} catch (InterruptedException e) {
e.printStackTrace();
}
}
}
In order to have the reliable messaging support at the client, we need to engage Mercury module with "stub._getServiceClient().engageModule("Mercury")". We also need to have ConfigurationContext to define the client repository where the Mercury.mar and axis2 configuration file (axis2.xml) is placed. Create a directory, client-repo and copy WSAS_HOME/repository/modules/mercury.mar to client-repo/modules directory. Also, create a sub-directory conf under client-repo and copy an axis2.xml file ( I have used axis2.xml copied from Axis2-1.4) in to that folder. As in one-way scenario, we need to let Mercury know when we are complete. The simplest way to do this is to mark the LastMessage with stub._getServiceClient().getOptions().setProperty("MercuryLastMessage", Constants.VALUE_TRUE)

Step 3

Compile and run the client. You should configure tcpmon in order to monitor request and response messages.

You will notice that the first message travels through tcpmon contains <wsrm:CreateSequence> as the first first child of soap body. If the transport channel does not get blocked, CreateSequenceResponse message will be returned to client immediately.

You will see that <wsrm:MessageNumber>1</wsrm:MessageNumber> soap header element in the next message where the actual request payload is transmitted. The response of this message may include <wsrm:SequenceAcknowledgement> which denotes the ack to the first message. This will be continued until the last message in which the <wsrm:LastMessage /> as a header element could be seen. (In our test, the message number should be 30)
The end of whole sequence will be denoted by TerminateSequance message.

Lets check whether the reliability is actually provided by WSO2 mercury module when the transport channel is interrupted.

When the 3rd message is sent (Message number 3), click on "Stop" button of Tcpmon listen port. You will see the following in tcpmon.



This mimics the behavior of typical network interruption in data communication. Wait a few seconds and restart the listen port.



As you can see, the response of request message number 3 will be returned when the transport channel is restarted and continues with the rest of the messages. No messages are lost though the channel interruptions are occurred. All 30 messages will be delivered reliably even the network communication issues are occurred during message transmission.

We have looked at one of a basic tests which can be done in order to verify how WSO2 WSAS and mercury module provides reliable message delivery in web service communication. There are more. I'll discuss them in a future post.