This performance hit is likely due to the fact that the WSS4J
interceptors require DOM structures for processing through the WSS4J
interfaces. So you are paying for DOM-ifying your entire message.
If you are using WS-Security to simply propagate security tokens
(E.g., UsernameTokens), then you should consider managing this yourself.
If, on the other hand, you require the full functionality of WSS4J,
e.g., to sign and/or encrypt messages, then you'll need to stick with
the current approach. (In which case the cost you'll pay for DOM will
likely be eclipsed by the overhead associated with public-key crypto,
c14n, etc.)
-Fred
On Jan 21, 2008, at 5:38 AM, Christian Vest Hansen wrote:
Hi,
We've rolled our own specialized WS-Security in-interceptor
(implementing PhaseInterceptor) to integrate with our single sign-on
system.
This is all nice, except that this interceptor seems to add quite an
overhead to our web services.
The interceptor operates in the UNMARSHAL phase and specifies its
placement in the PhaseInterceptorChain to be AFTER a SAAJInInterceptor
and an RPCInInterceptor.
It uses the SAAJInInterceptor's SOAPMessage to read the WS-Security
headers, and the RPCInInterceptor is used for improved fault handling.
I haven't done any real profiling on it yet (shame on me), but I'm
thinking that maybe the SAAJInInterceptor is one of bad guys,
performance wise, and we've discusses if we should read the wss
headers with stax instead.
I wonder if you have any performance tips, or other ideas that might
help improve this setup?
--
Venlig hilsen / Kind regards,
Christian Vest Hansen.
