The Apache Web Services Project is an umbrella project consisting of many projects. The scope of projects goes from SOAP implementations to a UDDI implementation to a host of WS-* implementation efforts. The developer community is a vibrant one, coming from a mixture of large companies, small companies, and independent consultants. The community is also global, with participants originating from the US, Europe and Asia.

In this article we briefly introduce some of the activity around the Apache Axis project, the flagship project of the Apache Web Services activities.

Axis
Apache Axis started with a total rewrite of the Apache SOAP implementation, which was the first SOAP 1.1 implementation. Apache Axis now has both Java and C++ incarnations. The Axis/Java product is a very mature product that is widely used by many vendors for SOAP enablement of their systems. In comparison, Axis/C++ is only about a year old but is rapidly gaining maturity, quality, and users. Axis/Java and Axis/C++ share a common base architecture, which at the time of its design (in 2001-02) was industry leading.

There is now a new effort, called Axis2, to redesign and totally reimplement both Axis/Java and Axis/C++ on a new architecture. Evolving from the now standard "handler chain" model that Axis1 pioneered, Axis2 is developing a more flexible pipeline architecture that can be managed and packaged in a more organized manner. This new design acknowledges the maturing of the Web services space ? in terms of new protocols such as WS-ReliableMessaging, WS-Security, and WS-Addressing that are built on top of the base SOAP system. At the time Axis1 was designed, while it was fully expected that other protocols such as WS-ReliableMessaging would be built on top of it, there was no proper extension architecture defined to enable clean composition of such layers. Thus, one of the key motivations for Axis2 is to provide a clean and simple environment like Apache Sandesha and Apache WSS4J to layer on top of.

Another driving force for Axis2 is the move away from RPC-oriented Web services towards more document-oriented, message style asynchronous service interactions. The Axis2 project is centered on a new representation for SOAP messages called AXIOM (AXIs Object Model), which is composed of two parts: a complete XML Infoset representation and a SOAP Infoset representation on top of that.

The XML Infoset representation provides a JDOM-like simple API but is built on a deferred model via a StAX-based (Streaming API for XML) pull parsing API. A key feature of AXIOM is that it allows you to stop building the XML tree and to just access the pull stream directly, enabling both maximum flexibility and maximum performance. This approach allows us to support multiple levels of abstraction for consuming and offering Web services: using plain AXIOM, using generated code and statically data-bound data types and so on.

At the time of Axis1's design, RPC-style, synchronous, request-response interactions were the order of the day for Web services. Today service interactions are much more message oriented and exploit many different message exchange patterns. The Axis2 engine architecture is careful to not build in any assumptions of request-response patterns to ensure that it can be used easily to support arbitrary message exchange patterns.

Conclusion
Axis2 is still in its infancy and many of the key decisions are still being hashed out. As we design the Axis2 core there are efforts underway to ensure that projects such as Apache Sandesha can be built on top of it without any difficulty. We welcome all contributions to this key project. We are working towards an informational milestone release soon to encourage the larger community to examine the progress so far and provide feedback on our approach.

References