Popular Posts

Wednesday, December 23, 2009

How to install WSO2 Carbon cluster management feature

I have written and published a tutorial on wso2.org which guides you through the steps of installing WSO2 Carbon cluster management feature.

Saturday, November 28, 2009

Selenium test reporting with maven surefire report plugin

If you are familiar with Junit, you may have already known the maven surefire plugin which enables running unit test inside maven build cycles. Normally, surefire plugin generates the XML test reports at /target/surefire-reports directory. If you use selenium RC integrated with your build system or as a separate test framework, you may use maven-selenium-plugin coupled with the surefire plugin to launch your tests.
As far as I know, there are two ways to generate test reports when selenium is coupled with maven.

1. Use LoggingSelenium java library to generate HTML test reports with screenshots

2. Use maven-surefire-report plugin

This post is about the latter one, maven-surefire-report plugin.

The default configuration of surefire-report-plugin is trivial. You just need to add a <reporting> element to projects' pom.xml as follows.

<reporting>
<plugins>
<plugin>

<groupId>org.apache.maven.plugins</groupId> <
<configuration>

<outputDirectory>${basedir}/target/wso2qa</outputDirectory>

</configuration>

</plugin>
</plugins>

</reporting>


When you run mvn surefire-report:report goal after running the tests, HTML based descriptive report will be created at the specified output directory. In this mechanism, you do not use anything specific to selenium,but get the advantage of surefire report plugin in test reporting.

Friday, November 13, 2009

Running WSO2 Carbon based products on IBM JDK

The next minor release of WSO2 Carbon product platform (2.0.2) will be fully compatible with IBM JDK (IBM J9 VM 2.4). You simply need to update transports.xml as follows in order to run any of the WSO2 carbon based product on IBM JDK.

Open CARBON_HOME/transports.xml

Add the following parameter to HTTPS transport configuration

<parameter name="algorithm">IBMX509</parameter>

Now, restart carbon. Server will be started successfully on IBM JDK.

Carbon-2.0.2 product platform will be released within next week. Stay tuned..

Thursday, October 29, 2009

How to configure persistent RM in WSO2 WSAS

WSO2 Web Services Application Server (WSAS) provides with a storage manager in which you can persist messages transmitted between RMS (reliable messaging source) and RMD (reliable messaging destination). By configuring persistent RM, you can prevent messages loses even if the server is down. This post guides you through the steps to configure persistent RM in the latest versions of WSO2 WSAS (WSAS-3.*). I assume you have a basic understanding about WS-RM, if not, please read http://www.infoq.com/articles/fremantle-wsrm-introduction first.
Pre-requisites
Download and install WSO2 WSAS-3.1.1

Persistent implementation of WS-RM will be supported in most of the popular DBMSs. However, I will use MySQL server 5.* in this demonstration. Therefore, install and configure MySQL.

Step 1
As the first step, we need to create the persistent storage which is going to be used in reliable message transmission. Lets create a data base and the necessary table as follows.

mysql>create database SANDESHA_DB;


mysql>use SANDESHA_DB;


mysql>create table wsrm_sender (
message_id varchar(255) not null,
message_context_ref_key varchar(255),
internal_sequence_id varchar(255),
sequence_id varchar(255),
to_address varchar(255),
inbound_sequence_id varchar(255),
send smallint,
sent_count integer,
message_number bigint,
resend smallint,
time_to_send bigint,
message_type integer,
last_message smallint,
inbound_message_number bigint,
transport_available smallint,
flags integer,
primary key (message_id)
);

mysql>create table wsrm_rmd (
sequence_id varchar(255) not null,
to_epr_addr varchar(255),
to_epr blob,
reply_to_epr_addr varchar(255),
reply_to_epr blob,
acks_to_epr_addr varchar(255),
acks_to_epr blob,
rm_version varchar(255),
security_token_data varchar(255),
last_activated_time bigint,
closed smallint,
terminated_flag smallint,
polling_mode smallint,
service_name varchar(255),
flags integer,
reference_message_key varchar(255),
highest_in_message_id varchar(255),
last_in_message_id varchar(255),
server_completed_messages blob,
outof_order_ranges blob,
to_address varchar(255),
outbound_internal_sequence varchar(255),
next_msgno_to_process bigint,
highest_in_message_number bigint,
rmd_flags integer,
primary key (sequence_id)
);

mysql>create table wsrm_rms (
create_seq_msg_id varchar(255) not null,
sequence_id varchar(255),
to_epr_addr varchar(255),
to_epr blob,
reply_to_epr_addr varchar(255),
reply_to_epr blob,
acks_to_epr_addr varchar(255),
acks_to_epr blob,
rm_version varchar(255),
security_token_data varchar(255),
last_activated_time BIGINT,
closed smallint,
terminated_flag smallint,
polling_mode smallint,
service_name varchar(255),
flags integer,
id bigint,
internal_sequence_id varchar(255),
create_sequence_msg_store_key varchar(255),
reference_msg_store_key varchar(255),
last_send_error blob,
highest_out_relates_to varchar(255),
client_completed_messages blob,
transport_to varchar(255),
offered_endpoint varchar(255),
offered_sequence varchar(255),
anonymous_uuid varchar(255),
last_send_error_timestamp bigint,
last_out_message bigint,
highest_out_message_number bigint,
next_message_number bigint,
terminate_added smallint,
timed_out smallint,
sequence_closed_client smallint,
expected_replies bigint,
soap_version integer,
termination_pauser_for_cs smallint,
avoid_auto_termination smallint,
rms_flags integer,
primary key (create_seq_msg_id)
);

mysql>create table wsrm_invoker (
message_context_ref_key varchar(255) not null,
sequence_id varchar(255),
context blob,
msg_no bigint,
flags integer,
PRIMARY KEY (message_context_ref_key)
);

mysql>create table wsrm_msgctx (
ctx_key varchar(255) not null,
ctx blob,
PRIMARY KEY (ctx_key)
);

Note: From WSAS-3.2.0 onwards, the following columns must be added to the wsrm_rms table in addition to the columns specified above.

offered_endpoint_epr_addr varchar(255),
offered_endpoint_epr varchar(255),
reallocated integer,
internalSeqIDOfSeqUsedForReallocation varchar(255),

Step 2

Since we are going to establish a JDBC connection to a MySQL DB, copy mysql jdbc driver to WSAS_HOME/repository/components/lib and restart WSAS
Log in to WSAS management console and click on modules -->list. Click on configure link of the sandesha2 module.
By default, WSO2 WSAS uses an inmemory implementation of WS-RM. You can change it to persistent by changing Storage Manager property. Configure the rest of the persistent storage details as follows.
Connection String - jdbc:mysql://localhost:3306/SANDESHA_DB
Driver Name - com.mysql.jdbc.Driver
Username - your mysql username
Password - your mysql password




Step 3

Now, you have enabled persistent RM in WSO2 WSAS. However, due to a bug in the latest WSAS releases, you should update the following property in WSAS_HOME/conf/axis2.xml

<parameter name="Sandesha2StorageManager">persistent</parameter>

Make sure to restart WSAS after configuring the above element in axis2.xml

Step 4

Now, you are ready to send requests to a service hosted in WSAS through RM and verify persistent RM. In order to do that, engage sandesha2 module in a service and send series of requests (say 100 requests) using a RM client (I assume you are familiar with sending soap messages with RM headers. I will publish a separate post on complete RM client-server invocation soon). After transmitting 30 requests, shutdown WSAS and restart. You will notice that after the server is restarted, the message transmission will be resumed from the message no: 31

If you have any issues with the steps given above, please drop me a mail.

Saturday, October 24, 2009

Key factors for successful test automation

At WSO2, we have been making considerable progress in building a complete test automation solution. According to my experience on that effort, I think the followings are the key factors contributed to a successful test automation project.

  • Dedication to automation (Instead of treating it as a spare-time activity)
  • Commitment by the entire team (rather than just one or two testers),
  • Commitment to automation from the start (rather than trying to automate a manual process later)
  • Making use of correct tools/frameworks/technology
  • Allocating sufficient time and resources

Friday, October 16, 2009

How to pass system properties to maven surefire plugin test run

While developing WSO2 QA test framework (which is based on selenium RC), we wanted to give users the choice of selecting test cases without running whole suite at once. Our plan was to pass a system property during maven test run. However, passing a system property directly through command line does not work since the surefire plugin is run under a different JVM instance that is launched by Maven.
In order to overcome this, maven surefire plugin can be configured as follows by specifying the required system property.

<systemProperties>
<property>
<name>test.suite</name>
<value>${test.suite}</value>
</property>
</systemProperties>

According to this example configuration, we can run test suite with passing a system property as follows.

'mvn clean install -Dtest.suite=test-case'

Saturday, October 10, 2009

The newest version (2.0.1) of WSO2 carbon family of prodcuts released!!

The latest version of WSO2 carbon based products were released yesterday. More info can be found at http://wso2.org/projects/carbon

New Features in This Release
----------------------------
* Improved transaction support.
* Improved Support for deploying on top of WebSphere, WebLogic, and
JBoss.
* P2 based provisioning for WSO2 Carbon family of products.
* Numerous bug fixes.

Wednesday, September 30, 2009

How to run multiple WSO2 WSAS instances in a single host

I have published a simple three step tutorial on running multiple WSO2 WSAS instances in a single host in WSO2 Oxygen Tank. Have a look!

Wednesday, September 16, 2009

How to enable JMS in WSO2 WSAS-3.*

WSO2 WSAS provides with a simple and easily configurable UI to enable transports. In this post, we are going to look at how JMS is enabled in WSAS-3.* versions.

Pre-requisites:
----------------
You can use any JMS provider as you preferred. I'm going to use Apache ActiveMQ-5.2.0 for this example.
Download the latest version of WSO2 WSAS from here

Step 1
-------
Suppose you have downloaded WSO2 WSAS-3.* and extracted in to a directory in your file system. Let it be WSAS_HOME

First, we need to start ActiveMQ message broker. Go to ActiveMQ_Install_dir/bin and run activemq.bat
Also, the following ActiveMQ libraries must be copied to WSAS_HOME/repository/components/lib directory
  • activeio-core-3.1-SNAPSHOT.jar (ActiveMQ_Install_dir\lib\optional)
  • activemq-core-5.0.0.jar (ActiveMQ_Install_dir\lib\)
  • geronimo-j2ee-management_1.0_spec-1.0.jar (ActiveMQ_Install_dir\lib\)
  • geronimo-jms_1.1_spec-1.0.jar (ActiveMQ_Install_dir\lib\)
Now, restart WSO2 WSAS

Step 2
-------
Log in to WSAS management console (username=admin, password=admin) and click on Manage --> Transports at the left navigation menu.
You will be directed to the Transport Management page as follows.



Step 3
-------
Locate JMS transport in the above Transport Management page and click on enable next to transportListener
Following page will be shown where you can configure JMS listener according to your JMS provider.



similarly, you can enable JMSSender.

If JMS is configured correctly as in the above steps, you will see the JMS endpoints of your service will be shown in the WSDLs or service dashboard as follows.

Monday, September 7, 2009

WSO2 Carbon is among InfoWorlds best open source software

WSO2 has been named an InfoWorld 2009 Best of Open Source Software (Bossie) Award winner.

http://www.infoworld.com/d/open-source/best-open-source-platforms-and-middleware-758?current=9&last=8?r=76

Proud to be a member of the award winning team :)

Friday, August 28, 2009

Where to put third party jars in WSO2 WSAS?

In the pre-carbon versions of WSO2 WSAS (2.* and older), you may have used WSAS_HOME/lib/extensions directory to put third party jars such as jdbc drivers.

After WSO2 WSAS became a part of WSO2 Carbon platform, a.k.a WSAS-3.* versions, all third party jars should be placed inside WSAS_HOME/repostiroy/components/lib directory of your WSAS distribution.

**This is applicable to all WSO2 Carbon products (WSAS, ESB, G-reg, IS, BPS)

Remotely starting OSGI console when WSO2 Carbon runs on an application server

When WSO2 Carbon based product (WSAS, ESB, G-reg, BPS, IS) runs in standalone mode, you can start server with equinox OSGI console just by issuing -DosgiConsole system property.

wso2server.bat -DosgiConsole

How do you connect to OSGI console when you are running Carbon on an application server such as WebSphere or WebLogic (or tomcat, JBoss etc..)?

1. Open WEB-INF/web.xml file of the carbon web application
2. Uncomment the following element

<init-param>

<param-name>osgiConsole</param-name>

<param-value>-console 19444</param-value>

</init-param>

3. Now restart carbon with these settings.
4. Open a new command window/shell and connect to osgiConsole using telnet as follows

telnet localhost 19444

Saturday, August 15, 2009

How to deploy WSAS-3.X on Oracle WebLogic 10.3

WSO2 DOES NOT ENCOURAGE INSTALLING WSO2 APPLICATION SERVER (previously known as WSAS) ON TOP OF OTHER APPLICATION SERVERS. WSO2 HAS DECIDED TO DROP SUPPORT FOR WEBAPP DEPLOYMENT MODE OF THE WSO2 PLATFORM AND PRODUCTS.






Once Azeez has written a 10 minute guide to installing WSO2 WSAS on Weblogic server. That guide explains the steps to deploy 2.X family of WSAS on weblogic. With the introduction of WSO2 Carbon platform in December 2008, WSO2 WSAS is no longer distributed as a separate war distribution. Hence, the instructions given in that document is not applicable when deploying WSO2 WSAS-3.X series on Oracle WebLogic server.
Since all WSO2 java products are built on Carbon platform, users can configure running WSO2 products on any application server using a set of components included in binary distributions. I have already explained the steps to deploy WSO2 BPS on tomcat and WSO2 WSAS-3.X on Jboss.

This post describes the steps to deploy WSO2 WSAS-3.X on WebLogic 10.3

Step1

Create a new weblogic domain by running config.sh {bat} located at WebLogic_HOME/wlserver_10.3/common/bin directory.
Lets assume the new domain is wsas.

Access your weblogic domain direcrtory and start weblogic (Go to WebLogic_HOME/user_projects/domains/wsas/bin and run startWebLogic.cmd)

Step 2
Download the latest version of WSO2 WSAS-3.X from here. Extract the downloaded zip into a directory. Copy conf, database, repository and resources directories in to a new folder. Here after, we will refer it is wsas-repo (i.e:- C:\wsas\wsas-repo)

Also, create a new directory, wso2wsas and copy the WEB-INF directory located at the webapps/ROOT directory of the downloaded WSO2 WSAS-3.X to wso2wsas directory. Now, your wsas-repo should have five sub directories - conf, database, repository, resources and wso2wsas.
wso2wsas will be used as the webapp root directory.

Step 3

We need to enable SSL in weblogic server. Log in to weblogic administration console (You should have configured username and password for admin console when creating your WebLogic domain) and go to Environment --> servers. Select AdminServer.
Click on KeyStores tab. Configure keystores as shown below.



Keystore = Custom Identity & Custom Trust


Custom Identity Keystore = C:\wsas\wsas-repo\resources\security\wso2carbon.jks

Custom Identity Keystore Type = JKS

Custom Identity Keystore Passphrase = wso2carbon

Confirm Custom Identity Keystore Passphrase = wso2carbon

Custom Trust Keystore = C:\wsas\wsas-repo\resources\security\wso2carbon.jks

Custom Trust Keystore Type = JKS

Custom Trust Keystore Passphrase = wso2carbon

Confirm Custom Trust Keystore Passphrase = wso2carbon

Now, select SSL tab and enter the following values.

Identity and trust locations = keystores

Private Key Alias = wso2carbon

Private Key Passphrase = wso2carbon

Confirm Private Key Passphrase = wso2carbon


Save the configuration and go to the General tab. Select the check box next to "SSL listen port enabled".

Now we have configured the necessary changes to enable SSL on weblogic. Lets continue with deploying WSO2 WSAS on weblogic.

Step 4

Now, we should update the set of config files shipped with WSO2 WSAS. We will update carbon.xml, axis2.xml, registry.xml and user-mgt.xml which can be found at the above wsas-repo\conf directory.
First, open carbon.xml and update the ServerURL element as follows.

<ServerURL>https://localhost:7002/wso2wsas/services/</ServerURL>

Note that we have configured weblogic to run on 7002 port.

Update WebContextRoot element as follows.

<WebContextRoot>/wso2wsas</WebContextRoot>

Save and close carbon.xml.

Open registry.xml and update DB URL as follows.

<url>jdbc:h2:C:\wsas\wsas-repo\database\WSO2CARBON_DB;create=true</url>

Now, open user-mgt.xml and update database URL as follows.

<url>jdbc:h2:C:\wsas\wsas-repo\database\WSO2CARBON_DB;create=true</url>

Make sure to specify the absolute path of the WSO2CARBON_DB in both of the above elements.

We must change the http and https ports in In Transports section of axis2.xml as follows.

<transportReceiver name="http"
class="org.wso2.carbon.core.transports.http.HttpTransportListener">
<parameter name="port">7001</parameter>

</transportReceiver>

<transportReceiver name="https"
class="org.wso2.carbon.core.transports.http.HttpsTransportListener">

<parameter name="port">7002</parameter>
</transportReceiver>

Step 5

We have completed the required configurations and we can deploy WSO2 WSAS on weblogic now.
First, shutdown the weblogic server instance if it is still running.
open a new command window and change the directory to WebLogic_HOME/user_projects/domains/wsas/bin.
Define an environment variable called CARBON_HOME and set the path to your wsas-repo directory.

In windows; set CARBON_HOME=C:\wsas\wsas-repo
In linux; export CARBON_HOME=\home\user\wsas\wsas-repo

Run startWebLogic.cmd

Once the server is started successfully, log in to weblogic administration console using https://localhost:7002/console
Then, go to the Summary of Deployments page and select Install.
Locate the deployment root by selecting C:\wsas\wsas-repo\wso2wsas directory. (web app root directory will be shown with a radio button option as follows.



Click on next to proceed through the wizard and continue with the default settings.
Once the deployment is successful, save the configuration and select start --> servicing all requests

Now, we are done with the deployment. You could access the management console using https:\\localhost:7002\wso2wsas\carbon

Note:-
1. In order to set the log4j logs, you may copy log4j.properties file in the extracted WSO2WSAS-3.X directory to wsas-repo\wso2wsas\WEB-INF\classes

2. If you want to deploy JaxWS services in WSAS/WebLogic platform, you should do the following configuration to avoid a class casting issue (https://wso2.org/jira/browse/CARBON-4835)

- Remove weblogic.jar/META-INF/services/com.sun.xml.ws.api.wsdl.writer.WSDLGeneratorExtension & restart Carbon

3. Also, Make sure to copy xalan-*.jar, xercesImpl-*.jar and xml-apis-*.jar from the lib/endorsed directory of the extracted WSAS binary distribution to weblogic endorsed directory before you start WSAS.




Thursday, July 9, 2009

Build your own server using WSO2 Carbon components

Building a customized server with a set of components downloading from a public repository...
It is no longer a hard and complex task. Now you can build your own version of WSO2 carbon platform using its Equinox P2 based provisioning capabilities.
This post guide you through the steps to build your own server platform using WSO2 carbon-2.0.0.

Pre-requisites:
Download the latest version of WSO2 Carbon server. WSO2 Carbon is the base platform on which we build our customized server.

Step 1

Start carbon server with osgiConsole so that we can issue commands to manage OSGI framework.

cd CARBON_HOME/bin (CARBON_HOME is the location where you unzipped wso2carbon-2.0.0.zip)
wso2server.bat -DosgiConsole

Step 2

Next, we need to specify artifact and metadata repositories from which we download several features and their metadata.

In the osgi console, issue the following commands.

osgi>provaddrepo http://dist.wso2.org/p2/carbon/releases/2.0

osgi>provaddartifactrepo http://dist.wso2.org/p2/carbon/releases/2.0



Step 3

Lets check the installable features included in the above artifact repository.

osgi>provlg

This will list down all the features available in the specified artifact repository as follows.


Step 4

Now we have connected to the artifcat and metadata repositories and looked at the installable features. Suppose we need to build our customized server with the following components out of the features included in the artifact repo.

  • data services
  • service management
  • tools
We can install data service feature as follows.

osgi>provinstall org.wso2.carbon.dataservices.feature.group 2.0.0

If the installation is successful, you will get "installation complete" message.

Similarly, you can install service management and tools features.

osgi>provinstall org.wso2.carbon.tools.feature.group 2.0.0

osgi>provinstall org.wso2.carbon.tools.feature.group 2.0.0



Step 5

Now you must restart carbon server to apply the changes you have done to the server.
Issue the following command to shutdown the server.
osgi>shutdownCarbon

Start the server again using wso2server.bat{sh}

After server is started, access management console using http://localhost:9443/carbon

Log in to management console using the default admin credentials (admin/admin)



You should notice that the data services, service management and tools features are added to the carbon core platform. In other words, we have built our own server on top of carbon-core server.
Simple.. isn't it?

Wednesday, July 8, 2009

How to deploy CARBON based WSO2 products on non-ROOT web context

The latest versions of WSO2 carbon product family is available for download now. This version consists of a lot of feature enhancements and bug fixes. All products are free, no hidden costs!

WSO2 Carbon based products (WSO2 WSAS, WSO2 ESB, WSO2 IS, WSO2 Governance Registry) can be deployed on any application server with minimum configuration steps. When you are setting up a web application on an application server, you must change the web context of web app. Even if you use WSO2 carbon based product in standalone mode, you may need to change the default ROOT web context.

You can change the web context easily with two steps.

1. Open CARBON_HOME/conf/carbon.xml and change the following parameter.

<WebContextRoot>/</WebContextRoot>

CARBON_HOME is the location where you extracted the binary distribution.

Suppose you need to change the web context of WSO2 WSAS to wsas. Then simply edit it as follows.

<WebContextRoot>/wsas</WebContextRoot>

2. Now you need to rename the carbon web app directory to match with the above web context.
Go to CARBON_HOME/webapps directory and rename ROOT to wsas.

Thats all! Start carbon server (i.e: WSO2 WSAS) and access administration console using the following URL

https://<hostname>:<port>/wsas/carbon

Sunday, July 5, 2009

Complexity of middleware testing

I have been testing SOA middleware applications for nearly 3 years. I also tested traditional CRM, Telco billing applications for more than 4 years. Quality assurance of middle ware is completely different from the traditional business application testing. It requires a lot of effort. I have observed following facts/concerns which related to middleware testing.

1. Target audience/end users of middleware apps
Most middleware products are developed for the use of highly technical tasks and they are used by programmers. When it comes to SOA middleware, product end-users are technically savy engineers. Therefore when testing them, QA/test teams should understand the purpose of it, target audience and act accordingly.

2. Complexity of applications
The developers understand the use cases of middleware applications when implementing them. Obviously without knowing the requirements, they can't be implemented. Therefore the developers of middleware applications gets the knowledge of the application under development while it is being developed regardless of the complexity of it.
This is not applicable for QA/testers. In agile like processes, due to the release crunch, QA gets no time to learn the use of middleware. They do not even get time to derive test cases/scenarios. So, QA teams are forced to test applications with these limitations.

3. Test Automation
Majority of the middle ware application tests can be automated. However, it cannot be done by overnight. Without having a better understanding of the applications, no body can automate them. Automation is highly effective for middleware testing.
Having said that, I must emphasize that, automation is not the solution for everything. Specially in middleware testing, human intervention is critical. If you are a middleware tester, you must live with the application and its surrounding technologies. You must learn the use cases of middle ware app and apply them to derive more and more test scenarios. In my career, 80% of highly severe bugs were uncovered by exploratory testing.

It takes times to learn the technologies behind middleware apps. It takes time to understand the use of them. A content management system or a telco billing application can be learned and understand with considerably less time and effort. However, middleware applications are different and deriving use cases are not simple.

If you have any doubts about the complexity of middleware testing, the best way to clarify them is to involve in middleware testing for few days. Work with middleware test teams. Then you can understand the real situation and issues behind it.

Saturday, June 27, 2009

Business activity monitoring (BAM) with WSO2 Governance Registry

BAM refers to the aggregation, analysis, and presentation of real time information about activities inside organizations and involving customers and partners. The main benefits of BAM are to enable an enterprise to make better informed business decisions, quickly address problem areas, and re-position organizations to take full advantage of emerging opportunities.
BAM solutions often present information on dash boards using various graphs.

WSO2 Governance Registry provides with BAM functionality which enables users to aggregate various web services data and visualize them using dashboard gadgets. In this post, I'll describe how you can add a remote server for monitoring and generate graphs.

Pre-requisites:
Download and install (Unzip the binary) WSO2 Governance Registry-3.0.0-beta1 release from here
We will refer to the unzipped directory, Greg_Home

Step 1
Start WSO2 Governance Registry server by running wso2server.bat{sh} from Greg_Home/bin

Step 2
Access the management console of Governance Registry by using https://localhost:9443/carbon
You can log in to the console with default administrator credentials (admin/admin).
You will be landed in the Home page of WSO2 Governance Registry.



Step 3
As the first step of activity monitoring, we need to add a server from which the data can be collected. In this post, I'll use a WSO2 Web Services Application Server (WSAS) instance running on my local machine as the monitored server.

Click on Monitoring servers at the left navigation of WSO2 Governance Registry console. You will be directed to the Monitored servers page. Click on Add server link to add an external server for monitoring.



Suppose the WSAS server instance (the monitored server) is running on https port 9444 on my local machine.
Enter the serverURL, https://localhost:9444
Enter WSAS administrator credentials (username=admin, password=admin)
Click on Add. You will get "Server successfully added" message.

Step 4

Now we have added a server instance to monitor. Lets gather the service statistics and configure dashboard gadgets to visualize data.
Click on Main Dashboard in the left navigation menu of Governance Registry management console. You will see the Dashboard page as follows.




Step 5
Select the first gadget, Messages received in last minute, and click on configure tab. Select https://localhost:9444 from the server dropdown list.


When you select a server from the drop down list, the services list will also get populated, so that you can select one of the services hosted in your server. In this example, I'll use the default HelloService.
Now click on Display tab. An empty graph will be shown as given below.



Step 6
Now, invoke HelloService multiple times (you can use Tryit tool or SOAPUI) and refresh the dashboard.
You will see that the Messages received in last minute graph is being populated.

Similarly, you could try with the other graphs as well.

WSO2 SOA Summer School - Security in SOA

Prabath Siriwardana, a colleague at WSO2, doing a webinar on Security in SOA on 2nd of July 2009.
You can register from here

Sunday, June 14, 2009

Importance of defect isolation

A problem well stated is half solved

True! A good bug report should provide with the information to reproduce the issue. It is QA tester's responsibility to specify the exact steps of bug recreation. Isolating the environment and conditions at which the issue occurred are extremely important components of a defect report.

Sadly I have seen some people ignore these important practices due to tight schedules and rush testing processes. No! In any case, even with management push towards quicker feedback of the products under test, ignoring these vital practices are totally unacceptable. Your bug report mirrors the professionalism of software QA testing job. Developers do not waste time or jump in to assumptions by reading your bug report. It provides all the necessary details. It consists of logs, screen shots when they are required.

A good QA tester must isolate the issue first. He never reports bugs just by seeing an exception in server console. He attempts multiple instances to recreate and isolate the issue. Some failures can be repeated easily but some requires more effort. Then prepare a detailed defect report.

As Cem Karner said, "there are no intermittent software errors. The problem may appear rarely but each time the exact conditions occur, the behavior will repeat".

More to follow....

Friday, May 1, 2009

Run time code coverage using Emma

Emma is a free java code coverage tool which measures and reports code coverage of java based products. The most important and usable factor of Emma is, its ability to measure code coverage during the application runtime. At WSO2, we have been searching for a tool to get QA test coverage of our middleware products. Automated QA tests are executed against the binary products. Therefore, source level unit test coverage does not help to identify the figures of QA test coverage. Emma was the best tool which satisfied our requirements.

The procedure is quite simple. Suppose you are going to get the coverage of a binary which obviously contains hundred of jars. First, you need to prepare a list of jars which requires to be instrumented. The list can be prepared easily in *nix environments as follows.

xargs -n 1 $JAVA_HOME/jre/bin/java -cp emma.jar emma instr -m overwrite -cp < jarlist.txt

This inserts tracking code to the jars listed in jarlist.txt.

Now, you should restart your application and Emma starts to gather coverage data. If you have an automated functional test suite, run it over the instrumented binary or test the product manually.


After completing the testing, stop your application. Now, we need to generate the coverage report. Issue the following command.

java -cp emma.jar emma report -r html -in coverage.em,coverage.ec

This generates an html report as shown below.





Currently, we are in the process of developing a selenium based automation framework and we use this test coverage mechanism to find out the components which require more tests.

Tuesday, April 28, 2009

How to deploy WSO2 WSAS-3.* on JBoss

WSO2 DOES NOT ENCOURAGE INSTALLING WSO2 APPLICATION SERVER (previously known as WSAS) ON TOP OF OTHER APPLICATION SERVERS. WSO2 HAS DECIDED TO DROP SUPPORT FOR WEBAPP DEPLOYMENT MODE OF THE WSO2 PLATFORM AND PRODUCTS.





WSO2 WSAS can be deployed on most of the application servers with a simple set of configuration steps. This post describes the steps to deploy WSO2 WSAS-3.* on JBOSS 5.*


Step 1

Download WSO2 WSAS-3.0.1 from here. Extract the downloaded zip into a directory. Copy conf, database, repository and resources directories in to a new folder. Here after, we will refer it is wsas-repo (i.e:- C:\wsas\wsas-repo)

Step 2
Lets refer to your jboss installation directory, JBOSS_HOME. Go to JBOSS_HOME\server\default\deploy directory and create a new folder, wso2wsas.war.
Now, copy wso2wsas-3.0.1\webapps\ROOT\WEB-INF to JBOSS_HOME\server\default\deploy\wso2wsas.war

Step3
We need to enable https in JBOSS. Therefore, edit JBOSS_HOME\server\default\deploy\jbossweb.sar\server.xml by editing the following entry. (This entry is commented out by default)

<!-- SSL/TLS Connector configuration using the admin devl guide keystore-->
<Connector protocol="HTTP/1.1" SSLEnabled="true"
port="8443" address="${jboss.bind.address}"
scheme="https" secure="true" clientAuth="false"
keystoreFile="C:\wsas\wsas_repo\resources\security\wso2carbon.jks"
keystorePass="wso2carbon" sslProtocol = "TLS" />

Make sure to give the exact location of wso2carbon.jks as highlighted above.

Step 4

We have done the configurations required inJBoss. Now, we must do the necessary configurations in a set of config files shipped with WSO2 WSAS. We will update carbon.xml, axis2.xml, registry.xml and user-mgt.xml which can be found at wsas-repo\conf directory.
First, open carbon.xml and update the ServerURL element as follows.

<ServerURL>https://localhost:8443/wso2wsas/services/</ServerURL>

Note that we have configured tomcat to run on 8443 port.
Save and close carbon.xml.

Open registry.xml and update DB URL as follows.
<url>jdbc:derby:C:/wsas/wsas-repo/database/WSO2CARBON_DB;create=true</url>

Now, open user-mgt.xml and update database URL as follows.

<url>jdbc:derby:C:/wsas/wsas-repo/database/WSO2CARBON_DB;create=true</url>

Make sure to specify the absolute path of the WSO2CARBON_DB in both of the above elements.

It is required to change the contextRoot in the service path of axis2.xml. Change it to wso2wsas.

<parameter name="contextRoot">/wso2wsas</parameter>

We must change the http and https ports in In Transports section of axis2.xml as follows.

<transportReceiver name="http"
class="org.wso2.carbon.core.transports.http.HttpTransportListener">
<parameter name="port">8080</parameter>

</transportReceiver>

<transportReceiver name="https"
class="org.wso2.carbon.core.transports.http.HttpsTransportListener">

<parameter name="port">8443</parameter>
</transportReceiver>

Step 6

We have completed the required configurations. Now, open a new command window and change the directory to JBOSS_HOME/bin.
Define an environment variable called CARBON_HOME and set the path to your wsas-repo directory.

In windows; set CARBON_HOME=C:\wsas\wsas-repo
In linux; export CARBON_HOME=\home\user\wsas\wsas-repo

Start JBoss from the same command window/shell.

WSO2 WSAS will be started successfully. You can access the management console using https:\\localhost:8443\wso2wsas\carbon

Friday, April 24, 2009

How to deploy a Java web service on WSO2 WSAS and secure it with Username token policy

I demonstrate how to deploy a java web service on WSAS and secure it with user name token policy.

Thursday, April 23, 2009

How to preserve the original WSDL when requesting ?wsdl of an Axis2 web service

I have noticed a lot of queries in Axis2 forums on keeping the WSDL unchanged when issuing ?wsdl of a particular Axis2 web service. This can easily be achieved by setting useOriginalwsdl parameter to true in services.xml. Then Axis2 shows the wsdl file placed at the META-INF directory of service archive when requesting ?wsdl

Suppose your Axis2 service archive (*.aar) includes a test.wsdl in the META-INF directory. Now, you deploy your Axis2 service and issue http://<host>:<port>/services/?wsdl.
Then, Axis2 generates a wsdl instead of your own wsdl placed in your service archive. How do you avoid this behavior?

Open your services.xml and add the following parameter.

<parameter name="useOriginalwsdl">true</parameter>

Now you will get the original wsdl when requesting ?wsdl of your service.
Simple.. isn't it?


Saturday, April 4, 2009

How to add FindBugs maven plugin to your project

FindBugs is a very useful static analyzer which inspects java bytecode for bug patterns. Static code inspection is important element in a good continuous integration process. Integrating FindBugs to your Maven build system is extremely simple as follows.

1. Add FindBugs maven2 plugin to the root pom of your maven project. You can add the plugin configuration element as a child of <reporting> element.

<reporting>

<plugins>

<plugin>

<groupId>org.codehaus.mojo</groupId>

<artifactId>findbugs-maven-plugin</artifactId>

<version>2.0</version>

<configuration>

<xmlOutput>true</xmlOutput>

<xmlOutputDirectory>C:\projects</xmlOutputDirectory>

</configuration>

</plugin>

</plugins>

</reporting>

Note: The xmlOutputDiectory is hard coded intentionally for demonstration purpose.

2. Go to the directory where the above pom.xml is placed and issue the following command.
mvn findbugs:findbugs

This will generate an XML report in the specified output directory. Here is an excerpt from such report.

<file classname="org.test.ExampleService">

<BugInstance type="OBL_UNSATISFIED_OBLIGATION" priority="Normal" category="EXPERIMENTAL" message="OBL: Method org.test.ExampleService.archiveFile(String, String) may fail to clean up stream or resource of type java.io.InputStream" lineNumber="69" />

<BugInstance type="OBL_UNSATISFIED_OBLIGATION" priority="Normal" category="EXPERIMENTAL" message="OBL: Method org.test.utils.ArchiveManipulator.extract(String, String) may fail to clean up stream or resource of type java.io.InputStream" lineNumber="114" />

<BugInstance type="OS_OPEN_STREAM" priority="Normal" category="BAD_PRACTICE" message="OS: org.test.utils.ArchiveManipulator.extractFromStream(InputStream, String) may fail to close stream" lineNumber="148" />

-------

<BugInstance type="RV_RETURN_VALUE_IGNORED_BAD_PRACTICE" priority="Normal" category="BAD_PRACTICE" message="RV: org.test.utils.ArchiveManipulator.extractFromStream(InputStream, String) ignores exceptional return value of java.io.File.mkdirs()" lineNumber="124" />

</file>

Thats all! For more information about plugin usage and configuration parameters, havea look at the plugin home page.

Thursday, March 26, 2009

Automated testing of wso2 products using Selenium


I have never been a fan of open source UI test automation tools due to the annoying issues of majority of them. Most of the tools provides you with a good first user experience however fails when try to use in advanced use cases. At WSO2, we have been looking for a test automation tool during the last few years. Due to the tight release schedules, we were not able to focus much on researches.
At the end of 2008, WSO2 started to build its SOA product suite based on revolutionary Carbon platform and a new JSP based UI framework has been designed. When I got the initial builds of new WSO2 carbon products, I was curious about the possibility of automating user interface. I tried with one of the tools which we have tried once but never got a chance to continue working on. That is, Selenium! For me, it is the best open source tool I have used so far in my career.
After the releases of WSO2 carbon based products, we have started to automate UI and functional use cases using Selenium. We are making a rapid and steady progress so far with this great tool.

We use Selenium RC with Junit. All the test are written using Junit. WSO2 products are built using maven2 and eventually our test framework will be integrated to build system. We have already used maven selenium plugin and surefire plugin to integrate our tests with maven. With the power and high flexibility of Selenium we are in a good position of cross browser testing.

While automating the product UIs with selenium, we had to overcome some blocking issues but thanks for the materials available in openQA forums and some nice blogs, we were able to resolve most of them. I'd appreciate Selenium team for their great vision and innovativeness of developing such a helpful free web automation tool.

Thursday, March 19, 2009

Adding BPEL features to WSO2 WSAS/ESB

A few days back, WSO2 has released carbon feature packs which allow users to integrate various functional components into their existing WSO2 products. I blogged about plugging in service hosting components into ESB while we were preparing for carbon release. With the carbon feature packs, now it is much more easier to add the functionalities what you want.

WSO2 BPS provides the facilities to execute business processes written using the WS-BPEL standard. BPEL feature pack enables the business process management inside your WSO2 WSAS or ESB instances.
Let's see how BPEL features can be added to WSO2 WSAS or ESB.

Pre-requisites:
Install WSO2 WSAS-3.0.1 or WSO2 ESB-2.0.1

Step 1
We are hoping to install BPEL features into WSAS or ESB. Therefore, download BPEL feature pack from here.

Step 2
Unzip the downloaded feature pack into a directory in your file system (suppose it is $BPEL_feature_pack_home)
You will see two sub directoris inside the extracted zip file, plugins and repository.

Go to $BPEL_feature_pack_home/plugins/ directory and copy all the jars to WSAS_HOME/webapps/ROOT/WEB-INF/plugins/ directory. (WSAS_HOME is the root directory of your WSO2 WSAS instance)

Then, go to $BPEL_feature_pack_home/repository directory and copy the contents to WSAS_HOME/repository.

Step 3
Restart WSO2 WSAS and access management console. You will see the BPEL features shown in the left menu as follows.



Thats it. We have installed BPEL features into WSAS. You could follow the same steps to install BPEL features into WSO2 ESB.

Thursday, February 19, 2009

Performing QA with last minute code changes




Changes are inevitable at the last moments of most projects. There are urgent requirements to do such changes and there will be situations where you
must do some critical fixes before shipping the product. In any case, both development and QA teams must be in a common understanding on how such changes affect the stability of the AUT (Application under test).
Sometimes, it will be required to repeat a complete functional test cycle after a significant change. In such cases, sufficient time must be allocated to do a full round of functional testing.
Or else, everyone (both development and QA) should take the responsibility if something goes wrong.
It is a common practice in most organizations to transfer responsibility to QA teams when clients find issues in a product after a release, which is not always valid in agile processes where everyone test and contribute to quality assurance regardless of their title/role playing in the project.
After doing a significant change at the last moment without providing enough time to complete the testing on affected areas, there is no point to blame QA. Everyone should take the responsibility.
This is one of the weird situations most QA teams come across regardless of the process being followed. With better understanding about the tasks and responsibilities of each other, project teams can avoid these concerns. Otherwise, rigid hard core processes must be followed although they are not always realistic.
After all, each team member should understand that QA is not a trivial activity. It takes time and effort to setup and configure test environments, uncover bugs, reproduce them in different platforms, report through defect tracking systems, verify the reported bugs in new builds, ensure the issues are not regressed.
A few months back, Krishantha posted a nice blog entry about how last minute changes affect software QA testing which is a good reference for anyone interested in this.

Switching wso2 carbon server to maintenance mode

When wso2 carbon server (WSO2 WSAS, ESB, Registry and BPS) is running in production environments, it may be required to perform some essential upgrades without shutting down the server.
[WSO2 Carbon is the base platform for all WSO2 Java products. wso2 carbon server refers to any of WSAS, ESB, Registry or BPS server]

WSO2 Carbon based products are equipped with JMX based monitoring and management facilities, through which you can switch to maintenance mode.

Step 1
In order to enable JMX management, you must uncomment the JMX port element in CARBON_HOME/conf/carbon.xml

<Ports> <!-- The JMX Port --> <JMX>9999</JMX> </Ports>

CARBON_HOME is the directory where you extracted wso2wsas-3.0, wso2esb-2.0, wso2-registry-2.0 or wso2-bps-1.0 binary distributions.

Step 2

Start your WSO2 carbon server (WSAS, ESB, Registry or BPS).
You will notice that the JMX service URL will be printed in the startup console as follows.



Step 3

You can use JConsole as the client for JMX monitoring and management. Start command prompt (or shell in linux), type Jconsole and hit enter. JConsole:Connect to Agent window will be popped up.
Enter JMX url (service:jmx:rmi:///jndi/rmi://YourHost:9999/server)
Enter admin as user name and password. Note that, any user with admin privileges can log in to JMX.
Click on Connect.

Select MBeans-->org.wso2.carbon-->ServerAdmin-->Operations
You will see the following server admin operations.



Step 4

Suppose you have a web service which is in the process of responding to a client. Now, you may want to do some upgrades in the server without shutting it down.
Click on startMaintenance() button in the jconsole.
Now server is being running on maintenance mode. It does not accepts service requests in this mode. Your client application may get "org.apache.axis2.AxisFault: Connection refused" error.

After server upgrade is done, click on endMaintenance() button. Server will be switching back to normal mode. You will notice that the message transmission of your client will be resumed.

Tuesday, February 17, 2009

How to deploy WSO2 BPS on Apache Tomcat

WSO2 DOES NOT ENCOURAGE INSTALLING WSO2 BPS ON TOP OF OTHER APPLICATION SERVERS. WSO2 HAS DECIDED TO DROP SUPPORT FOR WEBAPP DEPLOYMENT MODE OF THE WSO2 PLATFORM AND PRODUCTS.





WSO2 Business Process Server (BPS) -1.0 is the latest member of WSO2 SOA platform. I have demonstrated a basic scenario using WSO2 BPS standalone distribution in a previous blog post. WSO2 BPS (and all other carbon based products) can be deployed in most of the servlet containers with a few configuration steps. Lets deploy WSO2 BPS on Apache tomcat 6.*.

Step 1
Download WSO2 BPS-1.0 from here. Extract the downloaded zip into a directory. Copy conf, database, repository and resources directories in to a new folder. Say it is carbon-repo (i.e:- C:\bps\carbon-repo)
Also, create a new directory, lib\extensions under carbon-home.

Step 2
Lets refer to your tomcat installation directory, CATALINA_HOME. Go to CATALINA_HOME\webapps directory and create a new folder, bps.
Now, copy wso2bps-1.0\webapps\ROOT\WEB-INF to CATALINA_HOME\webapps\bps

Step3
We need to enable https in tomcat. Therefore, edit CATALINA_HOME\conf\server.xml by adding the following entry.

<Connector port="8443" maxHttpHeaderSize="8192"
maxThreads="150" minSpareThreads="25" maxSpareThreads="75"
enableLookups="false" disableUploadTimeout="true"
acceptCount="100" scheme="https" secure="true" SSLEnabled="true"
clientAuth="false" sslProtocol="TLS"
keystoreFile = "C:\bps\carbon-repo\resources\security\wso2carbon.jks"
keystorePass="wso2carbon"/>

Make sure to give the exact location of wso2carbon.jks as highlighted above.

Step 4
We have done the configurations required in tomcat. Now, we must do the necessary configurations in a set of config files shipped with WSO2 BPS. We will update carbon.xml, axis2.xml, registry.xml and user-mgt.xml which can be found at carbon-repo\conf directory.
First, open carbon.xml and update the ServerURL element as follows.

<ServerURL>https://localhost:8443/bps/services/</ServerURL>

Note that we have configured tomcat to run on 8443 port.
Save and close carbon.xml.

Open registry.xml and update DB URL as follows.
<url>jdbc:derby:C:/bps/carbon-repo/database/WSO2CARBON_DB;create=true</url>

Now, open user-mgt.xml and update database URL as follows.

<url>jdbc:derby:C:/bps/carbon-repo/database/WSO2CARBON_DB;create=true</url>

Make sure to specify the absolute path of the WSO2CARBON_DB in both of the above elements.

It is required to change the contextRoot in the service path of axis2.xml. Change it to match with the web application directory name we have given in step2. In our case, it is bps.

<parameter name="contextRoot">/bps</parameter>

We must change the http and https ports in In Transports section of axis2.xml as follows.

<transportReceiver name="http"
class="org.wso2.carbon.core.transports.http.HttpTransportListener">
<parameter name="port">8080</parameter>

</transportReceiver>

<transportReceiver name="https"
class="org.wso2.carbon.core.transports.http.HttpsTransportListener">

<parameter name="port">8443</parameter>
</transportReceiver>

Step 5
We have almost completed the required configurations. Before starting tomcat with those changes, we need to do one more change. Due to a bug in BPS-1.0, we must copy org.wso2.carbon.geronimo.jta.1.1.spec-1.1.jar (which is available at the lib\extensions directory of the WSO2 BPS binary distribution) to carbon-repo\lib\extensions and CATALINA_HOME\webapps\bps\WEB-INF\lib directories.

Step 6
Now, open a new command window and change the directory to CATALINA_HOME/bin.
Define an environment variable called CARBON_HOME and set the path to your carbon-repo directory.

In windows; set CARBON_HOME=C:\bps\carbon-repo
In linux; export CARBON_HOME=\home\user\bps\carbon-repo

Start tomcat from the same command window/shell.
catalina.bat run

WSO2 BPS will be started successfully. You can access the management console using https:\\localhost:8443\bps\carbon

Sunday, February 15, 2009

Visits to this blog



The success of this blog can easily be determined by looking at the above summarized report of visitors who accessed during the last year. I have started this blog to discuss/share my ideas on software quality assurance and my subject domain, SOA/web services. The majority of the posts were written to help users to solve simple issues which were not documented anywhere. I do not use this blog to discuss my personal life, politics etc..
I was able to build a community around my blog during the last year which encouraged me to write more and more useful posts. Sometimes, I could not maintain a consistent blog post publishing rate due to the tight project release deadlines. However, it did not affect the visits of regular user base.
With the releases of WSO2's revolutionary SOA platform, Carbon, there will be a lot of things to be demonstrated. Stay tuned.. This blog will be updated frequently with more and more how-tos..

Friday, February 13, 2009

A quick look at WSO2 Business Process Server (BPS)

WSO2 Business Process Server (BPS) is the newest member of WSO2 SOA product suite. It is developed on top of the revolutionary WSO2 Carbon platform hence the components of WSO2 ESB, WSO2 Web services application server (WSAS) can easily be plugged in.
WSO2 BPS provides the facilities to execute business processes written using the WS-BPEL standard. It uses Apache ODE as process server engine.
I'm going to demonstrate how a simple BPEL package will be deployed in WSO2 BPS and some of the features such as process instance creation and process summary statistics.

Step 1
Download WSO2 BPS-1.0 from here. Extract the downloaded zip into a directory. We will refer to the extracted location as BPS_HOME

Step 2
Start business process server by running wso2server.bat{sh} which can be found at BPS_HOME/bin

Step 3
Access BPS management console using https://localhost:9443/carbon. Log in to management console using the default administrator credentials, admin/admin
BPS Home page will be displayed as follows.



Step 4
We are going to deploy a new BPEL package. BPEL package is a ZIP archive with all the relevant deployment artifacts. BPEL package should contain the deployment descriptor, one or more process definitions(.bpel or .cbp), WSDL and XSDs. You may find more information about these artifacts in Apache ODE user guide.
In this demonstration, I will use a sample BPEL package (HelloWorldNew.zip) used for testing purposes. You can download it from here.
Now, select Business Processes --> Add BPEL in the left navigation menu of WSO2 BPS management console. You will be directed to New BPEL Package page. Browse the downloaded HelloWorldNew.zip file in your file system and click on upload.
You will see the confirmation message if the deployement is successful.

Step 5
We have completed adding a new BPEL package. You can find the deployed package in the Deployed Packages page as follows.



Step 6
When you upload a new BPEL package, the associated business process will be created and will be listed in Deployed Processes page. You can find the process definition and more details of the process by clicking on the process ID.



Step 7
When a new BPEL package is deployed, the services which are defined as partner links in the process definition (services participating in a particular BPEL process) will be listed in the Deployed Services page as shown below. You will notice the HelloWorldNew service at the top of the table.



Step 8
Now we can create process instances by invoking this HelloWorldNew service. The simplest way of invoking the service is using "Try this Service" feature associated with the service. Click on Try this Service link in HelloWorldNewService.
You will be directed to Try the HelloWorldNewService service page where you can give any string value as input. Click on Process button to invoke the service.
With different string inputs, invoke the service few more times.

Step 9
After invoking the service, select Business Processes --> Instances in the left menu.
You will see the generated process instances as shown below.



With WSO2 Business Process Server (BPS), you can secure processes using WS-security and enable reliable messaging with minimum configuration steps. I will demonstrate these QOS (quality of service) features in a future post.

For more information about Business process server, access WSO2 BPS home page at WSO2 Oxygen Tank.

Thursday, February 5, 2009

WSO2 Elevator Pitch

Short introduction to WSO2 from the founders....

Wednesday, February 4, 2009

QA does not exist if at least a lightweight process is not adopted

There are obvious differences between software quality assurance (SQA) and software testing. SQA is a much more systematic and process based approach. You can't expect any engineer to act SQA role any time. That needs experience, QA mind set and a lot more. That is true whether you follow traditional or agile development approach.
Having said that, I want to emphasize the fact that there is no QA if you do not follow at least a simple development process. QA faces a chaotic situation and everything is screwd up.

More on QA practices to follow......

Sunday, January 11, 2009

Get your Axis2 service or module archives validated using WSO2 tools

When creating Axis2 service archives (AARs) or module archives (MARs), it is important to adhere to the defined archive structure and standards. With the help of automated tools, you can validate these archives. WSO2 service and module validators can be used to validate your service or module archives freely in an efficient manner.
These tools are shipped as components inside WSO2 WSAS and hosted in WSO2 Oxygen tank developers portal as well.

If you have WSO2 WSAS binary distribution, validating aar or mar files is a simple process as given below.

1. Access WSAS management console using http://localhost:9443/carbon
2. Select Service Validator in the left menu



3. Select your axis2 service archive (aar file) and click on Validate AAR
4. Validation report will be shown as given below.



If WSAS binary distribution is not available, you can get your service or module validated using the online validator hosted in WSO2 Oxygen tank.

1. Go to http://wso2.org/tools
2. Click on Service Validator link under Validators section

you will be directed to the above AAR validator UI where the service archive can be validated.

Similarly, module archives (MARs) as well as service and module descriptors (services.xml. modules.xml) can be validated.