Understanding Axis2 Deployment Architecture, Page 3
Axis2 Service Extension (Modules)
The concept of service extension is a totally new concept in the Apache Axis paradigm, but the developers have achieved the functionally of service extension or the module by doing a very hard job in Axis 1.x. A module is something that can plug into a running system; then, it will do some extra job. In one respect, a module can be considered a set of handlers bundled together to provide some specific casemost of the time, it implements a WS spec.
The idea is very simple. Say you need to support WS-Addressing; what you have to do is download the module and drop that into the modules directory in the Axis2 repository. If you want to enable that globally, put the following entry into axis2.xml; otherwise, if you want to enable that into specific service, put the same entry into the services.xml of that particular service.
In this case ModuleName = addressing.
Note: In Axis2, you get WS-Addressing by default, so you do not need to do anything. In fact, addressing is globally enabled, so each and every service will have addressing functionally by default.
The same scenario is applicable for WS-Security, WS-RM, and so forth.
Creating a module archive file is almost the same as that of a service archive file; the only difference is that the module contains module.xml as its configuration file. In addition to that, the module may or may not contain a module implementation class, but as a module it should at least contain a single handler. (It won't be checked by deployment, but if a module does not have a single handler, it is useless.) A template of module.xml is shown below:
<module name="ModuleName" class="org.apache.module.Module1Impl"> <inflow> <handler name="h1" class="org.apache.axis2.registry.Handler3"> <order phase="userphase1"/> </handler> <handler name="h2" class="org.apache.axis2.registry.Handler3"> <order phase="userphase1"/> </handler> </inflow> <outflow> Out Flow handlers go here </outflow> <Outfaultflow> Out fault flow handler go here </Outfaultflow> <INfaultflow> In fault flow handlers go here </INfaultflow> <parameter name="ModulePara" locked="true"> ModuleParaValue </parameter> </module>
Note: If you have a module implementation class, set the value of the class attribute as a fully qualified name of the implementation class. If module.xml contains a module implementation class, its init method will be called by deployment at deployment time.
As you can see, there are some elements called ** flow. In module.xml, those are basically to configure Axis2 messaging paths. To write a correct module, you need to have a better understanding about all the possible and valid elements in module configuration, but explaining them here is beyond the scope of this article. Resources are available on the Axis2 site; you should read them before writing any modules.
Although a service can deploy without creating a service archive, it is not applicable here. To be a valid module in Axis2, (1) it should be an archive file (either *.mar or *.jar), (2) it should take the directory hierarchy as shown in Figure 5.
Figure 5: Axis2 module sub directories hierarchy
Note: It is not a requirement that you should drop the module archive file into the module's sub directory, but if you have the module archive in your class path and you ask to engage that particular module by putting <module ref="foo"/> in anywhere (may be axis2.xml or services.xml), the deployment engine will read the module from the class path and copy that into the modules directory.
Available Ways to Deploy a Service in Axis2
In Axis2 there are two ways to deploy a service. One is to drop the service archive file into the services sub directory in the Axis2 repository; the other is to deploy the service programmatically. The basis of repository-based deployment has mentioned above, and is the most common way of deploying a service.
Deploying a service programmatically is not really a user requirement, but it is kind of module author requirement, where some module requires you to deploy a Web service to provide the full functionality of the module. To create a service programmatically, you need to have servicesxml, a class loader with your class files (or CCL) and ServiceDescription, the static representation of a service in Axis2. The following code fragment will help you to get a basic understanding about programmatically service deployment.
DeploymentEngine de = new DeploymentEngine(); ServiceDescription service = new ServiceDescription(); ClassLoader cls = Thread.currentThread().getContextClassLoader(); InputStream in = new FileInputStream("location of servie.xml"); de.buildService(service,in,cls);
Axis2 is not there to prove Web services concepts, but to provide a better SOAP processing model, with considerable performance increase in both speed and memory with respect to Axis 1.x and other existing web service engines. In addition to that, it provides a user convenient deployment mechanism. Now, it's time to play with Axis2.