incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Fremantle <pzf...@gmail.com>
Subject Re: [PROPOSAL] SWSSF (Streaming-WebServices-Security-Framework) for Incubator
Date Thu, 13 Jan 2011 06:18:35 GMT
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 <gigerstyle@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-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@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
paul@wso2.com

"Oxygenating the Web Service Platform", www.wso2.com

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org


Mime
View raw message