How to add a custom SOAP header to the request using AXIOM

Suppose you want to add the following SOAP header block to your web service request message.
<myNS:header xmlns:myNS="http://ws.org">
This is a custom soap header
</myNS:header >

There are different approaches to add user defined headers to the request soap messages. Lets see how it could be done using AXIOM in simpler way.
In this example we are going to invoke Axi2 default version service with adding a custom soap header in to the request.

Pre-requisites
Download and install Apache Axis2
Install Apache Tcpmon

Step 1

Start Axis2 server by running AXIS2_HOME/bin/axis2server.bat{sh}
Go to http://localhost:8080. You will see that the default version service is deployed there.

Step 2

Now, we need to generate client stubs. Go to AXIS2_HOME/bin and run wsdl2java.bat{sh} with the following parameters.
WSDL2Java -uri http://localhost:8080/axis2/services/Version?wsdl -o out -uw

The client stubs will be generated in a directory called "out".

Now, write a client importing the generated stub classes as follows(You can easily create a project in Eclipse using the generated Build.xml)

import java.rmi.RemoteException;
import org.apache.axiom.om.OMAbstractFactory;
import org.apache.axiom.om.OMElement;
import org.apache.axiom.om.OMFactory;
import org.apache.axiom.om.OMNamespace;
import org.apache.axis2.AxisFault;
import sample.axisversion.ExceptionException0;
import sample.axisversion.VersionStub;


public class CustomSoapHeaderClient {

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

String url = "http://localhost:8090/axis2/services/Version";
VersionStub stub = new VersionStub(url);

OMFactory omFactory =OMAbstractFactory.getOMFactory();
OMNamespace omNamespace = omFactory.createOMNamespace("http://ws.org", "myNS");
OMElement header = omFactory.createOMElement("header", omNamespace);
header.setText("This is a custom soap header");
stub._getServiceClient().addHeader(header);

try {
System.out.println(stub.getVersion());
} catch (RemoteException e) {
e.printStackTrace();
} catch (ExceptionException0 e) {
e.printStackTrace();
}
}


}

Note the highlighted code which creates the custom soap header.

Step 3

We can visualize the soap request using Tcpmon. Therefore open tcpmon and configure listen port in 8090 and target port 8080.
Compile and run the above client. You will see the following message in request pane of Tcpmon.

<?xml version='1.0' encoding='UTF-8'?>
<soapenv:Envelope xmlns:soapenv="http://www.w3.org/2003/05/soap-envelope">
<soapenv:Header>
<myNS:header xmlns:myNS="http://ws.org">This is a custom soap header</myNS:header>

How to use tcpmon inside Eclipse

Apache TCPMon is an utility that allows the messages to be viewed and resent. It is very much useful as a debug tool. If you don't know much about this tool, you can find more information here , here or here.

I found an extension of this great tool, which can be included as an Eclipse plugin so that developers can monitor message transmission within their workspace without opening a separate tcpmon instance. It is very cool indeed.

Saliya Ekanayake, a colleague at WSO2 has developed this utility as part of his university project. Lets see how this tcpmon plugin can be used in Eclipse WTP.

1. If you haven't done yet, download and install Eclipse WTP

2. Download tcpmonitor-1.0.0.jar from here

3. Copy tcpmonitor-1.0.0.jar in to Eclipse_home/plugins directory

4. Start eclipse

5. Select Window --> Show View --> Other --> Tcp Monitor --> TCP Monitor

6. Tcp monitor will be added as an view tab.



Now you can configure the necessary port settings and trace message transmission.

How to monitor messages using tcpmon in Axis2 dual channel web service invocation

Apache Axis2 client API provides the necessary methods to utilize a service using two transport channels. You can even send request through one transport (e.g:- HTTP) and get the response back via a different transport such as TCP.

setUseSeperateListener(boolean) method of org.apache.axis2.client.Options
class can be used to utilize a separate listener for your response.
If two separate HTTP transport channels are used for request and response, Axis2 starts a new HTTP listener at the client side to receive the incoming response message.

As most of web service developers know, Apache tcpmon can be used to monitor message flow between web service invocations. In one way messaging, it is quite straightforward.
You just need to configure tcpmon to listen in some port and direct the messages to the port where the web service is hosted. In client, port of the endpoint reference has to be changed to tcpmonitor listen port. That's all you have to do for monitoring messages in single channel invocation.

In this post, you can see how tcpmonitor is configured to use in dual channel invocation.

1. If you have not done it yet, download Apache tcpmon from here
Unzip the downloaded file and run build/tcpmon.bat {sh}

2. As I stated before, Axis2 starts a http listener at the client in dual channel invocation. Therefore, you need to configure Axis2.xml to redirect messages to tcpmon as follows.

Open AXIS2_HOME/conf/axis2.xml and locate to the following section.

<!-- ============================================ -->
<!-- Transport Ins -->
<!-- ============================================ -->
<transportReceiver name="http"
class="org.apache.axis2.transport.http.SimpleHTTPServer">
<parameter name="port">8080</parameter>
<!-- Here is the complete list of supported parameters (see example settings further below):
port: the port to listen on (default 6060)
hostname: if non-null, url prefix used in reply-to endpoint references (default null)
------------
-->
<parameter name="hostname">http://localhost:8090</parameter>
<!-- <parameter name="originServer">My-Server/1.1</parameter> -->
----------
</transportReceiver>

3. Note the highlighted elements in the above axis2.xml configuration. First you have to uncomment the hostname paramter <parameter name="hostname"> and specify a port which is not already listened in your system (e.g:- 8090).

In tcpmon, create a new listener with 8090 as the listen port and 8080 as the target port. With this configuration, the response messages receive to the reply-to endpoint reference are directed to 8090 tcpmon port and then those will be targeted to client HTTP listener port, 8080.



Now, you should be able to monitor the response flow in dual channel invocation.