(57)【要約】【課題】本発明は、インストールに関連するアプリケーションを管理するために提供される。【解決手段】インストールに関連するアプリケーションをどのように管理するかを定めることをインストール管理システムに可能にさせる命令が受け取られる。命令は、インストール管理システムの知識を必要とすることなく、２つ以上のアプリケーションの命令を記述するのに使用できる定義を指定するアプリケーションモデリング言語に準拠している。命令が解析されることにより、インストール管理システムは、アプリケーションをどのように管理するかを定めることが可能になる。【選択図】図１
2008108241.tif 000002
【特許請求の範囲】
【請求項１】
インストールに関連するアプリケーションを管理する方法であって、
前記インストールに関連するアプリケーションをどのように管理するかを定めることをインストール管理システムに可能にさせる命令を受け取ることであって、該命令は、前記インストール管理システムの知識を必要とすることなく、２つ以上のアプリケーションの命令を記述するのに使用できる定義を指定するアプリケーションモデリング言語に準拠していることと、
前記命令を解析することであって、それによって、前記アプリケーションをどのように管理するかを定めることを前記インストール管理システムに可能にさせることと
を含む方法。
【請求項２】
前記インストール管理システムは、第１のインストール管理システムであり、
前記インストールに関連する前記アプリケーションをどのように管理するかを定める第２のインストール管理システムにおいて前記命令を受け取ることと、
前記命令を解析することであって、それによって、前記アプリケーションをどのように管理するかを定めることを前記第２のインストール管理システムに可能にさせることと
をさらに含む請求項１に記載の方法。
【請求項３】
前記第１のインストール管理システム及び前記第２のインストール管理システムは、同じ製品の異なるバージョン又は異なる製品の１つである
請求項２に記載の方法。
【請求項４】
前記インストールに関連する前記アプリケーションをどのように管理するかを定めることを前記インストール管理システムに可能にさせる前記命令を前記受け取ることであって、該命令は前記定義を指定する前記アプリケーションモデリング言語に準拠していることは、
前記定義を指定する前記アプリケーションモデリング言語に準拠している前記命令を受け取ることであって、該定義は、拡張可能マークアップ言語（ＸＭＬ）スキーマであること
をさらに含む
請求項１に記載の方法。
【請求項５】
前記命令を確かめるために前記命令を使用すること
をさらに含む請求項１に記載の方法。
【請求項６】
前記インストールに関連する前記アプリケーションをどのように管理するかを定めることを前記インストール管理システムに可能にさせる前記命令を前記受け取ることであって、該命令は前記定義を指定する前記アプリケーションモデリング言語に準拠していることは、
前記定義を指定する前記アプリケーションモデリング言語に準拠している前記命令を受け取ることであって、前記アプリケーションモデリング言語の特定の態様を構成するための内容が１つの定義において指定されること
をさらに含む
請求項１に記載の方法。
【請求項７】
前記インストールに関連する前記アプリケーションをどのように管理するかを定めることを前記インストール管理システムに可能にさせる前記命令を前記受け取ることであって、該命令は定義を指定する前記アプリケーションモデリング言語に準拠していることは、
前記定義を指定する前記アプリケーションモデリング言語に準拠している前記命令を受け取ることであって、該定義は、前記インストール管理システムの実施詳細を隠蔽しながら前記アプリケーションに関する内容をどのように指定できるかを示すこと
をさらに含む
請求項１に記載の方法。
【請求項８】
アプリケーションモデリング言語であって、
インストールに関連するアプリケーションをどのように管理するかを定めることをインストール管理システムに可能にさせる命令を記述するための定義
を含み、
前記定義は、前記インストール管理システムの知識を必要とすることなく、２つ以上のアプリケーションの命令を記述するのに使用することができる
アプリケーションモデリング言語。
【請求項９】
前記定義は、拡張可能マークアップ言語（ＸＭＬ）スキーマである
請求項８に記載のアプリケーションモデリング言語。
【請求項１０】
前記定義は、
別の定義
を含む
請求項８に記載のアプリケーションモデリング言語。
【請求項１１】
前記定義は、メトリック収集、監視ポリシー、外部収集エレメント、プロセス監視ポリシー、スケジューリングされたタスクポリシー、ＳＮＭＰポリシー、ログファイルエレメント、グラフエレメント、及びスケジューリングされたタスクから成る群から選択される
請求項８に記載のアプリケーションモデリング言語。
【請求項１２】
前記定義は、前記アプリケーションモデリング言語の特定の態様を構成するための内容を指定することを可能にし、
別の定義は、同じ内容を指定することを必要とされない
請求項８に記載のアプリケーションモデリング言語。
【請求項１３】
前記定義は、前記インストール管理システムの実施詳細を隠蔽しながら前記アプリケーションに関する内容をどのように指定できるかを示す
請求項８に記載のアプリケーションモデリング言語。
【請求項１４】
インストールに関連するアプリケーションを管理する方法をコンピュータシステムに実行させるためのコンピュータ可読プログラムコードが具現化されるコンピュータ使用可能媒体であって、
前記方法は、
前記インストールに関連するアプリケーションをどのように管理するかを定めることをインストール管理システムに可能にさせる命令を受け取ることであって、該命令は、前記インストール管理システムの知識を必要とすることなく、２つ以上のアプリケーションの命令を記述するのに使用できる定義を指定するアプリケーションモデリング言語に準拠していることと、
前記命令を解析することであって、それによって、前記アプリケーションをどのように管理するかを定めることを前記インストール管理システムに可能にさせることと
を含む
コンピュータ使用可能媒体。
【請求項１５】
前記コンピュータ使用可能媒体に具現化される前記コンピュータ可読プログラムコードは、前記コンピュータシステムに前記方法を実行させ、前記インストール管理システムは第１のインストール管理システムであり、
前記方法は、
前記インストールに関連する前記アプリケーションをどのように管理するかを定める第２のインストール管理システムにおいて前記命令を受け取ること、及び
前記命令を解析することであって、それによって、前記アプリケーションをどのように管理するかを定めることを前記第２のインストール管理システムに可能にさせること
をさらに含む
請求項１４に記載の方法。
【請求項１６】
前記コンピュータ使用可能媒体に具現化される前記コンピュータ可読プログラムコードは、前記コンピュータシステムに前記方法を実行させ、
前記第１のインストール管理システム及び前記第２のインストール管理システムは、同じ製品の異なるバージョン又は異なる製品の１つである
請求項１５に記載の方法。
【請求項１７】
前記コンピュータ使用可能媒体に具現化される前記コンピュータ可読プログラムコードは、コンピュータシステムに前記方法を実行させ、
前記インストールに関連する前記アプリケーションをどのように管理するかを定めることを前記インストール管理システムに可能にさせる前記命令を前記受け取ることであって、該命令は前記定義を指定する前記アプリケーションモデリング言語に準拠していることは、
前記定義を指定する前記アプリケーションモデリング言語に準拠している前記命令を受け取ることであって、該定義は、非独占的なフォーマットであること
をさらに含む
請求項１４に記載の方法。
【請求項１８】
前記コンピュータ使用可能媒体に具現化される前記コンピュータ可読プログラムコードは、コンピュータシステムに前記方法を実行させ、
前記方法は、
前記命令を確かめるために前記定義を使用すること
をさらに含む
請求項１４に記載の方法。
【請求項１９】
前記コンピュータ使用可能媒体に具現化される前記コンピュータ可読プログラムコードは、コンピュータシステムに前記方法を実行させ、
前記インストールに関連する前記アプリケーションをどのように管理するかを定めることを前記インストール管理システムに可能にさせる前記命令を前記受け取ることであって、該命令は前記定義を指定する前記アプリケーションモデリング言語に準拠していることは、
前記定義を指定する前記アプリケーションモデリング言語に準拠している前記命令を受け取ることであって、前記アプリケーションモデリング言語の特定の態様を構成するための内容が１つの定義において指定されること
をさらに含む
請求項１４に記載の方法。
【請求項２０】
前記コンピュータ使用可能媒体に具現化される前記コンピュータ可読プログラムコードは、コンピュータシステムに前記方法を実行させ、
前記インストールに関連する前記アプリケーションをどのように管理するかを定めることを前記インストール管理システムに可能にさせる前記命令を前記受け取ることであって、該命令は前記定義を指定する前記アプリケーションモデリング言語に準拠していることは、
前記定義を指定する前記アプリケーションモデリング言語に準拠している前記命令を受け取ることであって、該定義は、前記インストール管理システムの実施詳細を隠蔽しながら前記アプリケーションに関する内容をどのように指定できるかを示すこと
をさらに含む
請求項１４に記載の方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明の実施の形態は、アプリケーションの管理に関する。より詳細には、本発明の実施の形態は、インストールに関連するアプリケーションの管理に関する。
【背景技術】
【０００２】
企業は、通常、異なるタイプの処理を行うための多くの異なるタイプのアプリケーションを有する。これらのアプリケーションは、通常は互いにネットワーク接続されたコンピュータシステム上で実行される。アプリケーション、それらのアプリケーションが実行されるコンピュータシステム、及びそれらのコンピュータシステム間で通信を行うのに使用されるネットワークは、特に、企業の「インストール」として一般に知られているものの一部である。
【０００３】
インストールは、ルータ、ファイアウォール、ロードバランサ等の他のタイプのデバイスを含むことができる。コンピュータシステム及びさまざまなデバイスは、一般に「ノード」とも呼ばれる。
【０００４】
インストールの複雑さが増加するにつれて、インストールを管理するシステム（以下「インストール管理システム」という）の必要性が増大してきている。インストール管理システムの一例は、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（ｅ  グラフ：グラフ日付範囲）
【００６８】
多くの場合に、命令アナライザは、開発者側のいくつかの作業を軽減する妥当なデフォルトを提供できることが十分理解される。たとえば、ＳＮＭＰポリシーでは、命令アナライザは、開発者用の標準的なエラーメッセージを提供することができる。
【００６９】
結論
本発明の実施形態の多くの例を、企業のインストールの文脈で説明したが、さまざまな実施形態は、企業であるか否かにかかわらずあらゆるタイプの組織のインストールに適用される。
【００７０】
アプリケーションの管理に関する内容を指定し、且つ、インストール管理システムの実施詳細を隠蔽することによって、開発者は、インストール管理システムの知識を必要とすることなく、インストール管理システムを構成することが可能になる。アプリケーションの管理に関する内容を指定し、且つ、インストール管理システムの実施詳細を隠蔽することによって、企業が、異なるインストール管理システムに切り換えることを決定した場合にも、アプリケーションを管理することをインストール管理システムに可能にさせる命令が使用されうる。さらに、さまざまな実施形態によって、開発者には、インストール管理システムを構成する一貫した方法が提供される。インストール管理システムの特定の態様を構成する内容を一箇所で指定することによって、開発者は、冗長な手作業の構成作業を行う必要がない。したがって、さまざまな実施形態によって、開発者は、異なるアプリケーションの一貫した管理ソリューションを迅速且つ容易に作成することが可能になる。
【図面の簡単な説明】
【００７１】
【図１】一実施形態によるインストールに関連するアプリケーションを管理するためのシステムを示す図である。
【図２】一実施形態によるメトリック収集のスキーマを示す図である。
【図３】一実施形態によるタスクをスケジューリングするためのスキーマを示す図である。
【図４】一実施形態によるグラフのスキーマを示す図である。
【図５】本発明の一実施形態による、インストールに関連するアプリケーションを管理するための方法を説明するフローチャートである。
【図６】一実施形態によるルートスキーマのブロック図である。
【符号の説明】
【００７２】
１００  システム
１２０  エディタ
１３０  命令
１４０  インストール管理システム
１４２  命令アナライザ
１５０  インストール
１５２、１５４  アプリケーション
１６０  人
【図１】
2008108241.tif 000003
【図２】
2008108241.tif 000004
【図３】
2008108241.tif 000005
【図４】
2008108241.tif 000006
【図５】
2008108241.tif 000007
【図６】
2008108241.tif 000008
【外国語明細書】
MANAGING APPLICATIONS ASSOCIATED WITH AN INSTALLATION 
TECHNICAL FIELD
Embodiments of the present invention relate to managing applications.  More specifically, embodiments of the present invention relate to managing applications associated with an installation.
BACKGROUND ART
A company typically has many different types of applications for performing different types of processing.   The applications are executed on computer systems that are typically networked together.  The applications, the computer systems that the applications execute on and the networks that are used to communicate between the computer systems, among other things, are a part of what is commonly known as the company's "installation."  
An installation may include other types of devices such as routers, firewalls and load balancers.  The computer systems and the various devices are also commonly referred to as "nodes."  
As the complexity of installations increases, there has been a growing need for systems that manage the installations (referred to hereinafter as "installation management systems").  An example of an installation management system is Hewlett Packard(tm)'s Openview Operations (OVO).  
Examples of types of managing performed by an installation management system include, among other things, determining whether processes, nodes, or software are running, how much memory a node has, the Computer Processing Unit (CPU) utilization of the node, determining the response time of an application and taking action based on these determinations.  Examples of taking action may include, among other things, adding more memory to a node, re-balancing a workload, or reconfiguring the application.    
BRIEF DESCRIPTION OF THE DRAWINGS
The accompanying drawings, which are incorporated in and form a part of this specification, illustrate embodiments of the invention and, together with the description, serve to explain the principles of the invention:
Figure 1 depicts a system for managing applications associated with an installation, according to an embodiment.
Figure 2 depicts a schema for metric collection, according to an embodiment.
Figure 3 depicts a schema for scheduling tasks, according to an embodiment.  
Figure 4 depicts a schema for a graph, according to an embodiment.
Figure 5 depicts a flowchart describing a method for managing applications associated with an installation, according to an embodiment of the present invention. 
Figure 6 depicts a block diagram of a root schema, according to an embodiment.  
The drawings referred to in this description should not be understood as being drawn to scale except if specifically noted. 
BEST MODE FOR CARRYING OUT THE INVENTION
Reference will now be made in detail to various embodiments of the invention, examples of which are illustrated in the accompanying drawings.  While the invention will be described in conjunction with these embodiments, it will be understood that they are not intended to limit the invention to these embodiments.  On the contrary, the invention is intended to cover alternatives, modifications and equivalents, which may be included within the spirit and scope of the invention as defined by the appended claims.  Furthermore, in the following description of the present invention, numerous specific details are set forth in order to provide a thorough understanding of the present invention.  In other instances, well-known methods, procedures, components, and circuits have not been described in detail as not to unnecessarily obscure aspects of the present invention.  
OVERVIEW
Conventional installation management systems are "configured" in order to manage the devices and the applications associated with an installation.  For example, a developer can create policies and templates that can be received by the conventional installation management system for the purpose of configuring it.  The developer can create metric collection policies and a threshold policy, among other things, for monitoring various metrics associated with an application.  The developer can also create scheduling policies that a conventional installation management system uses as a part of scheduling tasks and graph templates that a conventional installation management system uses for creating graphs of collected metrics and so on.  Policies and templates are examples of what is commonly referred to as "artifacts."  
There are several disadvantages to the conventional way of configuring a conventional installation management system.  One, creating the artifacts requires in depth knowledge of the conventional installation management system.  Two, the artifacts are specific to a particular conventional installation management system and therefore cannot be reused in the event the company decides to switch to a different conventional installation management system.  Three, the interfaces that a conventional installation management system provides may have inconsistencies, which further complicates the developer's task of creating the artifacts.  Four, a developer may have to perform redundant manual configuration activities in order to create the appropriate artifacts.  For example, in order to monitor a specific metric, a developer may have to manually create a schedule policy, a threshold policy, a graph template, among other things, which include redundant content.  For the foregoing reasons, conventional installation management systems make it difficult for developers to create consistent management solutions for different applications.
According to an embodiment, an application modeling language that includes a definition for writing instructions that enable an installation management system to determine how to manage applications associated with an installation is provided.  The definition, according to an embodiment, can be used to write instructions for more than one application without requiring a developer to have knowledge of the installation management system.   The application modeling language shall also be referred to as a "neutral modeling language."  Since the application modeling language does not require a developer to have knowledge of the installation management system, it can be used to write instructions for more than one type of installation management system.  
INSTALLATION MANAGEMENT SYSTEMS
Examples of installation management systems include but are not limited to HP(tm)'s OpenView Operations (OVO), HP(tm)'s OpenView Performance Manager (OVOU), and BMC(tm)'s Remedy.  Other examples of different installation management systems include different versions of an installation management system such as version 6 and version 7 of HP(tm)'s Openview Operations for Unix.  
HP's OpenView Operations (OVO), HP's OpenView Performance Manager (OVOU), and BMC(tm)'s Remedy are examples of different products.   Version 6 and version 7 of HP(tm)'s Openview Operations for Unix are examples of different versions of the same product.
APPLICATIONS
Examples of applications that can be monitored using various embodiments of the present invention include, but are not limited to, Oracle(tm) database, BEA(r) (Bill Edward Alfred Systems(r)) WebLogic Application Server, and Microsoft(tm) Exchange Server.
A SYSTEM FOR MANAGING APPLICATIONS ASSOCIATED WITH AN INSTALLATION
Figure 1 depicts a system for managing applications associated with an installation, according to an embodiment, which does not require knowledge of the installation management system.  The blocks that represent features in Figure 1 can be arranged differently than as illustrated, and can implement additional or fewer features than what are described herein.  Further, the features represented by the blocks in Figure 1 can be combined in various ways.  The system 100 can be implemented using software, hardware, firmware, or a combination thereof.
Figure 1 depicts a person 160, an editor 120, instructions 130, an installation management system 140 and an installation 150.  The installation management system 140 includes an instruction analyzer 142.  It is appreciated that instruction analyzer 142 can reside outside the installation management system 140.  The installation 150 includes, among other things, applications 152 and 154.  The person 160 can be a developer.  The developer 160 can use the editor 120 to write the instructions 130 which are received by the installation management system 140.  The editor 120 could be, among other things, a text editor or an Extensible Markup Language (XML) editor.
According to an embodiment, the developer 120 uses an application modeling language definition, which does not require knowledge of the installation management system 140, to write the instructions 130.  The definition can indicate how the developer can write instructions 130 for configuring an installation management system 140.   For example, the definition may indicate that a metric can be specified, that the name of the metric can be specified, how often to obtain the value of the metric, where to obtain the value of the metric from, whether a value for a metric indicates there is a problem with the application being monitored for example by among other things specifying a threshold for the metric, and what to do if the value of the metric indicates there is a problem.  The definition can also include a syntax for specifying the content.  According to an embodiment, the instructions 130 are written in XML and one or more XML schemas are used to specify a definition of the application modeling language.  An XML schema is an example of a non-proprietary format.
The installation management system 140 can receive instructions 130 written according to the definition.  The installation management system 140 uses the instructions 130 to determine how to manage the installation 150.  For example, the instruction analyzer 142 analyzes the instructions to enable the installation management system 140 to determine how to manage the installation 150. 
THE APPLICATION MODELING LANGUAGE AND DEFINITIONS
No matter what installation monitoring system 140 is used, the types of things and the way that those things are monitored will be essentially the same.  For example, there are certain metrics for Oracle(tm) database that will be monitored and graphed regardless of whether the installation management system 140 is HP(tm)'s OVO or BMC(tm)'s Remedy.  Therefore, according to an embodiment, configuration details that are specific to a particular installation management system 140 are handled behind the scenes.  For example, a developer 160 would not need to know that OVOW uses a "Process Monitoring Policy" whereas OVOU uses a "Monitor Policy."  All the developer needs to know, for example, is how they want a particular application process, such as for an Oracle(tm) database, to be monitored, according to an embodiment.
By hiding implementation specifics of configuring an installation management system 140, according to an embodiment, the application modeling language can be used for configuring more than one installation management system 140.  For example, instructions 130 for monitoring Oracle(tm) database, written using various embodiments, could easily be used to configure either HP(tm)'s OVO or BMC(tm)'s Remedy
As already stated, according to an embodiment an application modeling language that includes a definition for writing instructions 130 that enable an installation management system 140 to determine how to manage applications 152, 154 associated with an installation 150 is provided.  According to an embodiment, the definition is provided with one or more XML schemas and the instructions 130 are written in XML.  XML is widely known by developers 160 and therefore makes it easier for developers 160 to configure installation management systems 140.   
Figure 2 depicts a schema for metric collection, according to an embodiment.  The metric collection schema provides information for how to write instructions 130 that specify what metric to monitor, how to monitor the metric, what to do if the value of a metric indicates there is a problem and so on.  For example, the metric collection schema indicates that a name of a metric (e.g., "CollectionName"), a schedule for collecting values of the metric (e.g., "Schedule"), and a command line (e.g., "CommandLine") for collecting the metric's values can be specified.  The metric collection schema also indicates that optionally a description of the metric (e.g., "Description") and that credentials (e.g., "Credentials"), such as a user password, for collecting the metric's values can be specified.  
Figure 3 depicts a schema for scheduling tasks, according to an embodiment.  According to an embodiment, a task is some activity that a developer 160 wants an installation management system 140 to perform on a regular schedule such as pinging a server to see if it is active or running the task every night to see if any new instances of an application server have been deployed to a device.  The scheduled task schema provides information for how to write instructions 130 that specify, for example, what task to monitor, how to monitor the task and so on.  For example, the scheduled task schema indicates that a name of the schedule (e.g., "Schedule") and a name of the task can be specified (e.g., "Task").  The StartMessage, FailureMessage, SuccessMessage enable the developer 160 to specify text that for example can be displayed to an operator of an installation management system 140 when a scheduled task is started, fails, or is successful.
Figure 4 depicts a schema for a graph, according to an embodiment.  The graph schema provides information for how to write instructions 130 that specify how a graph will appear.  For example, the graph schema indicates that a class (e.g., Class), a name of a metric (e.g., MetricName),  metric label (e.g., MetricLabel), and a metric description (e.g., MetricDescription) can be specified.   The class refers to the "class" or a database table as defined in a database where the data that will be displayed on the graph is stored.  MetricName is the name of the metric that will be graphed, the MetricLabel indicates what label to use for the metric on the graph, and MetricDescription is the description of a metric to use on the graph.  More than one metric can be specified by a graph schema.
The graph schema can also be used to specify a GraphName, a GraphDescription, a GraphTitle, a GraphCategory, GraphMetrics, YAxisTitles, and GraphDateRange, according to an embodiment.  GraphName is the name of the graph.  GraphDescription is the description of the graph.  GraphTitle is the title of the graph.  GraphCategory enables organizing graphs so that they appear in "groups" for example when displayed using a user interface associated with the installation management system.  GraphMetrics are the metrics to be graphed.  YAxisTitles enables specification of the titles for the Y axises.  GraphDateRange enables specification of ranges of dates that will appear on the graph.  More than one graph can be specified by a graph schema and more than one metric can appear on a particular graph.
Frequently graphs use different back ground colors and colors for various lines.  Further the graph may be a line graph or a bar graph, among other things.  However, according to an embodiment, the graph schema does not require a developer to specify certain types of information, such as background colors, line colors, or the type of the graph, for example. It is appreciated that this can be performed by the Instruction Analyzer 142 to ensure consistency across the Installation Management System 140.
For the sake of illustration, simplified versions of schemas were depicted in Figures 2-4.  More elements than what are depicted in Figures 2-4 can be associated with the schemas depicted in Figures 2-4.  For example, the metric collection schema could specify a threshold, a frequency, and a source for obtaining a value for a metric.  The threshold can be used for determining if the value of a metric indicates there is a problem, for example, when the value meets or exceeds the threshold.  The frequency can be used for determining how often to obtain the value of the metric, for example, from the source.  In another example, the scheduled task schema could specify how often the task is performed, among other things.  In yet another example, the graph schema could enable a filter to be specified for filtering the graph on an instance name of the data that potentially could appear in the graph.
Further, Figures 2-4 depict just a few application modeling language definitions.  There are numerous other definitions that could be implemented using various embodiments of the present invention.  For example, a packaging schema could be used for writing instructions on how to package software that will be installed on a platform, such as Microsoft(tm) Windows.  The packaging schema could specify what files include the software that is to be packaged, the locations of those files, and the platform the files will be installed on.  In another example, there could be a schema (SNMP schema) indicating how to write instructions configuring Simple Network Management Protocol (SNMP) processing of an installation management system.  For more information on schemas refer to the subheading "More information on Schemas" included hereinafter.
As already stated, with conventional installation management systems a developer may have to perform redundant manual configuration activities in order to create the appropriate artifacts.  For example, in order to monitor a specific metric using a conventional installation management system, a developer may have to manually create a schedule policy, a threshold policy, a graph template, among other things, which include redundant content.  However, according to an embodiment, content for configuring a particular aspect of an installation management system is specified in one place.  Therefore, the developer will not have to perform redundant manual configuration activities.  For example, if a policy needs information about a metric, content about that metric can be obtained from the set of instructions that were written based on the metric collection schema rather than including redundant content in a set of instructions for a policy. 
INSTRUCTIONS
For the sake of illustration, Figure 1 depicts one set of instructions 130, according to an embodiment.  Different sets of instructions 130 can be used to configure an installation management system 140 to manage different applications 152, 154.  Further, more than one set of instructions can be used to configure the installation management system 140 to manage different aspects of the same application, as will become more evident.  For example, both the Oracle(tm) database application and Microsoft's(tm) Exchange Server have metrics that a developer 160 may want to monitor.  Therefore, multiple sets of instructions 130 may be written based on the metric collection schema (Figure 2) for the various metrics. 
According to an embodiment, a definition can be used to verify a set of instructions that were written based on that definition.  For example, a set of instructions that were written based on the metric collection schema depicted in Figure 2 can be verified using the metric collection schema by the installation management system 140.  A set of instructions is also referred to as "a model instance" or "an instance of a model." 
OPERATIONAL EXAMPLE OF A METHOD OF MANAGING APPLICATIONS ASSOCIATED WITH AN INSTALLATION
Figure 5 depicts a flowchart 500 describing a method for managing applications associated with an installation, according to an embodiment of the present invention.   Although specific steps are disclosed in flowchart 500, such steps are exemplary.  That is, embodiments of the present invention are well suited to performing various other steps or variations of the steps recited in flowchart 500.  It is appreciated that the steps in flowchart 500 may be performed in an order different than presented, and that not all of the steps in flowchart 500 may be performed.  
All of, or a portion of, the embodiments described by flowchart 500 can be implemented using computer-readable and computer-executable instructions which reside, for example, in computer-usable media of a computer system or like device. As described above, certain processes and steps of the present invention are realized, in an embodiment, as a series of instructions (e.g., software program) that reside within computer readable memory of a computer system and are executed by the of the computer system.  When executed, the instructions cause the computer system to implement the functionality of the present invention as described below.
In step 510, the method begins.
In step 520, instructions are received that enable an installation management system to determine how to manage an application associated with the installation.  The instructions 130 conform to an application modeling language that specifies a definition that can be used to write instructions 130 for more than one application 152 and 154 without requiring knowledge of the installation management system 140.  The schemas depicted in Figures 2-4 are examples of definitions provided by an application modeling language that can be used to write instructions 130.  Assume for the sake of illustration, that one set of instructions 130 is written for a particular metric for a particular application 152 based on the schema depicted in Figure 2 and that another set of instructions 130 is written based on the same schema (Figure 2) for another metric for that same application 152.  Those two sets of instructions could be used to configure different installation management systems 140.  For example those two sets of instructions could be used to configure either HP(tm)'s OVO or BMC(tm) Remedy because the application modeling language does not require the developer 160 to have knowledge about any installation management systems 140.  
The developer 160 can create the sets of instructions 130 using an editor 160.  The editor 160 according to an embodiment is an XML editor and the instructions 130 are XML instructions.  The installation management system 140 can receive the files that include the sets of instructions 130.
In step 530, the instructions are analyzed to enable the installation management system to determine how to manage the application.  For example, the sets of instructions 130 that were received in step 520 are analyzed.  Thus, the installation management system 140 is enabled to monitor the application 152 that the sets of instructions were written for.  
In step 540, the method ends.
MORE INFORMATION ON SCHEMAS
The following describes other possible schemas and content that can be associated with schemas.  For example, the following describes various attributes and types that can be associated with various schemas.  One of the schemas is a MasterModel, according to an embodiment.  Schema elements such as SPIInformation, GraphFiles, Policies, PkgFiles, and Products, according to an embodiment, can be children of the MasterModel schema.  GraphFiles is an example of a Graph schema depicted in Figure 4.  Policies is an example of a Policy schema.  PkgFiles is an example of a packaging schema.  SNMPPolicy is an example of an SNMP Schema, ScheduledTaskPolicy is an example of a Scheduling Task Schema depicted in Figure 3.  External Metric Collections is an example of a Metric Collection Schema depicted in Figure 2.  
Also refer to Figure 6 which depicts a block diagram of a root schema, according to an embodiment.  Referring to Figure 6, according to an embodiment, the root element is used for all policies.  According to an embodiment, the SPIInformation is used for SPI artifacts, such as filename prefixes.  According to an embodiment, PolicyName is unique within the SPI model and CollectionName is the name of a policy.
Examples the Application Management Language:
Examples of application management language in accordance with embodiments of the present invention are described in the following paragraphs.
The metric element defines information about the metrics being monitored for an application in accordance with embodiments of the present invention.  This information includes, but is not limited to, 1) the metric name and description, 2) the source of the metric, and 3) the unit of measure.
Example of the metric element:
2008108241.tif 000009
The monitor policy element defines information about monitoring data, such as response time or incoming workload, provided by an application to management systems in accordance with embodiments of the present invention.  This information includes, but is not limited to, 1) a policy name and description, 2) the interval at which to monitor the data, 3) the condition to monitor, including a numeric threshold or a script which determines the condition, 4) the metrics to be monitored, 5) the object instances to be monitored, and 6) the actions to perform if an error condition occurs, including the severity of the event and instructions on what to do to fix the problem.
Example of a monitor policy element: 
2008108241.tif 000010
The external collection element defines the information necessary to collect metrics from a collector external to the Installation Management System in accordance with embodiments of the present invention.  This information includes, but is not limited to, 1) a policy name and description, 2) the interval at which to collect the data, 3) the command line to run to collect the data, and 4) the user/password required for the collection. 
Example of an external collection element:
2008108241.tif 000011
The process monitoring policy element defines information about a process or service to monitor in accordance with embodiments of the present invention.  This information includes, but is not limited to, 1) a policy name and description, 2) the interval at which to monitor the process, 3) the process name, and 4) the actions to perform if an error condition occurs, including the severity of the event and instructions on what to do to fix the problem.
Example of a process monitoring policy element:
2008108241.tif 000012
The scheduled task policy element defines information about a scripts or executables to be executed by the management system in accordance with embodiments of the present invention. This information includes, but is not limited to, 1) a policy name and description, 2) the interval at which to perform the execution (defined as a repeating interval or as a specific times or specific days), and 3) messages that should be sent to the operator console upon commencement, success, or failure of the task execution, including the severity of the event and instructions on what to do to fix the problem.
Example of a scheduled task policy element:
2008108241.tif 000013
The SNMP policy element defines the SNMP trap from which to collect metrics in accordance with embodiments of the present invention. This information includes, but is not limited to, 1) a policy name and description, 2) the SNMP trap ID and additional SNMP variables that further identify the trap to monitor, 3) a set of rules that specify the state or condition to monitor and the action to take if an error condition is found. This action includes such things as the severity of the condition and instructions on what to do to fix the problem.
Example of a SNMP policy element:
2008108241.tif 000014
The Logfile element defines information about monitoring an application logfile in accordance with embodiments of the present invention. This information includes, but is not limited to, 1) the policy name and description, 2) the logfile location, and 3) one or more rules that specify a condition for which to monitor (the existence of a text pattern in the logfile) and 3) actions to take if an error condition is found, including such things as the severity of the condition and instructions on what to do to fix the problem.
Example of a logfile element:
2008108241.tif 000015
The Graph element defines information about a graph that will display metric values over time for performance analysis in accordance with embodiments of the present invention.  This includes, but is not limited to, the following: 1) information used in the display of the graph, such as graph name, description, or axis titles, 2) graph type, chosen from a selection of pre-defined graph patterns, such as a trend graph or comparison graph, and 3) the metrics that will appear on the graph and any instance filter that should be applied. 
Example of a graph element:
2008108241.tif 000016
It is appreciated that in many cases the Instruction Analyzer can provide reasonable defaults to alleviate some work on the part of the developer.  For example, in SNMP policies, the Instruction Analyzer can provide a standard error message for the developer. 
CONCLUSION
Although many examples of embodiments of the present invention were described in the context of a company's installation, various embodiments apply to installations for any type of organization regardless of whether it is a company or not.  
By specifying the content that pertains to managing applications and by hiding implementation specifics of installation management systems, developers are enabled to configure installation management systems without requiring knowledge of the installation management system.  By specifying the content that pertains to managing applications and by hiding implementation specifics of the installation management system the instructions that enable the installation management system to manage applications can be used in the event the company decides to switch to a different installation management system.  Further, because of various embodiments a developer will be provided a consistent way of configuring installation management systems.  By specifying content for configuring a particular aspect of an installation management system in one place, the developer will not have to perform redundant manual configuration activities.   Therefore, various embodiments enable developers to quickly and easily create consistent management solutions for different applications.  
CLAIMS
What is claimed is:
1.    A method of managing applications associated with an installation, the method comprising: 
receiving instructions that enable an installation management system to determine how to manage an application associated with the installation, wherein the instructions conform to an application modeling language that specifies a definition that can be used to write instructions for more than one application without requiring knowledge of the installation management system; and
analyzing the instructions to enable the installation management system to determine how to manage the application.
2.    The method as recited in Claim 1, wherein the installation management system is a first installation management system and wherein the method further comprises:
receiving the instructions at a second installation management system to determine how to manage the application associated with the installation; and
analyzing the instructions to enable the second installation management system to determine how to manage the application.
3.    The method as recited by Claim 2, wherein the first and second installation management systems are one of different versions of the same product or different products.
4.    The method as recited by Claim 1, wherein the receiving of the instructions that enable the installation management system to determine how to manage the application associated with the installation and wherein the instructions conform to the application modeling language that specifies the definition further comprises: 
receiving the instructions that conform to the application modeling language that specifies the definition, wherein the definition is an Extensible Markup Language (XML) schema.
5.    The method as recited by Claim 1, wherein the method further comprises:
using the definition to verify the instructions.
6.    The method as recited by Claim 1, wherein the receiving of the instructions that enable the installation management system to determine how to manage the application associated with the installation and wherein the instructions conform to the application modeling language that specifies the definition further comprises:
receiving instructions that conform to the application modeling language that specifies the definition, wherein content for configuring a particular aspect of the application modeling language is specified in a single definition.
7.    The method as recited by Claim 1, wherein the receiving of the instructions that enable the installation management system to determine how to manage the application associated with the installation and wherein the instructions conform to the application modeling language that specifies the definition further comprises:
receiving the instructions that conform to the application modeling language that specifies the definition, wherein the definition indicates how content that pertains to the application can be specified while hiding implementation specifics of the installation management system.  
8.    An application modeling language, the application modeling language comprising:
a definition for writing instructions that enable an installation management system to determine how to manage applications associated with an installation, 
wherein the definition can be used to write instructions for more than one application without requiring knowledge of the installation management system.
9.    The application modeling language of Claim 8, wherein the definition is an Extensible Markup Language (XML) schema.
10.    The application modeling language of Claim 8, wherein the definition includes another definition.
11.    The application modeling language of Claim 8, wherein the definition is selected from a group consisting of metric collection, monitor policy, external collection element, process monitoring policy, scheduled task policy, SNMP policy, log file element, graph element, and scheduled task,.
12.    The application modeling language of Claim 8, wherein the definition enables specifying content for configuring a particular aspect of the application modeling language and wherein another definition is not required to specify the same content.
13.    The application modeling language of Claim 8, wherein the definition indicates how content that pertains to the application can be specified while hiding implementation specifics of the installation management system.
14.    A computer-usable medium having computer-readable program code embodied therein for causing a computer system to perform a method of managing applications associated with an installation, the method comprising: 
receiving instructions that enable an installation management system to determine how to manage an application associated with the installation, wherein the instructions conform to an application modeling language that specifies a definition that can be used to write instructions for more than one application without requiring knowledge of the installation management system; and
analyzing the instructions to enable the installation management system to determine how to manage the application.
15.    The method as recited in Claim 14, wherein the computer-readable program code embodied therein causes a computer system to perform the method, and wherein the installation management system is a first installation management system and wherein the method further comprises:
receiving the instructions at a second installation management system to determine how to manage the application associated with the installation; and
analyzing the instructions to enable the second installation management system to determine how to manage the application.
16.    The method as recited by Claim 15, wherein the computer-readable program code embodied therein causes a computer system to perform the method, and wherein the first and second installation management systems are one of different versions of the same product or different products.
17.    The method as recited by Claim 14, wherein the computer-readable program code embodied therein causes a computer system to perform the method, and wherein the receiving of the instructions that enable the installation management system to determine how to manage the application associated with the installation and wherein the instructions conform to the application modeling language that specifies the definition further comprises: 
receiving the instructions that conform to the application modeling language that specifies the definition, wherein the definition is in a non-proprietary format.
18.    The method as recited by Claim 14, wherein the computer-readable program code embodied therein causes a computer system to perform the method, and wherein the method further comprises:
using the definition to verify the instructions.
19.    The method as recited by Claim 14, wherein the computer-readable program code embodied therein causes a computer system to perform the method, and wherein the receiving of the instructions that enable the installation management system to determine how to manage the application associated with the installation and wherein the instructions conform to the application modeling language that specifies the definition further comprises:
receiving the instructions that conform to the application modeling language that specifies the definition, wherein content for configuring a particular aspect of the application modeling language is specified in a single definition.
20.    The method as recited by Claim 14 wherein the computer-readable program code embodied therein causes a computer system to perform the method, and wherein the receiving of the instructions that enable the installation management system to determine how to manage the application associated with the installation and wherein the instructions conform to the application modeling language that specifies the definition further comprises:
receiving the instructions that conform to then application modeling language that specifies the definition, wherein the definition indicates how content that pertains to the application can be specified while hiding implementation specifics of the installation management system.  
ABSTRACT OF THE INVENTION
The present invention provides for managing applications associated with an installation. In an embodiment, instructions are received that enable an installation management system to determine how to manage an application associated with the installation.  The instructions conform to an application modeling language that specifies a definition that can be used to write instructions for more than one application without requiring knowledge of the installation management system.  The instructions are analyzed to enable the installation management system to determine how to manage the application.
2008108241.tif 000017
2008108241.tif 000018
2008108241.tif 000019
2008108241.tif 000020
2008108241.tif 000021
2008108241.tif 000022