RSS Feed
Download our iPhone app
Browse DevX
Sign up for e-mail newsletters from DevX


Enterprise Software Configuration Made Simple

Stop copying and editing configuration files, and find out how to build your own system to store and deliver configuration information from a central location.

n organized system for maintaining and delivering configuration information is an essential component of any enterprise software system. For small enterprises with only a few servers, registry entries and individual configuration files offer a very simple configuration management solution; however, as the size and complexity of an organization grows to include many computers running across several physical locations, keeping all the related software components configured correctly quickly becomes a serious challenge. This article describes the various storage strategies available for storing configuration information, and then proposes a configuration system that you can easily implement yourself.

First, consider the attributes required to provide a useful system for managing configuration properties for a large enterprise of servers and software components. The following list prioritizes some key characteristics of such a system.

  • Centralized Storage and Management. Whether the actual settings are stored in a central location or whether a tool provides the appearance of centralized storage, settings should be managed from a central location.
  • Localized Settings. The system should be able to assign property values to the module, server, or location where the software will operate—for example, to a specific piece of software (the module)—more generically to a hosting server, or even more generically to a location (a physical location such as a primary datacenter or a disaster recovery facility). This feature supports (for example) setting a log file directory at the server level (all software modules on the same server will log to the same directory) and assigning an error reporting web service at the location level (all software modules running on all servers at a location will share the same value).
  • Reliability. Even in the event of occasional network or database failures, the software components must be able to obtain the configuration information required to operate "properly." While it's likely that the software will not be able to perform fully during such failures, the available configuration should at least give it the capability to log errors, reroute messages to operational components, or queue work requests until the disturbance has passed.
  • Scalability. Even when high numbers of servers and software components are reading configuration information very rapidly, the configuration system should scale with increasing demand.
Storage and Distribution Strategies
Historically, there have been four main ways of storing software configuration information: the registry, .config and .ini files, centralized databases, and custom text or XML files. These strategies all have their strengths (measured in terms of ease of modification, tools availability, retrieval speed, etc.) but they all become problematic as the size and complexity of the enterprise software environment grows (see Table 1).

Table 1. A comparison of the most popular storage strategies for configuration information shows their relative strengths and weaknesses.
RegistryLocal storage, fast reads, and immune to network and database failuresLarge numbers of servers can be very burdensome to maintain
Config filesLocal storage, fast reads, and immune to network and database failuresVery difficult to maintain due to lack of tools
Centralized databaseCentralized managementSlow reads, difficult to scale to high numbers of servers
Custom filesLocal storage, fast reads, and immune to network and database failuresVery difficult to maintain due to lack of tools

Building a Configuration System
The configuration system described here has two main goals: central configuration storage, and enterprise-wide configuration property distribution.

Author's Note: This article uses the following terminology. A "module" is any logical piece of software that is operated—or more importantly—configured, as a single entity. A "location" is either a physical or logical group of servers that are configured similarly. A "property value" is a named piece of information affecting the operation of a software system.

Close Icon
Thanks for your registration, follow us on our social networks to keep up-to-date