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
Table 2. Sample escPropertyValues: Here's a sample set of property values that illustrate how a query can retrieve a specific or generic property.
| 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
