JP2004158012A - ソフトウェアアプリケーション管理のためのシステムおよび方法 - Google Patents

Abstract

【課題】アプリケーションに属する各リソース状態に基づいてアプリケーションの管理を一元化・自動化できる。
【解決手段】管理システムの１つの側面は、１台のマスターサーバと複数のエージェントを含む。マスターサーバは、展開済みの複数リソースの中から幾つかのリソースを選択し、それらのリソースを相互に結合してアプリケーションを形成できる。次に、マスターサーバは選択されたリソース及びそれに対応するリソース状態を取得する命令を生成し、取得されたリソースとリソース状態を結合し1つのアプリケーションパッケージを形成できる。管理システムの別の側面では、各リソースのリソースタイプに基づいて管理手順をアプリケーションに関連付けることができる。こうして、その管理手順を実行して、各リソース状態に基づいてアプリケーションを管理できる。
【選択図】 図１

Description

著作権表示

この特許文献の開示の一部には、著作権保護の対象となる要素が含まれる。特許商標庁の特許ファイルまたは特許記録簿に表示されている場合、著作権所有者はいかなる者によるこの特許文献または特許情報開示のファクシミリ複製に対しても異議を申し立てないが、それ以外の場合、すべての著作権は保有される。

発明の分野

本発明は一般に、コンピュータに関し、そしてより詳しくはネットワークか、コンピュータ上のソフトウェアアプリケーションを管理するためのシステムおよび方法に関する。

発明の背景

ネットワークコンピュータとは、通信ネットワーク（たとえばインターネットプロトコル（ＩＰ）ネットワーク）に接続されたコンピュータである。ネットワークコンピュータは、通信ネットワークを介してサーバに接続されたクライアントコンピュータに機能を提供するサーバとして機能することができる。サーバが提供できる機能は、サーバにインストールされサーバ上で実行される１つ以上のアプリケーション（たとえばソフトウェアプログラム）によって決まる。通常、アプリケーションには特にバイナリ（たとえば、実行可能な）ファイル、コンフィギュレーション設定、および登録設定が含まれる。これらのファイルと設定は、サーバ上の１つ以上のディレクトリに常駐することができる。

アプリケーションをクライアントコンピュータで利用可能にする前に、システム管理者（または大企業のシステム管理者グループ）はアプリケーションをサーバ（たとえば企業サーバ）に展開する必要がある。システム管理者は通常、各サーバが協調して所定の業務目標に合った機能を提供するように、全サーバ上のアプリケーションソフトウェアを管理する責任がある。業務目標が変動しやすい場合、アプリケーションの頻繁な展開、アンインストール、またはアップグレード（古いバージョンをアンインストールし、新しいバージョンを展開すること）がしばしば必要になることがある。またたとえば、正常に機能しない場合はアプリケーションを解析しなければならないこともある。

管理プロセスが複雑であり、各種アプリケーション間でコンフィギュレーション設定と登録設定が多様であるため、アプリケーション管理に時間がかかり、システム管理者に各アプリケーションに関する知識が必要とされることがある。さらに、たとえば１台のサーバ上の１つのアプリケーションの設定ファイルのセッティングに少しでもエラーがあると、企業全体としての必要な機能を実行できなくなることもある。設定エラーが長期間検出されない場合もある。一般に従来のシステム管理ソフトウェアでは、すべてのサーバとアプリケーションが起動・実行され、システム管理ソフトウェアが対応できるイベントを生成しないため、警報が生成されない。

アプリケーションの手動管理には上記のような欠陥があることから明らかなように、すべてのサーバが必要な業務機能を全体として実現するような方法で管理操作を実行できるようにすると同時に、たとえば企業データセンターの１台以上のサーバ上のアプリケーション管理を一元化・自動化するシステムと方法が必要とされている。

発明の概要

本発明の１つの側面もしくは局面は、１台以上の管理対象サーバマシン上のソフトウェアアプリケーションを管理するシステムおよび方法にかかわる。展開されたアプリケーションの状態（アプリケーションに属する各リソースの状態）の管理が管理システムによって一元化されるため、アプリケーション管理を簡素化できる。たとえば、ソースサーバマシン上に先に展開されたアプリケーションの状態を取り込み、それを利用して同じアプリケーションを１台以上のターゲットサーバマシンに展開できるため、以前に取り込まれた展開状態（ソースサーバマシン上の）と同じまたは似た展開状態をターゲットサーバマシン上で達成することができる。解析やアンインストールなど、その他の管理手順もこの展開状態を利用して効果的に実行することができる。たとえば、展開されたアプリケーションをその展開状態に関して解析することができる。また、展開されたアプリケーションを、その展開状態を利用してサーバマシンからアンインストールまたは削除することも可能である。

本発明の１つの側面によれば、アプリケーション管理システムは１台のマスターサーバと複数のエージェントを含み、各エージェントは１つの管理対象サーバマシン上に常駐する。マスターサーバによって、ユーザ（たとえば、システム管理者または別のソフトウェアプログラム）は管理対象サーバマシン上にすでに展開されている複数リソースの中からリソースを選択し、それらを相互に組み合わせて１つのアプリケーションを形成することができる。１台以上の管理対象サーバマシン（この場合は、ソースサーバマシンとして知られている）からリソースを選択できる。マスターサーバは、選択されたリソースをそれに対応するリソース状態を取り込む命令を生成し、取り込まれたリソースとリソース状態を１つのアプリケーションパッケージに結合する。

本発明の別の側面によればアプリケーション管理システムは、アプリケーションを形成する各リソースのリソースタイプに基づいて管理手順をアプリケーションに関連付けることができる。このため、その管理手順を実行して、各リソースの状態に基づいてアプリケーションを管理できる。

一実施形態では、１台以上のコンピュータ（またはサーバマシン）にプログラムすることができる一系列のコンピュータプログラム命令として、アプリケーション管理システムを実現できる。代替的に、アプリケーション管理システムをハードウェア（たとえば、プログラム可能論理デバイスなどの専用ハードウェアや特定のソフトウェアを実行する汎用コンピュータ）に実現し、製品としてコンピュータリード処理可能媒体（たとえばディスク）に格納される一系列の命令として実現することができる。

本発明とその利点は、以下の望ましい実施形態の詳細な説明を添付図面と併せて検討することによって容易に理解されるものである。なお、全図面において類似部分は同一符号で示してある。

好ましい実施形態の詳細な説明

アプリケーションとは、共に動作して特定機能（または関連機能群）を実行するように設計されたリソース（フィーチャ）の集まりである。アプリケーション（たとえばソフトウェアアプリケーション）はソフトウェアベンダーから１つのユニットとして購入し、またはソフトウェア開発グループが社内で作成することができる。アプリケーションパッケージ（たとえばソフトウェアパッケージ）とは、単一のファイル（通常はアーカイブファイル）、または１つのアプリケーション用の全データ（たとえば実行可能コード、内容、コンフィギュレーション情報）を含む一組のファイルである。

リソースとは、１つ以上を相互に組み合わせて１つのアプリケーションとして機能できるフィーチャである。リソースは、実行可能コード、設定ファイル、ユーザインタフェース用のグラフィックスファイルなど、単一ファイルまたは様々なタイプのファイルの集まりであってよい。リソースの例としては、（１）ウェブコンテンツ（たとえばＨＴＭＬテキスト、Ａｃｔｉｖｅ Ｓｅｒｖｅｒページ（ＡＳＰ））、各種形式の画像（たとえばＧＩＦやＪＰＥＧ）などを含むディレクトリ；（2）１つ以上のＣＯＭ（Ｃｏｍｐｏｎｅｎｔ Ｏｂｊｅｃｔ Ｍｏｄｅｌ）コンポーネントを含むことができるＤＬＬ（Ｄｙｎａｍｉｃ Ｌｉｎｋ Ｌｉｂｒａｒｙ）；（３）Ｊ２ＥＥ（Ｊａｖａ ２ Ｅｎｔｅｒｐｒｉｓｅ Ｅｄｉｔｉｏｎ）アプリケーションコードなどを含むＷＡＲ（Ｗｅｂ Ａｒｃｈｉｖｅ）が挙げられる。各リソースはそれに関連付けられた特定のリソースタイプを持つため、リソースタイプに基づいて管理することができる。リソースタイプとはリソースの名前であり、定義された一組の名前（たとえばＣＯＭ＿ＰＬＵＳ、ＷＡＲ＿ＷｅｂＬｏｇｉｃ、ＩＩＳ＿Ｗｅｂ＿Ｓｉｔｅ）から選ばれる。たとえば、ＣＯＭ＋コンポーネントを含む１つのリソースは、リソースタイプＣＯＭ＿ＰＬＵＳを持つことができる。したがって、１つのリソースタイプは、リソースの種類を一意に決めるリソースの属性である。

サーバマシンとは、サーバマシンにインストールされたアプリケーションの機能を、通信ネットワークを介してサーバマシンに接続された他のコンピュータ（たとえばクライアントコンピュータ）に提供する任意のネットワークコンピュータである。たとえば、特定のコンピュータが、第１のアプリケーションに関してはサーバマシンとして機能し（別のコンピュータに、第１のアプリケーションの機能を提供する場合など）、第２のアプリケーションに関してはクライアントコンピュータとして機能することができる（別のコンピュータが提供する第２のアプリケーションの機能を利用する場合）。

サーバマシンに展開された各リソースは、それに関連付けられたリソース状態を持つ。１つの展開されたリソースの状態（リソース状態）には通常、特定のサーバマシン上に展開された時点のリソースのコンフィギュレーション設定と登録設定が含まれる。

１つのサーバマシンに展開された各アプリケーションは、それに関連付けられた１つのアプリケーション状態を持つ。展開されたアプリケーションの状態（アプリケーション状態）は、アプリケーションに属する各リソースの状態の集まりである。

アプリケーション管理とは、（１）アプリケーション（およびそれに対応する機能）をサーバマシンに追加するプロセスとしての展開、（２）アプリケーション（およびそれに対応する機能）をサーバマシンから削除するプロセスとしてのアンインストール、（３）同じアプリケーションが展開されている複数のサーバマシン間のコンフィギュレーションおよび登録上の差異を識別するプロセスとしての解析、（４）特定のアプリケーションまたはリソースが展開されているサーバマシンを決定するプロセスとしての発見など、複数のプロセスを表す用語である。その他のアプリケーション管理手順としては、たとえばアップグレード、ロールバック、モニタリングがある。

アプリケーション展開は通常、アプリケーション（アプリケーションリソース）を形成するリソースすべてをサーバマシンに転送することを含む。リソースは通常、予め定義されたディレクトリに配置される。各リソースのコンフィギュレーション設定と登録設定には値が付けられる。リソースに応じて、これらの設定をデータベースのような構造、各種形式（ＸＭＬ、アプリケーション固有の形式など）のファイル、または登録タイプ構造（Ｗｉｎｄｏｗｓレジストリなど）に格納することができる。各リソースの設定は、サーバのタイプ、サーバのＩＰアドレス、サーバが配置されているサブネット、サーバが所属しているＦＬＡＮセグメント、サーバにインストール済みの別のソフトウェア、企業内のサーバの役割、サーバの基本ＯＳ（オペレーティングシステム）またはハードウェアのような、様々な側面または局面によって異なることがある。

アプリケーションソフトウェアが動作するようにサーバの環境を設定しなければならないことがある。たとえば、サーバにインストールされたリソースのタイプに応じてサーバレジストリを変更しなければならないことがある。さらに、選択したサーバ上で各リソースを実行するために、使用可能メモリ、アーキテクチャ、その他の以前にインストールしたソフトウェアなど、複数の条件をチェックする必要がある。一度設定すれば、アプリケーションソフトウェアを起動できる。つまり、アプリケーションソフトウェアの実行可能プログラムを実行状態にすることができる。

一般にアプリケーションアンインストールには、実行状態が継続しないようにアプリケーションソフトウェアを停止するプロセス、サーバマシンからすべてのリソースを削除するプロセス、展開時に生成されたコンフィギュレーション設定と登録設定をすべて削除するプロセスが含まれる。

アプリケーションコンフィギュレーション解析では、現在アプリケーションが展開されている２つ以上のサーバマシン間のコンフィギュレーション設定と登録設定を比較することを含む。各サーバマシンに関連付けられたコンフィギュレーション設定と登録設定をすべて比較しなければならない場合がある。また、代替的に特定のアプリケーションリソースの影響を受けるコンフィギュレーション設定と登録設定だけを比較することもある。両設定上の差異を出力としてシステム管理者または別のアプリケーション管理機能に提示することができる。

アプリケーション発見は、所定の組のサーバマシン上で、現在アプリケーションが展開されているサーバマシンをすべて発見するプロセスである。出力として、各サーバのＩＤを展開されているアプリケーションの正確なバージョンと共に提示することができる。

図１は、本発明のアプリケーション管理システム１００の１つの実施形態を示すブロック図である。このアプリケーション管理システム１００は、複数の中から選ばれた１台以上のターゲットサーバマシン１１０上のアプリケーション管理を自動化するのに適している。アプリケーション管理システム１００によって、各リソースの状態またはリソースタイプにどのような差異があったとしても、あらゆるリソースについて同じ（または類似の）ワークフローが可能になる。

アプリケーション管理システム１００は、ソースサーバマシン１３５（「ゴールドサーバ」と呼ばれることもある）に展開済みの１つ以上のリソース１３０を選択するユーザ入力１２０を受け取る（たとえば図２に示したユーザインタフェース１８０などを介して）。場合によっては、リソース１３０の選択においてリソースタイプを指示することもできる。選択されたリソース１３０を相互に結合してアプリケーションとして機能させることもできる。一実施形態では、リソース１３０を１台以上のソースサーバマシン１３５から選ぶことができる。たとえば、第１のリソースを第１のソースサーバマシンから選び、第２のリソースを第２のソースサーバマシンから選ぶことができる。複数のソースサーバマシン１３５上で特定のリソース１３０を利用可能な場合、そのリソース１３０を提供する１つの特定のソースサーバマシン１３５を選択できる。１つの事例において、そして他の事例において、特定のサーバがソースサーバマシン１３５として機能したり（別のサーバマシンに展開するために、インストール済みのリソースをアプリケーション管理システム１００に提供する場合）、ターゲットサーバマシン１１０として機能することができる（リソースをインストールするターゲットである場合）。

アプリケーション管理システム１００は、ソースサーバマシン１３５上の選択された各リソース１３０と選択された各リソース１３０に対応するリソース状態１４０を取り込むための命令を生成する。選択されたリソース１３０および対応するリソース状態１４０を（たとえばインストール命令を）結合してアプリケーションパッケージ（ソフトウェアパッケージ）を形成することができる。

アプリケーション管理システム１００は、選択された各リソース１３０に基づいて管理手順をアプリケーションに関連付ける。このため、アプリケーション管理システム１００によってユーザ（たとえば、システム管理者または別のソフトウェアプログラム）はその管理手順を実行して、ターゲットサーバマシン１１０を管理できる。好都合なことに、この管理手順を管理者またはその他の操作員が使用するマシンのような１つの中央部所から実行できる。アプリケーション管理システム１００によって、ユーザは各アプリケーションについて、自動化された一組の管理手順（展開、アンインストール、解析、発見）から選択できる。

展開時、選択されたリソース１３０が１台以上のターゲットサーバマシン１１０にインストールされる。アプリケーションと選択されたターゲットサーバマシン１１０の両方のコンフィギュレーション設定を展開管理手順にしたがってセッティングできる。展開管理手順では、選択された各リソース１３０に対応するリソース状態１４０から、コンフィギュレーション設定と登録設定に関する必要な情報を取得する。

アンインストール管理手順を実行すると、展開プロセス時にインストールされたリソースがすべてターゲットサーバマシン１１０から削除される。さらに、展開プロセス時に作成された、アプリケーション（アプリケーション状態）に関連付けられたコンフィギュレーション設定と登録設定がすべて取り消される。

解析管理手順では、ターゲットサーバマシン１１０上のアプリケーションのコンフィギュレーション設定と登録設定（アプリケーション状態）を解析し、別のサーバマシン上の同じアプリケーションの設定（またはアプリケーション状態）と比較する。さらに、この解析管理手順では、ターゲットサーバマシン１１０上のアプリケーションの現在の設定を、同じターゲットサーバマシン１１０で１つの先の時点においてアクティブであった設定と比較することもできる。

アプリケーション発見管理手順は、１台以上のサーバマシンにアプリケーションを展開済みであるかどうかを決定する。展開済みである場合、アプリケーション発見管理手順で、特定のサーバマシンのＩＤを、各サーバマシン上の現在のアプリケーション状態と共に出力できる。

その結果、操作員は管理手順（アプリケーションの各リソースに応じて利用可能になるどれかの手順）を単に選択して特定のリソース状態を管理するだけで、アプリケーションを管理できる。したがって、利用可能な管理手順の中から選択すれば、操作員は管理操作が正確であることを確信できる。また、複数のターゲットサーバマシン１１０、さらには企業ネットワーク全体に渡って特定の管理手順を呼び出すことで、操作員はアプリケーションの管理に一貫性があることを確信することもできる。たとえば、各展開プロセスを同じ方法で実行できる。解析、アンインストール、およびその他の手順（ロールバックのような）を、展開手順に基づいて実行する（展開手順後のアプリケーション状態を、これらの管理手順の開始点として利用する）ことができる。

図２は、本発明の実施形態にしたがってアプリケーションを管理できるコンピュータネットワークの概略図である。１台の中央コンピュータ１５０が通信ネットワーク１５５に接続されている。複数の管理対象サーバマシン（コンピュータ）１６０も通信ネットワーク１５５に接続されている。中央コンピュータ１５０および管理対象サーバマシン１６０は、１つ以上の物理通信回線、無線システム、またはこれらの任意の組み合わせを介して通信ネットワーク１５５に接続されたパーソナルコンピュータ、ワークステーション、またはサーバマシンなどを含むことができる。通信ネットワーク１５５として、１つ以上のネットワークまたはその他の通信プロトコル（たとえば、インターネットプロトコル）を採用したLAN（ローカルエリアネットワーク）やWAN（ワイドエリアネットワーク）など１つ以上のネットワークを使用できる。

一実施形態では、本発明のアプリケーション管理システム１００に、中央コンピュータ１５０に常駐するマスターサーバ（MS）１７０と１つの管理対象サーバマシン１６０に常駐する少なくとも１つのエージェント１７５が含まれる。各管理対象サーバマシン１６０は、実行される管理機能に応じてソースサーバマシン１３５またはターゲットサーバマシン１１０として機能できる。たとえば、インストール済みのリソース１３０をアプリケーション管理システム１００に提供する場合、特定の管理対象サーバマシン１６０はソースサーバマシン１３５であってよい。これと同じ管理対象サーバマシン１６０が、別の管理対象サーバマシン１６０が提供するリソース状態情報に基づいてアプリケーション管理システム１００によって管理される場合、ターゲットサーバマシン１１０であってもよい。

マスターサーバ１７０は、通信ネットワーク１５５を介して直接、または中間ホップを介して管理対象サーバマシン１６０上のエージェント１７５と通信することができる。一実施形態では、マスターサーバ１７０は、好ましくはシステム管理者（またはその他の操作員）が使用するマシンである中央コンピュータ１５０で実行されるプログラム（ソフトウェアパッケージなど）である。マスターサーバ１７０にはユーザインタフェース１８０（たとえばグラフィカルユーザインタフェース、アプリケーションプログラムインタフェース）が組み込まれており、このユーザインタフェースを介してユーザ（たとえばシステム管理者、コンピュータプログラム）はアプリケーション生成とアプリケーション管理手順実行のためのコマンド（たとえばユーザ入力１２０）を発することができる。

一実施形態では、エージェント１７５の１つの事例（たとえば別のソフトウェアパッケージ）が、それぞれの管理対象サーバコンピュータ１６０にインストールされ実行される。一般に管理対象サーバマシン１６０はデータセンターに配置され、たとえばクラスタにグループ化することができる。たとえば、システム管理者またはその他の操作員は、物理的に分離された複数のデータセンターに配置された管理対象サーバマシン１６０を担当してよい。システム管理者は、本発明のアプリケーション管理システム１００を使用して任意のまたはすべての管理対象サーバマシン１６０上のアプリケーションを管理することができるが、その際、管理対象サーバマシン１６０の物理的場所は問題にならない。マスターサーバ１７０は特定のターゲットサーバマシン１１０上のエージェント１７５と通信して、所定のアプリケーション管理手順を実行することができる。

アプリケーション管理システム１００の一実施形態には、アプリケーションビルダーとアプリケーションマネージャという２つの機能が含まれる。アプリケーションビルダーは、アプリケーションに含めるリソースの選択に基づいてアプリケーションとそのアプリケーション状態をアセンブルする。アプリケーションマネージャは、アプリケーションを管理するための一組の命令を生成する。

図３は、本発明に従うアプリケーション生成プロセスの実施形態を示す流れ図である。このプロセスはステップ２００から始まる。ステップ２０５で、マスターサーバ１７０が１つのリソースの選択を受け取る（たとえばユーザインタフェース１８０を介して）。ユーザは、ソースサーバマシン１３５上のリソースを参照することで（たとえば、特定の管理対象サーバマシン１６０とその管理対象サーバマシン１６０上のリソース１３０の場所（たとえばパス）を指定することで；このため、この例では管理対象サーバマシン１６０はソースサーバマシン１３５として機能する）リソース１３０を選択することができる。ステップ２１０で、マスターサーバ１７０が選択されたリソース１３０のリソースタイプをユーザが指示したかどうかを決定する。ユーザがリソースタイプを指示している場合、ステップ２２０に進む。指示していない場合、ステップ２１５で、マスターサーバ１７０が指定されたソースサーバマシン１３５（図１）上のエージェント１７５に命令を発して、リソースタイプを決定する。次に、ステップ２２０に進む。

ステップ２２０で、マスターサーバ１７０がソースサーバマシン１３５上のエージェント１７５に対する命令を生成し発する。この命令はリソースタイプと選択された実際のリソース１３０の両方に基づいており、以下の１つ以上の処理を実行するように設計されている。（１）ソースサーバマシン１３５上のリソース１３０を取り込む、（２）リソース１３０に関連付けられたリソース状態１４０（たとえばコンフィギュレーション設定）を取り込む、（３）すべての関連データ（たとえばリソース１３０、リソース状態１４０など）をマスターサーバ１７０に転送する。ソースサーバマシン１３５上のエージェント１７５が命令を受け取って実行し、関連データをマスターサーバ１７０に返す。ステップ２２５で、マスターサーバ１７０が取り込まれたリソース１３０を含む関連データを受け取る。

選択された一組のリソース１３０のどの組でもアプリケーションとして指定できるため、ステップ２３０でマスターサーバ１７０が、アプリケーションに追加するリソース１３０をさらに選択するかどうかユーザに照会する。もう１つのリソース１３０をさらに追加する場合、ステップ２０５に戻って、追加するもう１つのリソース１３０の選択を受け取る。追加しない場合、ステップ２３５に進む。ステップ２３５で、マスターサーバ１７０が、選択されたリソース１３０と取り込まれたリソース状態１４０（アプリケーション状態になる）をすべて含むアプリケーションパッケージをアセンブルする。次に、プロセスがステップ２４０で終了する。

図４は、本発明に従うアプリケーション管理プロセスの実施形態を示す流れ図である。このプロセスはステップ３００から始まる。ステップ３０５で、マスターサーバ１７０は、アプリケーションの選択、管理手順、およびその上で選択された管理手順が実行される１台以上の管理対象サーバマシン１６０を受け取る（たとえばユーザインタフェース１８０を介して）。したがって、この事例では、選択された管理対象サーバマシン１６０はターゲットサーバマシン１１０である。ステップ３１０で、マスターサーバ１７０が、１台のターゲットサーバマシン１１０上のエージェント１７５に対する命令を生成し発する。この命令はリソースタイプとアプリケーションを形成する実際のリソースの両方に基づいており、ターゲットサーバマシン１１０上のエージェント１７５に、選択された管理手順を選択されたアプリケーションに対して実行させるように設計されている。また、この命令は現在のアプリケーション状態に基づくこともできる。たとえば、アンインストールや解析など多数の管理手順において、先に実行された管理手順（同じアプリケーションに対する）によって生成された状態情報を入力として使用することができる。

ステップ３１５で、マスターサーバ１７０が、アプリケーションパッケージとアプリケーション状態をエージェント１７５に渡す必要があるような１つのタイプの管理手順（たとえば、展開やアップグレードのような管理手順）であるかどうかを決定する。この種の管理手順である場合、ステップ３２０でマスターサーバ１７０がアプリケーションパッケージとアプリケーション状態をエージェント１７５に渡し、ステップ３２５に進む。この種の管理手順でない場合、ステップ３１５から直接ステップ３２５に進む。ステップ３２５で、マスターサーバ１７０が、命令を生成する必要があるターゲットサーバマシン１１０が残っているかどうかを決定する。残っている場合、ステップ３１０に戻る。残っていない場合、ステップ３３０に進む。

ステップ３３０で、エージェント１７５が、選択された管理手順を選択されたアプリケーションに対して実行する命令を受け取って実行する。次に、ステップ３３５でエージェント１７５が、ターゲットサーバマシン１１０に対する管理手順の実行によって生成された新しいアプリケーション状態を格納する。一実施形態では、以前のバージョンのアプリケーションへのロールバックなどを可能にするために、エージェント１７５は特定アプリケーションのアプリケーション状態の系列を格納することができる。ステップ３４０で、エージェント１７５が管理手順の実行によって生成された任意の必要なデータをすべてマスターサーバ１７０に渡す。たとえば、冗長的に格納するために新しいアプリケーション状態をマスターサーバ１７０に渡すことができ、管理手順の実行結果の一部としてマスターサーバ１７０に渡すこともある（たとえば、発見のような管理手順では、アプリケーション状態をマスターサーバ１７０に戻さなければならないことがある）。次に、プロセスがステップ３４５で終了する。

アプリケーションの生成と管理でリソースタイプ情報（リソースに対応する）を利用できる。一実施形態では、リソースタイプが拡張可能であるため、アプリケーション管理システム１００により認識されるリソースタイプの組を拡張して新しいリソースタイプを含めることができる。その際、アプリケーション管理システム１００自体の変更は不要であり、新しいリソースタイプに関する情報を管理手順モデルに追加するだけでよい。次に、アプリケーション管理システム１００は、自動的にこの新しい情報をシステムの広範囲で（たとえば、関連エージェント１７５で）利用可能にすることができる。

また、各リソースタイプについての一組の管理手順を拡張することもできる。その際、アプリケーション管理システム１００自体の変更は不要であり、新しい管理手順の新しいモデルを追加するだけでよい。次に、アプリケーション管理システム１００は、自動的にこの新しい情報をシステムの広範囲で（たとえば、関連エージェント１７５で）利用可能にすることができる。

一実施形態では、本発明に従うアプリケーション管理システム１００をカスタマイズできる。たとえば、既存のリソースタイプに関連付けられた管理手順を変更できる。その際、アプリケーション管理システム１００自体の変更は不要であり、管理手順モデルを変更するだけでよい。次に、アプリケーション管理システム１００は、自動的にこの新しい情報をシステムの広範囲で（たとえば、関連エージェント１７５で）利用可能にすることができる。

さらに、利用可能な管理手順の組をリソースタイプそれぞれについてカスタマイズすることもできる。次に、アプリケーション管理システム１００は、自動的にこの新しい情報をシステムの広範囲で（たとえば、関連エージェント１７５で）利用可能にすることができる。

図５は、本発明に従うマスターサーバ１７０の実施形態における複数の内部モジュールを示すブロック図である。マスターサーバ１７０には、ユーザと対話しながらアプリケーションを作成し、管理手順を実行し、アプリケーション管理システム１００の機能を拡張する複数のモジュールが含まれる。この実施形態におけるマスターサーバ（１７０には、アプリケーションビルダー４００、アプリケーションマネージャ４１０、モデリングマネージャ４２０、状態マネージャ４３０、およびモデル実行エンジン４４０が組み込まれている。

さらに、状態マネージャ４３０と連係して、管理対象リソース、コンフィギュレーション設定、および登録設定などのためのバージョン管理中央記憶装置として機能するリポジトリ４５０をマスターサーバ１７０に組み込むこともできる。ただし、リポジトリ４５０をマスターサーバ１７０の一部として組み込まなければならないというわけではない。一実施形態では、マスターサーバ１７０が常駐するコンピュータ（たとえば中央コンピュータ１５０）からアクセスできる記憶媒体にリポジトリ４５０が配置される。このため、マスターサーバ１７０は必要に応じてリポジトリ４５０の内容にアクセスできる。

図６は、本発明に従うエージェント１７５の実施形態における複数の内部モジュールを示すブロック図である。エージェント１７５には、マスターサーバ１７０と対話しながら管理対象サーバマシン上で必要な処理を実行する複数のモジュールが組み込まれている。この実施形態におけるエージェント１７５に組み込まれているのは、複数のリソースハンドラモジュール４６０とエージェントモデル実行エンジン４７０である。また、展開されたリソース１３０の状態を表すファイルとディレクトリのためのバージョン管理記憶装置として機能するリソース状態デポ４９０を制御するリソース状態デポマネージャ４８０をエージェント１７５に組み込むこともできる。マスターサーバ１７０は、リポジトリ４５０の代わりに、あるいはリポジトリ４５０に加えて、各エージェント１７５に関連付けられたリソース状態デポ４９０を利用できる。

この実施形態におけるエージェント１７５には、リソースタイプ１、２、および４のリソース１３０を処理するリソースハンドラ４６０が組み込まれている。したがって、タイプ１および４のリソース１３０を持つコンポーネント「コンポーネントA４９５」をエージェント１７５が正しく処理できる。ただし、エージェントモデル実行エンジン４７０を大幅に変更することなく、エージェント１７５が新しいリソースタイプを処理する機能を獲得できるようにアプリケーション管理システム１００を拡張することができる。より正確に言えば、たとえばマスターサーバ１７０を使用して新しいリソースハンドラ４６０をエージェント１７５に提供するだけでよい。たとえば、タイプ１、２、および３のリソースを持つ１つのコンポーネント上でエージェント１７５が処理しなければならない場合、タイプ３のリソースを処理できるリソースハンドラ４６０をマスターサーバ１７０がエージェント１７５に提供することができる。一実施形態では、新しいリソースハンドラを受け取り、そのリソースハンドラをエージェント１７５に提供するようにモデリングマネージャ４２０が設定される。特定のオペレーティングシステムでのみ動作するようにリソースハンドラ４６０が設計されていてよい。この場合、モデリングマネージャ４２０は、そのオペレーティングシステムがインストールされている管理対象サーバマシン１６０上で実行されているエージェント１７５に対してのみ、このようなリソースハンドラ４６０を提供することができる。

図５と図６に示したように、アプリケーションビルダー４００、アプリケーションマネージャ４１０、モデリングマネージャ４２０、および状態マネージャ４３０の各モジュールが、アプリケーションの作成プロセスと管理プロセスを実行するモデル実行エンジン４４０を呼び出す。一実施形態では、モデル実行エンジン４４０はソースサーバマシンからのリソース取り込み、複数のターゲットサーバマシンへのアプリケーション展開、およびターゲットサーバマシン上に展開されたアプリケーションの解析を実行できる。

リソース取り込み：リソースタイプに応じて、モデル実行エンジン４４０は選択されたソースサーバマシン１３５から１つのリソースを取り込むことができる。取り込みを行うために、モデル実行エンジン４４０は選択されたソースサーバマシン１３５上のリソース状態１４０全体をリード処理、（必要であれば）リード処理したデータを特定形式のファイルなどに変換する。一実施形態では、ファイル形式はソースサーバマシン１３５のファイルシステムまたはオペレーティングシステムに依存しない。別の実施形態では、リソース状態がデータベース内のエントリに変換される。さらに代替的に、特定の管理手順に関連するリソース状態１４０の一部のみ取り込めばよい。次に、ファイルをリポジトリ４５０に格納できる。たとえば、リソースタイプ”ＩＩＳ Ｗｅｂ ａｐｐｌｉｃａｔｉｏｎ”を持つリソースの場合、モデル実行エンジン４４０はＩＩＳメタベース（ＩＩＳウェブサーバの設定データベース）の特定部分をリード処理し、その内容をＸＭＬファイルに変換することができる。

一実施形態では、モデル実行エンジン４４０は選択されたソースサーバマシン１３５上のエージェント１７５に対する命令を生成できる。次に、エージェントモデル実行エンジン４７０はその命令を実行してリソース状態をリード処理し、（必要であれば）読み取ったデータを特定の形式に変換し、リポジトリ４５０への格納のために結果としてもたらされた状態情報をマスターサーバ１７０に転送することができる。

展開：モデル実行エンジン４４０を使用して、一組のターゲットサーバマシン１１０にアプリケーションを展開することもできる。アプリケーションを展開するために、モデル実行エンジン４４０はたとえばリソース状態を示すファイルからの設定情報を利用して、サーバを設定するための値を提供する。たとえば、上述のリソースタイプ”ＩＩＳ Ｗｅｂ ａｐｐｌｉｃａｔｉｏｎ”用のＸＭＬファイルをリード処理し、その値を設定値としてターゲットサーバマシン１１０上のＩＩＳメタベースに挿入することができる。さらに、モデル実行エンジン４４０は展開後のリソース状態を取り込み、各ターゲットサーバマシン１１０上のリソース状態デポ４９０内に格納することもできる。また、リソース状態をマスターサーバ１７０（たとえば中央コンピュータ１５０）上のリポジトリ４５０に格納することもできる。

一実施形態では、モデル実行エンジン４４０はターゲットサーバマシン１１０上のエージェント１７５に対する命令を生成できる。次に、エージェントモデル実行エンジン４７０はその命令を実行して、ターゲットサーバマシン１１０にアプリケーションを展開することができる。この命令には、展開されるリソースの取り込まれたリソース状態に基づいてたとえばターゲットサーバマシン１１０を設定するための命令を含むことができる。さらに、展開後のリソース状態を取り込むための命令、ターゲットサーバマシン１１０上のリソース状態デポ４９０に生じるリソース状態を格納する命令、およびまたは生じる状態情報をマスターサーバ１７０に転送する命令を含むこともできる。

解析：さらに、モデル実行エンジン４４０を利用して、展開済みのアプリケーションを解析することもできる。各リソースの現在のリソース状態を取り込み、先の時点でリソース状態（ターゲットサーバマシン１１０上のリソース状態デポ４９０に格納できる）または別の管理対象サーバマシン１６０上の現在のリソース状態（この状態を取り込んだ後でも）と比較することができる。

一実施形態では、モデル実行エンジン４４０はターゲットサーバマシン１１０上のエージェント１７５に対する命令を生成できる。次に、エージェントモデル実行エンジン４７０はこの命令を実行して、ターゲットサーバマシン１１０上のアプリケーションを解析することができる。この命令には、選択された各リソースの現在のリソース状態を取り込むための命令と現在のリソース状態をマスターサーバ１７０に返す命令などを含むことができる。さらに、現在のリソース状態（選択されたリソースの）を先のリソース状態と比較する命令を含むこともできる。一実施形態では、先のリソース状態をターゲットサーバマシン１１０上のリソース状態デポ４９０に格納できる。

一実施形態では、リソースタイプ固有の管理を実行するソフトウェアを含むモデリングレイヤーと、モデリングレイヤーによって提供されるプロセスを解釈し実行する第２のソフトウェアレイヤーを使用して、マスターサーバ１７０を実現できる。モデルのオブジェクトは、アプリケーション（そのリソースと、管理手順への参照をすべて含む）と各リソースタイプに関連付けられた一組の管理手順の両方を取り込むことができる。

モデリングレイヤーには、アプリケーションモデル、リソースハンドラ、およびリソースタイプテーブルを含むことができる。アプリケーションモデルは、アプリケーション管理システム１００および関連する管理手順によって管理されるアプリケーションを記述できるモデルである。一実施形態では、このモデルに、アプリケーションのすべてのリソースへの参照と取り込まれたリソース状態情報を含むことができる。アプリケーションコンポーネントとは、アプリケーションの完全なモデルである。アプリケーションビルダー４００はユーザによって選択されたリソースからコンポーネントを生成し、リソース状態取り込みの一部として生成されたすべての設定情報（たとえば設定ファイル）への参照を挿入することができる。代替的に、特定の管理手順に関する設定情報の一部のみ参照すればよい。

リソースハンドラは、所定タイプのリソース１３０の実際の動作を定義する。一実施形態では、リソースハンドラ４６０は特定のリソースタイプについて取り込み、展開、アンインストール、発見、解析などの複数の管理手順をカプセル化する。リソースハンドラ４６０をコンポーネントとして実現することもできる。だたし、一般にアプリケーションビルダー４００を使用してユーザが作成するアプリケーションコンポーネントとは対照的に、これらのコンポーネントまたは「システムサービス」は通常、アプリケーション管理システム１００に添付されている。システムサービスは、サポートされているリソースタイプに対してモデル化された管理手順の実現（たとえばスクリプト、Ｊａｖａクラス）としての独自のリソースを持つことがある。同じターゲットサーバマシンに展開された別のコンポーネントからこれらの手順にアクセスできる。このため、これらの手順を呼び出せば、パラメータを渡すことができる。

一実施形態では、リソースハンドラをリソースタイプに関連付けるルックアップテーブルなどのデータ構造としてリソースタイプテーブルを実現できる。

コンポーネントとは、アプリケーションとリソースハンドラの両方を表すために使用できるモデルオブジェクトである。一実施形態では、ｃｏｍｐｏｎｅｎｔという名前のＸＭＬ要素によってコンポーネントを表すことができる。ＸＭＬ要素ｃｏｍｐｏｎｅｎｔは、Ｎａｍｅ、ＳｏｆｔｗａｒｅＶｅｒｓｉｏｎ、Ｔａｒｇｅｔ Ｐｌａｔｆｏｒｍｓのような、１つ以上のＸＭＬ属性を持つことができる。属性Ｎａｍｅは、コンポーネントの名前を参照する。属性ＳｏｆｔｗａｒｅＶｅｒｓｉｏｎは、コンポーネントのバージョン記述を参照する。属性Ｔａｒｇｅｔ Ｐｌａｔｆｏｒｍｓは、このコンポーネントをインストールできる一組のＯＳプラットフォームを参照する。

ＸＭＬ要素ｃｏｍｐｏｎｅｎｔは、ＲｅｓｏｕｒｃｅＬｉｓｔ、ＣｏｎｔｒｏｌＬｉｓｔ、ＩｎｓｔａｌｌＳｔｅｐ、ＵｎｉｎｓｔａｌｌＳｔｅｐ、Ｄｉｓｃｏｖｅｒｙのような複数のＸＭＬ子要素を含むこともできる。要素ＲｅｓｏｕｒｃｅＬｉｓｔは、タイプＲｅｓｏｕｒｃｅのゼロ、１、または複数の独自のＸＭＬ子要素を持つことができる。タイプＲｅｓｏｕｒｃｅのＸＭＬ要素は、アプリケーションへのリソース（たとえばバイナリファイル、設定ファイル、ディレクトリ、ウェブページ）またはリソースハンドラのリソース（たとえばスクリプト、Ｊａｖａクラス）への参照であってよい。一実施形態では、タイプＲｅｓｏｕｒｃｅの要素がＲｅｓｏｕｒｃｅＮａｍｅ、ＩｎｓｔａｌｌＰａｔｈ、ＩｎｓｔａｌｌＰｅｒｍｉｓｓｉｏｎのような１つ以上のＸＭＬ属性を持つことができる。属性ＲｅｓｏｕｒｃｅＮａｍｅは、マスターサーバ１７０のリポジトリ４５０内のリソースの名前とディレクトリパスから成る文字列であってよい。属性ＩｎｓｔａｌｌＰａｔｈは、展開されたリソースの名前とパスから成る文字列であってよい。属性ＩｎｓｔａｌｌＰｅｒｍｉｓｓｉｏｎは、一旦展開されると、展開されたリソースのアクセス許可を参照できる。

要素ＣｏｎｔｒｏｌＬｉｓｔは、タイプＣｏｎｔｒｏｌまたはＣａｐｔｕｒｅ−Ｃｏｎｔｒｏｌの１つ以上のＸＭＬ子要素を持つことができる。一実施形態では、タイプＣｏｎｔｒｏｌの要素はｃｏｍｐｏｎｅｎｔの制御サービスを定義し、Ｎａｍｅ（属性：制御サービスの名前）、ＰａｒａｍｅｔｅｒＬｉｓｔ（子要素）、Ｐｌａｎｓｔｅｐｓ（子要素）など１つ以上のＸＭＬ属性および／またはＸＭＬ子要素を持つことができる。タイプＣａｐｔｕｒｅ−Ｃｏｎｔｒｏｌの要素はｃｏｍｐｏｎｅｎｔの取り込み制御サービスを定義し、ＰａｒａｍｅｔｅｒＬｉｓｔ（子要素）、Ｐｒｅｐａｒｅ（Ｐｌａｎ ｓｔｅｐ ｌｉｓｔなど独自の複数子要素を持つ１つの子要素）、Ｃａｐｔｕｒｅ（取り込まれるファイルとディレクトリをリストする子要素）、Ｃｌｅａｎｕｐ（Ｐｌａｎ ｓｔｅｐ ｌｉｓｔなど複数独自の子要素を持つ１つの子要素）など１つ以上のＸＭＬ属性および／または子要素を持つことができる。

要素ＩｎｓｔａｌｌＳｔｅｐは、ＰａｒａｍｅｔｅｒＬｉｓｔ（子要素）、Ｐｌａｎ ｓｔｅｐ ｌｉｓｔ（子要素）など１つ以上のＸＭＬ属性および／またはＸＭＬ子要素を持つことができる。要素ＵｎｉｎｓｔａｌｌＳｔｅｐは、ＰａｒａｍｅｔｅｒＬｉｓｔ、Ｐｌａｎ ｓｔｅｐ ｌｉｓｔなど１つ以上のＸＭＬ子要素を持つことができる。

一実施形態では、パラメータリストをＰａｒａｍｅｔｅｒＬｉｓｔという名前のＸＭＬ要素で記述できる。要素ＰａｒａｍｅｔｅｒＬｉｓｔは、属性Ｎａｍｅ（パラメータの名前を参照）と要素Ｄｅｆａｕｌｔ（パラメータのデフォルト値を参照）を持つＰａｒａｍなど１つ以上のＸＭＬ属性および／またはＸＭＬ子要素を持つことができる。

一実施形態では、プランステップリストをＰｌａｎ ｓｔｅｐ ｌｉｓｔという名前のＸＭＬ要素で記述できる。要素Ｐｌａｎ ｓｔｅｐ ｌｉｓｔは、ＤｅｐｌｏｙＲｅｓｏｕｒｃｅｓ、ＵｎｄｅｐｌｏｙＲｅｓｏｕｒｃｅｓ、ＥｘｅｃＮａｔｉｖｅ、ＥｘｅｃＪａｖａ、Ｃａｌｌ、ＣｏｐｙＦｉｌｅ、ＣｈａｃｋＤｅｐｅｎｄｅｎｃｙなど１つ以上のＸＭＬ子要素を含むことができる。要素ＤｅｐｌｏｙＲｅｓｏｕｒｃｅｓは、この要素を含むコンポーネントのリソースを展開する。この展開は、該当するリソース１３０の各リソースタイプについて適切なリソースハンドラ４６０を呼び出してコンポーネントのＸＭＬ属性（たとえばＲｅｓｏｕｒｃｅＮａｍｅ、ＩｎｓｔａｌｌＰａｔｈ、ＩｎｓｔａｌｌＰｅｒｍｉｓｓｉｏｎ）をパラメータとして使用することにより実行される。要素ＵｎｄｅｐｌｏｙＲｅｓｏｕｒｃｅｓは、この要素を含むコンポーネントのアプリケーション（すなわちそのリソースすべて）をアンインストールする。

要素ＥｘｅｃＮａｔｉｖｅによって、ターゲットサーバマシン上で任意のコマンドの実行が可能になる。一実施形態では、要素ＥｘｅｃＮａｔｉｖｅはＣｏｍｍａｎｄ、ＳｕｃｃｅｓｓＭａｔｃｈ、ＭａｔｃｈＳｏｕｒｃｅなど１つ以上のＸＭＬ属性を含む。属性Ｃｏｍｍａｎｄは、実行されるコマンド（実行可能コマンドまたはシェルコマンドなど）を参照する文字列であってよい。属性ＳｕｃｃｅｓｓＭａｔｃｈは、実行されたコマンドの出力を検証するための式であってよい。属性ＭａｔｃｈＳｏｕｒｃｅは、コマンド出力のソースであってよい。

要素ＥｘｅｃＪａｖａによって、ターゲットサーバマシン上のエージェントによるＪａｖａプログラムの実行が可能になる。一実施形態では、要素ＥｘｅｃＪａｖａは、実行されるＪａｖａを示すＣｌａｓｓＮａｍｅなどのＸＭＬ子属性を含むことができる。要素Ｃａｌｌは、同じターゲットサーバマシン上に展開された別のコンポーネントの制御サービスを呼び出す。一実施形態では、要素ＣａｌｌはＮａｍｅ、ＣｏｍｐｏｎｅｎｔＮａｍｅ、ＡｒｇＬｉｓｔなど１つ以上のＸＭＬ属性および／またはＸＭＬ子要素を含むことができる。属性Ｎａｍｅは、別のコンポーネントの制御サービスの名前を参照する。属性ＣｏｍｐｏｎｅｎｔＮａｍｅは、別のコンポーネントの名前を参照する。属性ＡｒｇＬｉｓｔは、制御サービスの引数リストを参照する。

要素ＣｏｐｙＦｉｌｅによって、ターゲットサーバマシン上の１つ以上のファイルのコピーまたは移動が可能になる。一実施形態では、要素ＣｏｐｙＦｉｌｅはＳｏｕｒｃｅ（コピーされる１つ以上のファイルの１つ以上のパス名を示す）、Ｄｅｓｔｉｎａｔｉｏｎ（ファイルのコピー先のディレクトリまたはフォルダの１つ以上のパス名を示す）などのＸＭＬ属性を含むことができる。

要素ＣｈｅｃｋＤｅｐｅｎｄｅｎｃｙは、別のコンポーネントがターゲットサーバマシンにインストールされているかどうかを決定する。一実施形態では、要素ＣｈｅｃｋＤｅｐｅｎｄｅｎｃｙは、ＣｏｍｐｏｎｅｎｔＮａｍｅ、ＣｏｍｐｏｎｅｎｔＶｅｒｓｉｏｎ、ＩｎｓｔａｌｌＰａｔｈ、ＢｏｏｌｅａｎＤｅｐｅｎｄｅｎｃｙなどのＸＭＬ属性を含むことができる。属性ＣｏｍｐｏｎｅｎｔＮａｍｅは、依存関係をチェックするためにコンポーネントＸＭＬ要素の名前を参照する。属性ＣｏｍｐｏｎｅｎｔＶｅｒｓｉｏｎは、依存関係を確認するためにコンポーネントＸＭＬ要素のバージョンを参照する。属性ＩｎｓｔａｌｌＰａｔｈは、対応するコンポーネントのインストールパスを参照する。属性ＢｏｏｌｅａｎＤｅｐｅｎｄｅｎｃｙは、インストールされたコンポーネントのバージョンとの関係（たとえばｅｑｕｉａｌ、ｇｒｅａｔｅｒ＿ｔｈａｎ、ｇｒｅａｔｅｒ＿ｔｈａｎ＿ｅｑｕａｌ）を参照する。

一実施形態では、アプリケーション管理システム１００はＸＭＬ要素ｃｏｍｐｏｎｅｎｔおよびＰｌａｎ ｓｔｅｐ ｌｉｓｔのＸＭＬ Ｓｃｈｅｍａを含む。ＸＭＬ Ｓｃｈｅｍａとは、ＸＭＬ要素の必須ＸＭＬ下位要素、属性、およびデータ型を定義する標準化された手法である。

本発明の一実施形態では、アプリケーション管理システムがサポートする各リソースタイプ（ユーザに提供される各リソースタイプ）について少なくとも１つのリソースハンドラが存在する。リソースハンドラは、そのリソースタイプについて使用可能な管理手順すべてをカプセル化する。ＸＭＬ要素ｃｏｍｐｏｎｅｎｔによってリソースハンドラをモデル化することができる。一実施形態では、リソースハンドラをモデル化するコンポーネントをシステムサービスと呼ぶ（アプリケーションをモデル化するコンポーネントと対照して）。一般に、システムサービスはＸＭＬ子要素ＣｏｎｔｒｏｌＬｉｓｔを含み、ＣｏｎｔｒｏｌＬｉｓｔはこのリソースタイプとともに提供される各管理手順（たとえば展開、アンインストール）に対するＸＭＬ子要素Ｃｏｎｔｒｏｌと、各管理手順（および解析管理手順）についてリソース状態を管理するＸＭＬ子要素Ｃａｐｔｕｒｅ−Ｃｏｎｔｒｏｌとを含む。

特定の管理手順に対する制御要素は、その管理手順を実現するためのプランステップを表すＸＭＬ要素を直接または間接的に含むことができる。たとえば、いずれかのプランステップのタイプがＥｘｅｃＮａｔｉｖｅまたはＥｘｅｃＪａｖａである場合、該当するスクリプトまたはＪａｖａプログラムがＸＭＬ要素Ｒｅｓｏｕｒｃｅによってモデル化され参照される。アプリケーション管理システムは、アプリケーション展開と同じ方法でターゲットサーバマシン上にリソースハンドラを展開することができる。これによって、リソースハンドラのリソース（アプリケーション管理システムに属するスクリプトとＪａｖａプログラム）がターゲットサーバマシン上に展開され、対応するリソースタイプに対する管理手順がターゲットサーバマシン上で利用可能になる。したがって、アプリケーション管理システムは、そのリソースタイプを持つリソースを有するアプリケーションを管理できるまえに、ターゲットサーバマシン上にリソースハンドラを展開しなければならない。

図５に示したように、アプリケーションビルダー４００はリソース１３０（および対応するリソースタイプ）への１つ以上の参照を受け取る（たとえばユーザから）。選択された各リソース（受け取った各リソース）について、アプリケーションビルダー４００はモデル実行エンジン４４０のリソース取り込み（ＲｅｓｏｕｒｃｅＣａｐｔｕｒｅ）管理手順を呼び出し、選択されたリソース（および対応するリソースタイプ）への参照を入力として渡す。アプリケーションビルダー４００は選択されたリソース（および、ファイル集合において取り込むことができるリソースの属性とリソース状態）を受け取り、そのリソース（およびその属性とリソース状態）をリポジトリ４５０に配置する。次にアプリケーションビルダー４００は、アプリケーションに含めるために、選択されたすべてのリソースを参照するアプリケーションコンポーネントを作成できる。

アプリケーションコンポーネントを作成するために、アプリケーションビルダー４００は、とりわけＸＭＬヘッダーとリソースリスト（ＸＭＬ要素ＲｅｓｏｕｒｃｅＬｉｓｔ）を持つｃｏｍｐｏｎｅｎｔ ＸＭＬ要素を作成する。次に、各リソースについて、アプリケーションビルダー４００はＲｅｓｏｕｒｃｅ ＸＭＬ子要素をＸＭＬ要素ＲｅｓｏｕｒｃｅＬｉｓｔに追加する。アプリケーションビルダー４００は、リソース属性から属性ＩｎｓｔａｌｌＰａｔｈとＩｎｓｔａｌｌＰｅｒｍｉｓｓｉｏｎ（Ｒｅｓｏｕｒｃｅの）を引き出すことができる。アプリケーションビルダー４００は、ＩｎｓｔａｌｌＳｔｅｐ ＸＭＬ子要素とＤｅｐｌｏｙＲｅｓｏｕｒｃｅｓプランステップ（ＸＭＬ子要素として）を追加できる。また、アプリケーションビルダー４００はＵｎＩｎｓｔａｌｌＳｔｅｐ ＸＭＬ子要素とＵｎｄｅｐｌｏｙＲｅｓｏｕｒｃｅｓプランステップ（ＸＭＬ子要素として）を追加することもできる。さらに、アプリケーションビルダーはＤｉｓｃｏｖｅｒｙ ＸＭＬ子要素も追加できる。

さらに、ユーザは、追加ＸＭＬ子要素をコンポーネントに挿入することで、生じる結果としてアプリケーションコンポーネントをカスタマイズできる。たとえば、追加プランステップをアプリケーションコンポーネントのＩｎｓｔａｌｌＳｔｅｐ要素に追加して、そのリソースそれぞれについてではなくアプリケーション全体の展開動作をモデル化することができる。

アプリケーションマネージャ４１０は、アプリケーションへの参照、管理手順、およびターゲットサーバの組を入力として受け取る（たとえばユーザから）。アプリケーションマネージャ４１０は、リポジトリ４５０からアプリケーションコンポーネント（参照されたアプリケーションに対応する）を取得する。次に、アプリケーションマネージャ４１０はモデル実行エンジン４４０を呼び出して、選択された管理手順を実行する。モデル実行エンジン４４０の呼び出しには、アプリケーションに対応するｃｏｍｐｏｎｅｎｔ ＸＭＬ要素、実行される管理手順のタイプ、アプリケーション管理について選択された一組のターゲットサーバマシン１１０のパラメータが含まれる。

モデル実行エンジン４４０は、以下の１つ以上を入力として受け取る。（１）実行される管理手順のタイプ、（２）アプリケーションに対応するｃｏｍｐｏｎｅｎｔ ＸＭＬ要素、（３）リソースおよび／またはリソースタイプの指定、（４）そこからリソースおよびリソース状態を取得すべきソースサーバマシンの一組、（５）管理操作が実行されるターゲットサーバマシンの一組。

本発明の一実施形態では、モデル実行エンジン４４０をメインプログラムと複数のサブルーチンに組み込むことができる。一実施形態では、メインプログラムは各ターゲットサーバマシンの一組について以下の機能を実行できる。各リソースタイプ（直接入力によって受け取られた場合でもｃｏｍｐｏｎｅｎｔによって参照された場合でも）について、メインプログラムはリソースタイプテーブルを検索して該当するリソースハンドラを決定する。メインプログラムはターゲットサーバマシン上のエージェントと対話して、リソースハンドラがターゲットサーバマシンにインストールされているかどうかを決定できる。リソースハンドラがインストールされていない場合、およびＸＭＬ属性ｔａｒｇｅｔＰｌａｔｆｏｒｍｓにターゲットサーバマシンのプラットフォームが含まれている場合、メインプログラムはリソースハンドラＸＭＬコンポーネントを入力として、ｅｘｅｃｕｔｅ＿ＩｎｓｔａｌｌＳｔｅｐサブルーチンを呼び出す。この手順によって、ターゲットサーバマシン上のエージェントがアプリケーションを管理する装備が完全に整っていることが保証される。

選択された管理手順が”ｄｅｐｌｏｙ”である場合、メインプログラムはアプリケーションコンポーネントとターゲットサーバマシンを入力として、ｅｘｅｃｕｔｅ＿ＩｎｓｔａｌｌＳｔｅｐサブルーチンを呼び出す。また、メインプログラムはアプリケーションコンポーネントとターゲットサーバを入力として、ｅｘｅｃｕｔｅ＿Ｓｎａｐｓｈｏｔサブルーチンを呼び出すこともできる。このサブルーチン呼び出しによって、展開直後のアプリケーション状態を取り込むことができる。後で、必要に応じて別の管理手順からこの展開後状態にアクセスできることが保証される。

管理手順が”ｕｎｉｎｓｔａｌｌ”である場合、メインプログラムはアプリケーションコンポーネントとターゲットサーバマシンを入力として、ｅｘｅｃｕｔｅ＿ＵｎＩｎｓｔａｌｌＳｔｅｐサブルーチンを呼び出す。管理手順が”ａｎａｌｙｚｅ”である場合、メインプログラムはアプリケーションコンポーネントとターゲットサーバマシンを入力として、ｅｘｅｃｕｔｅ＿Ａｎａｌｙｓｉｓサブルーチンを呼び出す。管理手順が”ｃａｐｕｔｕｒｅ”である場合、メインプログラムはリソースタイプとターゲットサーバマシンを入力として、ｅｘｅｃｕｔｅ＿Ｃａｐｔｕｒｅサブルーチンを呼び出す。

一実施形態では、ｅｘｅｃｕｔｅ＿ＩｎｓｔａｌｌＳｔｅｐサブルーチンはＸＭＬ要素ＩｎｓｔａｌｌＳｔｅｐｓの各プランステップについて以下の機能を実行できる。プランステップがＤｅｐｌｏｙＲｅｓｏｕｒｃｅｓである場合、ｃｏｍｐｏｎｅｎｔの各ＸＭＬ子要素Ｒｅｓｏｕｒｃｅについて、ｅｘｅｃｕｔｅ＿ＩｎｓｔａｌｌＳｔｅｐサブルーチンは（１）リポジトリ４５０からリソースとその属性を取り出し、（２）リソースタイプを決定し（リソースタイプは次にリソース属性として格納される）、（３）リソースタイプテーブルを検索して該当するリソースハンドラを決定することができる。次に、ｅｘｅｃｕｔｅ＿ＩｎｓｔａｌｌＳｔｅｐサブルーチンは選択されたリソースハンドラ４９０を以下のように使用できる。すなわち、ＸＭＬ要素Ｃｏｎｔｒｏｌ（”ｄｅｐｌｏｙ”という名前の）を構文解析し、このＸＭＬ要素内の各プランステップについてターゲットサーバマシンを入力として、ｅｘｅｃｕｔｅ＿Ｐｌａｎ＿Ｓｔｅｐサブルーチンを呼び出す。ＤｅｐｌｏｙＲｅｓｏｕｒｃｅｓ以外のプランステップについて、ｅｘｅｃｕｔｅ＿ＩｎｓｔａｌｌＳｔｅｐはｅｘｅｃｕｔｅ＿Ｐｌａｎ＿Ｓｔｅｐサブルーチンを呼び出すことができる。

一実施形態では、ｅｘｅｃｕｔｅ＿ＳｎａｐｓｈｏｔサブルーチンはｃｏｍｐｏｎｅｎｔのＲｅｓｏｕｒｃｅ ＸＭＬ子要素それぞれについて以下の機能を実行できる。ｅｘｅｃｕｔｅ＿Ｓｎａｐｓｈｏｔサブルーチンは、リソースタイプ（たとえば、リソース属性としてリポジトリ４５０に格納されたリソースタイプ）および／または対応するリソースハンドラ（リソースタイプテーブルの検索により）を決定することができる。

また、ｅｘｅｃｕｔｅ＿ＳｎａｐｓｈｏｔサブルーチンはリソースハンドラのＣａｐｔｕｒｅ−Ｃｏｎｔｒｏｌ ＸＭＬ要素の各プランステップについて以下の機能を実行できる。ＸＭＬ要素Ｐｒｅｐａｒｅの各プランステップについて、ｅｘｅｃｕｔｅ＿Ｓｎａｐｓｈｏｔサブルーチンはターゲットサーバマシンを入力として、ｅｘｅｃｕｔｅ＿Ｐｌａｎ＿Ｓｔｅｐサブルーチンを呼び出す。たとえば、このプランステップは、データベースのような構造（Ｍｉｃｒｏｓｏｆｔ ＩＩＳメタベース、データベースなど）に格納された設定情報をＸＭＬプランステップＣａｐｔｕｒｅがアクセスできるファイル形式に変換することができる。ｅｘｅｃｕｔｅ＿Ｐｌａｎ＿Ｓｔｅｐサブルーチンはリソース名を入力として、ターゲットサーバマシンのエージェント上で実行されているリソース状態デポマネージャのｃｒｅａｔｅ＿ｓｔａｔｅサブルーチンを呼び出すことができる。ｅｘｅｃｕｔｅ＿Ｐｌａｎ＿Ｓｔｅｐサブルーチンは、ＸＭＬプランステップＣａｐｔｕｒｅで参照されるファイルとディレクトリそれぞれについてリソース状態デポマネージャのａｄｄ＿ｔｏ＿ｓｔａｔｅサブルーチンを呼び出すこともできる。ＸＭＬ要素Ｃｌｅａｎｕｐの各プランステップについて、ｅｘｅｃｕｔｅ＿Ｓｎａｐｓｈｏｔサブルーチンはターゲットサーバマシンを入力として、ｅｘｅｃｕｔｅ＿Ｐｌａｎ＿Ｓｔｅｐサブルーチンを呼び出すことができる。たとえば、Ｐｒｅｐａｒｅプランステップで作成されたファイルをここで削除することができる。

一実施形態では、ｅｘｅｃｕｔｅ＿ＵｎＩｎｓｔａｌｌＳｔｅｐサブルーチンは、ＸＭＬ要素ＵｎｉｎｓｔａｌｌＳｔｅｐ内の各プランステップについて以下の機能を実行できる。プランステップがＵｎｄｅｐｌｏｙＲｅｓｏｕｒｃｅｓである場合、ｃｏｍｐｏｎｅｎｔのＸＭＬ子要素Ｒｅｓｏｕｒｃｅそれぞれについて、ｅｘｅｃｕｔｅ＿ＵｎＩｎｓｔａｌｌＳｔｅｐサブルーチンはリソース状態デポマネージャ４８０のｒｅｔｒｉｅｖｅ＿ｓｔａｔｅ＿ｉｎｆｏｒｍａｔｉｏｎサブルーチンを呼び出してリソース状態情報を取得し、リソースのリソースタイプ（リソース属性として格納された）および／または対応するリソースハンドラ（リソースタイプテーブルを検索して）を決定することができる。さらに、ｅｘｅｃｕｔｅ＿ＵｎＩｎｓｔａｌｌＳｔｅｐサブルーチンはリソースハンドラ４９０を以下のように使用することができる。すなわち、ＸＭＬ要素Ｃｏｎｔｒｏｌの各プランステップ（”ｕｎ−ｉｎｓｔａｌｌ”という名前の）について、ｅｘｅｃｕｔｅ＿ＵｎＩｎｓｔａｌｌＳｔｅｐサブルーチンはターゲットサーバマシンおよび／または状態情報を入力として、ｅｘｅｃｕｔｅ＿Ｐｌａｎ＿Ｓｔｅｐサブルーチンを呼び出すことができる。一実施形態では、この入力情報をＸＭＬ要素ＰａｒａｍｅｔｅｒＬｉｓｔ内に提示することができる。代替的には、ＵｎｄｅｐｌｏｙＲｅｓｏｕｒｃｅｓ以外のプランステップについて、ｅｘｅｃｕｔｅ＿ＵｎＩｎｓｔａｌｌＳｔｅｐサブルーチンはｅｘｅｃｕｔｅ＿Ｐｌａｎ＿Ｓｔｅｐサブルーチンを呼び出すことができる。

一実施形態では、ｅｘｅｃｕｔｅ＿Ａｎａｌｙｓｉｓサブルーチンは、ｃｏｍｐｏｎｅｎｔのＲｅｓｏｕｒｃｅ ＸＭＬ子要素それぞれについて以下の機能を実行できる。ｅｘｅｃｕｔｅ＿Ａｎａｌｙｓｉｓサブルーチンは、リソースタイプ（リソース属性として格納された）および／または対応するリソースハンドラ（リソースタイプテーブルを検索して）を決定できる。さらに、ｅｘｅｃｕｔｅ＿Ａｎａｌｙｓｉｓサブルーチンはリソースへの参照を入力として、ターゲットサーバマシンのエージェント上で実行されているリソース状態デポマネージャからデータを取得することもできる。このプロセスで、たとえば一組のファイルとディレクトリを取得することができる。ｅｘｅｃｕｔｅ＿Ａｎａｌｙｓｉｓサブルーチンは、アプリケーションの各リソースのレコードを更新できるｅｘｅｃｕｔｅ＿Ｓｎａｐｓｈｏｔサブルーチンを呼び出すこともできる。

また、ｅｘｅｃｕｔｅ＿Ａｎａｌｙｓｉｓサブルーチンは、ｃｏｍｐｏｎｅｎｔのＲｅｓｏｕｒｃｅ XML子要素それぞれについて以下の機能を実行できる。ｅｘｅｃｕｔｅ＿Ａｎａｌｙｓｉｓサブルーチンはリソース名を入力として、リソース状態デポマネージャからｒｅｔｒｉｅｖｅ＿ｓｔａｔｅサブルーチンを呼び出すことができる。このプロセスで、たとえば一組のファイルとディレクトリを取得できる。次に、ファイルとディレクトリそれぞれについて、ｅｘｅｃｕｔｅ＿Ａｎａｌｙｓｉｓサブルーチンは２つのバージョンを比較し、比較結果をレポートに追加することができる。

一実施形態では、ｅｘｅｃｕｔｅ＿Ｃａｐｔｕｒｅサブルーチンは、リソースタイプ（リソース属性として格納された）および／または対応するリソースハンドラ（リソースタイプテーブルを検索して）を決定することができる。また、対応するリソースハンドラのＣａｐｔｕｒｅ−Ｃｏｎｔｒｏｌ ＸＭＬ要素の各プランステップについて、ｅｘｅｃｕｔｅ＿Ｃａｐｔｕｒｅサブルーチンは以下の機能を実行できる。ＸＭＬ要素Ｐｒｅｐａｒｅの各ＸＭＬ要素について、ｅｘｅｃｕｔｅ＿Ｃａｐｔｕｒｅサブルーチンはターゲットサーバマシンを入力として、ｅｘｅｃｕｔｅ＿Ｐｌａｎ＿Ｓｔｅｐサブルーチンを呼び出す。ｅｘｅｃｕｔｅ＿Ｃａｐｔｕｒｅサブルーチンは、ＸＭＬ要素Ｃａｐｔｕｒｅで参照されるファイルとディレクトリそれぞれを呼び出す側の手順に返すことができる。また、ＸＭＬ要素Ｃｌｅａｎｕｐの各ＸＭＬ要素について、ｅｘｅｃｕｔｅ＿Ｃａｐｔｕｒｅサブルーチンはターゲットサーバマシンを入力として、ｅｘｅｃｕｔｅ＿Ｐｌａｎ＿Ｓｔｅｐサブルーチンを呼び出す。

一実施形態では、ｅｘｅｃｕｔｅ＿Ｐｌａｎ＿Ｓｔｅｐサブルーチンは以下の機能を実行できる。ｅｘｅｃｕｔｅ＿Ｐｌａｎ＿Ｓｔｅｐサブルーチンは、実行される実際のプランステップに応じて様々な入力を処理できる。たとえば、プランステップがＥｘｅｃＮａｔｉｖｅである場合、ｅｘｅｃｕｔｅ＿Ｐｌａｎ＿ＳｔｅｐサブルーチンはＸＭＬ属性の列（Ｃｏｍｍａｎｄ、ＳｕｃｃｅｓｓＭａｔｃｈなど）をエージェントに渡すことができる。この例では、エージェントが適切なコマンドラインインタプリタ（シェルなど）でＣｏｍｍａｎｄ属性を実行し、その結果をＳｕｃｃｅｓｓＭａｔｃｈ評価の実行のために返す。たとえばプランステップがＥｘｅｃＪａｖａである場合、ｅｘｅｃｕｔｅ＿Ｐｌａｎ＿ＳｔｅｐサブルーチンはＸＭＬ属性の列（ＣｌａｓｓＮａｍｅ、ＩｎｐｕｔＦｉｌｅなど）を、この例では指示されたＪａｖａプログラムを実行するエージェントに渡すことができる。たとえばプランステップがＣｈｅｃｋＤｅｐｅｎｄｅｎｃｙである場合、ｅｘｅｃｕｔｅ＿Ｐｌａｎ＿Ｓｔｅｐサブルーチンは、エージェントが常駐する管理対象サーバマシン上にアプリケーションが存在するかどうかをエージェントが発見する命令（たとえば、ファイルとディレクトリの操作）を生成することができる。この命令ではＮａｍｅ、ＩｎｓｔａｌｌＰａｔｈなどの値を使用できる。

本発明の一実施形態では、モデリングマネージャ４２０はリソースタイプテーブルとリソースハンドラコンポーネントを管理できる。モデリングマネージャ４２０は、本発明のアプリケーション管理システムを拡張可能およびカスタマイズ可能にするメソッドをカプセル化することができる。モデリングマネージャ４２０を使用すれば、ユーザは１つ以上のサブルーチン（ａｄｄ＿ｒｅｓｏｕｒｃｅ＿ｔｙｐｅ、ｕｐｄａｔｅ＿ｒｅｓｏｕｒｃｅ＿ｔｙｐｅ、およびｒｅｍｏｖｅ＿ｒｅｓｏｕｒｃｅ＿ｔｙｐｅ）を呼び出すことができる。

一実施形態では、サブルーチンａｄｄ＿ｒｅｓｏｕｒｃｅ＿ｔｙｐｅは入力としてリソースタイプと対応するリソースハンドラを受け取る。サブルーチンａｄｄ＿ｒｅｓｏｕｒｃｅ＿ｔｙｐｅは新しいエントリをリソースタイプテーブルに追加し、リソースタイプを使用して、新たに追加されたリソースハンドラにマッピングすることができる。サブルーチンａｄｄ＿ｒｅｓｏｕｒｃｅ＿ｔｙｐｅは、リソースハンドラコンポーネントのリソース（たとえばスクリプト、Ｊａｖａプログラム）をリポジトリ４５０に追加することもできる。次に、新しいリソースハンドラをアクティブなリソースハンドラの組に追加することができる。

一実施形態では、サブルーチンｕｐｄａｔｅ＿ｒｅｓｏｕｒｃｅ＿ｔｙｐｅは入力としてリソースタイプと対応するリソースハンドラを受け取る。サブルーチンｕｐｄａｔｅ＿ｒｅｓｏｕｒｃｅ＿ｔｙｐｅは、新しいリソースハンドラにマッピングするようにリソースタイプテーブル内のリソースタイプのマッピングを変更することができる。このため、新しいリソースハンドラは「アクティブなシステムサービス」となり、古いリソースハンドラは非アクティブとなる。サブルーチンｕｐｄａｔｅ＿ｒｅｓｏｕｒｃｅ＿ｔｙｐｅは、リソースハンドラコンポーネントのリソース（たとえばスクリプト、Ｊａｖａプログラム）をリポジトリ４５０に追加することもできる。次に、サブルーチンｕｐｄａｔｅ＿ｒｅｓｏｕｒｃｅ＿ｔｙｐｅは管理手順”ｄｅｐｌｏｙ”、新しいリソースハンドラ、およびターゲットサーバマシンの組を入力として、モデル実行エンジン４４０のメインプログラムを呼び出すことができる。さらに、同じリソースタイプについてリソースハンドラが管理対象サーバマシン上に先に展開されている場合、サブルーチンｕｐｄａｔｅ＿ｒｅｓｏｕｒｃｅ＿ｔｙｐｅはその管理対象サーバマシンをターゲットサーバマシンの組に含めることができる。

一実施形態では、サブルーチンｒｅｍｏｖｅ＿ｒｅｓｏｕｒｃｅ＿ｔｙｐｅは入力としてリソースタイプを受け取る。サブルーチンｒｅｍｏｖｅ＿ｒｅｓｏｕｒｃｅ＿ｔｙｐｅは、リソースタイプテーブルからリソースタイプのエントリを削除できる。次に、サブルーチンｒｅｍｏｖｅ＿ｒｅｓｏｕｒｃｅ＿ｔｙｐｅは管理手順”ｕｎｉｎｓｔａｌｌ”と一組のターゲットサーバマシンを入力として、モデル実行エンジン４４０のメインプログラムを呼び出すことができる。さらに、同じリソースタイプについてリソースハンドラが管理対象サーバマシン上に先に展開されている場合、サブルーチンｒｅｍｏｖｅ＿ｒｅｓｏｕｒｃｅ＿ｔｙｐｅはその管理対象サーバマシンを一組のターゲットサーバマシンに含めることができる。

図６に示したように、一実施形態では、管理手順によって管理対象アプリケーションそれぞれの状態の履歴をリソース状態デポ４９０に格納することができる。たとえばファイルの集まりとして状態を格納できる。各リソースタイプについて、状態情報は、所定の形式の様々なファイルの集まりであってよい。たとえば、リソースタイプ”ＩＩＳ Ｗｅｂ ａｐｐｌｉｃａｔｉｏｎ”のリソースの場合、状態情報として、ＩＩＳメタベース（ＩＩＳウェブサーバの設定データベース）内のリソースの関連コンフィギュレーション設定を反映するＸＭＬファイルを含むことができる。管理手順によって、このＸＭＬファイルをリード処理、リソースの実際の設定を反映するように変更することができる。

さらに、エージェント１７５は、リソースに関連付けられたすべての管理手順に代わってエージェント１７５上のリソース状態デポを管理するリソース状態デポマネージャ４８０を含むことができる。一実施形態では、リソース状態デポマネージャ４８０は１つ以上のサブルーチン（ｃｒｅａｔｅ＿ｓｔａｔｅ、ａｄｄ＿ｔｏ＿ｓｔａｔｅ、ｒｅｔｒｉｅｖｅ＿ｓｔａｔｅ＿ｉｎｆｏｒｍａｔｉｏｎ、ｒｅｔｒｉｅｖｅ＿ｓｔａｔｅ、およびｄｅｌｅｔｅ＿ｓｔａｔｅ）を含むことができる。

一実施形態では、サブルーチンｃｒｅａｔｅ＿ｓｔａｔｅは入力としてリソース名を受け取る。次に、サブルーチンｃｒｅａｔｅ＿ｓｔａｔｅはそのリソース名に関連付けられた空のレコードを作成できる。サブルーチンａｄｄ＿ｔｏ＿ｓｔａｔｅは、入力としてリソース名と要素名を受け取る。次に、サブルーチンａｄｄ＿ｔｏ＿ｓｔａｔｅは要素（たとえばファイル、ディレクトリ）をレコードに追加できる。サブルーチンｒｅｔｒｉｅｖｅ＿ｓｔａｔｅ＿ｉｎｆｏｒｍａｔｉｏｎは、入力としてリソース名を受け取る。次に、サブルーチンｒｅｔｒｉｅｖｅ＿ｓｔａｔｅ＿ｉｎｆｏｒｍａｔｉｏｎは各要素（たとえばファイル、ディレクトリ）の参照および／または属性を呼び出す側のプロセスに返すことができる。サブルーチンｒｅｔｒｉｅｖｅ＿ｓｔａｔｅは、入力としてリソース名を受け取る。次に、サブルーチンｒｅｔｒｉｅｖｅ＿ｓｔａｔｅは各要素（たとえばファイル、ディレクトリ）を呼び出す側のプロセスに返すことができる。サブルーチンｄｅｌｅｔｅ＿ｓｔａｔｅは、入力としてリソース名を受け取る。次に、サブルーチンｄｅｌｅｔｅ＿ｓｔａｔｅはリソース状態デポ４９０からレコード（およびその要素すべて）を削除できる。

Ｍｉｃｒｏｓｏｆｔ Ｗｉｎｄｏｗｓプラットフォーム用の財務アプリケーションをモデル化するコンポーネントの例示部分を表１に示している。このコンポーネント（部分）には、IISウェブアプリケーション（ＦＭＳｔｏｃｋｓ２０００）とCOM PLUSコンポーネント（ＦＭＳｔｏｃｋｓ２０００ｃｏｒｅ）という２つのリソースが含まれている。この例では、ＩｎｓｔａｌｌＳｔｅｐ ＸＭＬ要素に以下の３つのプランステップが含まれる。（１）別のコンポーネント（”ｓｅｒｖｉｃｅＨａｎｄｌｅｒ”）の”ｓｔｏｐ”という名前の制御サービスの呼び出し、（２）ＩＩＳ ＷｅｂとＣＯＭ Ｐｌｕｓの両方のリソースタイプについてリソースハンドラの制御サービス”ｄｅｐｌｏｙ”を呼び出すｄｅｐｌｏｙＲｅｓｏｕｒｃｅｓプランステップ、（３）別のコンポーネント（”ｓｅｒｖｉｃｅＨａｎｄｌｅｒ”）の”ｓｔｏｐ”という名前の制御サービスの呼び出し。第１と第３のプランステップは、アプリケーション構築時のユーザカスタマイズの結果である。

リソースタイプ”ＩＩＳ Ｗｅｂ”のリソースハンドラ（「システムサービス」）の例示的な部分を表２に示している。このコンポーネント（部分）には、Ｗｉｎｄｏｗｓホスティングスクリプトのディレクトリである１つのリソース”ｍｅｔａ”が含まれている。ＩｎｓｔａｌｌＳｔｅｐ ＸＭＬ要素は、このディレクトリをターゲットサーバ上のどこに配置するかをガイドする。ｃｏｎｔｒｏｌＬｉｓｔ ＸＭＬ要素”ｉｎｓｔａｌｌ”は、”ｍｅｔａ”ディレクトリから特定のスクリプト”ｍｅｔａＩｍｐｏｒｔ”を呼び出す。この実施形態では、タイプが”ＩＩＳ Ｗｅｂ”のリソースすべての設定データが、ターゲットサーバマシン上のデータベースのような構造（「メタベース」）に格納される。このスクリプトは、リソースの設定をターゲットサーバマシン上の実際のメタベースに結合する。この設定データは、コンポーネントの作成時にアプリケーションによって取り込みされたものであり、明確な形式でファイルに格納されている。このファイルは、”ｍｅｔａＩｍｐｏｒｔ”スクリプトによってリード処理される。

例を示し添付図面と合わせて本発明を詳述してきたが、多くの変更と修正を、本発明の精神と範囲から逸脱することなく実施できることは当業者にとって理解されるものである。したがって、このような変更と修正が本発明の範囲から逸脱しない限り、このような変更と修正は本発明に含まれるものとみなすべきである。

本発明による従うアプリケーション管理システムの実施形態を示すブロック図である。 本発明の実施形態に従ってアプリケーションを管理できるコンピュータネットワークの概略図である。 本発明に従うアプリケーション作成プロセスの実施形態を示す流れ図である。 本発明に従うアプリケーション管理プロセスの実施形態を示す流れ図である。 本発明に従うマスターサーバの実施形態における複数の内部モジュールを示すブロック図である。 本発明に従うエージェントの実施形態における複数の内部モジュールを示すブロック図である。

符号の説明

１００ アプリケーション管理システム
１１０ ターゲットサーバマシン
１２０ ユーザ入力
１３０ リソース
１３５ ソースサーバマシン
１４０ リソース状態
１５０ 中央コンピュータ
１５５ 通信ネットワーク
１６０ 管理対象サーバマシン、管理対象サーバコンピュータ
１７０ マスターサーバ
１７５ エージェント
１８０ ユーザインタフェース
４００ アプリケーションビルダー
４１０ アプリケーションマネージャ
４２０ モデリングマネージャ
４３０ 状態マネージャ
４４０ モデル実行エンジン
４５０ リポジトリ
４６０ リソースハンドラ（モジュール）
４７０ エージェントモデル実行エンジン
４８０ リソース状態デポマネージャ
４９０ リソース状態デポ
４９５ コンポーネントＡ

Claims (77)

1. 第１のコンピュータによって実行可能なアプリケーション管理方法であって、
   前記アプリケーションに含めるために利用可能なリソース群の中から選択された、第２のコンピュータ上に展開されている第１のリソースの情報を、前記第１のコンピュータが受け取るステップと、
   前記第１のリソースのリソース状態を取得するための命令群を、前記第１のコンピュータが生成するステップと、
   前記リソース状態を前記第２のコンピュータから取得する処理が前記第２のコンピュータ上で実行されるように、前記第２のコンピュータに前記命令群を与えるステップと、
   前記第１のコンピュータが、前記リソース状態を前記第２のコンピュータから受け取るステップと、を含み、
   前記命令群は、前記第１のリソースのリソースタイプに基づくものである、方法。
2. 前記第１のリソースのリソースタイプの指定を前記第１のコンピュータが受け取るステップを更に含む、請求項１記載の方法。
3. 前記第１のリソースのリソースタイプを決定するステップを更に含む、請求項１記載の方法。
4. 前記命令群は、前記第２のコンピュータから前記第１のリソースを取得するための命令を更に含み、
   前記第２のコンピュータから前記第１のリソースを受け取るステップを更に含む、請求項１記載の方法。
5. 管理の対象となるターゲットコンピュータの選択結果を前記第１のコンピュータが受け取るステップと、
   前記第１のリソース及び前記リソース状態に基づいて、当該選択された前記ターゲットコンピュータ上の前記アプリケーションを管理するための命令群を、前記第１のコンピュータが生成するステップと、
   前記ターゲットコンピュータ上で前記アプリケーションの管理が実行されるように、前記ターゲットコンピュータに前記命令群を与えるステップと、
   を含む請求項１記載の方法。
6. 前記アプリケーションを管理するための前記命令群は、
   前記ターゲットコンピュータ上で前記アプリケーションを展開する命令、前記ターゲットコンピュータ上で前記アプリケーションを再設定する命令、及び前記ターゲットコンピュータ上で前記アプリケーションをアップグレードする命令からなる群から選択される命令を含む、請求項５記載の方法。
7. 前記リソース状態を前記第１コンピュータ上に格納するステップを更に含む、請求項１記載の方法。
8. 前記リソース状態を形成する設定情報は、前記リソースタイプに基づくものである、請求項１記載の方法。
9. 前記設定情報は、前記第２コンピュータのオペレーティングシステムに依存しないものである、請求項８記載の方法。
10. 前記リソース状態を取得するための前記命令群は、少なくとも１つのファイルに前記リソース状態を格納するための命令を含み、
    前記リソース状態を含む前記少なくとも１つのファイルを前記第２コンピュータから受け取るステップを更に含む、請求項１記載の方法。
11. 前記リソース状態を取得するための前記命令群は、データベースに前記リソース状態を格納するための命令を含み、
    前記リソース状態を含む前記データベースを前記第２コンピュータから受け取るステップを更に含む、請求項１記載の方法。
12. 前記アプリケーションに含めるために利用可能な前記リソース群の中から選択された、第３のコンピュータ上に展開されている第２のリソースの情報を、前記第１のコンピュータが受け取るステップと、
    当該選択された第２のリソースのリソース状態を取得するための第２の命令群を、前記第１のコンピュータが生成するステップと、
    前記第２のリソースの前記リソース状態を取得する処理が前記第３のコンピュータ上で実行されるように、前記第３のコンピュータに前記第２の命令群を与えるステップと、
    前記第１のコンピュータが、前記第２のリソースの前記リソース状態を前記第３のコンピュータから受け取るステップと、
    前記第１及び第２のリソース並びに前記アプリケーションを展開するための命令を含み、前記アプリケーションをターゲットコンピュータに展開するためのアプリケーションパッケージを、前記第１のコンピュータが生成するステップと、を含み、
    前記第２の命令群は、前記第２のリソースのリソースタイプに基づくものであり
    前記アプリケーションを展開するための前記命令は、前記第１及び第２のリソースの前記リソース状態に基づくものである、請求項１記載の方法。
13. 前記アプリケーションに含めるために利用可能な前記リソース群の中から選択された、第２のコンピュータ及び第３のコンピュータ上に展開されている第２のリソースの情報を、前記第１のコンピュータが受け取るステップと、
    前記第２のコンピュータ及び前記第３のコンピュータのうち、リソース状態を取得するために選択された何れか１つの情報を前記第１のコンピュータが受け取るステップと、
    前記第２のリソースのリソース状態を取得するための第２の命令群を前記第１のコンピュータが生成するステップと、
    前記第２のリソースの前記リソース状態を取得する処理が前記第２のコンピュータ及び前記第３のコンピュータのうち選択された何れか一方のコンピュータ上で実行されるように、当該選択された一方のコンピュータに前記第２の命令群を与えるステップと、
    前記第１のコンピュータが、前記第２のリソースの前記リソース状態を当該選択された一方のコンピュータから受け取るステップと、を含み、
    前記第２の命令群は、前記第２のリソースのリソースタイプに基づくものである、請求項１記載の方法。
14. 管理の対象となるターゲットコンピュータの選択結果を前記第１のコンピュータが受け取るステップと、
    前記第１及び第２のリソース並びに前記アプリケーションを管理するための命令を含み、前記アプリケーションをターゲットコンピュータ上で管理するためのアプリケーションパッケージを、前記第１のコンピュータが生成するステップと、を含み、
    前記アプリケーションを管理するための前記命令は、前記第１及び第２のリソースの前記リソース状態に基づくものである、請求項１３記載の方法。
15. 前記アプリケーションを管理するための前記命令は、
    前記ターゲットコンピュータ上で前記アプリケーションを展開する命令、前記ターゲットコンピュータ上で前記アプリケーションを再設定する命令、及び前記ターゲットコンピュータ上で前記アプリケーションをアップグレードする命令からなる群から選択される命令を含む、請求項１４記載の方法。
16. 通信ネットワークを介してマスターサーバに接続されたターゲットサーバマシン上のアプリケーションを管理する、前記マスターサーバによって実行可能な方法であって、
    前記アプリケーションに含めるために選択された複数のリソースの情報を、前記マスターサーバが受け取るステップと、
    前記複数のリソースに対応するリソース状態を取得するための命令を、前記マスターサーバが生成するステップと、
    前記リソース状態を取得する処理がソースサーバマシン上で実行されるように、前記複数のリソースのうち少なくとも１つを含む前記ソースサーバマシンに前記命令を与えるステップと、
    前記マスターサーバが、前記ソースサーバマシンから取得された前記リソース状態を受け取るステップと、
    前記複数のリソース並びに前記リソース状態に基づいて前記アプリケーションを展開するための命令を含み、前記アプリケーションを前記ターゲットサーバマシンに展開するためのアプリケーションパッケージを、前記マスターサーバが生成するステップと、を含み、
    前記複数のリソースの各々は、前記通信ネットワークを介して前記マスターサーバに接続された少なくとも１つの前記ソースサーバマシン上に展開されたものであり、
    前記命令は、前記複数のリソースの各々のリソースタイプに基づくものである、方法。
17. 前記ターゲットサーバマシン上に前記アプリケーションが展開されるように、前記ターゲットサーバマシンに前記アプリケーションパッケージを与えるステップを更に含む、請求項１６記載の方法。
18. 前記アプリケーションを展開するための前記命令は、前記ターゲットサーバマシンを設定するための命令を含むものである、請求項１６記載の方法。
19. 前記アプリケーションを展開するための前記命令は、前記ターゲットサーバマシン上の前記複数のリソースの各々を設定するための命令を含むものである、請求項１６記載の方法。
20. コンピュータによって実行可能な方法であって、
    リソース及びそれに対応するリソースタイプを有し、ユーザによって選択されたアプリケーションの情報を、前記コンピュータが受け取るステップと、
    前記リソースに関連付けられたリソース状態を検索するステップと、
    前記リソースタイプに基づいて利用可能な管理手順群を決定するステップと、
    前記管理手順群をユーザの選択肢として与えるステップと、
    前記管理手順群の中から選択された管理手順の情報を前記コンピュータが受け取るステップと、
    当該選択された前記管理手順を実行するための命令群を前記コンピュータが生成するステップと、を含み、
    前記命令群は、前記リソース状態及び前記管理手順に基づくものである、方法。
21. 前記命令群は、更に前記リソースタイプにも基づくものである、請求項２０記載の方法。
22. 前記命令群は、前記管理手順の実行後に、前記リソースのリソース状態を取得するための命令を含み、
    前記管理手順の実行後に、当該取得された前記リソース状態を受け取るステップを更に含む、請求項２０記載の方法。
23. 前記アプリケーションが展開されており、管理の対象となるターゲットコンピュータの選択結果を、前記コンピュータが受け取るステップと、
    当該選択された前記ターゲットコンピュータ上で前記管理手順が実行されるように、前記ターゲットコンピュータに前記命令群を与えるステップと、を更に含み、
    前記命令群は、更に前記ターゲットコンピュータにも基づくものである、請求項２０記載の方法。
24. 前記命令群は、前記ターゲットコンピュータから前記アプリケーションを削除するための命令を含むものである、請求項２３記載の方法。
25. 前記命令群は、前記ターゲットコンピュータ上の前記アプリケーションのリソース状態を決定するための命令を含むものである、請求項２３記載の方法。
26. 前記命令群は、前記ターゲットコンピュータ上の前記アプリケーションのリソース状態を比較するための命令を含むものである、請求項２３記載の方法。
27. 前記リソース及び前記リソース状態を前記ターゲットコンピュータに与えるステップを更に含む、請求項２３記載の方法。
28. 前記アプリケーションが展開されており、管理の対象となる複数のターゲットコンピュータの選択結果を、前記コンピュータが受け取るステップと、
    当該選択された前記ターゲットコンピュータの各々に、当該各コンピュータ上で前記管理手順が実行されるように生成された前記命令群を与えるステップと、を更に含み、
    前記命令群を生成するステップは、前記各ターゲットコンピュータに対して、前記管理手順を実行するための命令群を生成するステップを含み、
    前記命令群は、前記リソース状態、前記管理手順及び前記各ターゲットコンピュータに基づくものである、請求項２０記載の方法。
29. 通信ネットワークを介してマスターサーバに接続された管理対象サーバマシン上のアプリケーションを管理する、前記マスターサーバによって実行可能な方法であって、
    少なくとも１つのリソースを有するアプリケーションの選択結果を、前記マスターサーバが受け取るステップと、
    前記管理対象サーバマシンの中から前記アプリケーションが展開されている管理対象サーバマシンを決定するための命令を、前記マスターサーバが生成するステップと、
    前記アプリケーションが展開されている前記管理対象サーバマシンを特定する処理が実行されるように、前記管理対象サーバマシンに前記命令を与えるステップと、を含み、
    前記命令は、前記少なくとも１つのリソースに対応するリソースタイプに基づくものである、方法。
30. 前記命令は、前記少なくとも１つのリソースに対応する現在のリソース状態を取得するための命令を更に含むものである、請求項２９記載の方法。
31. 前記命令は、展開された前記少なくとも１つのリソースのリソース状態を決定するとともに比較する命令を更に含むものである、請求項２９記載の方法。
32. アプリケーションを管理するための第１のコンピュータによって実行可能な命令が記録されている、コンピュータ読取可能な媒体であって、
    当該媒体に記録されている前記命令は、
    前記アプリケーションに含めるために利用可能なリソース群の中から選択された、第２のコンピュータ上に展開されている第１のリソースの情報を受け取るための命令と、
    前記第１のリソースのリソース状態を取得するための命令群を生成するための命令と、
    前記リソース状態を前記第２のコンピュータから取得する処理が前記第２のコンピュータ上で実行されるように、前記第２のコンピュータに前記命令群を与えるための命令と、
    前記リソース状態を前記第２のコンピュータから受け取るための命令と、を含み、
    前記命令群は、前記第１のリソースのリソースタイプに基づくものである、媒体。
33. 前記第１のリソースのリソースタイプの指定を受け取るための命令を更に含む、請求項３２記載の媒体。
34. 前記第１のリソースのリソースタイプを決定するための命令を更に含む、請求項３２記載の媒体。
35. 前記命令群は、前記第２のコンピュータから前記リソースを取得するための命令を更に含むものである、請求項３２記載の媒体。
36. 管理対象となるターゲットコンピュータの選択結果を受け取るための命令と、
    前記第１のリソース及び前記リソース状態に基づいて、当該選択されたターゲットコンピュータ上の前記アプリケーションを管理するための命令群を生成するための命令と、
    前記ターゲットコンピュータ上で前記アプリケーションの管理が実行されるように、前記ターゲットコンピュータに前記命令群を与えるための命令と、を更に含む、請求項３２記載の媒体。
37. 前記アプリケーションを管理するための前記命令群は、
    前記ターゲットコンピュータ上で前記アプリケーションを展開する命令、前記ターゲットコンピュータ上で前記アプリケーションを再設定する命令、及び前記ターゲットコンピュータ上で前記アプリケーションをアップグレードする命令からなる群から選択される命令を含む、請求項３６記載の媒体。
38. 前記リソース状態を形成する設定情報は、前記リソースタイプに基づくものであり、前記第２のコンピュータのオペレーティングシステムには依存しないものである、請求項３２記載の媒体。
39. 前記リソース状態を取得するための前記命令群は、少なくとも１つのファイルに前記リソース状態を格納するための命令を含むものである、請求項３２記載の媒体。
40. 前記リソース状態を取得するための前記命令群は、データベースに前記リソース状態を格納するための命令を含むものである、請求項３２記載の媒体。
41. 当該媒体に記録されている前記命令は、
    前記アプリケーションに含めるために利用可能な前記リソース群の中から選択された、第３のコンピュータ上に展開されている第２のリソースの情報を受け取るための命令と、
    当該選択された第２のリソースのリソース状態を取得するための第２の命令群を生成するための命令と、
    前記第２のリソースの前記リソース状態を取得する処理が前記第３のコンピュータ上で実行されるように、前記第３のコンピュータに前記第２の命令群を与えるための命令と、
    前記第２のリソースの前記リソース状態を受け取るための命令と、
    前記第１及び第２のリソース並びに前記アプリケーションを展開するための命令を含み、前記アプリケーションをターゲットコンピュータに展開するためのアプリケーションパッケージを生成するための命令と、を更に含み、
    前記第２の命令群は、前記第２のリソースのリソースタイプに基づくものであり、
    前記アプリケーションを展開するための前記命令は、前記第１及び第２のリソースの前記リソース状態に基づくものである、請求項３２記載の媒体。
42. 当該媒体に記録されている前記命令は、
    前記アプリケーションに含めるために利用可能な前記リソース群の中から選択された、第２のコンピュータ及び第３のコンピュータ上に展開されている第２のリソースの情報を受け取るための命令と、
    前記第２のコンピュータ及び前記第３のコンピュータのうち、リソース状態を取得するために選択された何れか１つの情報を受け取るための命令と、
    前記第２のリソースのリソース状態を取得するための第２の命令群を生成するための命令と、
    前記第２のリソースの前記リソース状態を取得する処理が前記第２のコンピュータ及び前記第３のコンピュータのうち選択された何れか一方のコンピュータ上で実行されるように、当該選択された一方のコンピュータに前記第２の命令群を与えるための命令と、
    前記第２のリソースの前記リソース状態を当該選択された一方のコンピュータから受け取るための命令と、を更に含み、
    前記第２の命令群は、前記第２のリソースのリソースタイプに基づくものである、請求項３２記載の媒体。
43. 前記第１及び第２のリソース並びに前記アプリケーションを展開するための命令を含み、前記アプリケーションをターゲットコンピュータに展開するためのアプリケーションパッケージを生成するための命令を更に含み、
    前記アプリケーションを展開するための前記命令は、前記第１及び第２のリソースの前記リソース状態に基づくものである、請求項４２記載の媒体。
44. 通信ネットワークを介してコンピュータに接続されたターゲットサーバマシン上のアプリケーションを管理するための前記コンピュータによって実行可能な命令が記録されている、コンピュータ読取可能な媒体であって、
    当該媒体に記録されている前記命令は、
    前記アプリケーションに含めるために選択された複数のリソースの情報を受け取るための命令と、
    前記複数のリソースに対応するリソース状態を取得するための第１の命令群を生成するための命令と、
    前記リソース状態を取得する処理がソースサーバマシン上で実行されるように、前記複数のリソースのうち少なくとも１つを含む前記ソースサーバマシンに前記第１の命令群を与えるための命令と、
    前記ソースサーバマシンから取得された前記リソース状態を受け取るための命令と、
    前記複数のリソース並びに前記リソース状態に基づいて前記アプリケーションを展開するための第２の命令群を含み、前記アプリケーションを前記ターゲットサーバマシンに展開するためのアプリケーションパッケージを生成するための命令と、を含み、
    前記複数のリソースの各々は、前記通信ネットワークを介して前記コンピュータに接続された少なくとも１つの前記ソースサーバマシン上に展開されたものであり、
    前記第１の命令群は、前記複数のリソースの各々のリソースタイプに基づくものである、媒体。
45. 前記ターゲットサーバマシンが前記アプリケーションを展開できるように、前記アプリケーションパッケージを前記ターゲットサーバマシンに与えるための命令を更に含む、請求項４４記載の媒体。
46. 前記第２の命令群は、前記ターゲットサーバマシンを設定するための命令を含むものである、請求項４４記載の媒体。
47. 前記第２の命令群は、前記ターゲットサーバマシン上の前記複数リソースの各々を設定するための命令を含むものである、請求項４４記載の媒体。
48. コンピュータによって実行可能な命令が記録されているコンピュータ読取可能な媒体であって、
    当該媒体に記録されている前記命令は、
    リソース及びそれに対応するリソースタイプを有し、ユーザによって選択されたアプリケーションの情報を受け取るための命令と、
    前記リソースに関連付けられたリソース状態を検索するための命令と、
    前記リソースタイプに基づいて利用可能な管理手順群を決定するための命令と、
    前記管理手順群をユーザの選択肢として与えるための命令と、
    前記管理手順群の中から選択された管理手順の情報を受け取るための命令と、
    当該選択された前記管理手順を実行するための命令群を前記コンピュータが生成するステップと、を含み、
    前記命令群は、前記リソース状態及び前記管理手順に基づくものである、媒体。
49. 前記命令群は、更に前記リソースタイプにも基づくものである、請求項４８記載の媒体。
50. 前記命令群は、前記管理手順の実行後に、前記リソースのリソース状態を取得するための命令を含むものである、請求項４８記載の媒体。
51. 当該媒体に記録されている前記命令は、
    前記アプリケーションが展開されており、管理の対象となるターゲットコンピュータの選択結果を、前記コンピュータが受け取るための命令と、
    当該選択された前記ターゲットコンピュータ上で前記管理手順が実行されるように、前記ターゲットコンピュータに前記命令群を与えるための命令と、を更に含み、
    前記命令群は、更に前記ターゲットコンピュータにも基づくものである、請求項４８記載の媒体。
52. 前記命令群は、前記ターゲットコンピュータから前記アプリケーションを削除するための命令を含むものである、請求項５１記載の媒体。
53. 前記命令群は、前記ターゲットコンピュータ上の前記アプリケーションのリソース状態を決定するための命令を含むものである、請求項５１記載の媒体。
54. 前記命令群は、前記ターゲットコンピュータ上の前記アプリケーションのリソース状態を比較するための命令を含むものである、請求項５１記載の媒体。
55. 当該媒体に記録されている前記命令は、前記リソース及び前記リソース状態を前記ターゲットコンピュータに与えるための命令を更に含む、請求項５１記載の媒体。
56. 通信ネットワークを介してコンピュータに接続された管理対象サーバマシン上のアプリケーションを管理する、前記コンピュータによって実行可能な命令が記録されている、コンピュータ読取可能な媒体であって、
    当該媒体に記録されている前記命令は、
    少なくとも１つのリソースを有するアプリケーションの選択結果を受け取るための命令と、
    前記管理対象サーバマシンの中から前記アプリケーションが展開されている管理対象サーバマシンを決定するための命令群を生成するための命令と、
    前記アプリケーションが展開されている前記管理対象サーバマシンを特定する処理が実行されるように、前記管理対象サーバマシンに前記命令群を与えるための命令と、を含み、
    前記命令群は、前記少なくとも１つのリソースに対応するリソースタイプに基づくものである、媒体。
57. 前記命令群は、前記少なくとも１つのリソースに対応する現在のリソース状態を取得するための命令を更に含むものである、請求項５６記載の媒体。
58. 前記命令は、展開された前記少なくとも１つのリソースのリソース状態を決定するとともに比較する命令を更に含むものである、請求項５６記載の媒体。
59. 通信ネットワークを介してソースサーバマシンに接続されたマスターサーバを備えるアプリケーション管理システムであって、
    前記マスターサーバは、
    前記アプリケーションに含めるために利用可能なリソース群の中から選択された第１のリソースの情報を受け取るアプリケーションビルダーと、
    前記アプリケーションビルダーに接続されており、前記第１のリソースに対応するリソース状態を取得するための命令群を生成するモデル実行エンジンと、を有し、
    前記命令群は、前記第１のリソースのリソースタイプに基づくものであり、
    前記マスターサーバは、前記命令群を前記通信ネットワークを介して前記ソースサーバマシンに与えるのに適合している、システム。
60. 前記マスターサーバは、
    前記リソース状態を格納するリポジトリと、
    前記ソースサーバマシンから前記リソース状態を受け取り、前記リソース状態を前記リポジトリに格納する状態マネージャと、を更に有する、請求項５９記載のシステム。
61. 前記マスターサーバは、前記第１のリソースのリソースタイプを決定し、前記リソースタイプを前記モデル実行エンジンに与えるモデリングマネージャを更に有する、請求項５９記載のシステム。
62. 前記ソースサーバマシン上で動作するエージェントを更に備え、
    前記エージェントは、
    あるリソースタイプで動作するように設定され、前記リソースタイプに関連付けられた前記命令群の一部を実行するリソースハンドラと、
    前記命令群のうちリソースに特有でない部分を実行するエージェント実行エンジンとを有する、請求項５９記載のシステム。
63. 前記モデリングマネージャは、第２のリソースタイプで動作するように設定された第２のリソースハンドラを受け取り、前記第２のリソースハンドラを前記エージェントに与えるのに適合している、請求項６２記載のシステム。
64. 前記モデリングマネージャは、第２のリソースタイプで動作するように設計された第２のリソースハンドラを受け取るのに適合しており、
    前記第２のリソースハンドラは、特定のオペレーティングシステム上で実行されるように設定されており、
    前記モデリングマネージャは、前記決定のオペレーティングシステム上で前記エージェントが実行される場合に、前記第２のリソースハンドラを前記エージェントに与えるのに適合している、請求項６２記載のシステム。
65. 前記命令群は、前記エージェントに前記リソース状態を読み取らせるとともに前記リソース状態を前記マスターサーバに転送させるための命令を含むものである、請求項６２記載のシステム。
66. 前記命令群は、前記エージェントに前記リソース状態を設定情報に変換させるための命令を含み、
    前記設定情報は、前記ソースサーバマシンのオペレーティングシステムに依存しないものである、請求項６２記載のシステム。
67. 前記モデリングマネージャは、選択された各リソースタイプに対応するリソースハンドラを前記エージェントに与えるのに適合している、請求項６２記載のシステム。
68. 前記エージェントは、
    前記ソースサーバマシン上に展開されているリソースに対応するリソース状態を格納するリソース状態デポと、
    前記リソース状態デポからリソース状態情報を取得するのに適合しているリソース状態デポマネージャと、を更に有する、請求項６２記載のシステム。
69. 通信ネットワークを介して複数のソースサーバマシンに接続されたマスターサーバを備えるアプリケーション管理システムであって、
    前記マスターサーバは、
    前記アプリケーションに含めるために利用可能なリソース群の中から選択された複数のリソースの情報を受け取るアプリケーションビルダーと、
    前記アプリケーションビルダーに接続されており、前記複数のリソースの各々のリソース状態を取得するための命令群を生成するモデル実行エンジンと、を有し、
    前記命令群は、前記複数のリソースの各々のリソースタイプに基づくものであり、
    前記マスターサーバは、前記通信ネットワークを介して、前記複数のリソースのうち少なくとも１つが展開されている前記ソースサーバマシンに前記命令群を与えるのに適合している、システム。
70. 前記各ソースサーバマシン上で動作するエージェントを更に備え、
    前記モデル実行エンジンは、少なくとも１つのターゲットコンピュータ上の前記アプリケーションを管理するためのアプリケーションパッケージを生成するのに適合しており、
    前記アプリケーションパッケージは、前記複数のリソース並びに前記アプリケーションを管理するための命令を含み、
    前記命令は、前記複数のリソースの各々の前記リソース状態に基づくものである、請求項６９記載のシステム。
71. 前記アプリケーションを管理するための前記命令は、
    前記少なくとも１つのターゲットコンピュータ上で前記アプリケーションを展開する命令、前記少なくとも１つのターゲットコンピュータ上で前記アプリケーションを再設定する命令、及び前記少なくとも１つのターゲットコンピュータ上で前記アプリケーションをアップグレードする命令からなる群から選択される命令を含む、請求項６９記載のシステム。
72. 管理対象サーバマシン上のアプリケーションを管理するためのアプリケーション管理システムであって、
    通信ネットワークを介して前記管理対象サーバマシンに接続されたマスターサーバを備え、
    前記マスターサーバは、
    リソース及びそれに対応するリソースタイプを有するアプリケーションの選択結果を受け取り、利用可能な管理手順群をユーザの選択肢として与え、ユーザが選択した管理手順の情報を受け取るアプリケーションマネージャと、
    前記アプリケーションマネージャに接続され、当該選択された前記管理手順を実行するための命令を生成するモデル実行エンジンと、を有し、
    前記命令は、前記リソースのリソース状態に基づくものであり、
    前記マスターサーバは、前記命令を前記通信ネットワークを介して前記管理対象サーバマシンに提供するのに適合している、システム。
73. 前記マスターサーバは、前記リソース状態を格納するリポジトリと、前記リポジトリを制御する状態マネージャとを更に有する、請求項７２記載のシステム。
74. 前記モデル実行エンジンは、更に、前記リソース及び前記リソース状態に基づいて、ターゲットコンピュータ上の前記アプリケーションを管理するための命令群を生成するのに適合している、請求項７２記載のシステム。
75. 前記アプリケーションを管理するための前記命令群は、
    前記ターゲットコンピュータ上で前記アプリケーションを展開する命令、前記ターゲットコンピュータ上で前記アプリケーションを再設定する命令、及び前記ターゲットコンピュータ上で前記アプリケーションをアップグレードする命令からなる群から選択される命令を含む、請求項７４記載のシステム。
76. 前記管理手順群は前記リソースタイプに基づくものである、請求項７２記載のシステム。
77. 前記管理手順群の中の管理手順は、前記リソースのモデルを変更することにより修正可能である、請求項７６記載のシステム。

Images