Monday, September 7, 2009

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.