On Wed, Apr 20, 2011 at 19:56, George Stanchev <[email protected]> wrote: > Hi, > > > > I just saw a developer from the santuario-genxdm project posted this email > [1] on the xml-security mailing list stating that their project have made > the important milestone of porting xml-security over Axiom. This has > important implications on wss4j, rampart and its handling of Axiom data > without the need to bridge over DOM or usage of DOOM. So I guess this is a > question for Colm, would their work allow WSS4J to switch over to that > Axiom-based xml-security processing of signature and encryption thus > eliminating DOM unwinding? > > George > > [1] http://thread.gmane.org/gmane.text.xml.security.devel/7381
George, Thanks for bringing up this question. I also recently discovered the genxdm project and I was thinking about what this means for Rampart, WSS4J and Santuario (and also CXF). Here is my point of view (as a member of the Axis2 project and maintainer of Axiom). >From the perspective of Rampart, there are actually two strategies to solve the performance issue related to DOM vs. Axiom: 1. Create an object model that provides both a complete implementation of the Axiom API and the DOM API, so that it is able to support the Axis2 runtime and at the same time seamlessly integrate with WSS4J. I've been working for some time on a project called DDOM that tries to achieve this (see [1] for some discussion about this), and I recently completed the first successful test runs with Rampart (showing a huge performance increase). It is still work in progress and the next goal is to be able to execute Dennis Sosnoski's performance test scenarios with DDOM as Axiom implementation. 2. Make WSS4J and its dependencies work with Axiom. Some time ago people proposed to create Axiom specific forks of these projects, and people actually started doing this. That is e.g. how we got the axiom-c14n module, which appears to be a fork of some parts of Santuario. I don't think that that is a good idea. The approach proposed by genxdm is much better because the same code base could be used with both DOM and Axiom. On the other hand, things look quite differently from the point of view of the CXF project (members of the CXF project are invited to correct me if I'm wrong). It is clear that they will never adopt Axiom, but some discussions I had with Dan Kulp indicate that they may be interested in DDOM (because it also supports SAAJ and brings deferred parsing to that API). That means that for CXF, porting WSS4J and Santuario to genxdm doesn't have any added value, at least not if the goal is limited to support Axiom in addition to DOM. Things become more interesting if one looks at the question from a different angle. Instead of focusing on the question of API support, it is more interesting to look at possible ways to improve performance inside WSS4J and Santuario. I didn't carry out a thorough analysis of that question, but my impression is this (Colm, please correct me): * There are generally no performance issues in WSS4J itself because it mainly focuses on SOAP header processing and delegates the performance critical stuff to Santuario. * There are pieces of code in Santuario that seam to suffer from some intrinsic limitations of the DOM API (no streaming, no parsing of XML fragments, no deferred building of nodes). Therefore, my favorite approach would be this: * Keep WSS4J as is and use DDOM to solve the performance issues specific to Rampart. * Make sure that genxdm defines sufficiently high level APIs so that it allows to leverage particular optimizations available in object models such as DDOM and Axiom, while still providing decent implementations for DOM (I didn't check the genxdm API to see if that is already the case). * Port Santuario to genxdm so that it no longer suffers from the limitations of DOM. * Create a bridge implementation specifically for DDOM so that it can use the features available in DDOM (and currently only available via internal APIs) that go beyond what is available through the Axiom API. That approach would provide added value to all involved projects: * It minimizes the number of projects that would need to be forked or ported. * Minimal changes required to Axis2 because DDOM will provide a full featured implementation of the Axiom API (that is the key difference with DOOM, which is neither a complete implementation of the Axiom API nor a particularly good implementation of DOM). * It avoids the unnecessary conversion overhead in Rampart because DDOM also provides DOM support. * CXF can benefit from the additional optimizations in Santuario by using DDOM as a SAAJ implementation (without the need to introduce any dependency on Axiom). The same optimizations will also benefit to Rampart (but without the need to sacrifice Axiom). Regards, Andreas [1] http://markmail.org/thread/366j7pkypwxl3ppy --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
