How to run WSAS-v3.0-beta2 on Apache Tomcat

WSAS-v3.0-beta2 is the first WSAS release which runs on the brand new WSO2 Carbon platform. Just like the previous releases of WSAS, this release also capable of running as a standalone server and on top of other well known application servers. A step by step procedure to run it on Apache Tomcat is explained below.

Step 1 : Download WSAS-v3.0-beta2 binary distribution and extract it (say you extracted it to /home/foo/wsas). If you don't have an already extracted Apache Tomcat server, download and extract it too (say you extracted it to /home/foo/tomcat). Tomcat version 5.5.x or higher is recommended.

Step 2 : Copy 'repository', 'resources' and 'conf' directories from extracted WSAS folder and paste them into a separate folder (say /home/foo/wsas-home).

Step 3 : Set an environment variable of the name CARBON_HOME with the above folder path as the value (according to above example, CARBON_HOME=/home/foo/wsas-home). Then set the environment variable CATALINA_HOME with extracted tomcat folder path as the value (CATALINA_HOME=/home/foo/tomcat).

Note : If you want, you can use the folder to which you extracted WSAS (/home/foo/wsas), as WSAS_HOME without copying the above folders into a separate location.

Step 4 : Create a folder inside the 'webapps' folder (say with the name 'wsastest') of extracted Tomcat and copy the WEB-INF folder which is inside /webapps/ROOT folder of the extracted WSAS in to the created folder (copy /home/foo/wsas/webapps/ROOT/WEB-INF folder into /home/foo/tomcat/webapps/wsastest folder).

Step 5 : Open the server.xml file which is inside the conf folder of the extracted Tomcat (/home/foo/tomcat/conf/server.xml). Insert the following 'Connector' entry inside the 'Service' tag to set the HTTPS port.

<
Connector port="8443" maxHttpHeaderSize="8192"
maxThreads="150" minSpareThreads="25" maxSpareThreads="75"
enableLookups="false" disableUploadTimeout="true"
acceptCount="100" scheme="https" secure="true"
clientAuth="false" sslProtocol="TLS"
keystoreFile = "/home/foo/wsas-home/resources/security/wso2carbon.jks"
keystorePass="wso2carbon"
/>

Note : You can use any port instead of 8443 and you have to correctly set the path to 'keystoreFile' according to your CARBON_HOME.

Step 6 : Open the carbon.xml file which is inside CARBON_HOME/conf folder. It contains a ServerURL entry as shown below (line 47).
https://localhost:9443/services/
Edit the port and add the correct context. According to the example above, it should be as follows.
https://localhost:8443/wsastest/services/

Step 7 : Open the axis2.xml file which is inside CARBON_HOME/conf folder. Go to line number 145 and change the http port to Tomcat http port which is 8080 (default port).
Then go to line number 160 and change the https port to what you have given above (8443).

Step 8 : Open a terminal and move into the bin folder of the extracted Tomcat and start the server using the following command.
On Windows : catalina.bat run
On Linux : sh catalina.sh run

Step 9 : Open your web browser and access the URL https://localhost:8443/wsastest/carbon. You will be directed to the WSAS home page through which you can log into the system.

Known Issues

• When the server starts up, you will see and exception regarding a data services sample. Please ignore it for now.
• Shutdown/restart option provided in the WSAS UI doesn't work in Tomcat. Therefore please use the shutdown option of Tomcat to shutdown and restart WSAS.
  

WSO2 WSAS 3.0-beta2 Released

The WSO2 WSAS & WSO2 Carbon team is pleased to announce the release of version 3.0-beta2 of the Open Source WSO2 Web Services Application Server (WSAS).

This release is available for download at [1]. WSAS is based on revolutionary the WSO2 Carbon [2] framework, Middleware a la carte'. Now you can adopt the middleware to suite your enterprise architecture. All the major features have been developed as pluggable Carbon components.

New Features
------------
1. Based on the OSGi based WSO2 Carbon architecture. This is a unification of all Java based products from WSO2. Now you can have features from the lightweight super-fast WSO2 ESB & the super-cool WSO2 MashupServer, running on your WSAS instance. You can mix and match the functionality you require according to requirements of your enterprise. The middleware can be adopted to your architecture. You could even extend the middleware by developing your own middleware components.

2. Enhanced admin UI
3. Extensible server admin framework
4. Separable frontend & backend - a single frontend server can be used
to administer several backend servers simultaneously
5. Various bug fixes and enhancements.

The full feature list is available at
http://wso2.org/projects/wsas/java/features

How to Run
----------
1. Extract the downloaded zip
2. Go to the bin directory in the extracted folder
3. Run the wso2server.sh or wso2server.bat as appropriate
4. Point you browser to the URL https://localhost:9443/carbon/
5. Use "admin", "admin" as the username and password.
6. If you need to start the OSGi console with the server use the property -DosgiConsole when starting the server

Known issues
------------
1. Data Services definition wizard is not available


All known issues have been filed here [3]. Please report any issues you find as JIRA entries.

Thanks
WSO2 Carbon & WSO2 WSAS team

1. http://wso2.org/downloads/wsas
2. http://wso2.org/projects/carbon
3. https://wso2.org/jira/browse/CARBON

WSO2 WSAS 3.0 - Coming Soon!

Expect the WSAS 3.0 release in mid December this year. The most significant feature in this release is going to be the fully componentized architecture. This new release is going to be based on WSO2 Carbon, which is the base platform for all future Java products from WSO2. WSO2 Carbon is based on OSGi. All the major features have been bundled into Carbon components which are in fact OSGi bundles. All major middleware vendors, including WSO2, have recognized the power of OSGi and are migrating their products towards an OSGi based architecture.

What is the value & benefit this is going to give the WSAS users & in general the Carbon users? Well, there are several.

Pick & Choose
1. Ability to select only the bare minimum functionality needed. You can simply remove unnecessary functionality
2. Ability to extend the server's functionality. For example, if you have a running WSAS instance, and need some service mediation capabilities enabled or BPEL capabilities, you simply need to drop in the relevant Carbon components into the Carbon plugins directory. You do not need to restart the server.

In short, you can mix & match whatever the functionality you desire.

Improved Availability - Server Restarting Minimized
Let's say you have enabled data services support through the Carbon Data Services component, and that your server is running in a production system. You need to deploy a data service which talks to a MS-SQL Server RDBMS, but have not included the JDBC driver in the WSAS instances classpath. In a traditional deployment, you'd need to drop the JDBC driver jar file into the classpath & restart the server, thereby impacting the availability. With the Carbon based approach, restarting is no longer required. Carbon takes care of wiring in the new MS-SQL Server JDBC driver.

Extend the server's functionality through custom components
The users can write their own components & extend the functionality of a Carbon based server.

What are the benefits this approach gives to the middleware vendor? The greatest benefit is having the ability to go from concept to solution in the minimum possible time period. For example, the BPEL Carbon was developed within 3 weeks! We did not have to rethink how to secure the BPEL processes & provide other enterprise features. These were already available as Carbon components. This benefit is also directly passed on to the Carbon user since they can expect to get new functionality within the shortest possible period.

What is an App Server?

I recently came across an interesting article on TSS aptly titled "What is an App Server?"

The traditional mindset has been, App Server = J2EE App Server, but that is changing now. As mentioned in that article,"an application server provides an environment where applications can run, no matter what the applications are or what they do"

Some people have been questioning whether it is correct to call WSAS an App Server since it does not support any of the JEE(J2EE) specs. This article on TSS should provide good answers to their questions.

System calls to Linux kernel

System call provides an interface to user-space processes to interact with kernel. This interface gives applications to access hardware and other operating system resources. This article gives you a good introduction to implement system calls in i 386 architecture.

It seems that _syscallX macros have been removed from "unistd.h". Hence, we have to use syscall available from libc.

Running WSAS on WebLogic

on

Amila has written a blog post about running WSAS on WebLogic. WebLogic uses its own StAX parser implementation. Due to some issues in the way Axiom uses the underlying StAX parsers, some of the functionality did not work properly when WSAS or Axis2 were deployed on WebLogic. Now, Amila has fixed Axiom so to handle this issue. For more details, see Amila's blog post.

Increasing Axis2 Popularity

Apache Axis2, the core of WSO2 Web Services Application Server (WSAS), has been showing exponentially increasing popularity growths. for more details, see my blog post on the exponentially increasing Axis2 popularity.