Introducing Axis 2, the Next Generation of the Apache Web Service Stack, Page 2
The Future of Axis 1.x and Axis 2
Axis gained its current stable state over a long period of time. It will take time until Axis 2 enjoy the same. Both Axis 2 and Axis will co-exist in development and the complete migration might take a long time. But, with time, Axis will freeze its functionality and ask the users to move to Axis 2 if they desire more.
It is interesting to note that Apache SOAP is still used and maintained. Considering the richness and the power of Axis over Apache SOAP, it seems irrational, yet given that Apache SOAP handles what it does successfully and users do not expect more, the decision is indeed cost effective and rational.
Let me discuss the problem of migration and the timing, and as usual the answer lies in the user's expectations. Axis 2 is aimed at the future and focused on the smooth operations of the functionalities that are believed will be used extensively in the future. As a rule of thumb, if the user desires any of the six features explained as the strength of Axis 2, he should consider migrating seriously. Let me discuss each case in more detail.
- Both Axis and Axis 2 can handle request-response synchronous use cases gallantly, but when more complex message exchanges come into the picture, Axis 2 would pay off.
- Axis supports all synchronous scenarios and asynchronous scenarios where the message responses return in a comparatively shorter period of time. But, if the application is inherently asynchronous, the Axis 2 model would have an upper hand.
- Axis 2 is designed with the goal of providing better performance, yet the result cannot be known until the production release comes up. Developers expect an order of magnitude advantage in the case of big messages. But, for smaller and moderate messages, both would perform comparatively.
- Deploying an extensibility module such as security is a major hassle with Axis, but Axis 2 provides a module that can be enabled by adding a single line to the deployment descriptor. If the use case has a lot of modules plugged in, Axis 2 would pay off, but there is a subtle point that the implementation that is compatible for Axis2 for the Web Service extensions is not done yet, and might take time to be available.
- Axis 2 provides a archive-based deployment model for Web Services and modules, supporting hot deployment whereas Axis supports only limited deployment facilities.
To summarize, if the user needs to address new requirements such as messaging support, synchronous support, and WS-extensions, they should consider migration, but, if they can cope with the functionality Axis presently provides, they might as well wait a bit more.
Over the last three years, Web Services space has changed a great deal. Axis 2 is the Apache effort to handle the changes that have taken place. Axis 2 has five primary strengths: better performance, messaging support, synchronous support, better support for WS-extensions, and better deployment support. The strength of Axis 2 lies in the flexibility and the functionality that Axis 2 provides; migration can be justified for the cases where few of those functionalities are vital. Future articles will provide examples on using Axis 2.
About the Author
Srinath Perera is a principal architect for Axis2, and his expertise are in Web services, J2EE, and XML-processing technologies. He is a PMC-Member of the Apache Web Service Project and is a committer of Apache Projects, Geronimo, Axis, EWS and Axis2.
Page 2 of 2