ws-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Kulp <>
Subject Re: [jira] Created: (WSS-257) Avoid converting the SOAP Body to DOM on the processing side if possible
Date Thu, 02 Dec 2010 16:47:32 GMT
On Thursday 02 December 2010 11:20:15 am Dittmann, Werner (NSN - DE/Munich) 
> Hi all,
> just a thought here: why is this necessary or should be done? Enhance
> performance? Reduce memory footprint?

Umm.. Both.

There are a bunch of usecases where this can have relatively huge benefits.  
Some off the top of my head:

1) HTTPs used for  "encryption", but there are ws-security headers (like SAML 
tokens or username token and timestamps and such).  In such case, there is NO 
need for the body to be touched.   If the soap bodies are large, this can 
SIGNIFICANTLY reduce the memory footprint as very little is retained in a DOM 

2) Small soap messages, but LARGE attachments.  To properly sign them, the 
binary attachments must be pulled into memory, base64 encoded into a String 
(keep in mind, UTF-16, so double the memory), and added to the DOM as a text 
node.  That is a LOT of extra memory.   Ideally, we could keep the attachments 
on disk.  At least keep it in byte form and not String.   Let Santaurio handle 
the base64 encoding in small chunks that can be 
signed/hashed/verified/whatever in smaller chunks and discarded.

3) Fail fast - kind of an optimization as well, but while processing the 
username token or timestamp or something, if they fail (like the timestamp has 
expired), we could fail immediately and not spend any time parsing and 
processing the body.

4) Allow some extra non-SOAP usecases.  This is a bit more obscure, but in 
CXF, we've talked a little about how to leverage some of the WS-Sec stuff for 
REST by having the security "header" in one mime part and the REST XML payload 
in another or similar.   By having the callback mechanism, we can avoid having 
to construct a "fake" soap message to combine everything together and really 
pass just what is needed into WSS4J as needed.   

> Well, if I recall correctly then most of the processing time of WSS4J is
> spent in the crypto methods (public key processing in particular),
> signature processing and alike. IMHO tuning the DOM processing does not
> really enhance the performance and these changes may require quite some
> effort to do it.

The attachment stuff can be a HUGE performance thing for signature and crypto.  
A large attachment right now can easily result in an OutOfMemory situation.  
Working on optimizing that can be a big win.


> Best regards,
> Werner
> -----Original Message-----
> From: ext Colm O hEigeartaigh (JIRA) []
> Sent: Thursday, December 02, 2010 3:34 PM
> To:
> Subject: [jira] Created: (WSS-257) Avoid converting the SOAP Body to DOM on
> the processing side if possible
> Avoid converting the SOAP Body to DOM on the processing side if possible
> ------------------------------------------------------------------------
>                  Key: WSS-257
>                  URL:
>              Project: WSS4J
>           Issue Type: Improvement
>     Affects Versions: 1.5.10
>             Reporter: Colm O hEigeartaigh
>             Assignee: Colm O hEigeartaigh
>              Fix For: 1.6
> On an inbound request, WSS4J currently iterates through each security token
> in the security header and processes each one. However it also requires
> the entire SOAP request be converted into a DOM structure, even though it
> might not be necessary to access the SOAP body as part of processing the
> security header, e.g. processing a Timestamp, or a Username Token.
> This task is to enhance WSS4J on the processing side, so that it does not
> require access to the SOAP body. If it needs to find an element in the
> SOAP request, it should use a callback mechanism, to obtain e.g. the SOAP
> body if required. This mechanism could potentially provide support for
> signed MTOM. WSS4J should supply a default implementation that more or
> less parallels the current implementation. CXF/Rampart etc. could define
> their own callback implementations for their specific needs.
> The callback class could look something like:
> public abstract class LookupCallbacks {
> //for the wsu:ID, get the element
> Element getElementForID(Object msgContext, String i) {
>    return null;
> }
> //for processing of MTOM things eventually
> InputStream getAttachment(Object msgContext, String contentId) {
>    return null;
> }
> }

Daniel Kulp

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message