Application properties and storage strategies

It baffles and disappoints

I've been in this industry for a long time. I've seen the good and bad and take away from each experience lessons for the next project. It's not uncommon to look back on the way an application came together and think about how it could have been done differently to improve maintainability, robustness, etc.

Now in the Java world and enjoying it thoroughly, I'm continuously exposed to an aspect of Java development that both baffles and disappoints; property files.

What in the hell were “they” thinking?

The idea being employed by property files is to have a place to store application related information such as database connection criteria, behavioral specifications, etc. The property file is nothing but a common text file. I know of an inter-net application that relies upon a property file named “system.properties” which contains names of other property files to be processed during the startup phase!

#
# Property File name : dbConnection.properties
#
# DBTYPE.URL.NAME=VALUE
#  DBTYPE    : [mySQL, DB400]
#  URL       : Example  localhost, 10.240.19.84, as240d
#  Parm NAME : dbPooling     [on, off]
#  Parm NAME : dbPoolsize    [1,2,3...]   0=off
#  Parm NAME : dbName        For mySQL, the DB Name. For iSeries, the library
#  Parm NAME : dbUserID      User ID having authorized access
#  Parm NAME : dbPassword    Password for the user having authorized access 
#
# Syntax Examples:  
# DB400.as240d.poolsize=5 defines a connection pool size of 5 for an AS400
#    database located on the machine identified as as240d (IP add resolved via DNS).
#
#   mySQL.as240d.dbPooling=off specifies that pooling of db connections is off. The 
#       application software is required to create a connection either by prompting or
#  using the values specified here.  Prompted values are treated as overrides.
#

mySQL.localhost.dbPooling=off
mySQL.localhost.dbPoolsize=0
mySQL.localhost.dbName=resources
mySQL.localhost.dbUserID=prbxf000
mySQL.localhost.dbPassword=prbxf000

DB400.as240d.dbPooling=on
DB400.as240d.dbPoolsize=3
DB400.as240d.dbName=scdbfp10
DB400.as240d.dbUserID=2br02b
DB400.as240d.dbPassword=07734

# end of property file

Although this approach to storing properties for use by applications is common to see, it is problematic. As stated, these files are nothing more than text files. To change their contents, various text editors or even word processors are used. By its nature, information entered is prone to error and it is easy for anyone with access to the machine to change the contents of these files. In addition, there is no audit capability.

Usually, these property files are given names to reflect their role within the system. Sometimes, due to system changes giving rise for the need to create new property entries or remove old ones, the name no longer reflects those contents. Other times, the developer just finds it easier to add new property entries rather than create a new property file to contain those entries. If lucky, a suitable property file is found and the property values are added. If not so lucky, the developer sticks the properties into any file that exists.

It gets unwieldy quickly. Take for example a certain inter-net based order entry system used by a distribution company. Because of the user-volume, traffic is balanced across three application servers connected to a common database server. This approach calls for three separate sets of property files with each set residing in the three application servers. Most of the data within the property files is identical but some of the properties reflect the name of the application server itself while other properties relate to data queue names allocated for that server. Due to design requirements there are many property files containing over 2,300 entries. Together, that architecture calls for the existence of over 7,000 properties.

There are better ways to address this design requirement of providing static or server specific data to an application.

A properties file editor

This stand-alone editor provides the means to establish connection criteria to the database used by the client application. The data that can be maintained is listed in the table below.





The above is an example of an application designed to store values to be used by one or several other applications to govern database connection criteria. In addition it provides the means to establish other values. Such data could be the name or address and the contact information of the company that might be accessed by a billing application. You get the idea; static data.

The application stores the data entered into a Java serialized object. This provides a level of security in that the data within cannot be easily edited; you have to use the application to do that.

Below is a diagram that illustrates how the application stores the information entered.





Even though the above is by far a better approach compared to using a text file to store application property data, there is even a better method to storing static data such as state abbreviations, company addresses, application security contexts, etc., etc. ....


USE A DATABASE !!!