On Mon, May 3, 2010 at 07:02, Dennis Sosnoski <d...@sosnoski.com> wrote: > Andreas Veithen wrote: >> >> On Sat, May 1, 2010 at 09:12, Dennis Sosnoski <d...@sosnoski.com> wrote: >> >>> >>> ... >>> >> >> Each of the two approaches (porting WSS4J to Axiom / building a new >> optimized Axiom+DOM implementation) have their pros and cons and I >> think there is enough room for the two. They could even be >> complementary provided that the new Axiom+DOM implementation has a >> lower memory footprint and better performance. >> >> >>> >>> As a radical suggestion, how about just implementing a build-on-demand >>> DOM >>> subset suitable for use by WSS4J and other tools? This wouldn't need to >>> support all the DOM operations (including those using NodeList). >>> >> >> That part is actually almost ready [1] (with more than just a subset >> suitable for WSS4J). However, to work with Axis2 we have no other >> choice than to support the Axiom API as well, at least the object >> model part of it (while getting rid of what you called the "mess"). >> >> [1] http://code.google.com/p/ddom/ >> > > Well, I suspect most people who've looked into the Axiom code and tried to > follow the spaghetti paths involved in building the nodes would agree with > the "mess" characterization. :-) This is not to say that the code is > necessarily poorly written, either - it's just a very complex process to try > to build a DOM incrementally, as the Axiom developers have found. > > Your DDOM project looks like an interesting 2nd-generation take on Axiom, > and as such it should definitely represent a major improvement. After > thinking it over and seeing how deferred building is actually applied with > web services, though, I wonder if a simpler approach wouldn't be better. > > On the inbound side it's pretty easy to implement deferred building, since > all the current-generation web services stacks use pull parsing. If you need > to build a DOM, you just use the pull parser to do so and supply a pull > parser facade for reading data back out of the DOM, and all the rest of the > code just works with the pull parser. The outbound side is more difficult. > ADB implements a StAX reader for pulling data out of data bound objects, but > other data bindings such as JiBX and JAXB do not. This means that if you > want to build a DOM for any portion of the bound data you pretty much need > to do the whole thing, since these data bindings use push output.
Note that ADB (neither POJOs nor generated code) no longer provides (a working) pull parser and always uses push, as the other data bindings. This is BTW an issue in some cases: http://people.apache.org/~veithen/axiom/userguide/ch05.html#d0e1102 > But that's actually not such a drawback, since it corresponds with the way > WS-* uses the data in the document - if you need a DOM representation for > *any* of the data in the SOAP Body, you probably need it for *all* the data. > It doesn't have to be that way, but in practice, how often do you see > WS-Security, for instance, applied to only a portion of the SOAP Body? > > So rather than an incremental build-on-demand model, I think an approach > which just flipped DOM on or off at the message level would work just as > well for web services. On the inbound side, if a SOAP Header is present > you'd just always build a DOM representation of the Header part so it can be > passed to handlers in an easily-manipulated form. If any of the handlers > request the content of the SOAP Body you'd then build that as a DOM and pass > it in. Outbound side is pretty much the same, with the data only requested > from the data binding if needed to build the DOM and otherwise streamed > directly to the output. Using this approach there's no need to build the DOM > incrementally, other than at this very granular Header/Body level, so all > that's required is a simple and high-performance DOM (or DOM subset) with > just enough built-in smarts to recognize the Body expansion part, along with > a StAX reader which takes a DOM as input. Sounds pretty much like CXF... > > - Dennis >
