On Monday 03 May 2010 6:57:54 am Dennis Sosnoski wrote: > 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...
:-) Got a good chuckle out of that. :-) > 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). I've thought of trying something similar to this by utilizing some sort of callback mechanism from WSS4J for finding the appropriate Element for a particular wsu:Id. The problem is that you cannot really 100% reliably figure out if we need the body or not from the policy, especially on server side where there could be different policies depending on the operation which we wouldn't know until a bit later. Thus, I'd like to be able to add something to WSS4J that it could use to find elements when there is a ref rather than always using an xpath search. There could be something more optimized put in place (like a simple String -> Element map for those elements already parsed) that could avoid the xpaths and such. However, it could also allow some delayed loading of the Body. Anyway, it's some stuff I've been noodling on a bit for a while. Not sure if I'll ever have time to actually do it. :-( Dan > > - Dennis > > --------------------------------------------------------------------- > To unsubscribe, e-mail: wss4j-dev-unsubscr...@ws.apache.org > For additional commands, e-mail: wss4j-dev-h...@ws.apache.org -- Daniel Kulp dk...@apache.org http://dankulp.com/blog --------------------------------------------------------------------- To unsubscribe, e-mail: wss4j-dev-unsubscr...@ws.apache.org For additional commands, e-mail: wss4j-dev-h...@ws.apache.org
