Amila's Blogs

Java Security Model

2010-04-16T23:53:00.000-07:00

An OS process runs under the privileges of the user who fork the process. Therefore under normal conditions a java applications also runs under the privileges of the user who starts it. But there are situations where some privileges of the person who starts it should not be granted to the java application and only set of java code should give the privilege access.
Java security model provides a solution for this problem. It let users to specify a set of granted permissions and act as a additional security layer between java application and OS allowing only granted permissions.
To understand the concepts lets use the following sample program which creates the file test/test.txt.
public class CreateFile {
public void createFile(){
File file = new File("test/test.txt");
try {
System.out.println("Creating file ==> " + file.getAbsolutePath());
file.createNewFile();
} catch (IOException e) {
e.printStackTrace();
}
}
public static void main(String[] args) {
new CreateFile().createFile();
}
}
Now lets run the program with the following command as a normal user
java -classpath classes/ com.test.security.CreateFile

This would create the file without any problem in the test directory. Here we ran this program without the security manager. Now lets try to run this program as super user but with the security manager.

java -Djava.security.manager -classpath classes/ com.test.security.CreateFile
Exception in thread "main" java.security.AccessControlException: access denied (java.util.PropertyPermission user.dir read)
at java.security.AccessControlContext.checkPermission(AccessControlContext.java:264)
at java.security.AccessController.checkPermission(AccessController.java:427)
at java.lang.SecurityManager.checkPermission(SecurityManager.java:532)
at java.lang.SecurityManager.checkPropertyAccess(SecurityManager.java:1285)
at java.lang.System.getProperty(System.java:628)
at java.io.UnixFileSystem.resolve(UnixFileSystem.java:118)
at java.io.File.getAbsolutePath(File.java:473)
at com.test.security.CreateFile.createFile(CreateFile.java:27)
at com.test.security.CreateFile.main(CreateFile.java:35)

So Even this simple operation runs as the super user it is not allowed to create the file. When a program runs under the security manager it only exposes the security permissions allowed in the security policy files. This is similar to Linux Capabilities. In this way only the required security permission can be given even the program has to started as super users.
Now lets give the necessary permissions to run this program.
First lets create the policy file as follows
grant {
permission java.util.PropertyPermission "user.dir", "read";
permission java.io.FilePermission "test/test.txt", "write";
};

And now run this program as follows,
java -Djava.security.manager -Djava.security.policy=policy/sample.policy -classpath classes/ com.test.security.CreateFile

Here the -Djava.security.policy is used to specify the policy file location. Now again file is created successfully.

To understand what happens exactly lets implements our own security permission. Here we write a watch tv permission.
public class TVPermission extends BasicPermission {
public TVPermission(String name) {
super(name);
}
public TVPermission(String name, String actions) {
super(name, actions);
}
public boolean implies(Permission p) {
boolean isPermitted = false;
if (p instanceof TVPermission){
isPermitted = p.getName().equals(getName())
&& p.getActions().equals(getActions());
}
return isPermitted;
}
}

Any java permission should implements the java.security.Permission interface. Implies is the important method. Actually when someone requests a permission normally java creates a permission object for that object and check for the permission. Lets use this code to check this.

public class WatchTV {
public void watchTV() {
TVPermission tvPermission = new TVPermission("chanel-5", "watch");
AccessController.checkPermission(tvPermission);
// other code goes here
}
public static void main(String[] args) {
new WatchTV().watchTV();
}
}

Now run this program with the following command
It gives this exception
Exception in thread "main" java.security.AccessControlException: access denied (com.test.permission.TVPermission chanel-5)
at java.security.AccessControlContext.checkPermission(AccessControlContext.java:264)
at java.security.AccessController.checkPermission(AccessController.java:427)
at com.test.security.WatchTV.watchTV(WatchTV.java:27)
at com.test.security.WatchTV.main(WatchTV.java:32)

Now lets add this permission to the policy file as follows and run with the policy file.
grant {
permission java.util.PropertyPermission "user.dir", "read";
permission java.io.FilePermission "test/test.txt", "write";
permission com.test.permission.TVPermission "chanel-5", "watch";
};

java -Djava.security.manager -Djava.security.policy=policy/sample.policy -classpath classes/ com.test.security.WatchTV

Now it executes correctly. Now we can understand how java runtime manage permissions under a security manager.
Lets see how actually jdk 1.5 implements the createNewFile method.

public boolean createNewFile() throws IOException {
SecurityManager security = System.getSecurityManager();
if (security != null) security.checkWrite(path);
return fs.createFileExclusively(path);
}

First it gets the Security manager and if it is not null (i.e when running under security manager) check for the write permission. This checkWrite method is like this,
public void checkWrite(String file) {
checkPermission(new FilePermission(file,
SecurityConstants.FILE_WRITE_ACTION));
}
public void checkPermission(Permission perm) {
java.security.AccessController.checkPermission(perm);
}

This finally calls the AccessController as in earlier sample.

Axis2 temp files

2010-03-09T03:31:00.001-08:00

Axis2 supports archive based deployment for both services (.aar) and modules (.mar). These files can internally have 'lib' folders to contain the third party libraries of those services.
From Axis2 1.5, when Axis2 creates Configuration Context object which happens when the server starts up or service client invocation, it creates a separate folder under the temp folder to store the temp files. This temp folder is taken from the "java.io.tmpdir" system property.
For an example if Axis2 1.5 is deployed under tomcat 6.0.24, it creates the following two files under $CATALINA_TMPDIR.
axis2-tmp-2165190954418103759.tmp
axis2-tmp-2165190954418103759.tmp.lck

Axis2 creates .lck files as a temp file which deletes on a jvm exits.

File lockFile = new File(tmpDirName, tmpDir.getName() + ".lck");
lockFile.createNewFile();
lockFile.deleteOnExit();

Therefore when the tomcat goes down this .lck file should also be deleted. But the .tmp folder remains. At the next start up time Axis2 searches for .tmp file folders which does not have a corresponding .lck files and deletes them. So there can not be any grow of temp files.

One important thing to remember is that Axis2 copies the repository files (.aar and .mar) when ever it creates a configuration context object. Therefore the tmp folder can be grown while in the server running. Obviously this can be stopped by using one configuration context object for all the service invocations.

But there are some instances where .lck file is not properly deleted when the jvm exits. For those situations the temp folder can be deleted within the server starts up shell script. For tomcat this can be done adding code to catalina.sh.

Queued Transaction processing with WS-RM

2010-03-08T03:22:00.000-08:00

Couple of years ago I started writing a new WS-RM implementation called Mercury which uses an state machine model to handle the reliability. It was working well for the requirements we had at that time and we have done two releases under the name WSO2 Mercury. But however WSO2 Mercury could not support the user initiated transactions due to a limitation of its storage design. Then that project didn't last too long and WSO2 moved to use Apache Sandesha as its WS-RM implementation for newly developed carbon based products.
At that time I was doing my Msc at University of Moratuwa. For my Msc I was looking for an idea and Dr Sanjiva Weerawarana and Mr Paul Fremantle gave me the idea of re engineering the WSO2 mercury code to support transactions by introducing a new transaction based storage API. Then I started researching different types of reliable message delivery models and finally was able to developed a WS-RM protocol which provides application to application reliability using distributed transactions. This model follows a similar pattern as the well known Queued Transaction processing and hence the thesis tile.

Here is the abstract of my Msc Thesis
With the popularity of the distributed business applications, the application data is distributed in various physical storages. However most of the business transactions require to update data stored in more than one storage. Hence updating two data storages reliably is a common problem for most of the distributed business applications.

Queued transaction processing is a concept widely used to achieve such a processing model using intermediate queues to transfer messages reliably. In such a system at the client side, both updating the client storage and writing the message to be sent to the client side message queue happens in the same distributed transaction. Similarly at the server side reading the message from the server side queue and updating the sever storage happens in the same distributed transaction. But such a system may have interoperability problems if client and server use different types of technologies.

Web services are used to communicate among the heterogeneous systems by passing SOAP messages using standard transport mechanisms like http. Web services can reliably communicate by using WS-Reliable messaging specification(WS-RM). WS-RM uses concepts of Reliable messaging source (RMS) and Reliable messaging destination (RMD) between which it guarantees reliable message delivery.

By combining these two concepts, we introduce an approach to solve the above mentioned problem in an interoperable manner using WS-RM to communicate between nodes while keeping RMS and RMD as intermediate storages. In our model reliable message delivery happens in three phases. First both updating application client storage and writing message to the RMS happens in the same distributed transaction. Then WS-RM protocol reliably transfers the message to RMD at the server side. Finally at the server reading the message from the RMD and updating the server storage happens in the same distributed transaction. The middleware software entity that we developed to encapsulate this approach is called Mercury which implements WS-RM protocol.

Msc Thesis report
CD copy which provides the source code, binaries and demos

WSO2 WSAS 3.1.3 released

2010-02-07T23:01:00.000-08:00

WSO2 WSAS is an Enterprise ready web service container based on Apache Axis2 and related other libraries such as Rampart, Sandesha2, Transports etc... Then what is the advantage of using WSO2 WSAS rather than using those apache libraries directly?

WSO2 WSAS comes with an integrated and tested set of all those libraries so that users do not have to find the compatible libraries and integrate them.

WSO2 WSAS Admin console provides the extensive monitoring, management features.
The try it can be used to test a web service quickly without generating the stubs. Users can change the log levels through the admin console and can enable request/response message logging in order to check the messages comes in and out.
Admin Console can be used to update servers while they are running. I.e users can add parameters, engage modules (there are even sample scenarios to engage Security), apply polices, add transports, add services etc .. WSO2 WSAS persists all these changes to its registry so that it is available even if some one restart the server. This is very useful for services that do not uses a services.xml like jaxws servers.
There are some graphical tools called wsdl2java, java2wsdl, WSDL Converter, Try it, Service Validator and Module Validator.

WSO2 WSAS 3.1.3 can be downloaded here.

Improving Axis2 http transport client

2010-01-17T01:08:00.000-08:00

Until Axis2 1.5 a separate http client instance was created per request by default. This leads to an connection timeout problem with the high loads. See here for more details.

In order to solve this issue Axis2 1.5.1 uses one http client object cached in configuration context for all requests. Since by default MultiThreadedHttpConnectionManager allows two request per host this causes an issue if tried to invoke a service more than twice.

Following options can be taken to solve this issue.
1.set HTTPConstants.AUTO_RELEASE_CONNECTION to true
serviceClient.getOptions().setProperty(HTTPConstants.AUTO_RELEASE_CONNECTION, Constants.VALUE_TRUE);
this would build the response stream once the response stream returned and release the connection. But this may have a performance hit since it build the OM tree at transport level.
2.Clean up the transport after each call
serviceClient.cleanupTransport();

However both the above methods can only invoke two requests at time since there is only two connections. Again this may cause problems with invoking slow services. This can be avoided by the following technique to increase the default number of connections.

ConfigurationContext configurationContext =
                    ConfigurationContextFactory.createConfigurationContextFromFileSystem(
                            AXIS2_REPOSITORY_LOCATION, AXIS2_CLIENT_CONFIG_FILE);

            MultiThreadedHttpConnectionManager multiThreadedHttpConnectionManager = new MultiThreadedHttpConnectionManager();

            HttpConnectionManagerParams params = new HttpConnectionManagerParams();
            params.setDefaultMaxConnectionsPerHost(20);
            multiThreadedHttpConnectionManager.setParams(params);
            HttpClient httpClient = new HttpClient(multiThreadedHttpConnectionManager);
            configurationContext.setProperty(HTTPConstants.CACHED_HTTP_CLIENT, httpClient);

and call serviceClient.cleanupTransport(); after each service invocation.

Changing Axis2 application path

2010-01-15T23:10:00.000-08:00

By default Axis2 generates an context path as follows when deployed it in tomcat or other application server.

http://localhost:8080/axis2/services/Version?wsdl

but most of the it is requried to customize this as follows.

http://localhost:8080/myApp/myServices/Version?wsdl

Below steps can be used to achive this.
1. Rename the web app name axis2 to myApp
2. Uncomment and edit the servicePath parameter at the axis2.xml file
myServices
3. Add the following entry to web.xml. Here we need to add this entry rather than chaing existing one since services part is hard coded in some places.

<servlet-mapping>
<servlet-name>AxisServlet</servlet-name>
<url-pattern>/myServices/*</url-pattern>
</servlet-mapping>

How to get a path like this?

http://localhost:8080/myServices/Version?wsdl

This can be done my making this application as ROOT app
1. change the myApp to ROOT

WSO2 Data Services v2.2.0 released

2010-01-07T03:37:00.000-08:00

Axis2 lets users to develop web services from the java code. This can either be a POJO where users write the business logic first or a generated code with the WSDL. In whatever form real business logic retrieve data from the data store (most of the time a database) and update it.

Therefore isn't it useful to publish the data stored in permanent storage straight away (I.e using some descriptor files) without doing any coding? WSO2 Data services server let users to publish data by just writing a descriptor file. Currently it can publish data stored in many forms. eg. Databases, text files, excel sheets, google docs etc..
Since WSO2 Data services server build on top of WSO2 carbon platform it inherit all the WS* features such as security, reliable messaging, addressing etc ..

Following are some of the key features:

- Multiple data source support - any relational database accessible via JDBC, CSV, Excel, JNDI bound data sources and Google Spreadsheets
- Web service and REST interfaces for data
- Customizable response format to match your next adaptor's input
- Support for large data sets with little to no impact to the server's memory usage
- Nested queries and federated response from multiple disparate data sources
- Role based content filtering
- Full support for WS-Security, WS-Trust, WS-Policy, WS-SecureConversation and XKMS
- Web based GUI wizard
- Multi transport support - send and receive your data in either HTTP(s), SMTP, JMS and XMPP
- Reliable delivery of data
- Access throttling based on IP/Domain or frequency

WSO2 Data Services 2.2.0 can be downloaded from http://wso2.org/downloads/data-services-server.

Axis2 Authentication

2010-01-01T07:44:00.000-08:00

The servlet specification provides four authentication mechanisms for any web application. Therefore any web services engine which receives http requests through a servlet can use those authentication mechanisms. Here is how you can do BASIC and DIGEST authentication with Apache Axis2 deployed under tomcat.

Axis2 war distribution is a standard web application. This war distribution contains a web.xml and within it there is a servlet called AxisServlet which is used to receive the http requests.

Configuring the war distribution.
First the following should add to the web.xml file to protect the AxisServlet from the anonymous access.

<login-config>

<auth-method>DIGEST</auth-method>
<realm-name>default</realm-name>
</login-config>

<security-constraint>
<web-resource-collection>
<web-resource-name>Protected Resource</web-resource-name>
<url-pattern>/services/*</url-pattern>
</web-resource-collection>

<auth-constraint>
<role-name>tomcat</role-name>
</auth-constraint>
</security-constraint>

then add the following to the tomcat-users.xml

Now the servlet is protected and Lets see how to provide the credentials when accessing the service. This is in fact done by using the functionality available with the commons http client.

ServiceClient serviceClient = new ServiceClient();
serviceClient.setTargetEPR(new EndpointReference("http://localhost:8080/axis2/services/Version/getVersion"));
serviceClient.getOptions().setAction("urn:getVersion");

HttpTransportProperties.Authenticator authenticator = new HttpTransportProperties.Authenticator();
authenticator.setUsername("tomcat");
authenticator.setPassword("tomcat");

serviceClient.getOptions().setProperty(HTTPConstants.AUTHENTICATE, authenticator);
serviceClient.sendReceive(null);

This request can be send through a tcpmon to understand how this authentication works. First Axis2 client sends a normal request and tomcat server returns an Unauthorized response with the required authentication method.

HTTP/1.1 401 Unauthorized

Server: Apache-Coyote/1.1

WWW-Authenticate: Digest realm="default", qop="auth", nonce="6da725c4d901eee87d2ad49cadbac74a", opaque="37629e27fec9bfaf38063bc3ab65f12d"

After receiving this Axis2 client sends another request with the authentication details.

Minimal jars required for Axis2 1.5

2009-11-30T01:08:00.000-08:00

Minimal jars required for Axis2 1.5 is slightly different from Axis2 1.4.1.

Here is a set of jars required with Axis2 1.5 to invoke a service written using Axiom and
to invoke it using direct service client using default axis2.xml file.

axis2-kernel-1.5.jar
axiom-api-1.2.8.jar
axiom-dom-1.2.8.jar
axiom-impl-1.2.8.jar
commons-logging-1.1.1.jar
wsdl4j-1.6.2.jar
XmlSchema-1.4.3.jar
neethi-2.0.4.jar
axis2-transport-local-1.5.jar
axis2-transport-http-1.5.jar
commons-httpclient-3.1.jar
mail-1.4.jar
commons-fileupload-1.2.jar
woden-api-1.0M8.jar
woden-impl-dom-1.0M8.jar
httpcore-4.0.jar
commons-codec-1.3.jar
geronimo-stax-api_1.0_spec-1.0.1.jar
wstx-asl-3.2.4.jar

axis2-jaxws-1.5.jar may be used to avoid some waning messages with the default axis2.xml.

Axis2 Class loading

2009-10-05T06:30:00.001-07:00

Axis2 let users to deploy services and modules as separate archive files. These files can contain normal java classes or .jar files. Therefore at the deployment time Axis2 has to read those java classes and .jar files and create class loaders for services and modules. These are the places it looks for load those classes.
When axis2 deployed as web application using the axis2 war distribution, Axis2 uses the web application class loader (this contains WEB-INF/classes and WEB-INF/lib jars) as the top most parent.

For service deployment it creates a service class loader using jars under the services/lib (this folder has to create by the users if needed) folder and using web application class loader as the parent. Then for each service it creates a separate class loader (which contains archive class files and lib jar files) using the service class loader as the parent.

Similar thing happens for modules. The module class loader can uses the modules/lib folder to load the jar files and it use as the parent class loader for other modules. This forms the following parent child relationship for class loaders.

Web class loader
services class loader modules class loader
other service class loaders other service class loaders

Child First (parent last) class loading
By default Axis2 uses the parent first class loading. Child first class loading can be switch by setting EnableChildFirstClassLoading parameter.
<parameter name="EnableChildFirstClassLoading">true</parameter>

Thread Context class loading
Some libraries uses the Thread context class loading. By default axis2 sets the service class loader as the thread context class loader before invoking a service. This can be changed by setting the context class loader to composite.

I.e adding this parameter to service
<parameter name="ServiceTCCL">composite</parameter>

when this parameter is set it creates the context class loader by using both existing thread context class loader and service class loader.

Axis2 Hierarchical Service Deployment

2009-10-01T08:12:00.000-07:00

Axis2 has a concept of a service archive (.aar). After introducing the custom deployers even users can deploy different types of files as services. (eg. .class and .jar for jaxws services).
But until recently all those service files had to kept in the services folder or respective other service folders. This may not efficient in managing a lot of services. With the introduction of hierarchical service deployment it is possible to keep the directory structure under the services folder and the folder structure is reflect in the service epr as well.

eg. one can have services like this.

./services/interop/rm/EchoStringService.aar

./services/interop/rm/PingService.aar
./services/version/v1.1/version.aar

./services/version/v1.2/version.aar

Epr for the PingService is
http://localhost:8080/axis2/services/interop/rm/PingService

As seen in the last two lines this feature can be used for version management as well. Different version of the same service can be deployed and Epr is generated accordingly.

http://localhost:8080/axis2/services/version/v1.2/Version

Inter operating Apache Sandesah2 with WCF

2009-09-30T07:57:00.001-07:00

Recently I have been working on interoperating WCF with the Apache Sandesha2. The good news is all the plain RM scenarios pass with some small fixings. Here is an sample client which can be used to invoke the wcf services available at http://131.107.72.15/endpoints/

First I generated the code for the given wsdl with wsdl2java tool with the following arguments

-uri http://10.100.1.238/ReliableMessaging_Service_WSAddressingAugust2004_Indigo/RequestReply.svc?wsdl
-u -ap -uw

-p org.wso2.carbon.interop.microsoft.rm.requestreply

-o target/generated-code

-Emp org.wso2.carbon.interop.microsoft.rm.requestreply

-ns2p http://tempuri.org/=org.wso2.carbon.interop.microsoft.rm.requestreply,http://schemas.microsoft.com/2003/10/Serialization/=org.wso2.carbon.interop.microsoft.rm.requestreply.types

Then we can simple invoke the service using the following client code.

// creating an configuration context which contains sandesah2 and addressing
ConfigurationContext configurationContext = ConfigurationContextFactory.createConfigurationContextFromFileSystem("target" + File.separator +
"org.wso2.carbon.interop.microsoft.rm-SNAPSHOT.dir" +
File.separator + "repository");

EchoStringServiceCustomBinding_IEchoString9Stub stub = new EchoStringServiceCustomBinding_IEchoString9Stub(configurationContext,
"http://131.107.72.15/ReliableMessaging_Service_WSAddressingAugust2004_Indigo/RequestReply.svc/Reliable_Anonymous_Soap11_WSAddressingAugust2004_RM11");
// this is to send messages through tcp mon
stub._getServiceClient().getOptions().setProperty(Constants.Configuration.TRANSPORT_URL,
"http://localhost:8088/ReliableMessaging_Service_WSAddressingAugust2004_Indigo/RequestReply.svc/Reliable_Anonymous_Soap11_WSAddressingAugust2004_RM11");

// setting the correct addressing , soap and rm versions
stub._getServiceClient().getOptions().setProperty(AddressingConstants.WS_ADDRESSING_VERSION, AddressingConstants.Submission.WSA_NAMESPACE);
stub._getServiceClient().getOptions().setSoapVersionURI(SOAP11Constants.SOAP_ENVELOPE_NAMESPACE_URI);
stub._getServiceClient().getOptions().setProperty(SandeshaClientConstants.RM_SPEC_VERSION, Sandesha2Constants.SPEC_VERSIONS.v1_1);

//wcf does not support make connections so disable it
Parameter sandeshaPolicyBeanParam = stub._getServiceClient().getAxisConfiguration().getParameter(Sandesha2Constants.SANDESHA_PROPERTY_BEAN);
if (sandeshaPolicyBeanParam != null) {
SandeshaPolicyBean sandeshaPolicyBean = (SandeshaPolicyBean) sandeshaPolicyBeanParam.getValue();
sandeshaPolicyBean.setEnableMakeConnection(false);
}

stub._getServiceClient().engageModule("addressing");
stub._getServiceClient().engageModule("sandesha2");

PingRequestBodyType pingRequestBodyType = new PingRequestBodyType();
pingRequestBodyType.setSequence("Sequence 1");
pingRequestBodyType.setText("testparam");
PingResponseBodyType pingResponseBodyType = null;
String responseString = "";
for (int i = 0; i < 3; i++) {
responseString += "testparam";
pingResponseBodyType = stub.echoString(pingRequestBodyType);
}

// after sending the messages we can close and terminate the sequence
SandeshaClient.closeSequence(stub._getServiceClient());
SandeshaClient.terminateSequence(stub._getServiceClient());

//wait until terminate sequence messge is send
SandeshaClient.waitUntilSequenceCompleted(stub._getServiceClient());

Handling date and dateTime with Axis2

2009-09-27T22:40:00.000-07:00

With Axis2 1.5 java.util.Date is mapped to xs:date type and java.util.Calendar is mapped to xs:dateTime. For an example if we deployed a POJO service as follows

public class TestService {

public Date getDate() {
return new Date();
}

public Calendar getCalendar() {
return Calendar.getInstance();
}
}

This generates an WSDL with schema like this.

<xs:element name="getDateResponse">
<xs:complexType>
<xs:sequence>
<xs:element minOccurs="0" name="return" nillable="true" type="xs:date"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="getCalendarResponse">
<xs:complexType>
<xs:sequence>
<xs:element minOccurs="0" name="return" nillable="true" type="xs:dateTime"/>
</xs:sequence>
</xs:complexType>
</xs:element>
When invoking the service we get the following response xmls

<ns:getDateResponse xmlns:ns="http://service.lockhead.test"><ns:return>2009-09-28</ns:return></ns:getDateResponse>
<ns:getCalendarResponse xmlns:ns="http://service.lockhead.test"><ns:return>2009-09-28T10:55:01.770+05:30</ns:return></ns:getCalendarResponse>

Sending an arbitrary soap message with Axis2

2009-09-24T21:55:00.000-07:00

Axis2 code generation strictly follows the WS-I profile which prohibits sending soap messages with two child elements in the soap body. Even normal Service client API allows only one omElement to be send at the soap body.
One work around to send two elements is to use an operation client which allows a user to set whole SoapEnvelope hence sending any arbitrary one.

ServiceClient serviceClient = new ServiceClient();
OperationClient opClient = serviceClient.createClient(ServiceClient.ANON_OUT_IN_OP);
//creating message context
MessageContext outMsgCtx = new MessageContext();
Options opts = outMsgCtx.getOptions();
//setting properties into option
opts.setTo(new EndpointReference("http://localhost:8088/axis2/services/TestInOutService"));
opts.setAction("urn:TestInOutService");

SOAPFactory soapFactory = OMAbstractFactory.getSOAP11Factory();
SOAPEnvelope soapEnvelope = soapFactory.getDefaultEnvelope();

OMElement omElement1 = soapFactory.createOMElement(new QName("http://axis2.test","firstElement"));
OMElement omElement2 = soapFactory.createOMElement(new QName("http://axis2.test","secondElement"));

soapEnvelope.getBody().addChild(omElement1);
soapEnvelope.getBody().addChild(omElement2);

outMsgCtx.setEnvelope(soapEnvelope);
opClient.addMessageContext(outMsgCtx);
opClient.execute(true);

MessageContext inMsgtCtx = opClient.getMessageContext("In");

SOAPEnvelope response = inMsgtCtx.getEnvelope();
System.out.println(response);

Axis2 child first class loading

2009-05-20T04:22:00.000-07:00

With axis2 it is possible to deploy services as service archive files and modules as module archive files. Both these two types of archives can contain .class or .jar files within it. Axis2 creates a separate class loader to load these class and jar files within the archive file.
By default Axis2 uses parent first class loading. This means jvm search for a particular class in parent before search it at the current class loader. As a result of this user could not use a different version of a jar file within their archives.
I recently added the child first class loading support (this is only available with main trunk) so that users can use different versions of class files at their services.

How to enable it?
This can be globally enable by setting the 'EnableChildFirstClassLoading' parameter to true at the axis2.xml file. Further the behavior of the services or modules can be set adding the same parameter to services.xml and module.xml.

How it works?
Axis2 uses a custom class loader called DeploymentClassLoader which is extended from the java URLClassloader. URLClassloader uses a parent first approach. LoadClass method of the java classloader class looks like this,

protected synchronized Class loadClass(String name, boolean resolve)
throws ClassNotFoundException
{
// First, check if the class has already been loaded
Class c = findLoadedClass(name);
if (c == null) {
try {
if (parent != null) {
c = parent.loadClass(name, false);
} else {
c = findBootstrapClass0(name);
}
} catch (ClassNotFoundException e) {
// If still not found, then invoke findClass in order
// to find the class.
c = findClass(name);
}
}
if (resolve) {
resolveClass(c);
}
return c;
}

it first checks the parent class loader to check the class and child class loader after that. We can revise this order simply overriding this method at the DeploymentClassLoader like this,
protected synchronized Class loadClass(String name, boolean resolve) throws ClassNotFoundException {
Class c = null;
if (!isChildFirstClassLoading) {
c = super.loadClass(name, resolve);
} else {
c = findLoadedClass(name);
if (c == null) {
try {
c = findClass(name);
} catch (Exception e) {
c = super.loadClass(name, resolve);
}
}
}
return c;
}

Here the isChildFirstClassLoading is set according to the parameters uses set above.

Improving Axis2 client http transport performance

2009-05-07T01:18:00.000-07:00

Although Axis2 supports a many transports http is the highly used one. Axis2 uses Apache HttpClient to implement its http transports sender. By default Axis2 creates a new http client object per invocation. This causes a new MultiThreadedHttpConnectionManager object being created for each invocation. As a result axis2 by default does not use the http 1.1 keep alive feature as well.
The solution for this problem is to re use the same HttpClient and MultiThreadedHttpConnectionManager per one thread. Axis2 client invocation may happen using one thread or using multiple threads. After reusing the MultiThreadedHttpConnectionManager has to shut down to release connections. If not this can lead to multiple tcp CLOSE_WAIT connections situation.

Following code shows this settings.

// creates a new connection manager and a http client object
MultiThreadedHttpConnectionManager httpConnectionManager = new MultiThreadedHttpConnectionManager();
HttpClient httpClient = new HttpClient(httpConnectionManager);

try {

client = new ServiceClient(null, null);
Options opts = new Options();
client.setOptions(opts);
opts.setTo(new EndpointReference("http://localhost:8085/axis2/services/TestInOutService"));
opts.setAction("urn:TestInOutService");

OMElement payload = buildSoapObject(
"" +
"IBM" +
""
);
System.out.println("Sending the request ...." + System.currentTimeMillis());

// set the above created objects to re use.
client.getOptions().setProperty(HTTPConstants.REUSE_HTTP_CLIENT, Constants.VALUE_TRUE);
client.getOptions().setProperty(HTTPConstants.CACHED_HTTP_CLIENT, httpClient);

// since we reuse the same http client and conneciton manager all these http messages
// will go in one tcp connection.
// this can be verified by sending the messages through tcpmon.
for (int i = 0; i < 10; i++) {
OMElement response = client.sendReceive(payload);
response.build();
}

} catch (Exception e) {
e.printStackTrace();
}
finally {
if (client != null) {
try {
client.cleanupTransport();
} catch (Exception e) {
e.printStackTrace();
}

try {
client.cleanup();
} catch (Exception e) {
e.printStackTrace();
}
}

}
try {
Thread.sleep(1000);
} catch (Exception e) {// do nothing}
}
httpConnectionManager.closeIdleConnections(0);
httpConnectionManager.shutdown();

Accessing WSO2 products back end directly

2009-02-16T20:32:00.000-08:00

Recently wso2 release a set of products which address all aspects of any SOA solution. All these products are build upon a platform called WSO2 carbon which is base on OSGI. One of the common features of them is to ability to run as Front End (FE) and Back End (BE) services. FE server contains all the GUI components and BE server expose the back end functionality as web services. Therefore in a typical Adminconsole usage scenario client application runs on the browser makes servlet request to FE server and FE server makes a web service call to BE server.
As it can be seen it is possible to access these BE serer web services directly using web service clients generated using the respective WSDL files for the service. The following example code provides a code for such a client which try to directly access the WS02 registry back end services to put a resource and retrieve it back. Generally this code segment show how one can access a service using https transport and mange cookies between many stubs.

try {

// set the system properties to enable the https conection
System.setProperty("javax.net.ssl.trustStore", "src/test/resources/wso2carbon.jks");
System.setProperty("javax.net.ssl.trustStorePassword", "wso2carbon");

// first authenticate the client.
AuthenticationAdminServiceStub authenticationStub =
new AuthenticationAdminServiceStub("https://10.100.1.104:9443/services/AuthenticationAdminService");
authenticationStub._getServiceClient().getOptions().setManageSession(true);
boolean loggedIn = authenticationStub.login("admin", "admin", NetworkUtils.getLocalHostname());

// get the cooke to use in the next service invoations. This lets registry service to authenticate
// the second request
ServiceContext serviceContext = authenticationStub._getServiceClient().getLastOperationContext().getServiceContext();
String sessionCookie = (String) serviceContext.getProperty(HTTPConstants.COOKIE_STRING);
// print the cookie
System.out.println("session Cookie " + sessionCookie);

// doing the registry update
ResourceAdminServiceStub stub = new ResourceAdminServiceStub("https://10.100.1.104:9443/services/ResourceAdminService");
stub._getServiceClient().getOptions().setManageSession(true);
stub._getServiceClient().getOptions().setTimeOutInMilliSeconds(60000000);
// create a path to add new resource
String path = "/testfolder/axis2.zip";
String mediaType = "application/xml";
String description = "test service";
// enable MTOM and set the previous cookie
stub._getServiceClient().getOptions().setProperty(Constants.Configuration.ENABLE_MTOM, Constants.VALUE_TRUE);
stub._getServiceClient().getOptions().setProperty(HTTPConstants.COOKIE_STRING, sessionCookie);
DataHandler dataHandler = new DataHandler(new FileDataSource("/home/amila/services.xml"));
// adding the resource
stub.addResource(path, mediaType, description, dataHandler);

// getting content
ContentDownloadBean contentDownloadBean = stub.getContentDownloadBean("/testfolder/testxml3");
DataHandler response = contentDownloadBean.getContent();
FileOutputStream fileOutputStream = new FileOutputStream("/home/amila/new_services2.xml");
response.writeTo(fileOutputStream);
fileOutputStream.flush();
} catch (AxisFault axisFault) {
axisFault.printStackTrace();
} catch (java.rmi.RemoteException e) {
e.printStackTrace();
} catch (org.wso2.carbon.registry.mgt.ui.resource.services.ExceptionException0 exceptionException0) {
exceptionException0.printStackTrace();
} catch (org.wso2.carbon.core.services.authentication.AuthenticationExceptionException0 authenticationExceptionException0) {
authenticationExceptionException0.printStackTrace();
} catch (SocketException e) {
e.printStackTrace();
} catch (FileNotFoundException e) {
e.printStackTrace();
} catch (IOException e) {
e.printStackTrace();
}

Using MTOM with Axis2

2009-01-03T18:48:00.000-08:00

MTOM provides a way to send binary data as it is without encoding it to a text format. Axis2 ADB has built in support for MTOM. Therefore it is almost a trivial task to send and receive binary data using axis2.

Here is an sample wsdl

<definitions xmlns:tns="http//tempuri.org/sample"
xmlns:ns1="http//tempuri.org/sample/types"
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
xmlns:soap12="http://schemas.xmlsoap.org/wsdl/soap12/"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns="http://schemas.xmlsoap.org/wsdl/"
targetNamespace="http//tempuri.org/sample">
<types>
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:tns="http//tempuri.org/sample/types"
targetNamespace="http//tempuri.org/sample/types"
elementFormDefault="qualified"
attributeFormDefault="unqualified">
<xsd:element name="echoBinaryData">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="param" type="xsd:base64Binary"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="echoBinaryDataResponse">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="param" type="xsd:base64Binary"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
</xsd:schema>
</types>

<message name="EchoBinaryDataRequest">
<part name="part1" element="ns1:echoBinaryData"/>
</message>
<message name="EchoBinaryDataResponse">
<part name="part1" element="ns1:echoBinaryDataResponse"/>
</message>

<portType name="SamplePortType">
<operation name="echoBinaryData">
<input message="tns:EchoBinaryDataRequest"/>
<output message="tns:EchoBinaryDataResponse"/>
</operation>
</portType>

<binding name="SampleSoap11Binding" type="tns:SamplePortType">
<soap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/>
<operation name="echoBinaryData">
<soap:operation style="document" soapAction="urn:echoBinaryData"/>
<input>
<soap:body use="literal"/>
</input>
<output>
<soap:body use="literal"/>
</output>
</operation>
</binding>
<binding name="SampleSoap12Binding" type="tns:SamplePortType">
<soap12:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/>
<operation name="echoBinaryData">
<soap12:operation style="document" soapAction="urn:echoBinaryData"/>
<input>
<soap12:body use="literal"/>
</input>
<output>
<soap12:body use="literal"/>
</output>
</operation>
</binding>

<service name="SampleService">
<port name="Soap11Port" binding="tns:SampleSoap11Binding">
<soap:address location="http://localhost:8080/axis2/services/SampleService"/>
</port>
<port name="Soap12Port" binding="tns:SampleSoap12Binding">
<soap:address location="http://localhost:8080/axis2/services/SampleService"/>
</port>
</service>
</definitions>

then both client and server side code can be generated with the wsdl2java tool.

it sends and receives a binary file. Following client and server side code can be used to send and receive binary data.
try {
SampleServiceStub stub = new SampleServiceStub("http://localhost:8080/axis2/services/SampleService");
stub._getServiceClient().getOptions().setProperty(Constants.Configuration.ENABLE_MTOM, Constants.VALUE_TRUE);
String clientFolder = "/home/amila/work/articles/binary/samples/mtom/client/";
DataSource dataSource = new FileDataSource(clientFolder + "client.jar");
DataHandler request = new DataHandler(dataSource);
DataHandler response = stub.echoBinaryData(request);
FileOutputStream fileOutputStream = new FileOutputStream(clientFolder + "server.jar");
response.writeTo(fileOutputStream);
fileOutputStream.flush();
System.out.println("Saved the file to client folder");
} catch (AxisFault axisFault) {
axisFault.printStackTrace();
} catch (java.rmi.RemoteException e) {
e.printStackTrace();
} catch (FileNotFoundException e) {
e.printStackTrace();
} catch (IOException e) {
e.printStackTrace();
}

Skelton code.
public javax.activation.DataHandler echoBinaryData
(
javax.activation.DataHandler param
) {

String serverFolder = "/home/amila/work/articles/binary/samples/mtom/server/";
try {
FileOutputStream fileOutputStream = new FileOutputStream(serverFolder + "client.jar");
param.writeTo(fileOutputStream);
fileOutputStream.flush();
System.out.println("Saved the file to client.jar");
} catch (FileNotFoundException e) {
e.printStackTrace();
} catch (IOException e) {
e.printStackTrace();
}

FileDataSource fileDataSource = new FileDataSource(serverFolder + "server.jar");
DataHandler dataHandler = new DataHandler(fileDataSource);
return dataHandler;
}

WSO2 WSAS 3.0-beta2 Released

2008-12-25T03:45:00.000-08:00

WSO2 WSAS 3.0-beta2 is now available for public review.
WSO2 WSAS is the enterprise version of widely used Axis2. WSO2 WSAS users the Axis2 and related other projects (Rampart, Sandesha2) to provide the Soap Stack functionality. It is shipped with a well tested version of these components (eg. Axis2 with some bug fixed version of Axis2 1.4.1) while supporting essential monitoring and administrative functionality. It supports scalability and high availability for web services with an improved and well tested clustering implementation.
Based on WSO2 Carbon platform since version 3.0, It lets users even to add WSO2 ESB which is based on synapse and WSO2 Mashup functionalities with a minimal effort.

Low cost IT solutions

2008-11-30T05:46:00.000-08:00

With the global economic crisis a lot of companies find it difficult to mange their IT budgets with the commercial proprietary software products. Most of these companies find Open source software products as a solution for there problem.
This article named as Open source lets developers speed SOA development despite economic slowdown
describes how the company called concur have build there SOA solution using WSO2 open source products.

Axis2 service Invocations

2008-11-30T04:59:00.000-08:00

Axis2 client API provides a comprehensive set of ways to access a web service. In fact there are four ways depending on the following two properties.

1.Synchronous/Asynchronous invocations – whether client thread wait until response comes or not
2.Single/Dual Channel invocations. - whether the response comes on the back channel or a separate channel initiated by the server.

Now lets see each and every method separately.

1.Synchronous Single channel
In this way the client side invocation thread blocks until the response message comes. If the transport is Http it can be seen that the response comes at the back channel with Http status 200 ok. By default Axis2 works on the single channel mode. Therefore following method does the job. Note that this method returns the response.
serviceClient.sendReceive(getTestOMElement())

2.Asynchronous Single channel
Unlike in the earlier way this kind of invocation returns the client thread immediately. User should register a callback to get the response. But response comes in the back channel as in the earlier case. Following code can be used for this kind of invocation.

AxisCallback axisCallback = new AxisCallback() {
public void onMessage(MessageContext msgContext) {
System.out.println("Got the message ==> " + msgContext.getEnvelope().getBody().getFirstElement());
}

public void onFault(MessageContext msgContext) {

}

public void onError(Exception e) {
System.out.println("Received an error ...");
}

public void onComplete() {

}
};
serviceClient.sendReceiveNonBlocking(getTestOMElement(), axisCallback);

3.Synchronous Dual channel mode
The only difference of this invocation compare to others is that the invocation happens using two different http channels. This type of invocation can only be done using Addressing. i.e both client and service should have addressing enabled. Before sending the request Axis2 client starts a Simple Http server at client side and set the Endpoint reference address of this server to the reply-To addressing header. The request channel receives a Http 202 Accepted header. Server reads the reply-to header from the request and starts a new channel to the reply-to header address. Here is the code for this.
serviceClient.engageModule("addressing")
serviceClient.getOptions().setUseSeparateListener(true);
serviceClient.sendReceive(getTestOMElement());

The useSeparateListener attribute is used to specify this dual channel mode.

4.Asynchronous Dual channel mode
This is the complete asynchronous invocation method. Client immediately returns the thread and response message receive in a separate channel. This kind of access can be made by adding the addressing engaging and useSeperateListner code for the second type of invocation.

AxisCallback axisCallback = new AxisCallback() {
public void onMessage(MessageContext msgContext) {
System.out.println("Got the message ==> " + msgContext.getEnvelope().getBody().getFirstElement());
}

public void onFault(MessageContext msgContext) {

}

public void onError(Exception e) {
e.printStackTrace();
System.out.println("Received an error ...");
}

public void onComplete() {

}
};
serviceClient.engageModule("addressing")
serviceClient.getOptions().setUseSeparateListener(true);
serviceClient.sendReceiveNonBlocking(getTestOMElement(), axisCallback);

Getting java runtime stack trace

2008-11-13T22:30:00.000-08:00

In most of the time finding java runtime stack trace is useful in debugging. The common practice is to run the application in debug mode and find the stack trace.
Here is a way I found to print the stack trace within the java code it self without running in debug mode. I found this in JavaUtils class of the Axis2 kernel.

public static String callStackToString() {
return stackToString(new RuntimeException());
}

public static String stackToString(Throwable e) {
java.io.StringWriter sw = new java.io.StringWriter();
java.io.BufferedWriter bw = new java.io.BufferedWriter(sw);
java.io.PrintWriter pw = new java.io.PrintWriter(bw);
e.printStackTrace(pw);
pw.close();
String text = sw.getBuffer().toString();
// Jump past the throwable
text = text.substring(text.indexOf("at"));
text = replace(text, "at ", "DEBUG_FRAME = ");
return text;
}

Accessing Axis2 Information at Client and Service

2008-11-05T22:50:00.000-08:00

Most of the people get used to implement web services either using POJO or generated services with wsdl using wsdl2java tool. The preferred way to generate the client code is again to use wsdl2java tool with service wsdl. In other words people preferred to use data bound java classes.
But sometimes they need to get inside information even at the Client and service level. Axis2 internally keep XML data as an Axiom object. It uses the context hierarchy in processing data. For each message Axis2 creates a message context which is bound to an Operation Context. Normally an Operation Context can have one or two message contexts depending on the Operation MEP (message exchange pattern). Therefore if there is a way to get access to Message Context or Operation Context all these details can be retrieved by using them.

At server side.
At the server side message context can be accessed like this,
MessageContext messageContext = MessageContext.getCurrentMessageContext();

once get the message context then any thing can be access from that
messageContext.getEnvelope(); // getting soap envelop
messageContext.getProperties(); // getting all the properties these inclued properties set by transports as well
messageContext.getOperationContext(); // accessing operation context
messageContext.getAxisOperation(); // axis operation information
messageContext.getAxisService(); // axis servier information

At the client side.
At the client side operation context can be accessed like this,
OperationContext operationContext = stub._getServiceClient().getLastOperationContext();
MessageContext outMessageContext = operationContext.getMessageContext(WSDL2Constants.MESSAGE_LABEL_OUT);
MessageContext inMessageContext = operationContext.getMessageContext(WSDL2Constants.MESSAGE_LABEL_IN);

Once got the message context other can be accessed as given above.

Minimal jars to run Apache Axis2

2008-11-03T23:07:00.000-08:00

Apache Axis2 distributions comes with number of jars which are used in various services. Out of these 60 jar files there are only a few needs for some applications. Actually the minimum set of jars depends on the service type to be used.

Here is a list of jars required to Deploy a service created by using wsdl2java tool using ADB databinding. This jars set is taken from Axis2 1.4.1 release.

axis2-kernel-1.4.1.jar
commons-logging-1.1.1.jar
geronimo-stax-api_1.0_spec-1.0.1.jar
wstx-asl-3.2.4.jar
wsdl4j-1.6.2.jar
XmlSchema-1.4.2.jar
axiom-impl-1.2.7.jar
axiom-dom-1.2.7.jar
axiom-api-1.2.7.jar
backport-util-concurrent-3.1.jar
neethi-2.0.4.jar
commons-httpclient-3.1.jar
activation-1.1.jar
commons-fileupload-1.2.jar
woden-api-1.0M8.jar
woden-impl-dom-1.0M8.jar
httpcore-4.0-beta1.jar
axis2-adb-1.4.1.jar
commons-codec-1.3.jar

For additional binding corresponding runtime jars for that binding is required. (i.e for xmlbeans-2.3.0.jar)

How Axis2 Engine works

2008-10-15T10:47:00.000-07:00

Axis2 Engine is one of the most important parts of Axis2 message processing. Axis2 Engine is responsible for invoking the Phases (Phase is a collection of handlers) which are supposed to invoke for a given message context object. Once Axis2 Engine invokes a Phase, then the Phase invokes the handlers for that phase in a similar a manner. Axis2 Engine uses currentHandlerIndex variable which is stored in messageContext to keep a track of executed phases.
Axis2 supports mainly two flows of message processing, namely Out flow and In flow. To support these two flows Axis2 has two methods called send() and receive() respectively.
Before calling to the send() method, Axis2 assume that the AxisService and AxisOperation has already been set to the messageContext. Normally Axis2 client calls the send() method. Therefore at the send() method it creates the handler chain by getting the Operation specific handler chain and global handler chain. Then it invokes the each phase as mentioned earlier.
Unlike in the send() method, when calling to the receive() method most of the time by the transport receiver, both AxisOperation and AxisService has not been found in the messageContext. Therefore at the receive method first it invoke the Global phases or Inflow chain which is stored in the AxisConfiguration. The main idea of this global phases is to dispatch the message (i.e. finding the AxisService and AxisOperation according to the parameters of the messageContext). Distpatch phase is the last phase of this chain. After Dispatch phase AxisService and AxisOperation should have been found. This is checked at the checkPostConditions method of the DispatchPhase class. If the dispatch information is found handler chain is populated with the operation specific handlers and continue the execution. Otherwise it throws an exception.

Using WS-commons mail transport with Axis2

2008-09-29T22:07:00.000-07:00

Axis2 and Synapse (an ESB which uses Axis2) were using separate set of codes for transports while keeping them in Axis2 and Synapse code repositories. Recently we moved then into a common place under the ws_commons project called transports. As a result of this now Axis2 uses the mail transport which was originally there with the Synapse and have removed its own mail transport.
Compared to earlier Axis2 mail transport Synapse mail transport configure a mail box parameters per service and do not use ?x-service-path to specify the service.

I recently had some tests with this transport and here is how this mail transport can be used with Axis2 for inonly and inout message operations.

First here is how to use it with a in only operation.
For in only operations we need to set the mail message receiver at the server (for service) and sender at the client. To configure the mail message receiver at server side first it is required to declare the Mail transport receiver at the Axis2 xml file and it should be looked like this,


<transportReceiver name="mailto" class="org.apache.axis2.transport.mail.MailTransportListener">

</transportReceiver>

Note that there are no parameters specified here as in with the previous Axis2 mail transports. then where we specify them? it should be done at services.xml as entry per service.


<service name="TestInService">
    <description>Test In Service</description>
    <parameter name="transport.mail.Address">mail address to listen</parameter>
    <parameter name="transport.mail.Protocol">pop3</parameter>
    <parameter name="transport.PollInterval">2</parameter>
    <parameter name="mail.pop3.host">pop3 mail account</parameter>
    <parameter name="mail.pop3.user">username</parameter>
    <parameter name="mail.pop3.password">password</parameter>
    <messageReceivers>
        <messageReceiver
                mep="http://www.w3.org/2004/08/wsdl/in-only"
                class="com.test.transports.service.TestInOnlyMessageReceiver"/>
    </messageReceivers>
    <operation name="TestInOperation" mep="http://www.w3.org/ns/wsdl/in-only">
        <actionMapping>urn:TestInOperation</actionMapping>
    </operation>
</service>

These are the only steps to follow to mail transport at server side.
At the client side we need to first declare a mail sender.


<transportSender name="mailto"
                 class="org.apache.axis2.transport.mail.MailTransportSender">
    <parameter name="mail.smtp.from">from address this is added to from header</parameter>
    <parameter name="mail.smtp.user">user name</parameter>
    <parameter name="mail.smtp.password">password</parameter>
    <parameter name="mail.smtp.host">smtp host</parameter>
</transportSender>

Sender configuration is almost similar to earlier Axis2 sender configuration. Now we can use this code to send the message using mail transport.


    ConfigurationContext configurationContext =
                    ConfigurationContextFactory.createConfigurationContextFromFileSystem(
                            AXIS2_REPOSITORY_LOCATION, AXIS2_CLIENT_CONFIG_FILE);
    ServiceClient serviceClient = new ServiceClient(configurationContext, null);
    serviceClient.setTargetEPR(new EndpointReference("mailto:test@wso2.com"));
    serviceClient.getOptions().setAction("urn:TestInOperation");
    serviceClient.fireAndForget(getTestOMElement("org"));

Note here that it is enough to specify the email address of the server. Since there is a particular receiver for this service, it will pick the message from there.

Now lets see how we can use mail transport for an inout operation. The smtp transport does not have an implicit back channel. Therefore response should come as a separate mail message. The request message will go to the server as in the inonly scenario. So now lets see how to configure to receive the response message.
First a mail sender should be configured at the Axis2 xml in the server side as given above. So that the server can send the response using this transport sender. Server picks the sending address either using WSA reply to header if given or SMTP reply to header.
To configure the receiver at the client side first we need to add the mail transport receiver at the client Axis2 xml file as given above. Then the there is a question of how to set the other parameters since there is no any services.xml file at the client side. Actually mail transport receiver gets these parameters from the Axis2 service and hence we can set them at the client code itself like this.


     ConfigurationContext configurationContext =
                    ConfigurationContextFactory.createConfigurationContextFromFileSystem(
                            AXIS2_REPOSITORY_LOCATION, AXIS2_CLIENT_CONFIG_FILE);
     ServiceClient serviceClient = new ServiceClient(configurationContext, null);
     serviceClient.setTargetEPR(new EndpointReference("mailto:oiositest2@wso2.com"));
     serviceClient.getOptions().setAction("urn:TestInOutOperation");
            
     // these two lines are needed only if it is required to use addressing
     serviceClient.getOptions().setUseSeparateListener(true);
     serviceClient.engageModule("addressing");

     serviceClient.getAxisService().addParameter("transport.mail.Address","test@wso2.com");
     serviceClient.getAxisService().addParameter("transport.mail.Protocol","pop3");
     serviceClient.getAxisService().addParameter("transport.PollInterval","2");
     serviceClient.getAxisService().addParameter("mail.pop3.host","pop 3 address");
     serviceClient.getAxisService().addParameter("mail.pop3.user","username");
     serviceClient.getAxisService().addParameter("mail.pop3.password",”password");

     OMElement result = serviceClient.sendReceive(getTestOMElement("org"));
     System.out.println("Result ==> " + result);

There will be a separate listener for the given mail address and that receives the response.

Running WSO2 WSAS on WebLogic

2008-09-16T03:27:00.000-07:00

WSO2 WSAS can be used not only as a standalone application but also as an web application for a servlet container. Many people find latter very useful since that let them run the WSO2 WSAS within their favorite Servlet Container along with the other applications.

I recently had some experiments with the WebLogic server using the 10 Minute Guide to Installing WSO2 WSAS on WebLogic Tutorial written by Afkham Azzez. Every thing worked fine in the installation process.

Then I tried to do more experiments with some WSO2 Mercury samples. By doing this I found that the response messages are not serialized properly. Further looking into that I found when running on Weblogic Axiom uses the underline stax implementation of the WebLogic and that causes some problems of serializing the namespaces and namespace prefixes.

This made me surprised since Axiom supposed to work with any stax implementation. Then I looked into the Axiom serialization logic and found that it works on two different ways.

For some stax implementations it first writes the prefix for a new namespace
For some stax implementations it writes the prefix after start Element

For wstx (default for Axis2) and sun stax implementations it works on the later mode and that has done by specifying these names at the serializing logic. I specified the weblogic also as a later mode implementation and that made every thing worked fine.

I have made these changes already to Axiom and any one having problems working in weblogic can try with Axiom nightly builds.