SpiderLogic has been involved with developing a large application for the past two years for an insurance company. During the course of this project a number of tools open source and otherwise have been used. The change in Java technology over the years allowed this project to adapt many of these toolsets. At times many things were thrown out and replaced with something else without affecting other parts of the application.
This article is an attempt to share those experiences about development process and the toolsets being used
This is an insurance application used by agents of the company who are in the field selling insurance policies. Primarily this allows agents to get instant quotes to give to clients when selling insurance policies. Apart from this the system allows stores customer and account information.
The UI is extremely reactive to rules. The screen functionality changes quite a bit depending on what rules are being executed. Most agents work on a disconnected laptop and dial in to get quotes.
Agents run a swing based client to work on the quotes. They have a local database which is DB2. Once quotes are created they are stored to the local file system and once the user connects these quote requests are posted to a JMS queue.
On the server side a Websphere server, message driven beans running on AS400, process these messages and stores them to a centralized repository. Another java process kicks off a rating engine (mainframe) and gets the price for that quote request. This price is stored locally in the quote repository and another message is posted to the client. Whenever the clients connect they get the rate for this quote.
Client applications launched on the laptops from within Lotus Notes client. Customer data is retrieved from a notes database.
With no further delay let’s look into the development process, open source tools used and lessons learnt in general with a promise not to talk again about the project specific details.
The development team consists of 10 - 15 developers in three different geographic locations including one that is on the other side of the world. A part of this developer profile consists of mainframe developers doing their first java project.
A conscious decision was made early on that all three teams will work together as one. The same code repository is shared between the three locations. In order to control the quality of code, Continuous integration is done. Check in tested code nothing happens. Check in something that breaks some unit tests, the entire group and the managers get an email.
A blend of XP / Scrum is what is used as development process. There is lots of white board usage for design. There is an emphasis on unit testing using JUnit. Every week there is a stand up meeting (literally) where developers in all three centers stand up and go through what they do in a few minutes.
The testing team is led by business users who are constantly testing the product before each release.
No one owns the code in particular. However since the system is so large in scope, over a period of time some developers have become experts of certain components.
Websphere Studio and Eclipse are used as a development tool. Although XP gives levy to each user to use the editor of their choice, it is much more practical is all developers share the same toolset.
Ant scripts do the build process. There is an internal release at least once a month. The release goes through all phases of incremental development including a detail user testing
CVS is user as a common code repository. After every release the code gets labeled and branched, while development continues in the main branch.
What is not done very efficiently is code walkthroughs that enhance the quality of the code. There is a emphasis on using design patterns when there is a need.
There is a XML file that has the database schema. Developers don’t have to touch the database directly. XSL is used and an ant script kicks off populating the test / production database. This is discussed a bit more in one of the sections that follow.
Webstart is used to deploy the code to clients. The section that follows looks at the many open source technologies that were used..
This project had nearly 40 different open source jar files in use at one point. While that made a deployment nightmare, a lot of open source tools have been used successfully.
Here is the list of few tools in use
MDateSelector - The MDateSelector is a Java Swing Popup Dialog that provides a Calendar to allow dates to be 'picked off' and returned to the date entry field on the Frame.
Piccolo -Piccolo is a non-validating high performance XML parser for Java. The benchmark shows that this is much faster than other common parsers like xerces.
Ant - Ant for build.
Arch4j-ui -An open source swing based framework from SpiderLogic.
Arch4j -An open source java toolkit from SpiderLogic.
Beanshell - Beanshell is a light weight scripting framework for Java.
Castor -Castor is an open
source data binding framework for Java[tm]. It is an OR mapping
tool like hibernate
Note: See
O/R Mapping with Castor JDO in the Real World for more
details.
Checkstyle - Checkstyle is a development tool to help programmers write Java code that adheres to a coding standard.
Drools -Drools is a rule engine written in the java language.
Kunststoff Look and Feel A look and feel plugin for swing applications.
Log4j Logging in the project is done using this.
CruiseControl
Used for continuous integration.
Note: This article from SpiderLogic discusses
setting up Cruise Control and will get you going.
Like the DLL hell in windows systems, it is essential to manage the jar file versions and what is used in a large project to avoid a “jar file fiasco”
Castor OR Mapper, is being used mostly for XML to Object mapping and also to persist data in the server side of the application. Castor had many issues and failed in deep update scenario and had a number of issues that have been documented in this white paper O/R Mapping with Castor JDO in the Real World.