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

Wednesday, December 31, 2008

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"

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).
Edit the port and add the correct context. According to the example above, it should be as follows.

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

Wednesday, December 24, 2008

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

How to Run
1. Extract the downloaded zip
2. Go to the bin directory in the extracted folder
3. Run the 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.

WSO2 Carbon & WSO2 WSAS team


WSO2 WSAS 3.0 - Coming Soon!

Friday, November 7, 2008

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?

Tuesday, September 23, 2008

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

Saturday, September 20, 2008

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

Tuesday, September 16, 2008


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

Saturday, August 30, 2008

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.

Where does WSAS fit into your enterprise deployment?

Saturday, August 23, 2008

Figure1: Open source SOA product deployment

Where does WSAS fit-in in your enterprise deployment? Figure1 shows how WSAS as well as other open source SOA products from WSO2, The Open Source SOA Company, fit into a typical enterprise deployment. Of course, this is only one of the ways in which WSAS as well as other open source SOA products from WSO2 can be deployed. In fact the above deployment diagram shows how one of largest managed care organizations has deployed WSAS as well as the other SOA products.

Figure 2: Deployment of WSO2 WSAS & WSO2 ESB for High Availability

An enterprise deployment cannot afford to have any single points of failure. Even with some degree of degraded performance, the system should continue to function correctly, until such time that it can be brought back to full operating capacity. Figure2 depicts how a 2-node WSO2 ESB cluster fronts a 2-node WSO2 WSAS cluster. WSO2 WSAS is used to expose some existing business logic running on mainframes as Web services, as well as to expose some enterprise data as Data Services. WSO2 WSAS supports POJO services, whereby POJOs containing the business logic, like in this case, can be easily exposed as Web services. In fact, this is the path take by most enterprises which begin to SOA enable their systems. It is also common for some of the business logic of such systems to reside in databases in the form of stored procedures. WSO2 Data Services running within WSAS enables the exposing of data & stored procedures as services. Of course, ideally the enterprise architects have to clearly define the contracts when designing the system before any implementation is carried out, but the real-world situation is that most companies have already invested large sums of money into their software systems, and cannot afford to throw all that away and start from scratch. So the meet-in-the-middle approach is to first expose some of the existing logic as services, and then gradually refine the systems to come up with clean contracts. Newer components in the system can do it the proper way by starting by defining clean contracts. WSAS supports the contract first approach for this purpose, where the architects will write WSDLs defining the proper interfaces, and subsequent development work will be based on these WSDLs.

For more details on how WSAS as well as other open source SOA products from WSO2 can fit into your enterprise, see this case study by Asankha Perera who is the Software Architect and Product Manager of WSO2 ESB

Security features of WSO2 WSAS

Monday, August 18, 2008

One of the main advantages of WSO2 WSAS is it’s built in security features. They can be very easily configured using the web administration console.

  • SSL Support
    WSO2 WSAS has out of the box SSL support. All you need to do is change the WSAS default SSL certificate with your certificate which you may have purchased from a certificate authority or you can even use a self signed certificate.
  • WSAS Security Configuration
    WSAS Security Configuration consists of WS–Security Policies for most commonly used transport level and message level security scenarios. These policies are based on security requirements such as Authentication, Integrity, Confidentiality, Non-repudiation, Message Freshness and combinations of them. There are policies which optimize securing multiple messages using WS – Secure conversation and also policies which allow trust brokering through WS-Trust. These default policies can be further tweaked to suit custom scenarios using the built in policy editor.
  • User Management and Key Store Management
    WSO2 WSAS provides user management features such as adding users, deleting users and changing user passwords through the web administration console. It also allows users to be grouped in to roles. Set of users or roles can be easily associated with a web service for Authentication.
    WSO2 WSAS also provides key store / certificate management features. WSAS can handle both JKS and PCKS12 keys stores. Using the WSAS administration console, we can upload key stores, view the content of a key store, import certificates to a key store as trusted certificates, remove certificates from key store and remove certificates from existing key stores.
  • WSAS Security Token Service (WSAS STS)
    WSO2 WSAS comes with a built in Security Token Service built on top of WS-Trust protocol which can be used to issue SAML tokens. Security Token Services can be used to broker trust between two untrusted parties when both parties have a trust relationship with the Security Token Service. WSAS STS supports all the four bindings defined in the WS – Trust that is Issue binding, Validate binding, Renew binding and Cancel binding.
  • WSO2 XKMS (XML Key Management Specification) service
    WSO2 WSAS also ships a inbuilt XKMS trust web service. Main objective of XKMS trust web services is processing and management of PKI-based cryptographic keys. This allows web services to delegate the key processing functionality to XKMS service reducing the complexity and making it more manageable.
  • WSO2 Mex and WSO2 XFer modules
    WSO2 Mex (implementation of WS-MetadataExchange) and WSO2 XFer (WS-Transfer) are two modules that ship with WSO2 WSAS which supports metadata exchange. These modules can be used to exchanges metadata about web services such as policies, WSDLs, schema specially when you want to implement web services federation.
  • WSO2 POX (Plain Old XML) security handler
    WSO2 WSAS allows RESTful web service invocations to be protected with HTTP Basic Authentication via WSO2 POX security handler. This is integrated with the user management.

Tooling capabilities of WSO2 WSAS

Friday, August 15, 2008

WSAS comes with several tools that are useful to Web service developers as a whole(& especially to developers using Axis2).
Some of them are,
  • WSDL2Code generator - Give us your WSDL(online WSDLs are also supported) & we can generate both service & client side Java code for you.
  • Java2WSDL (WSDL View) - Generate/View WSDLs from Plain Old Java (POJO) Web services
  • WSDL Converter - Still running on WSDL 1.1? convert it to 2.0 using our WSDL Converter
  • Try It - Give us the URL of your WSDL & we generate a UI through which you can call the service
  • AAR Validator - Validate your Axis Service Archives & services.xml

WSAS Integrates leading Apache WS Projects

WSO2 WSAS packages a number of popular Apache Web services components. Seamlessly integrating these components in not a trivial task for a Web service developer. WSO2 WSAS takes this burden off the shoulders of the Web service developer and provides a clean and simple interface.

The figure above clearly shows the relationship between WSO2 WSAS and other Apache WS Components, as well as some other popular Open Source components.

At the core of WSO2 WSAS is the popular Apache Axis2 Web services engine, which has proved to be one of the fastest Java Web service engines. Apache Axis2 has an extensible messaging engine architecture, which enables plugging-in of other quality of service modules (QoS). Apache Addressing, Apache Rampart, Apache Rahas and Apache Sandesha2 are such quality of service modules which are included in WSO2 WSAS. These QoS modules also seamlessly plug-in to Apache Axis2. These QoS modules implement the most popular and widely used WS-* standards; hence they have been prominently shown in the diagram. Needless to mention, security & relaibility are two essential aspects of any enterprise deployment. Rampart & Rahas provide implementations of WS-Security, WS-Trust & WS-SecureConversation. Sandesha2 is an implementation on WS-ReliableMessaging.

Apache AXIOM is the default XML Infoset representation used in WSAS. One of the reasons for the high performance of WSAS is the usage of a pull-based XML object model. Apache Neethi is the WS-Policy framework. In addition, WSO2 WSAS also bundles Apache XMLSchema which provides utilities for XML Schema manipulation, and Apache WSS4J, which contains implementations XML Security specifications as well as useful security utilities.

What is WSAS?

WSO2 Web services application server (WSAS) is a Web services engine powered by Apache Axis2. WSO2 WSAS provides a secure, transactional and reliable runtime for deploying and managing Web services.
It is not a JEE application server, rather a platform for developing and deploying Web services, using any standard Java application server out there. WSO2 WSAS is a truly open source product released under Apache License v2.0

The key feature is the management console. You also have the benefit of world class development and production support from WSO2 Inc.

It is battle tested, production hardened and quality guaranteed.

Try it today and experience the power of SOA tooling from WSO2.