+1..
Mvgr,
Martin
Phil Steitz wrote:
> I have changed the proposal to indicate that initial source will not
> be made available until the software grant is executed. Other than
> that, the proposal is unchanged from the original submission. Full
> text is attached below.
>
> Votes, please. The vote will remain open for 72 hours, closing 2 July
> 0200 GMT.
>
> [ ] +1 Accept this project into the incubator
> [ ] -1 No, because....
>
> Thanks!
>
> Phil
>
------------------------------------------------------------------------------------------------------------------
>
>
> Java Resource Simulator (JRS) Proposal
>
> The following is a proposal for a new top-level project within the ASF.
>
> Abstract
> -------------
> The Java Resource Simulator (JRS) is a Java-based interface response
> capture/playback tool for testing purposes, intended for use in
> development or testing environments.
> Proposal
>
> JRS will provide a lightweight (meaning no or very little code changes
> to the application under test) utility for Java applications that
> simulates interactions with remote services, without having to have an
> active connection to those remote services. JRS is currently a
> community source, internal project at American Express. This proposal
> is to develop the JRS code and community at the ASF.
>
> Background
> -------------------
> A big problem that legacy-dependent development groups have is that
> when developing new applications, the legacy systems that they depend
> on move relatively slowly from a development and integration
> standpoint, are often unavailable during development and test and
> require long lead times to set up test data sufficient to give good
> path and data coverage for front end testing. For this reason, people
> tend to develop ad hoc "simulators" or "smart stubs" over and over
> again to enable modularity in development. JRS aims to provide a
> generic solution to this problem, or at least to minimize the work
> required to set up and maintain effective resource simulators.
>
> Rationale
> --------------
> Increasingly, systems are being built by aggregating services from
> multiple sources. While there are a number of advantages to this
> approach, testing these service-client systems can be a challenge.
> Test services have to be deployed and maintained, test data must be
> managed, test service nodes must be up and running and accessible to
> clients. Every additional service used adds an additional dependency
> that makes testing harder to coordinate, execute, and manage in a
> repeatable fashion.
>
> Core use cases that JRS aims to address:
> 1. Mock Design. When building a system, external resources are not
> yet available, so those interfaces can be simulated by manually
> writing hard-coded responses which are played back through JRS. The
> manually-written responses may allow more experimentation in new
> development situations where the interactions are not clear, and when
> established these test cases may help drive the final definition of
> the interfaces.
> 2. Code Coverage. When attempting to achieve high code coverage in
> a set of tests, it may be easier to artificially hard code responses
> from external systems rather than attempting to prod the desired
> behavior out of those external systems. The responses are then played
> back through JRS.
> 3. Test Without Dependence. When building a system, it may be
> problematic to repeatedly execute tests against external resources,
> because they are unstable, intermittently available, inaccessible, or
> just difficult to repeatedly populate with test data sets. The
> external interactions are recorded once, possibly edited, and played
> back multiple times as needed without requiring that the external
> resources be available. In this way, regression tests can be run
> against the system-under-test without having to coordinate with
> external systems.
> 4. Stress Test. JRS can be used for pre-production stress testing.
> This is not a substitute for production stress testing since it is the
> interaction with external resources themselves where bottlenecks often
> occur and JRS is only simulating these interactions. Stress testing
> using JRS can help identify bottlenecks within the system under test
> itself, and offers the advantage that delay factors can be
> artificially varied in order to observe the effect of changing remote
> system latencies.
>
> JRS will provide a framework for simulating remote systems in each of
> the following ways:
>
> * Interactions can be recorded (this requires the remote service
> to be connected), and later played back (the remote service does not
> have to be connected).
> * Request/response pairs can be manually added or edited (e.g.
> after having been recorded).
> * Custom Java handlers can be defined
>
> JRS will operate as a library (jar file) that is included with the
> application that intercepts calls to supported protocols. The
> persistence component ("JRS server" -- for record/playback) can run in
> the same JVM as the system under test, or it can be run remotely as
> indicated in a JRS configuration file. The current (working) version
> supports JMS, Session EJBs, and web services. Support for JDBC is in
> early stages of development.
>
> Why ASF?
> ---------------
> The developers of JRS are interested in joining the Apache Software
> Foundation for several reasons:
> * We would like to see the framework extended and improved via
> open, standards-based development.
> * We would like open development of JRS to take place within the
> ASF legal, licensing and oversight structure.
> * As indicated in the "Alignment" section below, JRS has
> dependencies on and natural connections with several ASF projects. We
> would like to establish and leverage cross-pollinating relationships
> with these communities to improve the design of JRS, its
> standards-compliance, and ease of use.
>
> Initial Goals
> -----------------
> In addition to establishing an open development community, the
> immediate goal is to continue the development of the framework. Main
> areas of effort:
> * Add JDBC support.
> * Provide JRS server real-time console.
> * Implement additional mechanisms to reduce record conflicts (same
> recorded input generates different responses at different times).
> Options include understanding ordered sequences or more generally
> support for stateful client-server dialogs, as well as techniques to
> map test sequences to separate namespaces.
> * Implement multi-user JRS server support, enabling separate
> projects to share a common test server.
> * Implement more robust JRS configuration management for n client
> x m server scenarios.
> * Full JMS support (currently only pseudo synchronous supported).
> * Add import/export to facilitate early stage test-driven development.
>
> Current Status
> ---------------------
> JRS is currently a community source, internal project at American
> Express. The code base has been in development for 18 months and an
> initial internal release is being used by American Express development
> projects. Along with several other internally maintained components,
> JRS was opened internally as a community source project earlier this
> year.
>
> Meritocracy
> ----------------
> The JRS project will be meritocractic open development. The purpose of
> this submission is to make a quality product that will be used by many
> users, and the only way to achieve that is by recognizing the value of
> community. There are many difficult design and implementation problems
> to solve in JRS and we feel strongly that open, meritocratic
> development will result in a substantially better, more extensible and
> fully-featured product than we could develop internally.
>
> Community
> ----------------
> JRS has been developed over the last couple of years as a corporate
> internal project, with most of the work done by three developers and
> one architect. Nevertheless, there has been from the beginning an
> interest to eventually open source the project, as such the project
> has been opened as an internal "community source" project at American
> Express. While this clearly does not equate to an open source
> community development, we believe it gives us a strong base to build
> upon.
>
> Core Developers
> -----------------------
> The initial developers for the project are associated with the
> donating company. Two of the developers have worked on open source
> projects before (one is an ASF member) and have experience with open
> development principles. There are a number of other strong developers
> in the internal community that have expressed interest and we expect
> will prove themselves worthy committers in a short period of time. In
> addition, there are some current ASF committers interested in
> participating in the project and we have included them in the list of
> initial committers.
>
> Alignment
> --------------
> The initial code has been implemented in Java and uses a number of
> Apache and other open source components, such Maven, Log4J, XStream,
> JUnit, etc. It is expected that further integration may happen with
> Apache projects such as Oro (regular expressions processing of
> requests), Axis/CXFire/Mina (alternative JRS client-server protocol
> and server implementation), Derby (for DBMS persistence of messages),
> Struts (for JRS server console), and ActiveMQ (for processing JMS
> selectors during playback).
>
> Known Risks
> ------------------
> Orphaned products
> ---------------------------
> The initial committers are users of this package and have a long-term
> interest in use and maintenance of the code. All of the active
> developers would like to become JRS Committers and plan to remain
> active in the project.
>
> Inexperience with open source
> ------------------------------------------
> The initial committers have varying degrees of experience with open
> source projects as users, participants or committers, with one being
> an active ASF member. All have been involved with source code that has
> been released under an open source license and with internal open
> source projects.
>
> Homogeneous developers
> --------------------------------------
> Since the Java Resource Simulator has been developed to date by
> American Express, the initial contributors to the project are
> associated with that corporation, though not all are employees of
> American Express. They are experienced working in a geographically
> distributed and diverse team and they have a broad range of
> experiences with open source, industry standards, emerging
> technologies and product development. Furthermore, our strong
> intention is to attract a diverse set of additional committers, beyond
> the initial contributors and current Apache committers listed below.
>
> Reliance on salaried developers
> ---------------------------------------------
> It is expected that, at the beginning, JRS development will occur on
> both salaried time and on volunteer time, after hours. While there is
> reliance on developers associated with American Express, through the
> incubation process, we expect the independent Community to become
> actively involved in the project.
>
> No ties to other Apache products
> -----------------------------------------------
> JRS currently uses or is planned to use a number of Apache and other
> open source projects. These have been outlined above.
>
> A fascination with the Apache brand
> ---------------------------------------------------
> JRS has been started as a response to real and critical needs of
> development projects over many years. The originating environment has
> been IT internal of a non-software company, as such there was/is no
> need to associate the Apache brand with JRS. We believe that JRS will
> solve in an elegant and lightweight manner development lifecycle
> problems and, as such, we are interested in the best way for the
> project to develop and flourish. We have no interest or intention of
> "productizing" JRS for commercial purposes or offering paid services
> associated with its use; though part of our motivation for pursuing
> open development of JRS under the ASL is that this will not prevent
> others from doing so.
>
> Scope of the project
> ----------------------------
> The scope of the JRS project at ASF would be to continue the product
> development and would include adding new features and improving
> performance, scalability, quality, and extensibility.
>
> Documentation
> ---------------------
> Documentation is available on request. See below.
>
> Initial source
> -----------------
> Initial source code for the project will be granted (see next section)
> to the ASF on acceptance of this proposal and once granted it will be
> made publicly available and the normal Incubator IP Clearance process
> will be followed to approve inclusion of the initial sources in the
> project source repository.
>
> Source and Intellectual Property Submission Plan
> -----------------------------------------------------------------------
> American Express is prepared to submit a code grant and a CCLA and to
> license all JRS code under the ASL. All rights to the current codebase
> are owned by American Express. The initial committers have or will all
> submit ICLAs.
>
> External Dependencies
> ----------------------------------
> The current implementation depends on the following components:
> * XStream- BSD- [WWW] http://xstream.codehaus.org/license.html
> * JUnit- CPL - [WWW] http://www.opensource.org/licenses/cpl.php
> * Maven - ASF
> * Log4J - ASF
> * J2EE API - CDDL
> * XPP3 - [WWW]
> http://www.extreme.indiana.edu/viewcvs/~checkout~/XPP3/java/LICENSE.txt
> All dependencies have ASL or ASL-compatible licenses.
>
> Cryptography
> ---------------------
> JRS currently makes no direct use of cryptographic functions.
>
> Required resources
> ---------------------------
> Mailing lists
> ----------------
> * jrs-private (with moderated subscriptions)
> * jrs-dev
> * jrs-commits
> * jrs-user
>
> Subversion or CVS repositories
> ---------------------------------------------
> JRS would like to use a Subversion repository: [WWW]
> https://svn.apache.org/repos/asf/incubator/jrs
>
> Issue tracking
> --------------------
> Since JRS would have its own release cycle, it should have its own JIRA
> project
> * Project Name: JRS
> * Project Key: JRS
>
> Initial set of committers
> -----------------------------------
> * Brendan McCarthy (brendan_dot_mccarthy_at_ gorillalogic_dot_com)
> * Tony Ambrozie (tony_dot_a_dot_ambrozie_at_aexp_dot_com)
> * Phil Steitz (psteitz_at_apache_dot_org)
> * Ian Gray (ian_dot_d_dot_gray_at_aexp_dot_com)
> * Rahul Akolkar (rahul_at_apache_dot_org)
> * Sebastian Bazley (sebb_at_apache_dot_org)
> * Martin van den Bemt (mvdb_at_apache_dot_org)
> * Henri Yandell (bayard_at_apache_dot_org)
>
> Affiliations
> -----------------
> Tony Ambrozie, Phil Steitz and Ian Gray are employees of American
> Express. Brendan McCarthy is an employee of Gorilla Logic, working
> under contract to American Express. The rest are ASF committers
> working for distinct companies. As individuals, none of the ASF
> committers have any contract or employment relationship with American
> Express.
>
> Sponsors
> -------------
> Champion
> ---------------
> * Phil Steitz
>
> Nominated Mentors
> ----------------------------
> * Phil Steitz
> * Sebastian Bazley
> * Martin van den Bemt
> * Henri Yandell
>
> Sponsoring Entity
> -------------------------
> We are asking the Incubator PMC to sponsor this proposal.
>
> ---------------------------------------------------------------------
> 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]
