ws-sandesha-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andreas Veithen <andreas.veit...@gmail.com>
Subject Re: Performance Comparison
Date Tue, 04 May 2010 08:07:46 GMT
On Tue, May 4, 2010 at 04:05, Dennis Sosnoski <dms@sosnoski.com> wrote:
> 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.

Your statement assumes that the memory/processor overhead in Axiom is
caused by the deferred parsing/building support. I don't think that is
true. I think the reason is simply the way (the default
implementations of) Axiom stores the information. For example, storing
the attributes and namespace declarations of an element in hash maps
is probably suboptimal. In SOAP messages, the average number of
attributes (resp. namespace declarations) on elements having at least
one attribute (resp. namespace declaration) is probably less then 2.
Therefore the overhead of creating and maintaining a hash map is
probably not justified by any gain in access performance.

>  - Dennis
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: wss4j-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: wss4j-dev-help@ws.apache.org
>
>

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


Mime
View raw message