Re: WSS4J future

[Aleksander Slominski]

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 (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/[EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- The best way to predict the future is to invent it - Alan Kay