JP2007519075A - 監視ルールのスケーラブル（ｓｃａｌａｂｌｅ）な同期処理および非同期処理 - Google Patents

Abstract

ルールをスケジュールし、同時に処理するためのルールランタイムエンジンを備える。このエンジンは、多数のルールを並列に効率的に実行する。これは、ルール定義言語でルールを記述し、翻訳器を介してこれらのルールを渡してランタイムエンジンに送り、ランタイムエンジンを使用して翻訳された命令をスケジュールし、同時に処理することによって実現される。このエンジンは、これらの命令をインスタンス化する構成データも受け取って、１組の現実のルールに具体化する。

Description

本発明は、ソフトウェア・アプリケーションのシステム管理に関し、より詳細には、ルールを非同期処理するルールエンジンに関する。

本出願は、２００３年１０月２４日出願のＳＣＡＬＡＢＬＥ ＳＹＮＣＨＲＯＮＯＵＳ ＡＮＤ ＡＳＹＮＣＨＲＯＮＯＵＳ ＰＲＯＣＥＳＳＩＮＧ ＯＦ ＭＯＮＩＴＯＲＩＮＧ ＲＵＬＥＳという名称の米国特許出願第１０／６９３，０７２号明細書の優先権を主張する。この出願全体を本明細書に組み込む。本出願は、同時係属の、２００３年１０月２３日出願のＭＯＤＥＬ−ＢＡＳＥＤ ＭＡＮＡＧＥＭＥＮＴ ＯＦ ＣＯＭＰＵＴＥＲ ＳＹＳＴＥＭＳ ＡＮＤ ＤＩＳＴＲＩＢＵＴＥＤ ＡＰＰＬＩＣＡＴＩＯＮＳという名称の米国特許出願第１０／６９２，２１６号明細書、２００３年１０月２４日出願のＲＵＬＥＳ ＤＥＦＩＮＩＴＩＯＮ ＬＡＮＧＵＡＧＥという名称の米国特許出願第１０／６９２，６６０号明細書、２００３年１０月２４日出願のＵＳＩＮＧ ＵＲＩ’Ｓ ＴＯ ＩＤＥＮＴＩＦＹ ＭＵＬＴＩＰＬＥ ＩＮＳＴＡＮＣＥＳ ＷＩＴＨ Ａ ＣＯＭＭＯＮ ＳＣＨＥＭＡという名称の米国特許出願第１０／６９３，５８８号明細書、および２００３年１０月２３日出願のＵＳＥ ＯＦ ＡＴＴＲＩＢＵＴＩＯＮ ＴＯ ＤＥＳＣＲＩＢＥ ＭＡＮＡＧＥＭＥＮＴ ＩＮＦＯＲＭＡＴＩＯＮという名称の米国特許出願第１０／６９２，４３２号明細書に関連するものである。

従来方式のシステム管理は、概ね場当たり的である。アプリケーション開発者は、自身のアプリケーションを管理し、高い信頼性を実現するための体系化されたフレームワークをもっていない。このような管理アーキテクチャをうまく進めるために採用される多くの言語は、本来シングルスレッドであり、マルチタスク処理を行うにはそのサポートを付加する。そのため、これらの言語では、スレッドなどのオペレーティングシステムによりサポートされたコンストラクト（ｃｏｎｓｔｒｕｃｔ）を介してマルチタスク処理を実現するのはユーザの責任である。

ルールに基づくメカニズムを利用することにより、ソフトウェアにおける柔軟性が得られ、その結果、１つまたは複数のルールを交換することによってタスクおよびデータを容易に変更し得る。最も基本的なプリミティブ（ｐｒｉｍｉｔｉｖｅ）は、状態を評価し、動作を開始するロジックを実装するルールである。例えば、あるルールは、システムディスクの状態を監視し、ディスクの使用率がある閾値未満になったときにエラーを報告し得る。別のルールは、プロセッサの利用率を監視し、この利用率がある閾値よりも大きくなったときにエラーを報告し得る。典型的な監視システムでは、両方のルールが同時に実行されることになる。ユーザが、Ｖｉｓｕａｌ Ｂａｓｉｃ ．Ｎｅｔなどの典型的なプログラミング言語を使用したい場合、このユーザは、ルールの意図を表すロジックに加えて、複数のルールが同時に実行されるようにこれらのルールをスケジュールするコードを記述しなければならないことになる。

多数のルールの同時処理をうまく進める改善されたルールに基づくエンジンが求められている。

本発明のいくつかの態様を基本的に理解するために、本発明の概要を簡略化して以下に示す。この概要は、本発明を広範に概説したものではない。本発明の主要不可欠な要素を明らかにし、また、本発明の範囲を限定するためのものではない。この概要の唯一の目的は、本発明のいくつかの概念を簡略化した形態で、後で示すより詳細な説明の前置きとして示すことである。

本明細書で開示し特許請求する発明は、その一態様において、ルールを命令に翻訳する翻訳コンポーネントを含む。こうすると、ルールランタイムエンジンでのこれらの命令の同時処理が容易になる。この翻訳コンポーネントは、ランタイムエンジンによってすべての状態が維持されるように、命令のインスタンス化をうまく進める。これらの命令は、ユーティリティ関数をコールし、ランタイムエンジンのコード実行切替えに優先権を渡すことをうまく進めるｙｉｅｌｄ文を含む。

本発明の別の態様では、モデルに基づく革新的な管理フレームワークのルールエンジンが提供される。このルールエンジンにより、開発者は、システムを健全な状態にするために満たさなければならない基準を表す多数のルールを容易に記述し得る。このフレームワークは、多数のルールのスケジュールおよび同時処理をうまく進めるランタイムアーキテクチャを提供する。

監視ルールエンジンは、ルールが自動的にスケジュールされるように処理し、それによって、ユーザからこの負担が取り除かれ、ユーザは監視ロジックを表現することだけに集中することができる。例えば、「ディスクの使用率が８０％を超えた場合、システム管理者に警告する」という意図を表すルールを記述することができる。監視ルールは、非コンピュータ世界におけるルールの集まりと同様に、（明示的に記述されない限り）すべてのルールが概念上同時に実施されるように暗黙的に同時に処理される。このようなルールエンジンは、ルールのスケジューリングを表現する負担がユーザから取り除かれるように、多数のルールの暗黙的な同時処理をうまく進めるランタイムアーキテクチャを提供する。その結果、ユーザに求められることは、スケジューリングを意識せずにこれらのルールを記述することだけであり、システムがスケジューリングおよび同時処理を引き受けることになる。

このルールエンジンは、ＲＤＬ（Ｒｕｌｅｓ Ｄｅｆｉｎｉｔｉｏｎ Ｌａｎｇｕａｇｅ）（ルール定義言語）として知られているルール言語をサポートする。このルール監視システムは、本質的に並列であること、すなわち同時に複数の事柄を監視すること、相関、使い易さ、スケーラビリティ、メモリ占有スペースが小さく、ルールの数に比例して増えること、ＣＰＵの利用率が低いこと、および拡張性という高水準の要件を実現し、それによって、既存のルールおよびランタイムソフトウェアの活用および拡張が容易になる。

上記の要件、特に使い易さおよび本質的な並列性は、ルールエンジンの設計に有利に働く。他の大部分の言語は本来シングルスレッドであり、マルチタスク処理を行うにはそのサポートを付加する。しかし、ＲＤＬ言語は、これと正反対のものである。というのは、ＲＤＬ言語は、ルールの論理的な並列実行が本質的に可能になるように設計されており、そのため、ルールの開発者は、同時ルール評価を実現するために多くの労力をかける必要がないからである。この本質的な並列性のために、このアーキテクチャでは、いくつかのスレッド間でルールのスケジューリングがサポートされる。

上記および関連する目的を達成するために、本明細書では、以下の説明および添付の図面に関連して本発明のある種の態様の例を説明する。ただし、これらの態様は、本発明の原理を利用し得る様々な方法を示すほんの数例であり、本発明は、このような態様およびそれらの均等物をすべて包含することを意図している。本発明の他の利点および新規な特徴は、本発明の以下の詳細な説明をこれらの図面と併せ読めば明らかになるであろう。

次に、図面を参照して本発明を説明する。これらの図面を通じて、同じ参照数字を用いて同じ要素を指す。以下の記載では、説明のために、本発明が十分に理解されるように多くの特定の細部を述べる。ただし、これらの特定の細部を用いずに本発明を実施し得ることが当業者には明らかであろう。他の例では、本発明の説明をうまく進めるために、周知の構造および装置はブロック図の形式で示す。

本出願では、「コンポーネント」および「システム」という用語は、コンピュータに関係するエンティティを指すためのものである。これらは、ハードウェア、ハードウェアとソフトウェアの組合せ、ソフトウェア、または実行中のソフトウェアのいずれかである。例えば、コンポーネントは、プロセッサ上で実行中のプロセス、プロセッサ、オブジェクト、実行ファイル、実行の流れ、プログラム、および／またはコンピュータとし得るが、これらに限定されるものではない。例として、サーバ上で実行されているアプリケーション、およびこのサーバはともにコンポーネントとし得る。１つまたは複数のコンポーネントが、実行の過程および／または流れの中に存在することもあるし、あるコンポーネントが、１つのコンピュータ上に局在し、かつ／または２つ以上のコンピュータに分散されることもある。

次に図１を参照すると、本発明のコンポーネントのブロック図が示されている。ルールの同時実行をうまく進めるルール監視システム１００が提供される。監視システム１００は、システム１００に入力される１つまたは複数のルール１０４を表現する（ＲＤＬ（ルール定義言語）と呼ぶ）入力命令コンポーネント１０２、命令１０２を読み込み、それらを並列実行形式に変換する翻訳コンポーネント１０６、およびこれら翻訳された命令を読み込み、これら翻訳された命令の効率的なスケジューリングおよび並列処理をうまく進めるルールランタイムエンジン１０８の３つの論理的エンティティを含む。

ＲＤＬ命令１０２により、ソフトウェアおよびハードウェアのコンポーネントの可用性を監視するためのルールを定義することができる。例えば、あるルールは、システムディスクの状態を監視し、ディスクの使用率がある閾値未満になったときにエラーを報告し得る。別のルールは、ＣＰＵの利用率を監視し、この利用率がある閾値を超えたときにエラーを報告し得る。典型的な監視システムでは、両方のルールが同時に実行されることになる。

ランタイムエンジン１０８は、その入力として、ＲＤＬで表されたルールコードならびにこのルールコードをインスタンス化するのに使用する構成データ１１０を取り込む。このルールコードは、一連のルールタイプに編成される。各タイプは、監視中のシステムについて、ハードウェアおよび／またはソフトウェアのターゲットが所望の状態にあるかどうかを判定するのに必要とされるロジックを表現するものである。このタイプにより、ターゲットが所望の状態にないと判定される場合、このタイプは典型的には、なんらかの動作を行う。例えば、下記のコードは、システムが望ましくない状態に陥ったときに、エラーイベントが大量に送信されないように抑制するルールタイプを使用する。このルールロジックは、ＲｕｌｅＴｙｐｅ．．．ＥｎｄＲｕｌｅＴｙｐｅキーワードによって囲まれ、他と区別されることに留意されたい。このコードは、翻訳コンポーネント１０６によって翻訳され、ルールエンジン１０８にロードされ、それによってこのコードは、インスタンス化され得る状態になる。ルールコードは、構成データ１１０をランタイムエンジン１０８にロードすることによってインスタンス化される。この構成データは、どのルールを実行するか、ならびにこのルールを実行するのに必要とされるパラメータを指定する。

一般に、ユーザが典型的なプログラミング言語を使用したい場合、ルールの意図を表現するロジックに加えて、同時に実行するルールをスケジュールするコードを記述する必要がある。本発明の新規なルールエンジン１０８は、ルールのスケジューリングを処理し、それによって、ユーザからこの負担を取り除き、ユーザは監視ロジックを表現することに集中することができる。

スケジューリングをうまく進めるために、ＲＤＬでルールを記述し、次いで、これらのルールを、Ｃ＃などの任意の適切な言語に翻訳することができる。これら翻訳されるコードは、「優先権を渡す」というセマンティック（ｓｅｍａｎｔｉｃｓ）をコードに導入することによって、多数のルール間でスケジューリングがサポートされるように設計される。この場合、「優先権を渡す」ことは、ルールコードからエンジンコード、そして他のルールコードへのコンテキストスイッチになる。こうすると、ルールエンジン１０８が、スレッドの数が制限された状態でルールをマルチタスク処理することができる。

下記のルールでは、構成データは、実行すべきルールとしてＤｎｓＲｕｌｅを指定し、ＴｉｍｅＬｉｍｉｔ、ＣｏｕｎｔＬｉｍｉｔ、およびＲｅｓｔａｒｔＩｎｔｅｒｖａｌのパラメータ値を供給する。

インスタンス化されたルールを並列に実行するために、翻訳コンポーネント１０６は、ルールコードを、ランタイムエンジン１０８との対話をうまく進める中間形式に翻訳する。この中間形式は、このルールについてのあらゆる状態（引数および局所変数）が、エンジン１０８によって維持されるように設計される。このルールは、コード実行切替えについてランタイムエンジン１０８に優先権を渡し、エンジン１０８によって提供されるユーティリティ関数をコールする。これら翻訳されたコードは、このコードにｙｉｅｌｄ命令を周期的に挿入する。上記の例では、この翻訳により少なくとも、各ループの終了時、かつＧｅｔＥｖｅｎｔコールの後で優先権が渡されることになる。

上記のコードサンプルでは、状態情報が、引数および局所変数の両方の形式で維持される。ＴｉｍｅＬｉｍｉｔおよびＣｏｕｎｔがそれぞれ、その例である。エンジン１０８がこのコードの実行を休止するとき、これらの変数の状態は、次にこのコードがエンジン１０８によって実行されるときにこの状態が利用可能になるように維持される。

Ｗｉｔｈｉｎブロックでは、エンジン１０８のユーティリティ関数が使用される例が提供される。上記のコードには、Ｗｉｔｈｉｎ．．．ＥｎｄＷｉｔｈｉｎ文ブロックが存在し、この中に含まれるコードに対して、エンジン１０８に時間制限を実施させる。この中に含まれるコードを実行するのに指定された時間よりも長くかかる場合、エンジン１０８は、自動的にこのブロックのＥｌｓｅ部分を実行させ、同時に、Ｗｉｔｈｉｎ．．．Ｅｌｓｅ文間のコードの実行を終了させる。このブロックの翻訳されたバージョンは、エンジン１０８に、Ｗｉｔｈｉｎブロックに入ったという命令を送る。次いで、エンジン１０８は、このルールコードの実行を監視し、前に説明したセマンティックがはっきり示されるように適切な動作を行う。

ルールを監視する際に、特定のイベントが生じるまで待ち、次いで、動作を行うことは極めて一般的である。エンジン１０８は、多数のイベントを効率的に待つことをサポートし、この待ちをコード内に容易に表現させる。ＧｅｔＥｖｅｎｔ命令コールは、何かが起こるまで待ち（Ｗｉｔｈｉｎ文により表される時間制限によって範囲が制限される）、次いで、この情報に対して動作を行うことが望まれることを表現するのに好都合である。ＧｅｔＥｖｅｎｔ命令は、エンジン１０８が、このコードを休止状態に置き、イベントをその代理で待つように翻訳される。このイベントが発生すると、このコードが再開され、このイベントに対して動作を行うことができる。

要約すると、エンジン１０８は、多数のルールを並列に効率的に実行する。これは、ルールをＲＤＬで記述し、これらのルールを翻訳器１０６を介してランタイムエンジン１０８に送ることによって実施される。エンジン１０８は、これらの命令をインスタンス化する構成データを受け取って、１組の現実のルールに具体化する。

ルールエンジンおよびそのすべてのコンポーネントは、コンピュータ可読媒体の形で実施し得ることを理解されたい。

次に図２を参照すると、ルール監視プロセスの流れ図が示されている。説明を簡単にするために、本明細書で、例えば流れ図の形式で示す１つまたは複数の方法を一連の動作として示し説明するが、本発明は、動作の順序によって限定されず、いくつかの動作は、本発明に従って、本発明で示し説明するものと異なる順序で、かつ／または他の動作と同時に実施し得ることを理解かつ認識されたい。例えば、一連の相互に関連する状態またはイベントとして、状態図などの形で方法を代わりに表現し得るはずであることが当業者には理解かつ認識されよう。さらに、本発明による方法を実施するのに、例示した動作が必ずしもすべて必要とされないことがある。

２００で、システムがルールを受け取り、それをＲＤＬで記述する。２０２で、これらのルールを、ルールエンジンとの対話がうまく進む中間形式に翻訳する。２０４で、これら翻訳されたルールをランタイムエンジンにロードする。２０６で、このエンジンは構成データを受け取って、このコード化され翻訳されたルールをインスタンス化する。２０８で、ランタイムエンジンは、この翻訳されたルールをスケジュールし処理して並列処理を行う。次いで、このプロセスはＳｔｏｐブロックに達する。

次に図３を参照すると、本発明によるルールのインスタンス化の流れ図が示されている。３００で、エンジンと対話するための中間形式にルールを翻訳する。３０２で、エンジンは、このルールについてのあらゆる状態を維持する。３０４で、この翻訳された形式は、このコードにｙｉｅｌｄ命令を挿入する。３０６で、この翻訳された形式は、ルールコードの実行について、ランタイムエンジンに優先権を渡す。３０８で、この翻訳された形式は、エンジンによって提供されるユーティリティ関数をコールする。次いで、このプロセスはＳｔｏｐブロックに達する。

翻訳アルゴリズム
翻訳中、深さ優先トラバースラベル（ｄｅｐｔｈ−ｆｉｒｓｔ ｔｒａｖｅｒｓａｌ ｌａｂｅｌｓ）および一時変数が、適切なノードごとに、順序が左から右かつ下から上になるように生成される。ラベル化されたノード（すべてのノードがラベルを取得することにはならない）はそれぞれ、一時変数の割当て、後続のラベルへの命令ブロックの割当て、およびリターン文を生成する。この翻訳アルゴリズムの利益は、コード化するのが容易であるということである。このアルゴリズムは、いくつかの命令ブロックを生成し、エンジンに戻る。以下に、簡単なａｓｓｉｇｎｍｅｎｔ文の翻訳を示す（読みやすくするために、省略表記を用いる）。

ｒＬｎ−命令ブロックをＬｎに設定し、戻る。
ＲＤＬ：

このａｓｓｉｇｎｍｅｎｔ文の翻訳を以下に示す。

ＲＤＬで記述したルールは、モジュールにグループ分けし得る。モジュールは、以下に示すように、例えば、Ｖｉｓｕａｌ Ｂａｓｉｃ ＳｔａｎｄａｒｄＭｏｄｕｌｅＡｔｔｒｉｂｕｔｅなどのコンパイラによって、クラスに翻訳し得る。

この翻訳されたコードを、一連の命令ブロックに分割する。これらの命令ブロックは、ｓｗｉｔｃｈ−ｃａｓｅブロックに分けられ、ルールフレームは、現在のブロックを維持するフィールドを有する。この命令ブロックは、ＭＳＩＬ（マイクロソフト中間言語）アドレスの均等物であるが、この翻訳ブロックの粒度レベルは、ＭＳＩＬの場合と同じではない。ＭＳＩＬは、いくつかのコンパイラ（例えば、Ｃ＃、ＶＢ、および．ＮＥＴ）の出力として使用する言語である。各命令ブロックは、このブロック内のすべてのコードがユニットとして実行され、それによって、ブロック間でエンジンに優先権が渡されるという意味での作業アイテムを表す。

以下のコードは、命令ブロックがどのように使用されるかの簡単な例を示す。以下に示すルールは、３つの別個のブロックに分割される。各ブロックは、リターン文で終了する。このルールがエンジンに戻る前に、ルールフレームは、このルールへの再エントリ後に、次に実行すべき命令ブロックによって更新される。第２ブロックに示すように、ｓｗｉｔｃｈ文中でｂｒｅａｋが発生した場合には、このルールを終了する。

終了する前に、ルールがＩＥｘｅｃｕｔｉｏｎＳｔａｃｋ．ＳｅｔＣａｌｌｅｒＦｒａｍｅ（）を呼び出し、それによってエンジンは、次にｃａｌｌｅｒルールに入ることになる。

すべてのルールは、それらが例えば下記のシグネチャを有するように翻訳される。

戻り値およびパラメータはすべて、スタック上に置かれる。ここで示すように、すべてのルールは、スタティック関数（ｓｔａｔｉｃ）として実装される。これらのスタティック関数は、モジュールのメンバであり、このモジュール内でこれらのメンバが定義される。本明細書の他のところで論じたように、モジュールはクラスに翻訳される。

ルール名は、ＲＤＬファイル内で表された名前と厳密に一致する。以下に、完全修飾されたルール名の例を示す。

起動ルールは、起動属性＜Ｓｔａｒｔｕｐ＞によってマーキングされる。すべての起動ルールは、ロードが成功した後でルールエンジンによって呼び出される。

翻訳された起動ルールは次のようになる。

ＶａｌｕｅＴｙｐｅが、参照により（ＢｙＲｅｆ）、Ｓｔａｒｔを介して関数に渡される場合、その関数は、下記のメカニズムによってコピーを受け取るだけである。すなわち、ｃａｌｌｅｒの元コピーは変化しない。

次に図４を参照すると、ルール間の呼出しについてのプロセスの流れ図が示されている。ＲＤＬは、１つのルールを収容し、このルールが他のルールを呼び出す。ルール間の呼出しは、翻訳されたコードの形で以下のステップを必要とする。４００で、ｃａｌｌｅｒについての戻りアドレスを設定する（ｃａｓｅブロック値）。４０２で、ｃａｌｌｅｅに関連するルールフレーム（「ＲｕｌｅＦｒａｍｅ」）が生成される。４０４で、このルールフレームについてのコンストラクタ（ｃｏｎｓｔｒｕｃｔｏｒ）が、翻訳された関数へのデリゲート（ｄｅｌｅｇａｔｅ）を取得し、エンジンがこれを用いて実際のコールを行う。４０６で、フレーム内でｃａｌｌｅｅ関数についてのパラメータを設定する。４０８で、ｃａｌｌｅｅフレームをスタック上にプッシュし、フローはエンジンに戻る。ステップ４００〜４０８は前段階を表す。４１０で、ｃａｌｌｅｒのスタックを設定する。４１２で、スタックからｃａｌｌｅｅフレームがポップする。４１４で、任意のＢｙＲｅｆパラメータについての局所変数を設定する。次いで、４１６に示すように、フローはエンジンに戻る。ステップ４１２および４１４は後段階を表す。

ＲＤＬの式は、式がルールの呼出しを含むときと、式が非同期関数の呼出しを含むときを除き、翻訳されたコードとほぼ１対１にマッピングされる。式がこれらのタイプの項を含むとき、この式は、３アドレスコードに要因として組み込まれる。コンパイラは、上から下かつ左から右にツリーを移動し、各ノードにおいて、プリミティブ翻訳をエミット（ｅｍｉｔ）する。ＡＳＴ（抽象構文ツリー）をトラバースすると、ラベルおよび一時変数の指定が得られる。

ＲＤＬは、変数、すなわち引数および局所変数について２つのスコープ（ｓｃｏｐｅ）を含む。式の評価が完全に縮小される場合、割当ては、引数または局所変数のいずれかに対して行うことができ、翻訳されることになる。

翻訳された関数はどれも、関連するカスタムのＲｕｌｅＦｒａｍｅの派生クラスを有する。この派生クラスは、ＲＤＬ関数に渡されるパラメータに直接相関するメンバを含む。これが翻訳されて関数になる。

関数が呼び出されると、派生ＲｕｌｅＦｒａｍｅ内のメンバが、前に説明したように前段階において適切に設定され、ＲｕｌｅＦｒａｍｅがスタック上にプッシュされる。リターン後、前に説明したように後段階において、ＢｙＲｅｆメンバが読み込まれ、ｃａｌｌｅｒフレームに適切に転送される。

ＲＤＬではポーリングがサポートされる。ポーリングをサポートするために、ＲｕｌｅＦｒａｍｅクラスは、ポーリング構造のスタックを維持する。このスタックにより、単一の関数内でポーリングのネストが可能になる。エンジンは、現在のフレームについてのポーリング構造およびスタックの最上部のポーリング構造にのみ従ってスケジュールする。ポーリングについての構成を行うために、スタックの最上部のところでポーリング構造を設定する。ポーリング命令は、それがポーリング構造を生成し、このポーリング構造をスタック上にプッシュするときに、１つのポーリングブロック当たり１回コールされるだけである。ブロックのエントリ後、時間枠が設定される。次いで、Ｒｅｔｕｒｎ命令がセットされ、フローはエンジンに戻る。

その後、エンジンは、ポーリングが確立されたかどうかを調べ、実行スタックをスケジュールして実行を行う。ポーリング間隔が設定されるたびに、ポーリングが確立したことを示すフラグがフレーム内でセットされる。ポーリング間隔が変化しなかった場合、このポーリングフラグを手動でセットすることができる。エンジンは、スケジューリング後に、このフラグをリセットする。したがって、エミットされたコードが、ポーリングフラグをリセットすることはない。次いで、終了（ｅｘｉｔ）後、このポーリング構造はポーリングスタックからポップする。

ＲＤＬは、参照タイプおよび値タイプという２つのデータタイプを用いる。ＲＤＬの参照データタイプは、１対１でプログラミング言語の相手（例えばＣ＃）に翻訳され、この相手のスコープに応じて、ローカルフレームまたはルールフレーム内に常駐する。このスコープについては、変数に関連して以下で論じる。値タイプは、ボックス化に関する計算可能なイシュー（ｉｓｓｕｅ）を提示する。というのは、値タイプは、参照によって渡すことができないからである。値タイプは、参照タイプ内でボックス化されることになる。

ＲＤＬでは、変数は、２つの別個のローカリティ（ｌｏｃａｌｉｔｙ）を有する。変数は、関数についてのパラメータリスト内でスコープが設定されるか、あるいはその関数自体の中でスコープが設定される。変数が、パラメータリストの一部である場合、これらの変数は、派生ＲｕｌｅＦｒａｍｅ命令内で生成される。変数が関数内で宣言される場合、これらの変数は、この関数のローカルフレーム内に常駐する。ローカルフレームは、コンテナ関数（ｃｏｎｔａｉｎｅｒ ｆｕｎｃｔｉｏｎ）に極めて固有なものである。ベースＲｕｌｅＦｒａｍｅクラスは、ローカルフレームへの参照を維持する。

アナリスト（ａｎａｌｙｓｔ）呼出しは、従来方式の任意のオブジェクト呼出しと同じものである。これらの呼出しには、同期および非同期という２つの特色がある。同期呼出しは、関数についてのパラメータおよび戻り値がローカルフレーム上の変数（またはリテラル（ｌｉｔｅｒａｌ））である直裁的なコールである。同期呼出しは、以下のようなものである。

場合によっては、メソッドの呼出しは非同期である。これらのコールは、標準の非同期設計パターンに従う。戻りアドレスが設定され、フレームは、延期されたとマーキングされる。次いで、このオブジェクトに対して非同期ＢＥＧＩＮ操作を呼び出す。

最後の２つのパラメータは、非同期コールバックを提供する。これらは、ルールエンジン用のディスパッチャ（ｄｉｓｐａｔｃｈｅｒ）メソッドおよびルール用の実行スタックである。これら最後の２つのパラメータは、同じものであり、すべての非同期コールに必要とされる。第１の組のパラメータは、非同期コンポーネントの性質に応じて変化する。非同期コールが完了すると、エンジンディスパッチハンドラ（ｅｎｇｉｎｅ ｄｉｓｐａｔｈ ｈａｎｄｌｅｒ）にスレッドがディスパッチされ、最終的にこのハンドラは、ルールにコールバックを渡す。

ループ
前に説明したように、ルールは、一連の命令ブロックに分割される。その結果、ループ処理は、条件付き確認、命令ブロック設定、およびエンジンに戻ることに分解される。これは、分岐命令により、１つの重要な差異を有する異なるアドレスに実行が移されるＭＳＩＬに類似している。飛越し処理が行われる前に、ルールは常に、ノンプリエンプティブ（ｎｏｎ−ｐｒｅｅｍｐｔｉｖｅ）スケジューリングを行うことができるようにエンジンに戻る。エンジンに戻ることは、タスクが消されることになることを必ずしも意味しないことに留意されたい。というのは、エンジンは、条件が許す場合には、直ちにこのタスクに戻ることができるからである。

ループ処理のコンストラクトは、ＭＳＩＬの場合と類似のやり方で策定され、それによって、すべてのループ処理コンストラクションが、それらがすべて同じ翻訳を共有するようにコンストラクションブロックの終了時の状態を調べる。すなわち、ＷＨＩＬＥループに対して、このループの前の命令により、初期エントリ後に状態が調べられるようにブロックの終わりに至る初期分岐が生じる。

ＲＤＬ言語は、多くのルール間でマルチタスク処理を本質的にサポートするように設計されている。その結果、翻訳されるコードは、ルールエンジンが、スレッドの数が制限された状態で、多数のルールの中で切り替わり、それによって、得られたアーキテクチャが本質的に、ノンプリエンプティブスケジューリングシステムに帰着され得るように構築される。

スケジューリング
スケジューリングの解決策の基礎を説明する前に、問題を明確に説明したほうがよい。多数のルールを含むルールドキュメントを考える。このドキュメント内には、ＣｈｅｃｋＣＤｉｓｋＳｐａｃｅ、ＣｈｅｃｋＣｏｕｎｔｅｒ、およびＣｒｅａｔｅＥｖｅｎｔと呼ぶ３つのルールがある。また、簡単にするために、ルールエンジンは、１組のタスク間でマルチタスク処理を行うのにスレッドを１つしか使用しないように構成されると考える（ＣｈｅｃｋＣＤｉｓｋＳｐａｃｅは、それを起動ルールとしてマーキングする属性を含み、かつ、同様にマーキングされた他のルールと並列に実行すべきであることに留意されたい）。概念上、このルールエンジンは、コンパイルされたアセンブリを処理し、例えば以下に示すＣｈｅｃｋＣＤｉｓｋＳｐａｃｅなど、並列に実行しなければならないすべてのルールの一覧を構築する。

次いで、各ルールを、タスク実行キュー内に配置して、ルールエンジンのスレッドがこれらを消費する。以下に示すルールの場合、ＣｈｅｃｋＣＤｉｓｋＳｐａｃｅを初期実行キュー内に配置する。ある時点で、スレッドは、このルールをデキュー（ｄｅｑｕｅｕｅ）し、ＣｈｅｃｋＣＤｉｓｋＳｐａｃｅの実行を開始する。いくらか後の時点で、このスレッドは、ＣｈｅｃｋＣｏｕｎｔｅｒに出くわす。このスレッドは、この内部関数の呼出しを、この関数をそれが現れるとおりに同期して呼び出すことによって行う。これは、翻訳されたプログラム言語コード（例えばＣ＃）が、ほぼ下記のＲＤＬサンプルで示すとおりに現れることを示唆している。

しかし、この解決策では、ルールエンジンについての問題が生じる。ルールが、「Ｗｈｉｌｅ−Ｓｌｅｅｐ（ｔｉｍｅ）−Ｅｎｄ Ｗｈｉｌｅ」の形式の連続ループを含み、スレッドがこのループに入ると考える。このタイプのコンストラクトに出くわすと、このスレッドは、戻ることができず、したがって、他のタスクに対してスケジューリングされ得ない状況に陥る。これほど深刻ではないが、ｃａｌｌｅｅが計算を行うのに尋常でない長さの時間を費やすときに逸脱が生じる。原因が何であれ、最終結果は、タスクの枯渇である。翻訳されたコードは、タスク間でスレッドをスケジュールして公平な処理を行うことができるようにタスクの切替えをうまく進めなければならない。したがって、翻訳されたコードは、関数の実行状態（引数、局所変数、および現在の命令）が保存され、後で再構成され得るように、協調し易いマルチタスク処理をうまく進める。

タスク切替え
協調的なマルチタスク処理システムでは、スケジュールされたタスクがスレッドの制御を放棄して他のタスクの実行を可能にすることが求められる。ＲＤＬコードの翻訳が制御されるので、各タスクが制御を放棄することになる場所についての決定がなされる。タスクは、単に通常のやり方で現在実行中の関数から戻ることによって制御を放棄する。しかし、戻る前に、各タスクは、パラメータ、局所変数、および再エントリ後に関数中のどこに飛び越すかについての情報を含むスタックフレームを更新することになる（スタックフレームに関する詳細は、後で示す）。タスク切替えは、関数が戻ることを必要とするので、システムスタックは解除されて失われる。そのため、ｃａｌｌｅｅ関数のエントリの前に、ルール間の関数コールがランタイムに戻ることを必要とするように、このシステムスタックを深さ１に制限し得る。関数がランタイムに戻るとき、２つの実行経路の１つを行うことができる。ランタイムが直ちにｃａｌｌｅｅ関数に入り、同じスレッド上で実行を開始するか、あるいは、タスクスタックフレームを作業アイテムキュー上にプッシュしてタスク切替えを行わせる。

スタックフレーム
ルール間のタスク切替えをうまく進めるために、ＲＤＬコードを翻訳して、得られたコードにコールフレームを構築するための命令を含める。これらのフレームは、関数パラメータ、現在の命令ブロック、現在の関数、および局所変数を含む。関数がコールされるたびに、これらのフレームが構築されリンクされ、それによってコールスタックが構成される。このようなコールスタックを維持すると、計算状態から命令が分離され、それによって関数がステートレス（ｓｔａｔｅｌｅｓｓ）になり、タスク切替えが容易になる。

ＲｕｌｅＦｒａｍｅ構造は、関数固有のフレーム構造を生成する基礎構造として働く。ＲｕｌｅＦｒａｍｅ構造は、ｃａｌｌｅｒ関数がｃａｌｌｅｅ関数を呼び出すたびに生成されポピュレート（ｐｏｐｕｌａｔｅ）される。ＲｕｌｅＦｒａｍｅ構造は以下の特徴を有する。すなわち、ｍ＿ＲｕｌｅＤｅｌｅｇａｔｅはこのフレームについての関数へのデリゲートであり、ｍ＿ＩｎｓｔｒｕｃｔｉｏｎＢｌｏｃｋは現在実行中の（または次に実行する）命令ブロックであり、ｍ＿Ｍｏｄｅはこの関数を（同期的または非同期的に）呼び出すべき方法であり、ｍ＿ＲｅｔＶａｌはこの関数の戻り値であり、ｍ＿ＬｏｃａｌＦｒａｍｅはこの関数に対する局所変数を含み、ｍ＿ＰａｒｅｎｔＦｒａｍｅはこのフレームのｃａｌｌｅｒ関数である。

関数はどれも、ＲｕｌｅＦｒａｍｅ構造から派生するカスタマイズされたフレームを有する。上記で示したＣｈｅｃｋＣｏｕｎｔｅｒ関数について、フレームがどのようなものになるかを以下に示す。

各ｃａｌｌｅｒは、各ｃａｌｌｅｅの派生コールフレーム構造がわかっている。ローカルフレーム構造も、それを適用する関数に固有のものである。ＣｈｅｃｋＣＤｉｓｋＳｐａｃｅ関数についてのローカルフレームを以下に示す。

上記で示したように、ＲＤＬは、ポーリングによって周期的にルールを呼び出す機能をサポートする。ポーリングされたルールは、広範に使用されることが予想され、その結果、何千ものこのようなルールが存在し得る可能性がある。下記のＲＤＬコードのフラグメントに、典型的なポーリングされたルールを示す。

上記のルールは、ルールエンジンからのスレッドによってコールされ、このルール内で計算が実施され、次いで、次の呼出しまで、３０分間の論理休止状態になる。このルールエンジンは、中央処理装置の利用率を最小限に抑えながら、潜在的には何千というこのようなタイプのルールをサポートするように求められる。そのため、このエンジンは、ポーリングされたルールの呼出しをスケジュールし分散させるアルゴリズムを実施する。ポーリングされた脱同期ルール（ｄｅ−ｓｙｎｃｈｒｏｎｉｚｉｎｇ ｐｏｌｌｅｄ ｒｕｌｅｓ）の問題は、多数のルールが活動状態になることが予想される起動時に最も深刻である。ポーリングが時間内に分散されない場合、プロセッサの利用率は、一群のタスクが実行予定時間になるたびに周期的に急上昇することになる。ポーリング間隔が短いほど、この問題は深刻になる。

現在、エンジンは、秒の粒度でポーリング間隔をサポートすることが期待されている。プロセッサの利用率を低く保つために、タスクを人為的に分散して目標利用率が約５％になるようにタスクの時間間隔を決める。この間隔のサイズは、プロセッサによる集中的なタスク計算にかかる時間が、この間隔の５％よりも絶対に長くならないように設定する。例えば、１ＧＨｚプロセッサを伴うシングルプロセッサマシンにおいて、タスクが、平均で３ミリ秒のプロセッサの時間を必要とすると仮定する。タスクの分散間隔は、利用率を５％に保つためには約６０ミリ秒でなければならないことになる。すなわち、１秒のポーリングの間にルールエンジンがサポートし得るルールの総数は１６個であり、それ以降は、利用率が５％よりも大きく上昇し始める。

上記の例に戻ると、ポーリングされたルールは、（上記で示したように起動時だけではなく）いつでも開始し得ることが明らかである。その結果、コードをなんら解析するまでもなく、このエンジンは、ポーリング要求がいつなされることになるのか全くわからないことになる。例えば、１０００個の３０秒ポーリングルールは、これらのルールの記述方法に応じて、すべて同じ時点でポーリング要求を出すこともできるし、２０分間にわたって要求を分散させることもできるはずである。２０分間にわたってポーリング要求が均一に到着する場合でも、多数のルールが周期的に同時に呼び出され、それによって３０秒ごとに利用率がぎこちなく急上昇する状態にエンジンが陥らないという保証はない。

この可能性を最小限に抑えるために、このエンジンは、以下の発見的方法を利用して、同期したルールの呼出しを最小限に抑える。このエンジンは、何らかの任意の絶対時間から一定の増分間隔ですべてのタスクをスケジュールする。ルールが明示的にスケジュール関数をコールすると、スケジュールの分散が行われる。

ｆｉｒｓｔＩｎｖｏｃａｔｉｏｎが真である場合、分散アルゴリズムを適用する。そうでない場合には、このルールは、指定した間隔で直ちにスケジュールされる。第１の呼出しは、次のようにスケジュールされる。

ただし、ｍ＿ＭｉｎＳｐｒｅａｄは、タスク間の最小スケジューリング間隔であり、実行時には一定（数１０ミリ秒程度）である。ｍ＿ＲｅｆｅｒｅｎｃｅＴｉｍｅは、すべてのポーリングの基礎となる固定された時間である（ルールエンジンは、起動時にこの値を設定する）。ｍ＿ＤｅｆａｕｌｔＩｎｔｅｒｖａｌは時間間隔であり、この上でポーリングされた呼出しを分散させる（これは数分程度であり、初期呼出し中に過度の遅延を生じることなく、数千のポーリングを分散させるのに十分に長くすべきである）。

この計算では、所与のポーリング期間についての１組の離散したタイムスロットにわたって、ポーリング呼出しを均一に分散させる。ポーリング間隔が極めて長い場合、呼出しを分散させる間隔は、比較的短いが、起動間隔における過度の遅延を防ぐのに十分に長い。短いポーリング間隔がそれらのそれぞれの期間にわたって均一に分散しない場合、同じポーリング間隔のルールが位相の合った状態で行われるので、これらのルール間でクラスタ化の影響が生じ得る。

初期ルールの起動
起動時に、ルールエンジンはリフレクション（ｒｅｆｌｅｃｔｉｏｎ）を利用し、Ｓｔａｒｔｕｐ属性でマーキングされたルールに基づいて、実行するタスクの一覧を形成する。このタスクの一覧が形成されると、エンジンは、そのスケジューリング機能を使用して、すべてのルールの開始を分散させる。ルールは、一連のバッチの形で起動され、そのため、各バッチは、時間により構成された時間間隔（すなわち、上記で定義したｍ＿ＤｅｆａｕｌｔＩｎｔｅｒｖａｌ）内でスケジュールされる。この既定の間隔は構成可能であり、コンピュータ内で使用するプロセッサの数に依存し得る。プロセッサの数が多いほど、この間隔は短くなる。

非同期関数の呼出し
多くのアナリストが、ルールエンジンによって完全に駆動される。これらのアナリストは、ルールによって生成され、このルールによってデータが供給され、次いで、計算結果についてのクエリを受ける。典型的に行われるサイクルを以下に示す。立ち上がりなどのアナリストが生成され、初期化される。ポーリングごとに、オペレーティングシステムは、パフォーマンスカウンタについてのクエリを受け、このデータをアナリストに渡す。次いで、アナリストは、それが、計算を完了するのに十分なデータをもっているかどうかの問合せを受ける。もっている場合には、結果が得られ処理される。もっていない場合には、次のポーリングを待ち、このサイクルが新たに開始される。下記のＲＤＬのフラグメントにこのサイクルを示す。

このサイクルは、アナリストの部分に完全に同期しており、エンジンまたはアナリストに対するキューを全く必要としない。

別の代替形態は、アナリストを非同期にし、このアナリストにデータが利用可能な時点をエンジンに通知させることである。次いで、このエンジンは、通知を受けた後でこのデータを取り出し、それを処理することになる。以下のコードに、この考え方を示す。

このパターンは、スレッドが妨害されないように、エンジンがＧｅｔＳｌｏｐｅを非同期で呼び出すことを必要とする。このパターンでは、ＧｅｔＳｌｏｐｅコールを、結果オブジェクトを伴う２つのステップに分解して、これらのコールを相関させる。最初のステップは、Ｂｅｇｉｎ操作メソッドコールを伴う。このコールでは、エンジンは、コールバック関数ならびにコールフレームを渡し、それと引替えに非同期コンテキストオブジェクトを受け取る。ある時点で、アナリストは、このコールバックを呼び出し、この非同期オブジェクトを供給する。このエンジンは、そのコンテキストをこの非同期オブジェクトから取得し、ルールをスケジュールして、スレッドプールによって実行する。このルールが実行されると、このルールは、アナリスト端操作を呼び出し、非同期オブジェクトを渡し、コール結果を受け取り、これらの結果を処理する。

このアナリストはこのシナリオを連続して実行するので、このアナリストは、より多くの結果を、その１つが処理されている間に生成することが可能である。このイベントでは、アナリストはキューを維持し、ルールからのＢｅｇｉｎ Ｇｅｔ要求を待つことができる。多くの場合、エンジンが一般にアナリストに供給を行うので、このタイプのモデルは必要とされない。このことに対する１つの例外では、アナリストは、そのデータをエンジンとは無関係に受け取る。

モデルに基づく管理アーキテクチャ
次に図５を参照すると、本発明によるルールエンジンを使用する、モデルに基づく管理アーキテクチャ５００が示されている。このモデルに基づく管理手法により、開発者は、アプリケーションまたはサービス５０２を、その構成要素、ならびに機能、構成、セキュリティ、およびパフォーマンスの点での所望の状態に関して記述することができる。そのため、アプリケーションまたはサービスの記述５０４により、少なくとも、モデルコンポーネント５０６、マニフェスト（ｍａｎｉｆｅｓｔ）コンポーネント５０８、システムコンポーネント５１０、およびタスクコンポーネント５１２を含めて、１つまたは複数の管理可能なコンポーネントに関してアプリケーションまたはサービス５０２を記述することが容易になる。モデルに基づく管理システム５００は、アトリビューション（ａｔｔｒｉｂｕｔｉｏｎ）コンポーネント５１４を使用して、モデルコンポーネント５０６からマニフェストコンポーネント５０８へのソースコードのアトリビューションをうまく進める。

コンピュータシステム５１６は、アプリケーション５０２のインストール時にアプリケーションまたはサービスの記述５０４を使用して、このコンピュータのオペレーティングシステムに関連する管理サービス５１８を構成する。次いで、管理サービス５１８は、構成管理、問題検出、診断、および復旧などの自動管理動作によってアプリケーションまたはサービス５０２の可用性を確保する助けとなる。モデル５０６は、管理者が実施し得る共通のタスクも記述する。モデルに基づく管理アーキテクチャ５００は、総所有コストを下げることを容易にし、開発から、デプロイメント（ｄｅｐｌｏｙｍｅｎｔ）、運用、およびビジネス分析までのアプリケーションのライフサイクル全体にわたって用いられる。一般に、開発者は、アプリケーションまたはサービスの１つまたは複数のモデルを生成することから開始する。このモデルは、このアプリケーションがどのように機能するか、その構成要素、開発者が定義し監視することを選択する所望の健全性の状態、少なくともこのアプリケーションまたはサービスをどのようにインストールし、このアプリケーションまたはサービスがどんな設定を必要とするかに関する構成上の態様、ならびに管理タスクおよびそのスケジューリングという点で生成されるものである。次いで、このモデルのソースコードの、明示する特定の領域に属性を与える（あるいは、タグを付ける）。

これらのモデルを機器編成マニフェストにロールアップ（ｒｏｌｌ ｕｐ）する。これらのモデルは、テキストドキュメント、スプレッドシートドキュメントなどの形式をとる傾向がある。これらは、コード、スクリプト、ツールによって、あるいは手作業で、より多くのＸＭＬスキーマになる傾向があるマニフェストに変換され、さらに機械によって処理され機械によって読み込まれる構造化ドキュメントである。すなわち、モデルドキュメントは、より人間可読であり、マニフェストはより機械可読である。次いで、これらのマニフェストを使用して、システム管理をうまく進める。

アトリビューションサブコンポーネント５１４は、ソースコードアトリビューションに関連するものである。アトリビューションを用いて、管理情報およびこの管理情報が関係するコードを表す。アトリビューションがないと、２つの別々のコードを記述することが必要になる。１つは、通常のアプリケーション処理用のものであり、１つは、アプリケーションを管理にエクスポーズ（ｅｘｐｏｓｅ）するためのものである。ソースコード中のアトリビューションを用いて、（プローブと呼ぶ）コードのどの部分を用いて健全性を判定かつ／または是正し、かつ管理ルールを実行する時点を指定すべきなのかを記述する。プローブは、既存のオペレーティングシステムＡＰＩ（アプリケーションプログラムインターフェース）にアクセスするコンポーネントから、あるいは、実行中のアプリケーションまたはサービスの内部にロードしたコンポーネントからエクスポーズし得る。いずれの場合でも、開発者は、アトリビューションを付加して、これらのコンポーネント内のタイプのどのサブセットをエクスポーズすべきかと、それらをどのように識別すべきかを示す。プローブは、管理者名前空間内のＵＲＩ（ユニフォームリソース識別子）を用いて識別する。実行時に、プローブは、コンピュータ上のすべてのプローブのカタログ内から識別し、このプローブについての関連情報をたどることによって取り出す。

ソースコードアトリビューションは、監視サービス、例えば属性関数に命令も提供し得る。この属性関数は、監視ルールとして使用され、起動時にロードされ、周期的にポーリングされ、イベントに対して実行されるべきものである。このアトリビューションを自動的に処理し、機器編成と同じやり方でマニフェスト中に置くことができる。そのため、アトリビューションは、単に機器編成ではなく、他の管理目的にも用いられる。アトリビューションを用いて、管理タスクおよび／または是正措置（ｃｏｒｒｅｃｔｉｖｅ ａｃｔｉｏｎ）をサポートすることもできる。

次に図６を参照すると、モデルに基づく管理アーキテクチャ５００の主要コンポーネントを記述することに関係する図面マップ６００が示されている。このアーキテクチャは、図７Ａに関連して説明するモデルコンポーネント５０６、図７Ｂに関連して説明するマニフェストコンポーネント５０８、図７Ｃおよび図７Ｄに関連して説明するシステムコンポーネント５１０、ならびに図７Ｅに関連して説明するタスクコンポーネント５１２を含む。アトリビューションはすでに説明してあり、本明細書を通じて参照する。

次に図７Ａを参照すると、モデルに基づく管理アーキテクチャのモデルコンポーネント５０６に関係するブロックが示されている。アプリケーションを構成するコンポーネント、健全性の状態および復旧、構成設定、ならびに管理タスクについてモデルが形成される。

これらに加えて、システムの任意のかつすべてのコンポーネント（ならびにこれらに関連する関係、依存性、およびサービスロール）をモデル化するためのコンポーネントモデルサブコンポーネント７００がある。コンポーネントモデル７００は、ファイル、構成、アプリケーションをインストールし得る様々な方法などを記述する。

健全性モデルサブコンポーネント７０１は、様々な障害状態、およびアプリケーションまたはサービスの障害の発生のしかたが記述されるように形成し得る。健全性モデル７０１は、健全性についての機能を自動化するためにとる必要があるステップを記述する。健全性モデル７０１は、少なくとも、障害の状態、これらの状態の検出、システム状態の検証、診断、および解決を表す。健全性の状態は、完全に健全である、完全に障害がある、および任意の中間状態とみなすにはどんな基準を満たさなければならないかという点で記述し得る。この中間状態は、例えば、パフォーマンスの劣化、部分的に機能している、顧客機能の一部が機能している、顧客機能の一部が、想定したレベルのサービスを提供するアプリケーションまたはサービスである、などである。健全性は、機能は満足のいく状態だが、パフォーマンスが基準以下であり、アプリケーションまたはサービスが健全でないことを示すことも考慮する。

構成モデルサブコンポーネント７０２は、システム構成のモデル化に関係するものである。構成モデル７０２を用いて、アプリケーション設定、ユーザコントロール、既定値、様々な制約などを記述する。管理タスクモデルサブコンポーネント７０３は、管理タスクのモデル化に関係するものであり、開始、停止、ユーザの追加、データベースの追加、および健全性モデル７０１からコールし得る是正処置など、ユーザがシステムに対して取り得る動作を含む。モデル７０２は、アプリケーションまたはサービスによって行い得るすべてのことを列挙する。アーキテクチャモデル７０４を用いて、分散環境および関連するデプロイメントを記述する。これらは通常、例えば、同じまたは類似のハードウェアおよびソフトウェアの設定および構成を有するクライアント、ならびに分散データベースからなる大規模ネットワークに関係するものである。そのため、ローカルアプリケーションは、リモートディスクアレイに依存し得る。デプロイメントの際に、このディスクアレイを、マニフェストによって、かつＵＲＩを用いてデプロイメントレベルでインスタンス化する必要がある。ＵＲＩは機械に依存しないので、分散システムも、モデルに基づく管理システムの利益を得ることができる。パフォーマンスモデル７０５は、開発者が、メトリクス（ｍｅｔｒｉｃｓ）を用いてアプリケーションまたはサービスのパフォーマンスを監視したい場合のやり方が記述されるように形成し得る。これは、システムの健全性と密接に関係する。アプリケーションまたはサービスに関係するセキュリティのタイプを記述するセキュリティモデル７０６を生成し得る。

本明細書で提供するモデルの数は網羅的ではないことに留意されたい。というのは、開発者は、アプリケーションまたはサービスの様々な態様を管理するための多くの異なるモデルを提供し得るからである。

この主題のモデルに基づくシステムは、その様々な態様を実施するために様々な人工知能に基づく方式を採用し得る。例えば、モデルに関して、所与のインスタンスまたはインプリメンテーションにはどのモデルを使用し得るかを決定するプロセスを、自動分類システムおよびプロセスによってうまく進めることができる。さらに、このような分類子を用いて、システムのパターンを検出し、何が良好な状態で、何が不良状態であり、何が成功したトランザクションで、何が成功しなかったトランザクションかを学習することを開始するシステムの動作プロファイルを形成し得る。次いで、この情報を、対応するモデルにフィードバックし、後続のシステムに対する更新されたモデルとして使用することができる。このような分類では、（例えば、解析ユーティリティおよびコストを計算に入れる）確率および／または統計に基づく解析を用いて、ユーザが自動的に実施されるように望む動作を予測または推測することができる。例えば、ＳＶＭ（サポートベクトルマシン）の分類子を用いることができる。他の分類手法には、ベイズネットワーク（Ｂａｙｅｓｉａｎ ｎｅｔｗｏｒｋｓ）、デシジョンツリー（ｄｅｃｉｓｉｏｎ ｔｒｅｅ）が含まれ、異なる独立パターンを提供する確率分類モデルを用いることができる。本明細書で用いる分類には、優先モデルを形成するのに用いられる統計回帰も含まれる。

本明細書から容易に理解されるように、モデルに基づくシステムは、（例えば、一般的な訓練データによって）明示的に訓練された分類子、ならびに（例えば、ユーザの挙動を観察し、外からの情報を受け取ることによって）暗示的に訓練された分類子を採用し、それによって、これら１つ（または複数）の分類子を用いて、所定の基準に従って、例えば、所与のインプリメンテーションに対してどの初期設定を用いるかを自動的に決定し、次いで、システムが成熟し、データ、インストールされたいくつかのアプリケーション、および対話するノードの数に関する様々なロード条件を経験するにつれ、時間をかけて設定を調整することができる。例えば、十分に理解されているＳＶＭに関して、ＳＶＭは、分類子コンストラクタおよび特徴選択モジュール内での学習または訓練の段階を介して構成される。分類子は、入力属性ベクトルｘ＝（ｘ１、ｘ２、ｘ３、ｘ４、ｘｎ）を、コンフィデンス（ｃｏｎｆｉｄｅｎｃｅ）にマッピングする関数である。コンフィデンスの入力はクラスに属し、すなわち、ｆ（ｘ）＝ｃｏｎｆｉｄｅｎｃｅ（ｃｌａｓｓ）である。管理システムの場合、例えば、属性は、所望の状態のシステムパラメータであり、クラスは、対象とするカテゴリまたは領域（例えば、すべてのドライブ、すべてのネイティブプロセス）である。分類子を用いて、トランザクションログをキャプチャ（ｃａｐｔｕｒｅ）し解析し、パターンを探し、成功したパターンおよび成功しなかったパターンを探すことによってシステムを診断することもできる。

構成の健全性は、例えば、キューのサイズを５から１０に変更し、この変更がアプリケーション、サービス、またはシステムにどんな影響を及ぼし得るかを判定することを含む。同じことが、セキュリティおよびパフォーマンスに当てはまる。この場合、分類子を用いて、パフォーマンスカウンタを監視し、それに従ってシステムの変更を行ってパフォーマンスを最適化することができる。セキュリティをパターンについて監視し分析することもでき、この影響を用いてセキュリティポリシーを提案または変更し得る。このように、健全性は、システムの多くの領域に適用し得る広い概念であることを理解されたい。システム規模の範囲では、パフォーマンスは良好だが、セキュリティが貧弱なことがある。そのため、システムの多くの規範にまたがる包括的な観点が有利である。

管理者が所望する状態をコード中に表現することができ、これを、マニフェストで表面化させ、それを渡して監視サービスによって監視する。システムは、マニフェスト中の命令に基づいてアプリケーションまたはサービスを監視し、アプリケーションまたはサービスがパフォーマンスを満たさないときには管理者に警告し、命令に基づいて是正措置を講ずることができる。例えば、電子メール用のテスト設定が維持されず、ある期間閾値未満に落ちる場合、負荷が正常な状態に戻るまで別の機械を追加することができ、ネットワークトラフィックを、リソースの数を増やすトリガとして用いて、所与の負荷に対処することもできる。目標は、手作業の動作が必要とされるときにのみ管理者が関与するように、できるだけ多くを自動化することである。

モデルに基づく管理システムは構成可能である。この管理システムは、コンポーネントに基づくものであり、コンポーネントはほぼ何でも含む。そのため、このシステムを、その最も小さい管理可能な部品まで小さくし、元通りに構成し得る。データベースでは、例えば、インスタンス、このデータベース、テーブル、およびストアドプロシージャを有するアプリケーションがあり、１つのファイルにまで小さくし得る。４０１ｋの応用例を考える。４０１ｋの応用例は、データベース、ウエブサーバ、および顧客自身のビジネス論理、さらに、オペレーティングシステムおよび関連のものに依存するデータベースにまで依存し得る。様々なレベルで管理および報告を行うことが望ましい。アプリケーションは、コンポーネント間の関係によって記述される。これらの関係は、個々のアプリケーションをどのように組み立てるか（例えば、ＳＱＬサーバは、サービス、インスタンス、およびデータベースを含む）、プラットフォームの要件（例えば、オペレーティングシステムその他のアプリケーション）、および他のコンポーネント（ＳＱＬサーバに接続するウエブサーバ）への通信を表現し得る。１人の管理者は、データベースおよび１台の機械を管理し、金融管理者は４０１ｋの応用例を管理し、ＣＩＯはこれらのアプリケーションおよび機械のすべてを管理する。これらのモデル、報告、および所望の状態により、個々のメトリクスを参照してシステムが想定どおりのことを行っているかどうかを判定し得るように、すべてのことが処理されるべきである。

すべてのモデルはＵＲＩ名前空間に結びつけられ、それによって、システムを運用し、インストールされているすべてのコンポーネントを列挙し、コンポーネントに問合せを行う標準的な方法が提供される。この問合せには、コンポーネントが何を提供するか、何が健全とみなされるか、コンポーネントがどんなイベントを有するか、この１日またはここ数時間でどんなエラーイベントが生じたか、どんな構成設定が含まれているか、この１時間でどんな変化が生じたか、などが含まれる。

次に図７Ｂを参照すると、モデルに基づく管理アーキテクチャのマニフェストコンポーネント５０８に関係するブロックが示されている。アプリケーションとともに出荷されるマニフェストは、モデルおよびソースコードアトリビューションからの情報を、管理システムのサービスが使用するために機械可読形式で含む。アプリケーション用の管理タスクは、このマニフェスト中で定義される。コンポーネント依存性、コンポーネント間の関係、およびサービスロールに関係する第１マニフェストサブコンポーネント７０７、イベント、プローブ、ルール、および動作に関係する第２マニフェストサブコンポーネント７０８、設定およびアサーション（ａｓｓｅｒｔｉｏｎ）に関係する第３マニフェストサブコンポーネント７０９、コマンド（すなわち、コマンドレット）および管理ロールに関係する第４マニフェストサブコンポーネント７１０、分散環境に関係する第５マニフェストサブコンポーネント７１１、ならびにデプロイメントに関係する第６マニフェストサブコンポーネント７１２を含めて、モデルに対応して生成されたいくつかのマニフェストが存在し得る。

マニフェストは、開発者、運用チーム、および管理者の間の「橋渡し」であり、属性を与えられたコードについてモデルを走査するツールによって自動的に生成される。設定エンジンは、コンポーネントマニフェスト７０７を使用して、アプリケーションまたはサービスのインストール方法を決める。コンポーネントマニフェスト７０７は、論理コンポーネント、ファイル、これらのファイルをどこにインストールすべきか、および構成設定（または任意の設定）を記述する。依存性は、インストール前に定義する必要があるものであり、アプリケーションを異なるモードで、様々なセキュリティの度合いおよび異なる動作プロファイルでインストールすることができるように様々なロールを含む。コンポーネントマニフェスト７０７は、手動および自動で何を行うかをユーザおよび／またはシステムにより簡単に知らせる。マニフェストの粒度は、１コンポーネント当たり１つのマニフェストにまで小さくし得る。

従来方式では、実際に必要とされるよりもはるかに多くのファイルをインストールする。マニフェストにより、必要とされるファイルだけをインストールすることができる。こうすると、少なくともパフォーマンスおよびセキュリティが改善される。ソフトウェアの依存性は、マニフェスト７０７内で定義される。アプリケーションレベルでは、こられの依存性は、単一の機械に固有のものであり、コンポーネントの関係およびハードウェアリソースを定義し得る。コンピュータは、マニフェストによって記述し得る。例えば、アプリケーションは、特定の製造業者のデュアルプロセッサマシン上にデプロイ（ｄｅｐｌｏｙ）すべきである、あるいは、４プロセッサマシンに接続すべきである、などである。マニフェスト７０７は、プロセッサ、メモリ、ドライブなどを、実装に必要とされるハードウェアの粒度のレベルまで記述する。そのため、管理は、従来方式のシステムの場合の事後対応型ではなく、事前対応型になり得る。ハードディスクの障害は、システム温度を長時間にわたって監視し、電源レール電圧を監視し、それらが十分であると判明した場合には、例えば、熱による障害によって生じると判定し得る。

健全性モデル７０１を用いて、健全性マニフェスト７０８を生成する。健全性マニフェスト７０８は、アトリビューションその他のツールを用いて健全性モデル７０１からポピュレートする。イベントはモデル７０１内でコールされず、リソースファイル内でコールされる。ツールがリソースファイルおよび属性を与えられたソースコードを走査し、健全性マニフェスト７０８をポピュレートする。所定のシーケンスのイベントに注意するか、あるいはパフォーマンスカウンタの閾値を監視することによって障害状態を検出し得る。このような障害状態の対処方法に関して、システムに命令を提供し得る。健全性モデルは、ルールに変換される。健全性マニフェスト７０８は、ｅｖｅｎｔ１、ｅｖｅｎｔ２、ｔｉｍｅ３などのパラメータを伴うルールタイプのイベントシーケンスを含む。

構成モデル７０２は、どんな設定が含まれるかを記述し、設定／アサーションマニフェスト７０９に変換される。マニフェスト７０９は、コンポーネントがインストールされるときにシステムが設定を生成するための命令スキーマを提供する。

管理タスクモデル７０３は、コマンドレット／管理ロールマニフェスト７１０を介して動作に変換される。例えば、データのバックアップが必要とされる場合、コマンドレットは、このバックアップタスクをうまく進めるのに用いられる実際のコードまたはＵＲＩになる。多くの管理タスクを実施する必要がある場合、マニフェスト７１０は、これらのコマンドへの、おそらくはコードへのＵＲＩ経路を提供する。コマンドレットは、このコードに対するアサーションによって処理するか、あるいは外部コードを要求し得る。管理ロールは、例えば、アプリケーションまたはサービスを管理するユーザの複数のクラスおよびそれらがそれぞれ実行し得る制御レベルをサポートする別のアブストラクション（ａｂｓｔｒａｃｔｉｏｎ）である。これは、ロールに基づくアクセスに関係する。様々なユーザのロールおよびそれらの許可機能を記述するメタデータが必要とされる。ロールは、誰にインストール権限があるのか、誰が監視を変更し得るのか、誰が健全性を監視し得るのか、誰が警告を解決し得るのか、誰がこれらの様々な動作を取り得るのかなど、このシステムのすべての態様にまたがるものである。

タスクモデル７０３は、管理者がすべきことと開発者が考えることを定義する。これらは、マニフェスト７１０に表され、運用チームによってその環境に対してカスタマイズされる。これらのカスタマイズ化は、クラスレベルおよびインスタンスレベルで行い得る。クラスレベル、インスタンスレベルでマニフェストに変更を加えることができ、実行時に直接変更を加えることができる。ここで開示するモデルに基づく管理アーキテクチャの極めて強力な特徴は、機能をまずクラスレベルで記述することができ、実行時にアクセスがインスタンス空間に対して行われることである。

アーキテクチャモデル７０４は、分散コンポーネントマニフェスト７１１およびデプロイメントマニフェスト７１２を表面化（ｓｕｒｆａｃｅ）させる。例えば、機械間のネットワーク接続、ハードウェア要件はここで扱う。デプロイメントマニフェスト７１２は少なくとも、ウエブサーバ、中間階層サーバ、およびデータベースサーバを備えるアプリケーションをサポートし、フロントエンド／バックエンドアプリケーション、２つのアプリケーション間のネットワーク接続性を含み、個々のノード間の関係を記述する。デプロイメント期間には、全体的アーキテクチャモデル７０４で記述したもののインスタンスが生成される。

パフォーマンスモデルおよびセキュリティモデル（７０５および７０６）はそれぞれ、対応する関連機能および操作を記述する（図示しない）マニフェストをサポートする。

機械ベースの学習を採用することに戻ると、分類子を用いて、例えば第１のデプロイメント中に、要件に基づいてモデルコードの選択部分のマニフェストを選択し、動的に生成し得る。使用するアトリビューションの数を増減させて、既定モデルを自動的に生成し得る。時間の経過とともにシステムの動作情報が利用可能になるので、この情報を分析して、例えば、最新のデータの傾向およびログに基づいて、特定の領域におけるシステムをより厳密に監視することができるようにマニフェストの粒度レベルを調整し得る。次いで、更新されたマニフェストを生成し直し、必要に応じて、アプリケーションまたはサービスをより厳密に監視するために使用する。

マニフェストに、製造業者からの既定のインストールまたは推奨された最適な実務慣行が記述されている場合、管理者は、それらの事柄を変更したいことがある。例えば、健全性ルールに関して、管理者は、閾値を３０から４０に変更し、コンポーネントをインストールし、またセキュリティポリシーを上書きしたいことがある。これは、マニフェストのカスタマイズされたバージョンを生成して、製造業者がバンドルしたマニフェストを上書きすることによって行い得る。異なるバージョンはインストール中に検出することができ、それによって、既定のマニフェストまたはカスタマイズされたマニフェストの選択権がユーザに与えられる。あるいは、上書き値が列挙された、システムが読み込む別のファイルが存在し得る。この一覧を表示し、それによってユーザが選択して既定のマニフェストに適用するか、あるいは、インストール中に既定の設定が上書きされるようにする。

分散アプリケーションに関して、管理者は、より一般には、これらのうち３つを、そのうちの４つを、それらのうち６つをすべてこの構成内で結線（ｗｉｒｅｄ）したいことを規定し得る。この管理者は、それに従って所与の環境についてのデプロイメントマニフェスト７１２をカスタマイズし得る。

次に図７Ｃを参照すると、モデルに基づく管理アーキテクチャに従ってアプリケーションまたはサービス７１４を管理するのに使用するシステムコンポーネント５１０のコアシステムＡＰＩのブロック図が示されている。システムコンポーネント５１０は、管理すべきアプリケーションまたはサービス７１４を含む。システム５１０は、モデルに基づく管理をうまく進めるために協調して通信を行ういくつかのＡＰＩを含む。システム５１０は、（図７Ｂに関して説明した）アプリケーションマニフェスト内の情報によって構成された複数のサービスからなる。

システム５１０は、アプリケーションの可用性を確保するのに必要なサービスからなり、マニフェストコンポーネント５０８内で表現され、かつ管理者によって改変された所望の状態を用いて、依存性を検証し、必要なファイル、設定、およびセキュリティだけをインストールするインストール作業と、イベントをサブスクライブ（ｓｕｂｓｃｒｉｂｅ）し、指定どおりに転送するイベントサブスクリプションと、機器編成をポーリングして、機器編成およびカウンタを周期的に収集することと、および統合的トランザクションまたはユーザシミュレーショントランザクションとを実施する。アプリケーションが利用可能であり、かつ想定どおりに（所望の状態で）実施されているかどうかを判定する最適な方法の１つは、監視システムが、ユーザであるかのようにこのアプリケーションを使用することである。これは能動的監視である。潜在的に可能な第２の方法は、ユーザによる現実のトランザクションを能動的に監視し、集計したデータをシステムに報告して分析することである。これらのステップではループが閉じており、内部アプリケーションデータが十分ではないことが示される。モデルに基づく管理は、アプリケーション外でも機能する。

また、システム５１０は、マニフェストコンポーネント５０８内で表現された所望の状態を用いて、自動タスク管理を行うためのタスクスケジューリングと、プログラムの機能へのアクセスを制限するためのロールに基づくアクセスと、問題を検出し、根本的原因を診断し、是正処置を講じ、介入が必要な場合にはシステム管理者に通知するために監視を行うことと、上記を行うためにポリシーをカスタマイズし、それを多くの機械に適用するための中央構成（ｃｅｎｔｒａｌ ｃｏｎｆｉｇｕｒａｔｉｏｎ）とを実施する。

アプリケーション７１４と通信するインストールＡＰＩ ７１６が提供され、それによって、このアプリケーションのインストール、アプリケーションのアップデート、およびパッチがうまく進む。インストールＡＰＩ ７１６は、コードを介してマニフェストアセンブリを取得し、これらのアセンブリをインスタンス化する。これは、この機械上に、このコンポーネント、このマニフェスト、およびこのバージョンをインストールするようにシステムに命令することによって行われる。インストールＡＰＩ ７１６は、それに関連するプロトコル７１８およびビューア７２０を有する。プロトコル７１８は、システム５１０の他のコンポーネントへのＡＰＩ関連データの通信をうまく進める。ビューア７２０は、インストールＡＰＩ ７１６に関係するデータを表示する。インストールＡＰＩ ７１６は、単一の機械上へのインストールだけでなく、ローカルシステムおよびリモートシステムがともに関与する分散アプリケーションまたはサービス、ならびにハードウェアのプロビジョニング（ｐｒｏｖｉｓｉｏｎｉｎｇ）およびアブストラクションもうまく進める。分散データセンタ環境では、ハードウェアシステムを全体的により細かい粒度に、個々の機械のアブストラクションに抽象化し得ることが重要である。プロトコルは、ＡＰＩに関して本明細書で企図されているように、ＡＰＩ関連データの送受信を司るルールである。ビューア７２０は、この記述の中で理解されるように、ＡＰＩ、ここではインストールＡＰＩ ７１６に関連するデータを表示するプログラムである。ＡＰＩデータは、例えば、サウンドファイル、ビデオファイル、その他のタイプのデータファイルを含むが、これらに限定されるものではない。

システム５１０は、アプリケーション７１４と通信する構成ＡＰＩ ７２２を含み、それによって、アプリケーション７１４の構成がうまく進む。構成ＡＰＩ ７２２は、それに関連するスキーマ７２３、プロトコル７２４、およびビューア７２６を有する。スキーマ７２３は、ＡＰＩ ７２２とアプリケーション７１４の間で渡されるデータの構造および内容を定義する。プロトコル７２４は、システム５１０の他のコンポーネントへのＡＰＩ関連データの通信をうまく進める。ビューア７２６は、構成ＡＰＩ ７２２に関係するデータを表示する。

分散環境で多数対１の管理をうめく進める管理ＡＰＩ ７２８も含まれる。ＡＰＩ ７２８は、管理されるアプリケーション７１４と通信し、（図示しない）リモートシステムとも通信する。ＡＰＩ ７２８は、それに関連するプロトコル７３０およびビューア７３２を有する。

システム５１０は、アプリケーション７１４と通信するパフォーマンスカウンタＡＰＩ ７３４を含み、それによって、アプリケーション７１４を管理するのに使用するカウンタ変数の追跡がうまく進む。カウンタＡＰＩ ７３４は、それに関連するプロトコル７３６およびビューア７３８を有する。プロトコル７３６は、システム５１０の他のコンポーネントへのＡＰＩ関連データの通信をうまく進める。ビューア７３８は、カウンタＡＰＩ ７３４に関係するデータを表示する。パフォーマンスカウンタは、アプリケーション７１４によってエクスポーズされ、ビューア７３８を介してカウンタをパブリッシュ（ｐｕｂｌｉｓｈ）する。

アプリケーション７１４と通信する機器編成ＡＰＩ ７４０が提供され、それによって、機器編成を構成し、機器編成データをアプリケーション７１４に渡すことがうまく進む。機器編成ＡＰＩ ７４０は、それに関連するプロトコル７４２およびビューア７４４を有し、ビューア７４４を介して機器編成がエクスポーズされる。プロトコル７４２は、システム５１０の他のコンポーネントへのＡＰＩ関連データの通信をうまく進める。ビューア７４４は、機器編成ＡＰＩ ７４０に関係するデータを表示する。機器編成ＡＰＩ ７４０は、ＩＰＣ（プロセス間通信）７４６を介して、管理されるアプリケーション７１４と通信する。ＩＰＣは、同じコンピュータ内の、あるいはネットワークを介して、１つのプログラムと別のプログラムの間でデータを自動的に交換する。ＩＰＣ機能の一例は、ユーザがクリップボードを使用して、１つのファイルから別のファイルに手作業でデータをカットアンドペーストするときに実施されるものである。カウンタは、共有メモリを介して常にパブリッシュされ、機器編成は、要求時に送達される。機器編成ＡＰＩ ７４０は、イベントスキーマに類似のやり方で機器編成クラスのサーフェイス（ｓｕｒｆａｃｅ）を記述するスキーマ７４８も含む。（図示しない）機器編成ログも含まれることがあるが、管理者の多くは、イベントログを使用することを好む。

システム５１０は、コンポーネントおよびモード情報を追跡しキャッシュする記憶部であるカタログ７４７を含む。このモード情報は、インストール時にマニフェストから送られ、その一部は動的であり、実行時に更新される。カタログ７４７は、カタログＡＰＩを含み、カタログ７４７内に記憶されるデータへのアクセスを提供する。これらのデータのいくつかのタイプとして、イベント、カウンタ、機器編成、および構成のデータが挙げられる。カタログ７４７へのアクセスは、プロトコル７５１およびビューア７５３によってうまく進む。中央構成データベースは、複数の管理ノード全体にわたってロールアップされた、あるいは集計されたカタログの一覧を含む。

システム５１０は、アプリケーションまたはサービス７１４と通信するイベントＡＰＩ ７５０を含み、それによって、アプリケーション７１４を管理するのに使用するイベントの実装および追跡がうまく進む。イベントＡＰＩ ７５０は、発生するすべてのイベントの記憶部として働くイベントログ７５２に接続される。イベントＡＰＩ ７５０は、それに関連するプロトコル７５４およびビューア７５６を有する。プロトコル７５４は、システム５１０の他のコンポーネントへのＡＰＩ関連データの通信をうまく進める。ビューア７５６は、イベントＡＰＩ ７５０に関係するデータを表示する。イベントＡＰＩ ７５０とアプリケーション７１４の通信は、それらの間で渡されるデータの構造および内容を定義するイベントスキーマ７５８に従う。これらのイベントは、それらが記述または発生したときにパブリッシュされる。このスキーマは、イベントのサーフェイスを記述する。

システム５１０は、アプリケーション７１４と通信する自動化ＡＰＩ ７６０を含み、それによって、普通ならアプリケーション７１４と対話的に行われる手順の自動化がうまく進む。自動化ＡＰＩ ７６０は、それに関連するプロトコル７６２およびシェル７６４を有する。プロトコル７６２は、システム５１０の他のコンポーネントへのＡＰＩ関連データの通信をうまく進める。シェル７６４は、ユーザと自動化ＡＰＩ ７６０の対話をうまく進めるユーザインターフェースを提供し、それによって、自動化プロセスおよびこれらの自動化プロセスのユーザコントロールに関係するデータの入力および表示が行われる。

システム５１０はさらに、アプリケーション７１４および自動化ＡＰＩ ７６６と通信するスケジュールされたタスクＡＰＩ ７６６を含む。スケジュールされたタスクＡＰＩ ７６６により、少なくとも自動化ＡＰＩ ７６０および管理されるアプリケーション７１４についてスケジューリングを行うジョブまたはプログラムがうまく進む。スケジュールされたタスクＡＰＩ ７６６は、実行すべきジョブの一覧を維持し、それに従ってリソースを割り当てる。スケジュールされたタスクＡＰＩ ７６６は、それに関連するプロトコル７６８およびビューア７７０を有する。プロトコル７６８は、システム５１０の他のコンポーネントへのＡＰＩ関連データの通信をうまく進める。ビューア７７０は、スケジュールされたタスクＡＰＩ ７６６に関係するデータを表示する。タスクスキーマ７７２は、タスクＡＰＩと他のコンポーネントの間で渡されるデータの構造および内容を定義する。

自動化およびタスクのデータは、タスクモデルおよびコマンドレットモデルから受け取る。これらの機能は、管理シェルを介してローカルまたはリモートで自動化し得る。このスケジューリングシステムは、これらの機能、例えば午前３時のバックアップを実行し得る。

図７Ｃで説明したコンポーネントは、ローカルな実施形態のものを表し、図７Ｄのコンポーネントは、多くの機械およびソフトウェアのシステム全体にわたって解析が行われる分散実施形態に関連するものを表し得ることを理解されたい。そのため、分散実施形態では、図７Ｄのコンポーネントは、図７Ｃのローカルシステムの少なくとも１つと通信する。ただし典型的には、複数のこのようなローカルな実施形態は、有線および／または無線の方式をとる。ローカルな実施形態では、システム５１０は、ローカル監視サービスＡＰＩ ７６５を含めて、図７Ｄのコンポーネントのいずれか、またはすべても含み得る。ローカル監視サービスＡＰＩ ７６５は、プロトコル７６７、ビューア７６９、およびスキーマ７７１も含み、これらはそれぞれ、他のＡＰＩのこのようなコンポーネントに類似の機能をうまく進める。分散実施形態では、ローカル監視サービスＡＰＩ ７６５は、以下で説明する分散監視サービスに監視情報を渡す。

次に図７Ｄを参照すると、モデルに基づく管理アーキテクチャのシステムコンポーネント５１０の管理に関連するＡＰＩのブロック図が示されている。構成データベースサブコンポーネント７７４が提供され、このサブコンポーネントに、中央構成ＡＰＩ ７７６を介してアクセスおよび制御が提供される。中央構成ＡＰＩ ７７６は、システム５１０のすべてのサブコンポーネントに接続される。中央構成ＡＰＩ ７７６は、それに関連する通信および対話用のプロトコル７７８およびビューア７８０、ならびにアサーションおよび既定値などの構成設定および属性のシェイプ（ｓｈａｐｅ）を記述するスキーマコンポーネント７８２を有する。プロトコル７７８は、システム５１０の他のコンポーネントへのＡＰＩ関連データの通信をうまく進める。

管理システムの運用関連データ、例えば、報告、現在の状態、および履歴データなどのリポジトリ（ｒｅｐｏｓｉｔｏｒｙ）として働く運用データベースサブコンポーネント７８３も提供される。監視ＡＰＩ ７８４は、運用データベース７８３およびモデルに基づく管理システムのすべてのサブコンポーネントに接続される。監視ＡＰＩ ７８４はさらに、それに関連するプロトコル７８５、ビューア７８６、およびスキーマ７８７を有する。プロトコル７８５は、システム５１０の他のコンポーネントへのＡＰＩ関連データの通信をうまく進める。ビューア７８６は、監視ＡＰＩ ７８４に関係するデータを表示する。スキーマ７８７は、運用データベース７８３全体の定義を、少なくともその構造と、この構造内の各データ要素が含み得る内容のタイプとに関して提供する。

中央構成は、すべてのＡＰＩに接続することができ、構成の詳細を設定するために管理者が使用するものである。構成の詳細は、どの機械にアプリケーションをインストールすべきかなど、分散アプリケーションのシナリオついての詳細を含み得る。構成は、監視構成も含み得る。例えば、すべての機械は、５分間にわたってＣＰＵの利用率が８０％未満にならないことを示さなければならない。そのため、この監視システムは、構成システムを使用する。監視は、アプリケーションが１つのモデルごとに、挙動し、構成され、インストールされることを、管理者が管理システムを介して保証する方法である。監視は、想定される機能、所望のセキュリティの程度、正しく実施されること、およびユーザの想定どおりにデータが送達されることを保証することも含む。そのため、監視は、これらすべての領域にまたがる。全体的なプロセスは、インストールし、構成し、要求時にタスクを実行し、イベントを消費し、機器編成、構成を提供し、データおよび結果を記憶することである。健全性マニフェストは、監視システムに作業命令を、監視システムへの命令であるルールの形式で提供する。一般に、このマニフェストは実行時の命令を含み、これら実行時の命令は所望の状態を実装する。

監視サービスは、ローカルサービスであるだけでなく、中央または分散型のメカニズムである。分散実施形態では、健全性は、ローカルマシンの健全性ならびにローカルマシンとリモートマシンの間の関係も含む。例えば、一まとまりの１０台の機械があると仮定し、６台が正しく機能している限り、このシステムは健全であるとみなされる。しかし、５台以下の機械しか動いていない場合、このシステムの健全性の状態は、警戒状態まで劣化している。４台以下の機械しか動いていない場合、このシステムの健全性は障害状態とみなし得る。ハードウェアのアブストラクションにより、１つまたは複数のクラスタマシンに障害が発生するか、あるいはオフラインになった場合、１つまたは複数のバックアップシステムまたはアプリケーション／サービスをオンラインにすることが容易になる。そのため、命令に基づいて、共同のアイドル状態のリソースまたは共有リソースを制御し得る。この機能は、データセンタ環境では特に有用である。システムが、最適な、あるいは少なくとも最低限の機能を確実に維持するために、自動化された動作を実装し得る。

モデルに基づく管理アーキテクチャの一態様により、開発者は、システムが健全であるとみなされるために満たさなければならない基準を表す多数のルールを記述し得る。監視ＡＰＩ ７８４は、ルールの暗示的な同時処理をうまく進めるルールランタイムエンジンを含む。このルールエンジンは、これらのルールを中間形式として表す入力命令を受け取る。これらのルールは、ＲＤＬ（ルール定義言語）を用いて表現される。このルールエンジンは、構成データベース７７４から、ルールコードをインスタンス化するのに用いる構成データも受け取る。翻訳器は、これらの入力命令を読み込み、これらを並列実行形式に変換する。ランタイムエンジンは、これら翻訳された命令を読み込み、並列実行をうまく進める。このルールコードは、ランタイムエンジンに、どのルールを実行するかと、このルールを実行するのに必要とされるパラメータとを指定する構成データをロードすることによってインスタンス化される。ルールのパラメータは、実行時に変更し得る。例えば、問題が検出されたときにのみ、システムに大きな影響を及ぼすルールを実行可能にする。このように、これらのルールは動的であり、それに従って変更し得る閾値もそうである。監視ＡＰＩ ７８４は、システム５１０のすべてのサブコンポーネントにも接続される。

管理者が使用するための、マニフェストを記憶し編集するサービス７８８も提供される。マニフェストサービス７８８は、それに関連するプロトコル７８９およびビューア７９０を有し、それによって、これらのマニフェスト機能を管理者にエクスポーズする。マニフェストサービス７８８は、プロトコル７８９およびビューア７９０を介してこれらのマニフェストを管理者に供給し、それによって管理者が、インストール前に、これらのマニフェストを閲覧し変更することができる。マニフェストサービス７８８により、アップデートおよびカスタマイズに従って、これらのマニフェストをバージョニング（ｖｅｒｓｉｏｎｉｎｇ）もうまく進む。

モデルに基づく管理システムのすべてのサブコンポーネントに接続されるロールに基づくアクセスＡＰＩ ７９１も提供される。ロールに基づくアクセスＡＰＩ ７９１はさらに、それに関連するプロトコル７９２およびビューア７９３を有する。プロトコル７９２は、システム５１０の他のコンポーネントへのＡＰＩ関連データの通信をうまく進める。ビューア７９３は、ロールに基づくアクセスＡＰＩ ７９１に関係するデータを表示する。このＡＰＩ ７９１は、監視コンポーネントおよび構成コンポーネントの上のレベルで示されており、そのため、モデルに基づく管理システムの様々なコンポーネントおよび態様へのアクセスを全体的に管理する。ロールに基づくアクセスＡＰＩ ７９１は、プロトコル７９２およびビューア７９３を含む必要はない。というのは、これらの機能は、システム５１０の他のコンポーネントによってうまく進めることができるからである。

このシステムは、機械ベースの学習および制御用の分類子７９４も含む。上記で示したように、分類子７９４は、システムの、いくつか例を挙げると、パフォーマンスや健全性を高めるために多くのやり方で使用することができる。機械ベースの学習をうまく進めるために、分類子７９４は、このシステムのすべてのコンポーネントにアクセスし、そのデータを使用し得るように、中央構成サービス７７６に接続される。

次に図７Ｅを参照すると、モデルに基づく管理アーキテクチャのタスクコンポーネント５１２の主要サブコンポーネントが示されている。これらのタスクは、管理タスクモデルによって記述される。これらのタスクは、監視サブコンポーネント７９５、トラブルシューティングサブコンポーネント７９６、および管理サブコンポーネント７９７の３つのサブコンポーネントに分けられる。

監視サブコンポーネント７９５のタスクは、健全性、セキュリティ、パッチ、構成、パフォーマンス、およびアプリケーションデータを監督することを含む。トラブルシューティングサブコンポーネント７９６のタスクは、健全性の状態の診断、警告の処理、ならびにイベントログ、機器編成ログ、およびパフォーマンスログを更新することを含む。管理サブコンポーネント７９７のタスクは、中央構成／ポリシー、スケジューリング、および更新デプロイメントを含む。管理には、単一のシステムの管理だけでなく、例えば、多数の機械、アプリケーション、およびシステム、ならびにポリシー、バックアップ時間、変更、およびアップデートを管理することも含まれる。

モデルに基づく管理アーキテクチャでは、抽象リソースまたは物理リソース、あるいはリソースコレクション（ｃｏｌｌｅｃｔｉｏｎ）を一意に識別するためにＵＲＩを用いる。リソース用のスキーマは、このリソース用のプレースホルダ（ｐｌａｃｅｈｏｌｄｅｒ）を伴うＵＲＩによって識別される。プレースホルダを伴うＵＲＩをＵＲＩテンプレートと呼ぶ。このシステムのカタログは、特定のインスタンスを参照せずに機器編成を記述するために、ＵＲＩテンプレートに依存する。ＵＲＩテンプレートにより、実際に特定のインスタンスについてのプローブを取り出すことなく、プローブを識別し、このプローブの特徴を理解することができる。インスタンスとは切り離して機器編成をあらかじめ定義する機能を保護すると、ルールのデプロイメントおよび記述が比較的容易になり、関連するオペレーティングシステムが管理可能になる。

モデルに基づく管理フレームワークでは、ソフトウェアおよびハードウェアの可用性を監視するために、ＲＤＬを用いてルールの定義を可能にする。ＲＤＬで記述されたルールは、ランタイムエンジンによって監視サービスの一部として実行される。ＲＤＬの目的は、アサーションをテストし、実行時の情報を用いて制約を実行し、推測を行い、相関を実施し、動的テストの結果を他のコンポーネントに送ることである。ＲＤＬによりルールタイプ（すなわちクラス）を定義し、別のＸＭＬ（拡張マークアップ言語）ドキュメントを用いて、インスタンス化に必要なパラメータ値を指定することによってこのルールタイプのインスタンスを生成する。問題の検出、診断、解決、検証、および警告を行うためにこのシステムが取るべきステップのシーケンスを記述するためにスキーマが存在する。このシーケンスが、監視システムによって、モデルに記述され、マニフェストに表現され、実行／管理される。

モデルに基づく管理フレームワークでは、前に示したように、イベントおよびパフォーマンスカウンタの更新値を用いて、サービスおよびテストまたは統合的トランザクションの健全性モデル（またはステータス）を示す。健全性モデル７０１は、サービスまたはコンポーネントにどのように障害が発生し得るかについてのグラフィカルな、かつ／またはテキストによる表現であり、サービスの様々なイベントおよびパフォーマンスカウンタの重大さを管理者が理解し、観察された機器編成データに基づいてなんらかの動作を取るかどうかを効率的に判断する助けになる。開発者は、健全性モデル７０１を、次いで、このモデルおよびソースコードアトリビューションから生成される対応するファイルとともに構築する。

健全性モデル７０１は、コンポーネントの依存性に加えて、コンポーネントの関係の記述を含む。検出された問題の状況に応じて、システムは、関係ツリーを移動し、他のコンポーネントの健全性に基づいて根本的原因を決定しようと試みることができる。この手法は、モデルおよびマニフェストによって補佐される。

次に図８を参照すると、モデルに基づく管理のプロセスの流れ図が示されている。８００で、インストールすべきアプリケーションまたはサービスを、そのコンポーネントに関して記述する。８０２で、このアプリケーションまたはサービスを、機能、構成、セキュリティ、およびパフォーマンスについての所望の状態の形で記述する。８０４で、この記述は、インストール中にアプリケーションまたはサービスとともに提供され、それによって、システムがこの記述を用いて、システムの管理サービスを構成する。次いで、このプロセスは、停止（Ｓｔｏｐ）ブロックに達する。

次に図９を参照すると、モデルに基づく管理を実施するプロセスのより詳細な流れ図が示されている。９００で、アプリケーションのコンポーネント、健全性の状態および復旧、構成の設定、ならびに管理タスクに関するモデルを形成する。９０２で、ユーザは、環境に応じて、システム／ルール／モデルをカスタマイズする。９０４で、ソースコードにアトリビューションを挿入して、監視を行うための機器編成および論理を示す。９０６で、モデル情報およびソースコードアトリビューションのマニフェストを提供し、それを管理システムのサービスが使用する。このマニフェストは、管理システムのサービスが使用できるように機械可読形式で提供される。９０８で、マニフェスト情報に基づいて、管理システムのサービスの１つまたは複数を構成する。９１０で、システムによるコマンドレットの登録、スケジュールの設定など、マニフェスト内でこのアプリケーションについての管理タスクを定義する。次いで、このプロセスは、停止（Ｓｔｏｐ）ブロックに達する。

次に図１０を参照すると、モデルに基づく管理の所望の状態を実施するプロセスの流れ図が示されている。１０００で、マニフェストから所望の状態にアクセスする。１００２で、依存性を検証し、必要なファイル、設定、およびセキュリティ機能だけをインストールする。１００４で、マニフェストの指定どおりにイベントをサブスクライブし、転送する。１００６で、機器編成データおよびカウンタデータ、ならびに実施されるテストおよび統合的トランザクションを周期的に収集する。１００８で、自動管理タスクを実施する。１０１０で、プログラム機能へのアクセスを制限する。ただし、モデルに基づく管理をうまく進めることにこれを含める必要はない。１０１２で、問題を検出し、根本的問題を診断し、是正措置を講じ、介入時にシステム管理者に通知する。１０１４で、上記すべてについてのポリシーをカスタマイズして、多くの他のタイプの機械およびシステムに適用する。次いで、このプロセスは、停止（Ｓｔｏｐ）ブロックに達する。

次に図１１を参照すると、開示したアーキテキチャを実行するように動作可能なコンピュータのブロック図が示されている。本発明の様々な態様についての追加の状況を提供するために、図１１および以下の検討は、本発明の様々な態様を実施し得る適切なコンピューティング環境１１００を簡潔かつ全体的に説明することを意図している。１つまたは複数のコンピュータ上で実行し得るコンピュータにより実行可能な命令の一般的な状況において本発明をこれまで説明してきたが、当業者には、他のプログラムモジュールと組み合わせて、かつ／または、ハードウェアおよびソフトウェアの組合せとして、本発明を実施することもできることが理解されよう。一般に、プログラムモジュールは、特定のタスクを実施し、また特定の抽象データタイプを実装するルーチン、プログラム、コンポーネント、データ構造などを含む。さらに、当業者には、シングルプロセッサまたはマルチプロセッサのコンピュータシステム、ミニコンピュータ、大型コンピュータ、ならびにパーソナルコンピュータ、ハンドヘルドコンピューティング装置、マイクロプロセッサベースまたはプログラム可能な民生用電子機器などを含めて、他のコンピュータシステム構成によって本発明の方法を実施し得ることが理解されよう。これらはそれぞれ、１つまたは複数の関連装置に動作可能に結合し得る。例示した本発明の態様は、通信ネットワークを介して接続された遠隔処理装置によってある種のタスクが実施される分散コンピューティング環境で実施することもできる。分散コンピューティング環境では、プログラムモジュールは、ローカルおよびリモートのメモリ記憶装置に配置することができる。

再度図１１を参照すると、本発明の様々な態様を実施するための、コンピュータ１１０２を含む環境の例１１００が示されている。コンピュータ１１０２は、処理装置１１０４、システムメモリ１１０６、およびシステムバス１１０８を含む。システムバス１１０８は、システムメモリ１１０６を含めてシステムコンポーネントを処理装置１１０４に接続するが、システムコンポーネントの例はこれに限定されるものではない。処理装置１１０４は、様々な市販のプロセッサのいずれかとし得る。処理装置１１０４として、デュアルマイクロプロセッサその他のマルチプロセッサアーキテキチャも使用し得る。

システムバス１１０８は、様々な市販のバスアーキテクチャのいずれかを利用して、（メモリコントローラ付き、またはメモリコントローラを伴わない）メモリバス、ペリフェラルバス、およびローカルバスをさらに相互接続し得るいくつかのタイプのバス構造のいずれかとし得る。システムメモリ１１０６は、ＲＯＭ（読出し専用メモリ）１１１０およびＲＡＭ（ランダムアクセスメモリ）１１１２を含む。ＢＩＯＳ（基本入出力システム）は、ＲＯＭ、ＥＰＲＯＭ、ＥＥＰＲＯＭなどの不揮発性メモリ１１１０内に格納される。このＢＩＯＳは、例えば起動時に、コンピュータ１１０２内の要素間で情報を転送する助けとなる基本ルーチンを含む。ＲＡＭ １１１２は、データをキャッシュするスタティックＲＡＭなどの高速ＲＡＭも含み得る。

コンピュータ１１０２は、ハードディスクドライブ１１１４、（例えば、リムーバブルディスク１１１８に対して読書きを行う）磁気ディスクドライブ１１１６、および（例えば、ＣＤ−ＲＯＭディスク１１２２を読み込み、また、ＤＶＤ（デジタルビデオディスク）などの他の大容量光メディアに対して読書きを行う）光ディスクドライブ１１２０をさらに含む。ハードディスクドライブ１１１４、磁気ディスクドライブ１１１６、および光ディスクドライブ１１２０はそれぞれ、ハードディスクドライブインターフェース１１２４、磁気ディスクドライブインターフェース１１２６、および光ドライブインターフェース１１２８よってシステムバス１１０８に接続し得る。これらのドライブおよびそれらに関連するコンピュータ可読メディアは、データ、データ構造、コンピュータにより実行可能な命令などを記憶する不揮発性記憶装置を提供する。コンピュータ１１０２の場合、これらのドライブおよびメディアは、適切なデジタルフォーマットでブロードキャストプログラムを記憶することに対応する。上記のコンピュータ可読メディアの説明では、ハードディスク、リムーバブル磁気ディスク、およびＣＤについて言及したが、当業者には、ｚｉｐドライブ、磁気カセット、フラッシュメモリカード、デジタルビデオディスク、カートリッジなど、コンピュータによって読込み可能な他のタイプのメディアも、例示の動作環境で使用し得ること、さらに、このようなメディアはいずれも、本発明の方法を実施するコンピュータにより実行可能な命令を収容し得ることが理解されよう。

オペレーティングシステム１１３０、１つまたは複数のアプリケーションプログラム１１３２、他のプログラムモジュール１１３４、およびプログラムデータ１１３６を含めて、いくつかのプログラムモジュールをこれらのドライブおよびＲＡＭ １１１２内に記憶することができる。オペレーティングシステム、アプリケーション、モジュール、および／またはデータの全部または一部を、ＲＡＭ １１１２内にキャッシュすることもできる。

様々な市販のオペレーティングシステムまたはオペレーティングシステムの組合せによって、本発明を実施し得ることを理解されたい。

ユーザは、キーボード１１３８、およびマウス１１４０などのポインティングデバイスを介してコンピュータ１１０２にコマンドおよび情報を入力することができる。（図示しない）他の入力装置は、マイクロホン、ＩＲリモートコントロール、ジョイスティック、ゲームパッド、衛星パラボラアンテナ、スキャナなどを含み得る。上記その他の入力装置は、システムバス１１０８に結合されたシリアルポートインターフェース１１４２を介して処理装置１１０４に接続されることが多いが、パラレルポート、ゲームポート、または「ＵＳＢ」（ユニバーサルシリアルバス）、ＩＲインターフェースなど、他のインターフェースによって接続することができる。モニタ１１４４その他のタイプのディスプレイ装置も、ビデオアダプタ１１４６などのインターフェースを介してシステムバス１１０８に接続される。コンピュータは一般に、モニタ１１４４に加えて、スピーカ、プリンタなどの（図示しない）他の周辺出力装置も含む。

コンピュータ１１０２は、１つ（または複数）のリモートコンピュータ１１４８など、１つまたは複数のリモートコンピュータへの有線および／または無線による通信を介した論理接続部を利用するネットワーク環境で動作し得る。１つ（または複数）のリモートコンピュータ１１４８は、ワークステーション、サーバコンピュータ、ルータ、パーソナルコンピュータ、ポータブルコンピュータ、マイクロプロセッサベースの娯楽機器、ピアデバイス（ｐｅｅｒ ｄｅｖｉｃｅ）その他一般のネットワークノードとすることができ、一般に、コンピュータ１１０２に関連して上記で説明した要素の多くまたはすべてを含むが、簡単にするために図にはメモリ記憶装置１１５０だけを示す。図に示す論理接続部は、ＬＡＮ（ローカルエリアネットワーク）１１５２およびＷＡＮ（ワイドエリアネットワーク）１１５４を含む。このようなネットワーク環境は、一般事務所、企業規模のコンピュータネットワーク、イントラネット、およびインターネットで一般的なものである。

ＬＡＮネットワーク環境で用いられるとき、コンピュータ１１０２は、有線または無線による通信ネットワークインターフェースまたはアダプタ１１５６を介してローカルネットワーク１１５２に接続される。アダプタ１１５６により、ＬＡＮ １１５２への有線または無線による通信が容易になり得る。ＬＡＮ １１５２は、無線アダプタ１１５６と通信するためにＬＡＮ １１５２上に配設された無線アクセスポイントも含み得る。ＷＡＮネットワーク環境で用いられるとき、コンピュータ１１０２は一般に、モデム１１５８を含むか、または、ＬＡＮ上の通信サーバに接続されるか、あるいは、インターネットなどのＷＡＮ１１５４を介して通信を確立するための他の手段を有する。内蔵型または外付け、および有線または無線による装置とし得るモデム１１５８は、シリアルポートインターフェース１１４２を介してシステムバス１１０８に接続される。ネットワーク環境では、コンピュータ１１０２に関連して示すプログラムモジュールまたはその一部は、リモートメモリ記憶装置１１５０に格納することができる。図に示すネットワーク接続部は例であり、コンピュータ間で通信リンクを確立する他の手段を使用し得ることを理解されたい。

コンピュータ１１０２は、任意の無線装置、または無線通信の形で動作可能に配設されたエンティティ、例えば、プリンタ、スキャナ、デスクトップ型および／またはポータブル型のコンピュータ、ポータブルデータ端末、無線により検出可能なタグに関連する任意の機器または場所（例えば、キオスク、新聞・雑誌販売所、休憩室）、ならびに電話と通信するように動作可能である。これは、少なくともＷｉ−ＦｉおよびＢｌｕｅｔｏｏｔｈ（登録商標）による無線技術を含む。このように、通信は、従来方式のネットワークの場合と同様に所定の構造とすることもできるし、あるいは、単に少なくとも２つの装置間のその場限りの通信とすることもできる。

Ｗｉ−Ｆｉすなわちワイヤレスフィデリティ（Ｗｉｒｅｌｅｓｓ Ｆｉｄｅｌｉｔｙ）により、自宅のソファから、またはホテルの部屋のベッドから、あるいは仕事での会議室から、電線なしにインターネットに接続することができる。Ｗｉ−Ｆｉは携帯電話のような無線技術であり、それによって、基地局の範囲内であればどこでも、例えばコンピュータなどの装置が屋内外でデータの送受信を行うことができる。Ｗｉ−Ｆｉネットワークは、安全で、信頼性が高く、高速な無線接続性を提供するＩＥＥＥ８０２．１１（ａ、ｂ、ｇなど）と呼ぶ高周波技術を利用する。Ｗｉ−Ｆｉネットワークを使用して、コンピュータの相互接続、インターネットへの接続、（ＩＥＥＥ８０２．３すなわちイーサネット（登録商標）を使用する）有線ネットワークへの接続が可能である。Ｗｉ−Ｆｉネットワークは、無認可の２．４ＧＨｚおよび５ＧＨｚの高周波帯域で、１１Ｍｂｐｓ（８０２．１１ｂ）または５４Ｍｂｐｓ（８０２．１１ａ）のデータレートで、あるいは、両方の帯域を含む（デュアルバンド）製品で動作し、そのため、これらのネットワークは、多くの一般事務所で使用されている基本１０ＢａｓｅＴ有線イーサネット（登録商標）ネットワークに類似の現実のパフォーマンスを提供し得る。

次に図１２を参照すると、本発明によるコンピューティング環境の例１２００の概略ブロック図が示されている。システム１２００は、１つまたは複数のクライアント１２０２を含む。１つ（または複数）のクライアント１２０２は、ハードウェアおよび／またはソフトウェア（例えば、スレッド、プロセス、コンピューティング装置）とし得る。１つ（または複数）のクライアント１２０２は、例えば、本発明を利用することによって、１つ（または複数）のクッキーおよび／または関連するコンテキスト情報を収容し得る。システム１２００は、１つまたは複数のサーバ１２０４も含む。１つ（または複数）のサーバ１２０４も、ハードウェアおよび／またはソフトウェア（例えば、スレッド、プロセス、コンピューティング装置）とし得る。サーバ１２０４は、例えば、本発明を利用することによって、変換を実施するためのスレッドを収容し得る。クライアント１２０２とサーバ１２０４の間の１つの可能な通信は、２つ以上のコンピュータプロセス間で送信されるように適合されたデータパケットの形態を取り得る。このデータパケットは、例えば、クッキーおよび／または関連するコンテキスト情報を含み得る。システム１２００は、１つ（または複数）のクライアント１２０２と１つ（または複数）のサーバ１２０４の間の通信をうまく進めるために使用し得る通信フレームワーク１２０６（例えば、インターネットなどのグローバル通信ネットワーク）を含む。

通信は、（光ファイバを含めて）有線および／または無線技術によってうまく進めることができる。１つ（または複数）のクライアント１２０２は、１つ（または複数）のクライアント１２０２に局在する情報（例えば、１つ（または複数）のクッキーおよび／または関連するコンテキスト情報）を記憶するのに使用し得る１つまたは複数のクライアントデータ記憶部１２０８に動作可能に接続される。同様に、１つ（または複数）のサーバ１２０４は、サーバ１２０４に局在する情報を記憶するのに使用し得る１つまたは複数のサーバデータ記憶部１２１０に動作可能に接続される。

以上説明してきたことには、本発明の実施例が含まれる。当然のことながら、本発明を説明するためにコンポーネントまたは方法の考え得るすべての組合せを説明することは不可能であり、本発明の多くの別の組合せおよび並替えが可能であることが当業者には理解されよう。したがって、本発明は、添付の特許請求の範囲の趣旨および範囲に含まれるすべてのこのような改変形態、修正形態、および変形形態を包含することを意図している。さらに、「含む」という用語を詳細な説明または特許請求の範囲において使用する限りにおいては、このような用語は、「備える」という用語が特許請求の範囲において用いられる際には暫定的な言葉として解釈されるように、「備える」と同様に包括的であることが意図されている。

本発明のコンポーネントのブロック図である。 ルール監視プロセスの流れ図である。 本発明によるルールのインスタンス化の流れ図である。 ルール間の呼出しについてのプロセスの流れ図である。 本発明によるルールエンジンを使用する、モデルに基づく管理アーキテクチャを示す図である。 モデルに基づく管理アーキテクチャの主要コンポーネントを記述することに関係する図面マップを示す図である。 モデルに基づく管理アーキテクチャのモデルコンポーネントに関係するブロックを示す図である。 モデルに基づく管理アーキテクチャのマニフェストコンポーネントに関係するブロックを示す図である。 モデルに基づく管理アーキテクチャに従ってアプリケーションまたはサービスを管理するのに使用するシステムコンポーネントのコアシステムＡＰＩのブロック図である。 モデルに基づく管理アーキテクチャのシステムコンポーネントの管理に関連するＡＰＩのブロック図である。 モデルに基づく管理アーキテクチャのタスクコンポーネントの主要サブコンポーネントを示す図である。 モデルに基づく管理のプロセスの流れ図である。 モデルに基づく管理を実施するプロセスのより詳細な流れ図である。 モデルに基づく管理の所望の状態を実施するプロセスの流れ図である。 本発明によるアーキテキチャを実行するように動作可能なコンピュータのブロック図である。 本発明によるコンピューティング環境の例の概略ブロック図である。

Claims (40)

1. ルールの処理をうまく進めるシステムであって、同期プログラミングモデルを用いて同期ステートメントを非同期命令に翻訳する翻訳コンポーネントを備えることを特徴とするシステム。
2. 前記ステートメントは、一連のルールタイプに編成されることを特徴とする請求項１に記載のシステム。
3. 前記ルールタイプは、ターゲットリソースの所望の状態を判定するロジックを表現することを特徴とする請求項２に記載のシステム。
4. 所望の状態に応答して処置を講じることを特徴とする請求項３に記載のシステム。
5. 前記翻訳コンポーネントは、前記非同期命令のインスタンス化をうまく進めることを特徴とする請求項１に記載のシステム。
6. 前記命令は、ランタイムエンジンによる同時処理をうまく進めることを特徴とする請求項１に記載のシステム。
7. 前記命令は、前記ランタイムエンジンがすべての状態を維持することをうまく進め、前記状態は、引数および局所変数の少なくとも１つを含むことを特徴とする請求項６に記載のシステム。
8. 前記命令は、ランタイムルールコード実行切替えに優先権を渡すことと、ユーティリティ関数をコールすることの少なくとも１つをうまく進めることを特徴とする請求項１に記載のシステム。
9. 前記命令は、周期的なｙｉｅｌｄ文を挿入することを特徴とする請求項１に記載のシステム。
10. 前記翻訳コンポーネントは、ラベルおよび一時変数の少なくとも１つが、対応するノードについて生成されるように、深さ優先トラバースをうまく進めることを特徴とする請求項１に記載のシステム。
11. 前記翻訳コンポーネントは、前記ルールのモジュールをクラスに翻訳することを特徴とする請求項１に記載のシステム。
12. 前記命令は、ランタイムエンジンによるコンテキスト切替えをうまく進めるためのアドレスコード表現を含むことを特徴とする請求項１に記載のシステム。
13. 前記アドレスコード表現は、少なくとも３つのアドレスコードを用い、前記表現は、ステートメントまたは式が非同期コールを含むときに用いられることを特徴とする請求項１２に記載のシステム。
14. 前記命令は、一連の命令ブロックに翻訳され、前記命令ブロックは、ｓｗｉｔｃｈ−ｃａｓｅブロックに分けられることを特徴とする請求項１に記載のシステム。
15. 前記命令ブロック内の命令は、ユニットとして実行され、前記命令ブロック間でのみランタイム実行に優先権を渡すことを特徴とする請求項１４に記載のシステム。
16. 前記一連の命令ブロックは、それに関連する更新識別子を有し、前記更新識別子は、前記ルールへの再エントリ後、前記一連の命令ブロックのどれを次に実行するかを維持することを特徴とする請求項１４に記載のシステム。
17. ルールの同時処理をうまく進めるシステムであって、
    同時処理を行うために前記ルールを命令に翻訳する翻訳コンポーネントと、
    処理を行うための前記命令をスケジュールし、前記スケジュールに従って前記命令の一部または全部を同時処理するランタイムエンジンと
    を備えることを特徴とするシステム。
18. 前記ランタイムエンジンは、前記ルールの暗示的な同時処理をうまく進めることを特徴とする請求項１７に記載のシステム。
19. 前記ランタイムエンジンは、前記命令および構成データをともに受け取り、前記構成データは、どのルールを実行するかと、前記ルールを実行するのに必要とされるパラメータの少なくとも１つを指定することを特徴とする請求項１７に記載のシステム。
20. モデルに基づく管理アーキテキチャにおいてルールの処理をうまく進めるシステムであって、
    前記アーキテキチャについての健全性基準を表す複数のルールと、
    同時処理を行うために前記ルールを非同期命令に翻訳する翻訳コンポーネントと、
    処理を行うための前記翻訳された命令をスケジュールし、前記スケジュールに従って前記命令の一部または全部を同時処理するランタイムエンジンと
    を備えることを特徴とするシステム。
21. 前記ランタイムエンジンは、コードの処理を一時停止する前記命令の１つに従って動作し、イベントが発生するのを待ち、前記コードの処理は、前記イベントに応答して再開され、前記イベントに対して動作し得ることを特徴とする請求項２０に記載のシステム。
22. 前記複数のルールの１つは、別のルールを呼び出すことを特徴とする請求項２０に記載のシステム。
23. 前記エンジンは、現在のフレームについてのポーリング構造に基づいて、かつ前記ポーリング構造が実行スタックの最上部にある場合に、前記実行スタックの実行をスケジュールすることを特徴とする請求項２０に記載のシステム。
24. 前記命令コンポーネントは、ループ処理をうまく進める言語を含み、それによって、飛越し処理の前に、ルールは、ノンプリエンプティブスケジューリングをうまく進めるために前記ランタイムエンジンに戻ることを特徴とする請求項２０に記載のシステム。
25. 前記翻訳された命令は、関数の実行状態が保存され、後で構成されるように、協調マルチタスク処理をうまく進めることを特徴とする請求項２０に記載のシステム。
26. 前記命令は、コールフレームの構築をうまく進め、前記コールフレームは、関数パラメータ、現在の命令ブロック、現在の関数、および局所変数の少なくとも１つを含むことを特徴とする請求項２０に記載のシステム。
27. 前記ランタイムエンジンは、過利用率が減少するように、任意の時点から始まる持続時間全体にわたってタスクの実行を分散させる分散アルゴリズムを含むことを特徴とする請求項２０に記載のシステム。
28. 請求項２０に記載のシステムであることを特徴とするコンピュータシステム。
29. ルールを処理する方法であって、
    複数の前記ルールを受け取ること、
    前記ルールを命令に翻訳して、ランタイムエンジンに送ること、
    前記ランタイムエンジンによって処理するために、前記翻訳された命令のスケジュールすること、
    前記ランタイムエンジンによって前記複数の命令の少なくとも２つを同時に処理すること、および
    前記ランタイムエンジンに構成データを受け入れて、前記ルールをインスタンス化すること
    を含むことを特徴とする方法。
30. 前記ルールにｙｉｅｌｄ命令を挿入して、前記ランタイムエンジンによる処理中に、前記ルール間のコード実行切替えの優先権を渡す実行をうまく進め、前記ランタイムエンジンによって提供されるユーティリティ関数のコールをうまく進めることをさらに含むことを特徴とする請求項２９に記載の方法。
31. 前記翻訳された命令は、一連の命令ブロックに翻訳され、前記ランタイムエンジンに優先権が渡される前に、前記命令ブロックの実行を開始することにより、前記命令ブロック全体が実行されることを特徴とする請求項２９に記載の方法。
32. 起動プロセス中に、起動時に前記ランタイムエンジンによって実行されるようにマーキングしたルールのタスク一覧を形成すること、および前記ルールの開始をバッチの形で分散させ、それによって、ルールの各バッチは、時間により構成された時間間隔内で処理されるようにスケジュールされることをさらに含むことを特徴とする請求項２９に記載の方法。
33. 所定の基準に基づいて前記時間間隔を構成することをさらに含み、前記基準は、前記コンピュータが使用するプロセッサの数を含むことを特徴とする請求項３２に記載の方法。
34. 前記命令は、前記ランタイムエンジンによってバッチで処理されるようにスケジュールされ、その結果、バッチのルールは、前記バッチを処理するための関連する時間間隔全体にわたって均一に処理されるようにスケジュールされることを特徴とする請求項２９に記載の方法。
35. ポーリング構造に基づいて、処理するための前記翻訳された命令をスケジュールすることをさらに含み、前記処理は、現在のフレームの前記ポーリング構造およびスタックの最上部の前記ポーリング構造の少なくとも１つに対して行われることを特徴とする請求項２９に記載の方法。
36. ノンプリエンプティブスケジューリング方式に従ってスケジューリングが実施されることを特徴とする請求項２９に記載の方法。
37. ルールを処理するシステムであって、
    複数の前記ルールを受け取る手段と、
    前記ルールを命令に変換する手段と、
    ランタイムエンジンによって処理するために、前記命令を翻訳する手段と、
    前記複数の命令の少なくとも２つをスケジュールし、同時に処理する手段と
    を備えることを特徴とするシステム。
38. 変換する前記手段は、前記ルールに、関連する前記翻訳された命令の制御を、その実行中にどこで放棄するかを決定する制御放棄コードを挿入する手段を含み、前記放棄コードは、パラメータ、局所変数、および再エントリ後に前記翻訳された命令内のどこに飛び越すかの少なくとも１つを含むスタックフレームに関連することを特徴とする請求項３７に記載のシステム。
39. ルール間でタスクを切り替える手段をさらに備え、前記翻訳された命令は、タスク切替えをうまく進めるためのコールフレームを含むことを特徴とする請求項３７に記載のシステム。
40. ルールの同時処理を実施するためのコンピュータにより実行可能な命令を有するコンピュータ可読メディアであって、同期プログラミングモデルを用いて同期ルールステートメントを非同期命令に翻訳する翻訳コンポーネントを備え、前記命令は、ユーティリティ関数をコールすることと、ランタイムコード切替えに優先権を渡すこととをうまく進めることを特徴とするコンピュータ可読メディア。
    

Images