(57)【要約】【課題】  プラットフォーム依存アプリケーションをグリッド環境に配置する方法を提供する。【解決手段】  本発明の下では、プラットフォーム依存アプリケーションをグリッド環境におけるその特定の「ネイティブな」プラットフォームに配置するのに十分なリソースが存在するか否かが判断される。存在しない場合には、アプリケーションのプラットフォーム依存部分が特定され、アプリケーションは、プラットフォーム依存部分とプラットフォーム非依存部分とに分割される。その後、プラットフォーム依存部分は、その対応するネイティブなプラットフォームに配置され、プラットフォーム非依存部分は、利用可能なリソースに基づいてグリッド環境における別のプラットフォームに配置される。次いで、２つの部分の間の相互接続を自動的に生成することができる。これは、例えば、リモート・メソッド呼び出しファサード・インターフェースを作成すること、リモート・メソッド呼び出し可能ファサード・クラスを作成すること、及び、第１のプラットフォームについてのリモート・メソッド呼び出しサーバを構築することを含むことができる。【選択図】  図２
2009528605.tif 000002
【特許請求の範囲】
【請求項１】
プラットフォーム依存アプリケーションをグリッド環境に配置するための方法であって、
前記プラットフォーム依存アプリケーションのプラットフォーム依存部分を特定するステップと、
前記プラットフォーム依存アプリケーションを前記プラットフォーム依存部分とプラットフォーム非依存部分とに分割するステップと、
前記プラットフォーム依存部分を第１のプラットフォーム上に配置し、前記プラットフォーム非依存部分を前記グリッド環境における第２のプラットフォーム上に配置するステップと、
前記プラットフォーム依存部分と前記プラットフォーム非依存部分の間に相互接続を生成するステップと、
を含む方法。
【請求項２】
前記生成するステップは、前記相互接続を自動的に生成するステップを含む、請求項１に記載の方法。
【請求項３】
前記生成するステップは、
リモート・メソッド呼び出しファサード・インターフェースを作成するステップと、
リモート・メソッド呼び出し可能ファサード・クラスを作成するステップと、
前記第１のプラットフォームについてのリモート・メソッド呼び出しサーバを構築するステップと、
を含む、請求項１に記載の方法。
【請求項４】
前記配置するステップは、グリッド・ジョブ・スケジューラによって実施される、請求項１の記載の方法。
【請求項５】
前記プラットフォーム依存アプリケーションのための利用可能なリソースを判断するステップであって、前記プラットフォーム依存アプリケーションが前記第１のプラットフォーム上で動作するのに十分なリソースが存在しない場合には、前記プラットフォーム依存アプリケーションが分割される、ステップをさらに含む、請求項１に記載の方法。
【請求項６】
前記第１のプラットフォームは、前記プラットフォーム依存部分に対して指定されており、前記第２のプラットフォームは、前記グリッド環境における利用可能なリソースに基づいて選択される、請求項１に記載の方法。
【請求項７】
プラットフォーム依存アプリケーションをグリッド環境に配置するためのシステムであって、
前記プラットフォーム依存アプリケーションを前記グリッド環境の第１のプラットフォーム上で動作させるのに利用可能なリソースを判断するためのシステムと、
前記プラットフォーム依存アプリケーションのプラットフォーム依存部分を特定するためのシステムと、
前記プラットフォーム依存アプリケーションを前記プラットフォーム依存部分とプラットフォーム非依存部分とに分割するためのシステムと、
前記プラットフォーム依存部分を前記第１のプラットフォーム上に配置し、前記プラットフォーム非依存部分を前記グリッド環境における第２のプラットフォーム上に配置するためのシステムと、
前記プラットフォーム依存部分と前記プラットフォーム非依存部分の間に相互接続を生成するためのシステムと、
を備えるシステム。
【請求項８】
前記生成するためのシステムは、前記相互接続を自動的に生成する、請求項７に記載のシステム。
【請求項９】
前記生成するためのシステムは、リモート・メソッド呼び出しファサード・インターフェースを作成し、リモート・メソッド呼び出し可能ファサード・クラスを作成し、前記第１のプラットフォームについてのリモート・メソッド呼び出しサーバを構築する、請求項７に記載のシステム。
【請求項１０】
前記配置するためのシステムは、グリッド・ジョブ・スケジューラを含む、請求項７の記載のシステム。
【請求項１１】
前記判断するためのシステムが、前記プラットフォーム依存アプリケーションが前記第１のプラットフォーム上で動作するのに十分なリソースが存在しないと判断した場合には、前記プラットフォーム依存アプリケーションが分割される、請求項７に記載のシステム。
【請求項１２】
前記第１のプラットフォームは、前記プラットフォーム依存部分に対して指定されており、前記第２のプラットフォームは、前記グリッド環境における利用可能なリソースに基づいて選択される、請求項７に記載のシステム。
【請求項１３】
プラットフォーム依存アプリケーションをグリッド環境に配置するための、コンピュータ使用可能媒体に格納されたプログラムであって、前記コンピュータ使用可能媒体は、
前記プラットフォーム依存アプリケーションを前記グリッド環境の第１のプラットフォーム上で動作させるのに利用可能なリソースを判断するステップと、
前記プラットフォーム依存アプリケーションのプラットフォーム依存部分を特定するステップと、
前記プラットフォーム依存アプリケーションを前記プラットフォーム依存部分とプラットフォーム非依存部分とに分割するステップと、
前記プラットフォーム依存部分を前記第１のプラットフォーム上に配置し、前記プラットフォーム非依存部分を前記グリッド環境における第２のプラットフォーム上に配置するステップと、
前記プラットフォーム依存部分と前記プラットフォーム非依存部分の間に相互接続を生成するステップと、
をコンピュータ・システムに実施させるためのプログラム・コードを含む、プログラム。
【請求項１４】
前記生成するステップは、前記相互接続を自動的に生成するステップを含む、請求項１３に記載のプログラム。
【請求項１５】
前記コンピュータ使用可能媒体は、
リモート・メソッド呼び出しファサード・インターフェースを作成するステップと、
リモート・メソッド呼び出し可能ファサード・クラスを作成するステップと、
前記第１のプラットフォームについてのリモート・メソッド呼び出しサーバを構築するステップと、
をコンピュータ・システムに実施させるためのプログラム・コードを含む、請求項１３に記載のプログラム。
【請求項１６】
前記プラットフォーム依存アプリケーションが前記第１のプラットフォーム上で動作するのに十分なリソースが存在しない場合には、前記プラットフォーム依存アプリケーションが分割される、請求項１３に記載のプログラム。
【請求項１７】
前記第１のプラットフォームは、前記プラットフォーム依存部分に対して指定されており、前記第２のプラットフォームは、前記グリッド環境における利用可能なリソースに基づいて選択される、請求項１３に記載のプログラム。
【請求項１８】
プラットフォーム依存アプリケーションをグリッド環境に配置するための方法であって、
前記プラットフォーム依存アプリケーションのプラットフォーム依存部分を特定し、
前記プラットフォーム依存アプリケーションを前記プラットフォーム依存部分とプラットフォーム非依存部分とに分割し、
前記プラットフォーム依存部分を第１のプラットフォーム上に配置し、前記プラットフォーム非依存部分を前記グリッド環境における第２のプラットフォーム上に配置し、
前記プラットフォーム依存部分と前記プラットフォーム非依存部分の間に相互接続を生成する、
ように作動可能なコンピュータ・インフラストラクチャを準備するステップを含む方法。
【請求項１９】
前記コンピュータ・インフラストラクチャはさらに、前記相互接続を自動的に生成するように作動可能である、請求項１８に記載の方法。
【請求項２０】
前記コンピュータ・インフラストラクチャはさらに、
リモート・メソッド呼び出しファサード・インターフェースを作成し、
リモート・メソッド呼び出し可能ファサード・クラスを作成し、
前記第１のプラットフォームについてのリモート・メソッド呼び出しサーバを構築する、
ように作動可能である、請求項１８に記載の方法。
【請求項２１】
前記コンピュータ・インフラストラクチャは、前記プラットフォーム依存部分及び前記プラットフォーム非依存部分を配置するためのグリッド・ジョブ・スケジューラを含む、請求項１８に記載の方法。
【請求項２２】
前記コンピュータ・インフラストラクチャはさらに、前記プラットフォーム依存アプリケーションのための利用可能なリソースを判断するように作動可能であり、前記プラットフォーム依存アプリケーションが前記第１のプラットフォーム上で動作するのに十分なリソースが存在しない場合には、前記プラットフォーム依存アプリケーションが分割される、請求項１８に記載の方法。
【請求項２３】
前記第１のプラットフォームは、前記プラットフォーム依存部分に対して指定されており、前記第２のプラットフォームは、前記グリッド環境における利用可能なリソースに基づいて選択される、請求項１８に記載の方法。
【発明の詳細な説明】
【技術分野】
【０００１】
一般に、本発明はアプリケーション配置に関する。具体的には、本発明は、プラットフォーム依存アプリケーションをグリッド環境に配置するための方法、システム、及びプログラムに関する。
【背景技術】
【０００２】
本明細書は、幾つかの態様において、本出願人に譲渡され、２００３年１１月２０日付で出願された「COMPUTERIZED SYSTEM,METHOD AND PROGRAM PRODUCT FOR MANAGING ANENTERPRISE STORAGE SYSTEM」という名称の公開された米国特許出願第ＵＳ２００３０００７１８４１９号に関連する。
【０００３】
今日の共有ウェブ・サービス・アーキテクチャは、単一のインフラストラクチャ内において多数のサービスを提供する。共通のニーズを有する企業もまた、インフラストラクチャ及びビジネス・リソースを共有するように歩み寄りつつある。この手法の１つの利点は、関係者の各々が、必要なコスト全体の一部のみを負担するという点である。上記で引用された公開された米国特許出願は、共有インフラストラクチャ内においてストレージ・セルを「グリッド化」することによってストレージ使用を最適化する、ストレージ・グリッド・アーキテクチャを開示する。このタイプの構造は、冗長性を備えるだけでなく、ファイル共有位置の選択に当たり、ストレージ容量、ユーザの要件といった性能ベースのパラメータを考慮に入れる。
【発明の開示】
【発明が解決しようとする課題】
【０００４】
共有インフラストラクチャから生じる１つの問題は、プラットフォーム依存アプリケーションの配置に関するものである。グリッド環境は、一般に、グリッド・コンポーネントにとって最良の負荷バランスを与えるために、アプリケーションがいずれのプラットフォームにおいても動作可能であることを必要とする。したがって、純粋なＪａｖａ（Ｊａｖａ及び全てのＪａｖａベースの商標は、米国、その他の国々、又はその両方におけるＳｕｎ  Ｍｉｃｒｏｓｙｓｔｅｍｓ，Ｉｎｃ．の商標である）アプリケーションは、プラットフォームに依存しないことを公表しているので、グリッド環境において動作させるためにはふさわしい候補である。しかしながら、幾つかの重要なＪａｖａアプリケーションは、プラットフォーム非依存コードを、プラットフォーム依存／特定のネイティブ・コールと混合しなければならない。したがって、このようなアプリケーションは、プラットフォーム依存であると見なされ、そのネイティブ・コールと適合するプラットフォーム上でのみ動作することができる。プラットフォーム依存Ｊａｖａをグリッド環境において動作させることは、それがターゲット・プラットフォームの選択に加える制限のために、さらなる困難となる。
【０００５】
上記の観点から、上述された欠点を克服する必要性が存在する。
【課題を解決するための手段】
【０００６】
一般に、本発明の実施形態は、プラットフォーム依存アプリケーションをグリッド環境に配置するための方法、システム、及びプログラムを提供する。具体的には、最初に、プラットフォーム依存アプリケーションをグリッド環境における特定の「ネイティブな」プラットフォーム上に配置するのに十分なリソースが存在するか否かが判断される。存在しない場合には、アプリケーションのプラットフォーム依存部分が特定され、アプリケーションは、プラットフォーム依存部分とプラットフォーム非依存部分とに分割される。その後、プラットフォーム依存部分は、対応するネイティブなプラットフォーム上に配置され、プラットフォーム非依存部分は、利用可能なリソースに基づいてグリッド環境における別のプラットフォーム上に配置される。次いで、２つの部分の間の相互接続を自動的に生成することができる。これは、例えば、リモート・メソッド呼び出しファサード・インターフェースを作成することと、リモート・メソッド呼び出し可能ファサード・クラスを作成することと、第１のプラットフォームについてのリモート・メソッド呼び出しサーバを構築することとを含むことができる。
【０００７】
本発明の第１の態様は、プラットフォーム依存アプリケーションをグリッド環境に配置するための方法であって、プラットフォーム依存アプリケーションのプラットフォーム依存部分を特定するステップと、プラットフォーム依存アプリケーションをプラットフォーム依存部分とプラットフォーム非依存部分とに分割するステップと、プラットフォーム依存部分を第１のプラットフォーム上に配置し、プラットフォーム非依存部分をグリッド環境における第２のプラットフォーム上に配置するステップと、プラットフォーム依存部分とプラットフォーム非依存部分の間に相互接続を生成するステップと、を含む方法を提供する。
【０００８】
本発明の第２の態様は、プラットフォーム依存アプリケーションをグリッド環境に配置するためのシステムであって、プラットフォーム依存アプリケーションをグリッド環境の第１のプラットフォーム上で動作させるのに利用可能なリソースを判断するためのシステムと、プラットフォーム依存アプリケーションのプラットフォーム依存部分を特定するためのシステムと、プラットフォーム依存アプリケーションをプラットフォーム依存部分とプラットフォーム非依存部分とに分割するためのシステムと、プラットフォーム依存部分を第１のプラットフォーム上に配置し、プラットフォーム非依存部分をグリッド環境における第２のプラットフォーム上に配置するためのシステムと、プラットフォーム依存部分とプラットフォーム非依存部分の間に相互接続を生成するためのシステムと、を備えるシステムを提供する。
【０００９】
本発明の第３の態様は、プラットフォーム依存アプリケーションをグリッド環境に配置するための、コンピュータ使用可能媒体に格納されたプログラムであって、前記コンピュータ使用可能媒体は、プラットフォーム依存アプリケーションをグリッド環境の第１のプラットフォーム上で動作させるのに利用可能なリソースを判断するステップと、プラットフォーム依存アプリケーションのプラットフォーム依存部分を特定するステップと、プラットフォーム依存アプリケーションをプラットフォーム依存部分とプラットフォーム非依存部分とに分割するステップと、プラットフォーム依存部分を第１のプラットフォーム上に配置し、プラットフォーム非依存部分をグリッド環境における第２のプラットフォーム上に配置するステップと、プラットフォーム依存部分とプラットフォーム非依存部分の間に相互接続を生成するステップと、をコンピュータ・システムに実施させるためのプログラム・コードを含むプログラムを提供する。
【００１０】
本発明の第４の態様は、プラットフォーム依存アプリケーションをグリッド環境に配置するための方法であって、プラットフォーム依存アプリケーションのプラットフォーム依存部分を特定し、プラットフォーム依存アプリケーションをプラットフォーム依存部分とプラットフォーム非依存部分とに分割し、プラットフォーム依存部分を第１のプラットフォーム上に配置し、プラットフォーム非依存部分をグリッド環境における第２のプラットフォームに配置し、プラットフォーム依存部分とプラットフォーム非依存部分の間に相互接続を生成する、ように作動可能なコンピュータ・インフラストラクチャを準備するステップを含む方法を提供する。
【００１１】
本発明の第５の態様は、プラットフォーム依存アプリケーションをグリッド環境に配置するための、伝搬信号に組み込まれたコンピュータ・ソフトウェアであって、プラットフォーム依存アプリケーションのプラットフォーム依存部分を特定し、プラットフォーム依存アプリケーションをプラットフォーム依存部分とプラットフォーム非依存部分とに分割し、プラットフォーム依存部分を第１のプラットフォーム上に配置し、プラットフォーム非依存部分をグリッド環境における第２のプラットフォーム上に配置し、プラットフォーム依存部分とプラットフォーム非依存部分の間に相互接続を生成する、ように作動可能なコンピュータ・インフラストラクチャを提供するステップをコンピュータ・システムに実施させるための命令を含むコンピュータ・ソフトウェアを提供する。
【発明を実施するための最良の形態】
【００１２】
本発明の好ましい実施形態は、添付の図面を参照して、単なる例として説明される。
【００１３】
図面は必ずしも縮尺通りには描かれていない。図面は、単なる概要図であり、本発明の実施形態の特定のパラメータを表すことを意図されてはいない。図面においては、同一の番号は同一の要素を表す。
【００１４】
ここで図１を参照すると、グリッド環境が示されている。一般に、グリッド環境１０によって、ユーザ１２のようなユーザは、管理サービス１８によって管理される１つ又は複数のデータ・センタ、即ち「ストレージ・セル」１４Ａ−Ｂにファイルなどを格納できるようになる。この点で、グリッド環境１０は、典型的には、インターネット、ローカル・エリア・ネットワーク（ＬＡＮ）、広域エリア・ネットワーク（ＷＡＮ）、仮想プライベート・ネットワーク（ＶＰＮ）などのようなネットワーク上に実装される。したがって、図１に示される種々のコンポーネント間の通信は、クライアント−サーバ環境又はサーバ−サーバ環境において、直接的な有線接続（例えばシリアルポート）を介して、又は、有線及び／又は無線の伝送方法のいずれかの組み合わせを利用することができるアドレス可能な接続を介して、行うことができる。コンポーネントは、トークン・リング、イーサネット、ＷｉＦｉ、又は他の従来の通信規格といった従来のネットワーク接続を利用することができる。さらに、従来のＴＣＰ／ＩＰソケットベースのプロトコルによって接続することもできる。この場合には、コンポーネントは、インターネット・サービス・プロバイダを利用して接続を確立することができる。図１に示されるアーキテクチャは単なる説明であることが意図されており、当業者には明らかなように他のバリエーションも実装できることを認識されたい。例えば、いかなる数量のデータ・センタ１４Ａ−Ｂを設けてもよい。
【００１５】
いずれにしても、典型的な実施形態においては、ユーザ１２は、自分のコンピュータ・システム１６（例えば、パーソナル・コンピュータ、ワークステーション、ラップトップ、携帯用装置など）上のアプリケーションを介して要求を生成することにより、ファイルを格納することになる。要求が行われると、管理サービス１８が、そのファイルを格納するために最適な又は最も適切なデータ・センタ１４Ａ−Ｂを判断する。この判断は、予め定められた特定の性能パラメータに基づいて行うことができる。例えば、判断は、ユーザ識別情報、ストレージ・コスト、具体的なユーザ要件、所望のセル使用パターン／バランス、セキュリティ要件、ストレージ・セル可用性、冗長性要件、及びネットワーク最適化要件に基づいて行うことができる。したがって、ファイルが、ユーザのグループによってアクセスを要求された場合には、そのファイルは、格納を要求したユーザだけではなく全てのそのようなユーザにとって最も中心となるデータ・センタ１４Ａ−Ｂに格納することができる。さらに、特定のデータ・センタ１４Ａ−Ｂが容量限界に近づいた場合には、ファイルは、データ・センタ１４Ａ−Ｂの負荷が均衡を保てるように、（より遠距離であっても）別のデータ・センタ１４Ａ−Ｂに格納されることがある。
【００１６】
図２に示されるように、既存のグリッド・システムにおいては、ジョブ・スケジューラ２０がアプリケーション・レベルで作動する（即ち、アプリケーション２２が必要なリソースの全てをそのノード上で獲得するのに要する特定のノード上で動作するように、アプリケーション２２をスケジューリングする）。ジョブ・スケジューラ２０は、典型的には、必要なリソースがターゲットとなる「ネイティブな」プラットフォーム上など（例えば、ＷＩＮ３２が動作するノード１、ＬＩＮＵＸが動作するノード２など）で利用可能になるまで、アプリケーション実行を遅らせることになる。
【００１７】
しかしながら、上述されたように、アプリケーション２２のような多くのアプリケーションは、ある程度プラットフォームに依存する。このことは、グリッド環境においてリソースが限られている場合に問題となることがある。このような場合には、アプリケーション２２のプラットフォーム非依存部分をいずれかの利用可能なプラットフォーム上で動作させ、プラットフォーム依存部分（ネイティブな部分）を必要なプラットフォーム上で動作させることができるようにアプリケーション２２を適合させて、そのプラットフォーム上で消費するリソースを最小限にすることができる。
【００１８】
図３を参照すると、ネイティブなプラットフォーム３０上におけるプラットフォーム依存アプリケーション２２の配置が示される。特に、図３は、プラットフォーム３０上におけるＪａｖａアプリケーション２２全体の配置を示す。図３には、また、Ｊａｖａ仮想マシン（ＪＶＭ）３２と、ネイティブなライブラリ３４Ａ−Ｂと、ファサード３６と、ＪＮＩ層３８とが示される。上述されたように、アプリケーション２２全体をそのネイティブなプラットフォーム３０上に配置するためのリソースが十分に存在しないことがある。
【００１９】
この問題に対処するために、図４による技術を実装することができる。ジョブ・スケジューラ２０（図２）は、最初に、アプリケーション２２をそのネイティブなプラットフォーム３０上に配置するのに十分なリソースが存在するか否かを判断する。この例示的な実施例においては、十分なリソースが存在しないと仮定すると、アプリケーション２２のプラットフォーム依存部分２２Ａが特定されることになる。このような特定は、アプリケーション２２についてのメタデータを調べることによって行うことができる。いずれにしても、アプリケーション２２は、プラットフォーム依存部分２２Ａと、プラットフォーム非依存部分２２Ｂとに分割されることになる。これは、どの部分が特定のプラットフォームに依存するのか（又は依存しないのか）を判断するための基本コードの分析に基づいて、行うことができる。分割が行われると、グリッド・ジョブ・スケジューラ２０は、プラットフォーム依存部分２２Ａをネイティブなプラットフォーム３０上に配置し、プラットフォーム非依存部分２２Ｂを、利用可能なリソースに基づいてグリッド環境における他のいずれかのプラットフォーム４０上に配置する。具体的には、グリッド・ジョブ・スケジューラ２０は、他のプラットフォームについてリソースの利用可能性を分析し、それに基づいてプラットフォーム非依存部分２２Ｂを配置する。
【００２０】
さらに、プラットフォーム依存部分２２Ａとプラットフォーム非依存部分２２Ｂの間の相互接続を自動的に生成することができる。これは、以下のステップを含むものとすることができる。即ち、（１）リモート・メソッド呼び出しファサード・インターフェース４２を作成する。ネイティブなメソッドにアクセスするのに用いられることがあった全てのファサード・メソッドは、リモートＪａｖａインターフェースのメソッドであることを必要とする。この要件は、メソッドにリモートにアクセスする必要性から生じる。リモートＪａｖａインターフェースは、標準的なｊａｖａ．ｒｍｉ．リモート・インターフェースを拡張する必要がある。アプリケーションは、これらのリモートＪａｖａインターフェースを用いて、対応するネイティブなメソッドにアクセスする。（２）ＲＭＩ可能ファサード・クラスを作成する。全ての既存の専用ファサード・クラスは、ＲＭＩ可能にされ、対応するリモートＪａｖａインターフェースを実装することが必要である。全てのファサード・メソッドが専用クラスに含まれていない場合には、新規のＲＭＩ可能クラスを作成して、対応するリモート・ファサードＪａｖａインターフェースを実装する必要がある。（３）Ｊａｖａ  ＲＭＩサーバ４４を構築する。ファサード・クラスのインスタンスにリモート・アクセスするために、Ｊａｖａ  ＲＭＩサーバ４４は、ネイティブなプラットフォーム上に構築及び配置される必要がある。Ｊａｖａ  ＲＭＩサーバ４４は、要求されると、リモート・ファサード・クラスのインスタンスを作成し、これらをローカルなＲＭＩレジストリに登録し、呼び出し者にリモートＪａｖａインターフェースを戻すことになる。
【００２１】
以上のように、Ｊａｖａアプリケーション・コードは、プラットフォーム依存コードをアプリケーションの残りの部分から分離してリモートにアクセスできるようにすることによって、プラットフォームに依存しなくなる。ネイティブなオブジェクト・ライブラリは、そのネイティブなプラットフォームにおいて動作しており、リモート・アクセスＡＰＩを介してアクセスされる。さらに示されるように、本発明の典型的な実施形態はリモート・メソッド呼び出し（ＲＭＩ）を利用するものであるが、他の同等の技術も利用できることを理解されたい。
【００２２】
ここで図５を参照すると、本発明の好ましい実施形態のコンピュータ実装形態１００のより詳細な図が示される。図示されるように、実装形態１００は、コンピュータ・インフラストラクチャ１０２内に配置されたコンピュータ・システム１０４を含む。これは、特に、ネットワーク環境（例えば、インターネット、広域エリア・ネットワーク（ＷＡＮ）、ローカル・エリア・ネットワーク（ＬＡＮ）、仮想プライベート・ネットワーク（ＶＰＮ）など）内に、又は独立型のコンピュータ・システム上に、本発明の実施形態を実装できることを示すように意図されている。前者の場合においては、様々なタイプの通信リンクのいずれかの組み合わせを介して、ネットワーク全体にわたる通信を行うことができる。例えば、通信リンクは、有線及び／又は無線の伝送方法のいずれかの組み合わせを利用することができるアドレス可能な接続を含むことができる。インターネットを介した通信が行われる場合においては、従来のＴＣＰ／ＩＰソケットベースのプロトコルによって接続を行うことができ、インターネット・サービス・プロバイダを利用してインターネットへの接続を確立することができる。さらにまた、コンピュータ・インフラストラクチャ１０２は、アプリケーションをグリッド環境に配置することを提供するサービス・プロバイダによって、実装形態１００のコンポーネントの幾つか又は全てを配置し、管理し、サービス提供することなどが可能であることを示すように意図される。
【００２３】
図示されるように、コンピュータ・システム１０４は、処理ユニット１０６と、メモリ１０８と、バス１１０と、入出力（Ｉ／Ｏ）インターフェース１１２とを含む。さらに、コンピュータ・システム１０４は、外部Ｉ／Ｏ装置／リソース１１４及びストレージ・システム１１６と通信するように示される。一般に、処理ユニット１０６は、メモリ１０８及び／又はストレージ・システム１１６に格納された、アプリケーション配置システム１２０などのコンピュータ・プログラム・コードを実行する。コンピュータ・プログラム・コードの実行の際に、処理ユニット１０６は、メモリ１０８、ストレージ・システム１１６、及び／又はＩ／Ｏインターフェース１１２との間でデータの読み出し及び／又は書き込みを行うことができる。バス１１０は、コンピュータ・システム１０４の各々のコンポーネントの間の通信リンクとなる。外部装置１１４は、ユーザがコンピュータ・システム１０４と対話できるようにするいずれかの装置（例えば、キーボード、ポインティング・デバイス、ディスプレイなど）、及び／又は、コンピュータ・システム１０４が１つ又は複数の他のコンピュータ装置と通信できるようにするいずれかの装置（例えば、ネットワーク・カード、モデムなど）を含むことができる。
【００２４】
コンピュータ・インフラストラクチャ１０２は、本発明の実施形態を実装するための様々なタイプのコンピュータ・インフラストラクチャの例にすぎない。例えば、１つの実施形態においては、コンピュータ・インフラストラクチャ１０２は、本発明の実施形態における種々の処理ステップを実施するためにネットワーク上で通信する２つ以上のコンピュータ装置（例えば、サーバ・クラスタ）を備える。さらに、コンピュータ・システム１０４は、ハードウェアの数多くの組み合わせを含むことがある種々の可能なコンピュータ・システムを単に代表するものである。この点で、他の実施形態においては、コンピュータ・システム１０４は、特定の機能を実施するためのハードウェア及び／又はコンピュータ・プログラム・コードを含むいずれかの専用コンピュータ製品、専用及び汎用のハードウェア／ソフトウェアの組み合わせを含むいずれかのコンピュータ製品などを含むものとすることができる。いずれの場合にも、プログラム・コードは標準的なプログラミング技術を用いて作成し、ハードウェアはエンジニアリング技術を用いて作成することができる。さらに、処理ユニット１０６は、単一の処理ユニットを含むものとすることも、例えばクライアントとサーバといった１つ又は複数の位置の１つ又は複数の処理ユニットにわたって分散させることもできる。同様に、メモリ１０８及び／又はストレージ・システム１１６は、１つ又は複数の物理位置に存在する様々なタイプのデータ・ストレージ及び／又は伝送媒体のいずれかの組み合わせを含むものとすることができる。さらに、Ｉ／Ｏインターフェース１１２は、１つ又は複数の外部装置１１４と情報を交換するためのいずれかのシステムを含むものとすることができる。さらにまた、図５に示されない１つ又は複数の付加的なコンポーネント（例えば、システム・ソフトウェア、数値演算コプロセッシング・ユニットなど）がコンピュータ・システム１０４に含まれる場合があることが分かる。しかしながら、コンピュータ・システム１０４が携帯用装置などを含む場合には、１つ又は複数の外部装置１１４（例えば、ディスプレイ）及び／又は１つ又は複数のストレージ・システム１１６は、図示されるように外部に存在するのではなく、コンピュータ・システム１０４の内部に含ませることができることが理解される。
【００２５】
ストレージ・システム１１６は、本発明の実施形態における情報、アプリケーション、メタデータなどのためのストレージとなる能力を有するいずれかのタイプのシステム（例えば、データベース）とすることができる。この点で、ストレージ・システム１１６は、磁気ディスク・ドライブ又は光ディスク・ドライブといった１つ又は複数のストレージ装置を含むものとすることができる。別の実施形態においては、ストレージ・システム１１６は、例えばローカル・エリア・ネットワーク（ＬＡＮ）、広域エリア・ネットワーク（ＷＡＮ）、又はストレージエリア・ネットワーク（ＳＡＮ）（図示せず）にわたって分散されたデータを含む。図示されないが、キャッシュ・メモリ、通信システム、システム・ソフトウェアなどといった付加的なコンポーネントを、コンピュータ・システム１０４に組み込んでもよい。
【００２６】
コンピュータ・システム１０４のメモリ１０８内に示されるのは、本発明の実施形態の機能を提供するソフトウェア・プログラムであるアプリケーション配置システム１２０であり、これは、リソース判断システム１２２と、部分特定システム１２４と、アプリケーション分割システム１２６と、部分配置システム１２８と、相互接続システム１３０とを含む。これらのシステムは、上記で概略が示された機能を実施する。具体的には、リソース判断システム１２２は、アプリケーション２２をそのネイティブなプラットフォーム上に配置するのに十分なリソースが存在するか否かを判断する。存在しない場合には、部分特定システム１２４が、アプリケーション２２のプラットフォーム依存部分２２Ａを特定することになる。その後、アプリケーション分割システム１２６が、アプリケーション２２をプラットフォーム依存部分２２Ａとプラットフォーム非依存部分２２Ｂとに分割する。このように分割されると、部分配置システム１２８が、プラットフォーム依存部分２２Ａをその対応するネイティブなプラットフォーム３０上に配置し、プラットフォーム非依存部分を、リソースの利用可能性に基づいてグリッド環境１４０における別のプラットフォーム４０上に配置する。部分２２Ａ−Ｂが配置されると、相互接続システム１３０が、それらの間の相互接続を自動的に生成する。上記で示されたように、これは、（１）リモート・ファサード・インターフェースを作成し、（２）ＲＭＩ可能ファサード・クラスを作成し、３）Ｊａｖａ  ＲＭＩサーバを構築することを含むことができる。アプリケーション配置システム１２０のシステムのうちの幾つか又は全ては、ジョブ・スケジューラ２０（図２）として実装できることを理解されたい。
【００２７】
ここでは、アプリケーションをグリッド環境に配置する方法及びシステムとして示され、説明されたが、本発明の実施形態は、さらに代替技術を提供できることが分かる。例えば、１つの実施形態は、コンピュータ・インフラストラクチャがアプリケーションをグリッド環境に配置できるようにするコンピュータ・プログラム・コードを含むコンピュータ可読／使用可能媒体を提供する。この点で、コンピュータ可読／使用可能媒体は、本発明の実施形態の様々な処理ステップの各々を実装するプログラム・コードを含む。コンピュータ可読媒体又はコンピュータ使用可能媒体という用語は、プログラム・コードのいずれかのタイプの物理的実施形態のうちの１つ又は複数を含むことが分かる。特に、コンピュータ可読／使用可能媒体は、１つ又は複数の携帯型ストレージ製品（例えば、コンパクト・ディスク、磁気ディスク、テープなど）に、メモリ１０８（図５）及び／又はストレージ・システム１１６（図５）といったコンピュータ装置の１つ又は複数のデータ・ストレージ部分（例えば、固定ディスク、読取り専用メモリ、ランダム・アクセス・メモリ、キャッシュ・メモリなど）に、及び／又は、（例えばプログラム・コードの有線／無線による電気的な配信の際に）ネットワーク上を移動するデータ信号（例えば伝搬信号）として、具体化されたプログラム・コードを含むものとすることができる。
【００２８】
さらに別の実施形態においては、アプリケーションをグリッド環境に配置するための、コンピュータに実装される方法が提供される。この場合においては、コンピュータ・インフラストラクチャ１０２（図５）のようなコンピュータ・インフラストラクチャを準備し、処理ステップを実施するための１つ又は複数のシステムを入手（例えば、作成するか、購入するか、使用するか、修正するなど）してコンピュータ・インフラストラクチャに配置することができる。この点で、システムの配置は、（１）コンピュータ可読媒体からコンピュータ・システム（図５）などのコンピュータ装置にプログラム・コードをインストールすること、（２）１つ又は複数のコンピュータ装置をコンピュータ・インフラストラクチャに追加すること、及び、（３）コンピュータ・インフラストラクチャが処理ステップを実施できるように、コンピュータ・インフラストラクチャの１つ又は複数の既存システムを組み込む及び／又は修正すること、のうちの１つ又は複数を含むことができる。
【００２９】
本明細書で用いられるときには、「プログラム・コード」及び「コンピュータ・プログラム・コード」という用語は同義であり、直接的に、又は、
（ａ）別の言語、コード、若しくは表記への変換、及び／又は、
（ｂ）異なる資源形態での複製、
のいずれか若しくはその両方の後で、情報処理能力を有するコンピュータ装置に特定の機能を実施させるように意図された命令セットの、いずれかの言語、コード、又は表記によるいずれかの表現を意味する。この点で、プログラム・コードは、アプリケーション／ソフトウェア・プログラム、コンポーネント・ソフトウェア／機能のライブラリ、オペレーション・システム、特定のコンピュータ装置及び／又はＩ／Ｏ装置についての基本Ｉ／Ｏシステム／ドライバなどのうちの１つ又は複数として具体化することができる。
【００３０】
上述された本発明の様々な態様の説明は、例示及び説明の目的で提示されたものである。網羅的であることも、本発明を開示された正確な形態に限定することも意図されておらず、多くの修正及び変形が可能であることが明らかである。当業者には明らかであろうそのような修正及び変形は、特許請求の範囲によって定められる本発明の範囲内に含まれるように意図されている。
【図面の簡単な説明】
【００３１】
【図１】関連技術によるグリッド環境を示す。
【図２】本発明の好ましい実施形態による、アプリケーションのための利用可能なリソースを判断するジョブ・スケジューラを示す。
【図３】本発明の好ましい実施形態による、プラットフォーム依存アプリケーションの概略図を示す。
【図４】本発明の好ましい実施形態に従って適合された後の図３のプラットフォーム依存アプリケーションの概略図を示す。
【図５】本発明の好ましい実施形態による、より具体的なコンピュータ実装形態を示す。
【図１】
2009528605.tif 000003
【図２】
2009528605.tif 000004
【図３】
2009528605.tif 000005
【図４】
2009528605.tif 000006
【図５】
2009528605.tif 000007
【国際調査報告】
2009528605.tif 000008
2009528605.tif 000009
2009528605.tif 000010