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
