Deploying the Service
One of the significant features of Axis2 is its deployment model. It follows the archive-based structure of J2EE deployments with the archive encompassing its deployment and service descriptors. The archive is called Axis Application Archive (AAR).
To create an archive of your service, you will use another Eclipse plug-in provided by the Axis2 project. This time you have to select the option for generating an archive. Again, there are command-line options available. Along with all the service code, this archive file will contain the service.xml, which will serve as the service descriptor. The idea is to hot deploy and update applications during runtime by uploading the archive through the Axis2 web application.
Another option, in case you need deploy these services as part of an existing EAR (embedded Axis2 deployment), is to create a special "services" directory under WEB-INF of a web project and drop the archive in that directory. Most enterprise applications are deployed in managed environments with planned releases, so the latter option is preferable as it allows web services to be part of the application deployment EAR. This facilitates better control, ownership, and accountability.
It is also recommended that this web project WAR be an independent project by itself (within the application EAR) to serve web services. It should not be shared with any other JSP/Servlet web app WAR. This provides added flexibility and also prevents conflicts with the container's web application libraries.
However, there are few issues involved with deploying AAR files with Spring support on enterprise application servers such as WebSphere or WebLogic. Hence, an exploded deployment approach is recommended that for these servers. The following steps walk through deploying an Axis2 application to the WebSphere Application Server platform in a exploded format:
- In an exploded format, you extract the AAR files into a unique directory under WEB-INF. This normally involves extracting the AAR file, which basically is a JAR file, into a directory WEB-INF/services/<service name as in WSDL>. However, when you leverage Spring support to allow visibility to the implementation classes of its defined beans, the process changes a bit and the following steps need to be followed.
- Instead of a complete services structure, the directory WEB-INF/services/<service name> will now have only the services.xml and the service WSDL. You will have to JAR up the remaining files, including the META-INF directory, and add them to the WEB-INF/lib directory in the application classpath. This allows Spring to find its defined classes and instantiate its bean definitions.
- You need to place a copy of service.xml under WEB-INF/.
- Given you are not using Axis2 webapp for deployment, you need to instruct your web application to map any requests to SOAP or REST services to the appropriate Servlets. Hence, you also will need to edit the WEB-INF/web.xml as follows:
- Deployment on WebSphere results in direct conflict with its own Axis 1.x-based web services implementation classes. The typical conflicts seem to be in the wsdl4j.jar and qname.jar libraries, but others might exist too. Hence, you should change the WebSphere classloader policy for both EAR and WAR to PARENT_LAST. This forces WebSphere to load the application libraries first and its own libraries later, thus preventing any Axis2 deployment issues.
After deploying and starting the application successfully, you can verify it at:
For the REST version, verify it at:
By and large, you can use the same process for WebLogic too.