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

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?