Hi Andreas/George, > 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.
Do all of the WSS4J unit tests pass using DDOM, or if not what remains to be done to get them to pass? Does using DDOM deliver a performance benefit when just dropped in as the DOM implementation, or is it necessary to use lower-level APIs? > 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. I'm not at all keen on this idea, I would like to avoid the possibility of forking code as much as possible. > * 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. I wouldn't be 100% confident of saying there are no performance issues in WSS4J :-) I think it's fair enough to say that Santuario does most of the heavy lifting though. I'm currently doing quite a lot of work on a Santuario 1.5.0 release, which comprises of some performance improvements. > * Keep WSS4J as is and use DDOM to solve the performance issues > specific to Rampart. Agreed. > * Port Santuario to genxdm so that it no longer suffers from the > limitations of DOM. I've sent a mail to Eric Johnson asking him some questions about the santuario-genxdm project. It may be that it could be accommodated as a subproject of Apache Santuario. I don't really like the idea of forking a project and changing one particular aspect of it, as subsequent bug fixes could easily not make it into the fork. I don't think there is scope for the current XML Security for Java project in santuario to move to genxdm, but as I said, maybe it could become a subproject. Colm. On Wed, Apr 20, 2011 at 10:14 PM, Andreas Veithen <[email protected]> wrote: > 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] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
