Christian, As Fred mentioned, doing the SAAJ stuff is definitely expensive, especially if the body of the message is large. With SAAJ, the entire message pretty much gets sucked into memory consuming memory, causeing extra garbage collections, etc... The Sun RI SAAJ impl isn't exactly quick either. If you CAN avoid it, it's recommended to try.
If all you need is the headers to process yourself, you could just stick an interceptor anytime after the SOAP ReadHeadersInterceptor (runs in the READ phase) and at that point, the Message will be a SoapMessage that has a "List<Header> getHeaders()" method on it. You can grab the information you need directly out of there. Doing this allows the "body" part of the message to stream directly into the jaxb objects like it normally would without having to SAAJ parse it all. Dan On Monday 21 January 2008, 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? -- J. Daniel Kulp Principal Engineer, IONA [EMAIL PROTECTED] http://www.dankulp.com/blog
