Configuration Management in Java EE Applications Using Subversion

The most critical asset of any enterprise application is the data that it stores. Today's enterprise applications are often required to not just store data, but also keep track of all the changes that are made. This expectation also permeates into an associated set of requirements, such as tracking the reason for each change, the time of the change etc. In many cases, the data tracking requirements apply to data that applications store in the form of documents. Using Subversion can help satisfy these complicated, albeit common, requirements.

The Data Challenge

Enterprise applications store critical pieces of data, and the requirements of such applications do not stop at just the create, read, update and delete (CRUD) operations on the data. Applications are expected to store the history of all the changes to such data. Furthermore, organizations have a variety of legal and regulatory compliance mandates that ultimately result in requirements to not just track every change to critical data assets, but also associated requirements such as who made the changes to the data, what time a change was made, what changes were made, why the change made, etc.

Application data also varies widely in form and size. Applications are required to store data varying from simple forms, such as strings and numbers, to complex types, such as documents that are stored as blobs and clobs. A certain class of applications deals very heavily with data in the form of documents uploaded into the application. Tracking data in complex forms such as documents can become a nightmare if traditional approaches, such as history tables, are chosen.

Tracking with History Tables

Relational databases are generally the preferred choice for storing application data. They help organize, store, and retrieve the data in a very efficient manner. Since application data is stored in these relational databases, applications try to use these databases for tracking historical data as well. The most pervasive approach to storing historical data is to have a time-stamped history table for every table that stores important application entities. Updates made to the main table result in actions that push out the previous values of data to the history tables. This is either done through triggers or by the applications themselves.

There are several issues with storing the historical information in history tables.

Relational databases and the relational data modeling concentrate on efficient data storage and retrieval. The history tables do not model naturally with relational databases.

There is no support for versioning from the database. The application has to carefully store the entries into the history tables either through triggers or some other custom techniques.

It's up to the application to determine what changed between versions. The retrieval of historical information from the history tables is also specific to the history table storing the data.

The relational databases should still be the repository for storing and retrieving transactional data. They excel in managing these critical data assets. The shortcomings listed above are confined to storing multiple versions of data entities within the relational data store and tracking such entities over time.

Subversion and JavaSVN

Subversion is a version control system that's a replacement for CVS, an older version control system. Subversion organizes data as files and directories in the form of a tree called a repository. Subversion tracks all the changes that are made to any asset stored in this repository. Subversion can have a centrally located repository and allows multiple concurrent updates to the repository. It can access its repository over HTTP and HTTPS using the WebDAV protocol, which helps avoid firewall issues that often crop up during deployment. Subversion works on the concept of copy-modify-merge, which effectively means that there is no requirement to lock an object before making changes to it.

JavaSVN is a pure-Java Subversion client library. It offers APIs for Java applications to interact with Subversion. JavaSVN offers low-level APIs that can directly interact with a repository or high-level APIs to manage working copies checked out from a repository.

Applications can use a combination of relational databases and Subversion to satisfy data management and data tracking requirements. Any updates that are made to the critical data assets present in the relational database would be accompanied with a commit into Subversion. Subversion would be the primary data source for use-cases for tracking, while the relational database would be used for all other purposes. An additional advantage is that due to Subversion's copy-modify-merge concept, there is no requirement to lock an object every time its retrieved from the relational database.

Learning by Example

Now that we've stated the problem and proposed a potential solution, let's use an example to illustrate the usage of Subversion and JavaSVN to solve the problem. We will store a sample domain object into Subversion using the JavaSVN API. We will also retrieve previous versions and display differences between two versions. Our sample domain object is the LoanData object as shown below. The complete code used in this article can be found in the Resources section at the end of this article.

An abstract BaseTrackingObject class defines the commonly required tracking information, such as modifiedUser, modificationDate, and modificationReason. It defines the abstract methods to set and retrieve the objectId that can acts as the primary key for the domain object. It also defines a utility method called getXmlRepresentation that we will use to convert the object representation to an XML format. This format will be used to store and retrieve data from Subversion.