[
https://issues.apache.org/jira/browse/AXIOM-447?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13593829#comment-13593829
]
Andreas Veithen commented on AXIOM-447:
---------------------------------------
You need to read the proposal more carefully. "Optimiz[ing] this code to use
new AXIOM features and bringing it inside AXIOM itself" is actually what this
proposal is NOT about. See the last item in the description of the project.
Also, the code that you mention doesn't expose an API to Spring-WS. It’s the
other way round: it is an implementation of an API defined by Spring-WS. The
GSoC project proposed here would create an alternative implementation of that
API from scratch. A priori that doesn't require changes in Spring-WS. That
being said it is possible that in the course of the GSoC project one would file
requests for enhancements to the Spring-WS project in order to enable specific
optimizations.
> [GSoC] New Axiom/Spring-WS integration
> --------------------------------------
>
> Key: AXIOM-447
> URL: https://issues.apache.org/jira/browse/AXIOM-447
> Project: Axiom
> Issue Type: New Feature
> Reporter: Andreas Veithen
> Labels: gsoc2013
>
> 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.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
