JP2009510635A - テンプレートベースのサービス管理 - Google Patents

Abstract

本発明の１つの実施形態は、所与のサービスタイプのある特定の特徴を定義するテンプレートを使用する。上記の特徴はそのサービスタイプのサービス全体に共通である。テンプレートをユーザが構成して、所与のサービスに対するサービス定義を得ることができる。サービス定義をプログラマビリティ層に渡し、ユーザがさらにカスタマイズすることなく所与のサービスを監視するために必要な様々なモニタ、ルール、クラスおよびタスクをプログラマビリティ層が構築可能であるのに十分な情報を与える。１つの実施形態では、ユーザはサービス定義を望ましいようにカスタマイズして、更なるモニタリングを得ることもできる。

Description

サービス（例えば、ソフトウェアアプリケーション、ハードウェアデバイス、ウェブサービス、データベースアプリケーション、ウェブページ、ウェブサイト、等）をモニタリングシステムにより監視することは現在、非常に一般的である。

モニタリングシステムは多種多様の形態を取り、多種多様のものを監視する。例えば、いくつかのモニタリングシステムはサービスの状態を監視する。上記のサービス状態には例えば、サービスが実行中かどうか、サービスが停止しているかどうか、または異常終了したかどうかがある。他のモニタリングシステムはサービスの健全性をある特定の性能基準で監視する。例えば、いくつかのモニタはサービスが使用しているメモリ量またはサービスが使用しているプロセッサ容量、または他の同様な基準を監視する。

この種のサービス監視の実施にはサービスの構成要素、サービスの依存関係、およびサービスの振る舞いの知識が必要である。これらの構成要素の定義は複雑であり、サービス設計に関わった技術者または他の技術担当者しか理解できないことがよくある。

同様に、ビジネスが監視を期待する異種のサービスは複雑に発展しており、分散サービス、冗長なアーキテクチャおよび多層アーキテクチャを含む。これらの要因が、この種のサービス監視を構成する作業を益々複雑にすることに寄与している。

同様に、ビジネスアプリケーションおよびビジネスソリューションが現在広く展開されている。しかしながら、上記ソリューションは一意であるか、またはそれらを使用する様々なユーザにカスタマイズされている可能性がある。従って、現行のシステムは、カスタムモニタリングロジックを構築しなければ上記ソリューションを監視できない。所与のサービスを効率的に監視するためには、多数のハイレベルな問題を解決しなければならないことがよくある。（解決する必要があるかまたは解決する必要がない）これらの問題のいくつかの例は以下の通りである。
サービスはどのように見えるか？
サービスはどの構成要素から構成され、そのサービスの構成要素はどのように相互作用するか？
問題のサービスはどの情報基盤サービスに依存するか？
サービスをネットワークにどのように展開すればよいか？
所与のサービスの２つの展開をどのように区別するか？
ユーザが関心のあるサービス属性は何か？
サービスに関して収集すべき計測データは何か？
サービス管理者にとって有用であるために、データをどのようにフォーマットおよび表示すべきか？
ユーザがサービス上で実施する共通作業は何か？
サービスが設計通りに実施されているかどうかを管理者はどのように知るか？
サービスの動作能力に影響を及ぼしうる問題は何か？
上記問題をどのように検出し、もっと改善し防止できるか？
前記問題を診断するために収集すべきデータは何か？
上記問題に応じて実施可能な是正措置はあるか？
起こり得る問題をいつ管理者に通知すべきか？
起こり得る問題を理解およびトラブルシュートするためのコンテクストとして、何を管理者に提供すべきか？

これらは一般的なハイレベルな問題のほんの一部であり、これらを使用して所与のサービスに対する監視ソリューションの設計を導くことができる。これら門題の各々は別レベルの細目の原因となる可能性があり、その中で更なる問題を解決しなければならないことにも留意されたい。モニタリングシステムが動作可能なように十分に事細かくこれらの問題を解決することに関わる複雑性は、そのソリューションのユーザ（またはそのソリューションの管理者）が把捉可能な複雑性を超えることがよくある。

従って、企業は、自身のカスタマイズしたビジネスソリューションを十分に監視する際に困難に直面する。その作業は外注を要する場合があり、その場合はコストが増加し、統合が困難である可能性がある。

上記議論は一般的な背景情報のために与えたに過ぎず、クレーム主題の範囲を決定する支援として用いることは意図していない。

本発明の１つの実施形態は、所与のサービスタイプのある特定のモニタリング特性を定義するテンプレートを使用し、前記特性は前記サービスタイプのサービス全てに共通である。テンプレートをユーザが構成して、所与のサービスに対するサービス定義を得ることができる。サービス定義をプログラマビリティ層に渡し、ユーザが更にカスタマイズせずに所与のサービスを監視するために必要な様々なモニタ、規則、クラス、ビューおよびタスクをプログラマビリティ層が構築可能とするのに十分な情報を与える。１つの実施形態では、ユーザは望ましいようにサービス定義をカスタマイズして更なるモニタリングを得ることもできる。

本要約は、選択した概念を簡潔な形で導入するために与えた。これらの概念は以下の詳細な記載でさらに説明する。本要約はクレーム主題の主要な特徴または本質的な特徴を特定するようには意図しておらず、クレーム主題の範囲を決定するための支援として使用するようにも意図していない。

本発明は一般に、監視すべきサービスの記述を、テンプレートを用いて構成することに関する。しかしながら、本発明をより詳細に説明する前に、本発明を使用可能な１つの例示的な環境を説明する。

図１は、実施形態の実装に適したコンピューティングシステム環境の例１００を示す。コンピューティングシステム環境１００は適切なコンピューティング環境の１例に過ぎず、本発明の使用または機能の範囲に関する制限を示唆するようには意図していない。また、コンピューティング環境１００を、例示的な動作環境１００に示した構成要素の任意の１つまたは組合せに関する依存性または要件を有するとして解釈すべきでもない。

実施形態を、多数の他の汎用目的または特殊目的コンピューティングシステムの環境または構成で動作させることができる。様々な実施形態との使用に適した公知のコンピューティングシステム、環境、および／または構成の例は、パーソナルコンピュータ、サーバコンピュータ、ハンドヘルドまたはラップトップデバイス、マルチプロセッサシステム、マイクロプロセッサベースのシステム、セットトップボックス、プログラム消費家電、ネットワークＰＣ、ミニコンピュータ、メインフレームコンピュータ、テレフォニーシステム、上記のシステムまたはデバイスの任意を含む分散コンピューティング環境、等を含むがこれらに限らない。

実施形態を、プログラムモジュールのようなコンピュータにより実行されるコンピュータ実行可能命令の一般的なコンテクストで説明することができる。一般にプログラムモジュールには、特定のタスクを実施するかまたは特定の抽象データ型を実装するルーチン、プログラム、オブジェクト、コンポーネント、データ構造、等が含まれる。いくつかの実施形態は、通信ネットワークを通して接続したリモート処理装置によりタスクを実施する分散コンピューティング環境で実践されるように設計してある。分散コンピューティング環境ではプログラムモジュールを、メモリ記憶装置を含むローカルおよびリモートコンピュータ記憶媒体の両方に置く。

図１を参照する。いくつかの実施形態を実装する例示的なシステムには、コンピュータ１１０の形での汎用目的コンピューティング装置が含まれる。コンピュータ１１０の構成要素は、処理装置１２０、システムメモリ１３０、およびシステムメモリを含む様々なシステムコンポーネントを処理装置１２０に接続するシステムバス１２１を含むことができるがこれらに限らない。システムバス１２１は数種のバス構造のうち任意のものであることができる。上記のバスアーキテクチャには、メモリバスまたはメモリコントローラ、周辺バス、および様々なバス構造のうち任意のものを用いるローカルバスが含まれる。限定ではなく例として、上記アーキテクチャには業界標準アーキテクチャ（ｌＳＡ）バス、マイクロチャネルアーキテクチャ（ＭＣＡ）バス、拡張ＩＳＡ（ＥＩＳＡ）バス、ビデオ電子標準協会（ＶＥＳＡ）ローカルバス、およびメザニンバスとしても知られる周辺機器相互接続（ＰＣＩ）バスが含まれる。

コンピュータ１１０には一般に様々なコンピュータ読取可能媒体が含まれる。コンピュータ読取可能媒体は、コンピュータ１１０がアクセス可能な任意の有効な媒体であることができ、揮発性および不揮発性媒体、取り外し可能および固定媒体の両方を含む。限定ではなく例として、コンピュータ読取可能媒体はコンピュータ記憶媒体および通信媒体を備えることができる。コンピュータ記憶媒体には、コンピュータ読取可能命令、データ構造、プログラムモジュールまたは他のデータのような情報を記憶するための任意の方法または技術で実装した揮発性および不揮発性媒体、取り外し可能および固定媒体の両方が含まれる。コンピュータ記憶媒体はＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリまたは他のメモリ技術、ＣＤ−ＲＯＭ、デジタル多用途ディスク（ＤＶＤ）または他の光学ディスク記憶、磁気カセット、磁気テープ、磁気ディスク記憶または磁気記憶装置、あるいは所望の情報の記憶に使用可能でかつコンピュータ１１０がアクセス可能な任意の他の媒体を含むがこれらに限らない。通信媒体は一般にコンピュータ読取可能命令、データ構造、プログラムモジュールまたは他のデータを搬送波または他の伝送媒体のような変調データ信号で具体化し、任意の情報配信媒体を含む。用語“変調データ信号”は１つまたは複数の特性集合を有するかまたは情報を信号内に符号化するよう変化した信号を意味する。限定ではなく例として、通信媒体には、有線ネットワークまたは直接配線通信のような有線媒体、および音響、ＲＦ、赤外線および他の無線媒体のような無線媒体が含まれる。上記の任意の組合せも、コンピュータ読取可能媒体に含まれるべきである。

システムメモリ１３０には、読取専用メモリ（ＲＯＭ）１３１およびランダムアクセスメモリ（ＲＡＭ）１３２のような揮発性および／または不揮発性メモリの形でのコンピュータ記憶媒体が含まれる。基本入出力システム１３３（ＢＩＯＳ）は、例えば起動時にコンピュータ１１０内の要素間での情報転送を支援する基本ルーチンを含み、一般にＲＯＭ１３１に記憶される。ＲＡＭ１３２は一般に、処理装置１２０に直接アクセス可能および／または処理装置１２０上で動作するデータおよび／またはプログラムモジュールを含む。限定ではなく例として、図１はオペレーティングシステム１３４、アプリケーションプログラム１３５、他のプログラムモジュール１３６、およびプログラムデータ１３７を示す。

コンピュータ１１０は、他の取り外し可能／固定、揮発性／不揮発性コンピュータ記憶媒体を含むこともできる。例としてのみ、図１は、固定、不揮発性磁気媒体を読み書きするハードディスクドライブ１４１、取り外し可能、不揮発性磁気ディスク１５２を読み書きする磁気ドライブ１５１、およびＣＤ ＲＯＭまたは他の光媒体のような取り外し可能、不揮発性光ディスク１５６を読み書きする光ディスクドライブ１５５を示す。例示的な動作環境で使用可能な他の取り外し可能／固定、揮発性／不揮発性コンピュータ記憶媒体は、磁気テープカセット、フラッシュメモリカード、デジタル多用途ディスク、デジタルビデオテープ、固体ＲＡＭ、固体ＲＯＭ、等を含むがこれらに限らない。ハードディスクドライブ１４１は一般に、インタフェース１４０のような固定メモリインタフェースを通してシステムバス１２１に接続され、磁気ディスクドライブ１５１および光ディスクドライブ１５５は一般に、インタフェース１５０のような取り外し可能メモリインタフェースによりシステムバス１２１に接続される。

図１で上述および示したドライブとその関連コンピュータ記憶媒体は、コンピュータ読取可能命令、データ構造、プログラムモジュールおよびコンピュータ１１０に関する他のデータを記憶する。例えば図１において、ハードディスクドライブ１４１をオペレーティングシステム１４４、アプリケーションプログラム１４５、他のプログラムモジュール１４６、およびプログラムデータ１４７を記憶するとして示す。これらのコンポーネントは、オペレーティングシステム１３４、アプリケーションプログラム１３５、他のプログラムモジュール１３６、およびプログラムデータ１３７と同一であるかまたは異なるかのいずれかでありうることに留意されたい。オペレーティングシステム１４４、アプリケーションプログラム１４５、他のプログラムモジュール１４６、およびプログラムデータ１４７にはここでは異なる数字を与え、少なくともそれらが異なるコピーであることを示す。

ユーザはコマンドおよび情報を、入力装置を通してコンピュータ１１０に入力することができる。入力装置には例えば、キーボード１６２、マイクロフォン１６３、およびマウス、トラックボールまたはタッチパッドのようなポインティングデバイス１６１がある。他の入力装置（示さず）はジョイスティック、ゲームパッド、パラボラアンテナ、スキャナ、等を含むことができる。これらおよび他の入力装置を、システムバスに接続したユーザ入力インタフェース１６０を通して処理装置１２０に接続することがよくあるが、パラレルポート、ゲームポートまたはユニバーサルシリアルバス（ＵＳＢ）のような他のインタフェースおよびバス構造により接続してもよい。モニタ１９１または他種の表示装置も、ビデオインタフェース１９０のようなインタフェース経由でシステムバス１２１に接続する。モニタに加えて、コンピュータはスピーカ１９７およびプリンタ１９６のような他の周辺出力装置を含むこともできる。前記周辺出力装置を、出力周辺インタフェース１９５を通して接続することができる。

コンピュータ１１０は、リモートコンピュータ１８０のような１つまたは複数のリモートコンピュータに対する論理接続を用いてネットワーク環境で動作する。リモートコンピュータ１８０はパーソナルコンピュータ、ハンドヘルドデバイス、サーバ、ルータ、ネットワークＰＣ，ピアデバイスまたは他の共通ネットワークノードであることができ、一般にコンピュータ１１０に関して上述した要素の多数または全てが含まれる。図１に示す論理接続には、ローカルエリアネットワーク（ＬＡＮ）１７１および広域ネットワーク（ＷＡＮ）１７３が含まれるが、他のネットワークを含んでもよい。上記ネットワーク環境は職場、企業規模のコンピュータネットワーク、イントラネットまたはインターネットで一般的である。

ＬＡＮネットワーク環境で使用するとき、ネットワークインタフェースまたはアダプタ
１７０を通してコンピュータ１１０をＬＡＮ１７１に接続する。ＷＡＮネットワーク環境で使用するとき、コンピュータ１１０は一般にモデム１７２および、インターネットのようなＷＡＮ１７３上で通信を確立するための他の手段を含む。モデム１７２は、内部または外部にあることができ、ユーザ入力インタフェース１６０、または他の適切なメカニズムを通してシステムバス１２１に接続することができる。ネットワーク環境では、コンピュータ１１０に対して示したプログラムモジュール、またはその一部をリモートメモリ記憶装置に記憶することができる。限定ではなく例として、図１はリモートアプリケーションプログラム１８５がリモートコンピュータ１８０上にあるとして示してある。示したネットワーク接続は例であって、コンピュータ間の通信リンクを確立する他の手段を使用できることは当然理解されるであろう。

図２は、１つの実施形態に従うテンプレートフレームワーク２００のブロック図である。テンプレートフレームワーク２００にはモニタリングコンフィギュレーションウィザード２０２とモニタリングシステムプログラマビリティ層２０４が含まれる。ウィザード２０２を、テンプレート２０８および２１０にアクセスするとして示す。テンプレート２０８および２１０の各々は、それぞれ異なるサービスタイプのサービスからの共通特性２１２および２１４より生成する。テンプレート２０８を、第１のサービスタイプ（集合的に数字２１６で参照する）のサービスからの特性２１２に基づくとして示してあり、テンプレート２１０は第２のサービスタイプ（集合的に数字２１８で参照する）のサービスからの特性２１４に基づくとして示してある。

コンフィギュレーションウィザード２０２は、コンフィギュレーション情報２２６をユーザ２２４から受信し、Ｕｌアセンブリ２０９にアクセスするとして示してある。Ｕｌアセンブリ２０９は、テンプレート２０８および２１０に対応するＵＩディスプレイである。以下でさらに詳細に説明するように、コンフィギュレーションウィザード２０２はサービス定義２２８を、（ユーザが選択した）選択テンプレート２０８または２１０から、およびユーザが与えたコンフィギュレーション情報２２６に基づいて生成する。

モニタリングシステムプログラマビリティ層２０４は、サービス定義２２８を受信し、利用可能なモニタリングロジック２２０にアクセスするとして示してある。サービス定義２２８に基づいて、プログラマビリティ層２０４は、所与のサービスを監視するよう展開したモニタリングロジック２２２を生成する。

図３Ａは、図２に示したフレームワーク２００の動作をさらに詳細に示すフロー図である。先ず、フレームワーク２００の動作を議論する前に、テンプレート２１２および２１４を議論する。監視するサービスをサービスタイプのグループにグループ化することでテンプレートの各々を導出する。第１のタイプのサービスを数字２１６で示し、第２のタイプのサービスを数字２１８で示す。前記サービスの各々は共通のモニタリング特性を有する。例えば、第１のタイプのサービス２１６は共通のモニタリング特性２１２を有し、第２のタイプのサービス２１８は共通のモニタリング特性２１４を有する。テンプレート２０８を、第１のタイプ２１６のサービスの特性２１２における共通的なモニタリングに基づいて生成する。テンプレート２１０を、第２のタイプ２１８のサービスの共通的なモニタリング特性２１４から生成する。

多種多様の手段を用いてサービスグループの共通特性を得ることができる。１つの手段の例として、サービスグループに対して型継承を用いることがある。例えば、図３Ｃは、特定のオペレーティングシステムサービス４００に対する型継承を示す。サービス４００は、型継承によって理解できるような、オペレーティングシステム（ＯＳ）ローカルアプリケーション４０２である。ＯＳローカルアプリケーション４０２はシステムローカルアプリケーション４０４であり、それ自身、システムアプリケーション４０６である。システムアプリケーション４０６はシステムのＭａｎａｇｅｄＥｎｔｉｔｙ４０８である。このように、図３Ｃは、特定のＯＳサービス４００が一連のモニタリングコンフィギュレーション特性４１０を有することを示す。従って、１つの実施形態では、様々なテンプレート２０８および２１０の各々は関連する共通的なモニタリング特性集合を有する。前記集合は、テンプレートが表すサービスタイプに対する型継承により得ることができる。

以上の理由で、所与のサービスに対するモニタリングロジックを生成および展開するため、ユーザ２２４は最初に入力を与えてモニタリングコンフィギュレーションウィザード２０２を開く。これを図３Ａのブロック３００で示す。コンフィギュレーションウィザード２０２を開くと、コンフィギュレーションウィザード２０２は、ユーザがコンフィギュレーションウィザードを用いてモニタリングを構成するためのユーザインタフェースディスプレイを生成する。

ユーザインタフェースディスプレイの１つの例示的なセットを図３Ｂにより示す。コンフィギュレーションウィザード２０２を最初に開くと、コンフィギュレーションウィザード２０２は図３Ｂに示すディスプレイ３５０のような静的なウェルカムディスプレイを具体的に生成することができる。静的なディスプレイはウェルカムメッセージを具体的に表示することができ、ディスプレイ２５０の底部に沿って位置する“次へ”ボタンのような、ユーザにより動作可能な要素を与えてユーザに次の画面へ進ませることができることが分かる。静的ディスプレイは、どのテンプレートをコンフィギュレーションウィザード２０２で構成可能であるかに関わらず変化しないので、静的である。

ユーザは、次いで、図３Ｂのブロック３５２で示すようなテンプレート選択画面に進む。理解できるように、ブロック３５２は利用可能なテンプレートのリストを与える。前記リストは、所与のサービスに対するモニタリングを構成するためのサービス定義を生成する開始点の役割を果たす。ＵＩディスプレイ３５２に示すテンプレートのリストには、オペレーティングシステムサービス、ｃｏｍ＋アプリケーション、多数のアプリケーション、ウェブサイト、ウェブサービス、ウェブアプリケーション、データベースアプリケーションおよび分散アプリケーションに対応するテンプレートが含まれる。ディスプレイ３５２に表示した様々なテンプレートは、ユーザが選択できる利用可能なテンプレート２０８−２１０（図２）を表す。ディスプレイ３５２におけるテンプレートは、代表的なテンプレートリストのみを表し、他のものも同様に与えることができる。

ユーザは、ユーザインタフェースディスプレイ３５２上にあるもののような、ユーザに対して表示したモニタリングテンプレートの１つを単純に選択する。モニタリングテンプレートの選択を、図３Ａのブロック３０２で示す。これは、例えば所望のテンプレートを強調表示して「次へ」をクリックするか、または選択したテンプレート上をダブルクリックする等により、多様な方法で行うことができる。

ユーザがモニタリングテンプレートを選択すると、モニタリングコンフィギュレーションウィザード２０２はＵＩアセンブリ２０９にアクセスして、選択したテンプレートに対応するアセンブリ内のＵＩページセットを得る。ＵＩページセット内のＵＩページを（図３Ｂに示す）コンフィギュレーション画面３５４として表示し、ユーザにコンフィギュレーション情報２２６を入力可能とする。コンフィギュレーション情報２２６を使用して、選択したテンプレートにより表したモニタリング機能をさらに構成する。例えば、テンプレートによりユーザは様々な異なるモニタリングオプションをオンまたはオフにすることができ、またはシステム性能基準に対して閾値レベルを設定することができる、等である。選択したテンプレートのユーザコンフィギュレーションに対してコンフィギュレーション画面を表示することを、図３Ａのブロック３０４で示す。

ユーザは、次いで、コンフィギュレーション情報２２６をコンフィギュレーションウィザード２０２に与え、ウィザード２０２はサービス定義２２８を生成する。これを図３Ａのブロック３０６で示す。

コンフィギュレーション画面３５４により例えば、ユーザはカスタマイズしたモニタリングを同様に追加することもできる。図３Ｄは健全性モデルの１つの例示的な実施形態を示す。前記健全性モデルをテンプレートにより表すことができ、コンフィギュレーション画面３５４を通してユーザにより構成しカスタマイズすることができる。この例示的なモデル３２０を説明し、本議論の残りをさらに理解する。

健全性モデル３２０には、例として、第１のモデル部３１５と第２のモデル部３３０が含まれる。第１のモデル部３１５は具体的に、選択したテンプレートにより予め定義され表されるモニタリング、およびコンフィギュレーション画面３５４を通してユーザにより構成されうるモニタリングである。第２のモデル部３３０は具体的に、コンフィギュレーション画面を通してユーザが入力したカスタマイズモニタコンフィギュレーションである。

第１のモデル部３１５には具体的に、複数のモニタ３２１−３２５が含まれる。それらの全ては異なるものを監視する。モデル３２０にはさらに、ロールアップモニタ３２６−３２９が含まれる。ロールアップモニタ３２６−３２９は低レベルモニタ３２１−３２５の結果をロールアップする。図３Ｄに示す実施形態では、モニタ３２１−３２５にはサービスチェックモニタ３２１が含まれる。サービスチェックモニタ３２１はサービスの状態（即ち、サービスが実行中かどうか、サービスが停止しているかどうか、または異常終了したかどうか）を単にチュックする。モニタには、依存サービスの状態を監視する依存サービスチェックモニタ３２２も含まれる。モニタ３２３−３２５は、プロセッサ、メモリ、およびハンドルの使用量をそれぞれ監視するリソース使用モニタである。これらモニタからの情報をロールアップモニタ３２６および３２７によりロールアップする。ロールアップモニタ３２６および３２７は、ルールを実装して状態情報を基本健全性サービスロールアップモニタ３２８に与える。前記ルールは、（モニタ３２１−３２５で監視した）基本的な監視基準または特性が所与の閾値を満足または超過したかどうかを示す。基本健全性サービスロールアップモニタ３２８は、ロールアップモニタ３２６および３２７からの入力に基づいて状態データをサービス健全性モニタ３２９に与える。

図３Ｄは、健全性サービスモデル３２０の第２のモデル部３３０にはカスタマイズ計測モニタコンフィギュレーションが含まれることも示す。モニタコンフィギュレーション３３０には、カスタマイズモニタ３３１および３３２の組が含まれる。上記の組は、高度健全性サービスモニタ３３３にロールアップされる高度な（基本的でない）特性または基準を監視する。カスタマイズモニタは、監視したサービスにおけるカスタマイズ計測値を監視することができる。例えば、モニタ３３１は具体的にイベントモニタであることができる。前記イベントモニタは、監視しているサービスの高度な健全性に影響するカスタマイズ計測イベントを監視する。同様に、数値データモニタ３３２は具体的に、監視した計測値により生成した任意の種類の数値データ（例えば、セキュリティ関連イベントの数）を監視することができる。モニタ３３１および３３２からのデータをモニタ３３３によりロールアップし、サービス健全性モニタ３２９に与える。サービス健全性モニタ３２９は、監視したサービスの全体的な健全性を示す出力を与える。１つの具体的な実施形態では、モデル部３３０内のカスタマイズした計測モニタリングコンフィギュレーションをユーザのコンフィギュレーション情報２２６により構成する。ユーザのコンフィギュレーション情報２２６は、選択したテンプレートに対応するコンフィギュレーション画面３５４を通して入力される。

いずれの場合でも、ユーザコンフィギュレーション情報２２６の全てをコンフィギュレーションウィザード２０２に入力すると、コンフィギュレーションウィザード２０２は図３のブロック３０６で示すようにサービス定義２２８を生成する。

コンフィギュレーションウィザード２０２は次いで具体的に、図３ＢのＵＩ画面３５６のような更なる画面をユーザに与えることができる。前記画面は、サービス定義２２８の名前、記述および位置の入力をユーザに求める。これにより、ユーザはサービス定義２２８を所与の位置で具体的に名前付け、記憶することができる。

最後に、コンフィギュレーションウィザード２０２は、（図３Ｂの）最終レビュー画面３５８を与えることができる。最終レビュー画面３５８によりユーザは、入力されたコンフィギュレーション情報の全て、および生成したサービス定義２２８の全てをレビューすることができる。勿論、多様な他のユーザインタフェース画面または別のユーザインタフェース画面を望ましいように与えることができる。

本出願の背景技術部で課した多数の問題を具体的に、ユーザが監視したいサービスタイプに対する型継承に基づいて、および従ってユーザが選択したテンプレートに基づいて、自動的に解決できることが分かる。

サービス定義を形成すると、モニタリングプログラマビリティ層２０４にそのサービス定義を渡す。プログラマビリティ層２０４は次いで利用可能なモニタリングロジック２２０にアクセスし、モニタ、ルール、タスク、ビュー、クラス、等を生成する。これらはサービス定義２２８により定義したサービスの監視に必要である。本情報を具体的に、層２０４がアクセス可能なデータ記憶に記憶する。これを図３Ａのブロック３０７で示す。

サービス定義２２８を生成してモニタリングロジックを作成すると、プログラマビリティ層２０４は探索を実施して、ユーザの環境において監視すべき全てのサービスを発見する。例えば、サービス定義２２８を生成すると、プログラマビリティ層２０４はユーザの環境内のそれぞれのマシンを検証して、マシンがモニタリングフレームワーク２００を実行しているかどうか、およびユーザが監視したい特定のサービスをマシンが有するかどうかを決定しなければならない。ユーザの環境は１つのマシン、イントラネットまたは他のマシンネットワークを含むことができ、サーバ、移勒体装置、ポータブルコンピュータ、ワイヤレスネットワーク上のコンピューティング装置、等も含むことができる。プログラマビリティ層２０４は従って、プログラマビリティ層２０４がサービス定義に関連するモニタリングロジックまたはポリシーを所与のマシンに適用する必要があるかどうかを判定する。

例えば、監視すべきサービスがアンチウイルスアプリケーションであると仮定する。また、マシンのユーザ環境内の所与のマシンがアンチウイルスアプリケーションをホストすると仮定する。その場合、プログラマビリティ層２０４はアンチウイルスアプリケーションをホストするマシンを識別し、サービス定義２２８に関連するモニタリングポリシーをそのマシンに適用する。これを、多様な方法で実現することができる。１つの実施形態では、プログラマビリティ層２０４は探索ルールを、モニタリングシステムにより監視されているユーザ環境内のマシンの各々に送信する。これらのマシンは採索ルールを受け取り、前記探索ルールを定期的に実行して、その特定のサービス（この場合、アンチウイルスアプリケーション）がそのマシン上に存在するかどうかを見る。サービスがそのマシン上に存在するとき、所望のサービス監視を実装できるように、サービス定義２２８で説明したようなそのサービスの監視に必要なモニタリングポリシーをそのマシンに与える。探索の実施を、図３Ａのブロック３０８で示す。

探索を実施して、監視すべきサービスを実行しているマシンを識別すると、プログラマビリティ層２０４は次いで、監視すべき個々のサービスインスタンスを識別してインスタンスの１つを別のインスタンスから区別する。換言すれば、マシンが同一サービスの２つのインスタンスを実行している場合、これらの２つのインスタンスを区別しなければならない。１つの実施形態では、これはユーザが選択したテンプレート内の識別情報を用いて実施する。テンプレートには具体的に、監視すべきサービスの各インスタンスを上手く識別する識別子またはキープロパティ（例えば、コンピュータ内部のサービス名、および複数コンピュータ実装に対するマシン名）が含まれる。これは例えばユーザが選択したテンプレートで実施されるであろう。個々のインスタンスを識別することは、図３Ａのブロック３１０で示す。

監視すべきサービスの位置と個々のインスタンスを識別すると、モニタリングシステムのプログラマビリティ層２０４は生成したモニタ、ルール、ビュー、等を、識別したマシンに展開してサービスを監視する。これを図３Ａのブロック３１２で示す。

展開したモニタリングロジック２２２は様々な出力を与えることができる。例えば、出力は、様々な方法で監視サービスの性能を示すビューであることができる。ビューは例えば、監視したサービスの性能を長時間に渡るメモリ使用量に関連して示すことができる。勿論、他の多種多様なビューを同様に使用することができる。同様に、展開したモニタリングロジック２２２はコレクションを生成することができる。コレクションは、収集、データベースへ記憶、および後にレポートされるべきイベントに関連するルールを実行することで得られる。例えば、モニタリングロジックがセキュリティ関連イベントを収集することが望ましい場合がある。ユーザは前記セキュリティ関連イベントのログを取ること、および後にそのレポートを生成することを望む。

モニタリングロジック２２２およびプログラマビリティ層２０４は、コンフィギュレーションウィザード２０２と関連してタスクを実施することもできる。例えばタスクにより、サービスが停止するとユーザはサービスを再開することができる。出力を与えることは、図３Ａのブロック３１４で示す。

プログラマビリティ層２０４は、テンプレートに対するプログラマビリティサポートも与える。例えば、プログラマビリティ層２０４により、テンプレートのコレクションを生成すること、テンプレートを列挙すること、テンプレートの識別子を取得すること、およびテンプレートを実行することによりテンプレートを管理することができる。

１つの実施形態では、それぞれのテンプレートはデフォルトのポリシーを有することに留意されたい。例えば、健全性モデルに適用したコンフィギュレーションはデフォルトで、デフォルトの閾値を含むことができる。換言すれば、健全性モデルのリソース利用部で、監視されているサービスによるメモリ使用量に関する閾値、プロセッサ使用量、等が存在することができる。これらの値のモニタはパフォーマンスカウンタであることができる。パフォーマンスカウンタが閾値を超過すると、モニタ内の状態情報が変化する。勿論、別の実施形態ではユーザはデフォルト値を同様に変更することができる。

図４は、本発明の１つの実施形態に従うテンプレートオーサリング環境５００のブロック図である。テンプレートオーサリング環境５００にはテンプレートオーサリングコンポーネント５０２が含まれる。テンプレートオーサリングコンポーネント５０２は作成者５１０から、ユーザインタフェースページセット５０６を含むアセンブリとともにテンプレート定義５０４を受け取る。テンプレートオーサリングコンポーネント５０２はテンプレートを生成して、それをアセンブリ５０６とともに、数字５１２で示すマネジメントパックのような配布メカニズムに挿入する。

図５は、配布メカニズムの生成における環境５００の動作をより良く示すフロー図である。配布メカニズムは任意の様々なメカニズムであることができ、本明細書で説明するものは実例のためのマネジメントパックである。上述のように、テンプレートは基本的に、何らかのコンフィギュレーション情報集合を入力した顧客が構成する所定のモニタリング集合である。先ず、作成者はテンプレート定義を生成する。これを図５のブロック６００で示す。１つの実施形態では、テンプレート定義５０４を生成するため、３つのものが必要である。即ち、コンフィギュレーション情報、参照、および実装情報である。コンフィギュレーション情報は具体的には、コンフィギュレーション値を指定する情報である。上記の指定値はユーザにより入力され、実装部で使用される。参照はマネジメントパック内で生成される参照のリストであり、テンプレート出力が前記マネジメントパックに記憶される。実装部はそれ自体、置換パラメータを内部に組み込んだマネジメントパックの断片である。これらのパラメータはテンプレートのコンフィギュレーション部を参照する。例えば、要素ＳｅｒｖｉｃｅＮａｍｅがコンフィギュレーションの一部として必要な場合、これを実装部で＄ｃｏｎｆｉｇ／ＳｅｒｖｉｃｅＮａｍｅ＄として使用することができる。次いで、テンプレートの実行時に、この値をＳｅｒｖｉｃｅＮａｍｅの実際の値で置換する。

テンプレート定義５０４を生成する第１のステップは、妥当なスタンドアロンのマネジメントパックとして必要なマネジメントパック要素（例えば、クラス、モニタ、ルール、等）を生成することである。前記機能を望ましいようにテストして更新し、テンプレートをマネジメントパックから生成して、マネジメントパックのテンプレート部に挿入する。前記マネジメントパックは最終的に前記テンプレートを含むことになる。テンプレートに対して必要なコンフィギュレーション情報を次いで定義し、コンフィギュレーションパラメータを、テンプレート内で必要な場所で置換する。テンプレートを次いで実行し、出力をテストすることができる。

テンプレートオーサリングコンポーネント５０２は例として、テンプレート定義５０４の生成においてこのステップバイステップのアプローチを作成者５１０に与える。テンプレート定義の生成ステップを、図６に関して以下でさらに詳細に説明する。

作成者は次いで対応するアセンブリを生成する。前記アセンブリには、ユーザインタフェースページセットが含まれる。前記ユーザインタフェースページセットは、テンプレートがユーザにより選択されるときに（図３Ｂに示す）コンフィギュレーションページ３５４としてユーザに表示される。これを図５のブロック６０２で示す。ＵＩページセットを多数の様々な方法で生成することができる。例えば、マネジメントパックは、ＵＩページセットとして構成可能な１つまたは複数の再利用可能ＵＩページ定義を含むことができる。ＵＩページ定義の例を以下の表１で示す。

[表１]
<UIPages>
<!- ユーザがマシンを閲覧し、ウィンドウズ（登録商標）性能カウンタおよびそのインスタンスを選択することができるＵＩページ。
入力：なし（このページに対する全ての入力を無視）
出力サンプル：<ComputerName/>
<CounterName>%ディスク時間</CounterName>
<ObjectName>物理ディスク</ObjectName>
<InstanceName/>
<AllInstances>true</AllInstances>
<Frequency>900</Frequency>
-->
<UIPage ID=”System.UIPage.PerformanceCounterPage” Accessibility=”Public”>
<Implementation>
<Assembly>Microsoft.Mom.UI.Components</Assembly>
<Type>
Microsoft.EnterpriseManagement.Mom.Internal.UI.Modules.PerfCounterDataSource
</Type>
</Implementation>
</UIPage>
・
・
・
</UIPages>

上の表１における例示的なページによりユーザは、性能オブジェクト、カウンタおよびインスタンスを選択して、その情報を出力することができる。

ページセットはページ参照のコレクションと出力変換とを含む。上記の出力変換は、ページの出力を、ページセットを割り当てた型が消費する形に変換する。以下の表２は、ページ参照を用いたページセットの定義方法のサンプルを示す。

[表２]
<UIPages>
<!- ユーザがＷＭＩ名前空間、クラス、クラスのプロパティ、およびＷＭＩを探索する頻度を選択できるＵＩページ。
入力：<ShowFrequency>false</ShowFrequency>（任意。指定しなければ頻度制御および値を示し、falseならばＷＭＩクエリタグを読み出し、更新時に生成）
出力サンプル：<NameSpace>root＼cimv2</NameSpace>
<Query>select * from Win32_Service</Query>
<Params>
<Param>Param1</Param><Param>Param2</Param>
<Frequency>900</Frequency>
-->
<UIPage ID=”System.UIPage.WMIQueryProviderPage” Accessibility=”Public”>
<Implementation>
<Assembly>Microsoft.Mom.UI.Components</Assembly>
<Type>
Microsoft.EnterpriseManagement.Mom.Internal.UI.Modules.WMIDataSource
</Type>
</Implementation>
</UIPage>
・
・
・
</UIPages>
<UIPageSets>
<! System.Windows.Windows.WmiQueryProviderモジュールタイプに対するＵＩページセット -->
<UIPageSet ID=”System.UIPageSet.Modules.Windows.WMIQUeryProvider”
TypeDefinitionID=”System.Windows.WmiQueryProvider”>
<UIPageReferences>
<UIPageReference ID=”System.UIPageSet.Modules.Windows.WmiQueryProvider.Reference1”
PageID=”System.UIPage.WMIQueryProviderPage”>
<InputParameters/>
<InputTransform/>
</UIPageReference>
</UIPageReferences>
<OutputTransform/>
</UIPageSet>
<UIPageSet ID=”System.UIPageSet.Modules.Windows.WMIQUeryProbe”
TypeDefinitionID=”System.Windows.WmiQueryProbe”>
<UIPageReferences>
<UIPageReference ID=”System.UIPageSet.Modules.Windows.WmiQueryProbe.Reference1”
PageID=”System.UIPage.WMIQueryProviderPage”>
<InputParameters>
<ShowFrequency>false</ShowFrequency>
</InputParameters>
<InputTransform/>
</UIPageReference>
</UIPageReferences>
<OutputTransform>
<xsl:stylesheet version=”1.0”
xmlns:xsl=”http://www.w3.org/1999/XSL/Transform”>
<xsl:output method=”xml” indent=”yes” omit-xml-declaration=”yes”/>
<xsl:template match=”/”>
<xsl:copy-of select=”/NameSpace”/>
<xsl:copy-of select=”/Query”/>
<xsl:copy-of select=”/Params”/>
</xsl:template>
</xsl:stylesheet>
</OutputTransform>
</UIPageSet>
</UIPageSets>

次に、マネジメントパックが新規テンプレートと対応するアセンブリ（ＵＩページセットに対応）とを含むように、マネジメントパックを生成するか、または既存のマネジメントパックを修正する。または、ＭＰ定義およびアセンブリを、ユーザが使用しているコンピュータにインストールしたインストールパッケージのような別のメカニズムを通して、配布することができる。重要なことは、それらを何らかの方法で配布し、同様にそれらを一緒に配布することである。これを、図５のブロック６０４で示す。

次いで、マネジメントパックを、動作モニタリングシステム（例えば、上述のウィザードおよびプログラマビリティ層）を有し、監視を行うべきマシンに配布する。これを、データベースにインポートすること、および正しいコンピュータにより引き出させることといった、様々な方法で行うことができる。これを図５のブロック６０６で示す。

配布したマネジメントパックをデータベースにインポートすると、新規テンプレートが、そのＵＩアセンブリに対する参照とともに利用可能テンプレートのリストに追加される。これにより、新規テンプレートをユーザにより選択することができる。換言すれば、ユーザがコンフィギュレーションウィザード２０２を起動すると、ウィザード２０２はデータベースを問い合わせて利用可能テンプレートのリストを取得する。次いで、新規テンプレートに対応するディスプレイを、その新規テンプレートをユーザが選択できるように、図３Ｂに示すテンプレートディスプレイ画面３５２に表示する。これを、図５のブロック６０８で示す。

新規テンプレートをユーザが選択すると、コンフィギュレーションウィザード２０２は、対応するアセンブリ（ＵＩページセット）２０９に基づいてコンフィギュレーション画面３５４を表示する。これを、図５のブロック６１０で示す。換言すれば、新規テンプレートをユーザが選択すると、前記テンプレートに関連する特定のコンフィギュレーションＵＩページセットが識別され、ユーザに対して示される。これらのページセットを図３Ｂに示すコンフィギュレーションページ３５４として表示する。

図６は、図５のブロック６００が示すテンプレート定義を生成する方法をより良く示すフロー図である。先ず、作成者はテンプレートが用いるマネジメントパック要素（例えば、クラス、モニタ、およびルール）を生成する。これを、任意の他のマネジメントパックを生成するのと同様に行うことができる。例えば、表３は非常に少数の情報（１つのクラス）しか含まず、本明細書で議論した基本原理を示すのみの例示的なマネジメントパックを示す。

[表３]
<ManagementPack xmlns:xsd=”http://www.w3.org/2001/XMLSchema”
xmlns:xsi=”http://www.w3.org/2001/XMLSchema-instance”>
<Manifest>
<Identity>
<ID>System.Windows.Service.Template</ID>
<Version>6.0.0.0</Version>
<PublicKeyToken>31bf3856ad364e35</PublicKeyToken>
</Identity>
</Name>Micorosft Windows Service Template Management Pack</Name>
<References>
<Reference Alias=”Windows”>
<ID>System.Windows.MP</ID>
<Version>6.0.0.0</Version>
<PublicKeyToken>31bf3856ad364e35</PublicKeyToken>
</Reference>
</References>
</Manifest>
<TypeDefinitions>
<EntityTypes>
<ClassTypes>
<ClassType ID=”SomeClassid” Abstract=”false” Accessibility=”Public”
Hosted=”true”
Base=”Windows!System.Windows.OwnProcessNTService”/>
</ClassTypes>
</EntityTypes>
</TypeDefinitions>
</ManagementPack>

マネジメントパック要素の生成を、図６のブロック７０２により示す。

１つの実施形態では、作成者５１０は次いで、元のマネジメントパックと同一でありうる識別子付きのテンプレートを作成する。１つの実施形態では、妥当なテンプレート定義には空の構成要素、元のマネジメントパックで定義したそれぞれの参照に対する１つの参照、および自己参照と称する新規参照が含まれる。自己参照をテンプレートが使用して、自己参照を含むマネジメントパックへの参照を定義する。テンプレート作成者が使用しない場合は、これは必要でなくてもよく、除去することができる。前記定義は例として、テンプレートの作成元であるマネジメントパック全体を含む実装部も含まれる。例えば、上記表３に示すマネジメントパックは表４で示す以下のテンプレートを生成する。

[表４]
<Template ID=”System.Windows.Service.Template”>
<Configuration>
</Configuration>
<References>
<Reference ID=”Windows”/>
<Reference ID=”Self” />
</References>
<Implementation>
<TypeDefinitions>
<EntityTypes>
<ClassTypes>
<ClassType ID=”SomeClassid” Abstract=”false” Accessibility=”Public”
Hosted=”true”
Base=”Windows!System.Windows.OwnProcessNTService”/>
</ClassTypes>
<RelationshipTypes/>
</EntityTypes>
</TypeDefinitions>
</Implementation>
</Template>

元のマネジメントパックをテンプレートに変換することを、図６のブロック７０４で示す。

別の実施形態では、テンプレートは単にマネジメントパックの一部である。

次に、作成者５１０は必要なテンプレートコンフィギュレーションを定義する。最初は、現在の例において、作成者はユーザが２つの構成要素をコンフィギュレーション情報２２６（図２）として与えることを望むと仮定する。その場合、作成者はコンフィギュレーション部を表５で以下に示すように入力することができる。

[表５]
<Template ID=”System.Windows.Service.Template”>
<Configuration>
<xsd:element name=”Namespace” type=”xsd:string”/>
<xsd:element name=”TypeName” type=”xsd:string”/>
</Configuration>
<References>
<Reference ID=”Windows”/>
<Reference ID=”Self” />
</References>
<Implementation>
<TypeDefinitions>
<EntityTypes>
<ClassTypes>
<ClassType ID=”SomeClassid” Abstract=”false” Accessibility=”Public”
Hosted=”true”
Base=”Windows!System.Windows.OwnProcessNTService”/>
</ClassTypes>
<RelationshipTypes/>
</EntityTypes>
</TypeDefinitions>
</Implementation>
</Template>

テンプレートコンフィギュレーションを定義することを、図６のブロック７０６で示す。

最後に、作成者は置換変数を追加する。これを行う際、作成者はコンフィギュレーション項目および参照に対する置換文字列を定義する。これらは、実装部の任意の場所であることができ、例えば挿入可能な構成要素および参照を示す右クリックコンテクストメニューを与えることで促進することができる。議論したこの単純な例では、作成者はクラス名に対する２つのコンフィギュレーション変数を使用し、基底クラス内の参照の１つを使用する。これを以下の表６で示す。

[表６]
<Template ID=”System.Windows.Service.Template”>
<Configuration>
<xsd:element name=”Namespace” type=”xsd:string”/>
<xsd:element name=”TypeName” type=”xsd:string”/>
</Configuration>
<References>
<Reference ID=”Self”/>
<Reference ID=”System”/>
<Reference ID=”Windows”/>
<Reference ID=”Mom”/>
</References>
<Implementation>
<TypeDefinitions>
<EntityTypes>
<ClassTypes>
<ClassType ID=”$Config/Namespace$.$Config/TypeName$” Abstract=”false”
Accessibility=”Public”Hosted=”true”
Base=”$Reference/Self$System.Windows.OwnProcessNTService”/>
</ClassTypes>
<RelationshipTypes/>
</EntityTypes>
</TypeDefinitions>
</Implementation>
</Template>

置換変数の追加を、図６のブロック７０８で示す。テンプレート定義は完了であり、作成者は例として本テンプレートの実行をテストする。

作成者は引き続いて、新規に生成したテンプレート用のユーザインタフェースページセットを生成する。これは上述してあり、新規ＵＩページを必要とするか、または既存のＵＩページを使用することができる。

マネジメントパックの全体のスキーマ（ｓｃｈｅｍａ）を図７に示す。本議論はマネジメントパックに対するテンプレートの追加を扱うので、本明細書ではテンプレート部のみを議論することに留意されたい。図７は単に、１つの例示的なスキーマ（ｓｃｈｅｍａ）において、テンプレートがマネジメントパックに適合しうる場所を示す。本スキーマ（ｓｃｈｅｍａ）を用いると、テンプレートが同梱のマネジメントパック内で定義され、必要な全ての型とテンプレートが必要とするオブジェクトとは同一のマネジメントパックまたは参照マネジメントパック内に含まれることが分かる。ＵＩコンポーネントを、マネジメントパック付きのアセンブリとして与え、これらアセンブリに対する参照をマネジメントパックに含める。

図７Ａ−７Ｅはテンプレートを定義するスキーマ（ｓｃｈｅｍａ）を示す。図８Ａ−８ＪはＵｌページセットを定義するスキーマ（ｓｃｈｅｍａ）を示す。

マネジメントパックのテンプレート部には、図７Ａで示す１つまたは複数のテンプレートが含まれる。それぞれのテンプレートは図７Ｂに示すようにコンフィギュレーション、参照および情報部を必要とする。テンプレートは例として２つの属性を有する。第１のものはＩＤであり、本タイプに対する内部識別子を表し、前記識別子はマネジメントパックの名前空間で一意である。第２のものは任意コメントであり、これはマネジメントパック作成者が使用するコメント領域である。

コンフィギュレーション部はテンプレートを実行するために設定が必須であるコンフィギュレーション項目を定義する。これを図７Ｃに示す。

参照部は例として、マネジメントパックに含まれ、テンプレートの実行後に出力を記憶する参照情報を含む。これを図７Ｄでより良く示す。実際の参照は、使用前にテンプレートを含むマネジメントパック内で定義する。マネジメントパック内で未定義であるテンプレート固有な参照の１つは、上述の自己参照である。

実装部はマネジメントパックの断片を含む。これは、テンプレートの実行後にマネジメントパックの断片を生成するテンプレートである。本部分は一般にマネジメントパックのスキーマ（ｓｃｈｅｍａ）の定義に従うが、違いは、テンプレートからのコンフィギュレーションを用いてオブジェクト名を埋め、マネジメントパックオブジェクトを構成することである。前記スキーマ（ｓｃｈｅｍａ）を図７Ｅに示す。

上で簡潔に議論したように、マネジメントパックは０個以上の再利用可能なＵＩページ定義を含むことができる。それぞれのＵＩページを図８Ａに示すようにＵｌページ部で定義する。それぞれのＵＩページは３つの属性を有する。第１のものは、本ＵＩページに対するマネジメントパックの名前空間で一意な識別子である識別子属性である。第２のものは、マネジメントパック作成者が使用する任意コメント領域である。第３のものは、本ＵＩページが別のマネジメントパックにおけるＵＩページセットにより参照可能であるかどうかを判定するアクセシビリティ属性である。

それぞれのＵＩページは実装部を必要とする。これに対するスキーマ（ｓｃｈｅｍａ）を図８Ｂで示す。本実装部は、ページを定義するアセンブリと型情報とを含む。これを図８Ｃで示す。

ＵＩページセットを用いて、同一のマネジメントパックまたは参照マネジメントパック内で定義したＵＩページの集合をグループ化する。ページセットは、テンプレートに対して示されるＵＩを記述する。Ｕｌページセット部には、図８Ｄに示す０個以上のＵＩページセットが含まれる。それぞれのページセットは３つの属性を有する。第１のものは識別子であり、第２のものは任意コメント領域であり、第３のものは本ページセットが対象とする型を識別する型定義識別子である。

ページセットは、ＵＩページに対する参照の集合を有し、図８Ｅに示す出力変換を任意に有する。ＵＩページ参照要素は、予め定義した１対多のＵＩページ参照を含む。これを図８Ｆで示す。それぞれのＵＩページ参照は、識別子属性と型識別子属性とを含む２つの属性を有する。型識別子属性は本マネジメントパックまたは参照マネジメントパック内で既に定義したＵＩページに対する参照である。

ページセットは、それぞれのページの出力を一緒に、テンプレートに対するコンフィギュレーション出力の生成順序で配置する。必要に応じて、出力変換を指定した場合は変換を送信前に出力コンフィギュレーションに対して適用する。本変換を、図８Ｇで示すＵＩページセットの出力変換要素内で指定することができる。

ＵＩページセット内のＵＩページ参照は、図８Ｈに示すスキーマ（ｓｃｈｅｍａ）を有する。タイトルおよびサブタイトルはＵＩ内のページ表示を制御する。これらは内部の名前であり、言語パックセレクション内で参照して、フレンドリーなローカライズテキストとすることができる。タブ名はタブの名前を制御する。タブコントロール内での表示時に、タブ上にこの名前が現れる。その場合は、タイトルおよびサブタイトルを使用しなくともよい。ページセット定義は、ＵＩ内（例えば、ウィザードページまたはタブページ内）でそれがどのように表示されるかを知る必要はない。

ページは任意に入力パラメータを取ることができる。これらのパラメータを必要に応じてページ実装により使用する。入力パラメータは、図８Ｉに示すＸＭＬのような任意の公知のコンフィギュレーションであることができる。

ＵＩページは対象オブジェクトのコンフィギュレーションを入力として取得する。例えば、テンプレートのプロパティがオープンであるとき、そのテンプレートのコンフィギュレーションはそれぞれのページに渡される。ページは本コンフィギュレーションの一部のみ意識すればよく、従って、要求されたコンフィギュレーションのみをページが使用するように変換を本コンフィギュレーションに適用することができる。この任意の変換を、図８Ｊで示すページ参照の入力変換要素内で指定する。

本システムは、カスタマイズしたソリューションまたはサービスに対してもユーザがモニタリング機能を迅速に構成可能なテンプレートを与えることが分かる。本システムを、新規テンプレートおよび対応するアセンブリ（またはユーザインタフェースディスプレイ）を容易に定義してモニタリングシステムに追加できるように拡張することもできる。

主題を構造的な特徴および／または方法論的動作に固有な言葉で説明したが、添付請求項で定義した主題は必ずしも上述の特定の機能または動作に限定されないことは理解されるべきである。むしろ、上述の特定の機能または動作は、請求項を実装する形態の例として開示してある。

本発明を使用可能な１つの例示的な環境を示す図である。 テンプレートフレームワークの１つの実施形態のブロック図である。 図２で示したテンプレートフレームワークの動作の１つの実施形態を示すフロー図である。 テンプレートを構成してサービス定義を得るように使用される、一連のユーザインタフェースページの１つの実施形態を示す図である。 所与の特徴のモニタリング特性を示す型継承の１つの実施形態を示す図である。 テンプレート作成者が生成可能な健全性モデルの１つの実施形態を示す図である。 １つの実施形態に従うテンプレートオーサリング環境のブロック図である。 １つの実施形態に従って、図４に示すシステムを用いたテンプレートの作成方法を示すフロー図である。 １つの実施形態に従って、配布用のテンプレート作成方法を示すフロー図である。 テンプレートをモニタリングシステムに配信するための配信メカニズムの全体スキーマ（ｓｃｈｅｍａ）を示す図である。 テンプレートに対するスキーマ（ｓｃｈｅｍａ）を示す図である。 テンプレートに対するスキーマ（ｓｃｈｅｍａ）を示す図である。 テンプレートに対するスキーマ（ｓｃｈｅｍａ）を示す図である。 テンプレートに対するスキーマ（ｓｃｈｅｍａ）を示す図である。 テンプレートに対するスキーマ（ｓｃｈｅｍａ）を示す図である。 ＵＩページディスプレイに対するスキーマ（ｓｃｈｅｍａ）である。 ＵＩページディスプレイに対するスキーマ（ｓｃｈｅｍａ）である。 ＵＩページディスプレイに対するスキーマ（ｓｃｈｅｍａ）である。 ＵＩページディスプレイに対するスキーマ（ｓｃｈｅｍａ）である。 ＵＩページディスプレイに対するスキーマ（ｓｃｈｅｍａ）である。 ＵＩページディスプレイに対するスキーマ（ｓｃｈｅｍａ）である。 ＵＩページディスプレイに対するスキーマ（ｓｃｈｅｍａ）である。 ＵＩページディスプレイに対するスキーマ（ｓｃｈｅｍａ）である。 ＵＩページディスプレイに対するスキーマ（ｓｃｈｅｍａ）である。 ＵＩページディスプレイに対するスキーマ（ｓｃｈｅｍａ）である。

Claims (20)

1. コンピュータ制御サービスを監視するためのコンピュータ実行型モニタを構成するコンピュータ実行型の方法であって、
   テンプレート選択の入力に基づいて複数のモニタリングテンプレートの中から選択されたものにアクセスするステップと、
   一連のユーザインタフェースコンフィギュレーションディスプレイを、前記選択されたテンプレートに対応するユーザインタフェースアセンブリから表示するステップと、
   前記選択されたテンプレートのユーザコンフィギュレーションを示すコンフィギュレーション入力を、前記一連のユーザインタフェースコンフィギュレーションディスプレイを通して受け取るステップと、
   前記サービス上で実施されるべき所望のモニタリングのコンフィギュレーションを示すサービス定義を、前記選択されたテンプレートおよび前記コンフィギュレーション入力に基づいて出力するステップとを備えることを特徴とするコンピュータ実行型の方法。
2. 前記サービス定義により定義される所望のモニタリングの前記コンフィギュレーションに基づいてモニタリングロジックを構成するステップをさらに備えることを特徴とする請求項１に記載のコンピュータ実行型の方法。
3. 前記構成されたモニタリングロジックを展開して前記サービスを監視するステップをさらに備えることを特徴とする請求項２に記載のコンピュータ実行型の方法。
4. 前記コンピュータ実行型の方法は、ユーザ環境に展開されており、
   前記構成されたモニタリングロジックを展開する前に、前記ユーザ環境内の前記サービスの展開位置を識別するステップをさらに備えることを特徴とする請求項３に記載のコンピュータ実行型の方法。
5. 前記ユーザ環境は、各々が対応するモニタリングシステムを有する複数のコンピューティングシステムを備え、前記位置を識別するステップは、
   探索ルールを前記コンピューティングシステムの各々に送信するステップであって、前記探索ルールは、前記モニタリングシステムにより実行され、前記対応するコンピューティングシステムが前記サービスを展開したかどうかを判定するステップを含むことを特徴とする請求項４に記載のコンピュータ実行型の方法。
6. 前記ユーザ環境に展開された前記サービスの個々のインスタンスを識別するステップをさらに備えることを特徴とする請求項４に記載のコンピュータ実行型の方法。
7. 前記サービス定義が示すように前記所望のモニタリングのコンフィギュレーションを展開し、前記サービスの個々のインスタンスを前記識別位置で監視するステップをさらに備えることを特徴とする請求項６に記載のコンピュータ実行型の方法。
8. 監視すべきサービスタイプを示すものとして前記テンプレート選択の入力を受け取るステップをさらに備えることを特徴とする請求項１に記載のコンピュータ実行型の方法。
9. サービスモニタリングテンプレートを管理する方法であって、
   サービスタイプに対する一連のモニタリングに対応するサービスモニタリングテンプレートを定義するテンプレート定義を生成するステップと、
   前記サービスモニタリングテンプレートに対応するユーザインタフェースディスプレイのセットを生成するステップと、
   前記サービスモニタリングテンプレートと対応するユーザインタフェースディスプレイとを配布メカニズムに置くステップと、
   前記サービスモニタリングテンプレートと、前記対応するユーザインタフェースディスプレイのセットとを、サービスモニタリングシステムを使用するユーザ環境内のコンピューティングシステムに配布するステップとを備えることを特徴とする方法。
10. 前記サービスモニタリングテンプレートと前記対応するユーザインタフェースディスプレイのセットとを、前記ユーザ環境内の前記サービスモニタリングシステムに公開するステップをさらに備えることを特徴とする請求項９に記載の方法。
11. 前記ユーザインタフェースディスプレイは、コンフィギュレーション画面を含み、前記サービスモニタリングテンプレートと前記ユーザインタフェースディスプレイを配布メカニズムに置くステップは、
    前記コンフィギュレーション画面を静的なユーザインタフェースディスプレイ画面のセットとグループ化するステップを含むことを特徴とする請求項１０に記載の方法。
12. 前記サービスモニタリングシステムにおいて、前記サービスモニタリングシステムに展開されたサービスモニタリングテンプレートの全てを表示するステップと、
    前記サービスモニタリングテンプレートの１つに対するユーザ選択を受け取るステップとをさらに備えることを特徴とする請求項１１に記載の方法。
13. 前記選択されたユーザのモニタリングテンプレートの１つに対応する前記コンフィギュレーション画面を表示するステップをさらに備えることを特徴とする請求項１２に記載の方法。
14. 前記サービスモニタリングテンプレートと前記対応するユーザインタフェースディスプレイとを配布メカニズムに置くステップは、
    前記サービスモニタリングテンプレートと前記ユーザインタフェースディスプレイに対する参照とを所定のスキーマ（ｓｃｈｅｍａ）を有するマネジメントパックに置くステップを含むことを特徴とする請求項９に記載の方法。
15. 複数のモニタリングコンフィギュレーションテンプレートであって、それぞれのモニタリングコンフィギュレーションテンプレートは、共通サービスタイプのサービスグループに共通なモニタリング特性のセットを表す複数のモニタリングコンフィギュレーションテンプレートと、
    複数のユーザインタフェースディスプレイのセット群であって、それぞれのセットは、前記複数のモニタリングコンフィギュレーションテンプレートに対応する複数のユーザインタフェースディスプレイのセット群と、
    前記複数のモニタリングコンフィギュレーションテンプレートの１つに対するユーザ選択を受け取り、前記選択されたモニタリングコンフィギュレーションテンプレートに対応するユーザインタフェースディスプレイのセットを表示するよう構成されたモニタリングコンフィギュレーションコンポーネントとを備えることを特徴とするサービスモニタリングシステム。
16. 前記モニタリングコンフィギュレーションコンポーネントは、コンフィギュレーション情報を前記ユーザインタフェースディスプレイに対するユーザ入力として受け取り、所与のサービス上で実施されるべき所望のモニタリングを示すサービス定義を、前記選択されたモニタリングコンフィギュレーションテンプレートと前記コンフィギュレーション情報とに基づいて生成するよう構成されていることを特徴とする請求項１５に記載のサービスモニタリングシステム。
17. 前記モニタリングコンフィギュレーションコンポーネントは、新規モニタリングコンフィギュレーションテンプレートと、対応するユーザインタフェースディスプレイのセット群とを受け取り、前記新規モニタリングコンフィギュレーションテンプレートを前記ユーザが選択するために表示するよう構成されていることを特徴とする請求項１６に記載のサービスモニタリングシステム。
18. 前記サービス定義を受け取り、前記サービス定義に基づいて前記所与のサービスに対するモニタリングロジックを構成するよう構成されたモニタリングプログラマビリティ層をさらに備えることを特徴とする請求項１６に記載のサービスモニタリングシステム。
19. 前記モニタリングプログラマビリティ層は、前記構成されたモニタリングロジックを展開して前記所与のサービスを監視するよう構成されていることを特徴とする請求項１８に記載のサービスモニタリングシステム。
20. 前記モニタリングプログラマビリティ層は、ユーザ環境内で使用する前記所与のサービスの個々のインスタンスを識別し、前記構成されたモニタリングロジックを展開して前記所与のサービスの各インスタンスを監視するよう構成されていることを特徴とする請求項１９に記載のサービスモニタリングシステム。

Images