![Close [x]](http://dw1.s81c.com/i/c.gif){kind=small}
Apache Axis2 (one of the key open source web services platforms) benefits from a number of new features, and judiciously, most of these have resulted in giving developers a more user-friendly approach. In previous versions of Axis, user friendliness had not been a priority. For example, in Axis1, users had to invoke the admin client manually and update the server class path, and then restart the server to apply the changes. This burdensome deployment model was a definite barrier for beginners. Thus, Axis2 was engineered to overcome this drawback and provide a more flexible, easily configurable deployment model.
What's new in Axis2 deployment?
The Axis2 deployment model introduces a number of new features into the Apache web services stack, some of which aren't new to the paradigm of web services. The key changes and new features of highest importance are listed here:
- Java™ 2 Platform, Enterprise Edition (J2EE)-like deployment mechanism (archive based)
- Hot deployment and hot update
- A repository (where you drop services and modules)
- Change in the deploying of handlers (modules)
- New deployment descriptors
- Multiple deployment options
In the following sections, we'll break these down and provide more detail on each one.
J2EE-like deployment mechanism
In any J2EE application server you can deploy applications as self-contained packages, where you can bundle all your resources, configuration files, and binary files together into one file and deploy it. This is clearly useful, and that's why Axis2 has also introduced the same mechanism to deploy services (and modules) conveniently.
Think about the scenario where you have a service with a couple of third-party dependencies and a set of property files, and in the meantime, assume that you don't have a J2EE-like deployment mechanism. You have to put all those dependent JAR files and property files into the class path manually. That's double if you have one or two servers! In a situation where you're in a clustering environment with hundreds of replicas, it's impractical to add dependent JAR files and other resources into the class path. Ultimately, when you have the J2EE-like deployment mechanism, you don't have these issues; instead, you can just put the services into the replicas and nothing else.
The internal structure of the Axis2 self-contained package (or archive file) is shown in Figure 1. Both Axis2 services, archive and module archive, are quite similar. The minor disparities include:
- In the case of Axis service, the descriptor file is services.xml, and in the case of Axis module, the descriptor file is module.xml.
- The file extension for the Axis2 service is .aar (the file name of a service will be foo.aar), and the file extension for module is .mar (the file name of module will be foo.mar).
Figure 1. Structure of an archive file
Availability is a big concern when it comes to enterprise-level applications. Even a short amount of downtime can be highly detrimental, so restarting a server is not a good option. You need to update your system without shutting it down. This is where hot deployment and hot update come in. Hot deployment and hot update are new features to the Apache web services stack (such as Axis and Axis2). Here's what these features are:
-
Hot deployment is the capability of deploying new services while the system is up and running. As an example, let's say that you have two services -- service1 and service2 -- up and running, and you deploy a new service called service3 without shutting down the system. Deploying service3 is a hot deployment scenario. As a system administrator, if you don't like the hot deployment of service, then you can turn that off easily by changing the Axis2 global configuration file called axis2.xml and changing the global configuration parameter like this:
<parameter name="hotdeployment">false</parameter>. -
Hot update is the ability to make changes to an existing web service without shutting down the system. This is an important feature and required in a testing environment. However, it's not advisable to use hot update in a real-time system, because it could result in the system leading into an unknown state. Additionally, there's 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. If you want to have this feature, you can do this by changing the configuration parameter like this:
<parameter name="hotupdate">true</parameter>.
The Axis2 repository is essentially a directory in the file system with a specific structure. It can be located either locally or in a remote machine. The idea of the repository concept was introduced to support archive-based and hot deployment features in a convenient manner.
The repository directory consists of two main subdirectories called services and modules. You might have an optional subdirectory called lib as well. If you want to deploy a service, you need to drop the service archive file into the services directory. Similarly, if you want to deploy a module, drop the module archive file into the modules directory. The idea behind the lib directory is that it acts as a place to keep third-party libraries common to both services and modules. A graphical representation of the repository is shown in Figure 2.
Figure 2. Axis2 repository
Note: If a few or all of the modules in the modules directory want to share some resources, those resources can be added to the lib directory inside the modules directory. Similarly, if all or a few services in the services directory want to share some common resources, the proper place is the lib directory inside the services directory.
Change in the deploying of handlers (modules)
The concept of a service extension (or module) is a new feature to the Apache Axis paradigm. The idea is to extend the core functionality of the system or to provide quality of services. With Axis1, if you need to extend its core functionality, then you need to write a handler (the smallest unit in the execution chain), change the global configuration files to add the handler, and finally, restart the system.
A module does the same work, but reduces the work you need to do. In the meantime, the module can have one or more handlers along with a module descriptor called module.xml. Most of the time, a module is an implementation of a specific WS specification, as an example Axis2 addressing module is an implementation of WS addressing.
As mentioned earlier, you can deploy a module as an archive file. The structure of the module archive file is shown in Figure 3.
Figure 3. Structure of a module archive file
The flexibility and extensibility of Axis2 is focused on its deployment descriptors. Rather than working with one configuration file, you have different configuration files for different levels of configuration. As an example, if you want to add a handler into the system, there's no need to change the global configuration; that can be done by changing only the module configuration file. There are three types of descriptors or configuration files in Axis2:
- Global descriptor (axis2.xml)
- Service descriptor (services.xml)
- Module descriptor (module.xml)
In the global descriptor, all the system-wide configurations are given by axis2.xml, including the following:
- Parameters
- Transport senders
- Transports listeners
- Phases
- Global module
Axis2 comes with the default axis2.xml. It contains the minimum configuration required to start Axis2, but you can change it as you wish and start Axis2 with your own axis2.xml. It's important to note that if you made any changes to axis2.xml, you have to restart the system to effect those changes.
In the service descriptor, the configuration about the service is given by services.xml. To be a valid service, you need to have services.xml in the service archive file. The service configuration file contains the following:
- Service-level parameters
- Description of the service
- Message receivers
- Operation needed to expose as Web operations (operations in the service)
- Service level modules
The module descriptor file, or module.xml, consists of the configuration data required to plug the module into the system. The key configurations include the following:
- Handlers and their phase rules
- Module parameters
It's important to note that module.xml may also contain the following elements:
- A description about the module (and the specification it has implemented)
- Endpoints (in the case of reliable messaging, an endpoint like create sequence)
Available deployment methods in Axis2
In Axis2, there are three main ways to deploy a service:
- Drop the service archive file into the repository.
- Create a service programmatically using an archive file.
- Deploy a service as a Plain Old Java Object (POJO)
The most common approach to deploying a service in Axis2 is just copying or dropping the service archive file into the repository (the services directory). If you're using Axis2 WAR file-based distribution, then you have two options:
- Manually drop the archive file into repository.
- Upload the service using the Web console.
The deploying service is programmatically not really a user requirement, but rather a module author requirement where some modules require the deployment of the web service to provide the full functionality of the module. To create a service programmatically, you need to have services.xml, a class loader, which can be used to load your class files, and AxisConfiguration. The advantage of this approach is that you don't need to copy your service archive file into the repository, and it's only at run time that your service is visible. Listing 1 helps give you a basic understanding about programmatic service deployment.
Listing 1. Programmatic service deployment
ConfigurationContext configContext;
// you need to have reference to ConfigurationContext
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,
configContext);
|
Deploying services using a Java class is a handy feature in Axis2; you can simply create a Java class in a web service, and there's no need to have a service archive file or services.xml. The only requirement is that you must put the Java class into the class path before creating the service. At run time, either a module or service can create the new service and deploy it. Deploying a POJO in Axis2 is merely three lines of code, as shown in Listing 2.
Listing 2. Deploying a POJO in Axis2
AxisService service = AxisService.createService(
MyService.class.getName(), axisConfig, RPCMessageReceiver.class);
axisConfig.addService(service);
|
Axis2 isn't here to prove web services concepts, but rather to provide a better SOAP processing model, with considerable performance increases in both speed and memory in comparison to Axis1 and other existing web services engines. In addition, it provides you with a convenient deployment mechanism. Now it's time to play with Axis2!
Learn
- Visit the Apache Axis2 Web site.
- Read "SOA development with Axis2, Part 1: Understanding Axis2 basis" (developerWorks, August 2006).
- The SOA and web services zone on IBM® developerWorks hosts hundreds of informative articles and introductory, intermediate, and advanced tutorials on how to develop web services applications.
- The IBM SOA Web site offers an overview of SOA and how IBM can help you to get there.
- Stay current with developerWorks technical events and webcasts.
- For more information on Apache projects, visit the developerWorks Open source zone. and check out lots of Apache articles and free Apache tutorials.
Get products and technologies
- Innovate your next development project with IBM trial software, available for download or on DVD.
Discuss
Deepal Jayasinghe, an Apache PMC member and Apache committer, is currently architecting and developing Apache Axis2 and Apache synapse. He has been a core architect and core developer of the Apache Axis2 project since its inception. His expertise is in distributed computing, fault tolerance systems, and Web services-related technologies.
Table of contents
Next steps from IBM
Rational Application Developer features provide the comprehensive Integrated Development Environment (IDE) used to develop J2EE applications requiring Servlets and JavaServer Pages (JSPs).
- Try: Try the free Rational Application Developer, which helps developers quickly design, develop, test, analyze, and deploy high-quality Java, Javaserver pages, and J2EE applications.
- Article: Learn how you can deliver accurate, higher-quality J2EE apps with Rational Application Developer, open source JUnit and JUnitEE test frameworks.
- Tutorial: Build a Facebook application using PHP, the Spring framework, and J2EE.
- Demo: This demo shows how to use the new Java EE 5 Java Persistence API (JPA) framework.
- Buy: Rational Application Developer
