Understanding Axis2 Deployment Architecture, Page 2
Axis2 Global Configuration
The flexibility and extensibility of Axis2 is focused mainly on its deployment descriptors. Because all these descriptors are XML-based, the extensibility nature of XML has reflected to Axis2 as well. There are three main deployment descriptors in Axis2, as follows:
- Global descriptor (axis2.xml)
- Service descriptor (services.xml)
- Module descriptor (module.xml)
All the global configurations that are needed to run Axis2 are given by axis2.xml (global parameters, transport information, and so forth). The most interesting thing about this is that someone can configure the deployment behavior by axis2.xml, meaning that one can configure "hotdeployment" and "hotupdate" parameters the way he wants, as shown below.
<parameter name="hotdeployment">true</parameter> <parameter name="hotupdate">false</parameter>
Likewise, all the global level parameters, modules, transports information, and so on can be included in the configuration file. When the axis2 starts, it search the repository for axis2.xml. If it is found, the system will be configured by using that; otherwise, the default one (which is distributed with the axis2 distribution) will be copied into the repository and the system starts using that. Later, if the user wants, he can change axis2.xml file. One thing to remember here is that, to affect any changes, you need to restart the system. (Explaining everything about axis2.xml is beyond the scope of this article. If you need to know more, click here.)
If you are an Axis 1.x user, you are familiar with deploying a service with Axis 1.x. The easiest way to do that is (say you are using Axis 1.x java) through the 'instant' Web service in Axis1.
- Write a Java class that has some methods that you want to publish (say Myservice.java).
- Drop the Java class into the Axis webapp directory.
- Rename the Java class to Myservice.jws (because the name of java class is Myservice.java).
- When you restart Axis, you have the Web service
So, with Axis 1.x deploying a service is nothing?. The answer is yes if you are going to publish a very simple service, but say:
- You have more than one class for the service
- You need to provide service-specific parameters
- You want to have specific library files for this service
This is not impossible with Axis 1.x but average users (particularly beginners) will have to do some hard work to get the job done. In this particular case, the user has to write a special deployment descriptor called the WSDD and feed it to the Axis AdminClient. The admin client does the modifications in the server (again through a Web service), but for the service to work, the server class path needs to be modified, which usually requires a server restart!
Therefore, Axis2 was developed to address the deployment drawbacks in Axis 1.x, and to provide a better deployment mechanism. As a result of that, in Axis2 deploying a service is nothing if you can mange to crate a correct service archive (creating a service archive is not such a difficult task because Axis2 comes with a tool to create archive files). Therefore, in Axis2, deploying a service is just a matter of dropping the archive file into the services sub directory in the Axis2 repository. If you are going to deploy Axis2 in an application server like tomcat, you can use a Web interface to deploy the service.
Here is the Axis2 way to write a Web service by hand (without using tools):
- If you already have the WSDL file for the service that you are going to publish, create a service skeleton using WSDL2Java.
- Then, complete (fill) the service skeleton the way you want.
- If you do not have the service skeleton class, don't worry. Write the service implementation class; it is considered the service skeleton class in this case.
Next, write services.xml, the configuration file of the service as described below. A template of a services.xml file is shown below:
<service > <description> The description of the service goes here; this can be any XML element </description> <parameter name="ServiceClass" locked="false"> org.apache.axis2.MyServiceImpl </parameter> <parameter name="ServicePara" locked="false"> ServicePara </parameter> <operation name="myOperation"> <parameter name="OperationPara" locked="false"> OperationParaValue </parameter> </operation> </service>
Steps to Write services.xml
- There is a specific parameter called ServiceClass. Set the name of the service implementation class as that. It could be a service skeleton class or aservice impl class.
- For each method in the skeleton or service impl class, there should be an operation element. As an example, if you have a method called "myOperation" in the service implementation class, you should write an operation element as shown above.
- There could be a service-specific parameter anywhere in services.xml. At run time, those parameters are available in ServiceDescription or OperationDescription.
Note: The above service configuration is very simple one, and the actual configuration file can be more complex than that. Note: Axis2 is on the way to introducing the concept of a service group into the Web service platform where the user can deploy more than one services in an archive file and share data across those services. This article only describes how a single service should look and the available ways of deployment.
The next step is to bundle the above files together into a service archive file, which can be done by applying the following procedures. (If you are using your IDE as either IntelJ IDEA or eclipse, you can download the plug-in for those IDEs from the Axis2 site; those will make your job much easier.)
- Create an empty folder.
- Create a directory called "META-INF" inside that.
- Put services.xml into the META-INF directory.
- If you have the WSDL file corresponding to the Web service, rename it to service.wsdl and put that into the same directory. (It is not necessary to have a wsdl file in Axis2.)
- If you want any third-party lib files or you own lib files, crate a directory called "lib" in the same level as META-INF, and drop all your lib files into that.
- Copy the compiled service implementation classes into the directory.
- Create a zip file from all those files and rename it to *.jar or *.aar.
The directory should look like Figure 4.
Figure 4: Axis2 service sub directory hierarchy
Note: If you are using Axis2 version above 0.91, you do not need to create an archive file. You can just drop your service folder into the service sub directory in the Axis2 repository.
Note: As mentioned earlier, in Axis2 it is not required to have a wsdl file to publish a service, but if you have a wsdl file, it provides more functionality or rather configurations. If the archive file contains a wsdl file, a WSDL Object Model (WOM) will be created using that particular wsdl by deployment and then fill rest of the data by using services.xml. If you do not have a wsdl with you, an empty WOM model will be crated and rest will be filled using services.xml.