(57)【要約】  ネットワーク要素の構成管理方法及び装置を開示する。この方法では、装置が、ネットワーク要素の構成データを保持する。構成データ内に構成オブジェクトのセットが生成され、所定の条件が満たされた場合、構成データ内にさらに別の構成オブジェクトが生成される。前記さらに別の構成オブジェクトが前記所定の条件又は別の所定の条件を満たす場合、構成データ内に１又はそれ以上のさらなる構成オブジェクトが生成される。前記所定の条件又は前記別の所定の条件を満たす構成オブジェクトの依存情報、及び前記所定の条件又は前記別の所定の条件に基づいて生成された構成オブジェクトの依存情報が構成データに記憶される。【選択図】図３
2014504469.tif 000002
【特許請求の範囲】
【請求項１】
ネットワーク要素の構成管理方法であって、ネットワーク装置において、
前記ネットワーク要素の構成データを維持するステップと、
前記構成データ内に構成オブジェクトのセットを生成し、所定の条件が満たされた場合、前記構成データ内にさらに別の構成オブジェクトを生成するステップと、
前記さらに別の構成オブジェクトが前記所定の条件又は別の所定の条件を満たす場合、前記構成データ内に１又はそれ以上のさらなる構成オブジェクトを生成するステップと、
前記所定の条件又は前記別の所定の条件を満たす前記構成オブジェクトの依存情報、及び前記所定の条件又は前記別の所定の条件に基づいて生成された前記構成オブジェクトの依存情報を前記構成データに記憶するステップと、
を実行することを特徴とする方法。
【請求項２】
前記所定の条件が、前記オブジェクト構成のために設定された、１又はそれ以上の構成オブジェクトと１又はそれ以上のさらなる構成オブジェクトの間の依存を定義するルールを含み、
前記所定の条件が満たされたことに応答して前記ルールを処理し、該処理に応答して前記１又はそれ以上の構成オブジェクトが変更された場合、前記ルール内に定義された前記依存に従って、前記１又はそれ以上のさらなる構成オブジェクトが変更される、
ことを特徴とする請求項１に記載の方法。
【請求項３】
前記所定の条件を、構成オブジェクトプロトタイプ定義内に特殊目的の宣言として表し、
参照整合性チェック、ガーベージコレクション、及び一連の手続き動作への低減のうちの１又はそれ以上を自動的に行うために、依存追跡システムを採用する、
ことを特徴とする請求項１又は請求項２に記載の方法。
【請求項４】
ネットワーク要素の構成データをオブジェクトセットとして定義し、
前記オブジェクトセットを、オブジェクトの位置を特定する一意のパス名を有する前記オブジェクト間の所有関係の表示が示されるように配置し、
前記オブジェクトが、指定されたオブジェクトクラスのインスタンスであり、それぞれのパス名によって参照オブジェクトが指定される、
ことを特徴とする請求項１から請求項３のいずれかに記載の方法。
【請求項５】
属性、参照及びこれらの割り当て値が、前記構成データ内の、前記他のオブジェクトと同等のパス名を有するオブジェクトとして表され、前記属性及び参照の前記割り当て値が、値オブジェクトの名目で符号化され、
前記方法が、前記オブジェクトクラスを一意に識別する名称と、下位オブジェクトの宣言と、追加の構成オブジェクトの自動生成による構成拡大を可能にする暗黙的オブジェクト宣言の順序付きリストと、継承されるオブジェクトクラス定義への参照と、前記オブジェクトクラスが抽象的であるかどうかを示すフラグとを含む構成オブジェクトクラスを定義するステップを含む、
ことを特徴とする請求項１から請求項４のいずれかに記載の方法。
【請求項６】
下位構成オブジェクト宣言が、前記構成オブジェクトの名称及び前記構成オブジェクトのタイプを含み、該構成オブジェクトのタイプが、
−  属性、
−  指定されたオブジェクトクラスのインスタンス、
−  前記構成データ内の特定の位置に存在する指定されたオブジェクトクラスの１又は複数のインスタンスへの参照、
−  前記指定されたオブジェクトクラスのインスタンスのセット、及び、
−  さらなる属性、インスタンス、参照、セット及びコンテナをグループ化するコンテナオブジェクト、
のうちの１又はそれ以上を含み、
前記インスタンスオブジェクトが生成されたことに応答して、前記属性、参照、セット及びコンテナの下位が自動的に生成され、必要に応じて、暗黙的構成オブジェクト宣言によって前記インスタンスの下位が生成される、
ことを特徴とする請求項１から請求項５に記載のいずれかに記載の方法。
【請求項７】
構成オブジェクト依存追跡を採用するステップを含み、これにより、
−  ＤＥＰＥＮＤＳ＿ＯＮ依存が、前記依存の前記オブジェクトが削除された場合に前記依存のサブジェクトが削除されることを意味し、
−  ＵＳＥＳ依存が、前記依存の前記オブジェクトの存在を正当化して、前記依存の前記サブジェクトが存在する限り、自動ガーベージコレクションによる前記オブジェクトの削除を防ぎ、
−  ＲＥＱＵＩＲＥＳ依存が、同じトランザクション内で前記依存の前記サブジェクトが削除されない限り、前記依存の前記オブジェクトの削除を防ぎ、
−  ＥＸＰＯＲＴＳ依存が、前記ネットワーク要素の高レベル構成の一部である前記依存の前記オブジェクトがネットワークオペレータによって明示的に生成されたことを示す、
ようになり、前記依存の前記サブジェクトがルートオブジェクトであり、
前記方法が、前記オブジェクト依存に基づいてガーベージコレクションを実施するステップを含み、前記ルートオブジェクトから前記ＵＳＥＳ依存をたどることによって前記構成オブジェクトに到達できない場合、前記構成オブジェクトが自動的に削除され、及び／又は前記構成オブジェクトの前記ＤＥＰＥＮＤＳ＿ＯＮ依存の前記オブジェクトが削除され、
前記方法が、対象オブジェクトの、前記ＥＸＰＯＲＴ依存のオブジェクトである下位オブジェクトを単一のトランザクションにおいて削除するステップを含むフラッシュ動作を実行するステップを含み、
前記方法が、前記ＥＸＰＯＲＴＳ依存に基づいて構成縮小を実施するステップを含む、
ことを特徴とする請求項１から請求項６に記載のいずれかに記載の方法。
【請求項８】
名前付きオブジェクトであるルールを定義し、前記名前付きオブジェクトが、
−  オブジェクトパスを照合する対象であるとともに、数式、条件式及びアサーション式、及び任意に名称によりアクセス可能な１又はそれ以上の変数を任意にもたらすパターンを含むオブジェクトセレクタのセット、
−  条件式及びアサーション式により、及びオブジェクトルールによりアクセス可能な文字列型変数をもたらす名称及び式を含む数式のセット、
−  選択したオブジェクトのセットに対して前記ルールが有効であるかどうかを指定するブール演算式である条件、
−  ブール演算式であるアサーション、
−  オブジェクトセレクタ及び数式変数への参照を含む暗黙的オブジェクト宣言のセット、
の下位を含む、
ことを特徴とする請求項１から請求項７のいずれかに記載の方法。
【請求項９】
セレクタの下にマッチオブジェクトを生成し、前記ルールの他のセレクタのマッチオブジェクトセットからデカルト積が計算され、該積集合の各要素が、前記マッチオブジェクトのベクトルであるとともに、
−  前記ベクトルの前記マッチオブジェクトの前記変数割り当てを互いに、及び新たに生成されたマッチオブジェクトの割り当てと組み合わせること、
−  前記割り当て値をセレクタ変数の参照に代入して前記数式表現を評価し、追加の変数割り当てを生成すること、
−  前記割り当て値をセレクタ及び数式変数の参照に代入して前記条件式を評価すること、
−  前記ルールオブジェクトの下にグループマッチオブジェクトを生成すること、
−  前記割り当て値をセレクタ及び数式変数の参照に代入して前記アサーション式を評価すること、
−  前記割り当て値を変数の参照に代入して、前記ルールの前記暗黙的オブジェクト宣言を処理し、前記宣言オブジェクトの下に特別グループマッチ特定オブジェクトを生成すること、
によって処理され、
前記グループマッチオブジェクトが、組み合わせた変数割り当て及び前記数式により生成された変数割り当てを記憶し、前記ベクトルのマッチオブジェクト毎にＤＥＰＥＮＤＳ＿ＯＮ依存が生成され、前記グループマッチオブジェクトがサブジェクトであり、
前記特別グループマッチ特定オブジェクトが、前記グループマッチオブジェクトに対してＤＥＰＥＮＤＳ＿ＯＮ依存を保持し、前記暗黙的オブジェクトに対して、及び任意に前記関連する属性及び参照割り当てに対してＲＥＱＵＩＲＥＳ及びＵＳＥＳ依存を保持し、
前記アサーションが、前記条件を満たすマッチオブジェクトのセットに関して真の値をもたらし、失敗したトランザクションに関して偽の値をもたらす、
ことを特徴とする請求項１から請求項８のいずれかに記載の方法。
【請求項１０】
ネットワーク要素の構成データを維持し、
前記構成データ内に構成オブジェクトのセットを生成し、所定の条件が満たされた場合、前記構成データ内にさらに別の構成オブジェクトを生成し、
前記さらに別の構成オブジェクトが前記所定の条件又は別の所定の条件を満たす場合、前記構成データ内に１又はそれ以上のさらなる構成オブジェクトを生成し、
前記所定の条件又は前記別の所定の条件を満たす前記構成オブジェクトの依存情報、及び前記所定の条件又は前記別の所定の条件に基づいて生成された前記構成オブジェクトの依存情報を前記構成データに記憶する、
ように構成されることを特徴とする装置。
【請求項１１】
前記所定の条件が、前記オブジェクト構成のために設定された、１又はそれ以上の構成オブジェクトと１又はそれ以上のさらなる構成オブジェクトの間の依存を定義するルールを含み、
前記装置が、所定の条件が満たされたことに応答して前記ルールを処理するようにさらに構成され、前記処理に応答して前記１又はそれ以上の構成オブジェクトが変更された場合、前記ルール内に定義された前記依存に従って、前記１又はそれ以上のさらなる構成オブジェクトが変更される、
ことを特徴とする請求項１０に記載の装置。
【請求項１２】
前記所定の条件を、構成オブジェクトプロトタイプ定義内に特殊目的の宣言として表し、
参照整合性チェック、ガーベージコレクション、及び一連の手続き動作への低減のうちの１又はそれ以上を自動的に行うために、依存追跡システムを採用し、
オブジェクトモデルを使用することにより、構成管理システムを相対的に高いレベルで記述し、
高レベルの定義に基づいて詳細構成を生成することにより、構成拡大を行う、
ようにさらに構成されることを特徴とする請求項１０又は請求項１１に記載の装置。
【請求項１３】
ネットワーク要素の構成データをオブジェクトセットとして定義し、
前記オブジェクトセットを、前記構成データ内のオブジェクトの位置を特定する一意のパス名を有する前記オブジェクト間の所有関係が示されるように配置し、
前記オブジェクトを、指定されたオブジェクトクラスのインスタンスとして定義する、
ようにさらに構成され、前記構成データ内に、それぞれのパス名によって指定されたものとして参照オブジェクトが存在する、
ことを特徴とする請求項１０から請求項１２のいずれかに記載の装置。
【請求項１４】
フラグを使用することによって参照がバインディング参照であるかどうかを示し、従って同じトランザクション内で参照割り当て自体が削除されない限り、参照対象の削除を防ぎ、
前記対象オブジェクトが削除された場合、非バインディング参照を自動的に削除する、
ようにさらに構成されることを特徴とする請求項１０から請求項１３のいずれかに記載の装置。
【請求項１５】
インスタンスが生成された時に、該インスタンスをプライマリ構成オブジェクトクラスに割り当てるように構成され、前記オブジェクトは、前記クラスのインスタンスであるとともに、前記クラスの直接的及び間接的スーパークラスのインスタンスでもあり、
前記オブジェクトのクラスによって特定のオブジェクトとともに使用可能な属性のセットを決定する、
ようにさらに構成される、
ことを特徴とする請求項１０から請求項１４のいずれかに記載の装置。
【請求項１６】
前記構成オブジェクトが、ハードウェア構成要素、プロセス、サービス、インターフェイス、アドレス及びデータベースのうちの１又はそれ以上を含む、前記ネットワーク要素内の物理又は論理エンティティを表すことを定義する、
ようにさらに構成されることを特徴とする請求項１０から請求項１５のいずれかに記載の装置。
【請求項１７】
提案された構成を検証し、前記ネットワーク要素がサポートしていない方法及び／又意味的に正しくない方法で前記構成が変更されようとしている場合、前記変更動作を拒否する、
ようにさらに構成されることを特徴とする請求項１０から請求項１６のいずれかに記載の装置。
【請求項１８】
属性、参照及びこれらの割り当て値が、前記構成データ内の、前記他のオブジェクトと同等のパス名を有するオブジェクトとして表され、前記属性及び参照の前記割り当て値が、値オブジェクトの名目で符号化されるように定義し、
前記オブジェクトクラスを一意に識別する名称と、下位オブジェクトの宣言と、追加の構成オブジェクトの自動生成による構成拡大を可能にする暗黙的オブジェクト宣言の順序付きリストと、継承されるオブジェクトクラス定義への参照と、前記オブジェクトクラスが抽象的であるかどうかを示すフラグとを含む構成オブジェクトクラスを定義する、
ようにさらに構成されることを特徴とする請求項１０から請求項１７のいずれかに記載の装置。
【請求項１９】
前記構成オブジェクトの前記名称及び前記構成オブジェクトのタイプを含む下位構成オブジェクト宣言を定義するようにさらに構成され、前記構成オブジェクトのタイプが、
−  属性、
−  指定されたオブジェクトクラスのインスタンス、
−  前記構成データ内の特定の位置に存在する指定されたオブジェクトクラスの１又は複数のインスタンスへの参照、
−  前記指定されたオブジェクトクラスのインスタンスのセット、及び、
−  さらなる属性、インスタンス、参照、セット及びコンテナをグループ化するコンテナオブジェクト、
のうちの１又はそれ以上を含み、
前記装置が、前記インスタンスオブジェクトが生成されたことに応答して、前記属性、参照、セット及び前記コンテナの下位を自動的に生成し、必要に応じて、暗黙的構成オブジェクト宣言によって前記インスタンスの下位を生成するようにさらに構成され、
前記装置が、ルールの処理後に、必要な属性及び参照が割り当てられたかどうか、及び前記属性の割り当てが意味的に正しいかどうかについての妥当性チェックを実行して、トランザクションの一貫性を保証するようにさらに構成される、
ことを特徴とする請求項１０から請求項１８のいずれかに記載の装置。
【請求項２０】
前記所定の条件が暗黙的オブジェクトを含み、これにより該暗黙的オブジェクトが、前記構成データ内に存在する構成オブジェクトを含むとともに、前記構成データ内に存在するさらなる構成オブジェクトにより、又は前記構成データ内に存在するさらなる構成オブジェクトの組み合わせにより暗示されるようになる、
ことを特徴とする請求項１０から請求項１９のいずれかに記載の装置。
【請求項２１】
前記構成データ内の前記オブジェクトの前記位置を示す一連のオブジェクト名としてパス名を定義するようにさらに構成され、前記オブジェクトを一意に識別する絶対パス名が、前記ルートオブジェクトに対する前記オブジェクトの前記位置を示し、相対パス名が、別のオブジェクトに対する前記オブジェクトの前記位置を示し、前記パス名の意味が、前記構成データ内の前記参照割り当てに依存する、
ことを特徴とする請求項１０から請求項２０のいずれかに記載の装置。
【請求項２２】
構成オブジェクト依存追跡を採用するようにさらに構成され、これにより、
−  ＤＥＰＥＮＤＳ＿ＯＮ依存が、前記依存の前記オブジェクトが削除された場合に前記依存のサブジェクトが削除されることを意味し、
−  ＵＳＥＳ依存が、前記依存の前記オブジェクトの存在を正当化して、前記依存の前記サブジェクトが存在する限り、自動ガーベージコレクションによる前記オブジェクトの削除を防ぎ、
−  ＲＥＱＵＩＲＥＳ依存が、同じトランザクション内で前記依存の前記サブジェクトが削除されない限り、前記依存の前記オブジェクトの削除を防ぎ、
−  ＥＸＰＯＲＴＳ依存が、前記ネットワーク要素の高レベル構成の一部である前記依存の前記オブジェクトがネットワークオペレータによって明示的に生成されたことを示す、
ようになり、前記依存の前記サブジェクトがルートオブジェクトであり、
前記装置が、
前記オブジェクト依存に基づいてガーベージコレクションを実施し、前記ルートオブジェクトから前記ＵＳＥＳ依存をたどることによって前記構成オブジェクトに到達できない場合、前記構成オブジェクトが自動的に削除され、及び／又は前記構成オブジェクトの前記ＤＥＰＥＮＤＳ＿ＯＮ依存の前記オブジェクトが削除され、
対象オブジェクトの、前記ＥＸＰＯＲＴ依存のオブジェクトである下位オブジェクトを単一のトランザクションにおいて削除するステップを含むフラッシュ動作を実行し、
前記ＥＸＰＯＲＴＳ依存に基づいて構成縮小を実施する、
ようにさらに構成されることを特徴とする請求項１０から請求項２１のいずれかに記載の装置。
【請求項２３】
名前付きオブジェクトであるルールを定義するようにさらに構成され、前記名前付きオブジェクトが、
−  オブジェクトパスを照合する対象であるとともに、数式、条件式及びアサーション式、及び任意に名称によりアクセス可能な１又はそれ以上の変数を任意にもたらすパターンを含むオブジェクトセレクタのセット、
−  条件式及びアサーション式により、及びオブジェクトルールによりアクセス可能な文字列型変数をもたらす名称及び式を含む数式のセット、
−  選択したオブジェクトのセットに対して前記ルールが有効であるかどうかを指定するブール演算式である条件、
−  ブール演算式であるアサーション、
−  オブジェクトセレクタ及び数式変数への参照を含む暗黙的オブジェクト宣言のセット、
の下位を含む、
ことを特徴とする請求項１０から請求項２２のいずれかに記載の装置。
【請求項２４】
セレクタの下にマッチオブジェクトを生成するようにさらに構成され、前記ルールの他のセレクタのマッチオブジェクトセットからデカルト積が計算され、該積集合の各要素が、前記マッチオブジェクトのベクトルであるとともに、
−  前記ベクトルの前記マッチオブジェクトの前記変数割り当てを互いに、及び新たに生成されたマッチオブジェクトの割り当てと組み合わせること、
−  前記割り当て値をセレクタ変数の参照に代入して前記数式表現を評価し、追加の変数割り当てを生成すること、
−  前記割り当て値をセレクタ及び数式変数の参照に代入して前記条件式を評価すること、
−  前記ルールオブジェクトの下にグループマッチオブジェクトを生成すること、
−  前記割り当て値をセレクタ及び数式変数の参照に代入して前記アサーション式を評価すること、
−  前記割り当て値を変数の参照に代入して、前記ルールの前記暗黙的オブジェクト宣言を処理し、前記宣言オブジェクトの下に特別グループマッチ特定オブジェクトを生成すること、
によって処理され、
前記グループマッチオブジェクトが、組み合わせた変数割り当て及び前記数式により生成された変数割り当てを記憶し、前記ベクトルのマッチオブジェクト毎にＤＥＰＥＮＤＳ＿ＯＮ依存が生成され、前記グループマッチオブジェクトがサブジェクトであり、
前記特別グループマッチ特定オブジェクトが、前記グループマッチオブジェクトに対してＤＥＰＥＮＤＳ＿ＯＮ依存を保持し、前記暗黙的オブジェクトに対して、及び任意に前記関連する属性及び参照割り当てに対してＲＥＱＵＩＲＥＳ及びＵＳＥＳ依存を保持し、
前記アサーションが、前記条件を満たすマッチオブジェクトのセットに関して真の値をもたらし、失敗したトランザクションに関して偽の値をもたらす、
ことを特徴とする請求項１０から請求項２３のいずれかに記載の装置。
【請求項２５】
構成オブジェクトが生成された時に、該構成オブジェクトを、その直接的及び間接的な上位構成オブジェクトの既存のルールに対して照合するようにさらに構成され、必要であれば、前記装置が、新たな暗黙構成オブジェクトを生成するようにさらに構成される、
ことを特徴とする請求項１０から請求項２４のいずれかに記載の装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明の例示的かつ限定的な実施形態は、一般にネットワーク要素の構成管理に関する。
【背景技術】
【０００２】
以下の背景技術についての記述は、本発明に先行する関連技術には知られていない本発明により提供される開示とともに、見識、発見、理解又は開示、或いは関連性を含むことができる。以下、本発明のいくつかのこのような寄与を具体的に指摘することができるが、その文脈から本発明のその他のこのような寄与が明らかになるであろう。
【０００３】
ネットワーク要素（ＮＥ）の構成データは、ツリー状階層に配置されたオブジェクトのセットとしてモデル化することができる。オブジェクトは、ハードウェア構成要素、プロセス、サービス、インターフェイス、アドレス又はデータベースなどの、ＮＥ内の物理的又は論理的エンティティを表すことができる。表されるエンティティの性質は、オブジェクトの特性であるクラスにより決定される。各オブジェクトは、そのオブジェクトが表す特定のエンティティを特徴付ける属性定義を含む。属性定義は、オブジェクトに固有の属性名及び割り当て値から成る。特定のオブジェクトに関連して使用しなければならない、又は使用できる属性のセットは、そのオブジェクトのクラスにより決定される。ツリー状階層は、オブジェクト間の単純な所有関係を示す手段を提供する。より複雑な関係は、参照型属性を用いてモデル化することができる。オブジェクトクラス及び属性の特性及び相互関係は、ＮＥ固有のスキーマ定義によって表される。構成管理システム（ＣＭＳ）が、構成データが確実にこのスキーマに従うようにすることなどの様々な機能を実行して構成を記憶することができる。
【発明の概要】
【課題を解決するための手段】
【０００４】
以下、本発明のいくつかの態様の基本的な理解をもたらすために、本発明の簡略化した要約を示す。この要約は、本発明の広範な概要ではない。本発明の重要な要素を特定すること、又は本発明の範囲を示すことを目的とするものでもない。後述する詳細な説明の前置きとして本発明のいくつかの概念を簡略化した形で示すことのみを目的とする。
【０００５】
本発明の態様によれば、ネットワーク要素の構成管理方法が提供される。この方法では、ネットワーク要素の構成データが保持される。この構成データ内に構成オブジェクトのセットが生成され、所定の条件が満たされた場合、この構成データ内にさらに別の構成オブジェクトが生成される。このさらに別の構成オブジェクトが所定の条件又は別の所定の条件を満たす場合、構成データ内に１又はそれ以上のさらなる構成オブジェクトが生成される。前記所定の条件又は前記別の所定の条件を満たす構成オブジェクト、及び前記所定の条件又は前記別の所定の条件に基づいて生成された構成オブジェクトの構成データには、依存情報が記憶される。
【０００６】
本発明の別の態様によれば、ネットワーク要素の構成管理装置が提供される。この装置は、ネットワーク要素の構成データを維持し、この構成データ内に構成オブジェクトのセットを生成し、所定の条件が満たされた場合、構成データ内にさらに別の構成オブジェクトを生成するように構成される。このさらに別の構成オブジェクトが、前記所定の条件又は別の所定の条件を満たす場合、装置は、構成データ内に１又はそれ以上のさらなる構成オブジェクトを生成するように構成される。この装置は、前記所定の条件又は前記別の所定の条件を満たす構成オブジェクト、及び前記所定の条件又は前記別の所定の条件に基づいて生成された構成オブジェクトの構成データに依存情報を記憶するように構成される。
【０００７】
以下、添付図面を参照しながら、例示的な実施形態を用いて本発明をより詳細に説明する。
【図面の簡単な説明】
【０００８】
【図１】例示的なシステムアーキテクチャを示す簡略ブロック図である。
【図２】本発明の実施形態による装置を示す図である。
【図３】本発明の実施形態を示すシグナリング図である。
【図４】本発明の実施形態を示すフロー図である。
【図５】本発明の実施形態を示すフロー図である。
【図６】構成管理動作に影響を与える依存を示す図である。
【図７】構成管理動作に影響を与える依存を示す図である。
【発明を実施するための形態】
【０００９】
構成管理システム（ＣＭＳ）が、実行時に構成データを読み出して変更するためのアプリケーションプログラミングインターフェイス（ＡＰＩ）を提供する。ＡＰＩは、ネットワーク要素（ＮＥ）のソフトウェアが構成変更に関する通知を受け取れるようにするコールバック機構を提供することもできる。さらに、アクセス制御リスト（ＡＣＬ）に従って構成データへのアクセス制御を行うために、ＡＰＩのユーザを認証する。ネットワーク要素は、コマンドラインインターフェイスを提供することができ、場合によっては人間のオペレータが構成データを見て変更できるようにするグラフィックユーザインターフェイスを提供することができる。ＡＰＩに加えて、同様に他のインターフェイスを提供することもできる。
【００１０】
構成管理は、装置又はシステムの構成を制御するために使用する関数群を参照する。この構成管理は、装置又はシステムの拡張又は縮小、構成要素の状態、及びこれらの割り当て特性を制御することができる。システムは、構成マネージャ（ＣＭ）エンティティにより、ネットワーク要素パラメータ及び／又はネットワーク要素接続パラメータを含む動作パラメータを制御できるようになる。
【００１１】
ネットワーク要素の構成管理は、上述したようなデータモデル及び構造に依拠することができる。ＣＭＳは、例えばライトウェイト・ディレクトリ・アクセス・プロトコル（ＬＤＡＰ）に基づくことができ、従ってこのデータモデルは、上述した説明に従うＬＤＡＰのデータモデルから導出される。また、拡張可能マークアップ言語（ＸＭＬ）文書を、階層型データモデルのインスタンスと見なすことができ、この場合オブジェクトは要素と呼ばれる。ＮＥの構成システムへの標準インターフェイスを記述するＮＥＴＣＯＮＦプロトコルは、ＸＭＬベースのデータモデルを使用する。
【００１２】
ＮＥプラットフォームにより提供されるアプリケーションインターフェイスを規格化しようとする試みに、サービス・アベイラビリティ・フォーラム（ＳＡＦ）のアプリケーションインターフェイス仕様（ＡＩＳ）がある。このＡＩＳは、上記の説明に従う階層型構成オブジェクトモデルも使用する。
【００１３】
多くの場合、全ての目的にかなう単一のＮＥ構成表現は存在しない。ＮＥは、工場で又は試運転時にプリセットされるデフォルト構成を有することができる。その後、ＮＥのオペレータは、新たなオブジェクトを生成することにより、或いは既存のオブジェクトを修正又は削除することにより、この構成を変更することができる。オペレータの観点からユーザインターフェイスを簡素に保つために、このオブジェクトモデルを、比較的高レベルでシステムを記述するように適合させることができる。しかしながら、アプリケーションソフトウェアの観点から見れば、ＣＭＳがシステムの詳細なビューを表示すれば一層便利になる。そうでなければ、このアプリケーションのプログラムコードは、システムに関する仮定を行い、高レベルなビューから必要な詳細を導出するための追加機能を含む必要がある。特に複数のプログラムが同様のロジックを含む必要がある場合、これにより全体的な複雑性が増して柔軟性が低下する。また、複数のアプリケーションにより共有されているプラットフォームによってＣＭＳが提供される場合、このアプローチでは、プラットフォームプログラムコードに対するハードコーディングアプリケーション固有の仮定につながることもあり、これは非常に望ましくない。ＣＭＳは、高レベルなビューから詳細なビューを容易に生成できるようにする機能を提供すべきである。高レベルな定義に基づいて詳細な構成を生成する処理を、構成拡大と呼ぶことができる。
【００１４】
関連する課題は、構成拡大の逆算を実現することである。オペレータにより生成された元々の高レベル定義を交互配置し、構成ツリー全体にわたって分散させることができる。オペレータは、構成ツリーを十分に拡大する代わりに、現在の構成をもたらした一連の高レベルな手続き動作として構成を見たいと望むことがある。このビューの生成は、構成拡大の逆関数と見なすことができ、構成縮小と呼ぶことができる。オペレータは、この構成縮小により、工場のデフォルト状態で適用されたいずれの構成動作が現在の構成を生み出したかを確認できるようになる。 
【００１５】
第３の課題は、オペレータが提案する構成の検証である。オペレータが、ＮＥがサポートしていない方法、又は意味的に正しくない方法で構成を変更しようと試みる場合、その動作を拒否できるようにすべきである。
【００１６】
さらに、第４の課題は、スキーマのアップグレードに関する。このような場合、ＮＥは、デフォルト構成に後退するのではなく、むしろ新たなバージョンのスキーマに従うように既存の構成を変換すべきである。
【００１７】
ＮＥＴＣＯＮＦ仕様は、高レベルな記述から詳細な構成を生成できる技術として拡張可能スタイルシート言語変換（ＸＳＬＴ）を使用することを提案している。しかしながら、必要なスタイルシートを実際に生成することは面倒な作業である。さらに、ＸＳＬＴは、大きな構成の小さな部分をオペレータが変更するような場合には実用的でない。高レベルビューの変更は、構成ツリー全体にわたる様々な変化を意味することもあり、ＸＳＬＴは、この変更を必要な場所に伝達するための効率的な方法を提供しない。
【００１８】
実際のＣＭＳは、拡大に関与する機能を実際のアプリケーションプログラムコードから分離し、アプリケーション内の冗長コードの必要性をなくすことによってこの問題に対処することができる。これを行うことにより、ＣＭＳは、オペレータの行動に基づく変更トランザクション内にスキーマ固有のプラグインがさらなる動作をもたらすようにすることができる。この変形例として、構成データに対する直接的作用を許可せずに、オペレータの要求を詳細な構成データに展開する専用のスキーマ固有ツールを提供することが挙げられる。
【００１９】
構成拡大スキームの下で構成オブジェクトをインスタンス化する場合、このオブジェクトのプロトタイプに基づいてその属性の一部を設定することができる。場合によっては、メインオブジェクトのプロトタイプに基づいて下位オブジェクトも生成される。プロトタイプは、オブジェクトの高レベル特性であり、オブジェクトのクラスとは異なる。プロトタイプ定義は、この種のオブジェクトに関する詳細情報を含み、後でオブジェクトのインスタンスにコピーされる。
【００２０】
いくつかの構成ツールでは、プロトタイプベースのアプローチを使用することができる。場合によっては、プロトタイプ定義間で複数の継承を可能にすることにより、この概念を強化することができる。たとえ従来技術が、拡大機能を分離することによってアプリケーションプログラムコードから冗長性を除去するように管理を行ったとしても、スキーマ固有のプラグイン又はツール自体の間に多くの冗長性が存在するという事実は、依然として大部分が対処されないままである。ＣＭＳが、構成データのどの部分が元々のものであり、どれが拡大によって生成されたものかについての知識を失うこともある。このことは、ＣＭＳが汎用構成縮小機能を実装しておらず、従って以下の２つの選択肢が残ることを意味する。
−  ＣＭＳが、構成縮小を全く行わずに、詳細なビューのみをオペレータに提供すること。これは不便である。
−  ＣＭＳが、スキーマ固有の構成縮小機能の実行を許可すること。この場合、スキーマとともに機能を更新する必要があるので、十分なスケーリングが行われない。
【００２１】
ＣＭＳによっては、試運転後にオペレータが実行した構成コマンドを全て記録したログを保持することによってこの問題に取り組もうと試みるものもある。これにより、現在の構成を再構築するために使用できる一連のコマンドが実際に生成されたとしても、これは構成縮小に等しいものではない。この方式では、ログの長さが、現在の構成の実際の複雑性に比例すると言うよりも、むしろＮＥの寿命の増加関数である。構成が頻繁に修正される場合、人はこのようなログを判読できなくなることがある。ＣＭＳは、スキーマ定義に基づいて、構成属性に対する単純な検証動作を自動的に実行することができる。ＸＭＬスキーマの単純型概念は、このような単純な制約を表現するための考えられる１つの方法である。
【００２２】
意味的検証及び整合性チェックに関しては、解決策が、構成拡大に使用されるもの、すなわちスキーマ固有のプラグイン又は構成ツールの使用と類似し得る。この場合も、この解決策は、このようなプラグインとツールの間の冗長性につながる。ＣＭＳでは、実行時にスキーマをアップグレードすると、構成データにスキーマバージョン固有の変換プログラムを適用する必要性が生じ得る。結局のところ、このようなプログラムを維持することは面倒な作業となり得る。
【００２３】
構成縮小を実行すること、すなわち詳細な構成から元々の高レベル定義を抽出することが可能な場合、変換プログラムはより単純であり、それほど頻繁には必要でない。高レベル定義に作用する変換プログラムは、詳細な構成に直接作用する変換プログラムよりも単純である。変換後、アップグレードされたスキーマに従って、高レベル定義を再び詳細な構成に拡大することができる。変更又は補足されているのは、詳細なビューのみとなり得る。このような場合、構成縮小が利用可能であれば、スキーマ固有の変換は全く必要ない。また、コマンドログのアプローチを使用してスキーマのアップグレードを容易にすることもできるが、これにより変換プログラムに不必要な複雑性が導入されることがある。さらに、ＮＥの寿命に応じて、変換プログラムの実行時間及びコマンドログの長さが増えることがある。
【００２４】
構造化問い合わせ言語（ＳＱＬ）に基づく最新のリレーショナルデータベースは、構成拡大及び検証に類似する問題の解決策を提供する。ＳＱＬ言語は、スキーマ記述の一部として、トリガ、アサーション、及び参照整合性制約の定義を可能にし、通常ＣＭＳが提供するものよりも高レベルなプログラミングインターフェイスを提供する。実際的な用途のための構成データのモデル化にリレーショナルデータモデルが適しているとは限らないので、必ずしもＣＭＳがこのようなＳＱＬを利用するとは限らないこともある。多くの場合、階層型モデルの方が望ましい。例示的な実施形態により提案する解決策は、ＳＱＬよりも有利である。
【００２５】
以下、本解決策の全部ではなく一部の実施形態を示す添付図面を参照しながら、本解決策の例示的な実施形態をより詳細に説明する。実際には、本解決策は多くの異なる形で具体化することができ、本明細書に示す実施形態に限定されると解釈すべきではなく、むしろこれらの実施形態は、本開示が、適用可能な法的要件を満たすように提供するものである。本明細書では、いくつかの箇所で「ある（ａｎ）」、「１つの（ｏｎｅ）」、又は「いくつかの（ｓｏｍｅ）」実施形態について言及する場合があるが、これは必ずしも、このような各言及が同じ実施形態に対するものであること、或いはその特徴が単一の実施形態にのみ適用されることを意味するものではない。また、異なる実施形態の単一の特徴を組み合わせて他の実施形態を実現することもできる。
【００２６】
本解決策の実施形態は、あらゆる通信装置、ネットワーク要素、ユーザ装置、サーバ、対応する構成要素、及び／又はあらゆる通信システム、或いはネットワーク要素の構成管理を行う異なる通信システムのあらゆる組み合わせに適用可能である。通信システムは無線通信システムであってもよく、又は固定ネットワークと無線ネットワークの両方を利用する通信システムであってもよい。特に無線通信では、使用するプロトコル、並びに通信システム、装置及びネットワーク要素の仕様が急速に発展を遂げている。このような発展により、実施形態のさらなる変更が必要となる場合がある。従って、全ての単語及び表現は広く解釈すべきであり、これらは実施形態を限定することではなく例示することを意図するものである。
【００２７】
以下では、様々な実施形態について、これらの実施形態を適用できるシステムアーキテクチャの例として、第３世代無線通信システムＵＭＴＳ（ユニバーサル移動体通信システム）に基づくアーキテクチャを用いて説明するが、これは、実施形態をこのようなアーキテクチャに限定するものではない。
【００２８】
通信システムの一般的アーキテクチャを図１に示す。図１は、いくつかの要素及び機能エンティティのみを示す簡略化したシステムアーキテクチャであるが、これらは全て論理ユニットであり、その実装は図示のものとは異なる場合がある。図１に示す接続は論理接続であり、実際の物理接続は異なる場合がある。当業者には、システムが他の機能及び構造を含むこともできることが明らかである。なお、グループ通信において又はグループ通信のために使用される機能、構造、要素及びプロトコルは、実際の発明とは無関係である。従って、ここでこれらについてより詳細に説明する必要はない。
【００２９】
図１には、基地局（ＢＳ、ノードＢ）、基地局コントローラ（ＢＳＣ）、ホーム・ロケーション・レジスタ（ＨＬＲ）、移動通信交換局（ＭＳＣ）、メディア・ゲートウェイ（ＭＧＷ）、無線ネットワークコントローラ（ＲＮＣ）、ビジタ・ロケーション・レジスタ（ＶＬＲ）、トランスコードレート適合化装置（ＴＲＡＵ）、サービングＧＰＲＳ（汎用パケット無線サービス）サポートノード（ＳＧＳＮ）、又はホームノードＢゲートウェイ（ＨＮＢ−ＧＷ）、モビリティ管理エンティティ及び拡張パケットコアゲートウェイ（ＭＭＥ／ＥＰＣ−ＧＷ）、或いは通信システムの他のあらゆるネットワーク要素などのネットワーク要素１０１を示す。このネットワーク要素は、構成管理装置１０２に接続される。図１には、簡略化した例しか示していない。実際には、ネットワークは、より多くのネットワーク要素及び装置を含むことができる。１又はそれ以上のさらなる装置（図示せず）を介してネットワーク要素と構成管理装置を互いに接続することもできると理解されたい。また、構成管理装置１０２を、ネットワーク要素１０１の一体部分とすることもできると理解されたい。しかしながら、これらの実施形態は、一例として上述したネットワークに限定されるものではなく、当業者であれば、必要な特性を有する他の通信ネットワークにこの解決策を適用することができる。
【００３０】
図２に、本発明の実施形態による装置の例を示す。図２には、ネットワーク要素１０１と接続するように構成された構成管理装置１０２を示している。構成管理装置１０２は、メモリ２０２及びインターフェイス２０３に動作可能に接続されたコントローラ２０１を含む。コントローラ２０１は、装置の動作を制御する。メモリ２０２は、ソフトウェア及びデータを記憶するように構成される。インターフェイス２０３は、ネットワーク要素１０１との接続を設定して維持するように構成される。
【００３１】
ネットワーク要素１０１は、メモリ２０５及びインターフェイス２０６に動作可能に接続されたコントローラ２０４を含む。コントローラ２０４は、ネットワーク要素の動作を制御する。メモリ２０５は、ソフトウェア及びデータを記憶するように構成される。インターフェイス２０６は、構成管理装置１０２との接続を設定して維持するように構成される。
【００３２】
ある実施形態では、ネットワーク要素が、別の装置を介して構成管理装置に接続される。
【００３３】
ある実施形態では、構成管理装置が、ネットワーク要素の構成パラメータを定義し、この構成パラメータをネットワーク要素に提供することができる。図３のシグナリング図に、所要のシグナリングを示す。図３の例では、構成管理装置１０２が、ネットワーク要素の構成パラメータを定義（３０１）し、この構成パラメータをネットワーク要素１０１に送信（３０２）する。その後、構成管理装置１０２及びネットワーク要素１０１は、このパラメータを適用（３０３）することができる。或いは、ネットワーク要素１０１に構成データを送信し、ネットワーク要素１０１がクエリを開始して、これに構成管理装置１０２が応答するようにしてもよい。
【００３４】
図４は、本発明の非限定的な実施形態を示すフロー図である。ステップ４０１において、構成管理装置が、ネットワーク要素の構成パラメータを定義する。ステップ４０２において、構成管理装置が、このパラメータをネットワーク要素に送信する。或いは、ネットワーク要素に構成データを送信し、ネットワーク要素がクエリを開始して、これに構成管理装置が応答するようにしてもよい。
【００３５】
図５は、ネットワーク要素の視点から見た本発明の非限定的な実施形態を示すフロー図である。ステップ５０１において、ネットワーク要素が、構成管理装置からネットワーク要素の構成パラメータを受け取る。ステップ５０２において、ネットワーク要素が、この構成パラメータを適用する。或いは、ネットワーク要素に構成データを送信し、ネットワーク要素がクエリを開始して、これに構成管理装置が応答するようにしてもよい。
【００３６】
例示的な実施形態では、構成管理装置が、複数の継承を含む汎化されたプロトタイプシステムを利用して、プロトタイプ定義内の特定の宣言を使用して構成拡大及び整合性チェックロジックを表現できるようにし、従って部分的に重複するスキーマ固有のプログラムロジックの必要性を排除する。この構成管理装置は、参照整合性チェック、ガーベージコレクション及び構成縮小を自動的に行うために、汎用依存追跡システムも使用する。このデータモデルは、上述した内容に従う。オブジェクトは、構成データ内のオブジェクトの位置を特定する一意のパス名を有する。このシステムでは、属性、参照、及びこれらの割り当て値を構成データ内のオブジェクトとして表し、他のオブジェクトと同等のパス名を有するようにすることもできる。属性及び参照割り当て値に関して言えば、これらは値オブジェクトという名目で符号化される。また、他のタイプの特別なオブジェクト、すなわちセット及びコンテナが存在することもできる。「インスタンス」という用語は、オブジェクトクラスのインスタンスを表すオブジェクトを意味するために使用できるのに対し、「オブジェクト」は、一意のパス名を有するあらゆるエンティティを意味することができる。
【００３７】
オブジェクトクラスの定義とプロトタイプの定義は、単一のエンティティに組み合わせることができる。オブジェクトクラスの定義は、以下を含む。
−  オブジェクトクラスを一意に識別する名称。
−  下位オブジェクトの宣言。
−  暗黙的オブジェクト宣言の順序付きリスト。これらの宣言により、追加の構成オブジェクトの自動生成、すなわち構成拡大が可能になる。
−  継承されたオブジェクトクラス定義、すなわちスーパークラスへの参照。クラス定義を処理する場合には、各スーパークラスから下位の及び暗黙的オブジェクト宣言が再帰的にインポートされる。特定の名称の下位オブジェクトが複数のクラスにより定義される場合、この定義は、互換性のある定義である。
−  クラスが抽象的であるかどうか、すなわちインスタンス化はできずに継承のみできることを示すフラグ。
【００３８】
インスタンスを生成する際には、これを１つのプライマリオブジェクトクラスに割り当てる。このオブジェクトは、このクラスのインスタンスであると言われ、またこのクラスの直接的及び間接的スーパークラスのインスタンスであるとも言われる。各インスタンスは、オブジェクトがインスタンスであると見なされるクラスを示す、．ｉｎｓｔａｎｃｅｏｆという名称の特別な多値属性を有する。オブジェクトをインスタンス化した後には、プライマリオブジェクトクラスを変更することはできない。下位オブジェクト宣言は、オブジェクト名及びオブジェクトタイプを含み、これらは以下のうちの１つとすることができる。
−  属性
属性は、必須の場合も、又は任意の場合もあり、１又は複数の値を割り当てることができる。デフォルト値を指定することもできる。
−  指定されたオブジェクトクラスのインスタンス。
−  指定されたオブジェクトクラスの１又は複数のインスタンへの参照。
−  指定されたオブジェクトクラスのインスタンスのセット。
−  さらなる属性、インスタンス、参照、セット及びコンテナをグループ化するコンテナオブジェクト。
【００３９】
属性、参照、セット及びコンテナの下位は、インスタンスオブジェクトによって自動的に生成される。インスタンスの下位は、インスタンスオブジェクトによって自動的に生成されないが、必要であれば、暗黙的オブジェクト宣言によって生成することができる。暗黙的オブジェクト宣言は、値割り当てオブジェクトを生成することにより、属性及び参照に値を割り当てることができる。暗黙的オブジェクト宣言は、ルールを生成することもできる。オブジェクトクラス定義は、ソフトウェアアップグレード間では静的と見なされる。参照は属性であり、その値は、構成データ内の別のオブジェクトのパス名である。参照のために定義できるいくつかの追加の特性が存在する。
−  参照オブジェクトのクラス。このオブジェクトは、指定されたオブジェクトクラスのインスタンスである。
−  参照の範囲。参照オブジェクトは、このパス名により指定されるサブツリー内に位置する。従って、割り当てオブジェクト名に符号化されたパスは、参照の範囲に関連することができる。このパス名は、参照を格納するオブジェクトに対して絶対的なもの又は相対的なものとすることができる。このパス名は間接的なものとすることができ、この場合、範囲は、他の参照割り当てに依存することができる。
−  これがバインディング参照であるかどうかを示すフラグ。バインディング参照は、同じトランザクション内で参照割り当て自体が削除されない限り、参照対象の削除を防ぐ。非バインディング参照は、対象オブジェクトとともに自動的に削除される。
−  相互参照。これは、参照オブジェクトクラスにより定義される参照を参照する任意の特性である。これにより、双方向参照の自動的な生成が可能になる。
【００４０】
パス名は、構成データ内のオブジェクトの位置を示す一連のオブジェクト名である。絶対パス名は、ルートオブジェクトに対する位置を示す。オブジェクトは、その絶対パス名によって一意に識別することができる。相対パス名は、別のオブジェクトに対する位置を示す。パス名解明は、このパス名が参照するオブジェクトを決定する再帰的な動作である。パス名解明は、このパスが関連するオブジェクトから開始する。解明アルゴリズムは、パス名から第１のコンポーネントを読み出す。このコンポーネントは、現在のオブジェクトの下位を参照することができる。次の一巡では、このオブジェクトが現在のオブジェクトになり、第１のコンポーネントがパスから除去される。パスのコンポーネントの各々の処理が完了すると解明が終了し、最後の現在のオブジェクトが初期解明結果になる。しかしながら、コンポーネントは、以下の特別なシンボルのうちの１つであってもよい。
−  ．現在のオブジェクト自体を参照する。
−  ．．現在のオブジェクトの上位を参照する。
−  ．．．現在のオブジェクトが割り当て値を有する単一値の参照である場合、参照オブジェクトを参照する。
このようにして参照をたどることを逆参照と呼ぶ。
【００４１】
パスコンポーネントが、存在しないオブジェクトを参照する場合、解明はうまくいかない。少なくとも１つの．．．コンポーネントを含むパス名は、間接的パス名である。他のパス名は、直接的パス名である。パス名解明に成功すると、オブジェクトの解明に加え、解明中に横切ったオブジェクトのリストという２次的結果ももたらされる。この結果は、オブジェクト生成動作によって使用される。間接的パスに関しては、逆参照された単一値参照の値割り当てオブジェクトも、横切ったオブジェクトのリストに含まれる。
【００４２】
トランザクションモデルに関しては、複数の修正動作をトランザクションにグループ化することがサポートされる。ＡＰＩ及びユーザインターフェイスは、トランザクションの開始、コミット及び取り消しを行うとともに、トランザクションを背景としてクエリ及び修正動作を発行する手段を提供する。トランザクションは原子的であり、他の動作から分離される。コミットされてないトランザクションの中間状態は、トランザクションの外からは見えず、トランザクションの外で開始された動作は、これを妨げることができない。入れ子トランザクションがサポートされ、すなわちトランザクションは、それ自体が複数の動作から成るトランザクションである動作を含むことができる。トランザクションは、例えば以下を含む構造として実装することができる。
−  データベース又は入れ子トランザクションへの参照、及び、
−  生成された、削除された、又は依存が変化したオブジェクトのリスト。
【００４３】
また、様々なインデックスを使用してパフォーマンスを最適化することもできる。修正動作は、オブジェクトリストを修正するにすぎず、これらは、コミット段階でデータベース又は入れ子トランザクションに伝達される。クエリ動作は、これらのリストから、クエリされたオブジェクトの状態を最初にチェックする。このオブジェクトが、トランザクションにおいて触れられていなかった場合、このクエリは、データベース又は入れ子トランザクションに転送される。データベース又は入れ子トランザクションに変更を伝える前に、コミット動作が、新たに生成されたオブジェクトのためのルールを処理する。ルールの処理後、ＣＭＳは、全ての必須属性及び参照が割り当てられたかどうか、及び属性割り当てが意味的に正しいかどうか、などのいくつかの妥当性チェックを行うことができる。これは、トランザクションの一貫性を保証するために行われる。また、依存追跡及びルール処理も、一貫性を保証する役割を有する。上記で概説した解決策により、トランザクションに原子性、一貫性及び分離性が与えられるが、ただし同時に１つのトランザクションしか修正を行えないものとする。この制限を緩和できる技術が存在し、この実施形態ではこれらの技術を使用することができる。
【００４４】
オブジェクト依存追跡システムを採用することができる。この実施形態では、依存とは、依存関係のサブジェクト及びオブジェクトと呼ばれる２つの構成オブジェクト間の方向関係のことである。サブジェクトは、オブジェクトに対して依存を保持すると言われる。依存は、以下で説明するようにＣＭＳによって自動的に生成され、外部インターフェイスを介して公開されることはない。４つのタイプの依存が存在する。
−  ＤＥＰＥＮＤＳ＿ＯＮ：この依存は、遅くともオブジェクトが削除された時にサブジェクトが削除されることを意味する。各構成オブジェクトは、少なくとも構成データ内の上位オブジェクトに対してこの種の依存を保持する。
−  ＵＳＥＳ：この依存は、オブジェクトの存在を正当化し、サブジェクトが存在する限り、自動ガーベージコレクションによるオブジェクトの削除を防ぐ。
−  ＲＥＱＵＩＲＥＳ：この依存は、同じトランザクション内でサブジェクトが削除されない限り、オブジェクトの削除を防ぐ。
−  ＥＸＰＯＲＴＳ：この依存は、オブジェクトが、オペレータにより明示的に生成されたこと、すなわち高レベル構成の一部であることを示す。このサブジェクトは、ルートオブジェクトである。この依存は、対応するＵＳＥＳ依存とともにしか存在しない。
【００４５】
ＥＸＰＯＲＴＳ依存が存在することにより、どのオブジェクトが高レベル構成の一部であるかを推測できるようになり、従って構成縮小を実施できるようになる。その他の依存では、同様の構成が最初から生成されている場合、高レベル構成オブジェクトを生成すべき順序を推測できるようになる。
【００４６】
オブジェクト依存に基づいてガーベージコレクションを行うことができる。ルートオブジェクトからＵＳＥＳ依存をたどることによって構成オブジェクトに到達できない場合、又は構成オブジェクトのうちのいずれかのＤＥＰＥＮＤＳ＿ＯＮ依存のオブジェクトが削除される場合には、構成オブジェクトが自動的に削除される。ルートオブジェクト自体は、決して削除されない。この削除アルゴリズムにより、オブジェクト間の循環依存を検出することができる。依存追跡及びガーベージコレクションシステムは、一般的なオブジェクト削除動作の実施を容易にする。
【００４７】
構成オブジェクト上の動作は、ＣＭＳにより提供されるオブジェクト固有の修正動作を含む。これらの動作は原子的であり、すなわち単一のトランザクション内で行われる。これらの動作は、成功するか、それとも障害時に完全にロールバックするかのいずれかである。他の動作を含むトランザクション内で修正動作を実行する場合、ＣＭＳは、そのための入れ子トランザクションを内部的に生成する。
【００４８】
このオブジェクト生成動作は、新たなオブジェクトのパスを入力として必要とする。このパスは、上位オブジェクトのパスと対象オブジェクト名に分割することができる。この生成動作により、上位オブジェクトのクラス定義内の下位の宣言からの新たなオブジェクトのタイプが決まる。このタイプは、インスタンス、属性又は参照値割り当て、或いはルールとすることができる。属性割り当ての生成は、比較的簡単な動作であるが、その他の場合はより複雑である。
【００４９】
インスタンスの生成に関し、ＣＭＳでは、インスタンスオブジェクト生成動作が、構成拡大を行うためにオブジェクトクラス固有の部分を必要とする場合がある。ある実施形態では、オブジェクトクラス定義によって必要なアクションが符号化され、十分に汎用的な実装が可能になる。オブジェクト生成動作への入力として、プライマリオブジェクトクラスを与えることができる。省略された場合、このオブジェクトクラスは、上位オブジェクトのクラス定義により指定されるオブジェクトクラスである。いずれにせよ、このオブジェクトは、そのクラスのインスタンスである。プライマリオブジェクトクラス及びそのスーパークラスの暗黙的オブジェクト宣言を処理する。基本的に、各宣言は、同じトランザクション内で行われる単一のオブジェクト生成動作への入力を記述する。暗黙的オブジェクトのパスは、暗示するオブジェクトに対して絶対的なもの又は相対的なものとすることができる。また、間接的なパスも可能である。以下の依存が生成され、暗示するオブジェクトがサブジェクトである。
−  暗黙的オブジェクト宣言において与えられたパスを解明する際に、すなわちアルゴリズムに基づいて生成すべき暗黙的オブジェクトの上位まで解明する際に横切った各オブジェクトに対するＲＥＱＵＩＲＥＳ依存、
−  暗黙的オブジェクトに対するＲＥＱＵＩＲＥＳ依存、及び、
−  暗黙的オブジェクトに対するＵＳＥＳ依存。
【００５０】
これらの依存は、暗黙的オブジェクトの削除が早くなり過ぎるのを防ぐ。間接的なパスを使用する場合、横切ったオブジェクトに対する依存が、暗黙的オブジェクトの絶対位置を決定した単一値の参照割り当ての変化を防ぐ。暗黙的オブジェクト宣言の処理順は確定的なものである。特定のオブジェクトクラス定義からの宣言は、これらの宣言が定義内に現れる順序と同じ順序で処理される。これらの宣言は、全てのスーパークラスの宣言が処理されるまで処理されない。オブジェクトクラスに加え、生成動作への引数としてインスタンス固有の属性割り当てを与えることも可能である。属性割り当てオブジェクトは、暗黙的オブジェクト宣言の処理後に同じトランザクション内で生成される。この時点で、関連する属性のデフォルト値割り当ても生成される。暗黙的オブジェクト宣言を処理する際にいずれかの属性割り当てオブジェクトが生成された場合、これらのオブジェクトは、メインオブジェクトと同様のＲＥＱＵＩＲＥＳ及びＵＳＥＳ依存のオブジェクトである。
【００５１】
参照割り当ては、対象オブジェクトへの直接的なパスを入力として取る。このパスは、絶対的なもの、参照を含むオブジェクトに対して相対的なもの、又は参照の範囲に対して相対的なものとすることができる。参照オブジェクトは、参照定義により指定されるクラス及び範囲制限を満たす。割り当て手順は、オブジェクトクラスにより定義される参照の範囲を解明することを含む。解明中に横切った各オブジェクトでは、ＤＥＰＥＮＤＳ＿ＯＮ依存が生成され、サブジェクトが新たな参照割り当てオブジェクトになる。バインディング参照の場合、代わりにＲＥＱＵＩＲＥＳ依存が生成される。割り当てオブジェクトは、対象オブジェクトにも類似する依存を保持する。これらの依存は、対象オブジェクト、又は（間接的なパスを使用して潜在的に表される）範囲に影響を与えるいずれかの参照がいつ変化又は消滅しようとするかを保証する。
−  影響を受けた参照割り当ては削除され、又は、
−  バインディング参照の場合には動作が防げられる。
【００５２】
オブジェクトクラスによって相互参照が定義される場合、参照割り当ての結果、対象オブジェクトから参照インスタンスオブジェクトへの相互参照割り当てが生成される可能性がある。この場合、参照割り当ての存続期間を結合するために、これらの参照割り当て間にＵＳＥＳ依存が生成され、オブジェクトは暗黙的相互参照である。
【００５３】
生成動作は、オペレータによって呼び出された場合、或いは暗黙的オブジェクトリスト又はルール処理（暗黙的及び明示的オブジェクト）の結果として呼び出された場合でわずかに異なる。オブジェクトがオペレータによって明示的に生成された場合、このオブジェクトのためのＵＳＥＳ及びＥＸＰＯＲＴＳ依存が生成され、サブジェクトがルートオブジェクトになって、このオブジェクトを高レベル構成に属するようにマークする。これは、メイン（インスタンス）オブジェクトのために生成されたあらゆる属性割り当てオブジェクトに対しても行われる。
【００５４】
オペレータが、既に存在するオブジェクトを生成しようと試みる場合、この動作はうまくいかない。暗黙的オブジェクト定義又はルールによって既存のオブジェクトの生成を試みる場合は、必ずしも動作がうまくいかないとは限らない。既存のオブジェクトが、要求されたオブジェクトクラスのインスタンスであり、矛盾する（単一値の）属性又は参照割り当てが存在しなければ、この動作はうまくいく。紛失した属性及び参照割り当てが生成され、動作前にはオブジェクトが存在しなかったかのようにこれらの及び既存のオブジェクトに関する依存が生成される。
【００５５】
ＣＭＳでは、削除動作が、参照整合性チェック及び潜在的にいくつかの関連オブジェクトの削除を処理するために、オブジェクトクラス固有の部分を必要とすることがある。ある実施形態では、依存データによって必要なアクションが符号化され、十分に汎用的な実装が可能になる。削除動作は、ＥＸＰＯＲＴＳ依存のオブジェクト、すなわち高レベル構成オブジェクトに対してのみ許可される。このようなオブジェクトが削除されると、ガーベージコレクション手順がトリガされて、さらなるオブジェクトが削除されるようになる。少なくとも１つのＲＥＱＵＩＲＥＳ依存が存在する場合には削除要求が拒否され、オブジェクトはトランザクション内で削除されるが、サブジェクトは削除されない。例えば、必須属性の割り当てに削除要求が適用されるような場合、他の理由でこの削除要求を拒否することもできる。
【００５６】
フラッシュ動作は、単一のトランザクション内の対象オブジェクトの全ての下位オブジェクトを削除する。全ての下位オブジェクトは、ＥＸＰＯＲＴ依存のオブジェクトでなければならない。
【００５７】
属性及び参照オブジェクトには、セット動作を適用することができる。セット動作は、対象オブジェクトをフラッシュし、入力に従って対象オブジェクトの下に１又はそれ以上の値割り当てオブジェクトを生成する。セット動作のあらゆる中間状態では妥当性チェックは行われず、必須属性及び参照に対しても再割り当てが可能になる。
【００５８】
暗黙的オブジェクト宣言は、オブジェクトのインスタンス化時に、追加プログラムコードを使用せずに関連オブジェクトを自動的に生成できるようにする。ルールは、構成管理装置にさらに多くの柔軟性を加え、暗黙的オブジェクト宣言が、
−  属性及び参照割り当てを含む他のオブジェクトに依存すること、
−  将来的にいくつかの指定された条件が満たされた時に処理されること、及び、
−  データベースオブジェクトに整合性制約を課すこと、
を可能にする。
【００５９】
ルールは、ルールを所有するオブジェクトの下の．ｒｕｌｅという名称の特別なセットの下に配置された名前付きオブジェクトを参照する。ルールの範囲は、所有するオブジェクトから開始するサブツリーに制限される。ルールオブジェクトは、以下の下位を含む。
−  オブジェクトセレクタのセット。セレクタは、名称及びパターンから成り、これ対してオブジェクトパスが照合される。パターンは、例えば正規表現（ｒｅｇｅｘ）として、又は（特に、ＸＭＬ文書の用途の場合）ＸＰａｔｈ構文に基づいて実装することができる。オブジェクトパスは、所有するオブジェクトに関連する。パターンに一致するオブジェクトは、絶対的及び相対的オブジェクトパスのための、及び潜在的にはグループが一致する正規表現のための変数をもたらす。これらの変数には、数式、条件式、アサーション式、及びオブジェクト宣言によってアクセスすることができる。ルールは、少なくとも１つのセレクタを有する。
−  数式のセット。数式は、条件式、アサーション式、及びオブジェクトルールによってアクセスできる文字列型変数をもたらす名称及び式から成る。
−  条件。選択されたオブジェクトのセットに対してルールが有効であるかどうかを指定するブール演算式。この式は、セレクタ及び数式変数への参照を含むことができる。省略した場合、トートロジーが推測される。
−  アサーション。ブール演算式は、定義した場合、条件を満たす全ての一致するオブジェクトのセットに真の値をもたらす。
−  暗黙的オブジェクト宣言のセット。この宣言は、オブジェクトセレクタ及び数式変数への参照を含むことができる。個々の宣言は、これらの相互処理順序を示す名称も有する。
【００６０】
ルール及びそのコンポーネントがオブジェクトである時には、他のオブジェクトの暗黙的オブジェクト宣言によりルールを生成することができる。ルールが生成されると、その下により多くの暗黙的オブジェクト宣言を生成することにより、このルールを拡張することができる。ルールは、必ずしも明示的に生成又は拡張されるとは限らないが、暗黙的オブジェクト宣言だけは介する。ルール及びその拡張は、その他の暗黙的オブジェクトのように通常のガーベージコレクション機構によって削除される。１つの代替の実装は、数式、条件式及びアサーション式を、関連オブジェクトの下の具体的な構文木として直接記憶することである。これにより、新たなオブジェクトの宣言によって既存の構文木を増強できるので、拡張可能なアサーション式を使用できるようになる。ＣＭＳは、セレクタパターン及び式内で使用する原始関数を定義するための言語を提供する。柔軟性を加えるために、ＣＭＳは、例えば、
−  構文木を特別な場所に構築することによる、式内で使用すべき導関数、及び、
−  汎用プログラム言語によるカスタムプリミティブ及びオブジェクトセレクタ、
の定義をサポートすることができる。
【００６１】
ＣＭＳのパフォーマンスを最適化するために、パラダイムの見地から必要でないとしても以下の制約を課す。
１．ルールの生成後には、いかなる新たなセレクタ又は数式も生成することができない。
２．数式及び条件式を拡張不可とする（アサーション式のみ可能）。
３．式は、セレクタ変数及び所有するオブジェクトの静的特性、すなわちオブジェクトのパス及びクラスを介してしかデータベースの状態に依存することができない。
【００６２】
これらの制約により、データベースの更新時に式を再評価する必要性が大幅に低減される。具体的には、制約３は、いかなる式も再評価することなく削除を行えることを意味する。例外は、構文木の部分的な削除に起因してアサーション式が変更された場合であり、この場合には特定の式を再評価する必要がある。
【００６３】
オブジェクトのためのルールを生成する場合、その支配的な下位オブジェクトをルールの各セレクタと照合する。各々が一致する場合、セレクタオブジェクトの下に特別なマッチオブジェクトが生成される。マッチオブジェクトは、その照合に関連する各変数割り当てを記憶する。マッチオブジェクトと一致するオブジェクトとの間にＤＥＰＥＮＤＳ＿ＯＮ依存が形成され、マッチオブジェクトはサブジェクトである。セレクタの下にマッチオブジェクトが生成されると、そのルールの他の全てのセレクタのマッチオブジェクトのセットからデカルト積が計算される。この積集合の各要素は、マッチオブジェクトのベクトルであり、以下のように処理される。
１．ベクトルの全てのマッチオブジェクトの変数割り当てを互いに、及び新たに生成されたマッチオブジェクトの割り当てと組み合わせる。
２．セレクタ変数の参照に割り当て値を代入して数式表現を評価する。これにより、追加の変数割り当てが生成される。
３．セレクタ及び数式変数の参照に割り当て値を代入して条件式を評価する。偽の場合、このベクトルの処理を停止する。
４．ルールオブジェクトの下にグループマッチオブジェクトを生成する。グループマッチオブジェクトは、組み合わせた変数割り当て、及び数式により生成された変数割り当てを記憶する。ベクトルのマッチオブジェクト毎に、ＤＥＰＥＮＤＳ＿ＯＮ依存を生成し、グループマッチオブジェクトをサブジェクトとする。
５．セレクタ及び数式変数の参照に割り当て値を代入してアサーション式を評価する。偽の場合、このトランザクションを中止する。
６．変数の参照に割り当て値を代入して、ルールの暗黙的オブジェクト宣言を処理する。この手順は、オブジェクトをインスタンス化する場合と同様である。また、宣言オブジェクトの下に特別グループマッチ特定オブジェクトが生成される。このオブジェクトは、グループマッチオブジェクトに対してＤＥＰＥＮＤＳ＿ＯＮ依存を保持し、暗黙的オブジェクト及び潜在的には関連属性及び参照割り当てに対してＲＥＱＵＩＲＥＳ及びＵＳＥＳ依存を保持する。なお、暗黙的オブジェクトは、それ自体がルール又はそのコンポーネントであってもよい。
【００６４】
（非ルール）オブジェクトが生成されると、この新たなオブジェクトを、新たなルールの生成時と同様の方法で、その直接的及び間接的上位オブジェクトの既存のルールに対して照合する。この処理は、直接上位のルールから開始し、ルートに向けて継続する。同じレベルのルールは、これらの名称によって示される順序で処理される。この処理の結果、新たな暗黙的オブジェクトが生成される可能性がある。コンポーネントの生成又は削除に起因してアサーション構文木のルールが変更された場合、ルールの全ての既存のグループマッチオブジェクトに関して（これらが記憶する変の割り当てに従って）式が再評価される。アサーションがいずれかのグループマッチに関して偽と評価した場合、トランザクションは中止される。新たな暗黙的オブジェクト宣言を追加することによってルールが拡張された場合、この新たな宣言が、上記のシーケンスのステップ６に従って処理される。この手順を、全ての既存のグループマッチオブジェクトに対して実行する。処理中に設定される依存は、暗黙的オブジェクトの生成をトリガした条件がもはや満たされない場合に暗黙的オブジェクトが自動的に削除されることを保証する。
【００６５】
ルール処理順に関しては２つのアプローチが考えられ、これらによる動作はわずかに異なる。第１の代替案では、ルールが生成され拡張された直後に、又は一致する可能性のあるオブジェクトが生成された直後にルールを処理する。ルールを処理することにより、別のオブジェクトが生成されることがあるので、この処理は再帰的処理になる。再帰レベル毎に入れ子トランザクションを生成することができる。第２の代替例では、トランザクションの最後までルール処理を延期させる。この実装は、トランザクション内で生成されたオブジェクトのリストを保持し、これらの要素をコミット段階で生成順に処理する。オブジェクトリストの最後には、ルールにより生成された暗黙的オブジェクトを挿入する。リストが尽きると、ルール処理が完了する。ルール定義の視点から見れば、後者の代替例の方が柔軟性が高いと見なされる。
【００６６】
以下のリストは、構成データに関連する２、３の例、並びに（ＨＡＳ、ＣＬＭ、ＡＭＦなどの）高可用性サービスに関する背景事情及びその構成によって例示的な構成管理装置の能力を示すものである。
【００６７】
リスト１は、オブジェクトクラス定義がどのように見えるかを示すものである。ｃｌａｓｓ  ｆｓ．ｈａ．ｎｏｄｅ．ｓｕｐｅｒｖｉｓｅｄは、ｃｌａｓｓ  ｆｓ．ｈａ．ｎｏｄｅ．ｍａｎａｇｅｄを継承し、回復ユニット（ｆｓ．ｈａ．ｒｕ）オブジェクトの追加のセット型下位を導入する。（サービスユニットと呼ばれることもある）回復ユニットクラスは下位参照を含み、サブツリーｈａ  ｒｇ内の（サービスグループと呼ばれることもある）回復グループ（ｆｓ．ｈａ．ｒｇ）インスタンスを示す。（これらの例では、パスの区切りとして空白文字を使用する）。この参照は、相互参照定義も特徴とし、回復グループオブジェクトクラス内のｒｕという名称の多値参照を参照する。以下のリスト１に、オブジェクトのクラス定義の例を示す。
［リスト１］
class fs.ha.node.supervised {
inherits fs.ha.node.managed;
set ru { type fs.ha.ru; }
}
class fs.ha.ru {
reference rg {
type fs.ha.rg;
scope ha rg;
backref ru;
}
set process { type fs.ha.process; }
string control-script;
...
}
class fs.ha.rg {
reference ru {
type fs.ha.ru;
multivalue;
scope ha;
backref rg;
}
...
}
【００６８】
リスト２は、単純な暗黙的オブジェクト定義を示すものである。ＦｏｏＳｅｒｖｅｒ（ｆｓ．ｈａ．ｒｕ．ＦｏｏＳｅｒｖｅｒ）のタイプの回復ユニットが、回復ユニットの基本クラスを継承することに加え、それ自体の２つの下位を自動的に生成し、制御スクリプト属性のための値を割り当てる。（．ｐｒｏｃｅｓｓ  Ｆｏｏなどの）先頭に．成分を付けたパス名は、インスタンスオブジェクトに関連するものとして解釈される。以下のリスト２に、回復ユニットタイプ定義の例を示す。
［リスト２］
class fs.ha.ru.FooServer {
inherits fs.ha.ru;
imply . process Foo { type fs.ha.process.Foo; }
imply . process Bar { type fs.ha.process.Bar; }
imply . control-script \
/opt/nokiasiemens/SS_Foo/script/FooServerControl.sh
}
【００６９】
リスト３は、データベース例のサブツリーｈａ  ｎｏｄｅ  ＣＬＡ−０のオブジェクトをリストにしたものである。リスト２の定義が有効である間に、オペレータが、ｆｓ．ｈａ．ｒｕ．ＦｏｏＳｅｒｖｅｒタイプのオブジェクトｈａ  ｎｏｄｅ  ＣＬＡ−０  ｒｕ  ＦｏｏＳｅｒｖｅｒを生成することを意図したコマンドを発行したと仮定する。リスト４（後の説明を参照）は、動作後のサブツリーを示すものであり、生成されたオブジェクトをイタリック体にしている。生成コマンド内に提供される情報は太字にしている。残りのオブジェクトは、オブジェクトクラス定義に基づいて生成される。以下のリスト３に、データベース例の一部を示す。
［リスト３］
ha node CLA-0
ha node CLA-0 .instanceof
ha node CLA-0 .instanceof fs.ha.node
ha node CLA-0 .instanceof fs.ha.node.cla
ha node CLA-0 .instanceof fs.ha.node.managed
ha node CLA-0 .instanceof fs.ha.node.supervised
ha node CLA-0 .rule
ha node CLA-0 ru
ha node CLA-0 ru .rule
ha node CLA-0 ru DirectoryServer
ha node CLA-0 ru DirectoryServer .instanceof
ha node CLA-0 ru DirectoryServer .instanceof fs.ha.ru
ha node CLA-0 ru DirectoryServer .instanceof fs.ha.ru.DirectoryServer
ha node CLA-0 ru DirectoryServer .rule
ha node CLA-0 ru DirectoryServer control-script
ha node CLA-0 ru DirectoryServer process
ha node CLA-0 ru DirectoryServer process .rule
ha node CLA-0 ru DirectoryServer process LDAPServer
ha node CLA-0 ru DirectoryServer process LDAPServer .instanceof
ha node CLA-0 ru DirectoryServer process LDAPServer .instanceof \
fs.ha.process
ha node CLA-0 ru DirectoryServer process LDAPServer .instanceof \
fs.ha.process.LDAPServer
ha node CLA-0 ru DirectoryServer process LDAPServer .rule
ha node CLA-0 ru DirectoryServer rg
ha node CLA-0 ru DirectoryServer rg Directory
【００７０】
現在では、クラスタ構成の定義は容易な作業ではない。この作業は、高レベル機能のみを有効にし、場合によってはこれらにいくつかのパラメータを供給する機能管理システムを実装することによって簡略化することができ、選択した機能に基づいて、回復グループ、回復ユニット、処理及び記憶装置を表す構成オブジェクトが自動的に生成される。実際には、機能定義が、必要とする管理されるオブジェクトに関する情報を含むことが必要である。
【００７１】
ｆｅａｔｕｒｅ  Ｆｏｏが、全ての監視されるノード上に展開されたＦｏｏＳｅｒｖｅｒ回復ユニットを必要とすると仮定する。これらの回復ユニットは、非冗長的な回復グループＦｏｏに属するものとする。リスト５は、このｆｅａｔｕｒｅ  Ｆｏｏの定義を示すものである。このクラスをインスタンス化することにより、ｆｅａｔｕｒｅ−Ｆｏｏという名称のルールが生成され、これに対してｈａ  ｎｏｄｅサブツリー内のオブジェクトが照合される。このルールにより、ｔｙｐｅ  ｆｓ．ｈａ．ｎｏｄｅ．．ｓｕｐｅｒｖｉｓｅｄの各現在の及び将来の下位の下にＦｏｏＳｅｒｖｅｒ回復ユニットが生成され、オブジェクトｈａ  ｒｇ  Ｆｏｏにｒｇ参照が割り当てられるようになる。パスは、参照の範囲に関連する（すなわち、Ｆｏｏは、ｈａ  ｒｇ  Ｆｏｏを参照する）と見なされる。以下のリスト５に、機能定義の例を示す。
［リスト５］
class fs.feature.Foo {
inherits fs.feature;
imply ha node .rule feature-Foo {
selector n { pattern "([^ ]+) .instanceof fs.ha.supervised"; }
imply ha rg Foo { type ha.rg.Foo; }
imply ". {n_1} ru FooServer" {
type fs.ha.ru.FooServer;
rg Foo;
}
}
}
class fs.feature.root {
inherits fs.feature;
fs.feature.Foo Foo;
...
}
【００７２】
対応する相互参照も割り当てて、リスト２に示す暗黙的オブジェクト宣言を処理する。このことを、リスト６に示す最初のデータベースによって示し、このリストは、オペレータがオブジェクトｆｅａｔｕｒｅ  Ｆｏｏを生成すると、リスト７に示す状態に変形する。オブジェクトクラスは、上位オブジェクトのクラス（ｆｓ．ｆｅａｔｕｒｅ．ｒｏｏｔ）によって定義されるので、オペレータがオブジェクトクラス（ｆｓ．ｆｅａｔｕｒｅ．Ｆｏｏ）を提供する必要はない。太字のイタリック体にしたオブジェクトは、ルールのセレクタ（ｒｅｇｅｘ（［＾］＋）．ｉｎｓｔａｎｃｅｏｆ  ｆｓ．ｈａ．ｎｏｄｅ．ｓｕｐｅｒｖｉｓｅｄ）に一致し、これによりリスト内のアンダーラインを付してイタリック体で示すマッチオブジェクトが生成される。これらの例では、マッチオブジェクトの名称が整数である。値には特別な意味はなく、基本的に一意の識別子にすぎない。以下のリスト６に、データベース例を示す。
［リスト６］
.rule
feature
feature .instanceof
feature .instanceof fs.feature
feature .instanceof fs.feature.root
feature .rule
ha
ha .rule
ha node
ha node .rule
ha node CLA-0
ha node CLA-0 .instanceof
ha node CLA-0 .instanceof fs.ha.node
ha node CLA-0 .instanceof fs.ha.node.cla
ha node CLA-0 .instanceof fs.ha.node.managed
ha node CLA-0 .instanceof fs.ha.node.supervised
ha node CLA-0 .rule
ha node CLA-0 ru
ha node CLA-0 ru .rule
ha node CLA-0 ru DirectoryServer
ha node CLA-0 ru DirectoryServer .instanceof
ha node CLA-0 ru DirectoryServer .instanceof fs.ha.ru
ha node CLA-0 ru DirectoryServer .instanceof fs.ha.ru.DirectoryServer
ha node CLA-0 ru DirectoryServer .rule
ha node CLA-0 ru DirectoryServer control-script
ha node CLA-0 ru DirectoryServer process
ha node CLA-0 ru DirectoryServer process .rule
ha node CLA-0 ru DirectoryServer process LDAPServer
ha node CLA-0 ru DirectoryServer process LDAPServer .instanceof
ha node CLA-0 ru DirectoryServer process LDAPServer .instanceof \
fs.ha.process
ha node CLA-0 ru DirectoryServer process LDAPServer .instanceof \
fs.ha.process.LDAPServer
ha node CLA-0 ru DirectoryServer process LDAPServer .rule
ha node CLA-0 ru DirectoryServer rg
ha node CLA-0 ru DirectoryServer rg Directory
ha node CLA-1
ha node CLA-1 .instanceof
ha node CLA-1 .instanceof fs.ha.node
ha node CLA-1 .instanceof fs.ha.node.cla
ha node CLA-1 .instanceof fs.ha.node.managed
ha node CLA-1 .instanceof fs.ha.node.supervised
ha node CLA-1 .rule
ha node CLA-1 ru
ha node CLA-1 ru .rule
ha node CLA-1 ru DirectoryServer
ha node CLA-1 ru DirectoryServer .instanceof
ha node CLA-1 ru DirectoryServer .instanceof fs.ha.ru
ha node CLA-1 ru DirectoryServer .instanceof fs.ha.ru.DirectoryServer
ha node CLA-1 ru DirectoryServer .rule
ha node CLA-1 ru DirectoryServer control-script
ha node CLA-1 ru DirectoryServer process
ha node CLA-1 ru DirectoryServer process .rule
ha node CLA-1 ru DirectoryServer process LDAPServer
ha node CLA-1 ru DirectoryServer process LDAPServer .instanceof
ha node CLA-1 ru DirectoryServer process LDAPServer .instanceof \
fs.ha.process
ha node CLA-1 ru DirectoryServer process LDAPServer .instanceof \
fs.ha.process.LDAPServer
ha node CLA-1 ru DirectoryServer process LDAPServer .rule
ha node CLA-1 ru DirectoryServer rg
ha node CLA-1 ru DirectoryServer rg Directory
ha rg
ha rg .rule
ha rg Directory
ha rg Directory .instanceof
ha rg Directory .instanceof fs.ha.rg
ha rg Directory .instanceof fs.ha.rg.Directory
ha rg Directory .instanceof fs.ha.rg.activestdby
ha rg Directory .instanceof fs.ha.rg.coldactivestdby
ha rg Directory .rule
ha rg Directory ru
ha rg Directory ru node CLA-0 ru DirectoryServer
ha rg Directory ru node CLA-1 ru DirectoryServer
【００７３】
以下のリスト７は、（リスト５の定義が有効である間に）オブジェクト生成時にリスト６内のデータベースをいかにして更新するかを示すものである。
［リスト７］
2014504469.tif 000003
2014504469.tif 000004
2014504469.tif 000005
2014504469.tif 000006
【００７４】
リスト内のアンダーラインも付したイタリック体の暗黙的オブジェクトは、ルールに従って生成され、正規表現グループ参照｛ｎ＿１｝の代わりにノード名（ＣＬＡ−０、ＣＬＡ−１）を使用する。ここでは、｛ｎ＿１｝がセレクタｎの最初のグループを参照する。グループには括弧を付けている。（サブツリーｈａ  ｎｏｄｅ内の）オブジェクトＣＬＡ−０．ｉｎｓｔａｎｃｅｏｆ  ｆｓ．ｈａ．ｎｏｄｅ．ｓｕｐｅｒｖｉｓｅｄが、（［＾］＋）．ｉｎｓｔａｎｃｅｏｆ  ｆｓ．ｈａ．ｎｏｄｅ．ｓｕｐｅｒｖｉｓｅｄに一致する場合、オブジェクト宣言を処理する際に、｛ｎ＿１｝はＣＬＡ−０として評価される。例えば、．｛ｎ＿１｝ｒｕ  ＦｏｏＳｅｒｖｅｒは、ＣＬＡ−０  ｒｕ  ＦｏｏＳｅｒｖｅｒ．として評価される。対応する絶対パスは、ｈａ  ｎｏｄｅ  ＣＬＡ−０  ｒｕ  ＦｏｏＳｅｒｖｅｒになる。これらのオブジェクトを生成することにより、ｆｓ．ｈａ．ｒｕ．ＦｏｏＳｅｒｖｅｒクラスの暗黙的オブジェクト宣言が、リスト４に示す方法と同様の方法で処理されるようになる。以下のリスト４に、オブジェクト生成時にリスト３内のデータベース部分をいかにして更新するかを示す。
［リスト４］
2014504469.tif 000007
2014504469.tif 000008
【００７５】
なお、上述の例では、回復グループオブジェクトもルールによって生成される。回復グループオブジェクトは、暗黙的オブジェクト宣言によって直接生成してもよいが、ここでは最初のｆｓ．ｈａ．ｎｏｄｅ．ｓｕｐｅｒｖｉｓｅｄの下位が現れるまで生成が延期されている。
【００７６】
リスト８は、オペレータがＡＳ−０という名称の新たなペイロードノードオブジェクト（ｆｓ．ｈａ．ｎｏｄｅ．ｐａｙｌｏａｄ）を生成する際に、リスト７に示すデータベースをいかにして更新するかを示すものである。ｆｓ．ｈａ．ｎｏｄｅ．ｓｕｐｅｒｖｉｓｅｄ  ｃｌａｓｓからペイロードノードクラスが導出されるという事実によって新たなマッチオブジェクトが生成され、これによりｈａ  ｎｏｄｅ  ＡＳ−０  ｒｕの下に新たなｆｓ．ｈａ．ｒｕ．ＦｏｏＳｅｒｖｅｒのインスタンス、及びそのｈａ  ｒｇ  Ｆｏｏへの連結が生成される。以下のリスト８に、（リスト５の定義が有効である間に）さらなるオブジェクトの生成時にリスト７のデータベースをいかにして更新するかを示す。
［リスト８］
2014504469.tif 000009
2014504469.tif 000010
2014504469.tif 000011
ha node CLA-1
ha node CLA-1 .instanceof
ha node CLA-1 .instanceof fs.ha.node
ha node CLA-1 .instanceof fs.ha.node.cla
ha node CLA-1 .instanceof fs.ha.node.managed
ha node CLA-1 .instanceof fs.ha.node.supervised
ha node CLA-1 .rule
ha node CLA-1 ru
ha node CLA-1 ru .rule
ha node CLA-1 ru DirectoryServer
ha node CLA-1 ru DirectoryServer .instanceof
ha node CLA-1 ru DirectoryServer .instanceof fs.ha.ru
ha node CLA-1 ru DirectoryServer .instanceof fs.ha.ru.DirectoryServer
ha node CLA-1 ru DirectoryServer .rule
ha node CLA-1 ru DirectoryServer control-script
ha node CLA-1 ru DirectoryServer process
ha node CLA-1 ru DirectoryServer process .rule
ha node CLA-1 ru DirectoryServer process LDAPServer
ha node CLA-1 ru DirectoryServer process LDAPServer .instanceof
ha node CLA-1 ru DirectoryServer process LDAPServer .instanceof \
fs.ha.process
ha node CLA-1 ru DirectoryServer process LDAPServer .instanceof \
fs.ha.process.LDAPServer
ha node CLA-1 ru DirectoryServer process LDAPServer .rule
ha node CLA-1 ru DirectoryServer rg
ha node CLA-1 ru DirectoryServer rg Directory
ha node CLA-1 ru FooServer
ha node CLA-1 ru FooServer .instanceof
ha node CLA-1 ru FooServer .instanceof fs.ha.ru
ha node CLA-1 ru FooServer .instanceof fs.ha.ru.FooServer
ha node CLA-1 ru FooServer .rule
ha node CLA-1 ru FooServer control-script
ha node CLA-1 ru FooServer control-script \
/opt/nokiasiemens/SS_Foo/script/FooServerControl.sh
ha node CLA-1 ru FooServer process
ha node CLA-1 ru FooServer process .rule
ha node CLA-1 ru FooServer process Bar
ha node CLA-1 ru FooServer process Bar .instanceof
ha node CLA-1 ru FooServer process Bar .instanceof fs.ha.process
ha node CLA-1 ru FooServer process Bar .instanceof fs.ha.process.Bar
ha node CLA-1 ru FooServer process Bar .rule
ha node CLA-1 ru FooServer process Foo
ha node CLA-1 ru FooServer process Foo .instanceof
ha node CLA-1 ru FooServer process Foo .instanceof fs.ha.process
ha node CLA-1 ru FooServer process Foo .instanceof fs.ha.process.Foo
ha node CLA-1 ru FooServer process Foo .rule
ha node CLA-1 ru FooServer rg
ha node CLA-1 ru FooServer rg Foo
ha rg
ha rg .rule
2014504469.tif 000012
【００７７】
リスト５に示すルール定義は、１つのセレクタのみを特徴とする。複数のセレクタ、並びに数式及び条件式を使用することにより、より複雑なトリガ条件を有するルールを定義することができる。
【００７８】
リスト９は、データベースがリスト８に示す状態にある場合、オペレータがオブジェクトｈａ  ｎｏｄｅ  ＣＬＡ−１を削除した時に何が起きるかを示すものである。太字のアンダーラインで示す（又は太字のイタリック体のアンダーラインを付した）オブジェクトが削除される。以下のリスト９に、オブジェクトの削除時にリスト８のデータベースをいかにして更新するかを示す。
［リスト９］
.rule
feature
feature .instanceof
feature .instanceof fs.feature
feature .instanceof fs.feature.root
feature .rule
feature Foo
feature Foo .instanceof
feature Foo .instanceof fs.feature
feature Foo .instanceof fs.feature.Foo
feature Foo .rule
ha
ha .rule
ha node
ha node .rule
ha node .rule feature-Foo
ha node .rule feature-Foo .match
2014504469.tif 000013
ha node AS-0 ru FooServer process .rule
ha node AS-0 ru FooServer process Bar
ha node AS-0 ru FooServer process Bar .instanceof
ha node AS-0 ru FooServer process Bar .instanceof fs.ha.process
ha node AS-0 ru FooServer process Bar .instanceof fs.ha.process.Bar
ha node AS-0 ru FooServer process Bar .rule
ha node AS-0 ru FooServer process Foo
ha node AS-0 ru FooServer process Foo .instanceof
ha node AS-0 ru FooServer process Foo .instanceof fs.ha.process
ha node AS-0 ru FooServer process Foo .instanceof fs.ha.process.Foo
ha node AS-0 ru FooServer process Foo .rule
ha node AS-0 ru FooServer rg
ha node AS-0 ru FooServer rg Foo
ha node CLA-0
ha node CLA-0 .instanceof
ha node CLA-0 .instanceof fs.ha.node
ha node CLA-0 .instanceof fs.ha.node.cla
ha node CLA-0 .instanceof fs.ha.node.managed
ha node CLA-0 .instanceof fs.ha.node.supervised
ha node CLA-0 .rule
ha node CLA-0 ru
ha node CLA-0 ru .rule
ha node CLA-0 ru DirectoryServer
ha node CLA-0 ru DirectoryServer .instanceof
ha node CLA-0 ru DirectoryServer .instanceof fs.ha.ru
ha node CLA-0 ru DirectoryServer .instanceof fs.ha.ru.DirectoryServer
ha node CLA-0 ru DirectoryServer .rule
ha node CLA-0 ru DirectoryServer control-script
ha node CLA-0 ru DirectoryServer process
ha node CLA-0 ru DirectoryServer process .rule
ha node CLA-0 ru DirectoryServer process LDAPServer
ha node CLA-0 ru DirectoryServer process LDAPServer .instanceof
ha node CLA-0 ru DirectoryServer process LDAPServer .instanceof \
fs.ha.process
ha node CLA-0 ru DirectoryServer process LDAPServer .instanceof \
fs.ha.process.LDAPServer
ha node CLA-0 ru DirectoryServer process LDAPServer .rule
ha node CLA-0 ru DirectoryServer rg
ha node CLA-0 ru DirectoryServer rg Directory
ha node CLA-0 ru FooServer
ha node CLA-0 ru FooServer .instanceof
ha node CLA-0 ru FooServer .instanceof fs.ha.ru
ha node CLA-0 ru FooServer .instanceof fs.ha.ru.FooServer
ha node CLA-0 ru FooServer .rule
ha node CLA-0 ru FooServer control-script
ha node CLA-0 ru FooServer control-script \
/opt/nokiasiemens/SS_Foo/script/FooServerControl.sh
ha node CLA-0 ru FooServer process
ha node CLA-0 ru FooServer process .rule
ha node CLA-0 ru FooServer process Bar
2014504469.tif 000014
2014504469.tif 000015
【００７９】
図６に、動作の最初に実際に存在する関連依存を示す。図６には、リスト９に示す動作に影響を与える依存を示している。リスト９には、削除すべきオブジェクトを太字のアンダーラインで（又は太字のイタリック体のアンダーラインで）示している。図６では、オブジェクトを指す実線矢印でＤＥＰＥＮＤＳ＿ＯＮ依存を示している。右向きの点線矢印で、ＵＳＥＳ依存を示す。左向きの点線矢印で、オブジェクト間にＵＳＥＳ及びＲＥＱＵＩＲＥＳ依存の両方が存在することを示す。図６内の数字は、マッチオブジェクトを表す。ｈａ  ｎｏｄｅ  ＣＬＡ−１及びその下位に加え、以下のオブジェクトも削除される。
【００８０】
−  下位オブジェクトのＤＥＰＥＮＤＳ＿ＯＮ依存により下位オブジェクトに関連するマッチオブジェクト、及び、
−  ＵＳＥＳ依存の枯渇による参照割り当て。
【００８１】
いくつかのＵＳＥＳ依存が残っているので、オブジェクトｈａ  ｒｇ  Ｆｏｏは削除されない。なお、この例では、ルールにより生成されたオブジェクトが、削除されたサブツリー内にたまたま存在してトリガオブジェクトを含んでいる。しかしながら、図６から明らかなように、トリガオブジェクトが消滅する際には、ガーベージコレクションシステムが構成データ内のどこかに位置する暗黙的オブジェクトを発見できるように依存が設定される。
【００８２】
リスト１０は、データベースがリスト９に示す状態にある場合（青で示すオブジェクトを除く）、オブジェクトｆｅａｔｕｒｅ  Ｆｏｏが削除された時に何が起きるかを示すものである。関連する既存の依存を図７に示しており、図７には、リスト１０に示す動作に影響を与える依存を示している。図７のルール及びマッチオブジェクトを囲むボックスは、マッチオブジェクトがルールのサブツリーに属することを示す。図７では、オブジェクトを指す実線の矢印でＤＥＰＥＮＤＳ＿ＯＮ依存を示す。右向きの点線矢印で、ＵＳＥＳ依存を示す。左向きの（又は下向きの５時の方向の）点線矢印で、オブジェクト間にＵＳＥＳ及びＲＥＱＵＩＲＥＳ依存の両方が存在することを示す。メインオブジェクト及びその下位に加え、ＵＳＥＳ依存の枯渇に起因して、ｆｅａｔｕｒｅ  Ｆｏｏを展開するルール、全てのＦｏｏＳｅｒｖｅｒ回復ユニット及びＦｏｏ回復グループといったオブジェクトが、それらの下位とともに削除される。以下のリスト１０に、さらなるオブジェクトの削除時にリスト９のデータベースがいかにして更新されるかを示す。
［リスト１０］
2014504469.tif 000016
2014504469.tif 000017
2014504469.tif 000018
2014504469.tif 000019
【００８３】
リスト１１は、展開特徴が類似する複数の機能が実際のルールを含む共通の基本タイプを利用できるようにするために、リスト５に示す定義をどのように汎化できるかを示すものである。最終的な機能クラスは、ルールを制御するパラメータを定義する。ｆｅａｔｕｒｅ  Ｆｏｏの定義は、リスト５に示す定義に等しい。ｆｅａｔｕｒｅ  Ｚｏｔも同様に展開されるが、回復ユニットは、ｔｙｐｅ  ｆｓ．ｈａ．ｎｏｄｅ．ｃｌａ．のオブジェクトの下にしか生成されない。この例では、ルールが、構成データ内の他の場所に位置するオブジェクトのための別のルールを実際に生成する。また、外部ルールも、複数のセレクタを特徴付けるルールの一例である。しかしながら、各セレクタは、単一値の属性割り当てに一致するので、（全ての一致する属性が割り当てられた時の）個々のセレクタの一致を通じたデカルト積の濃度は常に１に等しい。従って、この場合、機能インスタンス毎に内部ルールの１つのインスタンスのみが生成される。リスト１１の例には、ｉｄｅｎｔｉｆｉｅｒという名称の追加の属性タイプを定義するための考えられる方法も示す。以下のリスト１１に、一般的な基本定義を利用する２つの機能定義例を示す。
［リスト１１］
typedef identifier {
inherits string;
match "[A-Za-z_][A-Za-z_0-9]*";
}
class fs.feature.hosted {
inherits fs.feature;
identifier node-type;    
identifier rg;
identifier rg-type;
identifier ru;
identifier ru-type;
imply . .rule ru {
selector nt { pattern "node-type (.+)"; }
selector g { pattern "rg (.+)"; }
selector gt { pattern "rg-type (.+)"; }
selector u { pattern "ru (.+)"; }
selector ut { pattern "ru-type (.+)"; }
imply "ha node .rule feature-{_name}" {
selector n { pattern "([^ ]+) .instanceof fs.ha.node.{nt_1}"; }
imply "ha rg {g_1}" { type "fs.ha.rg.{gt_1}"; };
imply ". {{n_1}} ru {u_1}" {
type "fs.ha.ru.{ut_1}";
rg "{g_1}";
}
}
}
}
class fs.feature.Foo {
inherits fs.feature.hosted;
node-type supervised;
rg Foo;
rg-type Foo;
ru FooServer;
ru-type FooServer;
}
class fs.feature.Zot {
inherits fs.feature.hosted;
node-type cla;
rg Zot;
rg-type Zot;
ru ZotServer;
ru-type ZotServer;
}
【００８４】
リスト１２は、参照内の間接的範囲を使用する方法を示すものである。ｆｓ．ｈａ．ｎｏｄｅクラスは、ノードが存在する物理的コンピュータ装置を示すｈｗという名称の参照を有する。しかしながら、利用可能なプロセッサコアの一部しかノードに割り当てられていないこともある。従って、この特定のノードのためにいずれのコアが確保されているかを示す、ｃｏｒｅという名称の多値参照が存在する。ｃｏｒｅは、単一の物理的コンピュータ装置に属する。ｃｏｒｅ参照の範囲（．ｈｗ．．．）は、考えられる対象をｈｗ参照によって示されるサブツリーの下に制約する。ｈｗ参照の割り当てが削除されると、ガーベージコレクションシステムは、ｃｏｒｅ参照も同様に除去する。ｃｏｒｅがバインディング参照であった場合、いずれかのコアの割り当てが実際に存在していれば、動作が拒否される。また、暗黙的オブジェクト宣言内で間接的な参照を使用して、参照によって示されるサブツリーの下に、又はこれに関連してオブジェクトを生成することもできる。以下のリスト１２に、間接的範囲を含む参照を特徴とするオブジェクトクラス定義の例を示す。
［リスト１２］
class fs.ha.node {
reference hw {
type fs.hw.computer;
scope hw;
}
reference core {
type fs.hw.core;
multivalue;
scope . hw ...;
}
...
}
【００８５】
この例示的な構成管理装置の設計では、スキーマ固有のプラグイン、又は拡大及び検証のための構成ツールを開発する必要がないので、開発努力が軽減される。むしろ、ＣＭＳは、スキーマに組み込まれた定義により制御される十分に汎用的なロジックを実装する。従来の解決策では、属性割り当ての自動生成及びオブジェクトプロトタイプに基づく下位オブジェクトが可能であった。しかしながら、プロトタイプの表現力は、定義を解釈するスキーマ固有のツールにより制限され、容易に拡張することができない。
【００８６】
例示的な実施形態は、以下を可能にするように解決策を汎化する。
−  構成データ内のどこかにオブジェクトを生成し、この時に、汎用オブジェクトクラスインスタンスロジックを利用すること、
−  任意のタイプのオブジェクトを生成すること、
−  任意の属性及び参照に値を割り当てること、
−  指定された条件が満たされるまで上述の動作を延期すること、及び、
−  ルールの反応性連鎖を構築することによる複雑な構成拡大ロジックの実装。
【００８７】
多目的プラットフォーム上にＮＥを構築する場合、以下が必要となり得る。
−  プラットフォームにより提供される拡大ロジックを拡張すること、及び、
−  プラットフォーム部分の構成オプションに制約を課すこと。
【００８８】
元々のプロトタイプベースのシステムでこれらのことを行うのは困難であるが、スキーマ定義フォーマットが、オブジェクトクラス定義を複数ファイルに分割できるようにする限り、この実施形態ではむしろ些細なことである。この結果、アプリケーション固有の下位及び暗黙的オブジェクト宣言によってプラットフォームのスキーマを拡張することが容易になる。オブジェクトの生成及び削除のためのスキーマ固有のプログラムロジックに基づいて拡大するＣＭＳでは、プログラミングエラーの結果、固有のオブジェクトの削除動作が、対応する生成動作の正確な逆動作でないこともあり得る。この結果、データベースが、最終的に矛盾した状態になることもある。この実施形態は、依存追跡に基づいて十分に汎用的な削除動作を提供することにより、この問題を回避する。この設計では、十分に拡大された構成オブジェクトのセットが高レベル構成の関数であるにほかならない。高レベルオブジェクトの生成順又は構成の過去の状態は重要でない。この実施形態は、依存追跡システムを有利に利用して以下のことを行う。
−  オペレータがいずれのスキーマ固有の実装も使用することなく一連の高レベルな手続き動作として構成を抽出できるようにすることによって構成縮小を実施すること、及び、
−  スキーマのアップグレードを容易にすること。
【００８９】
たとえ例示的な構成管理装置が、トリガ、アサーション、及び従来のＳＱＬデータベースの参照整合性制約に似たいくつかの特徴を有する場合でも、この構成管理装置は、これらを凌ぐ利点を有する。ＳＱＬのガーベージコレクション能力は、外部キーのＯＮ  ＤＥＬＥＴＥ  ＣＡＳＣＡＤＥオプションに制限される。この実施形態は、複数のオブジェクトからの依存を可能にして循環的依存を検出する本物のガーベージコレクションシステムを特徴とする。ＳＱＬでは、実際のＮＥ構成モデルにおいて多くの場合必要な、階層型オブジェクト構造又はオブジェクトクラス階層をモデル化することも困難である。ＳＱＬアサーション又はその他の制約がうまくいかない場合、通常、データベースエンジンは、オペレータにとって何の意味もない汎用エラーコードを生成する。意味のあるエラーメッセージを表示するには、追加のスキーマ固有のプログラムコードが必要である。この実施形態では、暗黙的オブジェクト及びルール定義にエラーメッセージを組み込んで、アサーション又は暗黙的オブジェクトの生成に失敗した時にメッセージが表示されるようにすることができる。ルールに関して言えば、これらのメッセージは、セレクタ及び数式の変数を参照して、これらをさらに有用なものにすることができる。
【００９０】
例示的な実施形態は、手続き的構成動作を詳細なオブジェクトモデルに拡大するために多くのアプリケーション固有のプログラムコードを必要とする従来の同等のシステムの様々な不利点に対処する新規のプログラミングパラダイムを使用したネットワーク要素構成管理システムに関する。この改善されたシステムは、複数の継承を含む汎化されたプロトタイプシステムを利用して、オブジェクトプロトタイプ定義内で特殊目的の宣言を使用して構成拡大及び整合性チェックロジックを表現できるようにし、従って部分的に重複するスキーマ固有のプログラムロジックの必要性を排除することができる。この改善されたシステムは、参照整合性チェック、ガーベージコレクション、及び一連の手続き動作の削減を自動的に行うために、汎用依存追跡システムも採用する。
【００９１】
ある実施形態では、１又はそれ以上の所定の条件に基づいて、構成データ及び構成オブジェクトが管理される。この所定の条件は、例えば暗黙的オブジェクト宣言及びルールに関する。ルールにより、（セレクタ及び条件式の形の）条件及び／又は（暗黙的オブジェクト宣言の形の）因果関係を指定する。プロトタイプ定義内の暗黙的オブジェクト宣言は、この特定タイプのインスタンスが単に存在することを条件とすることを除いて類似する。
【００９２】
ある実施形態では、パス名が、間接的な絶対パス名又は相対パス名であり、この意味が、構成データベース内の参照割り当てに依存する。
【００９３】
ある実施形態では、ルール内の数式、条件及びアサーション、（式内で使用する）プログラム言語を使用するカスタムオブジェクトセレクタ、スキーマ定義への埋め込みエラーメッセージといった特性のうちの１又はそれ以上を実装することもできる。
【００９４】
ある実施形態では、ＣＭＳが、構成データのための永続記憶装置、（文字列以外の）属性タイプ、構成オブジェクト、内部オブジェクト及び（外部インターフェイスからは見えない）属性のためのＡＣＬ、リモートアクセスのためのネットワークプロトコル、リモートデータベースへのデータの複製、高可用性、構成データを読み出して修正するためのＡＰＩ、修正イベントをリスンするためのＡＰＩ、動的属性を介してシステム状態を示すためのＡＰＩ、カスタム法によってオブジェクトクラスを拡張するためのＡＰＩといった特性のうちの１又はそれ以上を実装することもできる。
【００９５】
ある実施形態では、事前設定された定義に従い、高レベルオブジェクトに基づいて、詳細レベルオブジェクトのセットが生成される。しかしながら、詳細レベルオブジェクトは、必ずしも構成データ内の暗示する高レベルオブジェクトの下位オブジェクトであるとは限らない。他の複数のオブジェクトを組み合わせた結果、詳細レベルオブジェクトを生成することもできる（ただし、オブジェクトが他の複数のオブジェクトの下位ではないこともある）。別の詳細レベルオブジェクトにより、又は高レベルオブジェクトと詳細レベルオブジェクトのセットみ合わせにより、詳細レベルオブジェクトを暗示することもできる。オブジェクトが上位の詳細レベルオブジェクトを暗示した後に下位が生成された場合、高レベルオブジェクトが詳細レベルオブジェクトの下位になることも可能である。
【００９６】
ある実施形態では、ルールを処理する際に生成されたオブジェクトの位置が重要である。各オブジェクトは、その上位に対してＤＥＰＥＮＤＳ＿ＯＮ依存を保持し、例えばルール生成オブジェクトのガーベージコレクション処理においてこれを反映する。
【００９７】
ある実施形態では、どうしてもルールを拡張できない場合、暗黙的オブジェクトとグループマッチオブジェクトの間にＲＥＱＵＩＲＥＳ及びＵＳＥＳ依存を直接形成することができる。
【００９８】
ある実施形態では、以下の処理ロジックを適用することができる。
条件＝偽、アサーション＝偽：ルールが適用されないので何もしない。
条件＝偽、アサーション＝真：ルールが適用されないので何もしない。
条件＝真、アサーション＝偽：トランザクションを中止する。
条件＝真、アサーション＝真：ルールを処理し続ける（暗黙的オブジェクト宣言）。
【００９９】
構成オブジェクトのための４つの考えられる修正動作である生成、削除、フラッシュ及びセットについて説明する。オブジェクトの生成がルールをトリガして、より多くのオブジェクトを生成することができる。その後、これらのオブジェクトがさらなるルールをトリガして、さらに多くのオブジェクトを生成することができる。これに対応して、オブジェクトの削除は、ガーベージコレクションをトリガして、さらなるオブジェクトを削除する可能性がある。フラッシュは、削除の汎化である。セット動作は、属性及び参照のために、またインスタンスの名称又はプライマリクラスを変更するためにも使用することができる。生成及び削除動作は、再帰性を有することができる。
【０１００】
ある実施形態では、上述した方法ステップを実行するようにプロセッサにより実行可能な命令のプログラムを具体化するコンピュータ可読メモリが提供される。
【０１０１】
図１〜図７に示すステップ、シグナリングメッセージ及び関連機能は、絶対的発生順になっておらず、これらのステップのいくつかを同時に、又は所与の順序とは異なる順序で実行することもできる。ステップ間又はステップ内で他の機能を実行すること、及び図示のメッセージの合間に他のシグナリングメッセージを送信することもできる。ステップの一部を省略すること、又は対応するステップに置き換えることもできる。シグナリングメッセージは例示的なものにすぎず、同じ情報を送信するための複数の別個のメッセージを含むこともできる。また、メッセージは他の情報を含むこともできる。
【０１０２】
上述のステップを実行できる装置は、ワーキングメモリ（ＲＡＭ）、中央処理装置（ＣＰＵ）及びシステムクロックを含むことができる電子デジタルコンピュータとして実装することができる。ＣＰＵは、一連のレジスタ、算術論理演算ユニット、及び制御ユニットを含むことができる。制御ユニットは、ＲＡＭからＣＰＵに転送される一連のプログラム命令により制御される。制御ユニットは、基本動作のための多くのマイクロ命令を含むことができる。マイクロ命令の実装は、ＣＰＵの設計によって異なることがある。プログラム命令は、プログラミング言語によってコード化することができ、これらの言語は、Ｃ、Ｊａｖａ（登録商標）などの高水準プログラミング言語であっても、或いはマシン語又はアセンブラなどの低水準プログラミング言語であってもよい。電子デジタルコンピュータは、プログラム命令で記述されたコンピュータプログラムにシステムサービスを提供できるオペレーティングシステムを有することもできる。
【０１０３】
ある実施形態は、電子装置にロードされた場合に、上述したようなネットワーク要素構成管理を実行するように構成されたプログラム命令を含む、配布媒体上で具体化されるコンピュータプログラムを提供する。
【０１０４】
コンピュータプログラムは、ソースコード形式、オブジェクトコード形式、又は何らかの中間形式をとることができ、これを、プログラムを搬送できるいずれのエンティティ又は装置であってもよい何らかの種類のキャリアに記憶することができる。このようなキャリアとして、例えば、記録媒体、コンピュータメモリ、読み取り専用メモリ、電気搬送波信号、電気通信信号、及びソフトウェア配布パッケージが挙げられる。必要な処理能力に応じ、コンピュータプログラムを単一の電子デジタルコンピュータで実行することも、或いは多くのコンピュータ間に分散させることもできる。
【０１０５】
装置を、特定用途向け集積回路ＡＳＩＣなどの１又はそれ以上の集積回路として実現することもできる。別個の論理要素で構築される回路などの他のハードウェアの実施形態も実現可能である。これらの異なる実装の混成も実現可能である。実施方法を選択する場合、当業者であれば、例えば、装置８００のサイズ及び消費電力、必要な処理能力、製造コスト、及び製造量に関して設定された要件を考慮するであろう。
【０１０６】
当業者には、技術が進歩するにつれて、本発明の概念を様々な方法で実現できることが明らかであろう。本発明及びその実施形態は、上述の例に限定されるものではなく、特許請求の範囲内で異なることができる。
【０１０７】
略語一覧
ＡＣＬ：アクセス制御リスト
ＡＩＳ：アプリケーションインターフェイス仕様
ＡＭＦ：可用性管理フレームワーク
ＡＰＩ：アプリケーションプログラミングインターフェイス
ＣＭＳ：構成管理システム
ＨＡＳ：高可用性サービス
ＩＥＴＦ：インターネット技術標準化委員会
ＬＤＡＰ：ライトウェイト・ディレクトリ・アクセス・プロトコル
ＮＥ：ネットワーク要素
ＮＳＮ：Ｎｏｋｉａ  Ｓｉｅｍｅｎｓネットワーク
ＳＡＦ：サービス可用性フォーラム
ＳＱＬ：構造化問い合わせ言語
ＸＭＬ：拡張可能マークアップ言語
ＸＳＬ：拡張可能スタイルシート言語
ＸＳＬＴ：ＸＬＳ変換
ＣＬＭ：クラスタメンバーシップサービス
【符号の説明】
【０１０８】
３０１：定義
３０３：適用
【図１】
2014504469.tif 000020
【図２】
2014504469.tif 000021
【図３】
2014504469.tif 000022
【図４】
2014504469.tif 000023
【図５】
2014504469.tif 000024
【図６】
2014504469.tif 000025
【図７】
2014504469.tif 000026
【国際調査報告】
2014504469.tif 000027
2014504469.tif 000028
2014504469.tif 000029