(57)【特許請求の範囲】
【請求項１】
アプリケーションのインストールを求める要求を受信するステップと、
前記アプリケーションによって求められる共有リソースを定義するデータにアクセスするステップと、
既存のランタイム・インスタンスに既にインストールされている共有リソースを定義するデータにアクセスするステップと、
前記アプリケーションによって求められる前記共有リソースに共通の最大多数のインストール済み共有リソースを備えた既存のランタイム・インスタンスを選択するステップと、
前記選択されたランタイム・インスタンスに前記アプリケーションをインストールするステップと
を含む、アプリケーションをランタイム・インスタンスにインストールする方法。
【請求項２】
既存のランタイム・インスタンスにインストールされた各共有リソースの識別子を格納するテーブルを維持することをさらに含み、既存のランタイム・インスタンスに既にインストールされている共有リソースを定義するデータにアクセスする前記ステップが、前記テーブルにアクセスすることを含む、請求項１に記載の方法。
【請求項３】
前記選択されたランタイム・インスタンスに前記アプリケーションをインストールする前記ステップに続いて、前記選択されたランタイム・インスタンスに前記アプリケーションをインストールする間にインストールされた各新規共有リソースの識別子で前記テーブルを更新することをさらに含む、請求項２に記載の方法。
【請求項４】
既存のランタイム・インスタンスで利用可能な空き容量を判定することをさらに含み、前記アプリケーションによって求められる前記共有リソースに共通の最大多数のインストール済み共有リソースを備えた既存のランタイム・インスタンスを選択する前記ステップが、前記アプリケーションをインストールするのに十分な空き容量を備えた既存のランタイム・インスタンスのみを選択することを含む、請求項１、２、または３に記載の方法。
【請求項５】
前記選択されたランタイム・インスタンスに前記アプリケーションをインストールする前記ステップが、前記アプリケーションから、前記選択されたランタイム・インスタンスに既に存在する共有リソースを取り除くことと、前記アプリケーションの残りのコンポーネントを、前記選択されたランタイム・インスタンスにインストールすることとを含む、請求項１ないし４のいずれかに記載の方法。
【請求項６】
それぞれが１つまたは複数のランタイム・インスタンスを実行するように構成された複数のサーバと、
前記サーバに接続され、
アプリケーションのインストールを求める要求を受信し、
前記アプリケーションによって求められる共有リソースを定義するデータにアクセスし、
既存のランタイム・インスタンスに既にインストールされている共有リソースを定義するデータにアクセスし、
前記アプリケーションによって求められる前記共有リソースに共通の最大多数のインストール済み共有リソースを備えた既存のランタイム・インスタンスを選択し、
前記選択されたランタイム・インスタンスに前記アプリケーションをインストールするように構成された管理コンポーネント（２８）と
を備えた、アプリケーションをランタイム・インスタンスにインストールするためのシステム。
【請求項７】
前記管理コンポーネントが、既存のランタイム・インスタンスにインストールされた各共有リソースの識別子を格納するテーブルを維持するようにさらに構成され、前記管理コンポーネントが、既存のランタイム・インスタンスに既にインストールされている共有リソースを定義するデータにアクセスするとき、前記テーブルにアクセスするように構成された、請求項６に記載のシステム。
【請求項８】
前記管理コンポーネントが、前記選択されたランタイム・インスタンスに前記アプリケーションをインストールすることに続いて、前記選択されたランタイム・インスタンスに前記アプリケーションをインストールする間にインストールされた各新規共有リソースの識別子で前記テーブルを更新するようにさらに構成された、請求項７に記載のシステム。
【請求項９】
前記管理コンポーネントが、既存のランタイム・インスタンスで利用可能な空き容量を判定するように、また前記アプリケーションによって求められる前記共有リソースに共通の最大多数のインストール済み共有リソースを備えた既存のランタイム・インスタンスを選択するとき、前記アプリケーションをインストールするのに十分な空き容量を備えた既存のランタイム・インスタンスのみを選択するようにさらに構成された、請求項６、７、または８に記載のシステム。
【請求項１０】
前記管理コンポーネントが、前記選択されたランタイム・インスタンスに前記アプリケーションをインストールするとき、前記アプリケーションから、前記選択されたランタイム・インスタンスに既に存在する共有リソースを取り除き、また前記アプリケーションの残りのコンポーネントを、前記選択されたランタイム・インスタンスにインストールするように構成された、請求項６ないし９のいずれか一項に記載のシステム。
【請求項１１】
処理回路によって読むことができかつ請求項１ないし５のいずれかに記載の方法を実行するために前記処理回路によって実行される命令を含む、
アプリケーションをランタイム・インスタンスにインストールするためのコンピュータ・プログラム。
【請求項１２】
プログラムがコンピュータ上で実行されるとき請求項１ないし５のいずれかの方法を実行するためのソフトウェア・コード部分を含む、デジタル・コンピュータの内部メモリにロードできるコンピュータ・プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、アプリケーションをランタイム・インスタンスにインストールする方法およびシステムに関する。
【背景技術】
【０００２】
「ＯＳＧｉ」は、Ｊａｖａ（Ｒ）のモジュール・テクノロジである。ＯＳＧｉ内でバンドルは、モジュールの構成単位である。バンドルの一例は、バンドルの識別情報および外的情報を記述する付加的なバンドル・メタデータを備えたバイナリＪａｖａ（Ｒ）  ｊａｒファイルの未加工アーティファクト（raw artefact）である。本明細書では、バンドルは「バンドル・リソース」と呼ばれ、未加工アーティファクトは「アーティファクト・リソース」と呼ばれ、またバンドルのメタデータは「メタデータ・リソース」と呼ばれる。リソースは、オブジェクトとしても知られている。
【０００３】
Ｊａｖａ（Ｒ）およびすべてのＪａｖａ（Ｒ）ベースの商標およびロゴは、Ｏｒａｃｌｅまたはその関連会社あるいはその両方の商標または登録商標である。
【０００４】
ソフトウェア・アプリケーションが個々のモジュールからなることは一般的である。Ｊａｖａ（Ｒ）  Ｅｎｔｅｒｐｒｉｓｅ  Ｅｄｉｔｉｏｎ（ＥＥ）のＥＡＲファイルやＯＳＧｉアプリケーションなどの大抵のアプリケーション・モジュールは、再利用可能な機能を提供する１つまたは複数のユーティリティ・モジュールを活用するものである。通常、ユーティリティ・モジュールは、アプリケーション・モジュールの一部としてパッケージ化され、アプリケーション・モジュールの一部でもあるメタデータを使用してアプリケーション・モジュールによって参照される。アプリケーション・フレームワークへのアプリケーション・モジュールのインストールは、通常、アプリケーション・モジュールとユーティリティ・モジュールの両方をハード・ディスクの単一のディレクトリにコピーすることを必要とする。したがって、ユーティリティ・モジュールの共通セットを利用するいくつかの異なるアプリケーション・モジュールがインストールされる場合、同じユーティリティ・モジュールの複数のコピーがハード・ディスクに格納されることになり、アプリケーション・モジュールが同じアプリケーション・フレームワーク・ランタイム・インスタンスで実行されている場合、同様に、同じユーティリティ・モジュールのいくつかのバージョンがメモリにロードされることがある。これは、ディスクおよびメモリの使用に関して、またユーティリティ・モジュールのメモリへのロードに要する時間に関して、明らかな無駄である。
【０００５】
この問題に対する既知の解決策は、共有ライブラリ（Ｊａｖａ（Ｒ）  Ｐｌａｔｆｏｒｍ，  Ｅｎｔｅｒｐｒｉｓｅ  ＥｄｉｔｉｏｎすなわちＪａｖａ（Ｒ）  ＥＥ（ＪＥＥ）アプリケーション向け）、または共通のバンドル・リポジトリでの共有バンドル（ＯＳＧｉアプリケーション向け）として知られている、共有リソースの概念を活用することである。いくつかのアプリケーション・モジュールに共通である可能性が高いユーティリティ・モジュールは、アプリケーション・モジュールから抜き出され、共有ライブラリまたは共通のバンドルとしてアプリケーション・フレームワーク・ランタイム・インスタンスにインストールされる。アプリケーション・モジュールのインストール時に、アプリケーション・モジュールは、必要な共有ライブラリまたは共有バンドルにリンク付けされる。このプロセスの結果として、複数のアプリケーション・モジュールが、ディスク上にある共有リソースのコピーが１つだけであるにしても、同じ共有リソースを利用することができる。アプリケーション・フレームワークに応じて、１つのバージョンの共有リソースのみがメモリにロードされる場合もある。
【０００６】
共有リソースの手法は、アプリケーション・モジュール開発者およびアプリケーション・フレームワーク管理者が、アプリケーション・インストールの前に、どのユーティリティ・モジュールを共通のリソースとして使用可能にすべきかを決定するために協力することができるときに、うまく機能する。しかし、アプリケーション・モジュールをＰａａＳ（Platform as a Service）型クラウドを使用して提供されるアプリケーション・フレームワークに展開しようとする場合、共有可能なリソースをあらかじめ計画することは不可能である。
【発明の概要】
【発明が解決しようとする課題】
【０００７】
したがって、本技術分野において、上述の問題に対処する必要がある。
【課題を解決するための手段】
【０００８】
本発明の第１の態様によれば、アプリケーションをランタイム・インスタンスにインストールする方法が提供され、その方法は、アプリケーションのインストールを求める要求を受信するステップと、アプリケーションによって求められる共有リソースを定義するデータにアクセスするステップと、既存のランタイム・インスタンスに既にインストールされている共有リソースを定義するデータにアクセスするステップと、アプリケーションによって求められる共有リソースに共通の最大多数のインストール済み共有リソースを備えた既存のランタイム・インスタンスを選択するステップと、選択されたランタイム・インスタンスにアプリケーションをインストールするステップとを含む。
【０００９】
本発明の第２の態様によれば、アプリケーションをランタイム・インスタンスにインストールするためのシステムが提供され、そのシステムは、それぞれが１つまたは複数のランタイム・インスタンスを実行するように構成された複数のサーバと、サーバに接続され、アプリケーションのインストールを求める要求を受信し、アプリケーションによって求められる共有リソースを定義するデータにアクセスし、既存のランタイム・インスタンスに既にインストールされている共有リソースを定義するデータにアクセスし、アプリケーションによって求められる共有リソースに共通の最大多数のインストール済み共有リソースを備えた既存のランタイム・インスタンスを選択し、選択されたランタイム・インスタンスにアプリケーションをインストールするように構成された管理コンポーネントを備える。
【００１０】
本発明の第３の態様によれば、アプリケーションをランタイム・インスタンスにインストールするための、コンピュータ可読媒体上のコンピュータ・プログラム製品が提供され、その製品は、アプリケーションのインストールを求める要求を受信し、アプリケーションによって求められる共有リソースを定義するデータにアクセスし、既存のランタイム・インスタンスに既にインストールされている共有リソースを定義するデータにアクセスし、アプリケーションによって求められる共有リソースに共通の最大多数のインストール済み共有リソースを備えた既存のランタイム・インスタンスを選択し、選択されたランタイム・インスタンスにアプリケーションをインストールする命令を含む。さらに別の態様から見ると、本発明は、アプリケーションをランタイム・インスタンスにインストールするためのコンピュータ・プログラム製品を提供し、そのコンピュータ・プログラム製品は、処理回路によって読むことができかつ本発明のステップを実行するための方法を実行するために処理回路によって実行される命令を格納するコンピュータ可読記憶媒体を含む。
【００１１】
さらに別の態様によれば、本発明は、コンピュータ・プログラムがコンピュータ上で実行されるとき本発明のステップを実行するためのソフトウェア・コード部分を含む、コンピュータ可読媒体に格納されかつデジタル・コンピュータの内部メモリにロードできるコンピュータ・プログラムを提供する。
【００１２】
本発明の結果、アプリケーション・モジュールを、使用するユーティリティ・モジュールに基づいて、自動的にＰａａＳ型クラウド内の個々のマシンおよびアプリケーション・フレームワーク・ランタイム・インスタンスに向けることができる方式を提供可能である。この手法は、各アプリケーション・モジュールを、そのアプリケーション・モジュールごとの任意のユーティリティ・モジュールのコピーとともにインストールする場合と比較して、ディスク領域、メモリ、および中央処理装置（ＣＰＵ）サイクルを節約する。この節約は、クラウド内の個々のマシンとクラウド全体の両方の利益となる。これは、例えば、多くの異なるアプリケーションによって共有できる共通のロギング・ユーティリティなどの、一般に再利用されているサード・パーティ・モジュールの場合、特に有益である。
【００１３】
アプリケーション・モジュールは、ＰａａＳ型クラウドに展開されるとき、含まれるユーティリティ・モジュールを判定するためにクラウド管理ソフトウェアによって分析される。次いで、クラウド内の既存のアプリケーション・フレームワーク・ランタイム・インスタンスが、いずれかが、例えば、共有ライブラリやＯＳＧｉバンドル・リポジトリ内のバンドルとして既にインストールされている適合するユーティリティ・モジュールを備えていないかを把握するためにチェックされる。アプリケーション・モジュールは、アプリケーション・モジュールのユーティリティ・モジュールに適合する共有リソースが既にインストールされている既存のアプリケーション・フレームワーク・ランタイム・インスタンスに優先的にインストールされる。
【００１４】
インストール時に、新規アプリケーション・モジュールのすべてのユーティリティ・モジュールは、新規共有リソースに変換されるか、既存の共有リソースにリンク付けされる。アプリケーションは、要件のできるだけ多くを提供するクラウド内のサーバに向けられる。値によるユーティリティを含むアプリケーションから、参照によるユーティリティを含むアプリケーションにアプリケーションを変換することにより、より柔軟な展開が可能になる。この手法は、アプリケーション・モジュールが自動的に展開され、それによって既存のランタイム機能およびクラウド構成を最大限に活用できることを意味する。特に、ユーティリティ・モジュールの複数のコピーを単一の共有リソースに置き換えることができるので、ディスク領域およびプロセス・メモリが減少する。
【００１５】
好ましくは、方法は、既存のランタイム・インスタンスにインストールされた各共有リソースの識別子を格納するテーブルを維持することをさらに含み、既存のランタイム・インスタンスに既にインストールされている共有リソースを定義するデータにアクセスするステップが、テーブルにアクセスすることを含む。コンピューティング・ネットワーク内の管理コンポーネントは、使用されている共有リソースのすべてを既存のランタイム・インスタンスのすべてにわたって記録する参照テーブルを維持することができる。これは、新規アプリケーションをクラウド内にインストールする必要があるときに、クラウド・コンピューティング環境に現在展開されている共有リソースを判定する簡単な方法を提供する。どの共有リソースが、どの特定のランタイム・インスタンスに、現在インストールされているかを把握するために、テーブルにアクセスすることができる。
【００１６】
先の段落で要約されているようなテーブルの使用に続いて、方法は、有利なことに、選択されたランタイム・インスタンスにアプリケーションをインストールするステップに続いて、選択されたランタイム・インスタンスにアプリケーションをインストールする間にインストールされた各新規共有リソースの識別子でテーブルを更新することをさらに含むことができる。アプリケーションのインストールを求める要求が出され、最良のランタイム・インスタンスがそのアプリケーションのために選択されるたびに、テーブルは、選択されたランタイム・インスタンスでインストールの結果として使用可能になる任意の新規共有リソースを反映するために更新することができる。このことは、この先のアプリケーション・インストールが、更新されたテーブルを反映するように構成されることにつながり得る、共有リソースのテーブルの持続的な更新を実現する。
【００１７】
理想的には、方法は、既存のランタイム・インスタンスで利用可能な空き容量を判定することをさらに含み、アプリケーションによって求められる共有リソースに共通の最大多数のインストール済み共有リソースを備えた既存のランタイム・インスタンスを選択するステップが、アプリケーションをインストールするのに十分な空き容量を備えた既存のランタイム・インスタンスのみを選択することを含む。新規アプリケーションがインストールされるのに使用するランタイム・インスタンスの選択は、使用可能なランタイム・インスタンスのそれぞれに使用可能な空きメモリの量を考慮することもできる。適当なランタイム・インスタンスの選択は、この場合、十分な空きメモリを備えたランタイム・インスタンスのみに限定される場合がある。
【００１８】
有利なことに、選択されたランタイム・インスタンスにアプリケーションをインストールするステップは、アプリケーションから、選択されたランタイム・インスタンスに既に存在する共有リソースを取り除くことと、アプリケーションの残りのコンポーネントを、選択されたランタイム・インスタンスにインストールすることとを含む。アプリケーションのインストールは、選択されたランタイム・インスタンスに既に存在する共有リソースの他に必要なモジュールのみをインストールすることに限定することができる。これは、アプリケーションをインストールする最も効率的な方法であり、大抵のプロセッサおよび帯域幅の使用を節約することになる。
【００１９】
次に、本発明の好ましい実施形態を、単に例示を目的として、以下の図面を参照しながら説明する。
【図面の簡単な説明】
【００２０】
【図１】本発明の好ましい実施形態による、ランタイム・インスタンスの概略図である。
【図２】本発明の好ましい実施形態による、新規アプリケーションのインストールに続く、ランタイム・インスタンスのさらなる概略図である。
【図３】本発明の好ましい実施形態による、アプリケーションおよびクラウド・コンピューティング環境の概略図である。
【図４】本発明の好ましい実施形態による、共有リソースの参照テーブルの図である。
【図５】本発明の好ましい実施形態による、クラウド・コンピューティング環境のさらなる概略図である。
【図６】本発明の好ましい実施形態による、クラウド・コンピューティング環境のさらなる概略図である。
【図７】本発明の好ましい実施形態による、クラウド・コンピューティング環境のさらなる概略図である。
【図８】本発明の好ましい実施形態による、アプリケーションをインストールする方法の流れ図である。
【発明を実施するための形態】
【００２１】
図１は、２つの特定のロケーション１２および１４を含むランタイム・インスタンス１０の例を示す。アプリケーション固有モジュールがロケーション１２にインストールされ、共有リソースがロケーション１４にインストールされている。（ＡＭ１およびＡＭ２のラベルの付いた）２つのアプリケーション１６が、ロケーション１２にインストールされている状態が示されている。各アプリケーション１６は、１つまたは複数のアプリケーション固有モジュール１８および１つまたは複数の共有リソース２０を含む。アプリケーションＡＭ１は、アプリケーション固有モジュールＭ１ならびに共有リソースＲ１およびＲ２を含む。同様に、アプリケーションＡＭ２は、アプリケーション固有モジュールＭ２ならびに同じ共有リソースＲ１およびＲ２を含む。
【００２２】
アプリケーションＡＭ１をランタイム・インスタンス１０にインストールしたとき、アプリケーション固有モジュールＭ１がロケーション１２にインストールされ、共有リソースＲ１およびＲ２がロケーション１４にインストールされた。アプリケーションＡＭ１内の実際の共有リソースは、共有リソースＲ１およびＲ２へのリンクに置き換えられた。次に、アプリケーションＡＭ２をランタイム・インスタンス１０にインストールしたとき、アプリケーション固有モジュールＭ２だけがロケーション１２にインストールされ、アプリケーションＡＭ２内の共有リソースＲ１およびＲ２は、既にロケーション１４に存在するのでインストールされなかった。アプリケーションＡＭ２は、前にインストールされた共有リソース２０へのリンクを伴ってインストールされた。
【００２３】
同様に、新規アプリケーション１６’をインストールしようとするとき、その新規アプリケーション１６’内のモジュールは、ランタイム・インスタンス１０のロケーション１４内に既にインストールされている共有リソース２０と比較してどうであるかを把握するために検査される。この場合、新規アプリケーションＡＭ３は、アプリケーション固有モジュールＭ３および共有リソースＲ２（標準ライブラリなど）を含む。この新規アプリケーション１６’をランタイム・インスタンスにインストールしようとするとき、アプリケーション固有モジュールＭ３だけがロケーション１２にインストールされる必要があり、アプリケーションＡＭ３内の共有リソースＲ２は、ロケーション１４内に存在する、Ｒ２の既にインストールされているコピーへのリンクに置き換えることができる。
【００２４】
図２は、図でＡＭ３のラベルの付いた第３の新規アプリケーション１６’のインストール後のランタイム・インスタンス１０を示す。Ｍ３のラベルの付いたアプリケーション固有モジュール１８は、ロケーション１２にインストールされ、Ｒ２のラベルの付いた共有リソース２０は、ロケーション１４にインストールされている、この特定の共有リソース２０のコピーが既にあるので、インストールされないことになる。アプリケーションの共有リソースＲ２は、ロケーション１４内の共有リソースＲ２のロケーションへのリンクに置き換えられる。すなわち、同じ共有リソースの重複するコピーは、同じランタイム・インスタンス１０にインストールされない。新規共有リソースだけが、ロケーション１４にインストールされることになる。
【００２５】
図１および図２に関して説明した手法は、アプリケーションをランタイム・インスタンス１０にインストールするための効率的なプロセスを実現するとともに、ランタイム・インスタンス１０で利用可能なリソースの有効利用も実現する。アプリケーションがインストールされるとき、メモリの使用は削減され、使用される帯域幅が抑えられる。同じランタイム・インスタンス１０にインストールされるこの先のアプリケーションはすべて、ロケーション１４にまだインストールされていない共有リソース２０だけをインストールする同じプロセスを経るようになる。インストールしようとする各新規アプリケーション１６’は、新規アプリケーション１６’内の、アプリケーション固有のモジュール、および既に存在しているかもしれない共有リソースであるモジュールを識別するために、検査される。
【００２６】
ランタイム・インスタンス１０は、クライアント・デバイスに、ランタイム・インスタンス１０によってホストされたアプリケーション１６へのアクセスを提供するサーバ上に存在する。クライアント・デバイスが、アプリケーション１６の実行を要求すると、クライアント・デバイスのユーザにアプリケーション１６へのアクセスを提供するために、利用可能なサーバ上のランタイム・インスタンス１０にコピーがインストールされる。インストールされたアプリケーション１６は、１つまたは複数のアプリケーション固有モジュール１８および１つまたは複数の共有リソース２０を含む。共有リソース２０は、ライブラリなどのある意味で本質的に標準化されたコンポーネントであり、同じコンピューティング環境の様々なアプリケーションによって使用可能である。
【００２７】
図３は、本質的に、それぞれが１つまたは複数のランタイム・インスタンス１０を提供するサーバのネットワークからなるクラウド２２である、より複雑なコンピューティング環境を示す。クラウド２２は、処理および記憶機能をクライアント・デバイスに提供するコンピューティング・リソースであり、それらは通常、利用可能なコンピューティング機能へアクセスするためにユーザが開始するセッションを介して提供される。管理コンポーネント２８が、セッションの設定、およびユーザが自身のローカル・クライアント・デバイスを介してアクセスするアプリケーションのインストールを管理する。クラウド２２を構成する基盤となるハードウェア・リソースはクライアント・デバイスには見えず、ユーザは、コンピューティング・リソースを提供する、基盤となるプロセスを意識していない。
【００２８】
この図では、クラウド２２内のどこかにインストールする予定の新規アプリケーション１６が示されている。このアプリケーション１６は、既存のランタイム・インスタンス１０にインストールされる必要がある、または新規インスタンスが、新規アプリケーション１６専用に作成される必要がある。このアプリケーション１６は、アプリケーション固有モジュール１８や共有リソース２０などのモジュールを含む。アプリケーション１６からクラウド２２への矢印上に示された疑問符は、どこにアプリケーション１６をインストールするのが最善かという未解決の問題があることを示している。クラウド２２内の管理コンポーネント２８は、クラウド２２内のランタイム・インスタンス１０の分析を行わなければならない。
【００２９】
この分析は、新規アプリケーション１６をクラウド２２内にインストールするための最も論理的なロケーションを決定し、このプロセスについて、以下でより詳しく説明する。要約すれば、管理コンポーネント２８は、アプリケーション１６のインストールを求める要求を受信した後、アプリケーション１６によって求められる共有リソース２０を定義するデータにアクセスし、既存のランタイム・インスタンス１０に既にインストールされている共有リソース２０を定義するデータにアクセスする。管理コンポーネント２８は、アプリケーション１６によって求められる共有リソース２０に共通の最大多数のインストール済み共有リソース２０を備えた既存のランタイム・インスタンス１０を選択し、選択されたランタイム・インスタンス１０にアプリケーション１６をインストールする。
【００３０】
図４は、既存のランタイム・インスタンス１０にインストールされた各共有リソース２０の識別子２６を格納するために使用できる、共有リソースの参照テーブル（ＬＵＴ）２４を示す。本質的に、参照テーブル２４は行を含み、各行は、その識別子２６によって参照テーブル２４に表される特定の共有リソース２０に専用である。各行は、その行の特定の共有リソース２０を含むランタイム・インスタンス１０のリストも含む。図４の参照テーブル２４は、各共有リソース２０を単一のランタイム・インスタンス１０に存在するだけのように示しているが、実際的な実装形態では、各共有リソース２０が複数のランタイム・インスタンス１０に存在することになる可能性が高い。
【００３１】
参照テーブル２４内で使用される共有リソースの識別子２６は、特定のテクノロジ環境で一般に使用される、ファイル、モジュール、またはライブラリの名前であってもよい。さらに、または代替方法として、同じ共有リソース２０に使用される２つ以上の名前が存在するであろう場合、共有リソースの識別子２６を、共有リソース２０に基づく事前定義されたハッシュ関数を使用して作成することができる。これにより、管理コンポーネント２８は、受信される新規アプリケーション１６の一部をなす任意の共有リソース２０を識別できるようになる。管理コンポーネント２８は、共有リソースの識別子２６を得るために、各新規共有リソースに基づくハッシュ関数を実行する。
【００３２】
管理コンポーネント２８は、参照テーブル２４の格納および維持を行い、また新規アプリケーション１６がインストールされるとき、常に参照テーブル２４を更新することができる。例えば、２つが特定のランタイム・インスタンス１０に既に存在するが、２つが管理コンポーネントにとって完全に新しい４つの共有リソース２０を含む新規アプリケーション１６が、受信される場合がある。新規アプリケーション１６は、既存の２つの共通の共有リソース２０を既に備えた特定のランタイム・インスタンス１０にインストールされ、参照テーブル２４は、前もって認識されなかった２つの新規共有リソース２０がその特定のランタイム・インスタンス１０にインストールされたことを示すために更新されることになる。
【００３３】
図５は、新規アプリケーション１６’をクラウド２２内のどこかにインストールしようとするときにとられるプロセスの最初のステップを示す。ユーザは、アプリケーション・モジュールをクラウド２２に展開する。展開時、管理コンポーネント２８によって実行されるクラウド２２制御ソフトウェアは、以下のステップを実行し、それは、５０１で、アプリケーション・モジュール・タイプを例えば、ＪＥＥのｅａｒファイルやＯＳＧｉのアプリケーション・ファイルとして検出することで始まる。クラウド２２内に既にインストールされているランタイム・インスタンス１０にインストールしようとする新規アプリケーション１６’内に存在する様々なアプリケーション・モジュール・タイプを検出するために、ファイル拡張子、またはプログラミング環境の構造に関する知識が使用されてもよい。
【００３４】
アプリケーション・モジュール・タイプの知識を使用して、管理コンポーネント２８は、５０２で、ユーティリティ・モジュール、例えば、ｅａｒファイル内のＥｎｔｅｒｐｒｉｓｅ  Ｊａｖａ（Ｒ）  Ｂｅａｎｓ（ＥＪＢ）ｊａｒファイルのマニフェストから参照されるｊａｒファイルや、ＯＳＧｉアプリケーション内に値によって含まれるバンドルを識別する。すべてのユーティリティ・モジュールは、たとえそれが単一のアプリケーション・モジュールのみによって使用される場合でも、変換されて共有ライブラリまたは共有バンドルになる。こうしたモジュールは、共有リソース２０になることが考えられ得る。本質的に汎用的でその特定のアプリケーションに固有でない、新規アプリケーション１６’内の任意のモジュールは、共有リソース２０になる可能性がある。これらは、同じランタイム・インスタンス１０内のアプリケーション１６間で再利用できるモジュールである。
【００３５】
クラウド２２向けの制御ソフトウェアを実行する管理コンポーネント２８は、新規アプリケーション１６’に使用されるプログラミング言語に関しては、中立的である。クラウド２２にインストールされた任意の新規アプリケーション１６’は、新規アプリケーション１６’が、アプリケーション１６間で２つ以上を共有できる個別のモジュールを含んでいる限り、本明細書で説明する手法で処理することができる。図５に示されているステップ１およびステップ２では、管理コンポーネント２８が、新規アプリケーション１６’をクラウド２２内により効率的にインストールするために、新規アプリケーション１６’を構成するモジュールを検査して、当該新規アプリケーション１６’内の「ユーティリティ・モジュール」を識別する。
【００３６】
図６は、プロセスの次のステップを示す。管理コンポーネント２８は、６０３で、新規アプリケーション１６’内の各共有リソース２０の識別子２６を作成する。このリソースの識別子２６は、同一性をチェックするために、他の共有リソース２０との比較用に使用される。これは、ハッシュ関数によって生成されてもよく、名前ベースであっても、単に共有リソース２０を構成するバイトであってもよい。管理コンポーネント２８は、６０４で、既に少なくとも１つの共有リソース２０がインストールされている、クラウド２２内の、アプリケーション・フレームワークのすべてのランタイム・インスタンス１０を、共有リソースの参照テーブル２４を使用して検索する。参照テーブルは、例えば参照テーブル２４を検索することで共有リソースがインストールされるランタイム・インスタンス１０に、共有リソースの識別子２６をマッピングする。こうしたランタイム・インスタンス１０は、新規アプリケーション１６’をインストールするための潜在的な候補と考えられる。
【００３７】
管理コンポーネント２８は、次いで６０５で、アプリケーション固有モジュール１８を、以下の基準セットを最も満たすランタイム・インスタンス１０にインストールする。基準セットでは、ランタイム・インスタンスは、できるだけ多くの共通の共有リソース２０を備えるとともに、アプリケーション固有モジュール１８のパフォーマンス要件を満たすのに十分な空き容量を備えている。インストール時に、管理コンポーネント２８は、必要に応じて、任意の新規共有リソース、またはアプリケーション固有モジュール１８から既存の共有リソース２０へのリンク、あるいはその両方を作成する。このように、管理コンポーネント２８は、新規アプリケーション１６’向けに最も効率的なロケーションを選択する。この効率性によって、インストールを要するデータ量が減少し、また管理コンポーネント２８による追加作業が最小限となってインストール・プロセスの帯域幅要件も抑えられる。
【００３８】
図５および図６の例では、新規アプリケーション１６’は、Ｒ１およびＲ２のラベルの付いた２つの共有リソース２０を含む。参照テーブル２４によれば、ＡＦＲ１のラベルの付いたランタイム・インスタンス１０は、既に存在する共有リソースＲ１を備えている。しかし、ＡＦＲ２のラベルの付いたランタイム・インスタンス１０は、同様に参照テーブル２４から分かるように、既存の共有リソースＲ１とＲ２の両方を備えている。これは、このランタイム・インスタンスＡＦＲ２が、新規アプリケーション１６’のインストールにより良いロケーションであり、したがって、図６の矢印によって示されているように、管理コンポーネント２８は、新規アプリケーション１６’をこのランタイム・インスタンス１０にインストールすることを意味する。
【００３９】
新規アプリケーション１６’のインストールに適合するランタイム・インスタンス１０が見つからない場合、管理コンポーネント２８は、通常どおりクラウド２２の新規のランタイム・インスタンス１０を準備し、アプリケーション固有モジュール１８および新規共有リソース２０がそこにインストールされる。最後に、管理コンポーネント２８は、共有リソースの参照テーブル２４を、新しく作成された任意の共有リソースの識別子２６、および共有リソースがインストールされたランタイム・インスタンス１０で更新する。これにより、新規アプリケーション１６’がインストールされるたびに絶えず更新されるようになる動的な参照テーブル２４が提供され、ランタイム・インストールの効率性が、アプリケーション１６のクラウド２２内へのインストールを求めるユーザ要求が受信されるとき、各新規アプリケーション１６’に対して継続することになる。
【００４０】
図７は、クラウド２２内のサーバとしての管理コンポーネント２８を示す。管理コンポーネント２８は、クラウド２２を構成する他のサーバ３０に通じている。多数の様々なマシンが、クラウド２２内で複数のコンポーネントを提供する、サーバ３０および専用記憶装置を含むクラウド２２を構成することになる。管理コンポーネント２８は、新規アプリケーション１６のインストールに関連して、ＣＤ−ＲＯＭ３２などのコンピュータ可読媒体から提供できるコンピュータ・プログラム製品によって制御可能である。コンピュータ・プログラム製品に付随する命令は、新規アプリケーション１６のインストールを処理するとき、管理コンポーネント２８のプロセッサを制御するために使用される。
【００４１】
コンピュータ・プログラム製品の命令によって具体化されたプロセスが、図８の流れ図に要約されている。新規アプリケーション１６をランタイム・インスタンス１０にインストールする方法は、８０１で、アプリケーション１６のインストールを求める要求を受信するステップと、８０２で、アプリケーション１６によって求められる共有リソース２０を定義するデータにアクセスするステップと、８０３で、既存のランタイム・インスタンス１０に既にインストールされている共有リソース２０を定義するデータ２４にアクセスするステップと、８０４で、アプリケーション１６によって求められる共有リソース２０に共通の最大多数のインストール済み共有リソース２０を備えた既存のランタイム・インスタンス１０を選択するステップと、８０５で、選択されたランタイム・インスタンス１０にアプリケーション１６をインストールするステップとを含む。
【００４２】
本発明の好ましい実施形態では、共有リソースがどこで見つかるかの記録は参照テーブル２４に格納されている。当業者であれば、そうした記録が、例えばリレーショナル・データベースになど、多数の様々なアーティファクトに格納でき、またそこからアクセスできることが理解されよう。
【００４３】
当業者であれば理解されようが、本発明の態様は、システム、方法、コンピュータ・プログラム製品、またはコンピュータ・プログラムとして具体化され得る。したがって、本発明の態様は、完全にハードウェアの実施形態、完全にソフトウェアの実施形態（ファームウェア、常駐ソフトウェア、マイクロコードなどを含む）、またはソフトウェアの態様とハードウェアの態様を組み合わせた一実施形態の形をとってもよい。それらはすべて、一般に本明細書で「回路」、「モジュール」、または「システム」と呼ばれる場合がある。さらに、本発明の態様は、コンピュータ可読プログラム・コードをその上で具体化する１つまたは複数のコンピュータ可読媒体で具体化されるコンピュータ・プログラム製品の形をとってもよい。
【００４４】
１つまたは複数のコンピュータ可読媒体の任意の組合せが利用されてもよい。コンピュータ可読媒体は、コンピュータ可読信号媒体でも、またコンピュータ可読記憶媒体でもよい。コンピュータ可読記憶媒体は、例えば、それだけに限定されるものではないが、電子的、磁気的、光学式、電磁的、赤外線式、もしくは半導体式のシステム、装置、またはデバイス、あるいは以上の任意の適当な組合せであってもよい。コンピュータ可読記憶媒体のより具体的な例（非網羅的リスト）には、次のものが含まれる。すなわち、１つもしくは複数の配線を有する電気的な接続、携帯型のコンピュータ・ディスケット、ハード・ディスク、ランダム・アクセス・メモリ（ＲＡＭ）、読出し専用メモリ（ＲＯＭ）、消去可能プログラム可能読出し専用メモリ（ＥＰＲＯＭもしくはフラッシュ・メモリ）、光ファイバ、携帯型コンパクト・ディスク読出し専用メモリ（ＣＤ−ＲＯＭ）、光学式記憶装置、磁気記憶装置、または以上の任意の適当な組合せである。本明細書の内容上、コンピュータ可読記憶媒体は、命令実行のシステム、装置、もしくはデバイスによって、またはこれらとともに使用するためのプログラムを収容、あるいは格納できる任意の有形の媒体であってもよい。
【００４５】
コンピュータ可読信号媒体は、コンピュータ可読プログラム・コードが具体化された伝搬されるデータ信号を、例えばベースバンド内に、または搬送波の一部として含むことができる。そのような伝搬される信号は、それだけに限定されるものではないが、電磁的、光学式、またはこれらの任意の適切な組合せを含めて、様々な形のいずれかをとることができる。コンピュータ可読信号媒体は、命令実行のシステム、装置、もしくはデバイスによって、またはこれらとともに使用するためのプログラムを通信、伝搬、あるいは転送できる、コンピュータ可読記憶媒体ではない任意のコンピュータ可読媒体であってもよい。
【００４６】
コンピュータ可読媒体上で具体化されるプログラム・コードは、それだけに限定されるものではないが、無線、有線、光ファイバ・ケーブル、ＲＦなど、または以上の任意の適切な組合せを含めて、任意の適当な媒体を使用して伝送することができる。
【００４７】
本発明の態様の動作を実行するコンピュータ・プログラム・コードは、Ｊａｖａ（Ｒ）、Ｓｍａｌｌｔａｌｋ（Ｒ）、Ｃ＋＋などのオブジェクト指向プログラム言語、および「Ｃ」プログラム言語もしくは類似のプログラム言語などの従来の手続き型プログラム言語を含む、１つまたは複数のプログラム言語の任意の組合せで記述することができる。プログラム・コードは、全体的にユーザのコンピュータ上で、部分的に、独立型のソフトウェア・パッケージとしてユーザのコンピュータ上で、部分的にユーザのコンピュータ上でまた部分的に遠隔のコンピュータ上で、または全体的に遠隔のコンピュータもしくはサーバ上で実行することができる。最後のシナリオの場合、遠隔のコンピュータは、ローカル・エリア・ネットワーク（ＬＡＮ）もしくはワイド・エリア・ネットワーク（ＷＡＮ）を含む、任意のタイプのネットワークを介してユーザのコンピュータに接続することができ、または外部のコンピュータへ（例えば、インターネット・サービス・プロバイダを使用してインターネットを介して）接続を行うこともできる。Ｊａｖａ（Ｒ）およびすべてのＪａｖａ（Ｒ）ベースの商標およびロゴは、Ｏｒａｃｌｅまたはその関連会社あるいはその両方の商標または登録商標である。
【００４８】
以下で、本発明の実施形態による、方法、装置（システム）、およびコンピュータ・プログラム製品の流れ図またはブロック図あるいはその両方を参照しながら、本発明の態様を説明する。流れ図またはブロック図あるいはその両方のそれぞれのブロック、および流れ図またはブロック図あるいはその両方のブロックの組合せが、コンピュータ・プログラム命令によって実装され得ることが理解されよう。これらのコンピュータ・プログラム命令は、汎用コンピュータ、特殊用途コンピュータ、または他のプログラム可能データ処理装置のプロセッサに提供可能であり、コンピュータまたは他のプログラム可能データ処理装置のプロセッサを介して実行された命令が、流れ図もしくはブロック図またはその両方のブロックあるいはブロック群で指定される機能／行為を実施するための手段を実現するようなマシンを形成する。
【００４９】
これらのコンピュータ・プログラム命令はまた、コンピュータ、他のプログラム可能データ処理装置、または他のデバイスに特定の方法で機能するよう指示できるコンピュータ可読媒体に格納可能であり、これにより、コンピュータ可読媒体に格納された命令が、流れ図もしくはブロック図またはその両方のブロックあるいはブロック群で指定された機能／行為を実施する命令を含む製品を形成する。
【００５０】
コンピュータ・プログラム命令はまた、コンピュータ、他のプログラム可能データ処理装置、または他のデバイスにロードでき、コンピュータ、他のプログラム可能装置、または他のデバイス上で一連の動作ステップを実行させ、コンピュータまたは他のプログラム可能装置上で実行された命令が、流れ図もしくはブロック図またはその両方のブロックあるいはブロック群で指定された機能／行為を実施するためのプロセスを提供するようなコンピュータ実施プロセスを形成する。
【００５１】
図示された流れ図およびブロック図は、本発明の様々な実施形態による、システム、方法、およびコンピュータ・プログラム製品に対する可能な実装形態のアーキテクチャ、機能性、ならびに動作を示す。この点に関連して、流れ図またはブロック図における各ブロックは、特定の論理機能（複数可）を実装するための１つもしくは複数の実行可能命令を含む、モジュール、セグメント、またはコードの一部を示すことができる。また、いくつかの別の実装形態において、ブロックに記された機能が、図に記された順序以外で発生し得ることにも留意されたい。例えば、関係する機能に応じて、連続して示されている２つのブロックは、実際には実質的に同時に実行されてもよく、またそのブロックは時には逆の順序で実行されてもよい。また、ブロック図または流れ図あるいはその両方のそれぞれのブロック、およびブロック図または流れ図あるいはその両方のブロックの組合せが、特定の機能または行為を実行する特殊用途のハードウェア・ベースのシステムによって、あるいは特殊用途のハードウェアとコンピュータ命令の組合せによって実装され得ることにも留意されたい。
【００５２】
疑念を回避するために、「備える、含む（comprising）」という用語は、明細書および特許請求の範囲を通じて本明細書で使用されるとき、「のみからなる（consisting only of）」を意味するとみなされるべきではない。
【図１】
0005719487.tif 000002
【図２】
0005719487.tif 000003
【図３】
0005719487.tif 000004
【図４】
0005719487.tif 000005
【図５】
0005719487.tif 000006
【図６】
0005719487.tif 000007
【図７】
0005719487.tif 000008
【図８】
0005719487.tif 000009