Popular Posts

Friday, June 29, 2007

An easy way to deploy pojo based Axis2 web services

Ever wonder deploying axis2 web services without archiving them in aars? There is an easy way to deploy axis2 web services directly inside any servlet container. Lets see how this simple deployment can be done..

If you haven't configured axis2 yet, get latest version from here
Simply copy axis2.war file in to the webapps directory of your favorite servlet container. Assuming apache tomcat 6 as the servlet container, axis2.war should be copied to ..\apache-tomcat-6.0.10\webapps. Start tomcat. axi2.war will be deployed inside tomcat.

Now you have to tell Axis2 to expose files in the given formats as web services. It can be done by adding the following custom element in to axis2.xml which can be found at ..\apache-tomcat-6.0.10\webapps\axis2\WEB-INF\conf\.
<deployer extension=".class" directory="pojo" class="org.apache.axis2.deployment.POJODeployer">



This simply says, the files with the extension .class which are placed at pojo directory will be exposed as web services.

You need to create a new directory, pojo inside ..\apache-tomcat-6.0.10\webapps\axis2\WEB-INF.

Now write your service implementation class.

public class myservice{
public String echo(String s){
return s;
}
}

Compile and save it under the above pojo directory.

Restart tomcat and access axis2 administration page. (http://localhost:8080/axis2)
You will be able to see the deployed service.

Thursday, June 28, 2007

Creating and deploying Java web services using Eclipse WTP and WSO2 WSAS

Recently WSO2 has worked with Eclipse WTP team to integrate wso2 Web Services Application Server (WSAS) in to Eclipse WTP (Web Tools Platform). This greatly reduces the effort of developing java web services and it will definitely a revolutionary tool for web service developers.
I would like to introduce a few nice features of this user friendly tool, so that anybody can start to use it for java web services development.

In order to use this integrated tool kit, WSO2 web services application server has to be downloaded to your local server. Get the latest WSAS binary distribution from here.
Just unzip it to your local file system. Suppose it is placed at C:\webservices\wso2wsas-2.0.

Now you have to download Eclipse WTP. An Stable WTP build can be downloaded from Eclipse web tools project . I would recommend you to get the wtp-all-in-one package.

Unzip the wtp distribution in to your file system. Suppose its located at C:\eclipsewtp.

Next, you need to add WSO2WSAS plugins to wtp in order to integrate it with the web tools platform. Go to your WSO2WSAS home directory (C:\webservices\wso2wsas-2.0) and run the install.bat under WSO2WSAS_HOME/bin.
It will prompt for selecting one of the two options;
1. WSO2 WSAS Servlet Container Installation
2. WSO2 WSAS Eclipse WTP Plugins Installation
Select 2. It will ask the eclipse WTP Home directory. Enter C:\eclipsewtp
You will see that the installer copying the required plugins to wtp.

Now Start wtp by clicking on eclipse.exe. You should see WSAS startup icon at the tool bar if the WSO2WSAS-Eclipse wtp integration was successful.

Now WTP should be configured to identify the WSAS runtime. Go to Window-->Preferences-->Webservices-->WSAS Preferences and specify WSO2WSAS_HOME directory(C:\webservices\wso2wsas-2.0). You should get the 'WSAS Runtime loaded successfully' message.

Click on 'WSAS server start' icon at the eclipse wtp tool bar.
WSO2WSAS server will be started in a separate command window and "WSO2 Web services application server instance started successfully" message will be displayed.
You can access the WSO2WSAS management console inside the eclipse WTP internal browser.

OK.. Thats all for installing and setting up your java web services platform. Lets write a simple web service and deploy it on WSO2WSAS.

- Create a new dynamic web project (New-->Web-->Dynamic web project)
- Select Target runtime as WSO2WSAS in 'New Server Runtime' (Second step of the new dynamic web project creation wizard)
- Write service implementation class
public class Testservice {
public String echo(String s){
return s;
}
}
- Now right-click on the service class in the package explorer pane and select Web services-->create web service
- Web service creation wizard will be displayed.
- Don't forget to change web service runtime to WSO2WSAS in the first step of the wizard.
- Click Finish

If you access WSO2WSAS management console through WTP internal browser, you can see your web service is deployed there.

You should realize how WSO2WSAS-Eclipse WTP integration reduce the java web service development effort and provide a user friendly IDE for JAVA web service developers.

You can find more information on WSO2WSAS at WSAS home page

Sunday, June 24, 2007

QA in open source projects

Quality assurance is a traditional activity in software development life cycle which starts from the inception stage of a project and flows through design, execution, release and maintenance phases. However these type of clearly defined phases cannot be realized in most of the open source projects. Rather defining SQA activities in to different stages, agile QA approaches emerge to facilitate quicker development and release cycles.
It is always not possible to define a properly managed quality assurance process in most of the open source projects. Strictly defined deadlines, properly documented requirements and designs, well planned releases are essential supporting components for having a good QA process. However most of the above (Sometimes none of the above) tasks are not done in open source software development. Due to these circumstances QA cannot control the whole process.
Is it possible to maintain an effective QA process in open source projects? Is it possible to adhere to a schedule even if a development process is not defined? How does QA control the open source product releases? Any QA engineer who involves in open source projects may raise these question.
I tried to find out answers for the above questions.

Maintaining a QA process

Most of the QA processes consist of the following phases.

Test requirements identification
Test design
Test execution

Due to the poorly documented open source software requirements, QA test requirement identification may be difficult. However QA can start this activity through wikis, mailing lists and they can publish the identified test requirements in a QA test plan. QA test plan will be the primary source of the quality assurance test activities which are going to be executed throughout the project. Also, Live updates on QA test plan is possible if it is wiki based.

In commercial software projects, QA test designing is performed by referring to the requirement specification. The use cases are converted to a set of test scenarios and which are used to derive test cases. How are tests designed when requirement specifications are not available? QA Test designing is an endless activity in most open source projects. The initial set of test cases are designed using the basic project requirements which are captured from the discussions happening in mailing lists and wiki pages. These are refined when a build is released for verifying the basic functionalities of the product. Subsequently more scenarios are captured and test cases are derived using them. But it is not the end of test design. More and more test cases and scenarios are identified when more functional builds are released for testing.

Test execution is a two-fold activity in open source projects. Initially QA team does ad-hoc testing to check the basic functions of the AUT (Application under test). Then the execution of test cases is carried out. If a new scenario is captured while performing the ad-hoc tests, it is amended to the QA test case document. So that, QA team is equipped with a comprehensive set of test cases when the final builds are available for testing.

QA Scheduling

Following the defined activities and maintaining the schedule are important features of a good QA process. However in open source world, schedule is haphazard. Projects are not governed by strict deadlines and plans. Because of that, builds are received randomly for QA testing. There is no strictly defined 'First Build to QA' date. When a set of features are done, QA gets a build for verifying the implemented features. However these random QA builds are really important for QA team to capture more test scenarios while studying the product.
Usually release candidates (RCs) are delivered for QA testing 2-3 weeks before the final product release (This depends, of course :) . Release candidates are equivalent to the official QA builds which includes almost all the functionalities. QA team conducts thorough functional and regression tests in these RCs. The effort and duration for testing a particular RC will be subjected to change even if it is planned initially due to the randomly added features and changes in the final release date.

Controlling product releases

In most commercial projects, an approximation about the release can be obtained through the QA metrics. Defect severity index, defect density provide a better indication of the project status and product stability. However, this is not exactly applicable for open source projects. Last moment changes are happened and regression issues are introduced. However it is really important to set an acceptable release criteria for any opensource project. For example, release will not be accepted by QA team unless blockers and critical bug count are zero. Also QA has to convince developers to resolve all the open bugs and update the status in defect tracking system. This will provide a clear indication on the release status.

Saturday, June 23, 2007

Using Apache Jmeter to test axis2 web services

I wrote a tutorial on apache JMeter and axis2 web services two months back and which was published in wso2.org. It describes the basic scenario of writing a Java service implementation class, Deploy it in a servlet container and send a soap request to the web service using JMeter and retrieving the response. Have a look!!