Andreas Veithen wrote:
On Sat, May 1, 2010 at 09:12, Dennis Sosnoski <[email protected]> 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.
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.
- Dennis
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
