A big milestone was reached when Apache Axis2 1.0 was released in May 2006. Axis2 1.1 will be released in November 2006, with lots of new features, mostly initiated by its user community, and numerous bug fixes making it more and more stable. Axis2 has come a long way since its Apache Axis and Apache SOAP origins. Not only is it more efficient, modular, and XML-oriented, it is also flexible and extensible and it implements enterprise features such as security and reliability. The ease of use and functionality of Apache Axis2 really makes it the next generation web services platform. And in this article, you will see how much has been achieved. You'll see a mature product that supports the new generation of interoperable standards such as WS-Security, WS-Reliable Messaging, and WS-Addressing.
Figure 1. The component view
AXIs Object Model (AXIOM) is the XML object model for Apache Axis2. The kernel layer on top of Axiom consists of the engine, the module, and the deployment frameworks. There are no Java™-specific concepts inside the core parts of Axis2. All other components are layered on top of the kernel. The various transports (for example, HTTP and SMTP) and data binding (converting XML to and from Java code) are not in the core and because they are pluggable, they provide a lot of flexibility. All other relevant technologies, such as Java API for XML Web Services (JAX-WS), are layered on top of Axis2.
We'll now examine the following components of Axis2:
- AXIOM (the new XML Infoset representation)
- Extensible messaging engine
- Pluggable module architecture
- Improved deployment model
- New client API
- Pluggable data binding
- Representational State Transfer (REST) support
AXIs Object Model (AXIOM) is an XML object model designed to improve both memory use and performance during XML processing and is based on pull parsing. By using the Streaming API for XML (StAX) pull parser, AXIOM (also referred to as OM) can control the parsing process to provide deferred building support. Deferred building is the ability of AXIOM to partially build the object model while the rest of the model is built based the user's needs. The following example illustrates the concept:
Suppose a user needs to get the value of
<Location> element of the
first person from an XML input stream, AXIOM builds the object model up
to the end of
<Location> element and leaves the rest in the stream:
Listing 1. AXIOM partial build of object model
<Persons> <Person> <Name>Dihini Himahansi</Name> <Sex>Female</Sex> <Location>Colombo, Sri Lanka</Location> <--- Object model is being built only up to this point </Person> <Person> <Name>Thushari Damayanthi</Name> <Sex>Female</Sex> <Location>Elpitiya, Sri Lanka</Location> </Person> </Persons>
The advantage here is that the memory is used only to satisfy user needs as much as possible. If a user wants to access first couple of bytes or kilo bytes in a larger document, then the deferred building capability will enhance the memory requirement of that application.
You can get StAX events from any element, regardless of whether the object model is fully built or not. There are some cases in which this feature becomes handy inside Axis2. For example, when Axis2 is mediating messages, and if it needs to read only the headers of the SOAP messages, AXIOM prevents it from reading the whole SOAP message, making it highly memory efficient. Another example would be when a web service implementation can consume StAX events directly, because of AXIOM, the memory requirements are very low for that web service.
In addition, AXIOM has built-in support for Message Transfer Optimization Mechanism (MTOM). With the AXIOM architecture, you can execute your own object model by implementing AXIOM interfaces and plugging them into Axis2.
Because AXIOM initially started as the object model for Axis2, AXIOM comes with SOAP interfaces built on top of base AXIOM APIs. This allows you to look at SOAP using convenience methods like
AXIOM has proven to be fast and efficient compared to other widely used object models. See Resources for some performance tests done with AXIOM.
As we mentioned earlier, the Axis2 engine is a pure SOAP processor and doesn't depend on any Java-specific specification. For example, JAX-WS will be implemented as a layer on top of Axis2 and won't leak into the core.
Figure 2. Extensible messaging engine
Once a message is received by the engine through a transport, the engine calls the preregistered set of interceptors called handlers. Handlers normally process the information inside the SOAP headers, although they have no limitations on processing other parts of the message as well. The message is then handed to a message receiver -- the ultimate recipient of the message. The message receiver also is responsible for dealing with the message accordingly, and most of the time will hand this message to a service implementation class for processing.
Axis2's core message processing parts can be modeled using a set of pipes. An incoming message to the Axis2 engine goes through the "in" pipe. All outgoing messages go through the "out" pipe.
Figure 3. Piping model of Axis2
The combination of the variable number of in and out pipes enables Axis2 to handle any MEP. For example, one in pipe and one out pipe can be used to enable an in-out interaction. One in pipe can be used to enable in-only interaction. The connecting of these pipes is done by the message receiver.
Axis2 can handle most MEPs defined in the Web Services Description Language (WSDL) 2.0 specification and can be extended to support any custom MEP.
The inside of every Axis2 pipe is divided logically into areas called phases. (Phases are a logical set of handlers in a pipe.) These phases are named to represent what happens to a message during that phase. For example, the first phase of the in pipe is the
TransportIn phase and all of the handlers which does transport information processing can be there. Handlers in the
Dispatch phase will identify to which service and operation this message is destined.
These phases come in handy, especially when trying to deploy new handlers, since we can specify in which phase the handler needs to be executed.
The Axis2 environment needs to keep information in different levels. For example, information that is common to the whole engine should be maintained at the system level, while the message-level information should be kept at the message level. Some information is dynamic and some is static. To address those various requirements, Axis2 has a context hierarchy to maintain information at different levels.
Figure 4. Context hierarchy
The left-hand side of the hierarchy contains all the dynamic information, while the right-hand side of the hierarchy contains static information that is mostly read from files.
MessageContext contains information relevant to the message that is being processed, and
OperationContext has the information relevant to the particular MEP this message belongs to.
ConfigurationContext contains system-wide dynamic information, while
AxisConfiguration contains system-wide static information mostly read from axis2.xml.
Every message that comes into the Axis2 engine is destined for a particular service and operation. Identifying this service/operation combination is called dispatching, and the Axis2 engine provides four basic ways to do that:
Dispatching based on request URI: Sometimes you can identify the service the message is destined for by looking at the request URI. For example, the request URI "http://myip/axis2/service/StockQuoteService/getQuote" can be used to identify that the message is destined for the
Transport information: The
SOAPActionHTTP header can be used to determine the service and operation.
- WS-Addressing headers: If the incoming message contains WS-Addressing headers, they also can be used for dispatching.
- The QName of the first child of the SOAP body also can be used if the name was defined using RPC rules.
Those are some of the basic features of the Axis2 engine. We'll look now at how modules provide an extension mechanism for Axis2.
Modules provide an extension mechanism to the server. Each module in Axis2 contains a set of related handlers. For example, a WS-Addressing module will contain a set of handlers for WS-Addressing support for the Axis2 engine. An Axis2 administrator can add WS-Addressing support to an Axis2 engine by downloading a WS-Addressing module and deploying it in the Axis2 engine. The module.xml file contains rules to designate which pipe and phase the handlers should go in.
Figure 5. Pluggable module architecture
The module is useful because if you need support for a WS-*, the proper module can be downloaded and deployed without worrying about where the handlers should go. Modules have the .mar extension to denote module archive. Following are several modules supporting WS-* specifications that have already been built:
- Sandesha2 module: Provides WS-Reliable Messaging support
- WS-Addressing module: Provides WS-Addressing support for Axis2
- Rampart and Rahas modules: Provide WS-SX (security-related specifications) support
- Kandula module: Provides WS-AT support
- Savan module: Provides WS-Eventing support
Once a module is deployed in the Axis2 engine, it is "available" and can be engaged. Engagement of a module can be done at the following levels, depending on the requirement:
- System level: The module will affect the entire system and the handlers in this module will work on all messages that come into the system.
- Service level: Handlers in this module will work on messages that are destined for a particular service. These handlers should always be deployed after the dispatch phase.
- Operation level: Handlers in this module will work on messages that are destined for a particular operation. These handlers should always be deployed after the dispatch phase.
When the service is deployed, modules can be engaged to the service by putting a small entry in the descriptor.
Axis2 now supports hot deployment of services into the Axis2 engine. This enables users to deploy services without restarting the server. Services should be archived ZIP files with a .aar (Axis2 archive) extension in the file name. Service archives contain the following:
- Service implementation class
- Services.xml file, which describes the message receiver it uses, any module that is required, and operations that are available
- Optional dependency libraries packed inside the lib folder
These service archive files can either be copied to the Axis2 repository, which contains all the services and modules, or uploaded through the administration console that is part of Axis2.
Axis2 can invoke a web service in two ways. The
ServiceClient API is the easiest to use but gives the user less control. The
OperationClient API provides a great deal of control during an invocation. Both APIs have built-in support for basic in-out and in-only MEPs.
Axis2 now supports both blocking and nonblocking invocation models. Nonblocking invocations are useful in designing user interfaces and when service invocations take a lot of time.
Users can now select different transports for different paths of the invocation. For example, with an in-out invocation, the user can do the following:
- Send a message using HTTP and receive the response using the same HTTP channel (use of one dual-channel transport)
- Send a message using HTTP and receive the response using a different HTTP channel (two dual-channel transports)
- Send a message using SMTP and receive the response using SMTP (two different transports)
This ability provides maximum control to the user in selecting the proper transport for interactions.
Working on a pure SOAP level is sometimes cumbersome, so most users prefer to use Java code and let the framework handle converting between XML and Java code. This is called data binding. There are many data binding frameworks available and users have preferences for various reasons. Axis2 enables most of the data binding frameworks available today without restraints. For example, Axis2 has built-in support for XMLBeans, JAXB, and JiBX, and a user can select any of these. Any other data binding framework can be plugged in easily.
Axis2 also comes with its own simple data binding framework, called Axis2 Data Binding (ADB). This allows users to download Axis2 and use it without a lot of concern about data binding frameworks. And due to the tight integration between ADB and Axis2 internals, it is expected to be better in terms of performance and generated code maintenance when compared to other frameworks. ADB was tested heavily during recent WS interoperability workshops (see Resources).
REST (REpresentational State Transfer) is gaining recognition with the introduction of Web 2.0. For some time, the REST camp and the SOAP camp have been debating which one to use. We have tried to support both in Axis2, with recent efforts in WSDL 2.0 to "marry" REST with web services.
In Axis2 users can invoke all the web services deployed in an Axis2 engine in a REST manner, but with the constraints defined in the WSDL 2.0 HTTP Bindings specification.
- WSDL 2.0 support: Axis2 now supports WSDL 2.0. We did successful initial interoperability tests during the recently concluded interoperability workshops.
- Tools support: A complex operation always needs tools to make life easier. Axis2 comes with WSDL2Java and Java2WSDL tools, together with Eclipse plug-ins to work with Axis2. Deploying the administration console in a Web container makes it easier to administer an Axis2 engine remotely.
- Various transports support: Axis2 supports HTTP, SMTP, TCP, and JMS.
- Spring support: Axis2 has built-in support for Spring services. You can write Spring beans and then easily use Axis2 to expose them as web services.
- WS-Policy integration: Axis2 fully supports WS-Policy, which is integrated into the core of the engine.
The Axis2 community provides support for users and developers though mailing lists. Visit the Apache Web Services Project to learn more.
Learn about the WSDL 2.0 Interoperability Event.
Stay current with developerWorks technical events and webcasts.
The IBM SOA Web site offers an overview of SOA and how IBM can help you to get there.
Visit the SOA and web services zone on developerWorks to learn more about SOA.
The Apache Axis2 project site
provides information on various aspects of the project.
Visit the Apache Axiom project site.
AXIOM Performance Testing results.
Check out the
Services Interop Plug-fest from September 2006.
The article Introduction to StAX provides beginner level introduction to StAX API and its usages.
Get products and technologies
Participate in developerWorks blogs and get involved in the developerWorks community.
Collaborate with a community of architects and developers in the SOA and web services discussion forums.