Marc Sounds like a really interesting proposal. I also slightly share Dan's concerns about community, but while this is never going to have a diversity of 10, it might easily have a diversity of 3 which is enough. I do agree with Dan that we need to involve the WSS4J community into this discussion.
On a slightly off-topic aspect, I'm personally very keen to see this succeed in one form or another, simply because I love the idea of taking work people do in their academic life, theses, etc and giving it ongoing life in Open Source. Long ago when I did my own Master's thesis I had a desire to ensure it had a future, and I completely failed and I don't even have the source code anymore (except maybe on a tape I can no longer read). I think creating Open Source projects and growing a community is a fantastic way of getting huge benefit from the academic world. So on that basis I'd be happy to mentor as well if this ends up as a podling. Finally, I'm sure you've checked, but I'll ask anyway. Some universities claim copyright to the work done in student's theses. Are you 100% sure you own all copyright? Paul On Tue, Jan 11, 2011 at 9:22 PM, Marc Giger <gigerst...@gmx.ch> wrote: > Hello All > > I would like to formally propose that the SWSSF Project will be > considered for inclusion in the ASF Incubator as a new podling. The > name of the project is not fixed and I am open for proposals. An idea > for a name was "RoadRunner" but this smells like trouble. > Please read further for a detailed description what the project is. > > Now I am looking for Mentors, contributors and other important person > to get the project accepted in the Incubator. > > I gracefully ask the Incubator PMC for sponsoring this project. > > Feedbacks about the project and the proposal would be appreciated. > > Best Regards > > Marc > > > == Abstract == > > SWSSF (Streaming-WebServices-Security-Framework) is a > streaming-based SOAP-Message-Security + > WS-SecurityPolicy implementation > > > == Proposal == > > SWSSF provides a streaming-based solution for SOAP-Message-Security and > WS-SecurityPolicy-Verification. Inbound- and Outbound-Security is > supported and based on the StAX API. > > > == Background == > > Some Parts of SWSSF were developed within my Master Thesis and > implements the SOAP-Message-Security Standard for message integrity, > message authentication and message confidentiality . Additionally a > Policy verification framework was build to get a "fail-fast" > behavior when a policy is violated. > > > == Rationale == > > Typically, it will be used a DOM based approach to do the > SOAP-Message-Security stuff in WebService-Frameworks as it > is done in Apache Axis and Apache CXF. Apache WSS4J and the underlying > Apache Santuario are the concrete implementation for WS-Security and > uses DOM. > Security-processing with DOM yields to multiple problems: > - High memory usage > - Long processing time > - Vulnerable to DoS Attacks > - Wasted computer resources in case of a security error. > > In contrast, the streaming-based approach of WS-Security shows > following characteristic: > - constant low memory usage (~5 - 15MB) independent of the document size > for inbound messages > - factor n less memory consumption on outgoing messages > - faster processing time (2 - 3 times faster) > - Vulnerability to DoS Attacks mitigated > - Minimum a computer resources are wasted in case of a security error > due to the possible fail-fast behavior in the streaming environment. > - in lot of cases a fail-fast behavior can be guaranteed by policy > violations. > > > == Initial Goals == > > SWSSF was a one man show - me. A goal would be to bring the framework, > with the help of experienced developers, in a architectural good shape > to have a good starting point for further development. > > > = Current Status = > > Currently SWSSF consists of about 200 Java-Classes > with ~18000 lines of codes and ~3800 lines test-code. > > Most of the features of WSS4J are implemented. > Some refactoring is needed and more time has > to be investigated to circumvent limitations in the streaming approach. > > > == Meritocracy == > > As already mentioned, SWSSF was developed by me. Experience to > work together with a community is limited to provided patches > to different Apache and other Projects in the community. > > > == Community == > > There exists no community around SWSSF yet. > > > == Core Developers == > > SWSSF was developed by me - Marc Giger > > > == Alignment == > > I think the project is for further development in good hands by the ASF. > Apache WSS4J and Apache Santuario are two examples which are well known > , successfully and have the same project goal as SWSS. > > > = Known Risks = > > == Orphaned products == > > Due to its small number of committers, there is a risk of being > orphaned. In my opinion the interest in this project can > fast grow, since it solves an long outstanding problem when > processing large SOAP documents. > > > == Inexperience with Open Source == > > Since I work daily on Open-Source platforms and with > Open-Source projects, I have some impressions how the > process works. I often open tickets and provide patches. > > > == Reliance on Salaried Developers == > > As already mentioned, SWSSF were developed within my Master Thesis. > So no company and the like is involved. The code is owned by me. > > > == Relationships with Other Apache Products == > > SWSSF compete with Apache WSS4J. > A possible integration (already realized) in Apache CXF. > A further integration should be possible in Apache Axis2 > > > == An Excessive Fascination with the Apache Brand == > > I believe that the project is interesting and useful and > could be a improvement for existing Apache Projects like > Apache CXF and Apache Axis2 > The Apache Brand may help attract more contributors to > improve the project. > > > = Documentation = > > Documentation exists as Master-Thesis (only in German and which must be > clarified with the University if I am allowed to release it). > Java-Doc exists to some extent. > > > = Initial Source = > > Most of the code for SWSSF is written by me. Some source code > where lend and extended from Apache Rampart, Apache WSS4J and Apache > Santuario. > > > = Source and Intellectual Property Submission Plan = > > The university confirmed that the code is owned by me and > so I can do whatever I want with it. At the moment the > code is licensed under LGPL3 for different reasons. > If the project will accepted by Apache I have no problem > to re-license the code under the ASL > > > = External Dependencies = > > Most of the following dependencies are needed for > test code and integration testing. > > Public Domain: AOP alliance > > GNU LESSER GENERAL PUBLIC LICENSE: BeanShell > > Eclipse Public License - Version 1.0: Jetty Server, Jetty Utilities > > Unknown: ASM Core, Java API for XML Based RPC, SLF4J API Module, > Streaming-WebService-Security-Framework, Unnamed - > com.sun.xml.messaging.saaj:saaj-impl:jar:1.3.2, Unnamed - > javax.xml.bind:jaxb-api:jar:2.1, Unnamed - > xalan:serializer:jar:2.7.1-mgi, Unnamed - xalan:xalan:jar:2.7.1-mgi, > jaxen > > Bouncy Castle Licence: Bouncy Castle Provider > > Apache License, Version 2.0: TestNG COMMON DEVELOPMENT AND DISTRIBUTION > LICENSE (CDDL) Version 1.0: SOAP with Attachments API Package The > Apache Software License, Version 2.0: Activation 1.1, Annotation 1.0, > Apache CXF API, Apache CXF Command Line Tools Common, Apache CXF Common > Schemas, Apache CXF Common Utilities, Apache CXF Runtime Core, Apache > CXF Runtime HTTP Jetty Transport, Apache CXF Runtime HTTP Transport, > Apache CXF Runtime JAX-WS Frontend, Apache CXF Runtime JAXB > DataBinding, Apache CXF Runtime SOAP Binding, Apache CXF Runtime Simple > Frontend, Apache CXF Runtime WS Addressing, Apache CXF Runtime WS > Security, Apache CXF Runtime XML Binding, Apache Geronimo JAX-WS 2.1 > API, Axiom API, Axiom Impl, Commons Codec, Commons Lang, Commons > Logging, JCommander, JavaMail 1.4, Log4j, Neethi, Servlet 2.5, Spring > Framework: Beans, Spring Framework: Context, Spring Framework: Core, > Spring Framework: Web, StAX API, Streaming API for XML (STAX API 1.0), > Unnamed - com.google.inject:guice:jar:2.0, WSS4J, Web Services Metadata > 2.0, Woodstox, XML Commons External Components XML APIs, XML Commons > Resolver Component, XML Security, Xerces2 Java Parser, XmlSchema > > CPL: WSDL4J > > CDDL 1.0: JAXB RI > > GPL2 w/ CPE: JAXB RI > > Apache Software License - Version 2.0: Jetty Server, Jetty Utilities > Common Public License Version 1.0: JUnit > > > = Cryptography = > > Yes, SWSSF depends strongly on cryptography. > > > = Required Resources = > > == Mailing lists == > > The following mailing lists will be required: > > * swssf-private > * swssf-dev > * swssf-commits > * swssf-users > > == Subversion Directory == > > https://svn.apache.org/repos/asf/incubator/swssf > > == Issue Tracking == > > JIRA SWSSF (SWSSF) > > = Initial Commiters = > > * NAME EMAIL > * Marc Giger gigerstyle at gmx dot ch > > > = Sponsors = > > == Champion == > > ?? > > == Nominated Mentors == > > ?? > > == Sponsoring Entity == > > ?? > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > > -- Paul Fremantle Co-Founder and CTO, WSO2 Apache Synapse PMC Chair OASIS WS-RX TC Co-chair blog: http://pzf.fremantle.org p...@wso2.com "Oxygenating the Web Service Platform", www.wso2.com --------------------------------------------------------------------- To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
