Skip to main content

Axis2: The Next Generation of Apache Web Services

September 7, 2006

{cs.r.title}






Web services have gained traction thanks to their ability to interoperate with heterogeneous systems. When Web services were introduced, performance or memory were minor concerns. Many organizations and individuals produced engines, like Apache SOAP, which were mere proofs of concept.

Several companies identified the potential in this emerging technology and entered the field, seeking to have better and faster SOAP engines. By that time, a Web services definition was standardized through WSDL (Web Services Description Language), and Web services discovery was standardized through UDDI (Universal Description, Discovery and Integration). Apache Axis was born and became dominant during this era.

Now that the initial stages of Web services are coming to an end, Web services are in high demand, and a large number of players have entered the Web services arena. Aspects governing different facets of Web services interactions have been standardized. The third generation of Web services requires faster, far more robust SOAP engines.

Axis2 Fulfills the Demand

Apache Axis2 is an effort to incorporate the latest changes in the Web services space and to improve performance and efficiency. During a face-to-face meeting in Colombo, Sri Lanka, in August 2003, some of the leading architects of Apache Axis 1.x got together and initiated Apache Axis2, the next generation of Apache Web services. A new architecture was introduced to fulfill the current demand, taking the best patterns and usage scenarios from Axis 1.x. Key improvements and new features included:

  • A new XML processing model
  • A messaging-based extensible core
  • An improved deployment model
  • Pluggable data binding support
  • Asynchronous and synchronous Web services invocation

A new XML processing model

AXIOM (Axis Object Model) represents an effort by the Axis2 team to provide a new, high-performance and memory-efficient object model optimized for SOAP processing engines. AXIOM shouldn't be considered as yet another object model as it possesses many aspects that other object models do not have.

AXIOM is built around the concept of pull parsing, which is now standardized by JSR 173: Streaming API for XML. When you parse an XML document, the parser has control over the process. Once started, a typical DOM or SAX parser parses the XML document from start to finish without taking the application into consideration. DOM (Document Object Model) builds a complete object model corresponding to the XML document in the memory. SAX (Simple API for XML), on the other hand, reads and throws events, from start to finish. (Events are information about the content of the XML message. As an example, a SAX parser will throw "start event" when it encounters a start tag of an XML element.) The advantage of stream parsers like SAX, however, is that they are memory efficient as they do not build anything in the memory. Since the application has no control over the streaming SAX parser, SAX is regarded as a "push" parser.

In the "pull" model, however, the application has control over the process. The application asks the parser to proceed and wait. With this process there is no requirement to parse the whole XML document at once. (For more information about pull parsing and StAX, read S. W. Eran Chinthaka's Introduction to StAX.)

Taking advantage of the concept of pull parsing, AXIOM has the great feature of deferred building of the XML object model. It builds the object model in memory only when it is absolutely required by the application.

Let's take a look at a SOAP message for sample XML that illustrates this concept:

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
    xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/03/addressing">
    <soapenv:Header>
        <wsa:MessageID soapenv:mustUnderstand="0">
            uuid:920C5190-0B8F-11D9-8CED-F22EDEEBF7E5</wsa:MessageID>
        <wsa:To soapenv:mustUnderstand="0">
            http://localhost:8081/axis/services/BankPort</wsa:To>
        <wsa:From soapenv:mustUnderstand="0">
            <Address xmlns="http://schemas.xmlsoap.org/ws/2004/03/addressing">
                http://schemas.xmlsoap.org/ws/2004/03/addressing/role/anonymous
            </Address>
        </wsa:From>
    </soapenv:Header>
    <soapenv:Body>
        <axis2:echoVoid xmlns:axis2="http://ws.apache.org/axis2" />
    </soapenv:Body>
</soapenv:Envelope>

As an example, let's say a user is interested in knowing only the value of the MessageId element. In that case, when that user asks for the MessageId element, AXIOM will build the memory model only up to the MessageID element. The rest is kept in the incoming stream, untouched. The beauty of AXIOM is that it can start again from the last place it stopped and continue to build the model until it has enough information to cater to the next user request.

The incoming XML stream takes some amount of space in memory. DOM-based parsers build another object model to make the access easier and unnecessarily duplicate information in the memory. The disadvantage to the user is that the entire message may be discarded after having read only one field. The deferred building capability of AXIOM avoids unnecessary memory usage, which leads to the low memory footprint of AXIOM.

AXIOM can provide the StAX events directly to the user from any given point in the XML document. Users have the option of building the object model in memory or not when they ask for events from the stream. Building the object model while getting the events is called "build with caching on." This approach gives the user significant control over memory. Caching brings up another interesting aspect: Let's say AXIOM has already built the memory model up to the end of the Header element of the above XML; if the user now needs to pull events from the start of the envelope, AXIOM will emulate the pull events up to the end of the Header element and then will switch to the stream. This is transparent to the user and isolates the user from all the headaches involved in handling the raw stream and the partially built object model together.

Tests with Sosnoski's XML bench toolkit show that AXIOM is just as fast as JDOM in traversing the tree but uses only a fraction of the memory. AXIOM gives Axis2 a huge advantage in performance.

I mentioned at the beginning of this article that AXIOM is not just another XML object model. Since AXIOM was initially used with Axis2, it has a few customizations on top of its base API for handling SOAP messages. Users can work at the XML level or they can get an instance of SOAPEnvelope as the document element. From that, users can call the getHeader() or getBody() methods. This provides a more user-friendly API for SOAP developers. This API includes complete support for both SOAP 1.1 and SOAP 1.2.

AXIOM has built-in support for MTOM, a concrete implementation for optimizing the transmission and/or wire format of SOAP messages. This enables users to send attachments with SOAP messages. AXIOM has also proved to have enough flexibility to integrate with most of the data binding tools available today, through its flexible APIs. I will discuss this topic in more detail later. (For more information about AXIOM, read this article.)

Extensible Core

The philosophy of Axis2 is to have a minimal core that can have other, related technologies layered on top of it. Java standards like JAX-WS have been kept out of the main core, but there is enough room for them to be layered on top of the core—after all, active development on JAX-WS is happening these days in the Axis2 community. Axis2 has adopted many best practices and patterns from the Axis 1.x family, for example, the handler framework and the engine concept.

Let's look at the key components of the core.

Engine - The engine is the driver or the controller of the process after the transports. Due to the decoupling of transports from the engine, theoretically Axis2 can support any transport, transparent to the message processing engine. The engine drives the messages within the "pipes" available, depending on the Message Exchange Patterns (MEP) that are being used. Before continuing, let's look more closely at a MEP.

Message Exchange Pattern - Think of a scenario whereby a client sends a message to a Web services engine. From the Web services engine point of view, this is an IN message. Then let's think about request-response message exchange, whereby a client sends a message and the Web service engine, having received it, sends out a response message. From the Web services engine's point of view, the client receives an IN message and sends an OUT message. The above two are message exchange patterns, being IN-only and IN-OUT respectively.

Axis2 does not by any means depend on any particular MEP. If one Web services operation is exposed as an IN-only MEP, Axis2 will provide an IN pipe for the messages coming into the engine. If the MEP is IN-OUT, the engine will provide two pipes for sending and receiving messages. Figure 1 shows a typical pipe that can be found inside the Axis2 engine. With this pipe concept, Axis2 can handle any MEP—either one defined by WSDL or a custom one defined by the user. Axis2 comes with built-in support for basic MEPs that are found in WSDL 2.0.

Figure 1
Figure 1. Pipeline view of Axis2 engine

Handlers and Phases - Axis2 incorporates the standard handler framework into the engine. A handler will act on the message for various purposes before it is delivered to the service implementation. For example, security handlers will decrypt the message, and addressing handlers will extract addressing information. The user can add or remove handlers at any time. Axis2 has defined "phases" to label the stages of execution, so that it's more convenient for users when they deploy new handlers (you can see phases in Figure 1, shown in different colors). For example, the dispatch phase will contain all the handlers that act on the message to identify the destination service and the operation it is intended to perform. If some handler needs to act on the message before dispatching happens, for example, the addressing handler or the security handler, those can always be deployed in the Pre-Dispatch phase, which is the phase just before the Dispatch phase. The phase ordering for IN flow is as follows: Transport-In, Pre-Dispatch, Dispatch, Post-Dispatch, and user-defined phases.

Contexts - Axis2 contains a very convenient context hierarchy to hold the various levels of context information. For example, the message context, as in Axis 1.x, will contain all the context information with respect to that particular message, and the service context will contain all the information related to a particular service. This context hierarchy offers a logical grouping of information, depending on the contexts.

New Deployment Model

Deployment in any engine is bit of a headache most of the time. But Axis2 has given top priority to the deployment model by providing a better and more convenient deployment mechanism. Axis2 comes bundled with hot deployment of services, therefore administrators will no longer get busted for the downtime of their Web services engines.

Archiving Model

Axis2 supports two sets of archives: the service archive and the module archive.

A service archive contains a Web services implementation and a set of related resources like jars and descriptors. You can create a service archive, an .aar file, and hot deploy it to the Axis2 engine. Likewise, a group of related handlers can be deployed as one unit, called a module. This module can contain handlers that go to the IN pipe, the OUT pipe, or both. The module.xml file can define the places those handlers will fit in the execution phases. For example, it can say Handler A should be deployed as the first handler in Phase B. These are called phase rules, and Axis2 has a small set of rules that can be defined by the module deployer.

Modules are very important to other service providers of Axis2. For example, you can group all the security-related handlers into one module and deploy. This security module will contain all the handlers that go to both IN and OUT pipes and a module descriptor to help Axis2 deployment mechanism to put the handlers in proper places. After you get the security module and deploy it in the Axis2 engine, boom! You have WS-Security support in your engine without doing anything. Then you can directly ask the engine to run the security module for your service(s). This is one of the great new features of Axis2.

Pluggable Data Binding Support

Data binding is an important requirement for a full-featured Web services engine. One of the major drawbacks of current Web services engines is that they can work only with a particular data binding framework, limiting their flexibility. But Axis2 can work with most of the data binding frameworks available today, like JAXB, XMLBeans, JiBX, and JaxMe, without much trouble. The secret behind this ability is the loosely coupled APIs of Axis2.

Most of the data binding tools use a SAX interface and/or a StAX interface for serialization and de-serializing XML. AXIOM, the data model that all of Axis2 depends on, can work in harmony with either SAX or StAX without a problem. The data binding infrastructure in Axis2 also can accommodate plugging in any data binding tool.

So, users of Web services engines needn't be bound to a data binding framework. You can use your favorite tool without much trouble. The current Axis2 comes with its own simple data binding implementation, ADB (Axis2 Data Binding), as the default. But Axis2 has built-in support for XMLBeans and JiBX as well.

Asynchronous and Synchronous Web Services Invocation

Axis2 provides synchronous and asynchronous support for the user in three levels in the API.

  1. The user can invoke the Web service and has the option of making a particular invocation blocking or non-blocking until the response comes.
  2. The user can invoke the Web service using either one two-way transport or two different instances of transports for IN-OUT Web services.
  3. Web services implementation invocation within the engine can be done either synchronously or asynchronously.

The above three methods can be used independently of each other. For example, the user can invoke a Web service in a non-blocking way, using one HTTP transport to send the message and one SMTP transport to receive the message. This method of invocation does not need to know whether the Web services invocation happens synchronously or asynchronously on the server side. This is just one combination for the user to invoke the Web service. In my opinion, this feature, which many business users have wanted for some time, is one of the key benefits of Axis2.

Other Notable Features (in Brief)

REST Support

Accessing Web resources through REST is becoming increasingly popular. WSDL 2.0 specification standardizes exposing and accessing Web services through REST, in its HTTP binding section. Axis2 also enables exposing and accessing Web services, by implementing HTTP bindings. The beauty of the implementation is that you only have to do a few steps to enable it.

Various Attachments Standards Support

AXIOM comes with built-in MTOM support. Axis2 together with AXIOM enables SAAJ (SOAP with Attachments API for Java) and SwA (SOAP Messages with Attachments) as well.

Different Transports Support

Since Axis2 fully decouples transport-level protocol details within the engine, it can support most of the transport mechanisms available. The current version of Axis2 comes with HTTP, SMTP, JMS, and TCP transport implementations.

Tools Support

The Axis2 developer community was successful in providing tools support for some of the most popular features in Axis2. For example, the community has created tools for code generation and service archive creation. All these tools were made to be used as Eclipse plug-ins, but there are some efforts to make them work with IDEA as well.

Writing Services in Other Non-Java Languages

There are about 150 languages like E4X and Groovy that can be compiled into the JVM. Axis2 can now support the service implementations written in those languages as well. Therefore people who want to work with Groovy or Jscript can now write their services in those languages and deploy and expose them as Web services using Axis2.

WS-Addressing, WS-Security, and WS-RM support

Axis2 comes with built-in WS-Addressing support, but you can use the entire engine without using that. WS-Addressing is a key for asynchronous Web services invocations. Axis2 even provides complete WS-Security support for business users, so you don't need to worry about security issues with Web services.

WS-RM (PDF), which provides a reliable infrastructure for Web services message exchange, is now becoming available as a pluggable module for Axis2. The Apache WS-RM team is working to provide WS-RM for Axis2.

The most interesting element about these three standards is that users can employ all of them at once. For example, they can use MTOM, security, RM, and addressing all at once for a particular service. Amazing isn't it ?

Conclusion

As the successor to the Apache Axis SOAP project, Axis2 is a major improvement in the Web services core engine and aims to be the platform for the next generation of Web services and Service Oriented Architectures (SOA). With an architecture that is highly flexible and supports many additional functionalities such as reliable messaging and security, it is blazing the trail by being a clean and extensible open-source Web services platform of the future.

Resources

width="1" height="1" border="0" alt=" " />
S. W. Eran Chinthaka is a pioneering member of Apache Axis2, AXIOM and Synapse projects, working fulltime with WSO2 Inc..
Related Topics >> Web Services and XML   |