構成データを保管する
分散されたソフトウェアコンポーネントに構成データを配布するプロセスを考える前に、まずデータを中央にどう保管するかを理解することが必要です。構成システムを利用すれば、プロパティ値をソフトウェアモジュール、サーバー、およびロケーションのすべてに割り当てる（またはどれにも割り当てない）ことができます。
図1に、本稿で提案する構成システムのデータモデルを示します。escPropertiesテーブルは、各プロパティに名前（PropertyLabelフィールド）を付与し、これらのプロパティ値のローカルキャッシュを更新する頻度（ValidForフィールド）を定義します。escModulesテーブルは、エンタープライズシステムを構成する各種のソフトウェアモジュールを定義します。escServersテーブルとescLocationsテーブルは、エンタープライズソフトウェアシステムの一部として動作するサーバーとロケーションを定義します。locationsテーブルとserversテーブル間の外部キーリレーションシップにより、構成システムはサーバー名が付与されたロケーションを自動的に検出することに注意してください。
図1の中心にあるescPropertyValuesテーブルは、プロパティに値を割り当てる方法を提供します。このテーブルの指定により、関連するモジュール、サーバー、およびロケーションに応じてプロパティ値を変化させることができます。具体的なモジュール、サーバー、またはロケーションに関連付けないプロパティ値割り当てをサポートするには、値にゼロを指定します。ゼロを指定すると、テーブルにワイルドカードマッチング機能が提供されます。例として、表2に示すescPropertyValuesレコードセットを見てみましょう。
| 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 |
表2の1行目のレコードは、ロケーション2239にあるサーバー729上で実行されているモジュール1113のID 1017のプロパティに、値\\SVRNAME\logfiles\abcを提供します。
同様に、2行目は、ロケーション2239にある任意のモジュール（0）または任意のサーバー（0）のID 1017のプロパティに、値\\SVRNAME\logfiles\を提供します。
3行目は、ロケーション2239にあるサーバー729上で実行されている任意のモジュールのID 1017のプロパティに、値\\OTHERSVRNAME\logfiles\を返します。
4行目は、ロケーション2239にある任意のサーバー上で実行されているID 1113のモジュールのID 1017のプロパティに、値\\SVRNAME\logfiles\123を提供します。
最後の5行目は、完全なワイルドカードレコードです。これにより、社内の任意のモジュールがID 1017のプロパティの値を要求した場合は、値\\SVRNAME\logfiles\app01が返されます。
クライアントソフトウェアがプロパティ値レコードを照会するときには、モジュールID、サーバー名、および取得しようとする値の名前を指定しなければなりません。サーバーのロケーションは、escServersテーブルとescLocationsテーブルのリレーションシップにより導かれます。これらの値を使って、次に示すSQLクエリは入力データに基づき最も具体的なプロパティ値を取得します。
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
クライアントの要求に関係するレコードのみを選択するために、クエリでは、指定された検索条件に正確に一致するか、フィールド値が0（ワイルドカード設定値）のレコードだけを抽出します。前述のクエリでは、モジュール、サーバー、またはロケーションを参照するWHERE句内の3つのフィルタ式がこの機能を提供しています。それぞれの式が、クライアントが指定した具体的な値またはワイルドカード値のいずれかと一致することに注意してください。
クライアントが指定した条件に最も適合するレコードを選択するため、このクエリでは、条件との突き合わせの優先順位をモジュール、サーバー、ロケーションの順にしています。具体的には、ModuleID、ServerID、およびLocationIDによる結果セットを降順に並べることで、これを実現しています。結果の並べ替えでは、ゼロ以外の設定値が優先されます。つまり、最上位のレコードのみを選択することで、クエリの結果は、プロパティ値を取得しているソフトウェアに最も具体的に適合する単一のプロパティ値の結果になります。
図1に示した各テーブルと、このような形式のクエリを組み合わせることで、中央から最も適切な構成データを取得するための基本システムを構築できます。これは、柔軟性に優れた構成システムを実現するという目標を満たすことにもなります。この手法を利用すれば、必要に応じて具体的または汎用的にプロパティ値を割り当てることができます。このようなプロパティ割り当てを行うためのシンプルな構成ツールは簡単に作成できるでしょう。
構成システムのもう1つの目標は、中央での一括管理を実現することです。本稿で提案する構成システムは、中央のSQL Serverデータベースに基づいています。ただし、前節で説明したように、このような構成はクライアントシステム数が増加したときにスケーラビリティ問題を引き起こす可能性があります。もっと問題なのは、データベース接続やネットワーク接続に障害が生じると、クライアントソフトウェアは構成情報を取得できなくなり、その結果、全社的なソフトウェア障害が引き起こされることです。
この問題を解決するため、次の節では、中央集中データベースから構成値を取得して、その値をクライアントサーバー全体に配布するための戦略を説明します。
