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.|
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
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.
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:
TOP 1 PropertyLabel, PropertyValue, ValidFor
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
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)
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
—by ordering the result set by ModuleID
, and LocationID
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.