Introduction to Apache axis2

ArticleDirectory

• Use Case 1
• Use Case 2
• Use Case 3
• Use Case 4

Http://www.redhat.com/magazine/021jul06/features/apache_axis2/

Web Services is gaining momentum and extends large vendors now offer Web Services stacks as part of their solution portfolios. the Open Source world has played a key role in Web services by providing some excellent web services stacks that are on par with-and sometimes exceed-the quality and innovative aspects of proprietary offerings.

Apache axis2,[1]The leading open source platform, provides the basis for the Web Services stack and supports both soap (Simple Object Access Protocol) and rest (representational state transfer ). it is the foundation for building a complete Web Services stack with Apache rampart/rahas[2], Sandesha2[3], And kandula2[4]Providing support for all key Web Services specifications. With its 1.0 Release on May 6, 2006, axis2 is production-ready.

This article takes a closer look at the axis2 architecture and the specified advantages it has to offer to speed up your Service Oriented Architecture strategy. the focus will be on how to use axis2 into tively in given scenarios.

Axis2 in a nutshell

Axis2 is a third-generation open source soap stack built on the experience of Apache axis[5]And Apache SOAP[6]. It has a highly modular and flexible architecture, making it easy to Support Web Services specifications as modules. axis2 architecture took a radical approach from axis to provide more scalability, to provide improved performance, and to better support the changes that were happening in the Web Services landscape. the Web Services was moving from mostly synchronous-RPC style interactions to a message-oriented approach, which encouraged both synchronous and asynchronous interactions. the axis2 core architecture reflects these dynamics and the engine provides flexibility to support different message-exchange patterns commonly referred to as MEPs[7].

The "big picture"

The core axis2 architecture is best described using the following diwing. the digram shows the core component of the axis2 engine and also how a message is passed through the engine until it is already ed by the message consumer er, which determines the course of action it shocould take. understanding this is key when working with axis2.

The chain of handlers (interceptors) provides an extensible model for message processing that provides an easy-yet powerful-way for users to extend or change the current behavior.

Everything else is built on top of the core component. For simplicity and relevance, only the core architecture is described here.

Key concepts and invalid tural points to remember

Axis2 is built based on several key concepts. Understanding these key concepts makes it easy for a user to better leverage the axis2 architecture and maximize the extensibility it provides.

• The axis2 engine does not assume a participant message-exchange pattern; this allows a user to support any message exchange pattern. the messagereceiver interface provides an ideal extension point for users to define their own message exchange patterns. axis2 currently supportsIn_onlyAndIn_outMessage-exchange patterns.

• The messagereceiver interface also provides the flexibility for the user to do as they please with the incoming message. for example, a user cocould implement the message handler er to simply ignore the message, log the message, invoke some business logic, or simply redirect the message somewhere else. the possibilities are endless. currently, axis2 uses this flexibility to invoke spring beans, to invoke a method in a pojo, or simply to consume the raw XML message.

• Support for both asynchronous and synchronous interactions is a key requirement in Web services as both styles have strong use-cases. axis2 provides this flexibility at the transport layer by allowing responses asynchronously via the same transport or via a different transport. for example, if a request comes via HTTP and the processing is done asynchronously, the reply can be sent via HTTP or it cocould leverage a completely different transport, such as JMS.

• Axiom is a new object model that was introduced with axis2. it builds on the streaming-pull parser and improves performance tremendously over axis. The differed parsing reflect CES the memory footprint when processing soap messages.

• the extensibility of the soap processing model occurs via the concept of handlers and phases. handlers can be thought of as a pipeline that passes the message context through. A phase is a logical grouping of handlers and contains rules such as " phase first ", " phase last ", " before ", and " after ", which defines a very flexible execution framework. each handler is responsible for processing a certain aspect of the SOAP message. for example, the addressing handlers deal with the WS-Addressing headers in the SOAP message.

• The concept of modules, which is designed to add support for Web service extensions, improves the extendability of the axis2 core architecture to support varous web service specifications such as WS-Addressing or WS-Security. it is basically a logical grouping of a set of handlers and related classes that extend the soap processing model to support a web service extension. these modules can be engaged dynamically per service, giving the end user very fine granularity in controlling the behavior of a web service.

• Hot deployment for modules and services is another key improvement over the axis 1.x family. It introduces a new archive format for packaging services and modules.

• Support for exposing pojos as Web services is another point worth mentioning. the built-in support provided via rpcmessagereceiver and the clean API provided to add a pojo as a Web service make it relatively easy to expose a pojo with few lines of code.

• Support for multiple transports such as HTTP, JMS, SMTP, and TCP greatly improves the usability of axis2 in a wide variety of environments.

• Axis2 is easily embeddable in a standalone application or can be packaged in your own web archive file, giving the end user the flexibility in deciding the deployment and packaging options.

How can axis2 accelerate your SOA strategy

Now that you have the basic ideas about axis2, let's look at some case studies and questions from the community. we can use these to learn more about the advantages of axis2 while demonstrating how axis2 can help you define tively implement your Service Oriented Architecture strategy.

Use Case 1

Company A has an existing application and there is a requirement to expose certain business interfaces as Web Services. This application is a non-web application.

How axis2 can help

axis2 provides easy support for exposing a pojo as a web service. axis2 is also highly embeddable. the developer cocould easily include the axis2 jars and, in a few simple steps, can leverage the API callto register a pojo as a web service and embed axis2 in the existing application. also, the developer has several choices for transports. they cocould use TCP, JMS, or even HTTP via the simplehttpserver encoded in axis2. the simplehttpserver is not production-ready and may not scale well under increased traffic. however, current work is being done to improve it to production strength. below is a simple example:

Use Case 2

Company B has a Web application and now they want to expose some of the business logic as web services to 3rd-party companies. for easy maintenance and convenience, axis2 has to be bundled within the same war file.

How axis2 can help

As mentioned above, axis2 has an easy way of exposing pojos as Web Services. axis2 can also be easily embedded in a war file. You simply need to add the axis2 jars inLibDirectory and then provideServices. xmlUnderWEB-INFFolders as your strated below. You also need to add the axisservlet in yourWeb. xml.

Use Case 3

You need to develop an application from scratch Based on the Web Services architecture.

How axis2 can help

Axis2 always encourages schema/WSDL first approach and has excellent support for it. once you design your schema/WSDL, you cocould leverage the code generation tools to provide with the code; the developer needs only to fill in the business logic. the application can be packaged in a war file and deployed in a Web Container or it cocould be run on its own using a transport other than http.

Use Case 4

What are my choices in manipulating the soap body? How does axis2 facilitate this?

How axis2 can help

Axis2 provides you several choices. basically if you prefer to work with raw XML, then raw XML based message receivers will provide you with an axiom representation of the XML that is very easy to navigate and manipulate.

If you desire to work with objects themselves, then data binding can be used partition tively. axis2 comes with ADB (axis data binding), which has limited data-binding support, but you cocould easily use xmlbeans or jaxme or jibx as your data binding framework. below is an example of the basic differences in the two approaches:

No login required. Want to see your comments in print? Send a letter to the editor.

Summary

Apache axis2 is an open source web-services platform that provides the foundation to build a complete Web Services stack that supports both soap and rest based applications. axis2 has very strong support in the key areas within the web services paradigm, which makes it stand above the rest. it is stronugly recommended for any organization that is interested in developing Web Services-based applications.

References

[1]Apache axis2 (http://ws.apache.org/axis2)

[2]Apache rampart/rahas (http://ws.apache.org/axis2/modules/rampart/1_0/security-module.html)

[3]Apache sandesha2 (http://ws.apache.org/sandesha/sandesha2)

[4]Apache kandula2 (http://ws.apache.org/kandula/2/index.html)

[5]Apache axis (http://ws.apache.org/axis)

[6]Apache SOAP (http://ws.apache.org/soap)

[7] MEP (message exchange patterns) (http://www.w3.org/TR/2004/WD-wsdl20-patterns-20040326/)