ws-sandesha-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dennis Sosnoski <...@sosnoski.com>
Subject Re: Performance Comparison
Date Mon, 03 May 2010 10:57:54 GMT
Andreas Veithen wrote:
> On Mon, May 3, 2010 at 07:02, Dennis Sosnoski <dms@sosnoski.com> wrote:
>   
> ...
>>
>> So rather than an incremental build-on-demand model, I think an approach
>> which just flipped DOM on or off at the message level would work just as
>> well for web services. On the inbound side, if a SOAP Header is present
>> you'd just always build a DOM representation of the Header part so it can be
>> passed to handlers in an easily-manipulated form. If any of the handlers
>> request the content of the SOAP Body you'd then build that as a DOM and pass
>> it in. Outbound side is pretty much the same, with the data only requested
>> from the data binding if needed to build the DOM and otherwise streamed
>> directly to the output. Using this approach there's no need to build the DOM
>> incrementally, other than at this very granular Header/Body level, so all
>> that's required is a simple and high-performance DOM (or DOM subset) with
>> just enough built-in smarts to recognize the Body expansion part, along with
>> a StAX reader which takes a DOM as input.
>>     
>
> Sounds pretty much like CXF...
>   

 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).

  - Dennis

---------------------------------------------------------------------
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