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.

Domain hosting

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