Enterprise Software Configuration Made Simple : Page 2

Storing Configuration Data
Before investigating the process of making configuration data available to distributed software components, you need to understand how the data is stored centrally. The configuration system allows a property value to be assigned to any (or none) of the following elements: software module, server, and location.

Figure 1. Data Model: The data model for the proposed configuration system supports linking property values to modules, servers, and locations.

Figure 1 shows the data model for the proposed configuration system. The escProperties table gives each property a name (the PropertyLabel field) and defines how often to update the local "caches" of these property values (the ValidFor field). The escModules table defines the various software modules that comprise the enterprise system. The escServers and escLocations tables define the servers and locations that operate as part the of the enterprise software system. Note that the foreign key relationship between the locations and servers tables lets the configuration system automatically detect the location given a server name.

In the center of Figure 1, the escPropertyValues table provides a way to assign values to properties. The tables' construction allows a property value to vary depending on the associated module, server, and location. To support property value assignments made without associating them with a specific module, server, or location, you may supply a zero for those values; this gives the table a wildcard matching capability. As an example, inspect the set of escPropertyValues records shown in Table 2

PropertyID	ModuleID	ServerID	LocationID	PropertyValue
1017	1113	729	2239	\\SVRNAME\logfiles\abc
1017	0	0	2239	\\SVRNAME\logfiles\
1017	0	729	2239	\\OTHERSVRNAME\logfiles\
1017	1113	0	2239	\\SVRNAME\logfiles\123
1017	0	0	0	\\SVRNAME\logfiles\app01

The first record in Table 2 holds a property value of \\SVRNAME\logfiles\abc for a property with the ID 1017 belonging to module 1113 running on server 729 at location 2239. Similarly, the second row provides the property value \\SVRNAME\logfiles\ for a property with an ID of 1017, for any module (0) or server (0) at location 2239. Row 3 returns \\OTHERSVRNAME\logfiles\ when any module running on server 729 at location 2239 requests the value of property ID 1017. Likewise, when module ID 1113 requests the value for property 1017 running on any server at location 2239, the return value will be \\SVRNAME\logfiles\123. Finally, the last row demonstrates a full wildcard record—the value \\SVRNAME\logfiles\app01 will be returned to any module requesting the value of property 1017 anywhere in the enterprise.

When querying for a property value record, client software must provide the module ID, the server name, and the name for the value it's attempting to retrieve. The escServers table's relationship with the escLocations table provides the location of the calling server. Using these values, the SQL query shown below will retrieve the most specific property value based on the input data:

   SELECT 
      TOP 1 PropertyLabel, PropertyValue, ValidFor
   FROM 
      eacPropertyValues pv 
      JOIN eacProperties p ON pv.PropertyID = p.PropertyID 
      LEFT JOIN eacServers s ON pv.ServerID = s.ServerID 
      LEFT JOIN eacLocations l ON s.LocationID = l.LocationID 
   WHERE 
      p.PropertyLabel like 'Log File Location'
      AND (pv.ModuleID = 1017 OR pv.ModuleID = 0) 
      AND (s.ServerName like 'CORP_SVR' OR pv.ServerID = 0) 
      AND (pv.LocationID = s.LocationID OR pv.LocationID = 0) 
   ORDER BY 
      pv.ModuleID DESC, 
      pv.ServerID DESC, 
      pv.LocationID DESC

To select only the records that are relevant to the client's request, the query filters only records that either match the specified search criteria exactly, or whose field value is 0 (the wildcard setting). In the preceding query, the three filter expressions in the WHERE clause that reference the module, server, or location provide this functionality. Notice that each clause matches either the specific value provided by the client or a wildcard value.

To select the record that is most specific to the search criteria specified by the client, the query gives precedence to criteria matches in the following prioritized order: module, server, location—by ordering the result set by ModuleID, ServerID, and LocationID in descending order. Non-zero settings values sort higher in the results, which means that by selecting only the TOP 1 record, the query result is the single property value result that applies most specifically to the software retrieving the property value.

Together, the tables illustrated in Figure 1 and queries formulated like the one shown above provide a basic system for retrieving the most appropriate configuration data from a central location, and fulfill the primary goal of providing a flexible configuration system. This method allows users to assign a property value either specifically or non-specifically as appropriate. Obviously, it wouldn't be difficult to write a simple configuration tool that would help users make such property assignments.

Remember, one primary goal of a configuration system is to provide centralized management. The proposed configuration system is based on a centralized SQL Server database. As discussed in the previous section, though, this can lead to scalability problems with large numbers of client systems. Even more troubling, when database or network connectivity fails, client software will be unable to retrieve any configuration information, leading to software failures throughout the enterprise.

To solve that problem, the next phase of this article discusses a strategy for taking the configuration values from the centralized database and distributing the values to all the client servers.

Previous Page

Next Page