Introducing Axis 2, the Next Generation of the Apache Web Service Stack

Axis 2, the next generation of the Apache Web Service stack, takes one more step closer to the first production version by releasing another developer version. In this article, an Axis 2 developer presents Axis 2 in contrast to Axis, the rationale for Axis 2, and the future of the two projects.

Web Services, a Brief History

The era of isolated computers is over; now connected we stand, isolated we fall is becoming the motto of computing. Networking and communication facilities have connected the world in a way as never before. The world has hardware that could support the systems that connects thousand of computers, and those systems have the capacity to wield power that was once only dreamed of.

But still, computer science lacked the technologies and abstraction to utilize the established communication networks. The goal of distributed computing is to provide such abstractions. RPC, RMI, IIOP, and CORBA are few proposals that provide abstractions over the network for the developers to build upon.

Those proposals fail to consider one critical nature of the problem. The systems are a composition of numerous heterogeneous sub systems, but the above proposals require all the participants to share a programming language or a few languages. Web Services provides the answer by defining a common XML-based wire representation for the interactions, thus enabling the different systems to interact.

Web Service defines SOAP, the message format, and WSDL, a common way to describe the Web Services. Different programming languages may define different implementations for Web Services, yet they interoperate because they all agree on the format of the information they share.

Web Services Middleware, the Three Generations

Web Services middleware provides simple abstractions for the users, and handle the inherent complexities of the Web Service messaging. Web Services middleware allows non-geeks to do Web Services while knowing only a fraction of the details in the long list of the Web Services specification.

As a result, middleware can be used as the measure of the success and the practicality of Web Services. The less the trouble the user undergoes when using Web Services middleware, the more users who will embrace Web Services.

Web Services fall under the so-called emerging technologies category, and rightly so. The history of Web Services spans barely a five-year period, yet Web Services middleware can be categorized into three clear generations that can be called the first, second, and third generation.

When the concepts of the Web Services were first heard, researchers wanted to demonstrate that the concept of Web Services is valid. In those days, performance was hardly a critical concern and the long list of messaging scenarios was unheard of. The first generation of Web Services was written to demonstrate the validity of Web Services. Apache SOAP is a classic example that does Web Service correctly, but practices lesser concerns about the Quality of Service (QOS) parameters.

When Web Services concepts enjoyed wider acceptance and were branded as the next big thing, the need to implement real-world scenarios using Web Services arose. Second generation middleware handled the basic scenarios correctly; they focused on a limited set of scenarios, yet implemented them completely. Users were happy with synchronous, request-response support and nobody tried to send DVDs over Web Services. Apache Axis, WASP, and the Microsoft SOAP toolkit are a few that belong to this second generation.

As the time passed, understanding about the problem space widen and, with the introduction of the Service Oriented Architecture (SOA), took the Web Services space great leaps forward. At first, Web Services were used as the method to provide XML RPC, but it soon turned out that Web Services can be used to build loosely coupled systems that can be decoupled in time as well as space. Furthermore, Web Service extensions, such as security, are more layered down and understood. The existing Web Services middleware cannot cope with all these changes; thus, the third generation of Web Services is called for. The third generation of Web Services is evolving to meet those requirements; Microsoft Indigo is one example that can be categorized as third generation.

The Rationale for Axis 2

Apache Axis has been the most successful open source Web Services implementation over the last three years. Axis has been the SOAP engine any other SOAP engine is always compared against and it is the defacto SOAP engine for academics in their research. Axis got a healthy user community and the developer community, and wide range applications that confirm the claims.

But nothing is forever. With the huge changes that took place in the Web Services space, the assumptions that were true at the time of the second generation no longer hold. The time of the third generation is coming.

The expectations from the Web Services, thus the expected features from Web Services middleware, have changed. As a result, the second generation fails to live up to expectations. The three main areas of concern follow.

1. Better performance, both in terms of memory and end-to-end latency. Real-life scenarios involve very big messages or a very high concurrent load.
2. Support for asynchrony and other messaging, in contrast to synchronous request-response scenarios.
3. Better support for the WS-extensions.

The evolution from second to third generations has broken a few basic assumptions that were made in the second. As a result, addressing the above concerns calls for a complete architectural reform. The developers of Axis have acknowledged this and have gathered around the Apache banner to build the next generation of the Apache Web Service stack; thus, Axis 2 was born. Axis 2 brings together the experience from the past two generations of the Apache Web Service Stack, Apache SOAP, and Axis. Axis and Axis 2 do not compete and most of the heads that are behind Axis are now behind Axis 2, working hard and guiding.

Axis 2, the Concepts

Axis 2 is best explained in a book, rather than with a article, but for the benefits of the users, this chapter walks though the most prominent areas where Axis 2 changes.

1. Axis 2 does not assume request-response message interactions by default; instead, it supports a wide range of messaging interactions. The core of Axis 2 enables users to model any of the message interaction, but because the patterns are unlimited, Axis 2 provides support only for the one-way and request-response patterns in the Client API.
2. Both asynchrony as well as synchrony are given the same stakes, and they are supported both in the Client API level as well as the transport level. The different behavior of the asynchrony/synchrony using both the two-way and one-way transports can be configured via the Axis 2 Client API.
3. A new object model that supports differed parsing, the object model provides a easy-to-use interface for the user while handling streaming based XML parsing within the implementation. This approach minimizes the memory taken by the SOAP processing and expected to yield an order of magnitude performance advantage over the Axis 1.x family.
4. Introduction of a new concept, Modules, to handle the WS-extensions. Each WS-extension is handle by a Module, and each Module may be in the states available (ready to action) or engaged (active with a service). At startup time, the Axis 2 deployment sub-system will find the available modules and services may engage them. If there are any WS-extension (modules have a border scope other than WS-extensions) associated with a module, once the module is engaged by a service extension it becomes active for the given service.
5. A archived-based deployment model, that is closely related to J2EE deployment model. Axis 2 defines a new service archive format and Module archive format; they can be deployed to Axis 2 simply by copying the archives into the repository directory. This archived-based Model enables hot deployment and service isolation, thus increasing usability.

The preceding five features are the defining characteristics of Axis 2, and are planned from the drawing board. Furthermore, Axis 2 incorporates a number of concepts that arise in the Web Services space, such as REST Web Services, MTOM, and JAX-RPC.

Axis 2 has released three developer versions to date and the good news is that the most of the architecture is already laid down. The team is planning for few release candidates before the first production release.

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.

There are lots of applications that use Axis, and Axis 2 aims for the future. The decision to migrate is a tricky one. Axis 2 encourages migration by making the migration as smooth as possible, but backward compatibility is a tough nut to crack, the developers are pacing up a slippery slope trying to support it. Developers have decided not to worry about the backward compatibility at the point of design and believes the resulting architecture will be rich enough to handle most scenarios. Fortunately, our experience so far shows that most Axis APIs can be layered on the Axis 2 API.

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.

1. 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.
2. 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.
3. 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.
4. 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.
5. 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.

Summary

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.

Reference

http://ws.apache.org/axis2/userguide.html

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.