You are viewing a plain text version of this content. The canonical link for it is here.
Posted to general@incubator.apache.org by Phil Steitz <ph...@gmail.com> on 2007/06/24 20:24:39 UTC
[Proposal] Java Resource Simulator (JRS)
This is a proposal to develop a Java-based interface response
capture/playback tool. The full proposal is here:
http://wiki.apache.org/incubator/JrsProposal
Comments and questions are welcome. We are by no means wedded to the
name "JRS" and have not yet done name searches, etc. If there are
concerns with the name, we can come up with an alternative, but our
preference would be for a descriptive name.
Attached for convenience below is the text of the initial revision of
the proposal on the Wiki. When discussion has reached the point where
an acceptance VOTE is appropriate (assuming generally favorable
response), I will call for the vote on this list, attaching the final
proposal text to the post that kicks off the VOTE.
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
-----------------
Until the project has been accepted, code grant executed and ASL
applied, we do not want to make the sources publicly available. This
is in part because the sources currently include license headers
inconsistent with public distribution. Interested parties may
individually contact the proposal Champion below to work out the
logistics of access to the source code during proposal review.
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: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [Proposal] Java Resource Simulator (JRS)
Posted by Phil Steitz <ph...@gmail.com>.
On 6/24/07, Henning Schmiedehausen <he...@apache.org> wrote:
> Is this a legal issue (you need clearance) or just a matter of "well,
> there are a bazillion of wrong/strange/bad license headers with (C)'s
> inside that we want to clean up first and need time"?
>
We have clearance to execute a code grant and CCLA. That is not a
problem. It is more the latter, making sure what we make publicly
available is appropriately licensed.
Phil
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [Proposal] Java Resource Simulator (JRS)
Posted by Henning Schmiedehausen <he...@apache.org>.
Is this a legal issue (you need clearance) or just a matter of "well,
there are a bazillion of wrong/strange/bad license headers with (C)'s
inside that we want to clean up first and need time"?
Best regards
Henning
On Sun, 2007-06-24 at 14:28 -0700, Phil Steitz wrote:
> On 6/24/07, Leo Simons <ma...@leosimons.com> wrote:
> > On Jun 24, 2007, at 8:24 PM, Phil Steitz wrote:
> > > This is a proposal to develop a Java-based interface response
> > > capture/playback tool.
> >
> > Interesting proposal. Seems useful.
> >
> > > Documentation
> > > ---------------------
> > > Documentation is available on request. See below.
> > >
>
> > > Initial source
> > > -----------------
> > > Until the project has been accepted, code grant executed and ASL
> > > applied, we do not want to make the sources publicly available. This
> > > is in part because the sources currently include license headers
> > > inconsistent with public distribution. Interested parties may
> > > individually contact the proposal Champion below to work out the
> > > logistics of access to the source code during proposal review.
> >
> > I don't think we've done it this way before. I can understand not
> > wanting to make source openly available, but I don't like that "to
> > work out logistics of access" happens individually, and the "on
> > request" makes me a bit itchy, too.
> >
>
> Its not really a matter of not wanting to, just the current license
> headers make posting it publicly dicey and there is also the issue of
> where to put it. I am assuming that until the grant is executed
> ~psteitz is not OK.
>
> > I think if you do things this way you should at least implement a
> > clear, open, privacy-respecting, documented and non-discriminating
> > logistics thingie (along the lines of "tarball is at https://<foo>/,
> > contact me for username/password. We won't use your contact details
> > in any way except to provide you the username/password.").
>
> Agreed. There is no intention to discriminate or limit in any way.
>
> What have others done to workaround the bootstrapping problem for code
> that is currently internally licensed / restricted distribution before
> the proposal is accepted and a grant can be executed?
>
> Phil
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [Proposal] Java Resource Simulator (JRS)
Posted by Phil Steitz <ph...@gmail.com>.
On 6/24/07, Eelco Hillenius <ee...@gmail.com> wrote:
> > What have others done to workaround the bootstrapping problem for code
> > that is currently internally licensed / restricted distribution before
> > the proposal is accepted and a grant can be executed?
>
> My understanding is that whether projects get accepted for incubation
> don't have to do much with the code you currently have, but rather
> about the motivations, community aspects etc. So why include this
> clause in the first place? Why not say you start with a clean slate
> and start adding source to the repository when they are deemed ready
> for that?
>
In retrospect, that may have been a better approach. The value of
making the code available is to clarify the technical ideas in the
proposal. Looking at the initial source code in an incubator proposal
can make it clearer where the project is starting from. In this case,
there is a working code base to start from and I thought it would be
good to make it available for people to look at. Unfortunately, I
can't just post the code on a public web site at this point, so I
probably should have just said it was not available. Unless anyone
has better suggestions than what I put in the proposal, I will modify
the proposal to just state that there is a working initial codebase
that will be granted, relicensed and reviewed for acceptance by the
ppmc assuming the project is accepted, but the initial source is not
available for review at this time.
Phil
> Eelco
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [Proposal] Java Resource Simulator (JRS)
Posted by Eelco Hillenius <ee...@gmail.com>.
> What have others done to workaround the bootstrapping problem for code
> that is currently internally licensed / restricted distribution before
> the proposal is accepted and a grant can be executed?
My understanding is that whether projects get accepted for incubation
don't have to do much with the code you currently have, but rather
about the motivations, community aspects etc. So why include this
clause in the first place? Why not say you start with a clean slate
and start adding source to the repository when they are deemed ready
for that?
Eelco
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [Proposal] Java Resource Simulator (JRS)
Posted by Phil Steitz <ph...@gmail.com>.
On 6/24/07, Leo Simons <ma...@leosimons.com> wrote:
> On Jun 24, 2007, at 8:24 PM, Phil Steitz wrote:
> > This is a proposal to develop a Java-based interface response
> > capture/playback tool.
>
> Interesting proposal. Seems useful.
>
> > Documentation
> > ---------------------
> > Documentation is available on request. See below.
> >
> > Initial source
> > -----------------
> > Until the project has been accepted, code grant executed and ASL
> > applied, we do not want to make the sources publicly available. This
> > is in part because the sources currently include license headers
> > inconsistent with public distribution. Interested parties may
> > individually contact the proposal Champion below to work out the
> > logistics of access to the source code during proposal review.
>
> I don't think we've done it this way before. I can understand not
> wanting to make source openly available, but I don't like that "to
> work out logistics of access" happens individually, and the "on
> request" makes me a bit itchy, too.
>
Its not really a matter of not wanting to, just the current license
headers make posting it publicly dicey and there is also the issue of
where to put it. I am assuming that until the grant is executed
~psteitz is not OK.
> I think if you do things this way you should at least implement a
> clear, open, privacy-respecting, documented and non-discriminating
> logistics thingie (along the lines of "tarball is at https://<foo>/,
> contact me for username/password. We won't use your contact details
> in any way except to provide you the username/password.").
Agreed. There is no intention to discriminate or limit in any way.
What have others done to workaround the bootstrapping problem for code
that is currently internally licensed / restricted distribution before
the proposal is accepted and a grant can be executed?
Phil
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [Proposal] Java Resource Simulator (JRS)
Posted by Leo Simons <ma...@leosimons.com>.
On Jun 24, 2007, at 8:24 PM, Phil Steitz wrote:
> This is a proposal to develop a Java-based interface response
> capture/playback tool.
Interesting proposal. Seems useful.
> Documentation
> ---------------------
> Documentation is available on request. See below.
>
> Initial source
> -----------------
> Until the project has been accepted, code grant executed and ASL
> applied, we do not want to make the sources publicly available. This
> is in part because the sources currently include license headers
> inconsistent with public distribution. Interested parties may
> individually contact the proposal Champion below to work out the
> logistics of access to the source code during proposal review.
I don't think we've done it this way before. I can understand not
wanting to make source openly available, but I don't like that "to
work out logistics of access" happens individually, and the "on
request" makes me a bit itchy, too.
I think if you do things this way you should at least implement a
clear, open, privacy-respecting, documented and non-discriminating
logistics thingie (along the lines of "tarball is at https://<foo>/,
contact me for username/password. We won't use your contact details
in any way except to provide you the username/password.").
- Leo
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [Proposal] Java Resource Simulator (JRS)
Posted by Paul Fremantle <pz...@gmail.com>.
Sounds like a good proposal. I'm +1 on this. I'd also be happy to help
out. It could certainly be useful addition to Synapse as well. Looks
like you have enough mentors, but if at any time you need mentoring
help I'll also be willing to do that.
Paul
On 6/24/07, Phil Steitz <ph...@gmail.com> wrote:
> This is a proposal to develop a Java-based interface response
> capture/playback tool. The full proposal is here:
>
> http://wiki.apache.org/incubator/JrsProposal
>
> Comments and questions are welcome. We are by no means wedded to the
> name "JRS" and have not yet done name searches, etc. If there are
> concerns with the name, we can come up with an alternative, but our
> preference would be for a descriptive name.
> Attached for convenience below is the text of the initial revision of
> the proposal on the Wiki. When discussion has reached the point where
> an acceptance VOTE is appropriate (assuming generally favorable
> response), I will call for the vote on this list, attaching the final
> proposal text to the post that kicks off the VOTE.
>
> 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
> -----------------
> Until the project has been accepted, code grant executed and ASL
> applied, we do not want to make the sources publicly available. This
> is in part because the sources currently include license headers
> inconsistent with public distribution. Interested parties may
> individually contact the proposal Champion below to work out the
> logistics of access to the source code during proposal review.
>
> 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: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
--
Paul Fremantle
Co-Founder and VP of Technical Sales, WSO2
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
Re: [Proposal] Java Resource Simulator (JRS)
Posted by Gilles Scokart <gs...@gmail.com>.
2007/6/24, Phil Steitz <ph...@gmail.com>:
> -------------------------------------------------------------------------------------------
>
> 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.
>
You should say more clearly what kind of interactions you want to
simulate. I first taught it was an AWT, then I thought it was an
HTTP, then I thought to any kind of java API.
Giving in the abstract the list that you give later will make thing
more directly clear:
> The current (working) version
> supports JMS, Session EJBs, and web services. Support for JDBC is in
> early stages of development.
--
Gilles SCOKART
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [Proposal] Java Resource Simulator (JRS)
Posted by Craig L Russell <Cr...@Sun.COM>.
My only concern is with the name, which is surprisingly and
unfortunately similar to JSR. When I saw the acronym I immediately
thought you were proposing a new Java TM Specification Request.
Actually, if you google java jrs you find things like this: "This
project consists in a java JRS-168 portlet that acts as a generic
client for SOAP services". Sorta kidding...
Craig
On Jun 24, 2007, at 12:20 PM, Henning Schmiedehausen wrote:
> Big +1. That kind of tool I would have needed a few months ago... :-)
>
> Best regards
> Henning
>
>
>
> On Sun, 2007-06-24 at 11:24 -0700, Phil Steitz wrote:
>> Java Resource Simulator (JRS) Proposal
> [...]
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!
Re: [Proposal] Java Resource Simulator (JRS)
Posted by Henning Schmiedehausen <he...@apache.org>.
Big +1. That kind of tool I would have needed a few months ago... :-)
Best regards
Henning
On Sun, 2007-06-24 at 11:24 -0700, Phil Steitz wrote:
> Java Resource Simulator (JRS) Proposal
[...]
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [Proposal] Java Resource Simulator (JRS)
Posted by "Frank W. Zammetti" <fz...@omnytex.com>.
This is definitely interesting... one of the components in Java Web
Parts[1] is a filter[2] that records incoming requests. Along with that
is an application[3] that can take the output file from this filter and
"play it back", which can be used as a poor man's load testing tool.
I'm wondering, would something like that fit in with the JRS goals?
I also had plans for a much more robust version of what exists now that
records both requests *and* responses... the idea being that you could
run through an existing application, record all the interactions the
client had with the server, and then essentially "replace" the server
with a simple local mechanism (basically a simple class that acts as a
very simple web server) that took the place of the real server, sending
back the recorded response for a given recorded request... think of
having to demo a system where you don't want to risk the server not
being available, with this you could do so, albeit only with the
functions you had the forethought to record. No need for a database, or
Web Service endpoint, since it just serves recorded HTTP responses,
everything "behind" those responses is simulated too.
If that fits in with this proposal, I'd offer to donate the existing
code from JWP as a start, and develop the new version here in
conjunction with anyone else interested.
Frank
[1] Java Web Parts project: http://javawebparts.sourceforge.net
[2] RequestRecorderFilter:
http://javawebparts.sourceforge.net/javadocs/javawebparts/filter/RequestRecorderFilter.html
[3] RecordedRequestPlayer:
http://javawebparts.sourceforge.net/javadocs/javawebparts/misc/RecordedRequestPlayer.html
--
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com
AIM/Yahoo: fzammetti
MSN: fzammetti@hotmail.com
Author of "Practical Ajax Projects With Java Technology"
(2006, Apress, ISBN 1-59059-695-1)
and "JavaScript, DOM Scripting and Ajax Projects"
(2007, Apress, ISBN 1-59059-816-4)
Java Web Parts - http://javawebparts.sourceforge.net
Supplying the wheel, so you don't have to reinvent it!
Phil Steitz wrote:
> This is a proposal to develop a Java-based interface response
> capture/playback tool. The full proposal is here:
>
> http://wiki.apache.org/incubator/JrsProposal
>
> Comments and questions are welcome. We are by no means wedded to the
> name "JRS" and have not yet done name searches, etc. If there are
> concerns with the name, we can come up with an alternative, but our
> preference would be for a descriptive name.
> Attached for convenience below is the text of the initial revision of
> the proposal on the Wiki. When discussion has reached the point where
> an acceptance VOTE is appropriate (assuming generally favorable
> response), I will call for the vote on this list, attaching the final
> proposal text to the post that kicks off the VOTE.
>
> 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
> -----------------
> Until the project has been accepted, code grant executed and ASL
> applied, we do not want to make the sources publicly available. This
> is in part because the sources currently include license headers
> inconsistent with public distribution. Interested parties may
> individually contact the proposal Champion below to work out the
> logistics of access to the source code during proposal review.
>
> 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: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
>
>
>
--
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [Proposal] Java Resource Simulator (JRS)
Posted by Petar Tahchiev <pa...@gmail.com>.
On 6/25/07, robert burrell donkin <ro...@gmail.com> wrote:
>
> On 6/25/07, Martijn Dashorst <ma...@gmail.com> wrote:
> >
> > From an incubator point of view, I think having the sources available
> > is not yet necessary. Having a clear proposal what the project is
> > going to do, and who is going to do it is more important, especially
> > with a third party donation. I think we should focus more on diversity
> > of the community rather than the actual code.
>
>
> +1
>
> The code can be cleaned and cleared inside the incubator afiac.
>
>
> +1
>
> - robert
>
+1
Eventually we can think of some integration with the Cactus project.
--
Regards, Petar!
Karlovo, Bulgaria.
Bulgarian medics in Libya are innocent!
http://www.nestesami.bg/main/index.php
Public PGP Key at:
http://keyserver.linux.it/pks/lookup?op=get&search=0x1A15B53B761500F9
Key Fingerprint: AA16 8004 AADD 9C76 EF5B 4210 1A15 B53B 7615 00F9
Re: [Proposal] Java Resource Simulator (JRS)
Posted by Matt Benson <gu...@yahoo.com>.
--- robert burrell donkin
<ro...@gmail.com> wrote:
> On 6/25/07, Martijn Dashorst
> <ma...@gmail.com> wrote:
> >
> > From an incubator point of view, I think having
> the sources available
> > is not yet necessary. Having a clear proposal what
> the project is
> > going to do, and who is going to do it is more
> important, especially
> > with a third party donation. I think we should
> focus more on diversity
> > of the community rather than the actual code.
>
>
> +1
>
> The code can be cleaned and cleared inside the
> incubator afiac.
>
A little late into the conversation, but if the
original intent was to make it possible to see some of
the concrete ideas being promoted, would providing the
javadoc, perhaps even only of a few top-level packages
and/or interfaces, be a possible compromise involving
significantly less work than actually modifying all
the necessary code headers?
-Matt
>
> +1
>
> - robert
>
____________________________________________________________________________________
Choose the right car based on your needs. Check out Yahoo! Autos new Car Finder tool.
http://autos.yahoo.com/carfinder/
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [Proposal] Java Resource Simulator (JRS)
Posted by robert burrell donkin <ro...@gmail.com>.
On 6/25/07, Martijn Dashorst <ma...@gmail.com> wrote:
>
> From an incubator point of view, I think having the sources available
> is not yet necessary. Having a clear proposal what the project is
> going to do, and who is going to do it is more important, especially
> with a third party donation. I think we should focus more on diversity
> of the community rather than the actual code.
+1
The code can be cleaned and cleared inside the incubator afiac.
+1
- robert
Re: [Proposal] Java Resource Simulator (JRS)
Posted by Martijn Dashorst <ma...@gmail.com>.
>From an incubator point of view, I think having the sources available
is not yet necessary. Having a clear proposal what the project is
going to do, and who is going to do it is more important, especially
with a third party donation. I think we should focus more on diversity
of the community rather than the actual code.
The code can be cleaned and cleared inside the incubator afiac.
Martijn
--
Wicket joins the Apache Software Foundation as Apache Wicket
Join the wicket community at irc.freenode.net: ##wicket
Wicket 1.2.6 contains a very important fix. Download Wicket now!
http://wicketframework.org
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [Proposal] Java Resource Simulator (JRS)
Posted by Martin van den Bemt <ml...@mvdb.net>.
+1.. If the source is a big problem for people, maybe putting it in your home (not on in
public_html) and set appropriate group rights so people can get to it by ssh.
I don't have a problem with not having access to the sources yet though..
Mvgr,
Martin
Phil Steitz wrote:
> This is a proposal to develop a Java-based interface response
> capture/playback tool. The full proposal is here:
>
> http://wiki.apache.org/incubator/JrsProposal
>
> Comments and questions are welcome. We are by no means wedded to the
> name "JRS" and have not yet done name searches, etc. If there are
> concerns with the name, we can come up with an alternative, but our
> preference would be for a descriptive name.
> Attached for convenience below is the text of the initial revision of
> the proposal on the Wiki. When discussion has reached the point where
> an acceptance VOTE is appropriate (assuming generally favorable
> response), I will call for the vote on this list, attaching the final
> proposal text to the post that kicks off the VOTE.
>
> 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
> -----------------
> Until the project has been accepted, code grant executed and ASL
> applied, we do not want to make the sources publicly available. This
> is in part because the sources currently include license headers
> inconsistent with public distribution. Interested parties may
> individually contact the proposal Champion below to work out the
> logistics of access to the source code during proposal review.
>
> 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: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org