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?

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

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.

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

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....

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.