Hello Dan, On Wed, 12 Jan 2011 23:24:48 -0500 Daniel Kulp <dk...@apache.org> wrote:
> > Marc, > > I honestly think this would be a VERY hard project to incubate and > I'd like to suggest an alternative course of action...... > > Basically, this is an extremely targetted technology, and not exactly > a "fun" one at that. I'm willing to bet I can count the number of > people in the world that WANT to do WS-SecPol things just on my > fingers, no toes required. :-) I think building a community might > be challenging. You are right, WS-SecurityPolicy isn't/wasn't that funny, but Streaming-SOAP-Security is:) > > Colm and I have chatted off and on about similar ideas for a WSS4J > 2.0 update. Right now, Colm is hard at work on 1.6, but that's mostly > incremental updates and such, but longer term, we've definitely been > thinking about how to support a more Stax based streaming for > WS-Sec. There were also discussions a while ago about pulling some > of the policy things from CXF into WSS4J (required a Neethi 3 version > as well) that I never really had the time to pursue. Thus, it > really is inline with some of the thoughts we've had. Thus, my I share exactly the same opinion. The experience while implementing the streaming-based solution showed that a higher integration of WS-SecurityPolicy into WS-Security makes sense. Regardless, a too high integration îs also not good, because WS-SecurityPolicy covers more than just Message-Level protection as you know best. In my design there is a loose coupling between WS-SecurityPolicy and WS-Security. > suggestion would be to approach the WSS4J community and spark > discussions there and possibly use what you have as a starting point > toward the WSS4J 2.0 ideas. > > I'm not saying incubating this project is impossible. I just think > it would be fairly hard and it might be easier and more enjoyable to > work with the existing projects. > > That said, if you feel incubation is still the best option, I'd be > happy to be a mentor, but I'm not sure if I'd have much time to > contribute beyond mentor duties. At the beginning, I've considered a integration into WSS4J/Santuario, but came to the conclusion that the streaming- and DOM- based implementations do have totally different requirements. Nevertheless I'm open for your suggestion and will present my streaming-based solution on the WSS4J mailing-list to start a discussion. Thanks Dan! Best Regards Marc > > Dan > > > On Tuesday 11 January 2011 4:22:49 pm Marc Giger 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 > > -- > Daniel Kulp > dk...@apache.org > http://dankulp.com/blog > > --------------------------------------------------------------------- > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
