There are a number of major areas where users can get into trouble when using Axis2. In this article, I provide possible solutions and suggestions to most of the problems you may face when you start to use Axis2. Even though this article is titled ‘10 Biggest Mistakes Developers make in Axis2’, rather than just citing problems and relevant solutions, I go one step ahead by explaining the major areas where you are most likely to get into trouble and by showing you how to overcome those situations.
1 — Trying To Do Advance Tasks Without Knowing Basics of Axis2
Axis2 is the next generation of web services stack, which is built on a new architecture. It was introduced in order to have a much more flexible, efficient and configurable Axis. Even though the architecture is new, some of the well-established concepts from Axis 1.x are preserved in Axis2.
Axis2 does, however, come with a lot of new features, enhancements and new industry specification implementations. Items such as AXIOM, Asynchronous Web service, MTOM, MEP support and archive-based deployment architecture are considerably esteemed among these new features and enhancements.
One of the main reasons of introducing Axis2 was to have proper XML processing model. Axis 1.x used DOM as its XML representation mechanism, but the draw back with DOM is the need to keep the complete objects hierarchy (corresponding to incoming message) in memory. For a message of small size this won’t be a problem, but when it comes to a large message this becomes an issue. It is to over come this problem Axis2 introduced a new XML representation for it base.
AXIOM (AXIs2 Object Model) is the base of Axis2, where any incoming SOAP message is represented as an object model called AXIOM inside Axis2. The advantage of AXIOM over other XML inforset representations is that it is based on PULL parser technique, while most others are based on PUSH parser technique. The main difference of PULL over PUSH is that in PULL technique invoker has the full control on the parser and can ask for the next event, where as in the case of PUSH, when the parser is asked to proceed it will fire the events until it reach the end of the document.
Since AXIOM is based on PULL parser technique it has so called ‘on-demand-building’ capability where object model will be built only if it is asked to do so, and, also if it is required one can directly access underline PULL parser from AXIOM and use that rather than building OM (Object Model).
If you don’t have a good understanding of AXIOM, then developing Web services with Axis2 is not an easy task. You will encounter different problems and you most likely won't use its optimization mechanisms. Of courses you can develop simple services without knowing anything about AXIOM, but if you are going to implement WS-spec or perform certain advance work with Axis2, it’s wiser to learn AXIOM first.
2 — Lack Of Knowledge On Axis2 Repository
In simple terms Axis2 is a SOAP processing engine with the main function of delivering incoming SOAP messages into the correct applications—and here every application is assumed to be a web service. In the mean while, just delivering an incoming message to an application is not enough. It is also required to have quality of services (QoS) like security and reliability.
To provide those QoS, or rather to extend Axis2 main functions, Axis2 has introduced the concept of extension modules. Axis2 repository keeps those two kinds of resources (web services and modules), in a simple term repository, a directory in the file system, which has some specific structure as shown in Figure 1.
Figure 1: Axis2 repository
As you can see there are three sub directories inside the repository and usage of them are as follows:
| lib | | if both services and modules want to share some third party libraries then those should be placed in lib directory |
| modules | | all the extension modules, or rather, module archive files should be in the modules sub directory |
| services | | all the web services or rather service archive files should be there in the services sub directory. |
The repository may contain Axis2 configuration file (axis2.xml) as well. When you start Axis2 for the very first time by giving repository location, if there is no axis2.xml found in the repository, it will copy the default axis2.xml file into repository and start the system using that axis2.xml. Thereafter a user can change that axis2.xml file if desired. Next time when the user starts Axis2, the system will be configured reflecting those changes as well.
Note: There is minor modification in the structure of the repository after Axis2 0.94 release. The axis2.xml file is located inside some other sub directory called conf inside the repository.
3 — Lack of Understanding regarding the Generation of WSDL
When working with WSDL files, it is possible to generate a service using WSDL that is given to you when you deploy the service. However, at run time you can end up receiving different WSDL when you ask for the specific service’s WSDL (?wsld).
In the Axis2 development process you should always think about the usability of product. Therefore a number of tools & IDE plug-ins have been developed to perform various tasks in Axis2. One such tool is WSDL2Code generation tool. As its name implies WSDL2Code generation tool generates source code for languages like Java and C++ using given WSDL. Note that only the WSDL2Java part has been completed and fully tested successfully.
In simple terms code generation is the creation of source code in some programming language for a given WSDL, so that users need not to worry about the WSDL or generating correct SOAP messages. All of this is handled by the code generated by the WSDL2Code generation tool.
The most common problem users face is that they generate server side code or rather service skeleton for a given WSDL and then they filled the skeleton the way they want (it is the nature in contract first approach). Then they create a service archive file for that service and deploy it in Axi2.
When Axis2 finds a service what it does is first it check whether there are any WSDL files in META-INF directory. If there is give the priority to the WSDL files and using those Axis2 web service will be created. If no WSDL files are found then it goes through services.xml file to find the service implementation class. Using that class, it generates a WSDL file using a process called Java2WSDL. This will only taken place if the service class was implemented using Java. Bottom line, when some one ask for ?wsdl for that particular service it will show the generated WSDL.
In the case of automatic WSDL generation, it first investigates the service implementation class using both Java reflection and JAM (annogen) and then generate XML schema for the given class and then generate the rest of the WSDL document. Most of the time (99% of the time) the generated WSDL file will differ from the original WSDL file that was used to generate service skeleton.
Note: I you generate client side code or stub using both of the above WSDL files you will get completely different set of classes, but that won’t affect to the request SOAP message.
Silverlight 2 SDK for Visual Studio 2008
Article: What Does it Take to Build the Best RIA? 
Expression Blend 2.5 Preview
The Hottest Mobile Platform Meets the Hottest RIA Platform 
Article: Leveraging Your Flash Development with Silverlight 
IE 7
Firefox 2.0
