On Thu, Apr 29, 2010 at 6:23 PM, Andreas Veithen <[email protected]> wrote: > On Thu, Apr 29, 2010 at 15:46, Ruchith Fernando > <[email protected]> wrote: >> This overhead is mainly due to OM<->DOM conversion that was >> unavoidable because we used WSS4J (which uses Apache XML-Sec) which is >> based on DOM. >> >> This following effort by Saliya et al. is a project where they tried >> to implement those base libraries based on OM: >> http://wssecforaxis2.blogspot.com/ >> >> They were able to produce very good perf numbers. >> >> Maybe it is time to consider rewriting C14N, XML-Sig, XML-Enc on AXIOM? > > That is one option. The other is to develop an object model that > implements the Axiom API and DOM at the same time. Of course, this is > exactly what DOOM promised to do, but realistically speaking, that was > a failure, because it is neither a complete implementation of the > Axiom API nor a complete implementation of DOM. The fact is that it is > not able to support Axis2 (because of the missing support for > OMSourcedElement and other reasons) and its DOM implementation is just > enough to support some selected frameworks.
DOOM is certainly missing a lot of features. The reason it did not completely implement DOM (especially DOM 3 APIs) was that, at the time we developed it, we just wanted this API to be minimal such that it supported the barely minimum required to use WSS4j + XML-Sec. This was practical at that time. > > Some of the reasons why DOOM is a failure are structural/architectural: > * DOM is document-centric, while the Axiom API is factory-centric. > DOOM never provided a smart answer to that problem. Any suggestions? Because the DOOM API would be required to support both behaviors. > * The code in the DOOM classes mixes different aspects: implementing > the Axiom API, implementing the DOM API and managing the data > structures necessary to store the XML/SOAP infoset. This makes the > code very complex and difficult to maintain. The problem is worsened > by the fact that it is not possible to come up with an object oriented > design (class hierarchy) that properly models the XML infoset model > and at the same time supports the Axiom and DOM APIs in a natural way. > * ... > > It is clear that an approach that attempts to optimize WS-Security > processing by using an Axiom+DOM implementation will never be able to > leverage all the features provided by Axiom (and thus not be able to > match the performance of a native WS-Security implementation), but it > is nevertheless a very attractive one: > * No need to rewrite WSS4J and related libraries. This is an obvious > advantage because WSS4J is very stable and well tested. > * If one includes the SAAJ object model into the scope of the project, > one could get rid of the code in axis2-saaj that relies on the (in > this context) very inefficient proxy pattern. > * Parts of the JAX-WS API also rely on DOM and/or SAAJ (handlers, > provider endpoints, dispatchers). Having an Axiom+DOM implementation > would allow us to avoid conversions here as well. > * Last but not least, it would make the Axiom project more attractive > (to end users and other projects) because it would become possible to > leverage the Axiom features (deferred parsing, streaming, sourced > elements, etc.) without the need to adopt a non-standard API. For > example, the WSS4J integration in CXF uses the SAAJ reference > implementation; while the CXF project would definitely not be > interested in Axiom as an object model, it may be interested in the > deferred parsing feature, provided that Axiom has good support for > DOM/SAAJ. > * Building a new implementation of the Axiom API could be an > opportunity to get rid of some of the performance issues in Axiom as > well and to optimize its memory footprint. > > I've been working on such an implementation over the last few months, > but it's currently still in a "research" stage. It's a valid > proof-of-concept of some of these ideas, but there are still many > important aspects missing. If there is interest, I can provide more > information. Would this new implementation still require us to build the complete DOM tree in memory when we sign and encrypt content (through WSS4J + XML-Sec)? If so, wouldn't this lead us to the same issues that we face now? Thanks, Ruchith --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
