Print Article: Axis2 - The Future of Web Services

Introduction
The Web Service stack has evolved rapidly over the last three years, during which time the Axis team initiated the development of the next generation of Apache Axis. Apache Axis 2 is based on a fresh architecture, consolidating the experience of its predecessors, Apache SOAP and Apache Axis. The first Axis2 milestone was released in February 2005, and the team is gearing up to release version 1.0 in another couple months. This article presents the rationale for Axis2 architecture explains the new features in contrast to the Apache Axis 1.x family.

Why Axis2 and Why Now?
The first generation of Web Services, that emerged in early 2000, concerned themselves with running a few controlled interactions through the Web. At this time, the objective of SOAP engines (Apache SOAP, for example) was to demonstrate that Web Services were something more than a concept. Therefore, the Web Service middleware developed in this era focused on accuracy rather than performance.

The second generation of Web Services were considered a feasible technology. It led to the making of many SOAP engines such as Apache Axis, Systinet WASP and gSOAP, that were capable of many different interaction styles. Specifications were put in place for major aspects of Web Services and most SOAP engines adhered to these common specifications, thus enabling cross platform interactions. Axis was one of these second-generation SOAP engines that soon became popular among Web Service implementers. But Web Services still lacked the robustness and efficiency needed by a true middleware platform.

This problem is set to be solved by the third generation of Web Services that are expected to be fast, robust, efficient, and reliable. They are well-matured and the specifications governing most aspects of Web Services have improved. Second-generation SOAP engines such as Axis are no longer sufficient to cater to the high-demand, new generation Web Services. Axis2 aims to fill this gap.

Axis2 - What Does the New Beast Look Like?
In this article, Axis2 is presented in contrast with the Axis1.x family. Axis2 is shaped by the experience gained from the Axis 1.x family and the advancements in the Web Service stack in the last few years. Axis2 developers have taken a conscious effort to ensure it delivers better speed and memory performance, with the additional features and functionalities in the latest version. The upcoming Axis2 design has marked changes in the following areas:

New SOAP Object Model
Better Support for message exchange patterns
Synchronous and asynchronous behavior
Improved deployment model
Pluggable data binding
Improved Handlers (Filter) framework

The New SOAP Object Model
The main challenge of any web service-based middleware is to avoid keeping the complete SOAP message in the memory. Keeping the entire object model in memory makes the "programmatical manipulation" of XML objects easier. However, the memory is penalized since the object model requires a considerable amount of memory that accounts to at least the size of the XML document being processed.

One of the first generation SOAP engines, Apache SOAP, uses a DOM-based object model internally to represent the XML document, where the XML handling techniques force the entire XML object model to be built at once. The second generation Apache Axis shifted to SAX to avoid keeping the complete information in the memory. SAX, however, has a major constraint - it is built around a "push" technique, and once the parsing of the XML document starts it cannot be stopped. To jump over this hurdle, Apache Axis has to record SAX events. So, effectively, the XML message has to be kept in the memory in the form of SAX events, thus making Apache Axis yet another memory intensive programming model.

The disadvantage of these memory intensive programming models becomes evident when large XML files need to be manipulated. For midsize XML documents the performance is acceptable, but not so for larger XML documents. A few concurrent requests with large XML documents can cause the SOAP engine to crash.

Axis2 avoids keeping the complete SOAP message in the memory by introducing a new Object Model for representing the SOAP message AXIOM. AXIOM (or OM for convenience) takes a dramatically new approach. Although AXIOM has an "external" resemblance to DOM, the difference lies in that it generates objects only when required. This "on-demand building" feature gives AXIOM the edge needed to overcome the memory barrier that early SOAP engines failed to pass.

Why AXIOM is Good for Axis2?
An interesting feature of AXIOM is that it is based on Pull parsing. It is capable of generating pull events from the Object Model that is built. Further, if the Object Model happens to be half built, AXIOM is capable of shifting to the underlying pull parser to generate pull events directly from the stream.

For example, consider a SOAP message that has three header elements in the SOAP header and 100 child elements in the SOAP body. If the user asks for the third child element in the SOAP Header, the Object model is built till the third element. Now, if the user asks for the pull events of the SOAP envelope, the pull events will be generated (from the Object Model) only till the third element and the other events will be taken directly from the underlying XML pull parser. Since in the SOAP message processing it is usual to process the SOAP Headers through the convenient DOM like API and process the SOAP body though the streaming API, above capabilities allows Axis2 to make a notable difference in performance.

The heart of AXIOM is the XML Pull parser since it is the only parsing model that supports the pausing of the parsing process. AXIOM uses the Streaming API for XML (StAX), making it easy to manipulate and utilizing only a fraction of the memory used by a conventional object model. Combined with the speed of the streaming pull parser, AXIOM pushes Axis2 leaps ahead of its predecessors in terms of efficiency and speed.

"Pull" Parsing versus "Push" Parsing
Pulling and pushing in parsing XML documents is termed according to the entity that has control.
A push parser acquires control once the parsing starts and keeps pushing events or objects to one or more content handlers. Since the parser has control during the parsing, no external entity can interrupt or hold the parsing process until the document is fully consumed. The SAX parser is a push parser.

In the last couple years, this push trend changed. Since large, "out-of-control" XML document parsers made parsing difficult and inefficient, efforts began to be focused on separating the control from the parser. This led to the birth of the pull parser. The success of pull parsers led to the standardization of XML pull parsing under JSR173. Eventually, StAX was born.

Improved Deployment Model
In the Axis 1.x family, deploying a Web Service requires updating the configuration file and making the class files available in the class path. The first can be achieved by running a tool called AdminClient, but the latter is far from simple. The simplest way to update the class path is by manually copying the class files to the correct location and restarting the Axis server. This cumbersome deployment model has been blamed as a major bottleneck in Axis' usability.

Axis2's deployment model is based on an archived file system. Each component of the Axis2 configuration is stored in an archive or a configuration file, which makes it similar to the J2EE deployment mechanism. With this new mechanism, the two steps in the Axis 1.x deployment model boils down to deploying a single Web Service archive.

To make the archival distribution more usable, Axis2 introduces "hot deployment". It detects the presence of the Web Service archive in the repository directory and loads the archive automatically. Although this hot deployment feature is unlikely to be used in a production environment, it is a great usability feature for beginners.

The real value of the new deployment model lies in the fact that information about each Web Service is packed in a single archive. Axis2 also provides Application Isolation based on each archive. The Web Service archives are portable across Axis2 containers and loading of the Web Service class files are simplified. The Axis archives can be dropped manually into the repository directory or uploaded through the Axis Web application for a J2EE servlet container. To make things easier, Axis2 also provides several GUI tools to help the creation of Web Service archives.

Improved Support for Message-Style Interactions
When Axis1.x was introduced, the main focus of Web Services was to emulate RPC over SOAP. So the Axis1.x family came with a burnt-in, Remote Procedure Calls-style (RPC-style) interaction model, which required the system to "answer" every request. This behavior causes problems in non-RPC style interactions like one-way messaging. However, the focus has now moved onto messaging, forcing today's SOAP engines to support message-style interactions natively.

Message-style interactions are defined by the Message Exchange Patterns (MEPs). The WSDL2.0 specification defines eight MEPs. Of these, the three essential for developing basic messaging solution are supported directly by Axis2 (see Figure 1). The Web Service developer would need to do some additional tweaking to include support for the others.

Fig. 1: Message Interaction Patterns

As shown in the figure, "In-Only" has only a SOAP Request, but no SOAP Response. "Robust-In" has a SOAP Request and a SOAP Response is sent only if there is an error. "In-Out" always has a SOAP Request and a SOAP Response.

Unlike its ancestors, Axis2 is built with one-way messaging in mind. The Axis2 core supports both RPC-style and message-style interactions based on the one-way messaging model. Further, RPC-style interactions can be built upon the message-style interaction model. Hence Axis2 provides legacy RPC support while maintaining the messaging model in the core, making it possible to co-exist with other RPC based SOAP engines, particularly Axis 1.x.

One Way Messaging
One-way messaging is worried only about delivering a single message. The message is sent and forgotten as far as the messaging framework is concerned. If there is any correlation between the messages it is left to the upper layers of the framework to handle it.

Synchronous and Asynchronous Aspects
Distributed computing has focused on RPC for long. As a result, the notion of a response immediately following the request is burnt into the consciousness of Web Services developers. In real world scenarios, however, the response may not occur at all or occur after some time (which can be either a minute or a year). Depending on the time taken to respond, the response may be sent through the incoming connection or a different connection.

In RPC, the invocation method blocks and waits for the response to arrive. The remote method call returns only when the response has arrived. As mentioned earlier real world scenarios are far more complex and the client-side programming model needs to be rich enough to cater for them. As far as the Web Service users are concerned,one of the following would be their expectation

The user may not expect a response at all, so the calling method should just return
The user might want to send the request and the calling method to wait till the response arrives to return. This is the usual RPC style.

The user may need the sending method to return immediately, have the middleware (Axis2) to take care of the messaging and let him handle the Response when the response arrives. The latter can be done with callbacks, events that signal the user that a response has arrived, or by a polling mechanism where the user periodically checks for the presence of the response.

Unfortunately, the picture is further blurred by the complexity introduced by different types of transports. There are primarily two types of transports one-way and two-way. The usage of two-way transports like HTTP is reducing with the focus shifting to one-way transport protocols like SMTP. Future Web Services are likely to be asynchronous in nature and HTTP may cease to be the default choice anymore. There is hope yet, however.

The Synchronous and Asynchronous programming models are intended to cover all the above scenarios. Although building a SOAP engine that supports all these aspects of messaging is not easy, Axis2 thrives in this environment. Since Axis2 is based on a core that is neutral, neither does it know anything about Message interaction styles nor does it need to know the behavior of the transport. Axis2 allows users to program Web Services in any of the above configurations.

Improved Handlers (Filter model)
Axis introduced the concept of Handlers that provide extensions or filtering to the Web Service stack. Handlers are configurable callbacks that can be registered before consuming or sending the SOAP message. With the existing Axis 1.x handler framework, the ordering of the handlers can be specified only at the service deployment time. This requires the exact order of the handlers to be known at the deployment time, thereby leaving the task of deciding the order of the handlers to the Web Service developer. However, most of the Handlers (Security, Reliable Messaging, and Transaction, for example) are developed by separate Web Service stack projects. Unfortunately, Web Service developers often do not understand the complex requirements that govern the ordering of the handlers.

Axis2 intends to change this by introducing "Phase rules" that enable the developers of each handler to specify the "partial order" of the handlers. This is achieved by introducing two concepts, the "Phases" and the "Phase Rules". While Phases are labels given to the specific area of the execution handler ordering, Phase Rules specify the location of each handler relative to particular phases. When execution takes place, the Axis2 engine will ensure the Handler is placed in such a way that all Phase Rules are met.

Figure 2 : Handler deployment scenarios

For example, say the Reliable Messaging (RM) project wrote a RM Handler. Since this Handler is supposed to run with other Handlers and is going to be used in different situations, there is no way developers of the RM Handler can specify the absolute location from which the RM Handler should run. This task then gets shifted to the Service developer, who is not required to be aware about the behavior of the RM Handler at all.

Even so, the developer will know some of the rules of how the RM Handler should be run. For example, a simple rule governing the RM Handler is that it should run after the security handler but before the transaction handler. The RM Handler will document this fact to assist the Service developer. Phase Rules go one step further by letting the RM Handler developer directly instruct Axis about the placement of handlers, rather than just documenting the fact, to ensure smooth operation.

Pluggable Data Binding
XML data binding or the conversion of XML to Java and Java to XML has been a well-known problem. It has been successfully solved with the use of JAXB, Castor and XMLBeans. The best data binding tool for a given use case is decided by the nature of the use case and programmer preferences.

Axis2's data binding solution is to provide a framework that enables different data binding tools to be used. The Axis2 development team believes this would yield the most flexible solution, as well as help focus attention on to the Web Service stack rather than "reinvent the wheel" with data binding.

Conclusion
We are at the threshold of a new world where Web Services will be used for everything. The next generation of Web Services-based middleware needs to handle all the use cases they confront. In the last few years, work on web services has matured the Web Services stack and the standards. Apache Axis2 plans to take on the next generation of Web Services by implementing a high performance web service engine that incorporates the advancements made on the Web Services stack.

Srinath earned his B.sc. in Computer Science and Engineering from the University of Moratuwa, Sri Lanka. He is a committer for Apache Axis2, Apache EWS, Apache Geronimo and Apache Axis projects. He has been working on Web Services‑based projects for the past three years and his expertise are Web Services, J2EE and XML processing technologies. He is currently one of the core developers for Apache Axis2 working under a fellowship from Lanka Software Foundation and his primary focus is on the Engine, the core of the Apache Axis2.

Ajith earned his B.sc. in Computer Science and Engineering from the University of Moratuwa, Sri Lanka. He is a committer for the Apcahe Axis2 project and has been working on Web service based projects for the past four years. His expertise is primarily in Web Services and XML processing technologies. He is currently one of the core developers for Apache Axis2 working under a fellowship from Lanka Software Foundation and specializes in the new XML object model, AXIOM.

References