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.
- 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.
- Support for asynchrony and other messaging, in contrast to synchronous request-response scenarios.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
IE 7
Firefox 2.0
