[AXIOM-447] New Axiom/Spring-WS integration

• Type: New Feature
• Status: Open
• Priority: Major
• Resolution: Unresolved
• Assignee: Andreas Veithen
• Reporter: Andreas Veithen
• Created: 28/Feb/13 22:44
• Updated: 01/Jan/15 18:16

Description

Background:

Spring Web Services can be configured to use either SAAJ or Axiom as object model. Generally, Axiom is preferred over SAAJ because in most cases it removes the need to create complete in-memory representations of the incoming and outgoing messages. However, since the time the Axiom support in Spring WS was originally implemented, there have been many improvements and optimizations in Axiom, and some APIs have been deprecated. The Axiom support in Spring WS doesn’t fully leverage all available optimizations and in some cases uses outdated APIs. It should also be noted that Spring WS only supports LLOM, but not DOOM. When WSS4J is used to implement WS-Security, this likely causes unnecessary overhead because messages need to be converted to/from DOM.

Goal:

The high level goal of the proposed GSoC project is to implement a completely new Axiom support for Spring WS that leverages the full potential of Axiom. The new implementation is not expected to be backwards compatible with the existing Axiom support, but should support all important features of the existing Axiom support (such as MTOM and SwA). The new implementation must support DOOM and be interoperable with WSS4J. It should be tuned in order to make the Spring-WS/Axiom/WSS4J combination competitive with respect to CXF and Metro in terms of performance for the scenarios described in the series of articles written by Dennis Sosnoski:

http://www.ibm.com/developerworks/library/j-jws14/index.html

This implies that in addition to the Axiom/Spring-WS integration, the candidate for this GSoC project may be required to work on the following areas as well:

• OMSourcedElement support for DOOM: the OMSourcedElement API is used by Spring WS, but is currently only supported by LLOM
• Performance tuning of the DOOM implementation: it is likely that WS-Security performance testing will identify some areas for improvement in DOOM
• API enhancements: it is possible that the development of the new Axiom support for Spring WS will require some enhancements of the current Axiom API (e.g. to support additional optimizations)

Deliverables:

The candidate is expected to provide the following deliverables during the project:

• The code for the new Axiom support, including reasonably complete Javadoc for all public APIs.
• A test suite that provides a high level of code coverage (at least comparable to the code coverage of those parts of Axiom that are currently under active development)
• User documentation, including a quick start guide explaining how to migrate from the existing Axiom support to the new implementation.
• A report comparing the performance of the new Axiom support with other SOAP stacks for the scenarios described in the articles written by Dennis Sosnoski.

Misc:

• In its present form, the project proposes to create a new Axiom/Spring-WS integration that would be maintained by the Axiom project, while the existing implementation is maintained by the Spring WS project. Before confirming the project, the candidate is expected to engage with the Spring WS developer community to get their opinion on this proposal and to check if they are willing to provide assistance for this project. Depending on their feedback, the proposal may be modified.
• The candidate is expected to develop the new Axiom support from scratch without starting from the existing code in Spring WS. This requirement is in line with the goal of fully utilizing the features and optimizations in the current Axiom version. In addition, it avoids making the new Axiom support a derivative work (in the sense defined by the ASL) of the existing implementation.