インストールに関連するアプリケーションの管理
【課題】本発明は、インストールに関連するアプリケーションを管理するために提供される。
【解決手段】インストールに関連するアプリケーションをどのように管理するかを定めることをインストール管理システムに可能にさせる命令が受け取られる。命令は、インストール管理システムの知識を必要とすることなく、２つ以上のアプリケーションの命令を記述するのに使用できる定義を指定するアプリケーションモデリング言語に準拠している。命令が解析されることにより、インストール管理システムは、アプリケーションをどのように管理するかを定めることが可能になる。
【解決手段】インストールに関連するアプリケーションをどのように管理するかを定めることをインストール管理システムに可能にさせる命令が受け取られる。命令は、インストール管理システムの知識を必要とすることなく、２つ以上のアプリケーションの命令を記述するのに使用できる定義を指定するアプリケーションモデリング言語に準拠している。命令が解析されることにより、インストール管理システムは、アプリケーションをどのように管理するかを定めることが可能になる。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明の実施の形態は、アプリケーションの管理に関する。より詳細には、本発明の実施の形態は、インストールに関連するアプリケーションの管理に関する。
【背景技術】
【０００２】
企業は、通常、異なるタイプの処理を行うための多くの異なるタイプのアプリケーションを有する。これらのアプリケーションは、通常は互いにネットワーク接続されたコンピュータシステム上で実行される。アプリケーション、それらのアプリケーションが実行されるコンピュータシステム、及びそれらのコンピュータシステム間で通信を行うのに使用されるネットワークは、特に、企業の「インストール」として一般に知られているものの一部である。
【０００３】
インストールは、ルータ、ファイアウォール、ロードバランサ等の他のタイプのデバイスを含むことができる。コンピュータシステム及びさまざまなデバイスは、一般に「ノード」とも呼ばれる。
【０００４】
インストールの複雑さが増加するにつれて、インストールを管理するシステム（以下「インストール管理システム」という）の必要性が増大してきている。インストール管理システムの一例は、Hewlett Packard（商標）のオープンビューオペレーションズ（Openview Operations）（ＯＶＯ）である。
【０００５】
インストール管理システムによって行われる管理のタイプの例には、特に、プロセス、ノード、又はソフトウェアが実行されているか否かを判断すること、ノードが有するメモリ量を求めること、ノードのコンピュータ処理ユニット（ＣＰＵ）の稼働率を求めること、アプリケーションの応答時間を求めること、並びにこれらの判断及び求値に基づいて動作を行うことが含まれる。動作を行うことの例には、特に、より多くのメモリをノードに追加すること、ワークロードを再バランスさせること、又は、アプリケーションを再構成することが含まれ得る。
【発明の開示】
【課題を解決するための手段】
【０００６】
添付図面は、本明細書に組み込まれて、本明細書の一部を成す。添付図面は、その説明と共に本発明の実施形態を示し、本発明の原理を説明する役割を果たす。
【０００７】
この説明で参照される図面は、特に注記されている場合を除いて、一律の縮尺で描かれているものと理解されるべきではない。
【発明を実施するための最良の形態】
【０００８】
次に、本発明のさまざまな実施形態を詳細に参照する。
【０００９】
これらのさまざまな実施形態の例は、添付図面に示されている。本発明は、これらの実施形態と共に説明されるが、実施形態は、本発明をこれらの実施形態に限定することを目的とするものではないことが理解されよう。その逆に、本発明は、代替形態、変更形態、及び均等物をカバーすることを目的としている。これらの代替的なもの、変更したもの、及び均等なものは、添付の特許請求の範囲によって画定された本発明の精神及び範囲内に含めることができる。
【００１０】
さらに、本発明の以下の説明では、本発明の徹底した理解を提供するために、多数の具体的な詳細が述べられる。それ以外の場合には、本発明の態様を不必要に分かりにくくしないように、既知の方法、手順、コンポーネント、及び回路は詳細に説明されていない。
【００１１】
概観
従来のインストール管理システムは、インストールに関連するデバイス及びアプリケーションを管理するように「構成」されている。たとえば、開発者は、従来のインストール管理システムを構成する目的でそのインストール管理システムが受け取ることができるポリシー及びテンプレートを作成することができる。開発者は、特に、アプリケーションに関連するさまざまなメトリック（metric）を監視するためのメトリック収集ポリシー及びしきい値ポリシーを作成することができる。また、開発者は、従来のインストール管理システムがタスクのスケジューリングの一部として使用するスケジューリングポリシー、及び、従来のインストール管理システムが収集されたメトリック等のグラフを作成するのに使用するグラフテンプレートを作成することもできる。ポリシー及びテンプレートは、一般に「アーティファクト（artifact）」と呼ばれるものの例である。
【００１２】
従来のインストール管理システムを構成する従来の方法には不利な点がいくつかある。１つ目は、アーティファクトを作成するのに、従来のインストール管理システムについての深い知識が必要とされることである。２つ目は、アーティファクトが特定の従来のインストール管理システムに特有であり、したがって、企業が、異なる従来のインストール管理システムへの切り換えを決定した場合にそれを再利用することができないことである。３つ目は、従来のインストール管理システムが提供するインターフェースが一致しない場合があることである。これによって、アーティファクトを作成する開発者の作業はさらに複雑になる。４つ目は、開発者が、適切なアーティファクトを作成するために冗長な手作業の構成作業を行わなければならない場合があることである。たとえば、特定のメトリックを監視するために、開発者は、特に、冗長な内容を含むスケジュールポリシー、しきい値ポリシー、グラフテンプレートを手作業で作成しなければならない場合がある。上記の理由から、従来のインストール管理システムは、開発者が、異なるアプリケーションに対する一貫した管理ソリューションを作成することを困難にしている。
【００１３】
一実施形態によれば、インストール管理システムにインストールに関連するアプリケーションをどのように管理するかを定めることを可能にさせる命令を記述するための定義を含むアプリケーションモデリング言語が提供される。この定義は、一実施形態によれば、開発者がインストール管理システムについて知る必要なく２つ以上のアプリケーションに対する命令を記述するのに使用することができる。アプリケーションモデリング言語は、「ニュートラルモデリング言語（neutral modeling language）」とも呼ばれる。アプリケーションモデリング言語は、開発者がインストール管理システムについて知る必要がないため、２つ以上のタイプのインストール管理システムの命令を記述するのに使用することができる。
【００１４】
インストール管理システム
インストール管理システムの例には、ＨＰ（商標）のオープンビューオペレーションズ（OpenView Operations）（ＯＶＯ）、ＨＰ（商標）のオープンビューパーフォーマンスマネージャ（OpenView Performance Manager）（ＯＶＯＵ）、及びＢＭＣ（商標）のレメディ（Remedy）が含まれるが、これらに限定されるものではない。異なるインストール管理システムの他の例には、Ｕｎｉｘ（登録商標）用のＨＰ（商標）のオープンビューオペレーションズのバージョン６やバージョン７等、インストール管理システムの異なるバージョンが含まれる。
【００１５】
ＨＰ（商標）のオープンビューオペレーションズ（ＯＶＯ）、ＨＰ（商標）のオープンビューパーフォーマンスマネージャ（ＯＶＯＵ）、及びＢＭＣ（商標）のレメディは、異なる製品の例である。Ｕｎｉｘ（登録商標）用のＨＰ（商標）のオープンビューオペレーションズのバージョン６及びバージョン７は、同じ製品の異なるバージョンの例である。
【００１６】
アプリケーション
本発明のさまざまな実施形態を使用して監視できるアプリケーションの例には、Ｏｒａｃｌｅ（商標）データベース、ＢＥＡ（登録商標）（Bill Edward Alfred Systems（登録商標））ウェブロジックアプリケーションサーバ（WebLogic Application Server）、及びＭｉｃｒｏｓｏｆｔ（商標）エクスチェンジサーバ（Exchange Server）が含まれるが、これらに限定されるものではない。
【００１７】
インストールに関連するアプリケーションを管理するためのシステム
図１は、インストール管理システムの知識を必要としない、一実施形態によるインストールに関連するアプリケーションを管理するためのシステムを示している。図１の機能を表すブロックは、図示したものとは異なって配置することができ、機能を追加して実施することもできるし、本明細書で説明するものよりも少ない機能を実施することもできる。さらに、図１のブロックによって表された機能は、さまざまな方法で組み合わせることができる。システム１００は、ソフトウェア、ハードウェア、ファームウェア、又はこれらの組み合わせを使用して実施することができる。
【００１８】
図１は、人１６０、エディタ１２０、命令１３０、インストール管理システム１４０、及びインストール１５０を示している。インストール管理システム１４０は、命令アナライザ１４２を含む。命令アナライザ１４２は、インストール管理システム１４０の外部に存在することができることが十分理解される。インストール１５０は、特に、アプリケーション１５２及び１５４を含む。人１６０は開発者とすることができる。開発者１６０は、エディタ１２０を使用して、インストール管理システム１４０が受け取る命令１３０を記述することができる。エディタ１２０は、特に、テキストエディタ又は拡張可能マークアップ言語（ＸＭＬ）エディタとすることができる。
【００１９】
一実施形態によれば、開発者１２０は、アプリケーションモデリング言語の定義を使用して命令１３０を記述する。このアプリケーションモデリング言語の定義は、インストール管理システム１４０の知識を必要としない。この定義は、開発者がインストール管理システム１４０を構成するための命令１３０をどのように記述できるかを示すことができる。たとえば、定義は、メトリックを指定できること、メトリックの名前を指定できること、メトリックの値をどれくらいの頻度で取得するか、メトリックの値をどこから取得するか、たとえば特にメトリックのしきい値を指定することによってアプリケーションが監視されることに関連する問題が存在することをメトリックの値が示しているか否か、及び、メトリックの値が問題が存在すること示している場合に何を行うかを示すことができる。また、定義は、内容を指定するためのシンタックス（syntax）を含むこともできる。一実施形態によれば、命令１３０は、ＸＭＬで記述され、１つ又は２つ以上のＸＭＬスキーマは、アプリケーションモデリング言語の定義を指定するのに使用される。ＸＭＬスキーマは、非独占的なフォーマットの一例である。
【００２０】
インストール管理システム１４０は、定義に従って記述された命令１３０を受け取ることができる。インストール管理システム１４０は、命令１３０を使用して、インストール１５０をどのように管理するかを定める。たとえば、インストールアナライザ１４２は、命令を解析して、インストール１５０をどのように管理するかを定めることをインストール管理システム１４０に可能にさせる。
【００２１】
アプリケーションモデリング言語及び定義
どのインストール管理システム１４０が使用されても、物事のタイプ及びそれらの物事を監視する方法は基本的に同じである。たとえば、Ｏｒａｃｌｅ（商標）データベースについては、インストール管理システム１４０がＨＰ（商標）のＯＶＯであるのか、又はＢＭＣ（商標）のレメディであるのかにかかわらず、監視されてグラフ化される一定のメトリックがある。したがって、一実施形態によれば、特定のインストール管理システム１４０に特有の構成の細部は、水面下でハンドリングされる。たとえば、開発者１６０は、ＯＶＯＷが「プロセス監視ポリシー（Process Monitoring Policy）」を使用するのに対して、ＯＶＯＵが「監視ポリシー（Monitor Policy）」を使用することを知る必要はない。開発者が知る必要のあるすべては、Ｏｒａｃｌｅ（商標）データベース等について、たとえば、開発者が、一実施形態に従って、特定のアプリケーションプロセスのどのような監視を欲するのかである。
【００２２】
インストール管理システム１４０を構成する実施詳細を隠蔽することによって、一実施形態によれば、アプリケーションモデリング言語は、２つ以上のインストール管理システム１４０を構成するのに使用することができる。たとえば、さまざまな実施形態を使用して記述された、Ｏｒａｃｌｅ（商標）データベースを監視するための命令１３０は、ＨＰ（商標）のＯＶＯ又はＢＭＣ（商標）のレメディのいずれを構成するのにも容易に使用することができる。
【００２３】
すでに述べたように、一実施形態によれば、インストール１５０に関連するアプリケーション１５２、１５４をどのように管理するかを定めることをインストール管理システム１４０に可能にさせる命令１３０を記述するための定義を含むアプリケーションモデリング言語が提供される。一実施形態によれば、定義は、１つ又は２つ以上のＸＭＬスキーマで提供され、命令１３０はＸＭＬで記述される。ＸＭＬは、開発者１６０に広く知られており、したがって、開発者１６０がインストール管理システム１４０を構成することをより容易にする。
【００２４】
図２は、一実施形態によるメトリック収集のスキーマを示している。メトリック収集スキーマは、どのメトリックを監視するかを指定する命令１３０をどのように記述するかの情報、メトリックをどのように監視するかの情報、問題が存在することをメトリックの値が示している場合に何を行うかの情報等を提供する。たとえば、メトリック収集スキーマは、メトリックの名前（たとえば、「収集名（CollectionName）」）、メトリックの値を収集するためのスケジュール（たとえば、「スケジュール（Schedule）」）、及びメトリックの値を収集するためのコマンドライン（たとえば、「コマンドライン（CommandLine）」）が指定可能であることを示す。また、メトリック収集スキーマは、オプションとして、メトリックの値を収集するための、メトリックの説明（たとえば、「説明（Description）」）及びユーザパスワード等のそのクレデンシャル（credentials）（たとえば、「クレデンシャル（Credentials）」）が指定可能であることも示す。
【００２５】
図３は、一実施形態によるタスクをスケジューリングするためのスキーマを示している。一実施形態によれば、タスクは、開発者１６０がインストール管理システム１４０に規則的なスケジュールで実行して欲しいと思っている或るアクティビティであり、サーバが毎夜アクティブであるか又はタスクを実行しているかを調べて、アプリケーションサーバの任意の新しいインスタンスがデバイスに対して配備されたか否かを調べるためにサーバをピングすること等である。スケジューリングされたタスクスキーマは、たとえば、どのタスクを監視するか、タスクをどのように監視するか等を指定する命令１３０をどのように記述するかについての情報を提供する。たとえば、スケジューリングされたタスクスキーマは、スケジュールの名前（たとえば、「スケジュール（Schedule）」）及びタスクの名前（たとえば、「タスク（Task）」）が指定可能であることを示す。開始メッセージ（StartMessage）、失敗メッセージ（FailureMessage）、成功メッセージ（SuccessMessage）によって、開発者１６０は、たとえば、スケジューリングされたタスクが開始された時、失敗した時、又は成功した時にインストール管理システム１４０のオペレータに向けて表示できるテキストを指定することが可能になる。
【００２６】
図４は、一実施形態によるグラフのスキーマを示している。このグラフスキーマは、グラフがどのように現れるかを指定する命令１３０をどのように記述するかについての情報を提供する。たとえば、グラフスキーマは、クラス（たとえば、クラス（Class））、メトリックの名前（たとえば、メトリック名（MetricName））、メトリックのラベル（たとえば、メトリックラベル（MetricLabel））、及びメトリックの説明（たとえば、メトリック説明（MetricDescription））が指定可能であることを示す。このクラスは、「クラス」、又は、グラフ上に表示されることになるデータが格納されるデータベースに定義されたデータベーステーブルを指す。メトリック名は、グラフ化されるメトリックの名前であり、メトリックラベルは、グラフ上のメトリックにどのラベルを使用するかを示し、メトリック説明は、グラフに使用するメトリックの説明である。２つ以上のメトリックがグラフスキーマにより指定可能である。
【００２７】
また、グラフスキーマは、一実施形態によれば、グラフ名（GraphName）、グラフ説明（GraphDescription）、グラフタイトル（GraphTitle）、グラフカテゴリー（GraphCategory）、グラフメトリック（GraphMetrics）、Ｙ軸タイトル（YAxixTitles）、及びグラフ日付範囲（GraphDateRange）を指定するのに使用することもできる。グラフ名はグラフの名前である。グラフ説明はグラフの説明である。グラフタイトルはグラフのタイトルである。グラフカテゴリーは、グラフが、インストール管理システムに関連するユーザインターフェースを使用して表示されるときにたとえば「グループ」で現れるようにグラフを編成することを可能にする。グラフメトリックはグラフ化されるメトリックである。Ｙ軸タイトルは、Ｙ軸のためのタイトルの指定を可能にする。グラフ日付範囲は、グラフ上に現れる日付の範囲の指定を可能にする。２つ以上のグラフがグラフスキーマによって指定可能であり、２つ以上のメトリックが特定のグラフ上に表示可能である。
【００２８】
グラフが、異なる背景色及びさまざまな線の色を使用することはしばしば行われる。さらに、グラフは、特に、線グラフの場合もあるか又は棒グラフの場合もある。しかしながら、一実施形態によれば、グラフスキーマは、開発者が、たとえば、背景色、線の色、又はグラフのタイプ等の一定のタイプの情報を指定することを必要としない。これは、インストール管理システム１４０全体にわたって一貫性を保証するために、命令アナライザ１４２によって遂行可能であることが十分理解される。
【００２９】
例示の目的で、スキーマの簡単化されたバージョンが図２〜図４に示されている。図２〜図４に示すものよりも多くのエレメントを、図２〜図４に示すスキーマに関連付けることができる。たとえば、メトリック収集スキーマは、しきい値、頻度、及びメトリックの値を得るためのソースを指定することができる。しきい値は、問題が存在することをメトリックの値が示しているか否か判断するのに使用することができ、たとえば、その値がしきい値と一致するか又はしきい値を超えているときを判断するのに使用することができる。頻度は、たとえばソースからメトリックの値をどれくらいの頻度で取得するかを定めるのに使用することができる。別の例では、スケジューリングされたタスクスキーマは、特に、タスクがどれくらいの頻度で実行されるかを指定することができる。さらに別の例では、グラフスキーマは、グラフに現れる可能性のあるデータのインスタンス名についてグラフをフィルタリングするためにフィルタを指定することを可能にすることができる。
【００３０】
さらに、図２〜図４は、ごく僅かなアプリケーションモデリング言語定義を示している。本発明のさまざまな実施形態を使用して実施できる他の多数の定義がある。たとえば、パッケージスキーマは、Ｍｉｃｒｏｓｏｆｔ（商標）Ｗｉｎｄｏｗｓ（登録商標）等のプラットフォームにインストールされるソフトウェアをどのようにパッケージするかについての命令を記述するのに使用することができる。パッケージスキーマは、どのファイルが、パッケージされるソフトウェアを含むか、それらのファイルのロケーション、及びファイルがインストールされるプラットフォームを指定することができる。別の例では、インストール管理システムのシンプルネットワーク管理プロトコル（ＳＮＭＰ）処理を構成する命令をどのように記述するかを指定するスキーマ（ＳＮＭＰスキーマ）が存在し得る。スキーマについてより多くの情報を得るには、以下に含まれる「スキーマについてのより多くの情報」の副題を参照されたい。
【００３１】
すでに述べたように、従来のインストール管理システムでは、開発者は、適切なアーティファクトを作成するために、冗長な手作業の構成作業を行わなければならない場合がある。たとえば、従来のインストール管理システムを使用して特定のメトリックを監視するために、開発者は、特に、冗長な内容を含むスケジュールポリシー、しきい値ポリシー、グラフテンプレートを手作業で作成しなければならない場合がある。しかしながら、一実施形態によれば、インストール管理システムの特定の態様を構成するための内容は、一箇所で指定される。したがって、開発者は、冗長な手作業の構成作業を行う必要はない。たとえば、ポリシーがメトリックについての情報を必要とする場合、そのメトリックについての内容は、ポリシーのための一組の命令に冗長な内容を含めるのではなく、メトリック収集スキーマに基づいて記述された一組の命令から取得することができる。
【００３２】
命令
例示の目的で、図１は、一実施形態による一組の命令１３０を示している。異なる組の命令１３０を使用して、異なるアプリケーション１５２、１５４を管理するようにインストール管理システム１４０を構成することができる。さらに、より明らかになるように、２組以上の命令を使用して、同じアプリケーションの異なる態様を管理するようにインストール管理システム１４０を構成することができる。たとえば、Ｏｒａｃｌｅ（商標）データベースアプリケーション及びＭｉｃｒｏｓｏｆｔ（商標）のＥｘｃｈａｎｇｅ Ｓｅｒｖｅｒの双方は、開発者１６０が監視したい場合があるメトリックを有する。したがって、複数の組の命令１３０を、さまざまなメトリックのメトリック収集スキーマ（図２）に基づいて記述することができる。
【００３３】
一実施形態によれば、定義を使用して、その定義に基づき記述された一組の命令を検証することができる。たとえば、図２に示すメトリック収集スキーマに基づいて記述された一組の命令は、インストール管理システム１４０がメトリック収集スキーマを使用して検証することができる。一組の命令は、「モデルインスタンス」又は「モデルのインスタンス」とも呼ばれる。
【００３４】
インストールに関連するアプリケーションを管理する方法の動作例
図５は、本発明の一実施形態による、インストールに関連するアプリケーションを管理するための方法を説明するフローチャート５００を示している。特定のステップがフローチャート５００に開示されているが、このようなステップは例示である。すなわち、本発明の実施形態は、さまざまな他のステップ又はフローチャート５００に列挙されたステップの変形を実行することによく適している。フローチャート５００のステップは、提示されたものとは異なる順序で実行することができ、フローチャート５００のステップのすべてが実行されるとは限らない場合もあることが十分理解される。
【００３５】
フローチャート５００によって説明される実施形態の全部又は一部は、コンピュータ可読で且つコンピュータ実行可能な命令を使用して実施することができる。これらの命令は、たとえば、コンピュータシステム又は同様のデバイスのコンピュータ使用可能媒体に存在する。上述したように、本発明の一定のプロセス及びステップは、一実施形態では、一連の命令（たとえば、ソフトウェアプログラム）として実現される。この一連の命令は、コンピュータシステムのコンピュータ可読メモリ内に存在し、コンピュータシステムによって実行される。これらの命令は、実行されると、後述するような本発明の機能をコンピュータシステムに実施させる。
【００３６】
ステップ５１０において、この方法は開始する。
【００３７】
ステップ５２０において、インストールに関連するアプリケーションをどのように管理するかを定めることをインストール管理システムに可能にさせる命令が受け取られる。命令１３０は、インストール管理システム１４０の知識を必要とすることなく、２つ以上のアプリケーション１５２及び１５４の命令１３０を記述するのに使用できる定義を指定するアプリケーションモデリング言語に準拠している。図２〜図４に示すスキーマは、命令１３０を記述するのに使用できるアプリケーションモデリング言語によって提供される定義の例である。例示の目的で、一組の命令１３０が、図２に示すスキーマに基づいて特定のアプリケーション１５２の特定のメトリックについて記述され、別の一組の命令１３０が、その同じアプリケーション１５２の別のメトリックの同じスキーマ（図２）に基づいて記述されるものと仮定する。それらの二組の命令は、異なるインストール管理システム１４０を構成するのに使用することができる。たとえば、それらの二組の命令は、ＨＰ（商標）のＯＶＯ又はＢＭＣ（商標）のレメディのいずれを構成するのにも使用することができ、これは、アプリケーションモデリング言語は、開発者１６０がどのインストール管理システム１４０についても知ることを必要としないからである。
【００３８】
開発者１６０は、エディタ１６０を使用して数組の命令１３０を作成することができる。一実施形態によるエディタ１６０はＸＭＬエディタであり、命令１３０はＸＭＬ命令である。インストール管理システム１４０は、数組の命令１３０を含むファイルを受け取ることができる。
【００３９】
ステップ５３０において、命令が解析されて、それによって、インストール管理システムは、アプリケーションをどのように管理するかを定めることが可能になる。たとえば、ステップ５２０で受け取られた数組の命令１３０が解析される。このように、インストール管理システム１４０は、数組の命令が記述されたアプリケーション１５２を監視することが可能になる。
【００４０】
ステップ５４０において、この方法は終了する。
【００４１】
スキーマについてのより多くの情報
以下は、他の可能なスキーマ及びスキーマに関連することができる内容を説明する。たとえば、以下は、さまざまなスキーマに関連することができるさまざまな属性及びタイプを説明する。スキーマの１つは、一実施形態によれば、マスタモデル（MasterModel）である。ＳＰＩ情報（SPIInformation）、グラフファイル（GraphFiles）、ポリシー（Policies）、Ｐｋｇファイル（PkgFiles）、製品（Products）等の一実施形態によるスキーマエレメントは、マスタモデルスキーマの子とすることができる。グラフファイルは、図４に示すグラフスキーマの一例である。ポリシーは、ポリシースキーマの一例である。Ｐｋｇファイルは、パッケージスキーマの一例である。ＳＮＭＰポリシー（SNMPPolicy）は、ＳＮＭＰスキーマの一例である。スケジュールドタスクポリシー（ScheduledTaskPolicy）は、図３に示すスケジューリングタスクスキーマの一例である。外部メトリック収集は、図２に示すメトリック収集スキーマの一例である。
【００４２】
また、一実施形態によるルートスキーマのブロック図を示す図６も参照されたい。図６を参照して、一実施形態によれば、ルートエレメントは、すべてのポリシーに使用される。一実施形態によれば、ＳＰＩ情報は、ファイル名のプレフィックス（prefix）等のＳＰＩアーティファクトに使用される。一実施形態によれば、ポリシー名は、ＳＰＩモデル内で一意であり、収集名（CollectionName）は、ポリシーの名前である。
【００４３】
アプリケーション管理言語の例：
本発明の実施形態によるアプリケーション管理言語の例が、以下のパラグラフで説明される。
【００４４】
メトリックエレメントは、本発明の実施形態によるアプリケーションについて監視されているメトリックについての情報を定義する。この情報は、１）メトリックの名前及び説明、２）メトリックのソース、並びに３）測定の単位を含むが、これらに限定されるものではない。
【００４５】
メトリックエレメントの例：
【００４６】
［表１］
- e policy:Metric（ｅ ポリシー：メトリック）
e policy:MetricName（ｅ ポリシー：メトリック名）
e policy:MetricDescription（ｅ ポリシー：メトリック説明）
e policy:MetricUnit（ｅ ポリシー：メトリック単位）
+ e policy:MetricSource（ｅ ポリシー：メトリックソース）
【００４７】
監視ポリシーエレメントは、本発明の実施形態による管理システムにアプリケーションにより提供される、応答時間又は入力ワークロード等、データの監視についての情報を定義する。この情報は、１）ポリシーの名前及び説明、２）データを監視する間隔、３）状態を判断する数値しきい値又はスクリプトを含む監視する状態、４）監視されるメトリック、５）監視されるオブジェクトインスタンス、並びに６）イベントの重大度（severity）及び問題を処理するために何を行うかについての命令を含む、エラー状態が発生した場合に行う動作を含むが、これらに限定されるものではない。
【００４８】
監視ポリシーエレメントの例：
【００４９】
［表２］
- e policy:MonitorPolicy（ｅ ポリシー：監視ポリシー）
e policy:PolicyName（ｅ ポリシー：ポリシー名）
e policy:PolicyDescription（ｅ ポリシー：ポリシー説明）
- e policy:MinMaxMonitor（ｅ ポリシー：最小最大監視）
a Type（ａ タイプ）
+ e policy:PolicyMetric（ｅ ポリシー：ポリシーメトリック）
- e policy:Rules（ｅ ポリシー：ルール）
- e policy:MinMaxMessageRule（ｅ ポリシー：最小最大メッセージルール）
a UUID
e policy:Description（ｅ ポリシー：説明）
- e policy:Conditions（ｅ ポリシー：状態）
- e policy:Condition（ｅ ポリシー：状態）
e policy:Description（ｅ ポリシー：説明）
- e policy:Actions（ｅ ポリシー：動作）
- e policy:StartAction（ｅ ポリシー：動作開始）
+ e policy:Message（ｅ ポリシー：メッセージ）
e policy:Severity（ｅ ポリシー：重大度）
+ e policy:Instructions（ｅ ポリシー：命令）
+ e policy:ContinueAction（ｅ ポリシー：動作継続）
e policy:EndAction（ｅ ポリシー：動作終了）
e policy:ThresholdLimitValue（ｅ ポリシー：しきい値制限値）
【００５０】
外部収集エレメントは、本発明の実施形態によるインストール管理システムの外部のコレクタからメトリックを収集するのに必要な情報を定義する。この情報は、１）ポリシーの名前及び説明、２）データを収集する間隔、３）データを収集するために実行するコマンドライン、並びに４）収集に必要とされるユーザ／パスワードを含むが、これらに限定されるものではない。
【００５１】
外部収集エレメントの例：
【００５２】
［表３］
- e policy:ExternalMetricCollection（ｅ ポリシー：外部メトリック収集）
e policy:CollectionName（ｅ ポリシー：収集名）
e policy:Description（ｅ ポリシー：説明）
+ e policy:Schedule（ｅ ポリシー：スケジュール）
e policy:CommandLine（ｅ ポリシー：コマンドライン）
+ e policy:Credentials（ｅ ポリシー：クレデンシャル）
【００５３】
ポリシーエレメントを監視するプロセスは、本発明の実施形態による監視するプロセスまたはサービスについての情報を定義する。この情報は、１）ポリシーの名前及び説明、２）プロセスを監視する間隔、３）プロセスの名前、並びに４）イベントの重大度及び問題を処理するために何を行うかについての命令を含む、エラー状態が発生した場合に行う動作を含むが、これらに限定されるものではない。
【００５４】
プロセス監視ポリシーエレメントの例：
【００５５】
［表４］
- e policy:Policies（ｅ ポリシー：ポリシー）
- e policy:ProcessMonitoringPolicy（ｅ ポリシー：プロセス監視ポリシー）
e policy:PolicyName（ｅ ポリシー：ポリシー名）
e policy:PolicyDescription（ｅ ポリシー：ポリシー説明）
+ e policy:ExecutionInterval（ｅ ポリシー：実行間隔）
- e policy:Processes（ｅ ポリシー：プロセス）
- e policy:Process（ｅ ポリシー：プロセス）
+ e policy:ProcessDetail（ｅ ポリシー：プロセス詳細）
+ e policy:ErrorCondition（ｅ ポリシー：エラー状態）
【００５６】
スケジューリングされたタスクポリシーエレメントは、本発明の実施形態による管理システムによって実行されるスクリプト又は実行可能ファイル（executable）についての情報を定義する。この情報は、１）ポリシーの名前及び説明、２）実行を行う間隔（繰り返し間隔又は具体的な時間若しくは具体的な日として定義される）、並びに３）イベントの重大度及び問題を処理するために何を行うかについての命令を含む、タスク実行の開始時、成功時、又は失敗時にオペレータコンソールへ送信されるべきメッセージを含むが、これらに限定されるものではない。
【００５７】
スケジューリングされたタスクポリシーエレメントの例：
【００５８】
［表５］
- e policy:ScheduledTaskPolicy（ｅ ポリシー：スケジュールドタスクポリシー）
e policy:PolicyName（ｅ ポリシー：ポリシー名）
e policy:PolicyDescription（ｅ ポリシー：ポリシー説明）
+ e policy:Schedule（ｅ ポリシー：スケジュール）
+ e policy:Task（ｅ ポリシー：タスク）
- e policy:StartMessage（ｅ ポリシー：開始メッセージ）
+ e policy:Message（ｅ ポリシー：メッセージ）
e policy:Severity（ｅ ポリシー：重大度）
+ e policy:Instrucitons（ｅ ポリシー：命令）
+ e policy:FailureMessage（ｅ ポリシー：失敗メッセージ）
+ e policy:SuccessMessage（ｅ ポリシー：成功メッセージ）
【００５９】
ＳＮＭＰポリシーエレメントは、本発明の実施形態によるメトリックの収集元のＳＮＭＰトラップを定義する。この情報は、１）ポリシーの名前及び説明、２）ＳＮＭＰトラップＩＤ及び監視するトラップをさらに識別する追加ＳＮＭＰ変数、並びに３）監視する状況又は状態及びエラー状態が見つかった場合に行う動作を指定する一組のルールを含むが、これらに限定されるものではない。この動作には、状態の重大度、及び問題を処理するために何を行うかについての命令のような物事が含まれる。
【００６０】
ＳＮＭＰポリシーエレメントの例：
【００６１】
［表６］
- e policy:SNMPPolicy（ｅ ポリシー：ＳＮＭＰポリシー）
e policy:PolicyName（ｅ ポリシー：ポリシー名）
e policy:PolicyDescription（ｅ ポリシー：ポリシー説明）
- e policy:Rules（ｅ ポリシー：ルール）
- e policy:MessageRule（ｅ ポリシー：メッセージルール）
e policy:Description（ｅ ポリシー：説明）
- e policy:Condition（ｅ ポリシー：状態）
e policy:EventObjectId（ｅ ポリシー：イベントオブジェクトＩｄ）
+ e policy:VariableBinding（ｅ ポリシー：変数バインディング）
- e policy:Action（ｅ ポリシー：動作）
+ e policy:Message（ｅ ポリシー：メッセージ）
e policy:Severity（ｅ ポリシー：重大度）
+ e policy:Instrucitons（ｅ ポリシー：命令）
【００６２】
ログファイル（Logfile）エレメントは、本発明の実施形態によるアプリケーションログファイルを監視することについての情報を定義する。この情報は、１）ポリシーの名前及び説明、２）ログファイルロケーション、並びに３）監視する状態を指定する１つ又は２つ以上のルール（ログファイル内のテキストパターンの存在）、並びに３）状態の重大度、及び問題を処理するために何を行うかについての命令のようなものを含む、エラー状態が見つかった場合に行う動作を含むが、これらに限定されるものではない。
【００６３】
ログファイルエレメントの例：
【００６４】
［表７］
- e policy:LogPolicy（ｅ ポリシー：ログポリシー）
e policy:PolicyName（ｅ ポリシー：ポリシー名）
e policy:PolicyDescription（ｅ ポリシー：ポリシー説明）
+ e policy:LogFile（ｅ ポリシー：ログファイル）
- e policy:Rules（ｅ ポリシー：ルール）
- e policy:MessageRule（ｅ ポリシー：メッセージルール）
e policy:Description（ｅ ポリシー：説明）
e policy:PatternToMatch（ｅ ポリシー：一致するパターン）
- e policy:Action（ｅ ポリシー：動作）
+ e policy:Message（ｅ ポリシー：メッセージ）
e policy:Severity（ｅ ポリシー：重大度）
+ e policy:Instrucitons（ｅ ポリシー：命令）
【００６５】
グラフエレメントは、本発明の実施形態による性能解析の経時的なメトリック値を表示するグラフについての情報を定義する。これは、以下のもの、すなわち、１）グラフの名前、説明、又は軸タイトル等のグラフの表示に使用される情報、２）傾向グラフ又は比較グラフ等の所定のグラフパターンの選択肢から選ばれたグラフタイプ、並びに３）グラフに現れるメトリック及び適用されるべきあらゆるインスタンスフィルタを含むが、これらに限定されるものではない。
【００６６】
グラフエレメントの例：
【００６７】
［表８］
- e graph:Graph（ｅ グラフ：グラフ）
a Pattern（ａ パターン）
e graph:GraphName（ｅ グラフ：グラフ名）
e graph:GraphDescription（ｅ グラフ：グラフ説明）
e graph:GraphTitle（ｅ グラフ：グラフタイトル）
- e graph:GraphMetrics（ｅ グラフ：グラフメトリック）
- e graph:GraphMetric（ｅ グラフ：グラフメトリック）
e graph:Class（ｅ グラフ：クラス）
e graph:MetricName（ｅ グラフ：メトリック名）
+ e graph:InstanceFilter（ｅ グラフ：インスタンスフィルタ）
+ e graph:YAxisTitles（ｅ グラフ：Ｙ軸タイトル）
+ e graph:GraphDateRange（ｅ グラフ：グラフ日付範囲）
【００６８】
多くの場合に、命令アナライザは、開発者側のいくつかの作業を軽減する妥当なデフォルトを提供できることが十分理解される。たとえば、ＳＮＭＰポリシーでは、命令アナライザは、開発者用の標準的なエラーメッセージを提供することができる。
【００６９】
結論
本発明の実施形態の多くの例を、企業のインストールの文脈で説明したが、さまざまな実施形態は、企業であるか否かにかかわらずあらゆるタイプの組織のインストールに適用される。
【００７０】
アプリケーションの管理に関する内容を指定し、且つ、インストール管理システムの実施詳細を隠蔽することによって、開発者は、インストール管理システムの知識を必要とすることなく、インストール管理システムを構成することが可能になる。アプリケーションの管理に関する内容を指定し、且つ、インストール管理システムの実施詳細を隠蔽することによって、企業が、異なるインストール管理システムに切り換えることを決定した場合にも、アプリケーションを管理することをインストール管理システムに可能にさせる命令が使用されうる。さらに、さまざまな実施形態によって、開発者には、インストール管理システムを構成する一貫した方法が提供される。インストール管理システムの特定の態様を構成する内容を一箇所で指定することによって、開発者は、冗長な手作業の構成作業を行う必要がない。したがって、さまざまな実施形態によって、開発者は、異なるアプリケーションの一貫した管理ソリューションを迅速且つ容易に作成することが可能になる。
【図面の簡単な説明】
【００７１】
【図１】一実施形態によるインストールに関連するアプリケーションを管理するためのシステムを示す図である。
【図２】一実施形態によるメトリック収集のスキーマを示す図である。
【図３】一実施形態によるタスクをスケジューリングするためのスキーマを示す図である。
【図４】一実施形態によるグラフのスキーマを示す図である。
【図５】本発明の一実施形態による、インストールに関連するアプリケーションを管理するための方法を説明するフローチャートである。
【図６】一実施形態によるルートスキーマのブロック図である。
【符号の説明】
【００７２】
１００ システム
１２０ エディタ
１３０ 命令
１４０ インストール管理システム
１４２ 命令アナライザ
１５０ インストール
１５２、１５４ アプリケーション
１６０ 人
【技術分野】
【０００１】
本発明の実施の形態は、アプリケーションの管理に関する。より詳細には、本発明の実施の形態は、インストールに関連するアプリケーションの管理に関する。
【背景技術】
【０００２】
企業は、通常、異なるタイプの処理を行うための多くの異なるタイプのアプリケーションを有する。これらのアプリケーションは、通常は互いにネットワーク接続されたコンピュータシステム上で実行される。アプリケーション、それらのアプリケーションが実行されるコンピュータシステム、及びそれらのコンピュータシステム間で通信を行うのに使用されるネットワークは、特に、企業の「インストール」として一般に知られているものの一部である。
【０００３】
インストールは、ルータ、ファイアウォール、ロードバランサ等の他のタイプのデバイスを含むことができる。コンピュータシステム及びさまざまなデバイスは、一般に「ノード」とも呼ばれる。
【０００４】
インストールの複雑さが増加するにつれて、インストールを管理するシステム（以下「インストール管理システム」という）の必要性が増大してきている。インストール管理システムの一例は、Hewlett Packard（商標）のオープンビューオペレーションズ（Openview Operations）（ＯＶＯ）である。
【０００５】
インストール管理システムによって行われる管理のタイプの例には、特に、プロセス、ノード、又はソフトウェアが実行されているか否かを判断すること、ノードが有するメモリ量を求めること、ノードのコンピュータ処理ユニット（ＣＰＵ）の稼働率を求めること、アプリケーションの応答時間を求めること、並びにこれらの判断及び求値に基づいて動作を行うことが含まれる。動作を行うことの例には、特に、より多くのメモリをノードに追加すること、ワークロードを再バランスさせること、又は、アプリケーションを再構成することが含まれ得る。
【発明の開示】
【課題を解決するための手段】
【０００６】
添付図面は、本明細書に組み込まれて、本明細書の一部を成す。添付図面は、その説明と共に本発明の実施形態を示し、本発明の原理を説明する役割を果たす。
【０００７】
この説明で参照される図面は、特に注記されている場合を除いて、一律の縮尺で描かれているものと理解されるべきではない。
【発明を実施するための最良の形態】
【０００８】
次に、本発明のさまざまな実施形態を詳細に参照する。
【０００９】
これらのさまざまな実施形態の例は、添付図面に示されている。本発明は、これらの実施形態と共に説明されるが、実施形態は、本発明をこれらの実施形態に限定することを目的とするものではないことが理解されよう。その逆に、本発明は、代替形態、変更形態、及び均等物をカバーすることを目的としている。これらの代替的なもの、変更したもの、及び均等なものは、添付の特許請求の範囲によって画定された本発明の精神及び範囲内に含めることができる。
【００１０】
さらに、本発明の以下の説明では、本発明の徹底した理解を提供するために、多数の具体的な詳細が述べられる。それ以外の場合には、本発明の態様を不必要に分かりにくくしないように、既知の方法、手順、コンポーネント、及び回路は詳細に説明されていない。
【００１１】
概観
従来のインストール管理システムは、インストールに関連するデバイス及びアプリケーションを管理するように「構成」されている。たとえば、開発者は、従来のインストール管理システムを構成する目的でそのインストール管理システムが受け取ることができるポリシー及びテンプレートを作成することができる。開発者は、特に、アプリケーションに関連するさまざまなメトリック（metric）を監視するためのメトリック収集ポリシー及びしきい値ポリシーを作成することができる。また、開発者は、従来のインストール管理システムがタスクのスケジューリングの一部として使用するスケジューリングポリシー、及び、従来のインストール管理システムが収集されたメトリック等のグラフを作成するのに使用するグラフテンプレートを作成することもできる。ポリシー及びテンプレートは、一般に「アーティファクト（artifact）」と呼ばれるものの例である。
【００１２】
従来のインストール管理システムを構成する従来の方法には不利な点がいくつかある。１つ目は、アーティファクトを作成するのに、従来のインストール管理システムについての深い知識が必要とされることである。２つ目は、アーティファクトが特定の従来のインストール管理システムに特有であり、したがって、企業が、異なる従来のインストール管理システムへの切り換えを決定した場合にそれを再利用することができないことである。３つ目は、従来のインストール管理システムが提供するインターフェースが一致しない場合があることである。これによって、アーティファクトを作成する開発者の作業はさらに複雑になる。４つ目は、開発者が、適切なアーティファクトを作成するために冗長な手作業の構成作業を行わなければならない場合があることである。たとえば、特定のメトリックを監視するために、開発者は、特に、冗長な内容を含むスケジュールポリシー、しきい値ポリシー、グラフテンプレートを手作業で作成しなければならない場合がある。上記の理由から、従来のインストール管理システムは、開発者が、異なるアプリケーションに対する一貫した管理ソリューションを作成することを困難にしている。
【００１３】
一実施形態によれば、インストール管理システムにインストールに関連するアプリケーションをどのように管理するかを定めることを可能にさせる命令を記述するための定義を含むアプリケーションモデリング言語が提供される。この定義は、一実施形態によれば、開発者がインストール管理システムについて知る必要なく２つ以上のアプリケーションに対する命令を記述するのに使用することができる。アプリケーションモデリング言語は、「ニュートラルモデリング言語（neutral modeling language）」とも呼ばれる。アプリケーションモデリング言語は、開発者がインストール管理システムについて知る必要がないため、２つ以上のタイプのインストール管理システムの命令を記述するのに使用することができる。
【００１４】
インストール管理システム
インストール管理システムの例には、ＨＰ（商標）のオープンビューオペレーションズ（OpenView Operations）（ＯＶＯ）、ＨＰ（商標）のオープンビューパーフォーマンスマネージャ（OpenView Performance Manager）（ＯＶＯＵ）、及びＢＭＣ（商標）のレメディ（Remedy）が含まれるが、これらに限定されるものではない。異なるインストール管理システムの他の例には、Ｕｎｉｘ（登録商標）用のＨＰ（商標）のオープンビューオペレーションズのバージョン６やバージョン７等、インストール管理システムの異なるバージョンが含まれる。
【００１５】
ＨＰ（商標）のオープンビューオペレーションズ（ＯＶＯ）、ＨＰ（商標）のオープンビューパーフォーマンスマネージャ（ＯＶＯＵ）、及びＢＭＣ（商標）のレメディは、異なる製品の例である。Ｕｎｉｘ（登録商標）用のＨＰ（商標）のオープンビューオペレーションズのバージョン６及びバージョン７は、同じ製品の異なるバージョンの例である。
【００１６】
アプリケーション
本発明のさまざまな実施形態を使用して監視できるアプリケーションの例には、Ｏｒａｃｌｅ（商標）データベース、ＢＥＡ（登録商標）（Bill Edward Alfred Systems（登録商標））ウェブロジックアプリケーションサーバ（WebLogic Application Server）、及びＭｉｃｒｏｓｏｆｔ（商標）エクスチェンジサーバ（Exchange Server）が含まれるが、これらに限定されるものではない。
【００１７】
インストールに関連するアプリケーションを管理するためのシステム
図１は、インストール管理システムの知識を必要としない、一実施形態によるインストールに関連するアプリケーションを管理するためのシステムを示している。図１の機能を表すブロックは、図示したものとは異なって配置することができ、機能を追加して実施することもできるし、本明細書で説明するものよりも少ない機能を実施することもできる。さらに、図１のブロックによって表された機能は、さまざまな方法で組み合わせることができる。システム１００は、ソフトウェア、ハードウェア、ファームウェア、又はこれらの組み合わせを使用して実施することができる。
【００１８】
図１は、人１６０、エディタ１２０、命令１３０、インストール管理システム１４０、及びインストール１５０を示している。インストール管理システム１４０は、命令アナライザ１４２を含む。命令アナライザ１４２は、インストール管理システム１４０の外部に存在することができることが十分理解される。インストール１５０は、特に、アプリケーション１５２及び１５４を含む。人１６０は開発者とすることができる。開発者１６０は、エディタ１２０を使用して、インストール管理システム１４０が受け取る命令１３０を記述することができる。エディタ１２０は、特に、テキストエディタ又は拡張可能マークアップ言語（ＸＭＬ）エディタとすることができる。
【００１９】
一実施形態によれば、開発者１２０は、アプリケーションモデリング言語の定義を使用して命令１３０を記述する。このアプリケーションモデリング言語の定義は、インストール管理システム１４０の知識を必要としない。この定義は、開発者がインストール管理システム１４０を構成するための命令１３０をどのように記述できるかを示すことができる。たとえば、定義は、メトリックを指定できること、メトリックの名前を指定できること、メトリックの値をどれくらいの頻度で取得するか、メトリックの値をどこから取得するか、たとえば特にメトリックのしきい値を指定することによってアプリケーションが監視されることに関連する問題が存在することをメトリックの値が示しているか否か、及び、メトリックの値が問題が存在すること示している場合に何を行うかを示すことができる。また、定義は、内容を指定するためのシンタックス（syntax）を含むこともできる。一実施形態によれば、命令１３０は、ＸＭＬで記述され、１つ又は２つ以上のＸＭＬスキーマは、アプリケーションモデリング言語の定義を指定するのに使用される。ＸＭＬスキーマは、非独占的なフォーマットの一例である。
【００２０】
インストール管理システム１４０は、定義に従って記述された命令１３０を受け取ることができる。インストール管理システム１４０は、命令１３０を使用して、インストール１５０をどのように管理するかを定める。たとえば、インストールアナライザ１４２は、命令を解析して、インストール１５０をどのように管理するかを定めることをインストール管理システム１４０に可能にさせる。
【００２１】
アプリケーションモデリング言語及び定義
どのインストール管理システム１４０が使用されても、物事のタイプ及びそれらの物事を監視する方法は基本的に同じである。たとえば、Ｏｒａｃｌｅ（商標）データベースについては、インストール管理システム１４０がＨＰ（商標）のＯＶＯであるのか、又はＢＭＣ（商標）のレメディであるのかにかかわらず、監視されてグラフ化される一定のメトリックがある。したがって、一実施形態によれば、特定のインストール管理システム１４０に特有の構成の細部は、水面下でハンドリングされる。たとえば、開発者１６０は、ＯＶＯＷが「プロセス監視ポリシー（Process Monitoring Policy）」を使用するのに対して、ＯＶＯＵが「監視ポリシー（Monitor Policy）」を使用することを知る必要はない。開発者が知る必要のあるすべては、Ｏｒａｃｌｅ（商標）データベース等について、たとえば、開発者が、一実施形態に従って、特定のアプリケーションプロセスのどのような監視を欲するのかである。
【００２２】
インストール管理システム１４０を構成する実施詳細を隠蔽することによって、一実施形態によれば、アプリケーションモデリング言語は、２つ以上のインストール管理システム１４０を構成するのに使用することができる。たとえば、さまざまな実施形態を使用して記述された、Ｏｒａｃｌｅ（商標）データベースを監視するための命令１３０は、ＨＰ（商標）のＯＶＯ又はＢＭＣ（商標）のレメディのいずれを構成するのにも容易に使用することができる。
【００２３】
すでに述べたように、一実施形態によれば、インストール１５０に関連するアプリケーション１５２、１５４をどのように管理するかを定めることをインストール管理システム１４０に可能にさせる命令１３０を記述するための定義を含むアプリケーションモデリング言語が提供される。一実施形態によれば、定義は、１つ又は２つ以上のＸＭＬスキーマで提供され、命令１３０はＸＭＬで記述される。ＸＭＬは、開発者１６０に広く知られており、したがって、開発者１６０がインストール管理システム１４０を構成することをより容易にする。
【００２４】
図２は、一実施形態によるメトリック収集のスキーマを示している。メトリック収集スキーマは、どのメトリックを監視するかを指定する命令１３０をどのように記述するかの情報、メトリックをどのように監視するかの情報、問題が存在することをメトリックの値が示している場合に何を行うかの情報等を提供する。たとえば、メトリック収集スキーマは、メトリックの名前（たとえば、「収集名（CollectionName）」）、メトリックの値を収集するためのスケジュール（たとえば、「スケジュール（Schedule）」）、及びメトリックの値を収集するためのコマンドライン（たとえば、「コマンドライン（CommandLine）」）が指定可能であることを示す。また、メトリック収集スキーマは、オプションとして、メトリックの値を収集するための、メトリックの説明（たとえば、「説明（Description）」）及びユーザパスワード等のそのクレデンシャル（credentials）（たとえば、「クレデンシャル（Credentials）」）が指定可能であることも示す。
【００２５】
図３は、一実施形態によるタスクをスケジューリングするためのスキーマを示している。一実施形態によれば、タスクは、開発者１６０がインストール管理システム１４０に規則的なスケジュールで実行して欲しいと思っている或るアクティビティであり、サーバが毎夜アクティブであるか又はタスクを実行しているかを調べて、アプリケーションサーバの任意の新しいインスタンスがデバイスに対して配備されたか否かを調べるためにサーバをピングすること等である。スケジューリングされたタスクスキーマは、たとえば、どのタスクを監視するか、タスクをどのように監視するか等を指定する命令１３０をどのように記述するかについての情報を提供する。たとえば、スケジューリングされたタスクスキーマは、スケジュールの名前（たとえば、「スケジュール（Schedule）」）及びタスクの名前（たとえば、「タスク（Task）」）が指定可能であることを示す。開始メッセージ（StartMessage）、失敗メッセージ（FailureMessage）、成功メッセージ（SuccessMessage）によって、開発者１６０は、たとえば、スケジューリングされたタスクが開始された時、失敗した時、又は成功した時にインストール管理システム１４０のオペレータに向けて表示できるテキストを指定することが可能になる。
【００２６】
図４は、一実施形態によるグラフのスキーマを示している。このグラフスキーマは、グラフがどのように現れるかを指定する命令１３０をどのように記述するかについての情報を提供する。たとえば、グラフスキーマは、クラス（たとえば、クラス（Class））、メトリックの名前（たとえば、メトリック名（MetricName））、メトリックのラベル（たとえば、メトリックラベル（MetricLabel））、及びメトリックの説明（たとえば、メトリック説明（MetricDescription））が指定可能であることを示す。このクラスは、「クラス」、又は、グラフ上に表示されることになるデータが格納されるデータベースに定義されたデータベーステーブルを指す。メトリック名は、グラフ化されるメトリックの名前であり、メトリックラベルは、グラフ上のメトリックにどのラベルを使用するかを示し、メトリック説明は、グラフに使用するメトリックの説明である。２つ以上のメトリックがグラフスキーマにより指定可能である。
【００２７】
また、グラフスキーマは、一実施形態によれば、グラフ名（GraphName）、グラフ説明（GraphDescription）、グラフタイトル（GraphTitle）、グラフカテゴリー（GraphCategory）、グラフメトリック（GraphMetrics）、Ｙ軸タイトル（YAxixTitles）、及びグラフ日付範囲（GraphDateRange）を指定するのに使用することもできる。グラフ名はグラフの名前である。グラフ説明はグラフの説明である。グラフタイトルはグラフのタイトルである。グラフカテゴリーは、グラフが、インストール管理システムに関連するユーザインターフェースを使用して表示されるときにたとえば「グループ」で現れるようにグラフを編成することを可能にする。グラフメトリックはグラフ化されるメトリックである。Ｙ軸タイトルは、Ｙ軸のためのタイトルの指定を可能にする。グラフ日付範囲は、グラフ上に現れる日付の範囲の指定を可能にする。２つ以上のグラフがグラフスキーマによって指定可能であり、２つ以上のメトリックが特定のグラフ上に表示可能である。
【００２８】
グラフが、異なる背景色及びさまざまな線の色を使用することはしばしば行われる。さらに、グラフは、特に、線グラフの場合もあるか又は棒グラフの場合もある。しかしながら、一実施形態によれば、グラフスキーマは、開発者が、たとえば、背景色、線の色、又はグラフのタイプ等の一定のタイプの情報を指定することを必要としない。これは、インストール管理システム１４０全体にわたって一貫性を保証するために、命令アナライザ１４２によって遂行可能であることが十分理解される。
【００２９】
例示の目的で、スキーマの簡単化されたバージョンが図２〜図４に示されている。図２〜図４に示すものよりも多くのエレメントを、図２〜図４に示すスキーマに関連付けることができる。たとえば、メトリック収集スキーマは、しきい値、頻度、及びメトリックの値を得るためのソースを指定することができる。しきい値は、問題が存在することをメトリックの値が示しているか否か判断するのに使用することができ、たとえば、その値がしきい値と一致するか又はしきい値を超えているときを判断するのに使用することができる。頻度は、たとえばソースからメトリックの値をどれくらいの頻度で取得するかを定めるのに使用することができる。別の例では、スケジューリングされたタスクスキーマは、特に、タスクがどれくらいの頻度で実行されるかを指定することができる。さらに別の例では、グラフスキーマは、グラフに現れる可能性のあるデータのインスタンス名についてグラフをフィルタリングするためにフィルタを指定することを可能にすることができる。
【００３０】
さらに、図２〜図４は、ごく僅かなアプリケーションモデリング言語定義を示している。本発明のさまざまな実施形態を使用して実施できる他の多数の定義がある。たとえば、パッケージスキーマは、Ｍｉｃｒｏｓｏｆｔ（商標）Ｗｉｎｄｏｗｓ（登録商標）等のプラットフォームにインストールされるソフトウェアをどのようにパッケージするかについての命令を記述するのに使用することができる。パッケージスキーマは、どのファイルが、パッケージされるソフトウェアを含むか、それらのファイルのロケーション、及びファイルがインストールされるプラットフォームを指定することができる。別の例では、インストール管理システムのシンプルネットワーク管理プロトコル（ＳＮＭＰ）処理を構成する命令をどのように記述するかを指定するスキーマ（ＳＮＭＰスキーマ）が存在し得る。スキーマについてより多くの情報を得るには、以下に含まれる「スキーマについてのより多くの情報」の副題を参照されたい。
【００３１】
すでに述べたように、従来のインストール管理システムでは、開発者は、適切なアーティファクトを作成するために、冗長な手作業の構成作業を行わなければならない場合がある。たとえば、従来のインストール管理システムを使用して特定のメトリックを監視するために、開発者は、特に、冗長な内容を含むスケジュールポリシー、しきい値ポリシー、グラフテンプレートを手作業で作成しなければならない場合がある。しかしながら、一実施形態によれば、インストール管理システムの特定の態様を構成するための内容は、一箇所で指定される。したがって、開発者は、冗長な手作業の構成作業を行う必要はない。たとえば、ポリシーがメトリックについての情報を必要とする場合、そのメトリックについての内容は、ポリシーのための一組の命令に冗長な内容を含めるのではなく、メトリック収集スキーマに基づいて記述された一組の命令から取得することができる。
【００３２】
命令
例示の目的で、図１は、一実施形態による一組の命令１３０を示している。異なる組の命令１３０を使用して、異なるアプリケーション１５２、１５４を管理するようにインストール管理システム１４０を構成することができる。さらに、より明らかになるように、２組以上の命令を使用して、同じアプリケーションの異なる態様を管理するようにインストール管理システム１４０を構成することができる。たとえば、Ｏｒａｃｌｅ（商標）データベースアプリケーション及びＭｉｃｒｏｓｏｆｔ（商標）のＥｘｃｈａｎｇｅ Ｓｅｒｖｅｒの双方は、開発者１６０が監視したい場合があるメトリックを有する。したがって、複数の組の命令１３０を、さまざまなメトリックのメトリック収集スキーマ（図２）に基づいて記述することができる。
【００３３】
一実施形態によれば、定義を使用して、その定義に基づき記述された一組の命令を検証することができる。たとえば、図２に示すメトリック収集スキーマに基づいて記述された一組の命令は、インストール管理システム１４０がメトリック収集スキーマを使用して検証することができる。一組の命令は、「モデルインスタンス」又は「モデルのインスタンス」とも呼ばれる。
【００３４】
インストールに関連するアプリケーションを管理する方法の動作例
図５は、本発明の一実施形態による、インストールに関連するアプリケーションを管理するための方法を説明するフローチャート５００を示している。特定のステップがフローチャート５００に開示されているが、このようなステップは例示である。すなわち、本発明の実施形態は、さまざまな他のステップ又はフローチャート５００に列挙されたステップの変形を実行することによく適している。フローチャート５００のステップは、提示されたものとは異なる順序で実行することができ、フローチャート５００のステップのすべてが実行されるとは限らない場合もあることが十分理解される。
【００３５】
フローチャート５００によって説明される実施形態の全部又は一部は、コンピュータ可読で且つコンピュータ実行可能な命令を使用して実施することができる。これらの命令は、たとえば、コンピュータシステム又は同様のデバイスのコンピュータ使用可能媒体に存在する。上述したように、本発明の一定のプロセス及びステップは、一実施形態では、一連の命令（たとえば、ソフトウェアプログラム）として実現される。この一連の命令は、コンピュータシステムのコンピュータ可読メモリ内に存在し、コンピュータシステムによって実行される。これらの命令は、実行されると、後述するような本発明の機能をコンピュータシステムに実施させる。
【００３６】
ステップ５１０において、この方法は開始する。
【００３７】
ステップ５２０において、インストールに関連するアプリケーションをどのように管理するかを定めることをインストール管理システムに可能にさせる命令が受け取られる。命令１３０は、インストール管理システム１４０の知識を必要とすることなく、２つ以上のアプリケーション１５２及び１５４の命令１３０を記述するのに使用できる定義を指定するアプリケーションモデリング言語に準拠している。図２〜図４に示すスキーマは、命令１３０を記述するのに使用できるアプリケーションモデリング言語によって提供される定義の例である。例示の目的で、一組の命令１３０が、図２に示すスキーマに基づいて特定のアプリケーション１５２の特定のメトリックについて記述され、別の一組の命令１３０が、その同じアプリケーション１５２の別のメトリックの同じスキーマ（図２）に基づいて記述されるものと仮定する。それらの二組の命令は、異なるインストール管理システム１４０を構成するのに使用することができる。たとえば、それらの二組の命令は、ＨＰ（商標）のＯＶＯ又はＢＭＣ（商標）のレメディのいずれを構成するのにも使用することができ、これは、アプリケーションモデリング言語は、開発者１６０がどのインストール管理システム１４０についても知ることを必要としないからである。
【００３８】
開発者１６０は、エディタ１６０を使用して数組の命令１３０を作成することができる。一実施形態によるエディタ１６０はＸＭＬエディタであり、命令１３０はＸＭＬ命令である。インストール管理システム１４０は、数組の命令１３０を含むファイルを受け取ることができる。
【００３９】
ステップ５３０において、命令が解析されて、それによって、インストール管理システムは、アプリケーションをどのように管理するかを定めることが可能になる。たとえば、ステップ５２０で受け取られた数組の命令１３０が解析される。このように、インストール管理システム１４０は、数組の命令が記述されたアプリケーション１５２を監視することが可能になる。
【００４０】
ステップ５４０において、この方法は終了する。
【００４１】
スキーマについてのより多くの情報
以下は、他の可能なスキーマ及びスキーマに関連することができる内容を説明する。たとえば、以下は、さまざまなスキーマに関連することができるさまざまな属性及びタイプを説明する。スキーマの１つは、一実施形態によれば、マスタモデル（MasterModel）である。ＳＰＩ情報（SPIInformation）、グラフファイル（GraphFiles）、ポリシー（Policies）、Ｐｋｇファイル（PkgFiles）、製品（Products）等の一実施形態によるスキーマエレメントは、マスタモデルスキーマの子とすることができる。グラフファイルは、図４に示すグラフスキーマの一例である。ポリシーは、ポリシースキーマの一例である。Ｐｋｇファイルは、パッケージスキーマの一例である。ＳＮＭＰポリシー（SNMPPolicy）は、ＳＮＭＰスキーマの一例である。スケジュールドタスクポリシー（ScheduledTaskPolicy）は、図３に示すスケジューリングタスクスキーマの一例である。外部メトリック収集は、図２に示すメトリック収集スキーマの一例である。
【００４２】
また、一実施形態によるルートスキーマのブロック図を示す図６も参照されたい。図６を参照して、一実施形態によれば、ルートエレメントは、すべてのポリシーに使用される。一実施形態によれば、ＳＰＩ情報は、ファイル名のプレフィックス（prefix）等のＳＰＩアーティファクトに使用される。一実施形態によれば、ポリシー名は、ＳＰＩモデル内で一意であり、収集名（CollectionName）は、ポリシーの名前である。
【００４３】
アプリケーション管理言語の例：
本発明の実施形態によるアプリケーション管理言語の例が、以下のパラグラフで説明される。
【００４４】
メトリックエレメントは、本発明の実施形態によるアプリケーションについて監視されているメトリックについての情報を定義する。この情報は、１）メトリックの名前及び説明、２）メトリックのソース、並びに３）測定の単位を含むが、これらに限定されるものではない。
【００４５】
メトリックエレメントの例：
【００４６】
［表１］
- e policy:Metric（ｅ ポリシー：メトリック）
e policy:MetricName（ｅ ポリシー：メトリック名）
e policy:MetricDescription（ｅ ポリシー：メトリック説明）
e policy:MetricUnit（ｅ ポリシー：メトリック単位）
+ e policy:MetricSource（ｅ ポリシー：メトリックソース）
【００４７】
監視ポリシーエレメントは、本発明の実施形態による管理システムにアプリケーションにより提供される、応答時間又は入力ワークロード等、データの監視についての情報を定義する。この情報は、１）ポリシーの名前及び説明、２）データを監視する間隔、３）状態を判断する数値しきい値又はスクリプトを含む監視する状態、４）監視されるメトリック、５）監視されるオブジェクトインスタンス、並びに６）イベントの重大度（severity）及び問題を処理するために何を行うかについての命令を含む、エラー状態が発生した場合に行う動作を含むが、これらに限定されるものではない。
【００４８】
監視ポリシーエレメントの例：
【００４９】
［表２］
- e policy:MonitorPolicy（ｅ ポリシー：監視ポリシー）
e policy:PolicyName（ｅ ポリシー：ポリシー名）
e policy:PolicyDescription（ｅ ポリシー：ポリシー説明）
- e policy:MinMaxMonitor（ｅ ポリシー：最小最大監視）
a Type（ａ タイプ）
+ e policy:PolicyMetric（ｅ ポリシー：ポリシーメトリック）
- e policy:Rules（ｅ ポリシー：ルール）
- e policy:MinMaxMessageRule（ｅ ポリシー：最小最大メッセージルール）
a UUID
e policy:Description（ｅ ポリシー：説明）
- e policy:Conditions（ｅ ポリシー：状態）
- e policy:Condition（ｅ ポリシー：状態）
e policy:Description（ｅ ポリシー：説明）
- e policy:Actions（ｅ ポリシー：動作）
- e policy:StartAction（ｅ ポリシー：動作開始）
+ e policy:Message（ｅ ポリシー：メッセージ）
e policy:Severity（ｅ ポリシー：重大度）
+ e policy:Instructions（ｅ ポリシー：命令）
+ e policy:ContinueAction（ｅ ポリシー：動作継続）
e policy:EndAction（ｅ ポリシー：動作終了）
e policy:ThresholdLimitValue（ｅ ポリシー：しきい値制限値）
【００５０】
外部収集エレメントは、本発明の実施形態によるインストール管理システムの外部のコレクタからメトリックを収集するのに必要な情報を定義する。この情報は、１）ポリシーの名前及び説明、２）データを収集する間隔、３）データを収集するために実行するコマンドライン、並びに４）収集に必要とされるユーザ／パスワードを含むが、これらに限定されるものではない。
【００５１】
外部収集エレメントの例：
【００５２】
［表３］
- e policy:ExternalMetricCollection（ｅ ポリシー：外部メトリック収集）
e policy:CollectionName（ｅ ポリシー：収集名）
e policy:Description（ｅ ポリシー：説明）
+ e policy:Schedule（ｅ ポリシー：スケジュール）
e policy:CommandLine（ｅ ポリシー：コマンドライン）
+ e policy:Credentials（ｅ ポリシー：クレデンシャル）
【００５３】
ポリシーエレメントを監視するプロセスは、本発明の実施形態による監視するプロセスまたはサービスについての情報を定義する。この情報は、１）ポリシーの名前及び説明、２）プロセスを監視する間隔、３）プロセスの名前、並びに４）イベントの重大度及び問題を処理するために何を行うかについての命令を含む、エラー状態が発生した場合に行う動作を含むが、これらに限定されるものではない。
【００５４】
プロセス監視ポリシーエレメントの例：
【００５５】
［表４］
- e policy:Policies（ｅ ポリシー：ポリシー）
- e policy:ProcessMonitoringPolicy（ｅ ポリシー：プロセス監視ポリシー）
e policy:PolicyName（ｅ ポリシー：ポリシー名）
e policy:PolicyDescription（ｅ ポリシー：ポリシー説明）
+ e policy:ExecutionInterval（ｅ ポリシー：実行間隔）
- e policy:Processes（ｅ ポリシー：プロセス）
- e policy:Process（ｅ ポリシー：プロセス）
+ e policy:ProcessDetail（ｅ ポリシー：プロセス詳細）
+ e policy:ErrorCondition（ｅ ポリシー：エラー状態）
【００５６】
スケジューリングされたタスクポリシーエレメントは、本発明の実施形態による管理システムによって実行されるスクリプト又は実行可能ファイル（executable）についての情報を定義する。この情報は、１）ポリシーの名前及び説明、２）実行を行う間隔（繰り返し間隔又は具体的な時間若しくは具体的な日として定義される）、並びに３）イベントの重大度及び問題を処理するために何を行うかについての命令を含む、タスク実行の開始時、成功時、又は失敗時にオペレータコンソールへ送信されるべきメッセージを含むが、これらに限定されるものではない。
【００５７】
スケジューリングされたタスクポリシーエレメントの例：
【００５８】
［表５］
- e policy:ScheduledTaskPolicy（ｅ ポリシー：スケジュールドタスクポリシー）
e policy:PolicyName（ｅ ポリシー：ポリシー名）
e policy:PolicyDescription（ｅ ポリシー：ポリシー説明）
+ e policy:Schedule（ｅ ポリシー：スケジュール）
+ e policy:Task（ｅ ポリシー：タスク）
- e policy:StartMessage（ｅ ポリシー：開始メッセージ）
+ e policy:Message（ｅ ポリシー：メッセージ）
e policy:Severity（ｅ ポリシー：重大度）
+ e policy:Instrucitons（ｅ ポリシー：命令）
+ e policy:FailureMessage（ｅ ポリシー：失敗メッセージ）
+ e policy:SuccessMessage（ｅ ポリシー：成功メッセージ）
【００５９】
ＳＮＭＰポリシーエレメントは、本発明の実施形態によるメトリックの収集元のＳＮＭＰトラップを定義する。この情報は、１）ポリシーの名前及び説明、２）ＳＮＭＰトラップＩＤ及び監視するトラップをさらに識別する追加ＳＮＭＰ変数、並びに３）監視する状況又は状態及びエラー状態が見つかった場合に行う動作を指定する一組のルールを含むが、これらに限定されるものではない。この動作には、状態の重大度、及び問題を処理するために何を行うかについての命令のような物事が含まれる。
【００６０】
ＳＮＭＰポリシーエレメントの例：
【００６１】
［表６］
- e policy:SNMPPolicy（ｅ ポリシー：ＳＮＭＰポリシー）
e policy:PolicyName（ｅ ポリシー：ポリシー名）
e policy:PolicyDescription（ｅ ポリシー：ポリシー説明）
- e policy:Rules（ｅ ポリシー：ルール）
- e policy:MessageRule（ｅ ポリシー：メッセージルール）
e policy:Description（ｅ ポリシー：説明）
- e policy:Condition（ｅ ポリシー：状態）
e policy:EventObjectId（ｅ ポリシー：イベントオブジェクトＩｄ）
+ e policy:VariableBinding（ｅ ポリシー：変数バインディング）
- e policy:Action（ｅ ポリシー：動作）
+ e policy:Message（ｅ ポリシー：メッセージ）
e policy:Severity（ｅ ポリシー：重大度）
+ e policy:Instrucitons（ｅ ポリシー：命令）
【００６２】
ログファイル（Logfile）エレメントは、本発明の実施形態によるアプリケーションログファイルを監視することについての情報を定義する。この情報は、１）ポリシーの名前及び説明、２）ログファイルロケーション、並びに３）監視する状態を指定する１つ又は２つ以上のルール（ログファイル内のテキストパターンの存在）、並びに３）状態の重大度、及び問題を処理するために何を行うかについての命令のようなものを含む、エラー状態が見つかった場合に行う動作を含むが、これらに限定されるものではない。
【００６３】
ログファイルエレメントの例：
【００６４】
［表７］
- e policy:LogPolicy（ｅ ポリシー：ログポリシー）
e policy:PolicyName（ｅ ポリシー：ポリシー名）
e policy:PolicyDescription（ｅ ポリシー：ポリシー説明）
+ e policy:LogFile（ｅ ポリシー：ログファイル）
- e policy:Rules（ｅ ポリシー：ルール）
- e policy:MessageRule（ｅ ポリシー：メッセージルール）
e policy:Description（ｅ ポリシー：説明）
e policy:PatternToMatch（ｅ ポリシー：一致するパターン）
- e policy:Action（ｅ ポリシー：動作）
+ e policy:Message（ｅ ポリシー：メッセージ）
e policy:Severity（ｅ ポリシー：重大度）
+ e policy:Instrucitons（ｅ ポリシー：命令）
【００６５】
グラフエレメントは、本発明の実施形態による性能解析の経時的なメトリック値を表示するグラフについての情報を定義する。これは、以下のもの、すなわち、１）グラフの名前、説明、又は軸タイトル等のグラフの表示に使用される情報、２）傾向グラフ又は比較グラフ等の所定のグラフパターンの選択肢から選ばれたグラフタイプ、並びに３）グラフに現れるメトリック及び適用されるべきあらゆるインスタンスフィルタを含むが、これらに限定されるものではない。
【００６６】
グラフエレメントの例：
【００６７】
［表８］
- e graph:Graph（ｅ グラフ：グラフ）
a Pattern（ａ パターン）
e graph:GraphName（ｅ グラフ：グラフ名）
e graph:GraphDescription（ｅ グラフ：グラフ説明）
e graph:GraphTitle（ｅ グラフ：グラフタイトル）
- e graph:GraphMetrics（ｅ グラフ：グラフメトリック）
- e graph:GraphMetric（ｅ グラフ：グラフメトリック）
e graph:Class（ｅ グラフ：クラス）
e graph:MetricName（ｅ グラフ：メトリック名）
+ e graph:InstanceFilter（ｅ グラフ：インスタンスフィルタ）
+ e graph:YAxisTitles（ｅ グラフ：Ｙ軸タイトル）
+ e graph:GraphDateRange（ｅ グラフ：グラフ日付範囲）
【００６８】
多くの場合に、命令アナライザは、開発者側のいくつかの作業を軽減する妥当なデフォルトを提供できることが十分理解される。たとえば、ＳＮＭＰポリシーでは、命令アナライザは、開発者用の標準的なエラーメッセージを提供することができる。
【００６９】
結論
本発明の実施形態の多くの例を、企業のインストールの文脈で説明したが、さまざまな実施形態は、企業であるか否かにかかわらずあらゆるタイプの組織のインストールに適用される。
【００７０】
アプリケーションの管理に関する内容を指定し、且つ、インストール管理システムの実施詳細を隠蔽することによって、開発者は、インストール管理システムの知識を必要とすることなく、インストール管理システムを構成することが可能になる。アプリケーションの管理に関する内容を指定し、且つ、インストール管理システムの実施詳細を隠蔽することによって、企業が、異なるインストール管理システムに切り換えることを決定した場合にも、アプリケーションを管理することをインストール管理システムに可能にさせる命令が使用されうる。さらに、さまざまな実施形態によって、開発者には、インストール管理システムを構成する一貫した方法が提供される。インストール管理システムの特定の態様を構成する内容を一箇所で指定することによって、開発者は、冗長な手作業の構成作業を行う必要がない。したがって、さまざまな実施形態によって、開発者は、異なるアプリケーションの一貫した管理ソリューションを迅速且つ容易に作成することが可能になる。
【図面の簡単な説明】
【００７１】
【図１】一実施形態によるインストールに関連するアプリケーションを管理するためのシステムを示す図である。
【図２】一実施形態によるメトリック収集のスキーマを示す図である。
【図３】一実施形態によるタスクをスケジューリングするためのスキーマを示す図である。
【図４】一実施形態によるグラフのスキーマを示す図である。
【図５】本発明の一実施形態による、インストールに関連するアプリケーションを管理するための方法を説明するフローチャートである。
【図６】一実施形態によるルートスキーマのブロック図である。
【符号の説明】
【００７２】
１００ システム
１２０ エディタ
１３０ 命令
１４０ インストール管理システム
１４２ 命令アナライザ
１５０ インストール
１５２、１５４ アプリケーション
１６０ 人
【特許請求の範囲】
【請求項１】
インストールに関連するアプリケーションを管理する方法であって、
前記インストールに関連するアプリケーションをどのように管理するかを定めることをインストール管理システムに可能にさせる命令を受け取ることであって、該命令は、前記インストール管理システムの知識を必要とすることなく、２つ以上のアプリケーションの命令を記述するのに使用できる定義を指定するアプリケーションモデリング言語に準拠していることと、
前記命令を解析することであって、それによって、前記アプリケーションをどのように管理するかを定めることを前記インストール管理システムに可能にさせることと
を含む方法。
【請求項２】
前記インストール管理システムは、第１のインストール管理システムであり、
前記インストールに関連する前記アプリケーションをどのように管理するかを定める第２のインストール管理システムにおいて前記命令を受け取ることと、
前記命令を解析することであって、それによって、前記アプリケーションをどのように管理するかを定めることを前記第２のインストール管理システムに可能にさせることと
をさらに含む請求項１に記載の方法。
【請求項３】
前記第１のインストール管理システム及び前記第２のインストール管理システムは、同じ製品の異なるバージョン又は異なる製品の１つである
請求項２に記載の方法。
【請求項４】
前記インストールに関連する前記アプリケーションをどのように管理するかを定めることを前記インストール管理システムに可能にさせる前記命令を前記受け取ることであって、該命令は前記定義を指定する前記アプリケーションモデリング言語に準拠していることは、
前記定義を指定する前記アプリケーションモデリング言語に準拠している前記命令を受け取ることであって、該定義は、拡張可能マークアップ言語（ＸＭＬ）スキーマであること
をさらに含む
請求項１に記載の方法。
【請求項５】
前記命令を確かめるために前記命令を使用すること
をさらに含む請求項１に記載の方法。
【請求項６】
前記インストールに関連する前記アプリケーションをどのように管理するかを定めることを前記インストール管理システムに可能にさせる前記命令を前記受け取ることであって、該命令は前記定義を指定する前記アプリケーションモデリング言語に準拠していることは、
前記定義を指定する前記アプリケーションモデリング言語に準拠している前記命令を受け取ることであって、前記アプリケーションモデリング言語の特定の態様を構成するための内容が１つの定義において指定されること
をさらに含む
請求項１に記載の方法。
【請求項７】
前記インストールに関連する前記アプリケーションをどのように管理するかを定めることを前記インストール管理システムに可能にさせる前記命令を前記受け取ることであって、該命令は定義を指定する前記アプリケーションモデリング言語に準拠していることは、
前記定義を指定する前記アプリケーションモデリング言語に準拠している前記命令を受け取ることであって、該定義は、前記インストール管理システムの実施詳細を隠蔽しながら前記アプリケーションに関する内容をどのように指定できるかを示すこと
をさらに含む
請求項１に記載の方法。
【請求項８】
アプリケーションモデリング言語であって、
インストールに関連するアプリケーションをどのように管理するかを定めることをインストール管理システムに可能にさせる命令を記述するための定義
を含み、
前記定義は、前記インストール管理システムの知識を必要とすることなく、２つ以上のアプリケーションの命令を記述するのに使用することができる
アプリケーションモデリング言語。
【請求項９】
前記定義は、拡張可能マークアップ言語（ＸＭＬ）スキーマである
請求項８に記載のアプリケーションモデリング言語。
【請求項１０】
前記定義は、
別の定義
を含む
請求項８に記載のアプリケーションモデリング言語。
【請求項１１】
前記定義は、メトリック収集、監視ポリシー、外部収集エレメント、プロセス監視ポリシー、スケジューリングされたタスクポリシー、ＳＮＭＰポリシー、ログファイルエレメント、グラフエレメント、及びスケジューリングされたタスクから成る群から選択される
請求項８に記載のアプリケーションモデリング言語。
【請求項１２】
前記定義は、前記アプリケーションモデリング言語の特定の態様を構成するための内容を指定することを可能にし、
別の定義は、同じ内容を指定することを必要とされない
請求項８に記載のアプリケーションモデリング言語。
【請求項１３】
前記定義は、前記インストール管理システムの実施詳細を隠蔽しながら前記アプリケーションに関する内容をどのように指定できるかを示す
請求項８に記載のアプリケーションモデリング言語。
【請求項１４】
インストールに関連するアプリケーションを管理する方法をコンピュータシステムに実行させるためのコンピュータ可読プログラムコードが具現化されるコンピュータ使用可能媒体であって、
前記方法は、
前記インストールに関連するアプリケーションをどのように管理するかを定めることをインストール管理システムに可能にさせる命令を受け取ることであって、該命令は、前記インストール管理システムの知識を必要とすることなく、２つ以上のアプリケーションの命令を記述するのに使用できる定義を指定するアプリケーションモデリング言語に準拠していることと、
前記命令を解析することであって、それによって、前記アプリケーションをどのように管理するかを定めることを前記インストール管理システムに可能にさせることと
を含む
コンピュータ使用可能媒体。
【請求項１５】
前記コンピュータ使用可能媒体に具現化される前記コンピュータ可読プログラムコードは、前記コンピュータシステムに前記方法を実行させ、前記インストール管理システムは第１のインストール管理システムであり、
前記方法は、
前記インストールに関連する前記アプリケーションをどのように管理するかを定める第２のインストール管理システムにおいて前記命令を受け取ること、及び
前記命令を解析することであって、それによって、前記アプリケーションをどのように管理するかを定めることを前記第２のインストール管理システムに可能にさせること
をさらに含む
請求項１４に記載の方法。
【請求項１６】
前記コンピュータ使用可能媒体に具現化される前記コンピュータ可読プログラムコードは、前記コンピュータシステムに前記方法を実行させ、
前記第１のインストール管理システム及び前記第２のインストール管理システムは、同じ製品の異なるバージョン又は異なる製品の１つである
請求項１５に記載の方法。
【請求項１７】
前記コンピュータ使用可能媒体に具現化される前記コンピュータ可読プログラムコードは、コンピュータシステムに前記方法を実行させ、
前記インストールに関連する前記アプリケーションをどのように管理するかを定めることを前記インストール管理システムに可能にさせる前記命令を前記受け取ることであって、該命令は前記定義を指定する前記アプリケーションモデリング言語に準拠していることは、
前記定義を指定する前記アプリケーションモデリング言語に準拠している前記命令を受け取ることであって、該定義は、非独占的なフォーマットであること
をさらに含む
請求項１４に記載の方法。
【請求項１８】
前記コンピュータ使用可能媒体に具現化される前記コンピュータ可読プログラムコードは、コンピュータシステムに前記方法を実行させ、
前記方法は、
前記命令を確かめるために前記定義を使用すること
をさらに含む
請求項１４に記載の方法。
【請求項１９】
前記コンピュータ使用可能媒体に具現化される前記コンピュータ可読プログラムコードは、コンピュータシステムに前記方法を実行させ、
前記インストールに関連する前記アプリケーションをどのように管理するかを定めることを前記インストール管理システムに可能にさせる前記命令を前記受け取ることであって、該命令は前記定義を指定する前記アプリケーションモデリング言語に準拠していることは、
前記定義を指定する前記アプリケーションモデリング言語に準拠している前記命令を受け取ることであって、前記アプリケーションモデリング言語の特定の態様を構成するための内容が１つの定義において指定されること
をさらに含む
請求項１４に記載の方法。
【請求項２０】
前記コンピュータ使用可能媒体に具現化される前記コンピュータ可読プログラムコードは、コンピュータシステムに前記方法を実行させ、
前記インストールに関連する前記アプリケーションをどのように管理するかを定めることを前記インストール管理システムに可能にさせる前記命令を前記受け取ることであって、該命令は前記定義を指定する前記アプリケーションモデリング言語に準拠していることは、
前記定義を指定する前記アプリケーションモデリング言語に準拠している前記命令を受け取ることであって、該定義は、前記インストール管理システムの実施詳細を隠蔽しながら前記アプリケーションに関する内容をどのように指定できるかを示すこと
をさらに含む
請求項１４に記載の方法。
【請求項１】
インストールに関連するアプリケーションを管理する方法であって、
前記インストールに関連するアプリケーションをどのように管理するかを定めることをインストール管理システムに可能にさせる命令を受け取ることであって、該命令は、前記インストール管理システムの知識を必要とすることなく、２つ以上のアプリケーションの命令を記述するのに使用できる定義を指定するアプリケーションモデリング言語に準拠していることと、
前記命令を解析することであって、それによって、前記アプリケーションをどのように管理するかを定めることを前記インストール管理システムに可能にさせることと
を含む方法。
【請求項２】
前記インストール管理システムは、第１のインストール管理システムであり、
前記インストールに関連する前記アプリケーションをどのように管理するかを定める第２のインストール管理システムにおいて前記命令を受け取ることと、
前記命令を解析することであって、それによって、前記アプリケーションをどのように管理するかを定めることを前記第２のインストール管理システムに可能にさせることと
をさらに含む請求項１に記載の方法。
【請求項３】
前記第１のインストール管理システム及び前記第２のインストール管理システムは、同じ製品の異なるバージョン又は異なる製品の１つである
請求項２に記載の方法。
【請求項４】
前記インストールに関連する前記アプリケーションをどのように管理するかを定めることを前記インストール管理システムに可能にさせる前記命令を前記受け取ることであって、該命令は前記定義を指定する前記アプリケーションモデリング言語に準拠していることは、
前記定義を指定する前記アプリケーションモデリング言語に準拠している前記命令を受け取ることであって、該定義は、拡張可能マークアップ言語（ＸＭＬ）スキーマであること
をさらに含む
請求項１に記載の方法。
【請求項５】
前記命令を確かめるために前記命令を使用すること
をさらに含む請求項１に記載の方法。
【請求項６】
前記インストールに関連する前記アプリケーションをどのように管理するかを定めることを前記インストール管理システムに可能にさせる前記命令を前記受け取ることであって、該命令は前記定義を指定する前記アプリケーションモデリング言語に準拠していることは、
前記定義を指定する前記アプリケーションモデリング言語に準拠している前記命令を受け取ることであって、前記アプリケーションモデリング言語の特定の態様を構成するための内容が１つの定義において指定されること
をさらに含む
請求項１に記載の方法。
【請求項７】
前記インストールに関連する前記アプリケーションをどのように管理するかを定めることを前記インストール管理システムに可能にさせる前記命令を前記受け取ることであって、該命令は定義を指定する前記アプリケーションモデリング言語に準拠していることは、
前記定義を指定する前記アプリケーションモデリング言語に準拠している前記命令を受け取ることであって、該定義は、前記インストール管理システムの実施詳細を隠蔽しながら前記アプリケーションに関する内容をどのように指定できるかを示すこと
をさらに含む
請求項１に記載の方法。
【請求項８】
アプリケーションモデリング言語であって、
インストールに関連するアプリケーションをどのように管理するかを定めることをインストール管理システムに可能にさせる命令を記述するための定義
を含み、
前記定義は、前記インストール管理システムの知識を必要とすることなく、２つ以上のアプリケーションの命令を記述するのに使用することができる
アプリケーションモデリング言語。
【請求項９】
前記定義は、拡張可能マークアップ言語（ＸＭＬ）スキーマである
請求項８に記載のアプリケーションモデリング言語。
【請求項１０】
前記定義は、
別の定義
を含む
請求項８に記載のアプリケーションモデリング言語。
【請求項１１】
前記定義は、メトリック収集、監視ポリシー、外部収集エレメント、プロセス監視ポリシー、スケジューリングされたタスクポリシー、ＳＮＭＰポリシー、ログファイルエレメント、グラフエレメント、及びスケジューリングされたタスクから成る群から選択される
請求項８に記載のアプリケーションモデリング言語。
【請求項１２】
前記定義は、前記アプリケーションモデリング言語の特定の態様を構成するための内容を指定することを可能にし、
別の定義は、同じ内容を指定することを必要とされない
請求項８に記載のアプリケーションモデリング言語。
【請求項１３】
前記定義は、前記インストール管理システムの実施詳細を隠蔽しながら前記アプリケーションに関する内容をどのように指定できるかを示す
請求項８に記載のアプリケーションモデリング言語。
【請求項１４】
インストールに関連するアプリケーションを管理する方法をコンピュータシステムに実行させるためのコンピュータ可読プログラムコードが具現化されるコンピュータ使用可能媒体であって、
前記方法は、
前記インストールに関連するアプリケーションをどのように管理するかを定めることをインストール管理システムに可能にさせる命令を受け取ることであって、該命令は、前記インストール管理システムの知識を必要とすることなく、２つ以上のアプリケーションの命令を記述するのに使用できる定義を指定するアプリケーションモデリング言語に準拠していることと、
前記命令を解析することであって、それによって、前記アプリケーションをどのように管理するかを定めることを前記インストール管理システムに可能にさせることと
を含む
コンピュータ使用可能媒体。
【請求項１５】
前記コンピュータ使用可能媒体に具現化される前記コンピュータ可読プログラムコードは、前記コンピュータシステムに前記方法を実行させ、前記インストール管理システムは第１のインストール管理システムであり、
前記方法は、
前記インストールに関連する前記アプリケーションをどのように管理するかを定める第２のインストール管理システムにおいて前記命令を受け取ること、及び
前記命令を解析することであって、それによって、前記アプリケーションをどのように管理するかを定めることを前記第２のインストール管理システムに可能にさせること
をさらに含む
請求項１４に記載の方法。
【請求項１６】
前記コンピュータ使用可能媒体に具現化される前記コンピュータ可読プログラムコードは、前記コンピュータシステムに前記方法を実行させ、
前記第１のインストール管理システム及び前記第２のインストール管理システムは、同じ製品の異なるバージョン又は異なる製品の１つである
請求項１５に記載の方法。
【請求項１７】
前記コンピュータ使用可能媒体に具現化される前記コンピュータ可読プログラムコードは、コンピュータシステムに前記方法を実行させ、
前記インストールに関連する前記アプリケーションをどのように管理するかを定めることを前記インストール管理システムに可能にさせる前記命令を前記受け取ることであって、該命令は前記定義を指定する前記アプリケーションモデリング言語に準拠していることは、
前記定義を指定する前記アプリケーションモデリング言語に準拠している前記命令を受け取ることであって、該定義は、非独占的なフォーマットであること
をさらに含む
請求項１４に記載の方法。
【請求項１８】
前記コンピュータ使用可能媒体に具現化される前記コンピュータ可読プログラムコードは、コンピュータシステムに前記方法を実行させ、
前記方法は、
前記命令を確かめるために前記定義を使用すること
をさらに含む
請求項１４に記載の方法。
【請求項１９】
前記コンピュータ使用可能媒体に具現化される前記コンピュータ可読プログラムコードは、コンピュータシステムに前記方法を実行させ、
前記インストールに関連する前記アプリケーションをどのように管理するかを定めることを前記インストール管理システムに可能にさせる前記命令を前記受け取ることであって、該命令は前記定義を指定する前記アプリケーションモデリング言語に準拠していることは、
前記定義を指定する前記アプリケーションモデリング言語に準拠している前記命令を受け取ることであって、前記アプリケーションモデリング言語の特定の態様を構成するための内容が１つの定義において指定されること
をさらに含む
請求項１４に記載の方法。
【請求項２０】
前記コンピュータ使用可能媒体に具現化される前記コンピュータ可読プログラムコードは、コンピュータシステムに前記方法を実行させ、
前記インストールに関連する前記アプリケーションをどのように管理するかを定めることを前記インストール管理システムに可能にさせる前記命令を前記受け取ることであって、該命令は前記定義を指定する前記アプリケーションモデリング言語に準拠していることは、
前記定義を指定する前記アプリケーションモデリング言語に準拠している前記命令を受け取ることであって、該定義は、前記インストール管理システムの実施詳細を隠蔽しながら前記アプリケーションに関する内容をどのように指定できるかを示すこと
をさらに含む
請求項１４に記載の方法。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図２】
【図３】
【図４】
【図５】
【図６】
【公開番号】特開２００８−１０８２４１（Ｐ２００８−１０８２４１Ａ）
【公開日】平成２０年５月８日（２００８．５．８）
【国際特許分類】
【外国語出願】
【出願番号】特願２００７−２４６４３１（Ｐ２００７−２４６４３１）
【出願日】平成１９年９月２５日（２００７．９．２５）
【出願人】（５０３００３８５４）ヒューレット−パッカード デベロップメント カンパニー エル．ピー． (1,145)
【Ｆターム（参考）】
【公開日】平成２０年５月８日（２００８．５．８）
【国際特許分類】
【出願番号】特願２００７−２４６４３１（Ｐ２００７−２４６４３１）
【出願日】平成１９年９月２５日（２００７．９．２５）
【出願人】（５０３００３８５４）ヒューレット−パッカード デベロップメント カンパニー エル．ピー． (1,145)
【Ｆターム（参考）】
[ Back to top ]