JP2017519309A - マルチテナントアプリケーションサーバ環境におけるパーティションマイグレーションのためのシステムおよび方法 - Google Patents

Abstract

一実施形態に従うと、マルチテナントアプリケーションサーバ環境におけるパーティションマイグレーションのためのシステムおよび方法がこの明細書中に記載される。各々のリソースグループまたはそのリソースグループを含むパーティションは、そのリソースグループまたはパーティションがターゲット設定されてデプロイされるべきターゲットを定義する仮想ターゲット（たとえば仮想ホスト）情報に関連付けることができる。ウェブ層コンポーネント（たとえば、Oracle Traffic Director）はルーティング情報を含み、当該ルーティング情報は、特定のパーティションのための仮想ターゲットをサーバまたはクラスタなどの対応するターゲットにマッピングして、これにより、そのパーティションのための複数の要求が、たとえば１つ以上のセッションの一部として、適切なターゲットに向けられるようにする。パーティションがマイグレートされると、セッション情報が元のターゲットと新しいターゲットとの間で複製され、ウェブ層コンポーネントには修正されたルーティング情報が与えられ、これにより、そのパーティションのための後続の複数の要求が新しいターゲットに向けられるようにする。

Description

発明の分野：
本発明の実施形態は、概して、アプリケーションサーバおよびクラウド環境に関し、特に、マルチテナントアプリケーションサーバ環境におけるパーティションマイグレーションのためのシステムおよび方法に関する。

背景：
アプリケーションサーバは、概して、ソフトウェアアプリケーションをデプロイして実行することができる管理された環境を提供する。クラウドベースの環境は、クラウドによって提供される分散型リソース内でアプリケーションを実行して、当該分散型リソースを利用することを可能にする。このような環境は、多くのユーザまたはテナントをサポートすることができ、それらのうちのいくつかは、そのユーザまたはテナントに特有の特定条件を有する可能性がある。これらは、本発明の実施形態が使用可能となる環境のタイプのいくつかの例に該当する。

概要：
一実施形態に従うと、マルチテナントアプリケーションサーバ環境におけるパーティションマイグレーションのためのシステムおよび方法がこの明細書中に記載される。各々のリソースグループまたはそのリソースグループを含むパーティションは、そのリソースグループまたはパーティションがターゲット設定されてデプロイされるべきターゲットを定義する仮想ターゲット（たとえば仮想ホスト）情報に関連付けることができる。ウェブ層コンポーネント（たとえば、Oracle Traffic Director）はルーティング情報を含み、当該ルーティング情報は、特定のパーティションのための仮想ターゲットをサーバまたはクラスタなどの対応するターゲットにマッピングして、これにより、そのパーティションのための複数の要求が、たとえば１つ以上のセッションの一部として、適切なターゲットに向けられるようにする。特定のパーティションがマイグレートされると、セッション情報が元のターゲットと新しいターゲットとの間で複製され、ウェブ層コンポーネントには修正されたルーティング情報が与えられ、これにより、そのパーティションのための後続の複数の要求が新しいターゲットに向けられるようにする。

一実施形態に従った、アプリケーションサーバ、クラウドまたは他の環境においてマルチテナンシをサポートするためのシステムを示す図である。 一実施形態に従った、アプリケーションサーバ、クラウドまたは他の環境においてマルチテナンシをサポートするためのシステムをさらに示す図である。 一実施形態に従った、アプリケーションサーバ、クラウドまたは他の環境においてマルチテナンシをサポートするためのシステムをさらに示す図である。 一実施形態に従った、例示的なマルチテナント環境で使用されるドメイン構成を示す図である。 一実施形態に従った例示的なマルチテナント環境をさらに示す図である。 一実施形態に従った、アプリケーションサーバ、クラウドまたは他の環境におけるパーティションマイグレーションの使用を示す図である。 一実施形態に従った、アプリケーションサーバ、クラウドまたは他の環境におけるパーティションマイグレーションの使用をさらに示す図である。 一実施形態に従った、アプリケーションサーバ、クラウドまたは他の環境におけるパーティションマイグレーションの使用方法を示す図である。

詳細な説明：
一実施形態に従うと、マルチテナントアプリケーションサーバ環境におけるパーティションマイグレーションのためのシステムおよび方法がこの明細書中に記載される。各々のリソースグループまたはそのリソースグループを含むパーティションは、そのリソースグループまたはパーティションがターゲット設定されてデプロイされるべきターゲットを定義する仮想ターゲット（たとえば仮想ホスト）情報に関連付けることができる。ウェブ層コンポーネント（たとえば、Oracle Traffic Director）はルーティング情報を含み、当該ルーティング情報は、特定のパーティションのための仮想ターゲットをサーバまたはクラスタなどの対応するターゲットにマッピングして、これにより、そのパーティションのための複数の要求が、たとえば１つ以上のセッションの一部として、適切なターゲットに向けられるようにする。特定のパーティションがマイグレートされると、セッション情報が元のターゲットと新しいターゲットとの間で複製され、ウェブ層コンポーネントには修正されたルーティング情報が与えられ、これにより、そのパーティションのための後続の複数の要求が新しいターゲットに向けられるようにする。

アプリケーションサーバ（たとえば、マルチテナント（Multi-Tenant：ＭＴ））環境
図１は、一実施形態に従った、アプリケーションサーバ、クラウドまたは他の環境においてマルチテナンシをサポートするためのシステムを示す。

図１に示されるように、一実施形態に従うと、アプリケーションサーバ（たとえばマルチテナント（ＭＴ））環境１００または他のコンピューティング環境は、ソフトウェアアプリケーションのデプロイメントおよび実行を可能にするものであって、アプリケーションサーバドメインを定義するために実行時に用いられるドメイン１０２の構成を含み、当該ドメイン１０２の構成に従って動作するように構成することができる。

一実施形態に従うと、アプリケーションサーバは、実行時に使用されるよう定義される１つ以上のパーティション１０４を含み得る。各々のパーティションは、グローバルユニークパーティション識別子（identifier：ＩＤ）およびパーティション構成に関連付けることができ、さらに、リソースグループテンプレートの参照１２６および／またはパーティション特有のアプリケーションもしくはリソース１２８とともに、１つ以上のリソースグループ１２４を含み得る。ドメインレベルのリソースグループ、アプリケーションおよび／またはリソース１４０も、任意にはリソースグループテンプレートの参照とともに、ドメインレベルで定義することができる。

各々のリソースグループテンプレート１６０は、１つ以上のアプリケーションＡ１６２、Ｂ１６４、リソースＡ１６６、Ｂ１６８および／または他のデプロイ可能なアプリケーションもしくはリソース１７０を定義することができ、リソースグループによって参照することができる。たとえば、図１に例示されるように、パーティション１０４におけるリソースグループ１２４は、リソースグループテンプレート１６０を参照する（１９０）ことができる。

概して、システムアドミニストレータは、パーティション、ドメインレベルのリソースグループおよびリソースグループテンプレート、ならびにセキュリティ領域を定義することができるとともに、パーティションアドミニストレータは、たとえば、パーティションレベルのリソースグループを作成するか、アプリケーションをパーティションにデプロイするかまたはパーティションについての特定の領域を参照することによって、それら自体のパーティションのアスペクトを定義することができる。

図２は、一実施形態に従った、アプリケーションサーバ、クラウドまたは他の環境においてマルチテナンシをサポートするためのシステムをさらに示す。

図２に示されるように、一実施形態に従うと、パーティション２０２は、たとえば、リソースグループテンプレート２１０の参照２０６を含むリソースグループ２０５と、仮想ターゲット（たとえば仮想ホスト）情報２０７と、プラグ接続可能なデータベース（pluggable database：ＰＤＢ）情報２０８とを含み得る。リソースグループテンプレート（たとえば２１０）は、たとえば、Ｊａｖａ（登録商標）メッセージサーバ（Java Message Server：ＪＭＳ）サーバ２１３、ストア・アンド・フォワード（store-and-forward：ＳＡＦ）エージェント２１５、メールセッションコンポーネント２１６またはＪａｖａデータベースコネクティビティ（Java Database Connectivity：ＪＤＢＣ）リソース２１７などのリソースとともに、複数のアプリケーションＡ２１１およびＢ２１２を定義することができる。

図２に例示されるリソースグループテンプレートが一例として提供される。他の実施形態に従うと、さまざまなタイプのリソースグループテンプレートおよび要素を提供することができる。

一実施形態に従うと、パーティション（たとえば２０２）内のリソースグループが、特定のリソースグループテンプレート（たとえば２１０）を参照する（２２０）と、パーティション特有の情報２３０（たとえば、パーティション特有のＰＤＢ情報）を示すために、特定のパーティションに関連付けられた情報を、参照されたリソースグループテンプレートと組合わせて用いることができる。次いで、パーティション特有の情報は、パーティションによって使用されるリソース（たとえば、ＰＤＢリソース）を構成するようにアプリケーションサーバによって使用可能である。たとえば、パーティション２０２に関連付けられたパーティション特有のＰＤＢ情報は、そのパーティションによって使用されるべき適切なＰＤＢ２３８を備えたコンテナデータベース（container database：ＣＤＢ）２３６を構成する（２３２）ようにアプリケーションサーバによって使用可能である。

同様に、一実施形態に従うと、特定のパーティションに関連付けられた仮想ターゲット情報を用いて、そのパーティションによって使用されるべきパーティション特有の仮想ターゲット２４０（たとえば、ユニフォーム・リソース・ロケータ（uniform resource locator：ＵＲＬ）（たとえば、http://baylandurgentcare.com）によってアクセス可能にすることができるbaylandurgentcare.com）を定義する（２３９）ことができる。

図３は、一実施形態に従った、アプリケーションサーバ、クラウドまたは他の環境においてマルチテナンシをサポートするためのシステムをさらに示す。

一実施形態に従うと、config.xml構成ファイルなどのシステム構成を用いて、パーティションを定義する。当該パーティションは、そのパーティションに関連付けられたリソースグループについての構成エレメントおよび／または他のパーティションプロパティを含む。値は、プロパティ名／値の対を用いてパーティションごとに指定することができる。

一実施形態に従うと、複数のパーティションは、管理されたサーバ／クラスタ２４２内で、または、ＣＤＢ２４３にアクセス可能でありかつウェブ層２４４を介してアクセス可能である同様の環境内で、実行することができる。これにより、たとえば、ドメインまたはパーティションを（ＣＤＢの）ＰＤＢのうち１つ以上のＰＤＢに関連付けることが可能となる。

一実施形態に従うと、複数のパーティションの各々、この例においてはパーティションＡ２５０およびパーティションＢ２６０は、そのパーティションに関連付けられた複数のリソースを含むように構成することができる。たとえば、パーティションＡは、アプリケーションＡ１ ２５２と、アプリケーションＡ２ ２５４と、ＪＭＳ Ａ ２５６と、さらには、ＰＤＢ Ａ ２５９に関連付けられたデータソースＡ２５７とをともに含むリソースグループ２５１を含むように構成することができる。この場合、パーティションは仮想ターゲットＡ２５８を介してアクセス可能である。同様に、パーティションＢ２６０は、アプリケーションＢ１ ２６２と、アプリケーションＢ２ ２６４と、ＪＭＳ Ｂ ２６６と、さらには、ＰＤＢ Ｂ ２６９に関連付けられたデータソースＢ２６７とをともに含むリソースグループ２６１を含むように構成することができる。この場合、パーティションは仮想ターゲットＢ２６８を介してアクセス可能である。

上述の例のうちいくつかはＣＤＢおよびＰＤＢの使用を例示しているが、他の実施形態に従うと、他のタイプのマルチテナントのデータベースまたは非マルチテナントのデータベースをサポートすることができる。この場合、特定の構成は、たとえば、スキーマを使用するかまたはさまざまなデータベースを使用することによって、各々のパーティションのために提供することができる。

リソース
一実施形態に従うと、リソースは、環境のドメインにデプロイすることができるシステムリソース、アプリケーションまたは他のリソースもしくはオブジェクトである。たとえば、一実施形態に従うと、リソースは、アプリケーション、ＪＭＳ、ＪＤＢＣ、ＪａｖａＭａｉｌ、ＷＬＤＦもしくはデータソースであり得るか、または、サーバ、クラスタもしくは他のアプリケーションサーバターゲットにデプロイすることができる他のシステムリソースもしくは他のタイプのオブジェクトであり得る。

パーティション
一実施形態に従うと、パーティションは、パーティション識別子（partition identifier：ＩＤ）および構成に関連付けられ得るドメインのうちランタイムおよび管理の区分またはスライスであるとともに、アプリケーションを含み得て、ならびに／または、リソースグループおよびリソースグループテンプレートを使用することによってドメイン全体に渡るリソースを参照し得る。

概して、パーティションは、それ自体のアプリケーションを含み、リソースグループテンプレートを介してドメイン全体に渡るアプリケーションを参照し、それ自体の構成を有し得る。パーティション可能なエンティティは、リソース、たとえば、ＪＭＳ、ＪＤＢＣ、ＪａｖａＭａｉｌ、およびＷＬＤＦリソースや、他のコンポーネント、たとえばＪＮＤＩネームスペース、ネットワークトラフィック、ワークマネージャ、セキュリティポリシーおよび領域などを含み得る。マルチテナント環境のコンテキストにおいては、システムは、テナントに関連付けられたパーティションの管理およびランタイムのアスペクトへのアクセスをテナントに提供するように構成することができる。

一実施形態に従うと、パーティション内の各々のリソースグループは、任意には、リソースグループテンプレートを参照することができる。パーティションは、複数のリソースグループを有し得るとともに、それらの各々はリソースグループテンプレートを参照し得る。各々のパーティションは、パーティションのリソースグループが参照するリソースグループテンプレートにおいて指定されていない構成データについてのプロパティを定義することができる。これにより、パーティションが、リソースグループテンプレートで定義されたデプロイ可能なリソースをそのパーティションで使用されるべき特定の値にバインドするものとして機能することが可能となる。場合によっては、パーティションは、リソースグループテンプレートによって指定される構成情報を無効にすることができる。

一実施形態に従うと、パーティション構成は、たとえば、config.xml構成ファイルによって定義されるように、複数の構成エレメントを含み得る。複数の構成エレメントは、たとえば、「パーティション（partition）」（そのパーティションを定義する属性および子エレメントを含む）；「リソース・グループ（resource-group）」（パーティションにデプロイされるアプリケーションおよびリソースを含む）；「リソース・グループ・テンプレート（resource-group-template）」；（そのテンプレートによって定義されるアプリケーションおよびリソースを含む）；「ｊｄｂｃ・システム・リソース・無効化（jdbc-system-resource-override）」（データベース特有のサービス名、ユーザ名およびパスワードを含む）；ならびに、「パーティション・プロパティ（partition-properties）」（リソースグループテンプレートにおいてマクロ置換のために使用可能なプロパティキー値を含む）を含む。

始動後、システムは、構成ファイルによって提供される情報を用いて、リソースグループテンプレートから各々のリソースについてのパーティション特有の構成エレメントを生成することができる。

リソースグループ
一実施形態に従うと、リソースグループは、名前付けされ完全に修飾されたデプロイ可能なリソースの集合であって、ドメインまたはパーティションのレベルで定義することができ、かつ、リソースグループテンプレートを参照することができる。リソースグループにおけるリソースは、完全に修飾されているものと見なされる。というのも、アドミニストレータが、それらのリソースを開始させるのに必要とされるかまたはそれらのリソースに接続するのに必要とされるすべての情報、たとえば、データソースに接続するためのクレデンシャル、またはアプリケーションについての目標情報、を提供しているからである。

システムアドミニストレータは、ドメインレベルで、またはパーティションレベルでリソースグループを公開することができる。ドメインレベルでは、リソースグループは、関連するリソースをグループ化するのに好都合な方法を提供する。システムは、グループ化されていないリソースと同じドメインレベルのリソースグループにおいて公開されたリソースを管理することができる。このため、リソースは、システム起動中に開始させたり、システムのシャットダウン中に停止させたりすることができる。アドミニストレータはまた、グループ内のリソースを個々に停止させるか、開始させるかまたは削除することができ、グループ上で動作させることによって暗黙的にグループ内のすべてのリソースに対して機能することができる。たとえば、あるリソースグループを停止させることにより、まだ停止されていないグループにおけるすべてのリソースを停止させ；リソースグループを始動させることにより、まだ始動させていないグループにおけるいずれのリソースも始動させ、リソースグループを削除することにより、グループに含まれるすべてのリソースを削除する。

パーティションレベルでは、システムまたはパーティションアドミニストレータは、任意のセキュリティ制限下で、或るパーティションにおいて０個以上のリソースグループを構成することができる。たとえば、ＳａａＳ使用事例においては、さまざまなパーティションレベルのリソースグループは、ドメインレベルのリソースグループテンプレートを参照することができる。ＰａａＳ使用事例においては、リソースグループテンプレートを参照しないが代わりにそのパーティション内でのみ利用可能にされるべきアプリケーションおよびそれらの関連するリソースを表わすパーティションレベルのリソースグループを作成することができる。

一実施形態に従うと、リソースグループ化を用いることで、アプリケーションと、それらアプリケーションがドメイン内で別個の管理ユニットとして使用するリソースとをともにグループ化することができる。たとえば、以下に記載される医療記録（ＭｅｄＲｅｃ）アプリケーションにおいては、リソースグループ化によりＭｅｄＲｅｃアプリケーションおよびそのリソースが定義される。複数のパーティションは、各々がパーティション特有の構成情報を用いて、同じＭｅｄＲｅｃリソースグループを実行することができ、このため、各々のＭｅｄＲｅｃインスタンスの一部であるアプリケーションが各々のパーティションにとって特有のものにされる。

リソースグループテンプレート
一実施形態に従うと、リソースグループテンプレートは、リソースグループから参照することができドメインレベルで定義されるデプロイ可能なリソースの集合であり、そのリソースを起動するのに必要な情報のうちいくらかは、パーティションレベル構成の仕様をサポートするように、テンプレート自体の一部として記憶されない可能性がある。ドメインは、リソースグループテンプレートをいくつ含んでもよく、それらの各々は、たとえば、１つ以上の関連するＪａｖａアプリケーションと、それらのアプリケーションが依存するリソースとを含み得る。このようなリソースについての情報のうちのいくらかは、すべてのパーティションにわたって同じであってもよく、他の情報はパーティションごとに異なっていてもよい。すべての構成がドメインレベルで指定される必要はなく、代わりに、パーティションレベル構成が、マクロまたはプロパティ名／値の対を使用することによってリソースグループテンプレートで指定することができる。

一実施形態に従うと、特定のリソースグループテンプレートは、１つ以上のリソースグループによって参照可能である。概して、任意の所与のパーティション内では、リソースグループテンプレートは一度に１つのリソースグループによって参照することができる。すなわち、同じパーティション内で複数のリソースグループによって同時に参照することはできない。しかしながら、異なるパーティションにおける別のリソースグループによって同時に参照することができる。リソースグループを含むオブジェクト、たとえばドメインまたはパーティションは、プロパティ名／値の割当てを用いて、任意のトークンの値をリソースグループテンプレートで設定することができる。システムは、参照するリソースグループを用いてリソースグループテンプレートを起動させると、それらのトークンを、リソースグループが含むオブジェクトにおいて設定された値と置換えることができる。場合によっては、システムはまた、静的に構成されたリソースグループテンプレートおよびパーティションを用いて、パーティション／テンプレートの組合せごとにランタイム構成を生成することができる。

たとえば、ＳａａＳ使用事例においては、システムは、同じアプリケーションおよびリソースを複数回起動することができるが、そのうちの１回は、それらを用いるであろう各パーティションごとに起動され得る。アドミニストレータがリソースグループテンプレートを定義すると、これらは、どこか他のところで提供されるであろう情報を表わすためにトークンを用いることができる。たとえば、ＣＲＭ関連のデータリソースに接続する際に使用されるユーザ名は、リソースグループテンプレートにおいて＼＄｛ＣＲＭＤａｔａＵｓｅｒｎａｍｅ｝として示すことができる。

テナント
一実施形態に従うと、マルチテナント（ＭＴ）アプリケーションサーバ環境などのマルチテナント環境においては、テナントは、１つ以上のパーティションおよび／もしくは１つ以上のテナント認識型アプリケーションによって表現可能であるエンティティ、または１つ以上のパーティションおよび／もしくは１つ以上のテナント認識型アプリケーションに関連付けることができるエンティティである。

たとえば、テナントは、別個のユーザ組織、たとえばさまざまな外部会社、特定の企業内のさまざまな部門（たとえばＨＲおよび財務部）などを表わすことができ、それら各々は、異なるパーティションに関連付けることができる。テナントのグローバルユニークアイデンティティ（テナントＩＤ）は、特定の時点において特定のユーザを特定のテナントに関連付けるものである。システムは、たとえば、ユーザアイデンティティの記録を参照することによって、ユーザアイデンティティから、特定のユーザがどのテナントに属しているかを導き出すことができる。ユーザアイデンティティにより、ユーザが実行することを認可されているアクションをシステムが実施することが可能となる。ユーザアイデンティティは、ユーザがどのテナントに属し得るかを含むが、これに限定されない。

一実施形態に従うと、システムは、互いに異なるテナントの管理およびランタイムを分離することを可能にする。たとえば、テナントは、それらのアプリケーションのいくつかの挙動、およびそれらがアクセスできるリソースを構成することができる。システムは、特定のテナントが別のテナントに属するアーティファクトを確実に管理することができないようにし、かつ、実行時に、特定のテナントの代わりに機能するアプリケーションがそのテナントに関連付けられたリソースのみを参照するが他のテナントに関連付けられたリソースは参照しないことを確実にすることができる。

一実施形態に従うと、テナント非認識型アプリケーションは、アプリケーションが応答している要求をどんなユーザが提示したかにかかわらず、アプリケーションが用いる如何なるリソースにもアクセス可能となるように明示的にテナントに対処する論理を含まないものである。対照的に、テナント認識型アプリケーションは、テナントに明示的に対処する論理を含む。たとえば、ユーザのアイデンティティに基づいて、アプリケーションは、ユーザが属するテナントを導き出すことができ、テナント特有のリソースにアクセスするためにその情報を用いることができる。

一実施形態に従うと、システムは、テナント認識型となるように明示的に書き込まれたアプリケーションをユーザがデプロイすることを可能にし、これにより、アプリケーション開発者は、現在のテナントのテナントＩＤを取得することができる。次いで、テナント認識型アプリケーションは、このテナントＩＤを用いて、アプリケーションの単一のインスタンスを用いている複数のテナントを処理することができる。

たとえば、単一の診療室または病院をサポートするＭｅｄＲｅｃアプリケーションは、２つの異なるパーティションまたはテナント（たとえばBayland Urgent CareテナントおよびValley Healthテナント）に対して公開することができ、その各々は、基礎をなすアプリケーションコードを変更することなく、別個のＰＤＢなどの別個のテナント特有のリソースにアクセスすることができる。

例示的なドメイン構成およびマルチテナント環境
一実施形態に従うと、アプリケーションは、ドメインレベルでリソースグループテンプレートにデプロイすることができるか、または、パーティションに範囲指定されているかもしくはドメインに範囲指定されているリソースグループにデプロイすることができる。アプリケーション構成は、アプリケーション毎またはパーティション毎に指定されたデプロイメントプランを用いて無効化することができる。デプロイメントプランはまた、リソースグループの一部として指定することができる。

図４は、一実施形態に従った、例示的なマルチテナント環境で使用されるドメイン構成を示す。

一実施形態に従うと、システムがパーティションを始動させると、当該システムは、提供された構成に従って、それぞれのデータベースインスタンスに対して、各パーティションごとに１つずつ、仮想ターゲット（たとえば仮想ホスト）および接続プールを作成する。

典型的には、各々のリソースグループテンプレートは、１つ以上の関連するアプリケーションと、それらアプリケーションが依存するリソースとを含み得る。各々のパーティションは、それが参照するリソースグループテンプレートにおいて指定されていない構成データを提供することができるが、これは、場合によっては、リソースグループテンプレートによって指定されるいくつかの構成情報を無効にすることを含めて、パーティションに関連付けられた特定値に対するリソースグループテンプレートにおけるデプロイ可能なリソースのバインディングを行なうことによって、実行可能である。これにより、システムは、各々のパーティションが定義したプロパティ値を用いて、パーティション毎にリソースグループテンプレートによってさまざまに表わされるアプリケーションを始動させることができる。

いくつかのインスタンスにおいては、パーティションが含み得るリソースグループは、リソースグループテンプレートを参照しないか、または、それら自体のパーティション範囲指定されたデプロイ可能なリソースを直接定義する。パーティション内で定義されるアプリケーションおよびデータソースは、概して、そのパーティションにとってのみ利用可能である。リソースは、パーティション：<partitionName>/<resource JNDI name>、またはドメイン：<resource JNDI name>を用いて、パーティションの中からアクセスすることができるようにデプロイ可能である。

たとえば、ＭｅｄＲｅｃアプリケーションは、複数のＪａｖａアプリケーション、データソース、ＪＭＳサーバおよびメールセッションを含み得る。複数のテナントのためにＭｅｄＲｅｃアプリケーションを実行させるために、システムアドミニストレータは、テンプレートにおけるそれらのデプロイ可能なリソースを公開している単一のＭｅｄＲｅｃリソースグループテンプレート２８６を定義することができる。

ドメインレベルのデプロイ可能なリソースとは対照的に、リソースグループテンプレートにおいて公開されたデプロイ可能なリソースは、テンプレートにおいて完全には構成されない可能性があるか、または、いくつかの構成情報が不足しているので、そのままでは起動させることができない。

たとえば、ＭｅｄＲｅｃリソースグループテンプレートは、アプリケーションによって用いられるデータソースを公開し得るが、データベースに接続するためのＵＲＬを指定しない可能性がある。さまざまなテナントに関連付けられたパーティション、たとえば、パーティションＢＵＣ−Ａ２９０（Bayland Urgent Care：ＢＵＣ）およびパーティションＶＨ−Ａ２９２（Valley Health：ＶＨ）は、各々がＭｅｄＲｅｃリソースグループテンプレートを参照する（２９６，２９７）ＭｅｄＲｅｃリソースグループ２９３，２９４を含むことによって、１つ以上のリソースグループテンプレートを参照することができる。次いで、当該参照を用いて、Bayland Urgent Careテナントによって使用されるＢＵＣ−Ａパーティションに関連付けられた仮想ホストbaylandurgentcare.com３０４と、Valley Healthテナントによって使用されるＶＨ−Ａパーティションに関連付けられた仮想ホストvalleyhealth.com３０８とを含む各々のテナントのための仮想ターゲット／仮想ホストを作成する（３０２，３０６）ことができる。

図５は、一実施形態に従った例示的なマルチテナント環境をさらに示す。図５に示されるように、２つのパーティションがＭｅｄＲｅｃリソースグループテンプレートを参照している上述の例から引続いて、一実施形態に従うと、サーブレットエンジン３１０は、この例においてはBayland Urgent Careの医師テナント環境３２０およびValley Healthの医師テナント環境３３０といった複数のテナント環境をサポートするために用いることができる。

一実施形態に従うと、各々のパーティション３２１および３３１は、そのテナント環境についての入来トラフィックを受入れるための異なる仮想ターゲットと、異なるＵＲＬ３２２，３３２とを定義することができる。異なるＵＲＬ３２２，３３２は、パーティションと、この例ではBayland Urgent Careデータベースまたはvalley healthデータベースを含むそれぞれのリソース３２４、３３４とに接続するためのものである。同じアプリケーションコードが両方のデータベースに対して実行され得るので、データベースインスタンスは互換性のあるスキーマを用いることができる。システムがパーティションを始動させると、当該システムは、それぞれのデータベースインスタンスに対する接続プールおよび仮想ターゲットを作成することができる。

パーティションマイグレーション
一実施形態に従うと、マルチテナントアプリケーションサーバ環境におけるパーティションマイグレーションのためのシステムおよび方法がこの明細書中に記載される。各々のリソースグループまたはそのリソースグループを含むパーティションは、そのリソースグループまたはパーティションがターゲット設定されてデプロイされるべきターゲットを定義する仮想ターゲット（たとえば仮想ホスト）情報に関連付けることができる。ウェブ層コンポーネント（たとえば、Oracle Traffic Director）はルーティング情報を含み、当該ルーティング情報は、特定のパーティションのための仮想ターゲットをサーバまたはクラスタなどの対応するターゲットにマッピングして、これにより、そのパーティションのための複数の要求が、たとえば１つ以上のセッションの一部として、適切なターゲットに向けられるようにする。特定のパーティションがマイグレートされると、セッション情報が元のターゲットと新しいターゲットとの間で複製され、ウェブ層コンポーネントには修正されたルーティング情報が与えられ、これにより、そのパーティションのための後続の複数の要求が新しいターゲットに向けられるようにする。

一実施形態に従うと、パーティションマイグレーションを用いることにより、シームレスなマイグレーションを提供することができる。このシームレスなマイグレーションは、パーティションが１つのターゲットから別のターゲットにマイグレートされるときに当該パーティションに関連付けられたセッションの状態を維持することを含む。これは、たとえば、基礎をなすコンピューティングインフラストラクチャに問題があるせいで顧客のアプリケーションが中断されてしまうのを確実に防止する際には有用であり得る。

図６は、一実施形態に従った、アプリケーションサーバ、クラウドまたは他の環境におけるパーティションマイグレーションの使用を示す。図６に示されるように、一実施形態に従うと、第１または元のターゲットクラスタＡ４０２は、パーティション構成４０６と１つ以上のパーティション特有のリソースグループ、アプリケーションまたはリソース４０８とに関連付けられた特定のパーティションＡ４０４を含む１つ以上のパーティションを含み得る。

任意には、パーティションはリソースグループテンプレート４１０を参照することができる。

各々のリソースグループまたはそのリソースグループを含むパーティションは、そのリソースグループまたはパーティションがターゲット設定されてデプロイされるべきターゲット（仮想ターゲットＡ４２０など）を定義する仮想ターゲット（たとえば仮想ホスト）情報に関連付けることができる。ウェブ層コンポーネント（たとえば、Oracle Traffic Directorなどのトラフィックディレクタ）４３０はルーティング情報４３２を含み、当該ルーティング情報４３２は、特定のパーティションのための仮想ターゲットをサーバまたはクラスタなどの対応するターゲットにマッピングして、これにより、その特定のパーティションのための複数の要求が、たとえば１つ以上のセッション４３４の一部としての適切なターゲットに向けられるようにする。

さらに例示されるように、システムは、パーティションがデプロイ可能な第２のまたは新しいターゲットクラスタＢ４４２を含み得る。

図７は、一実施形態に従った、アプリケーションサーバ、クラウドまたは他の環境におけるパーティションマイグレーションの使用をさらに示す。図７に示されるように、一実施形態に従うと、特定のパーティションと、その上で現在動作しているいずれかのセッションとを元のターゲットから新しいターゲットにまでマイグレートする（４４４）ようにとの指示を受信し得る。一般的に、システムは、特定の仮想ターゲットに関連付けられたターゲット間、たとえば、（異なる仮想ターゲット間ではなく）特定の仮想ターゲットに関連付けられたさまざまなクラスタメンバ間、でパーティションをマイグレートするだけであるだろう。

これに応じて、特定のパーティションがマイグレートされる。この場合、セッション情報が元のターゲットと新しいターゲットとの間で複製され、ウェブ層コンポーネントには修正されたルーティング情報４４６が与えられ、この修正されたルーティング情報４４６が特定のパーティションについての仮想ターゲットを新しいターゲットにマッピングし、これにより、そのパーティションのための後続の複数の要求が新しいターゲットに向けられる（４４８）ようにする。

たとえば、一実施形態に従うと、アプリケーションサーバ環境は、特定のコンピュータクラスタが（たとえば、メンテナンスまたはフェイルオーバーのせいで）まもなく停止するであろうことをトラフィックディレクタ（たとえばＯＴＤ）に通知して、予想される新しいクラスタに要求を送信し始めるようにトラフィックディレクタに指示することができる。一方、アプリケーションサーバは、新しいクラスタにセッション情報を複製することができる。セッション複製が完了すると、アプリケーションサーバ環境は、ダウングレードされたコンピュータクラスタをその構成から削除するようにトラフィックディレクタに通知することができ、次いで、このダウングレードされたコンピュータクラスタがいずれのリソースグループターゲット設定からも削除され得る。

一実施形態に従うと、クラスタがターゲットとして用いられる場合、システムはセッションのライブ・マイグレーションを実行する。コンピュータサーバがターゲットとして用いられる場合、ライブ・マイグレーション機能が使用不可能になって、ユーザ制御による手動のマイグレーションが用いられる可能性があり、これにより、起こり得るセッション情報の損失またはダウンタイムをいずれもユーザに通知することができるようにする。

図８は、一実施形態に従った、アプリケーションサーバ、クラウドまたは他の環境におけるパーティションマイグレーションの使用方法を示す。図８に示されるように、一実施形態に従うと、ステップ４６０において、ソフトウェアアプリケーションの実行のためのドメインならびに１つ以上のパーティションおよびリソースグループを含むアプリケーションサーバ環境が提供される。各々のパーティションは、ドメインの管理およびランタイム区分を提供し、１つ以上のリソースグループを含み得る。各々のリソースグループは、リソースグループテンプレートを参照し得るデプロイ可能なアプリケーションまたはリソースの集合である。

ステップ４６２において、各々のリソースグループまたはそのリソースグループを含むパーティションは、そのリソースグループまたはパーティションがターゲット設定されてデプロイされるべきターゲットを定義する仮想ターゲット（たとえば仮想ホスト）情報に関連付けることができる。

ステップ４６４において、特定のパーティションと、その上で現在動作しているいずれかのセッションとを元のターゲットから新しいターゲットにまでマイグレートするようにとの指示が受信される。

ステップ４６６において、特定のパーティションがマイグレートされる。この場合、セッション情報が元のターゲットと新しいターゲットとの間で複製され、ウェブ層コンポーネント（たとえば、Oracle Traffic Directorなどのトラフィックディレクタ）には修正されたルーティング情報が与えられ、当該修正されたルーティング情報は、特定のパーティションのための仮想ターゲットを新しいターゲットにマッピングして、これにより、そのパーティションのための後続の複数の要求が新しいターゲットに向けられるようにする。

インプリメンテーションの例
具体的な実施形態を説明する追加の詳細を例示の目的で以下に記載する。

（httpおよびｔ３トラフィックのための）ライブ・マイグレーションの概略
一実施形態に従うと、ライブ・マイグレーション中に、リソースグループが実行されている。アドミニストレータは、たとえばＪＭＸコマンドを用いてリソースグループ・マイグレーションを開始し、仮想ターゲットmbean、既存のターゲットおよび新しいターゲットをパラメータとして指定する。新しいターゲットは仮想ターゲットに追加され、リソースは新しいターゲットにデプロイされる。検証エラーが投入される場合、動作を終了させて、ソースとなるリソースグループをシャットダウンして、非ライブ・マイグレーションを実行することがユーザに通知される。使用中の新しいターゲットがクラスタである場合、セッション複製のためのＡＰＩのクラスタリングおよびＴ３の再ルーティングが開始される。ＯＴＤ再ルーティングのためのＬＣＭ ＡＰＩが開始され、これにより、ＯＴＤがこのリソースグループのフロントエンドとなっているかどうかが内部で判断される。指定されたターゲットのためにリソースグループのグレースフルシャットダウンを用いて、古いターゲットにターゲット設定されたアプリケーション／リソースのグレースフルシャットダウンが開始される。古いターゲットを削除するために、仮想ターゲットのためのmbean構成が更新される。

（httpおよびｔ３トラフィックのための）非ライブ・マイグレーションの概略
一実施形態に従うと、非ライブ・マイグレーション中に、リソースグループは実行されていない。ＷＬＳアドミニストレータは、たとえばＪＭＸコマンドを用いてリソースグループ・マイグレーションを開始し、仮想ターゲットmbean、既存のターゲット、新しいターゲットをパラメータとして指定する。古いターゲットが仮想ターゲットから削除され、新しいターゲットが仮想ターゲットに追加されて、内部においてリソース／アプリが新しいターゲットにデプロイされる。ＯＴＤ更新のためのＬＣＭ ＡＰＩが開始され、ＯＴＤがこのリソースグループのフロントエンドとなっているかどうかが内部において判断される。

リソースグループ・マイグレーションＡＰＩ
一実施形態に従うと、マイグレーションは、新しいサービスPortablePartitionManagerMbeanを用いて開始されることとなる。

新しいマイグレーション・コールが、同じ仮想ターゲットに対する別のマイグレーション・コールの処理中に開始される場合、検証例外（validation exception）が投入されることとなる。１つのリソースグループにおいて２つのマイグレーションプロセスを同時に開始させることはできない。ResourceGroupMigrationTaskは、この長い実行プロセスの状態についての情報を含んでいる。

仮想ターゲットへの新しいターゲットの追加
一実施形態に従うと、ライブ・マイグレーションの場合、新しいターゲットが仮想ターゲットに追加され、ＲＧにおけるアプリケーションおよびリソースが新しいターゲット上でデプロイされる。いずれのアプリケーションまたはリソースもマルチターゲット設定をサポートしていない場合、それらが検証例外を投入することとなる。この場合、マイグレーション動作は、リソースグループがライブ・マイグレーションをサポートしておらず、非ライブ・マイグレーションを実行するためにＲＧが最初にシャットダウンされなければならないという報告を終了させることとなる。

セッション複製およびＴ３再ルーティング
一実施形態に従うと、新しいターゲットが追加された後、ＷＬＳ−ＭＴクラスタリングセッション複製特徴を用いて、古いクラスタと新しいクラスタとの間でセッションを同期させることができ、セッション状態が新しいトポロジー（new Target：新しいターゲット）におけるいくつかのサーバにコピーされる。その後、コールバックイベントが送信されるが、変更されたセッション同士を同期さるためのプロセスは続けられる。マイグレーション・クラスタリング・サブシステムは、接続されているすべてのｔ３クライアントにターゲット変更を通知する。Ｔ３クライアントは、ターゲットからの新しいｕｒｌに再接続し、マイグレートされたアプリケーションとの通信をトランスペアレントに継続することとなる。クラスタ全体が停止すべき場合、クライアントは、周知のアドレスを入手してルーティングするべき新しいクラスタを再発見する能力を有していなければならない。

ＷＬＳ−ＭＴライフサイクルを用いたＨＴＴＰトラフィックの再ルーティング
一実施形態に従うと、マイグレーション機能は、さまざまな言語で、かつ構成および管理のためのさまざまなアーキテクチャを用いて、別個に開発されたコンポーネント間で構成を一体化することを企図して、マイグレーションのためのライフサイクル・モジュールの利用可能性を高め得る。

シームレス事例
一実施形態に従うと、シームレス事例の間、アプリケーションサーバは、パーティションマイグレーションＲＥＳＴコールでＬＣＭを呼出すこととなる：

ペイロードは、パーティションがデプロイされている新しいクラスタの詳細と、段階：start-migrate（マイグレートの開始）とを含むこととなる。ここで、段階：start-migrateでは、ＯＴＤにおける構成変更のためにＯＴＤ ｐｌｕｇｉｎ（プラグイン）を呼出し得る。ＯＴＤの機能仕様において指定されるようにＯＴＤ側で起こるステップを以下に記載する。

パーティションマイグレーションが開始されると、新しい要求を処理することとなる既存のプールとは別に新しいオリジンサーバプールをリストに記載するために、そのパーティションについての関連付けられた仮想サーバのobj.conf構成へのルートエントリが変更されることとなる。既存のプール（古いプールまたはドレインプール）は、そのオリジンサーバに対する厄介な要求だけを処理することとなる。

この構成変更の後、そのパーティションに対するすべての要求に関して、ＯＴＤは、それが厄介な要求かどうかと、要求を処理すると予想されているオリジンサーバが古いオリジンサーバプールの一部であるかどうかとを最初にチェックすることとなる。

そうであれば、要求が古いプールの特定のオリジンサーバへと経路設定される。その古いオリジンサーバが稼働中でなければ、それは古いプールの別のオリジンサーバへと経路設定されることとなる。

要求が厄介なものでなければ、その要求は新しいオリジンサーバプールへと経路設定される。

古いプールエントリを削除するように構成が変更されるまで、古いプールは厄介な要求を処理し続けることとなる。適切な時期にプールの排出を停止することはアドミニストレータの責任となるだろう。

ＷＬＳは、段階：end-migrate（マイグレートの終了）を指定する第２のパーティションマイグレーションＲＥＳＴコールを用いてＬＣＭを呼出し得る。段階：end-migrateでは、ＯＴＤにおける構成変更のためにＯＴＤ ｐｌｕｇｉｎを呼出し得る。

非シームレス事例
一実施形態に従うと、シームレス事例の間、アプリケーションサーバは、パーティション更新ＲＥＳＴコールを用いてＬＣＭを呼出すこととなる。

ペイロードは、パーティションがデプロイされている新しいクラスタの詳細を含むだろう。ＬＣＭは、そのパーティションのためのＯＴＤ構成を更新するために、コールをＯＴＤ Ｐｌｕｇｉｎに委任するだろう。

グレースフルシャットダウン（Graceful shutdown）
一実施形態に従うと、この段階中、リソースグループのシャットダウン特徴を用いて、指定された（古い）ターゲットのためにリソースグループ上でグレースフルシャットダウンが開始される。これにより、機内での作業の処理が可能になるだろう。これにより、ＪＭＳメッセージ、実行中のジョブ、スケジューリングされたタスクおよびＪＴＡトランザクションなどのシングルトンサービスによる未処理状態に関する問題が低減されるだろう。リソースコンテナは、それらの関連する停止／一時停止のコールをさまざまな方法で処理する。たとえば、データソースコンテナはトランザクションマネージャからそのリソースを完全に登録解除することとなり、一方で、ＪＭＳコンテナは登録解除を行なわないが、メッセージのさらなる要求／処理をブロックすることとなる。すべてのリソースコンテナは、デプロイ解除中に登録解除のコールを行なう。さまざまなリソースコンテナの登録解除動作は多様であるが、少なくとも猶予期間が常にあり、これにより、コンテナは、ペンディング中のトランザクションが完了するのを待つこととなる。

すべてのＪＴＡトランザクションの完了を確実化
一般的な場合、リソースグループ・マイグレーションが発生すると、関与するリソースを含むすべてのトランザクションは、マイグレーションの発生前に完了してしまっているだろう。猶予期間の終了によって所与のリソースのためのすべてのトランザクションが完了していないといった事例がまれにあり（これは、たとえば、リソースグループ・マイグレーションが開始されたのと同時にデータベースが長期間にわたって利用不可能になった場合に該当するだろう）、この場合でも、リソースは依然としてマイグレートすることができる。これは、リソース・マイグレーションが単一のドメインに制限されているためであり、さらに、元のサーバはその新しい位置でリソースを発見して回復させることができる。

ＥＪＢスタブ
クラスタ化されたＥＪＢおよびＲＭＩに関して、ＲＧマイグレーションはオブジェクトのレプリカ認識型スタブを用いて達成される。クライアントが、障害の発生したサービスに対してレプリカ認識型スタブによってコールを行う場合、スタブが障害を検出し、別のレプリカ上でコールを再試行する。一次的サーバに障害が発生した場合、クライアントのＥＪＢスタブは、自動的に、二次的アプリケーションサーバインスタンスに対してさらなる要求をリダイレクトする。この時点では、二次的サーバが複製された状態データを用いて新しいＥＪＢインスタンスを作成し、処理が二次的サーバ上で続けられる。クライアントが誤った指示（不正確な一次的／二次的サーバ情報）を受けた場合、セッション複製フレームワークはセッション状態クエリプロトコルを用いて、レプリカをホストしているサーバを決定し、クライアントスタブに情報を送信し返すこととなる。次いで、クライアントスタブは、レプリカをホストしているサーバにその要求を転送することとなる。

ＪＭＳ
アドミニストレータがＪＭＳコンフィグを有するリソースグループのマイグレーションを開始しようと試みる場合、検証例外が投入されるだろう。アドミニストレータは、マイグレーションの前にリソースグループをシャットダウンするようにとのメッセージを表示させることとなる。ＲＧマイグレーション中にデータ損失を回避するために、アプリケーションメッセージは完全に排出されなければならず、ペンディング中のすべてのトランザクションは、ＪＭＳサーバまたはＳＡＦエージェントをデプロイ解除するかまたは削除する前に完了させなければならない。したがって、リソースグループのシャットダウンが開始される前にすべての排出がなされることを確実にすることがアドミニストレータのジョブとなる。リソースグループ・マイグレーションが完了した後、次にリソースグループを再開させることがアドミニストレータのジョブとなる。

MBean構成変更
一実施形態に従うと、アプリケーションが停止するかまたはタイムアウトに達した場合、古いクラスタを削除するためにResourceGroupのターゲット、すなわち仮想ターゲットが更新される。これはマイグレーションプロセスの最終ステップである。

この発明は、この開示の教示に従ってプログラミングされた１つ以上のプロセッサ、メモリおよび／またはコンピュータ読取り可能記憶媒体を含む、１つ以上の従来の汎用または特化型デジタルコンピュータ、コンピューティング装置、マシン、またはマイクロプロセッサを使用して都合よく実現されてもよい。ソフトウェア技術の当業者には明らかであるように、この開示の教示に基づいて、適切なソフトウェアコーディングが、熟練したプログラマによって容易に準備され得る。

実施形態によっては、本発明は、本発明のプロセスのうちいずれかを実行するためにコンピュータをプログラムするのに使用できる命令が格納された非一時的な記録媒体または（１つもしくは複数の）コンピュータ読取可能な媒体であるコンピュータプログラムプロダクトを含む。この記録媒体は、フロッピー（登録商標）ディスク、光ディスク、ＤＶＤ、ＣＤ−ＲＯＭ、マイクロドライブ、および光磁気ディスクを含む、任意の種類のディスク、ＲＯＭ、ＲＡＭ、ＥＰＲＯＭ、ＥＥＰＲＯＭ、ＤＲＡＭ、ＶＲＡＭ、フラッシュメモリデバイス、磁気もしくは光カード、ナノシステム（分子メモリＩＣを含む）、または、命令および／もしくはデータを格納するのに適した任意の種類の媒体もしくはデバイスを含み得るものの、これらに限定されない。

本発明のこれまでの記載は例示および説明を目的として提供されている。すべてを網羅するかまたは本発明を開示された形態そのものに限定することは意図されていない。当業者には数多くの変更および変形が明らかであろう。実施の形態は、本発明の原理およびその実際の応用を最もうまく説明することによって他の当業者がさまざまな実施の形態および意図している特定の用途に適したさまざまな変形を理解できるようにするために、選択され説明されている。本発明の範囲は添付の特許請求の範囲およびそれらの同等例によって規定されるものと意図されている。

Claims (14)

1. アプリケーションサーバ環境においてパーティションマイグレーションをサポートするためのシステムであって、
   １つ以上のコンピュータを含み、前記１つ以上のコンピュータは、ソフトウェアアプリケーションの実行のためのドメインならびに１つ以上のパーティションおよびリソースグループを有するアプリケーションサーバ環境を含み、
   各々のパーティションは、前記ドメインの管理およびランタイム区分を提供し、１つ以上のリソースグループを含み得るとともに、
   各々のリソースグループは、リソースグループテンプレートを参照し得る複数のデプロイ可能なアプリケーションまたはリソースの集合であり、
   各々のリソースグループまたは前記リソースグループを含む前記パーティションは、前記リソースグループまたはパーティションがターゲット設定されてデプロイされるべきであるターゲットを定義する仮想ターゲット情報に関連付けることができ、
   ウェブ層コンポーネントはルーティング情報を含み、前記ルーティング情報は、特定のパーティションのための前記仮想ターゲットをサーバまたはクラスタなどの対応するターゲットにマッピングして、これにより、前記特定のパーティションのための複数の要求が適切なターゲットに向けられるようにする、システム。
2. 前記アプリケーションサーバまたはクラウド環境はＪａｖａ ＥＥアプリケーションサーバを含む、請求項１に記載のシステム。
3. 特定のパーティションがマイグレートされると、セッション情報が元のターゲットと新しいターゲットとの間で複製され、前記ウェブ層コンポーネントには修正されたルーティング情報が与えられ、これにより、前記特定のパーティションのための後続の複数の要求が前記新しいターゲットに向けられるようにする、請求項１または２に記載のシステム。
4. 前記システムは、クラウド環境内で動作する複数のテナントをサポートするために前記クラウド環境内に提供され、
   前記システムは、任意には、１つ以上のパーティションを、テナントによって使用されるように、前記テナントに関連付けることができる、請求項１から３のいずれかに記載のシステム。
5. アプリケーションサーバ環境においてパーティションマイグレーションをサポートするための方法であって、
   １つ以上のコンピュータにおいて、ソフトウェアアプリケーションの実行のためのドメインならびに１つ以上のパーティションおよびリソースグループを有するアプリケーションサーバ環境を提供するステップを含み、
   各々のパーティションは、前記ドメインの管理およびランタイム区分を提供し、リソースグループを含み得るとともに、
   各々のリソースグループは、リソースグループテンプレートを参照し得る複数のデプロイ可能なアプリケーションまたはリソースの集合であり、
   各々のリソースグループまたは前記リソースグループを含む前記パーティションは、前記リソースグループまたはパーティションがターゲット設定されてデプロイされるべきであるターゲットを定義する仮想ターゲット情報に関連付けることができ、
   ウェブ層コンポーネントはルーティング情報を含み、前記ルーティング情報は、特定のパーティションのための前記仮想ターゲットをサーバまたはクラスタなどの対応するターゲットにマッピングして、これにより、前記特定のパーティションのための複数の要求が適切なターゲットに向けられるようにする、方法。
6. 前記アプリケーションサーバまたはクラウド環境はＪａｖａ ＥＥアプリケーションサーバを含む、請求項５に記載の方法。
7. 特定のパーティションがマイグレートされると、セッション情報が元のターゲットと新しいターゲットとの間で複製され、前記ウェブ層コンポーネントには修正されたルーティング情報が与えられ、これにより、前記特定のパーティションのための後続の複数の要求が前記新しいターゲットに向けられるようにする、請求項５または６に記載の方法。
8. 前記方法は、クラウド環境内で動作する複数のテナントをサポートするために前記クラウド環境内で実行され、
   システムは、任意には、１つ以上のパーティションを、テナントによって使用されるように、前記テナントに関連付けることができる、請求項５から７のいずれかに記載の方法。
9. プログラム命令を機械読取り可能フォーマットで含むコンピュータプログラムであって、前記プログラム命令は、コンピュータシステムによって実行されると、前記コンピュータシステムに、請求項５から８のいずれかに記載の方法を実行させる、コンピュータプログラム。
10. 非一時的な機械読取り可能データ記憶媒体に記憶された請求項９に記載のコンピュータプログラムを含むコンピュータプログラムプロダクト。
11. 命令が格納された非一時的なコンピュータ読取り可能記憶媒体であって、前記命令が１つ以上のコンピュータによって読取られて実行されると、前記１つ以上のコンピュータに、
    ソフトウェアアプリケーションの実行のためのドメインならびに１つ以上のパーティションおよびリソースグループを有するアプリケーションサーバ環境を提供するステップを実行させ、
    各々のパーティションは、前記ドメインの管理およびランタイム区分を提供し、リソースグループを含み得るとともに、
    各々のリソースグループは、リソースグループテンプレートを参照し得る複数のデプロイ可能なアプリケーションまたはリソースの集合であり、
    各々のリソースグループまたは前記リソースグループを含む前記パーティションは、前記リソースグループまたはパーティションがターゲット設定されてデプロイされるべきであるターゲットを定義する仮想ターゲット情報に関連付けることができ、
    ウェブ層コンポーネントはルーティング情報を含み、前記ルーティング情報は、特定のパーティションのための前記仮想ターゲットをサーバまたはクラスタなどの対応するターゲットにマッピングして、これにより、前記特定のパーティションのための複数の要求が適切なターゲットに向けられるようにする、非一時的なコンピュータ読取り可能記憶媒体。
12. 前記アプリケーションサーバまたはクラウド環境はＪａｖａ ＥＥアプリケーションサーバを含む、請求項１１に記載の非一時的なコンピュータ読取り可能記憶媒体。
13. 特定のパーティションがマイグレートされると、セッション情報が元のターゲットと新しいターゲットとの間で複製され、前記ウェブ層コンポーネントには修正されたルーティング情報が与えられ、これにより、前記特定のパーティションのための後続の複数の要求が前記新しいターゲットに向けられるようにする、請求項１１または１２に記載の非一時的なコンピュータ読取り可能記憶媒体。
14. 前記アプリケーションサーバ環境は、クラウド環境内で動作する複数のテナントをサポートするために前記クラウド環境内に提供され、
    システムは、任意には、１つ以上のパーティションを、テナントによって使用されるように、前記テナントに関連付けることができる、請求項１１から１３のいずれかに記載の非一時的なコンピュータ読取り可能記憶媒体。

Images