Six deployment features of the AXIS2 deployment model provide a better user experience

Six deployment features of the AXIS2 deployment model provide a better user experience Next Generation SOAP processing framework

Document Options send this page as an e-mail message

Level: Intermediate

Deepal Jayasinghe (deepal@apache.org), Senior software engineer, WSO2

April 27, 2007 Are you feeling tired because you need to spend time deploying multiple services? It is not necessary to restart the server after each change. Apache Axis2 can help you get rid of these troubles. Axis2 is a clean and extensible open source Web services platform that is becoming increasingly widely accepted. Axis2 has concentrated on the many advantages of the Apache SOAP family, and has made some significant improvements. This article provides an overview of the most noteworthy new features of the AXIS2 deployment model, which makes the AXIS2 deployment model much easier to use than AXIS1.

Introduction

Apache Axis2 (one of the main open source Web services platforms) offers a range of new features, most notably, many of which contribute to a more user-friendly approach to developers. In previous versions of Axis, user-friendliness was not very important. For example, in Axis1, the user must manually invoke the administrative client and update the server classpath, and then restart the server to apply the changes. This somewhat cumbersome deployment model is certainly an obstacle for novices. As a result, AXIS2 has been carefully designed to overcome this shortcoming and provide a more flexible, easy-to-configure deployment model.

Axis2 Deploying new Features

The AXIS2 deployment model introduces a series of new features into the Apache Web services stack, some of which are not new to the Web services paradigm. The most important major changes and new features are listed below: Similar to java™2 Platform Enterprise Edition (Java EE) deployment mechanism (archive-based) hot-deployment and hot-update repositories (where services and modules can be placed) handler (module) deployment of changes to a new deployment Descriptor multiple deployment options

In the following sections, we will discuss each aspect in detail.

Back to top of page

A deployment mechanism similar to the Java EE

In any Java EE application Server, the application can be deployed as a self-contained package that can package all resources, configuration files, and binaries into one file and deploy them. This is obviously very practical, and precisely because of this, AXIS2 also introduces the same mechanism to make it easier to deploy services (and modules).

Consider this scenario if you have a service that has multiple third-party dependencies and a set of property files, assuming there is no deployment mechanism similar to the Java EE. You must manually place all of these dependent JAR files and property files into the classpath. If there is one or two servers, the amount of this work will be doubled. In a clustered environment where there are hundreds of replicas, it is not practical to add dependent JAR files and other resources to the classpath. With the deployment mechanism similar to the Java EE, there is no such problem, just put the service into the replica, and no need to do any other work.

The internal structure of the AXIS2 self-contained package (or archive file) is shown in Figure 1. The two Axis2 services (archive and module archive) are very similar. The subtle differences between the two include: for the Axis service, the descriptor file is Services.xml, and for the axis module, the descriptor file is module.xml. The AXIS2 service's file extension is. AAR (the service's file name is Foo.aar), and the module has a. mar file name extension (the file name for the module is Foo.mar).
Figure 1: Structure of the archive file

Back to top of page

Hot Deployment and Hot update

For enterprise applications, usability is a big problem. Restarting the server is not a good practice even if a short outage can cause a significant loss. It needs to be updated without shutting down the system. And that's where hot deployment and hot update comes in. Hot deployment and hot update are new features in the Apache Web services stack, such as Axis and Axis2. These two new features are as follows: A hot deployment is the ability to deploy a new service when the system is up and running. For example, suppose you have two services--service1 and service2--are up and running, and now you want to deploy a new service named Service3 without shutting down the system. Deploying Service3 is a hot deployment scenario. As a system administrator, if you do not like the hot deployment of the service, you can turn off this feature by changing the global configuration parameter to the following AXIS2 global configuration file, which is changed to Axis2.xml: <parameter name= "Hotdeployment" >false</parameter>. A hot update is the ability to change an existing WEB service without shutting down the system. This is an important feature that is required in a test environment. However, it is not advisable to use hot updates in a real-time system, as this may cause the system to enter an unknown state. Additionally, you may lose existing service data for the service. To prevent this, AXIS2 defaults to set the hot update parameter to FALSE. If you want to use this feature, you can enable this feature by changing the configuration parameters as follows: <parameter name= "Hotupdate" >true</parameter>.

Back to top of page

Storage Library

The Axis2 repository is essentially a directory with a specific structure in the file system. It can be located locally or on a remote computer. The repository concept is introduced to facilitate archiving-based thermal deployment capabilities.

The repository directory contains two primary subdirectories, called services and modules, respectively. There may also be an optional subdirectory named Lib. If you want to deploy the service, you need to put the service archive file into the Services directory. Similarly, if you want to deploy the module, put the module archive file in the modules directory. For the Lib directory, use it as a location for placing third-party libraries that are common to services and modules. Figure 2 shows a graphical representation of the repository.
Figure 2. Axis2 Repository

Note: If some or all of the modules in the modules directory want to share some resources, you can add these resources to the Lib directory in the modules directory. Similarly, if all or part of the service in the Services directory wants to share a common resource, the appropriate location is the Lib directory within the Services directory.

Back to top of page

Changes to Handler (module) deployment

The concept of a service extension (or module) is a new feature of the Apache Axis paradigm. The basic idea is to extend the core functions of the system or to provide quality assurance of service. For AXIS1, if you want to extend its core functionality, you need to write a handler (the smallest unit in the execution chain), change the global configuration file to add the handler, and then restart the system.

Modules do the same, but reduce the amount of work required. At the same time, the module can contain one or more handlers by using the module description file Modul.xml. In most cases, a module is an implementation of a specific WS specification, such as the Axis2 addressing module, which is the implementation of ws-addressing.

As mentioned earlier, you can deploy the module as an archive file. The structure of the module archive file is shown in Figure 3.
Figure 3: Structure of the module archive file

Back to top of page

New Deployment Descriptor

The focus of AXIS2 's flexibility and scalability is its deployment descriptor. You will no longer process only one profile, but different configuration levels for different configuration files. For example, if you want to add handlers to your system, there is no need to change the global configuration; You can do this by changing only the module configuration file. There are three types of descriptors or profiles in Axis2: Global Descriptor (Axis2.xml) service descriptor (Services.xml) module descriptor (module.xml)

In the global descriptor, all system-level configurations are given in Axis2.xml, including the following: Parameter transport Sender Transport listener stage Global module

The AXIS2 provides the default axis2.xml. It contains the minimum configuration required to start Axis2, but it can be freely changed to start Axis2 with your own axis2.xml. It is important to note that if you make any changes to Axis2.xml, you must restart the system for these changes to take effect.

In the service descriptor, the configuration of the service is given by Services.xml. For the service to be valid, you need to include the Services.xml file in the service archive file. The service profile contains the following content: Description of Service-level parameter services the message receiver needs to expose the operational service-level module as a WEB operation (an operation in the service)

The module descriptor file (module.xml) contains the configuration data required to insert the module into the system. The main configuration includes the following: Handlers and their stage rules module parameters

It is important to note that Module.xml may also contain the following elements: A description of the module (and its implementation specification) endpoint (for reliable messaging, which is similar to the endpoint of Create sequence)

Back to top of page

Deployment methods available in Axis2

In Axis2, there are three main ways to deploy services: Put service archive files into the repository. Create a service programmatically using an archive file. Deploy the service as a traditional Java object (Plain old Java object,pojo).

In Axis2, the most common way to deploy services is to copy or place service archive files directly into the repository (the Services directory). If you use a distribution version based on the Axis2 WAR file, there are two choices: Manually place the archive file in the repository. Use the Web console to upload the service.

Deploying programmatically is not a user requirement, but rather a requirement for the module creator, because some modules require the deployment of a WEB service to provide the full functionality of the module. To create a service programmatically, you need to use the Services.xml, ClassLoader (which you can use to load your class files), and axisconfiguration. The advantage of this approach is that you do not need to copy the service archive file to the repository and only the runtime service is visible. Listing 1 helps you to form a basic understanding of the programming services deployment approach.
Listing 1. Programming Services Deployment

Axisconfiguration Axisconfig; You need to has reference to axisconfiguration file File = new file ("Location of the file"); ClassLoader Clsloader = new URLClassLoader (New Url[]{file.tourl ()}); InputStream in = new FileInputStream ("Location of Service.xml"); Axisservice service = Deploymentengine.buildservice (in, Clsloader, axisconfig);

The use of Java class deployment Services is a very handy feature provided in Axis2, where it is not necessary to generate service archive files or Services.xml. The only requirement is that the Java class must be placed in the classpath before the service is created. At run time, a new service can be created and deployed by a module or service. Deploying POJO in AXIS2 requires only three lines of code, as shown in Listing 2.
Listing 2. Deploying POJO in Axis2

Axisservice service = Axisservice.createservice ( MyService.class.getName (), Axisconfig, Rpcmessagereceiver.class); Axisconfig.addservice (service);

Back to top of page

Summarize

Share this article ... Please Digg this article Publish to Del.icio.us Slashdot, please.

Axis2 here is not a proof of the Web service concept, but rather a better SOAP processing model, and this model has a significant improvement in speed and memory performance compared to AXIS1 and other existing Web service engines. In addition, it provides a convenient deployment mechanism. Now it is time to enter the AXIS2.

Reference Learn
You can see the original English text on the DeveloperWorks global site in this article.

Please visit the Apache Axis2 website.

Read "Using Axis2 for SOA development, part 1th: Understanding Axis2 Fundamentals" (developerworks,2006 December).

Visit the SOA and Web Services zone on Ibm®developerworks for hundreds of articles on how to develop WEB service applications, as well as entry-level, intermediate, and advanced tutorials that you will see. The

IBM SOA Web site provides an overview of the SOA and explains how IBM can help you achieve this goal.

Learn about the latest news about DeveloperWorks technology events and webcasts.

For more information about the Apache project, please visit the DeveloperWorks Open Source technology zone and read a large number of Apache articles and free Apache tutorials.
Get products and Technologies
Develop your next project with IBM trial software to download or request a DVD disc.


Discussion
Participate in forum discussions.