[
https://issues.apache.org/jira/browse/AXIOM-447?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13601506#comment-13601506
]
Andreas Veithen commented on AXIOM-447:
---------------------------------------
I wouldn't call DOOM mature code. Over the last couple of Axiom releases, there
have been some drastic changes in the DOOM implementation.
The profiling should be done once the Spring WS integration is sufficiently
complete to execute Spring-WS+DOOM+WSS4J scenarios. Obviously, in all realistic
use cases, the service will be implemented using a databinding such as JAXB
(this is the case also in Dennis' scenarios). However, support for databindings
will require OMSourcedElement support (to enable streaming for outgoing
messages). Therefore, in the GSoC project, implementation of OMSourcedElement
support would happen before optimizing DOOM.
> [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]
