Introduction

As a part of the third generation of Web Services, Apache Axis2 aims to implement a high performance web service engine that incorporates the advancements made on the Web Services stack over the last few years. Following are the key features of Axis2:

1. New XML Object Model (AXIOM)
2. Messaging based core
3. Pluggable data binding
4. Improved deployment model

This article focuses on the Axis2 deployment model and details its bouquet of features. This improved model provides a simple and easy service and deployment mechanism.

The Axis2 Deployment Model

Previous versions of Axis failed to address the user friendliness factor involved in the deployment of a web service. In Axis 1.x, the user has to invoke the admin client manually and update the server classpath, and restart the server to apply the changes. This cumbersome deployment model was a definite barrier for beginners. Axis2 is engineered to overcome this drawback and provide a flexible, user-friendly, high demand deployment mechanism.
The Axis2 deployment model focuses on a J2EE like deployment mechanism where the user bundles all the class files and library files together as an archive file, and drops it into a specific directory in the file system. Therefore in Axis2, a web service can deploy as a service archive file (that is, an axis archive file with a .aar file extension, which is really just a JAR file). Further, Axis extensible modules like reliable messaging and WS-security can be deployed as a module archive (that is, an axis file with a .mar file extension, which is really just a JAR file). The most convenient feature of the new model is service hot deployment and service hot update, which can be used to easily deploy a new web service and update an existing web service, all without shutting down the web server.

<server name="AxisJava2.0">

    <parameter name="hotdeployment" >true</parameter>

    <parameter name="hotupdate" >true</parameter>

    ......

    .......

    ........

    

</server>

The Axis2 Repository

The repository is a folder or a directory in the file system and the deployment search mechanism is always limited to inside the repository. So the deployment module can only load and read files inside the repository. The repository includes two reserved sub directories – services and modules. To deploy a web service, drop the service archive file into the services sub directory. To deploy a web services module (WS module), drop the module archive file into the modules sub directory. Figure 1 is a pictorial representation of the repository.

Figure 1: Axis2 Repository

What is Hot Deployment?

In a real time system or a business environment, it is important to ensure that all systems are accessible round the clock. The current crop of systems needs to be shut down, before you can add new services to the system. This downtime, even it only for a few minutes, may result in a substantial loss and affect the lifetime of the business. Axis2 offers a solution to this issue, with the web service hot deployment feature, where you don't need to shut down the system to deploy a new web service. You can drop the required web service archive into the services sub directory in the repository, and voila! – the deployment model will automatically deploy the service and make it available.

Why doesn’t Axis2 have modules hot deployment?

WS modules can make changes to the system's global configuration. Therefore, if the module author is unaware, the running system can lead to an unknown state (if the deployment model supports module hot deployment); for example, if the author changes the execution chain or the order to execution to suit his requirements it may cause an in-message routing problem. To prevent any such mishaps, the Axis2 deployment model comes with the module hot deployment feature disabled by default.

What is hot update?

Hot update allows you to make changes to an existing web service without shutting down the server. This is an important feature and required in a testing environment. However, it is not advisable to use hot update in real time system, because running a service hot update could result in the service leading into an unknown state (whereas running a module hot deployment could result in the system leading into an unknown state). Additionally, there is the possibility of loosening the existing service data of that service. To prevent this, Axis2 comes with the hot update parameter set to FALSE by default.

Service Archive

Axis2 services are no longer a discrete set of files. It is a single bundle, assorted in an AAR file. This archive has a defined internal format and contains a descriptor called the service.xml. The basic format of the service archive file is shown in Figure 2.

Figure 2: Service Archive File

The deployment procedure is stunningly simple. If the hot deployment is turned "ON", all you need to do is to drop the service archive into the repository folder. To facilitate remote deployment, the Axis2 web application comes with a file uploader function, which can also be used to remotely upload services. Service archives reduce the complexity of the deployment process dramatically. Even so, creating a service archive, especially the service descriptor, is not a trivial task. To make this process simpler and easier, Axis2 comes bundled with a tool kit that allows creating service archives easily.

A brief look into the service archive file

As mentioned earlier, the Axis2 service archive is a JAR file renamed to .aar, with the only difference being that the META-INF directory contains a configuration file called service.xml. The configuration file will tell the Axis system what operations the service can provide, the name of the service implementation class, WS modules that need to be invoked, and service specific parameters like username and password details. A simple service.xml file looks like this:

<service name="SampleService">



    <parameter name="username" >serviceuser </parameter>

   <parameter name="password" >foo123</parameter>

   

 <parameter name="ServiceClass" SampleServiceImpl </parameter>

    <module ref="sampleModule "/>

    <operation name="echo"/>

</service>

In the file, the ServiceClass parameter is used to specify whether SampleServiceImpl is the service implementation class or the class that does the actual web service invocation. The service class looks like this:

public class SampleServiceImpl {

    public SOAPEnvelope echo(SOAPEnvelope in){

        return in;

    }    

}

The configuration file itself is very simple. In this example, it does not say anything about service specific handlers, but it has a reference to a module called sampleModule. If sampleModule is not available in the system (inside the module directory, that is) the service cannot be deployed successfully.

Module Archive

This is a new concept introduced in Axis2. Modules are collections of resources that are relevant to providing a specific functionality like WS security or WS Addressing. Once a module is installed in the Axis system, the system becomes compliant to a particular functionality. For example, if the security module is installed in an Axis system, that system can act as a secure service provider.
Modules are similar to services in their anatomy, if not for the module.xml file, which is the module descriptor. Module descriptor is far more complex than the service descriptor and just as for the services, a tool is provided for creating the module archives.

Figure 3: Module Archive File

Although the new deployment model provides service hot deployment, the web service extension module cannot be hot deployed. So if you need to add a new module to the system, shut down the web server before dropping in the required module and then restart the web server. Although the new deployment model is capable of providing module hot deployment ability, because a module can change the behavior of the total system and possibly lead to unknown state of the running system, the module hot deployment feature is disabled by default in Axis2. Unlike web services, modules are not frequently developed; so disabling the module hot deployment capability does not translate into a terrible inconvenience.

A brief look into the module archive file

As in the case of service archives, META-INF contains a module configuration file called module.xml that consist of all the configuration data that the module requires to be deployed correctly, such as module parameters and module implementation class. The most important thing is module handlers. When the system is started, the deployment module reads all the module archive files. Next it reads its module.xml file and creates a corresponding object model – this is called ModuleDescription. The module.xml corresponds to WS Addressing implementation, and it looks like this:

<module name="addressing" class="org.apache.axis.AddressingModule">

    <inflow>

        <handler  name="AddressingInHandler"              class="org.apache.axis.handlers.addressing.AddressingInHandler">

            <order phase="PreDispatch"/>

        </handler>

    </inflow>



    <outflow>

        <handler name="AddressingOutHandler" class="org.apache.axis.handlers.addressing.AddressingOutHandler">

            <order phase="MessageOut"/>

        </handler>

    </outflow>

</module> 

The module description includes a number of new modules, such as inflow, outflow and phase. The term flow refers to a collection of handlers known as a handler chain. So inflow refers to the flow that executes when an incoming message is being processed (which is invoked when a request is being processed). An outflow is executed when a message is going out. In addition to inflow and outflow, the Axis2 execution framework consisted of infloutflow and outfloutflow which are executed if there is an error in either inflow or outflow. Phase, a new concept introduced by Axis2, provides a way to locate handlers relatively to another handler. To put it simply, phase is a logical collection of handlers and it represents a specific time interval in the execution.

Conclusion

The Axis2 development team started work on the deployment model to address the drawbacks of the Axis 1.x model. In the process we have been able to create a brand new, user-friendly deployment mechanism. The archive-based deployment makes the WS module developer's job easier by providing a facility to bundle all the class files, lib files, and so on, together into one archive file. The new mechanism reduces the task of deploying a web service into dropping the archive file into the service directory, and not having to change any other configuration.