NetarchiveSuiteResponsible: MSS
Estimated time to do POC: 15 M (confidence A). Note this is the estimate for the Proof-Of-Concept, where the high confidence on the estimate comes from the task being time boxed.
Background
Spring is a platform for building and running enterprise Java applications. Led and sustained by SpringSource, Spring delivers significant benefits for many projects, increasing development productivity and runtime performance while improving test coverage and application quality. Among other this Spring provides adaption of the following areas relevant to the NetarchiveSuite project: * Message-Driven Architecture including JMS * Task Execution and Scheduling * Hibernate * Enterprise composition patterns * Settings, see Follow-up on settings design discussions
See the Spring documentation for further details on Spring.
Problems with the Current Setup
Many of the challenges encountered in Java Enterprise application has not been addressed in a adequate manor, because the solutions to the challenges had to be identified, analyzed and developed from scratch. This has f.ex. cause the following issues: * No framework behind the GUI code * GUI, business and database logic mixed together (see Enforcing a nice 3-tier architecture and Keeping the classes clean) * Inconsistent and error prone scheduling implementations * Manual JMS integration * Manual database integration * Problematic attempt to construct the application components (see CleanupIF vs. Singleton)
Advantages of a Shift to Spring
A lot of other Enterprise related problems are also addressed by by Spring, which could improve the quality of the NAS software, Spring attempts to address all the short-comes listed with best-practice solutions. In addition to these already obvious problems Spring properly also identified and address a number of other relevant challenges, which aren't clear to us at present.
Spring can be introduced gradually, so more and more of the NAS system will be build on Spring. This means we are able to avoid a big bang refactoring.
Risks Associated with a Shift to Spring
Breaking functionality
The main problem we are attempting to address with Spring is the complex application design, no new functionality will come directly from a switch to Spring. This properly means we initial are going to introduce a number of functional bugs into the system, which will degrade the system stability while the refactoring is under way.
=== Time consuming == Refactoring can be a very time consuming process, certainly for at system as old and extensive as NAS. If we chose to reimplement part of NAS based on the Spring platform, we are going to spend a lot of time working on issues, which wouldn't contribute with any new functionality.
Understanding Spring
Spring introduces a number of tools to improve the quality of applications. If the challenges being addressed by Spring and the corresponding solutions are poorly understood, the price of using Spring can quickly outweigh the benefits. This means that if no initial experience with Spring exists in the development team, it may be difficult to take advantage of the potential benefits in using Spring.
Conclusions
The benefits of introducing Spring depends very much on how efficient we can take advantage of the integrations and design improvement possible with Spring, and this again depends on how well we understand Spring. The effort needed to introduce Spring scales with the level we wish to utilize the possibilities in Spring, so we can introduce Spring in small steps without having to waste a lot of resources initially. We should start out with a Proof-Of-Concept investigation into the possibilities and problems with Spring. Prior to this, a minimum understanding of the ideas behind Spring should have been acquired.