Mailing-List: contact java-dev-help@axis.apache.org; run by ezmlm
Precedence: bulk
Reply-To: java-dev@axis.apache.org
Received-SPF: pass (nike.apache.org: local policy)
Message-ID: <4BDF80DC.7020308@sosnoski.com>
Date: Tue, 04 May 2010 14:05:16 +1200
From: Dennis Sosnoski <dms@sosnoski.com>
User-Agent: Thunderbird 2.0.0.23 (X11/20090822)
MIME-Version: 1.0
To: Daniel Kulp <dkulp@apache.org>
CC: wss4j-dev@ws.apache.org, java-dev@axis.apache.org,
        commons-dev@ws.apache.org
Subject: Re: Performance Comparison
References: <y2n1e8c1ed41004281554hd28bda8p70093dc691c1c4e4@mail.gmail.com>
 <AANLkTiklYf0zyOfAzLYcKxoaSU3EX56LRN58ka90Sqf1@mail.gmail.com>
 <4BDEAC32.6000307@sosnoski.com> <201005032119.05950.dkulp@apache.org>
In-Reply-To: <201005032119.05950.dkulp@apache.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Daniel Kulp wrote:
> On Monday 03 May 2010 6:57:54 am Dennis Sosnoski wrote:
>   
> ...
>   
>>  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.
>   

The nice thing about using a slightly-hacked and simplified DOM is that 
everything would be automatic - as it is with Axiom now, but with 
considerably less memory and processor overhead (because this approach 
would *only* defer building the DOM representation of the Body content, 
and would build the entire Body content as a DOM whenever anything 
within the Body was accessed - a lot of the memory and processor 
overhead of Axiom relates to the incremental one-element-at-a-time build 
process). And because it'd still implement the DOM interface (or at 
least a subset suitable for use by WSS4J) applications using WSS4J could 
choose to use this or continue to use any other DOM they want.

  - Dennis

---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
For additional commands, e-mail: java-dev-help@axis.apache.org