Re: WSS4J future (resent to tsik-dev@ws.apache.org)

[Aleksander Slominski <as...@cs.indiana.edu>]

hi,

comments below,

Werner Dittmann wrote:

>As for DOM centic: yes, you are right. IMHO it is not easy to use
>SAX or pull parsers or other optimizations. Several reasons:
>- during Security processing you often must alter existing elements,
>  e.g. in the Body, replace elements, insert new elements
>- The scurity elements need to refer to elements in the Body and
>  elsewhere.
>- if you need to sign/encrypt you need the real content and, in case
>  of encryption, replace it with the encrypted data.
>- depeding on the order of the security actions to perform you may
>  again need to reference / sign these elements
>  
>
yes - that is the biggest problem and not easy to overcome. the most 
natural thing is to do streaming (SAX, xml pull) and expect messages to 
have structure that is "streaming friendly" - this is possible and 
described in details in our paper A streaming validation model for soap 
digital signature <http://www.cs.indiana.edu/%7Ewelu/c14n_hpdc05.pdf> 
(presented in The 14th IEEE International Symposium on High Performance 
Distributed Computing (HPDC-14), 2005)

>- last but not least: the libraries WSS4J uses (xml-sec, xalan) are
>  also based on DOM.
>  
>
yes - this is the biggest pain - to have tightly integrated lib that 
sits just above XML stream and can do efficient streaming 
digest/encryption for *selected* subsets of events.

>Many of these things need a "full tree" to be able to navigate inside
>the tree and modify it where needed.
>
>While it may be possible to rewrite WSS4J to use SAX or pull parsers
>it will introduce additional logic to keep track of references, element
>replacements etc. These functions are available in DOM. Thus, IMHO, it
>would not be simpler - maybe even more complex from the WSS4J code point
>of view.
>  
>
i think the best approach is to use streaming when input is "streamable" 
and switch to DOM/xml-sec/xalan otherwise.

thanks,

alek

>Granqvist, Hans wrote:
>  
>
>>Hi developers,
>>
>>I currently work on the a ws.apache.org incubation project [1], and 
>>I want to see how I can contribute to wss4j and ws.apache.org. 
>>
>>I've spent some time going through the wss4j source, but I lack 
>>an overall view of what you all currently work on, or what you plan 
>>to work on, now and in the close future.  Is there a roadmap?  Is there
>>also a list of who's involved with which standards bodies development?
>>
>>Are there areas in the wss4j code that you feel could be improved?  
>>I have some ideas -- e.g., I spotted some 300+ LOC functions -- but 
>>I'd like to know what you think the real itches are (there must be 
>>some? ;)
>>
>>Are there any ideas in the core/plugin/addon structure of [1] that you 
>>think makes sense to use/work on in wss4j? (Please note that the 
>>javadocs link in [1] is somewhat out-of-date currently.)
>>
>>What does Axis2 mean for the wss4j development?  Are there Axis v1 
>>areas of wss4j that I should not waste time on because of something 
>>else, something better in the works?  I'd hate to start working on 
>>something that is slated to go away.  
>>
>>Part of my personal drive is to try to implement the identity system
>>(see more info in [2]) and that would involve some work implementing 
>>WS-* standards, plus potentially some interesting end-user APIs. 
>>Previous emails [3] on for example WS-Trust sound promising, but 
>>directions are somewhat unclear.  Comments, ideas, prioritizations, 
>>etc., mucho welcome.
>>
>>The various ws.apache.org projects working together in a non-Axis 
>>setting -- is that concept out-of-scope?
>>
>>wss4j is currently quite DOM-centric.  Do we want to get away from 
>>that?  SAX, push-pull, etc.?  
>>
>>
>>Thanks for your time,
>>Hans
>>
>>PS. I have to end with a perhaps naïve question: What exactly is meant 
>>by the wss4j "sandbox"?  Sorry, this may be obvious, but I can't figure 
>>it out.
>>
>>[1] http://incubator.apache.org/tsik
>>[2] http://incubator.apache.org/tsik/roadmap.html
>>[3] http://mail-archives.apache.org/mod_mbox/ws-wss4j-dev/200508.mbox/%3C559c463d050831142314dacd7e@mail.gmail.com%3E
>>
>>---------------------------------------------------------------------
>>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: wss4j-dev-unsubscribe@ws.apache.org
>For additional commands, e-mail: wss4j-dev-help@ws.apache.org
>
>  
>


-- 
The best way to predict the future is to invent it - Alan Kay