WSO2 WSAS 3.1

Continuing my blogs about the latest Carbon releases, here are the details about WSO2 Web Services Application Server 3.1. Its based on Carbon 2.0.

Before I go into the details of the enhancements, I'd like to explain a little about what WSAS is. The question we often get asked is: "Is WSAS a competitor to a J2EE application server?". The answer is both yes and no. Yes, WSAS offers some of the same capabilities as a J2EE application server. It provides a managed runtime for hosting code, in this case Java Services. You can also deploy AJAX applications and REST services. You can write services as Pure Java (POJO), EJBs, JSR181 annotated classes, or Axis1 and Axis2 services.

Why No? Well, WSAS can be run on top of any J2EE server, and our customers use it on top of JBoss, Tomcat, WebSphere and WebLogic. We aren't trying to compete on hosting J2EE applications - what we do compete on is hosting services.

You can use those servers to host Services, so why would you choose WSAS? WSAS offers a huge amount of value add because we focus solely on what makes a good service container. Let me give you some simple examples:

• Graphical security configuration: we have the most comprehensive yet simple approach that allows you to easily configure and manage permissions, roles, WS-Security encryption, signature. There is a built-in STS and full support for WS-Trust and SecureConversation.
• Full XKMS service key management server.
  
• TryIt: we offer a built-in, instant dynamic test client for any WSDL service
• Full support for HTTP, SOAP, JMS and multi-transports with zero-coding. Your services are automatically exposed via HTTP POST/GET, SOAP, JMS all with a single codebase.
• Caching, throttling, and statistics on every service, with zero coding

I won't go on, because you can read the feature list. But the core idea is that we focus solely on what makes a really really good service container.

What is special about WSAS 3.0 and now 3.1 is the ability to plug in new features using OSGi. Here is a simple example. Suppose you have a deployed working service, but you need to support a different XML format as well. Of course you could rewrite the service with logic to handle this. Or you could write an Axis2 handler if you are an Axis2 guru. But with WSAS 3.1 you have a cleaner, simpler and more effective approach.

Using p2 (the Equinox provisioning model), you can go to the web repository and install the mediation feature. This pulls down the OSGi bundles from the web, validates all the dependencies are in place, and adds the new capability into the system. Now when you go into WSAS you will have a new option in the UI to enable Mediation against any service. Now you can use XSLT or even simple Javascript/E4X to write a conditional transform that ensures all messages match the existing service logic. Its like having a mini-ESB embedded into your service container, but without the overhead of managing it.

p2 is the Eclipse Update Manager, except based in the core OSGi container. This means that it gives Carbon, and WSAS, the ability to control how features are deployed (and undeployed) in a very clean, effective way. It really does bring properly componentized middleware.

In addition to the new p2 capability, WSAS 3.1 also has one big ease-of-use feature - auto-wrapping JARs as OSGi. If you want to deploy a JAR you simply copy it into the right directory and we take care of OSGi for you.

Finally, this release is based on Axis2 1.5, which has a huge number of enhancements and bug-fixes over Axis2 1.4, as well as the associated Rampart and Sandesha2 releases.