Andreas Veithen wrote:
On Mon, May 3, 2010 at 07:02, Dennis Sosnoski <d...@sosnoski.com> wrote:
...
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...
From what I've seen CXF always builds the DOM representation of the
entire message and passes it to WSS4J anytime WS-Security is configured,
just as Axis2 does (though Dan did add a check to disable response
message WS-Security handling if only UsernameToken is used). The
approach I'm suggesting would only build a DOM representation of the
Body if the security handling actually signed or encrypted the Body (or
any part of it).
- Dennis
