JP2017528846A - マルチテナントアプリケーションサーバ環境においてグローバルランタイムを使用するためのシステムおよび方法 - Google Patents

Abstract

実施形態に従うと、マルチテナントアプリケーションサーバ環境においてエンドツーエンドライフサイクルを提供するためのシステムおよび方法が本願明細書において記載される。ライフサイクルマネージャは、たとえばアプリケーションサーバ、トラフィックディレクタまたはロードバランサ、および、データベースまたは他のコンポーネントといった、自身のパーティションに特有の構成を有し得る異なるコンポーネントにわたる構成インテグレーションを可能にする。実施形態に従うと、エンドツーエンドライフサイクルインフラストラクチャは、マルチテナントアプリケーションサーバ環境内の異なるコンポーネントが自身のコンポーネントに特有のライフサイクル機能を提供するよう、ライフサイクルプラグインを使用することを可能にするプラグインベースのメカニズムを含む。実施形態に従うと、システムは、あるサービスのためのテナントを特定のパーティションにオンボードするのに使用され得るテナントオンボーディング機能のためのサポートを含む。実施形態に従うと、システムは、マルチテナントアプリケーションサーバ環境内のグローバルランタイムの使用をサポートする。

Description

著作権表示
この特許文献の開示の一部は、著作権保護の対象となる題材を含んでいる。著作権の所有者は、特許商標庁の包袋または記録に掲載されるように特許文献または特許情報開示を誰でも複製できることに対して異議はないが、その他の点ではすべての如何なる著作権をも保有する。

関連出願の優先権主張および相互参照
この出願は、「マルチテナントアプリケーションサーバ環境においてエンドツーエンドライフサイクルを提供するためのシステムおよび方法（SYSTEM AND METHOD FOR PROVIDING END-TO-END LIFECYCLE IN A MULTITENANT APPLICATION SERVER ENVIRONMENT）」という名称を有する２０１４年９月２５日に出願された米国仮出願番号第６２／０５５，５７５号と、「マルチテナントアプリケーションサーバ環境におけるテナントオンボーディングのためのシステムおよび方法（SYSTEM AND METHOD FOR TENANT ONBOARDING IN A MULTITENANT APPLICATION SERVER ENVIRONMENT）」という名称を有する２０１４年９月２５日に出願された米国仮出願番号第６２／０５５，５７７号と、「マルチテナントアプリケーションサーバ環境におけるデータベースおよびアプリケーションサーバライフサイクルブラグインのためのシステムおよび方法（SYSTEM AND METHOD FOR DATABASE AND APPLICATION SERVER LIFECYCLE PLUGINS IN A MULTITENANT APPLICATION SERVER ENVIRONMENT）」という名称を有する２０１４年９月２６日に出願された米国仮出願番号第６２／０５５，８５６号と、「マルチテナントアプリケーションサーバ環境におけるグローバルランタイムのためのシステムおよび方法（SYSTEM AND METHOD FOR GLOBAL RUNTIME IN A MULTITENANT APPLICATION SERVER ENVIRONMENT）」という名称を有する２０１４年９月２６日に出願された米国仮出願番号第６２／０５６，４２７号とに対する優先権の利益を請求し、「アプリケーションサーバ、クラウド、または他の環境においてマルチテナンシをサポートするためのシステムおよび方法（SYSTEM AND METHOD FOR SUPPORTING MULTI-TENANCY IN AN APPLICATION SERVER, CLOUD, OR OTHER ENVIRONMENT）」という名称を有する２０１５年１月２１日に出願された米国特許出願番号第１４／６０１，８８３号に関連する。上記の出願の各々は本願明細書において参照により援用される。

発明の分野
本発明の実施形態は一般にアプリケーションサーバおよびクラウド環境に関し、特定的には、マルチテナントアプリケーションサーバ環境においてエンドツーエンドライフサイクル、テナントオンボーディング（tenant onboarding）、またはグローバルランタイムを提供するためのシステムおよび方法に関する。

背景
アプリケーションサーバは、概して、ソフトウェアアプリケーションをデプロイして実行することができる管理されたコンピューティング環境を提供する。クラウドベースのコンピューティング環境は、クラウドによって提供される分散型リソース内でアプリケーションを実行して、当該分散型リソースを利用することを可能にする。このような環境は、多くのユーザまたはテナントをサポートすることができ、それらのうちのいくつかは、そのユーザまたはテナントに特有の特定条件を有する可能性がある。付加的なテナントがシステムに追加される場合、システムは、各テナントのニーズに対応することができなければならない。当該ニーズは必要に応じてテナントに他のシステムコンポーネントを関連付けることを含む。これらは、本発明の実施形態が使用可能となる環境のタイプのいくつかの例に該当する。

概要
実施形態に従うと、マルチテナントアプリケーションサーバ環境においてエンドツーエンドライフサイクルを提供するためのシステムおよび方法が本願明細書において記載される。ライフサイクルマネージャは、たとえばアプリケーションサーバ、トラフィックディレクタまたはロードバランサ、および、データベースまたは他のコンポーネントといった、自身のパーティションに特有の構成を有し得る異なるコンポーネントにわたる構成インテグレーションを可能にする。実施形態に従うと、エンドツーエンドライフサイクルインフラストラクチャは、マルチテナントアプリケーションサーバ環境内の異なるコンポーネントが自身のコンポーネントに特有のライフサイクル機能を提供するよう、ライフサイクルプラグインを使用することを可能にするプラグインベースのメカニズムを含む。実施形態に従うと、システムは、あるサービスのためのテナントを特定のパーティションにオンボードするのに使用され得るテナントオンボーディング機能のためのサポートを含む。実施形態に従うと、システムは、マルチテナントアプリケーションサーバ環境内のグローバルランタイムの使用をサポートする。

実施形態に従ったマルチテナントアプリケーションサーバ環境を示す図である。 実施形態に従ったマルチテナントアプリケーションサーバ環境をさらに示す図である。 実施形態に従ったマルチテナントアプリケーションサーバ環境をさらに示す図である。 実施形態に従ったマルチテナントアプリケーションサーバ環境をさらに示す図である。 実施形態に従ったマルチテナントアプリケーションサーバ環境をさらに示す図である。 実施形態に従った、マルチテナントアプリケーションサーバ環境におけるエンドツーエンドライフサイクルを示す図である。 実施形態に従った、マルチテナントアプリケーションサーバ環境におけるエンドツーエンドライフサイクルイベント図を示す図である。 実施形態に従った、マルチテナントアプリケーションサーバ環境におけるエンドツーエンドライフサイクルトポロジを示す図である。 実施形態に従った、マルチテナントアプリケーションサーバ環境における別のエンドツーエンドライフサイクルトポロジを示す図である。 実施形態に従った、マルチテナントアプリケーションサーバ環境においてエンドツーエンドライフサイクルを提供するための方法のフローチャートを示す図である。 実施形態に従った、マルチテナントアプリケーションサーバ環境におけるテナントオンボーディングを示す図である。 実施形態に従った、マルチテナントアプリケーションサーバ環境におけるテナントオンボーディングをさらに示す図である。 実施形態に従った、マルチテナントアプリケーションサーバ環境においてテナントオンボーディングを提供するための方法のフローチャートを示す図である。 実施形態に従った、マルチテナントアプリケーションサーバ環境におけるライフサイクルプラグインを示す図である。 実施形態に従った、マルチテナントアプリケーションサーバ環境におけるライフサイクルプラグインをさらに示す図である。 実施形態に従った、マルチテナントアプリケーションサーバ環境においてライフサイクルプラグインをサポートするための方法のフローチャートを示す図である。 実施形態に従った、マルチテナントアプリケーションサーバ環境におけるグローバルランタイムの使用を示す図である。 実施形態に従った、マルチテナントアプリケーションサーバ環境におけるグローバルランタイムの使用をさらに示す図である。 実施形態に従った、マルチテナントアプリケーションサーバ環境においてグローバルランタイムをサポートするための方法のフローチャートを示す図である。

詳細な説明
実施形態に従うと、マルチテナントアプリケーションサーバ環境におけるエンドツーエンドライフサイクルを提供するためのシステムおよび方法が本願明細書において記載される。ライフサイクルマネージャは、たとえばアプリケーションサーバ、トラフィックディレクタまたはロードバランサ、および、データベースまたは他のコンポーネントといった、自身のパーティションに特有の構成を有し得る異なるコンポーネントにわたる構成インテグレーション（統合）を可能にする。

実施形態に従うと、エンドツーエンドライフサイクルインフラストラクチャは、マルチテナントアプリケーションサーバ環境内の異なるコンポーネントが自身のコンポーネントに特有のライフサイクル機能を提供するよう、ライフサイクルプラグインを使用することを可能にするプラグインベースのメカニズムを含む。

実施形態に従うと、システムは、あるサービスのためのテナントを特定のパーティションにオンボードするのに使用され得るテナントオンボーディング機能のためのサポートを含む。

実施形態に従うと、システムは、マルチテナントアプリケーションサーバ環境内のグローバルランタイムの使用をサポートする。

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

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

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

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

一般に、システムアドミニストレータは、パーティションと、ドメインレベルリソースグループおよびリソースグループテンプレートと、セキュリティ領域（security realm）を定義し得る。その一方、パーティションアドミニストレータは、たとえば、パーティションレベルリソースグループを作成し、パーティションにアプリケーションをデプロイし、または、当該パーティションのために特定の領域を参照することによって、自身のパーティションの局面を定義し得る。

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

図２に示されるように、一実施形態に従うと、パーティション２０２は、たとえば、リソースグループテンプレート２１０の参照２０６を含むリソースグループ２０５と、仮想ターゲット（たとえば仮想ホスト）情報２０７と、プラガブルデータベース（ＰＤＢ：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データベースを含むそれぞれのリソース３２４，３３４とに接続するためのものである。同じアプリケーションコードが両方のデータベースに対して実行され得るので、データベースインスタンスは互換性のあるスキーマを用いることができる。システムがパーティションを始動させると、当該システムは、それぞれのデータベースインスタンスに対する接続プールおよび仮想ターゲットを作成することができる。

エンドツーエンドライフサイクル
実施形態に従うと、本願明細書において、マルチテナントアプリケーションサーバ環境におけるエンドツーエンドライフサイクルを提供するためのシステムおよび方法が記載される。ライフサイクルマネージャは、たとえばアプリケーションサーバ、トラフィックディレクタまたはロードバランサ、および、データベースまたは他のコンポーネントといった、自身のパーティションに特有の構成を有し得る異なるコンポーネントにわたる構成インテグレーションを可能にする。

さまざまな実施形態に従うと、本願明細書において提供されるエンドツーエンドライフサイクルプロセスの記載のうちのいくつかは以下の用語を使用する。

テナンシ（Tenancy）：限定された持続期間の間テナントによって典型的に得られる、当該テナントがシステムの挙動をそれらのニーズに適するようにある程度までカスタマイズすることを可能にするようにシステムのコンポーネントを使用する権利。

テナンシコンテキスト（Tenancy context）：請求書を生成するといったようなテナント特有の挙動をシステムが提供するためにテナンシコンテキストを使用することができるようにシステムのテナンシを決定するために使用される、たとえばセキュリティ、命名またはクラスローディング情報といったコンテキスト情報。

パーティションコンテキスト（Partition context）：システムがプラットフォームテナンシを決定するために使用し得る、実行の現在のスレッドに関連付けられるパーティション識別子（ＩＤ）。

リソーステナンシ（Resource tenancy）：オラクルフュージョンミドルウェア（ＦＭＷ： Fusion Middleware）／フュージョンアプリケーション（ＦＡ：Fusion Application）の実施形態を説明する際に主に用いられる「テナンシ」と同様のプロパティ。

ＭＴアドミンコード（MT admin code）：任意のテナントがマルチテナントシステムに対してオンボードされる前にデプロイおよび始動されるとともに、システムのライフサイクル管理およびテナントランタイムを担うコード。

ＭＴアドミンランタイム（MT admin runtime）：ＭＴアドミンコードのランタイム表示。

テナントコード：あるテナントについて具体的にデプロイされるコード。
テナントランタイム：テナントコードのランタイム表示。

レイヤードプロダクト（Layered product）：マルチテナントアプリケーションサーバ環境と共同動作するか、または、そうでなければマルチテナントアプリケーションサーバ環境を利用し得るソフトウェアプロダクト。その例には、ＦＭＷおよびＦＡファミリのプロダクトが含まれ得る。

図６は、実施形態に従ったマルチテナントアプリケーションサーバ環境におけるエンドツーエンドライフサイクルを示す。

図６に示されるように、実施形態に従うと、システムはライフサイクルコーディネーションフレームワーク４００を含み得る。ライフサイクルコーディネーションフレームワーク４００は、ライフサイクルマネージャ（ＬＣＭ）４１０およびライフサイクルインターフェイス４１１を含み、これにより、マルチテナントアプリケーションサーバ環境内での使用のために、たとえばトラフィックディレクタコンポーネント４１４、データベースコンポーネント４１５または他のタイプのコンポーネント４１６といった、パーティションおよび他のコンポーネントのライフサイクル管理４１２が可能になる。

たとえば、システムは、アプリケーションサーバ（たとえばＷｅｂＬｏｇｉｃ，ＷＬＳ）コンポーネントがマルチテナント認識型となるとともにアプリケーションサーバ内のパーティションの使用をサポートすることを可能にすることに加えて、他のコンポーネントおよびプロダクトがアプリケーションサーバパーティションと共同動作し得ることを保証することができなければならない。たとえば、データベース（たとえばオラクルデータベース（Oracle Database），ＤＢ）およびトラフィックディレクタまたはロードバランサ（たとえばオラクルトラフィックディレクタ（Oracle Traffic Director），ＯＴＤ）のインスタンスが適切に構成され、その後同様にそれらのパーティションをサポートし得ることを保証することができなければならない。

これに対応するために、実施形態に従うと、システムは、アプリケーションサーバとの使用のためにパーティションを作成する一部として、アプリケーションサーバパーティションを作成することに加えて、アプリケーションサーバパーティションに最終的に接続（wired up）されることになる他のコンポーネントにおけるランタイムのスライスの作成を可能にする。その結果は、たとえばＯＴＤレイヤーからデータベースレイヤーまでアプリケーションが完全に自身の環境内に実行され得るシステムである。

実施形態に従うと、エンドツーエンドライフサイクルインフラストラクチャは、マルチテナントアプリケーションサーバ環境内の複数の異なるコンポーネントが自身のコンポーネントに特有のライフサイクル機能を提供するよう、ライフサイクルプラグインを使用することを可能にするプラグインベースのメカニズムを含む。パーティションと接続されるように利用可能になる任意のコンポーネントは、自身のプラグインを提供し得る。ライフサイクルオペレーションがプラグインインターフェイスを呼び出し、これにより、たとえば、トラフィックディレクタインスタンスの作成またはデータベースインスタンスの作成といったコンポーネントの実際の作成を適切なように実行する。

実施形態に従うと、アプリケーションサーバおよび／またはコンポーネントパーティションを作成することに加えて、各テナントは、さらに以下に記載されるように環境に関連付けられ得る。当該環境は、パーティションのテナントが自身のアプリケーションを実行し得るコンテナまたはコンテナオブジェクトとして機能する。

たとえば、実施形態に従うと、ライフサイクルマネージャおよびそのプラガブル拡張可能メカニズムが、ミドルウェアまたはデータベーススタック内のコンポーネントの作成をサポートし、かつ、データソースを使用するためにアプリケーションサーバ（たとえばＷＬＳ）パーティションを接続することといったように、それらのコンポーネントの接続をサポートするために使用され得る。その後、接続されたコンポーネントの集合がパーティションまたはテナントの環境内に提供され得る。

別の例として、実施形態に従うと、システムは、アプリケーションサーバパーティションがデータベースに関連付けられるとともにライフサイクル中に作成されることを可能にし得、これにより、アプリケーションサーバパーティションにおいてデータソースを作成し、パーティションまたはテナントの環境内で使用可能にする。

同様に、実施形態に従うと、ライフサイクルマネージャは、クラスタにおいて実行されるＷＬＳパーティションがＯＴＤインスタンスによりフロントエンド（front-ended）となり、テナント環境内の使用のために、ライフサイクルマネージャが当該パーティションのためのＯＴＤインスタンスの作成と、ＷＬＳパーティションに対するその接続とを可能にするように、パーティションのためのＯＴＤルーティングをセットアップするために使用され得る。当該セットアップは、パーティションとの使用のためのＵＲＩまたはホスト名をセットアップすることを含む。

エンドツーエンドライフサイクル管理によって提供される付加的な利点は、アウトオブバンド（out-of-band）で変化を検出する能力を含む。

たとえば、アプリケーションサーバパーティションに対する更新は、そのパーティションに接続される他のコンポーネントに送られ得る。別の例として、新しいリソースグループが新しいターゲットに関連付けられている場合、当該更新された情報は、パーティションにおける変化が任意の他の接続されたコンポーネントに伝播されるように、他のレイヤードプロダクトに送られ得る。

実施形態に従うと、ライフサイクルのオーケストレーションは、さまざまなコンポーネントまたはランタイムのスライスを作成するためにさまざまな態様で実行され得る。たとえば、システムは個々に、ライフサイクルマネージャへのＲＥＳＴコールとしてパーティション、ＰＤＢ、および、ＯＴＤインスタンスを作成し得、これにより、ライフサイクルマネージャに、たとえば、ＷＬＳパーティション、ＯＴＤインスタンス、または他のコンポーネントのスライスを作成させる。オーケストレーション中に、障害が発生すれば、システムは、たとえばＲＥＳＴエンドポイントをそのアーティファクトの関連付けおよびオーケストレーションのために再び試みることによって、障害に対応し得る。

例示的なエンドツーエンドライフサイクルのユースケースは、クラスタ内においてアドミンサーバ上にライフサイクルマネージャを提供すること、および／または、クラスタ内において管理されたサーバ上に他のライフサイクルマネージャを提供することを含む。たとえば、単一のドメインにおいて、単一のライフサイクルマネージャがアドミンサーバ上に提供され得る。ライフサイクルマネージャがたとえば複数のサーバ上で複数のＯＴＤインスタンスを管理することができる複数のドメインまたは高可用性要件モデルの場合、ライフサイクルマネージャは、ロードバランサによってフロントエンドとされるクラスタ内で実行され得、そのドメインからライフサイクルマネージャは複数のランタイムを管理し得る。

実施形態に従うと、エンドツーエンドライフサイクル構成情報は、たとえば単一のドメインモードにおいてはＸＭＬファイルに保存され得、または、高可用性モードにおいてはより典型的にはデータベースに保存され得る。

実施形態に従うと、ライフサイクルマネージャは、登録ランタイムとの使用のためにコールをたとえばＲＥＳＴを介して受信することに応答して、コールの詳細から意図されるパーティションを決定し、そのコールが作成することを試みているものに基づいて、１つ以上の適切なプラグインを呼び出すことにより、自身が特定のパーティションに代わって動作しているということを認識し得る。

たとえば、コールがパーティションのためにＰＤＢを作成することに向けられる場合、ライフサイクルマネージャは、データベースライフサイクルプラグインを呼び出すことにより応答し得るか、または、コールがパーティションについてＯＴＤインスタンスを作成することに向けられる場合、ライフサイクルマネージャはＯＴＤライフサイクルプラグインなどを呼び出すことにより応答し得る。

単一ドメイン複数パーティション環境において、ライフサイクルマネージャ機能を提供していたアドミンサーバが障害を起こした場合、システムは、従来のアプリケーションサーバ（たとえばＷＬＳ）サーバ環境のように動作し続けることができるが、その運用および管理機能がある期間の間に無効にされる場合がある。

実施形態に従うと、当該システムは、サービスとしてコントラクト（contract）およびそれらのコントラクトのインプリメンテーションをルックアップするために依存性注入メカニズム（dependency injection mechanism）としてＨＫ２を使用し得る。たとえば、ＨＫ２を使用して、サービスはコンポーネントへ注入可能になり得、ひとたび注入されると、それらのＨＫ２オブジェクトは他のクラスの依存性を満たし得る。ライフサイクルプラグインはＨＫ２サービスとして実現され得、ランタイムにてそれらのコントラクトを実現し得る。システムは、サービスとしてプラグインされている適切なプラグインを発見するようコントラクトをルックアップし得る。

たとえば、実施形態に従うと、システムは、パーティションプラグインコントラクト、ランタイムプラグイン、または、他のコントラクトを認識し得る。各パーティションまたは他のプラグインは、そのコンポーネント内のパーティションまたはパーティションのスライスをどのように作成するかについての理解により、構成され得る。そのため、たとえば、データベースパーティションプラグインは、データベースのスライスを作成するためにどのように動作するかについての理解により、構成され得る。

実施形態に従うと、システムはコール中に必要とされるタイプオブサービス（type of service）（たとえば「type=database」）に関して指示を受信し得、この場合、使用されるべき適切なデータベースプラグインを決定し得る。

同様に、実施形態に従うと、アプリケーションサーバ（たとえばＷＬＳ）およびトラフィックディレクタ（たとえばＯＴＤ）コンポーネントのために、プラグインは、サービスとして実現され得るそれらのコンポーネントについて提供され得、その後、パーティションの作成中または構成中に使用される。

ＨＫ２のようなメカニズムはさらに、たとえばデフォルトストアまたは永続性タイプによってＸＭＬに格納される構成モデルを定義するために使用され得る構成管理のためのサポートを提供する。

実施形態に従うと、構成オブジェクトは、パーティションとの使用のための特定のコンポーネントについて属性を定義するよう使用され得る。これらのオブジェクトは同様に注入可能であり、これにより、たとえば構成オブジェクトを注入しそのパーティションについて情報をルックアップすることによって所与のパーティションの構成情報をルックアップすることが可能になる。

環境
実施形態に従うと、異なるコンポーネントにわたるパーティションのセットは、テナントのニーズを満たすまとまりのある単位（cohesive unit）を形成するよう、環境として一緒にリンクされ得る。環境は、各タイプの１つより多いパーティションを有し得るが、典型的に、各タイプのパーティションのうちの１つのみを有することになる。たとえば、ＦＡシナリオにおいて、マルチドメイントポロジにおけるドメインの各々からの１つより多いＷＬＳパーティションが存在し得る。そのようなシナリオにおいて、サポートされなければならないＷＬＳおよびＯＴＤとデータベースとの間に複数の関連性があり得る。

コンポーネント／ランタイム
実施形態に従うと、コンポーネントまたはランタイムは、たとえばＯＴＤ、ＷＬＳ、コヒーレンスまたはデータベースコンポーネントといったソフトウェアコンポーネントである。他の実施形態に従うと、付加的なタイプのソフトウェアコンポーネントもサポートされ得る。

ライフサイクルマネージャ
実施形態に従うと、ライフサイクルマネージャは、たとえばアプリケーションサーバ、トラフィックディレクタまたはロードバランサ、および、データベースまたは他のコンポーネントといった、自身のパーティションに特有の構成を有し得る異なるコンポーネントにわたる構成インテグレーションを可能にする。ライフサイクルマネージャは、ライフサイクル構成を作成し、それらの構成を更新し、それらの構成を閲覧し、環境にわたってそれらの構成を破棄するよう、クライアントに対してローカルＡＰＩおよび／またはＲＥＳＴアクセスを提供するライブラリとして実現され得る。

ライフサイクルプラグイン
実施形態に従うと、ライフサイクルプラグインは、ライフサイクルマネージャと、たとえばＯＴＤ、ＷＬＳ、コヒーレンスまたはデータベースコンポーネントといったコンポーネントとの間のブリッジを提供するソフトウェアモジュールである。ライフサイクルプラグインは、ＨＫ２サービスとしてランタイムプラグインおよびパーティションプラグイン（サポートされている場合）インターフェイスを実現するクラスを含み得、これにより、ライフサイクルプラグインが、構成変更トランザクションおよび通知イベントに参加し、コンポーネントにおいてそのアクティビティを反映するよう適切などのようなアクションでも実行することを可能になる。プラグインＡＰＩは一般に、ランタイムまたはパーティションについて実際のライフサイクルオペレーションを実行するために使用される下位プロトコルを認識しない（agnostic）。プラグインのインプリメンテーションは、必要なオペレーションを実行するためにどのようにランタイムに接続するかを選択し得る。たとえば、実施形態に従うと、quiesce、scaleUpまたはscaleDownのようなオペレーションがランタイムマネージャを介してランタイム上で開始されると、ランタイムタイプに対応するランタイムプラグインのインプリメンテーションがＨＫ２を介してルックアップされ得、適切なアクションを行うために、ランタイムプラグイン（たとえばRuntimePlugin）インプリメンテーションの対応するメソッドがランタイムプラグインについて呼び出される。

クライアント
実施形態に従うと、クライアントとは、たとえばＲＥＳＴ ＡＰＩを介してライフサイクルマネージャと相互作用するライフサイクルマネージャの任意のクライアントを指し、または、埋込み型の場合にはＪａｖａ ＡＰＩを介してライフサイクルマネージャと相互作用するライフサイクルマネージャの任意のクライアントを指す。クライアントの例は、オラクルフュージョンミドルウェアコントロール（ＦＭＷＣ：Fusion Middleware Control）およびエンタープライズマネージャクラウド制御（ＥＭＣＣ：Enterprise Manager Cloud Control）、ならびに、カールベースのスクリプト（curl-based script）を含む。実施形態に従うと、ライフサイクルマネージャＲＥＳＴ ＡＰＩは、コンポーネントにわたってパーティション構成をプロビジョニングおよび更新する場合、エンタープライズマネージャ（Enterprise Manager）のようなプロダクト内で使用され得る。

ライフサイクルユースケース
実施形態に従うと、以下はライフサイクルユースケースの例である。１．パーティションの作成、削除および更新を含むコンポーネントについてのパーティションＣＲＵＤオペレーション。
２．ランタイムの登録、登録されたランタイムに対する更新、およびランタイムの登録抹消を含む、コンポーネントのためのランタイムオペレーション。
３．２つのパーティションを関連付けることによりランタイムの２つのスライス（たとえばＷＬＳを有するデータベースまたはＷＬＳを有するＯＴＤ）をこれら２つが一緒に使用され得るように接続するような、異なるコンポーネントにわたるパーティションの関連付け。

ライフサイクルインタラクション
図７は、実施形態に従った、マルチテナントアプリケーションサーバ環境においてエンドツーエンドライフサイクルイベント図を示す。

図７に示されるように、実施形態に従うと、ライフサイクルマネージャは、アプリケーションサーバ（たとえばＷＬＳ）ライフサイクルプラグイン４２０、トラフィックディレクタ（たとえばＯＴＤ）ライフサイクルプラグイン４２２、データベース（たとえばオラクルデータベース）ライフサイクルプラグイン４２４、および／または、インメモリデータグリッド（たとえばコヒーレンス）ライフサイクルプラグイン４２６といった、１つまたは複数のプラグインに関連付けられるコンポーネントのオーケストレーションを可能にし得る。

実施形態に従うと、ライフサイクルマネージャは、環境４３０を作成する要求を（任意の関連付けられるメタデータと一緒に）受信することに応答して、さまざまなコンポーネントパーティションの作成および関連付けをオーケストレーションし、その後使用するべきテナントについての環境４３２を返す。

図８は、実施形態に従った、マルチテナントアプリケーションサーバ環境においてエンドツーエンドライフサイクルトポロジを示す。

図８に示されるように、実施形態に従うと、簡易または単一のドメイン使用は、１つ以上のクライアント４４０、アドミンサーバ４５０、管理されるサーバ４５２（ここではＭＳ１、ＭＳ２およびＭＳ３として示される）のクラスタ、データベース４５４、および、トラフィックディレクタ／ロードバランサ４６０を含み得る。その場合、ライフサイクルマネージャは、ＯＴＤ、データベースおよびコヒーレンスのような他のコンポーネントと共に、自身が管理するドメインにおいて実行されている。

このシナリオにおいて、エンドツーエンドライフサイクル構成はＸＭＬファイルに格納され得、ランタイムにおいてテナンシを確立するために、管理されているサーバ上で利用可能になる。ライフサイクルマネージャは、アドミンサーバ上で実行され任意の付加的なセットアップを必要としないいくつかのアプリケーションサーバ環境において追加設定なし（out-of-the-box）で有効化され得る。

図９は、実施形態に従った、マルチテナントアプリケーションサーバ環境において別のエンドツーエンドライフサイクルトポロジを示す。

図９に示されるように、ライフサイクルマネージャが多くのコンポーネントを管理しており高可用性要件を有し得るエンタープライズデプロイメントにおいてエンタープライズマネージャ（ＥＭ：Enterprise Manager）を使用するＦＡプロビジョニングのようなより複雑な実施形態およびシナリオに従うと、ライフサイクルマネージャは、各々がライフサイクルマネージャ機能４７３，４７５，４７７を有する複数のＥＭ／ＦＡプロビジョニングインスタンス４７２，４７４，４７６として、別個のライフサイクルマネージャクラスタ／ドメイン４７１において実行され得る。

実施形態に従うと、ライフサイクルマネージャドメインは、管理されたサーバ（ここでＭＳ１、ＭＳ２およびＭＳ３として示される）のクラスタ４９２を有するドメイン４９０といった他のドメインまたはコンポーネントを管理するために使用され得る。

このシナリオにおいて、ライフサイクルマネージャはライフサイクルマネージャクラスタにおける管理されたサーバ上で実行され得、エンドツーエンドライフサイクル構成はデータベースにおいて永続化され得るので、情報に対するアクセスを必要とする任意のドメインまたはランタイムはその情報を得るためにデータベースにアクセスすることができる。

上記のトポロジの両方において、ライフサイクル内において管理され得るコンポーネントは、ライフサイクルマネージャに登録されるライフサイクルプラグインによって決定されることになる。ライフサイクルマネージャは、構成および作成に加えて、適切なようにランタイムのスケーリングのための弾力性（エラスティシティ）機能をサポートし得る。

ライフサイクルランタイム
実施形態に従うと、ライフサイクルランタイム（たとえばLifecycleRuntime）は、ＷＬＳ、ＯＴＤまたはデータベースのようなコンポーネントまたは管理されるサービスを表わす。ライフサイクルマネージャは、ランタイムプラグインのインスタンスがコンポーネントによって実現される場合、ライフサイクルランタイムを管理し得る。ランタイムプラグインは、ライフサイクルマネージャを介して管理されているランタイム上で実行され得る作成オペレーション、削除オペレーション、更新オペレーション、スケーリングアップオペレーション、スケーリングダウンオペレーション、および静止（quiescing）オペレーションといったオペレーションを可能にするインプリメンテーションを提供する。ランタイムは、ライフサイクルマネージャを介して作成され得るか、または、ランタイムマネージャにおけるレジスタランタイム（たとえばregisterRuntime）メソッドを介してライフサイクルマネージャによる使用のためにアウトオブバンドで作成されていれば、ライフサイクルマネージャに登録され得るかのいずれかである。

ランタイム上で任意のオペレーションを実行するためには、ランタイムのインスタンスがルックアップされなければならない。実施形態に従うと、ライフサイクルランタイムのインスタンスは、以下に記載されるように所与のランタイムタイプについてランタイムマネージャを使用してルックアップされ得る。パーティション（ランタイムのスライス）の使用をサポートする管理されたサービスを表わすライフサイクルランタイムは、ライフサイクルランタイム上でのそのパーティションについてのＣＲＵＤオペレーションを可能にする。

実施形態に従うと、ライフサイクルランタイムをルックアップした後にパーティションを作成するために、選択されたランタイム上でパーティションを作成するよう、ライフサイクルランタイムのパーティション作成（たとえばcreatePartition）メソッドが使用され得る。パーティションが作成される態様は、ライフサイクルランタイムのためのパーティションプラグインがランタイムタイプについてＨＫ２サービスとしてルックアップされ、パーティションプラグイン上の対応する作成メソッドが呼び出されるような態様である。

ランタイムマネージャ
実施形態に従うと、ランタイムマネージャ（たとえばRuntimeManager）は、ランタイムを管理するために使用されるシングルトンＨＫ２サービス（singleton HK2 service）として提供され得る。ランタイムマネージャは、そのＪＶＭ上のすべてのランタイムのライフサイクルを管理することになる１つのＪａｖａ仮想マシン（ＪＶＭ：Java virtual machine）ごとに提供され得る。ランタイムは、ランタイムマネージャを使用して作成または登録され得る。ランタイムマネージャはさらに、ランタイムの作成、削除、更新、スケールアップ、スケールダウンおよび静止（クエーシング）を行うオペレーションを提供する。ランタイムマネージャは、そのランタイムタイプについてＨＫ２サービスとしてランタイムプラグインをルックアップし、プラグイン上で対応するオペレーションを呼び出す。

実施形態に従うと、ひとたびランタイムマネージャが所与のランタイムタイプについてルックアップされると、そのランタイムマネージャのスケールアップおよびスケールダウンオペレーションが、特定されたランタイムについて呼び出され得る。ランタイムマネージャは、サービスについて対応するランタイムプラグインをルックアップし、スケールアップまたはスケールダウンオペレーションを呼び出す。このランタイムサポートは、エラスティックなユースケースに対応するために特に有用である。

実施形態に従うと、ランタイムマネージャは、ランタイムとの使用のために以下のオペレーションを提供する。

実施形態に従うと、以下の擬似コードは、あらかじめ作成されたＷＬＳランタイムおよびデータベースランタイムがどのようにライフサイクルマネージャに登録され、次いで、ランタイム上でパーティションを作成するためにライフサイクルマネージャによってその後に使用されるかを示す。

ランタイムの静止
実施形態に従うと、ランタイムの静止／グレースフルシャットダウン（graceful shutdown）のサポートを含み得るＷＬＳのようなコンポーネントは、ランタイムプラグインにおける静止サポートを実現することによってライフサイクルマネージャを介して静止能力をサポートし得る。ランタイムを静止することは異なるフェーズを有し得る。そのようなシナリオにおいて、ランタイムプラグインの静止メソッドは、一回より多く呼び出され得、静止メソッドにおけるフェーズパラメータを介して静止フェーズを示す。

たとえば、サーバがその静止フェーズを始めていることを示しており、したがって静止されているサーバへ転送される新しい要求はないことを通知する「start_quiesce」フェーズが存在し得る。静止がなされた後、その後のコールは、サーバがここで再び新しい要求を受け入れ始める準備ができていることを示す「end_quiesce」フェーズを有することになる。コンポーネントが付加的なフェーズをサポートする場合、それらのフェーズは、完全な機能を保証するようランタイムプラグインによってサポートされ得る。

「start_quiesce」、「end_quiesce」は、コンポーネントがサポートし得るフェーズの例であり、すべてのコンポーネントがサポートしなければならないフェーズの標準リストではない。コンポーネントが静止をサポートしない場合、UnsupportedOperationExceptionが投入されなければならない。コンポーネントがフェーズをサポートしない場合、ヌル値は、静止メソッドに渡される有効な値である。

ランタイムスケーリング
マルチテナント環境の利点のうちの１つは、複数のアプリケーションおよびユーザグループにわたってハードウェア、リソースおよびサービスを共有することであり、これにより、規模の経済性が達成されるとともに、これらのユーザの必要性が時間にわたって変化する際に、キャパシティを割り当てることにおけるフレキシビリティをアドミニストレータが有することが可能になる。

実施形態に従うと、ライフサイクルマネージャＡＰＩは、ランタイムをスケールアップおよびスケールダウンすることが可能であるように、他のエラスティシティフレームワークについての能力を提供する。ランタイムマネージャおよびランタイムプラグインは、ランタイムをスケーリングするよう呼び出すためにユーザにスケールアップおよびスケールダウンメソッドを提供する。

実施形態に従うと、スケールアップまたはスケールダウンがランタイムマネージャにおいて呼び出されると、ランタイムタイプに対応するランタイムプラグインがルックアップされ、スケーリングオペレーションはランタイムプラグインのインスタンス上で呼び出される。コンポーネントがスケーリングオペレーションをサポートしない場合、ランタイムプラグインのインプリメンテーションは、UnsupportedOperationExceptionを投入しなければならない。

ランタイムプラグインインプリメンテーション
実施形態に従うと、ランタイムプラグインについての擬似コードが以下に示される（読みやすさのためこの例はすべての抽象メソッド（abstract method）を実現するわけではない）。

パーティションプラグイン
実施形態に従うと、パーティションをサポートするランタイム（たとえばＷＬＳ、１２ｃデータベースなどのようなランタイムのスライス）は、パーティションプラグインのインプリメンテーションを提供しなければならない。createPartitionのようなランタイム上のオペレーションが呼び出される場合、ランタイムタイプに対応するパーティションプラグインのインプリメンテーションはＨＫ２サービスとしてルックアップされ、対応する作成メソッドがパーティションプラグインインプリメンテーションクラス上で呼び出されることになる。ランタイムに接続しランタイムのスライスを作成することはインプリメンテーションクラス次第である。ひとたび作成されると、当該パーティションはライフサイクルマネージャに登録され、lifecycle-config.xmlにおいて永続化される。実施形態に従うと、ランタイムはパーティションについて以下の関数を提供する。

実施形態に従うと、パーティションプラグインについての擬似コードが以下に示される。プラグインにおけるすべてのオペレーションは、この例においてＷＬＳランタイム上でオペレーションを実行するために、実際のＷＬＳランタイムに対してＪＭＸ接続をする。

プラグイン登録
上述したように、実施形態に従うと、ランタイムプラグインおよびパーティションプラグインはＨＫ２コントラクトとして定義され得、これらのプラグインのインプリメンテーションはＨＫ２サービスとして定義され得る。ＨＫ２サービス名は、プラグインが登録されるサービスの名称と一致しなければならない。プラグイン登録は２つの態様で行われ得る。プラグインはｊａｒファイルとしてパッケージ化され、ＲＥＳＴコマンドを介してライフサイクルマネージャに登録されるか、または、プラグインインプリメンテーションのｊａｒを、たとえばＷＬＳシステムアドミニストレータによって構成可能でなければならないライフサイクルマネージャインプリメンテーションによって特定されるディレクトリにドロップする。ライフサイクルマネージャは起動時にディレクトリをスキャンして、プラグインをロードし、かつ、ライフサイクルマネージャインプリメンテーションを登録する。プラグインを配置するためのデフォルトディレクトリは、oracle_home/wlserver/common/lifecycle/pluginsである。

環境
典型的なプロダクションシステムにおいて、アプリケーションを実行するのに必要とされるＷＬＳパーティションおよびデータベースパーティションなどのような１つより多いアーティファクトが一般に存在する。実施形態に従うと、環境は、アプリケーションのすべての関連するピースについてグループ化構成を提供する。ライフサイクルマネージャは、ユーザが環境を作成することを可能にし、当該環境は、所与のテナントについてパーティションをグループ化するようシステムアドミニストレータによって使用され得る。実施形態に従うと、環境はパーティションのために以下の関数を提供する。

環境とのパーティションの関連付け
実施形態に従うと、ひとたびパーティションが環境に追加されると、環境に追加された他のパーティションに関連付けられ得る。

たとえば、環境がＷＬＳパーティションおよびデータベースを有している場合、これら２つを関連付けることにより、データソース（DataSource）が、関連付けられているデータベースを参照するＷＬＳにおいて作成される。２つのパーティションを関連付けるために、パーティションがまず環境に追加される必要がある。ひとたび環境に追加されると、associate（たとえばAssociate）メソッドが環境上で呼び出され得、関連付けられる必要がある２つのパーティションにおいて渡される。associateが環境上で呼び出されると、対応するプラグインのassociateメソッドがライフサイクルコンテキスト（たとえばLifecycleContext）オブジェクトと共に呼び出される。ライフサイクルコンテキストは、２つのパーティションの必要な接続を行うことができるようにプラグインに渡される必要な情報を有するはずである。パーティションプラグインのassociateメソッドは、環境のassociateメソッドコールに渡される順に呼び出される。

環境からのパーティションの分離
実施形態に従うと、パーティションがもはや使用されていない場合、環境における他のパーティションからのそのパーティションへの参照は、それが削除され得る前に、除去される必要がある。Dissociationは、環境において２つのパーティションを切断するメカニズムを提供する。dissociationが呼び出されると、パーティションプラグインの対応するdissociateメソッドが呼び出され、２つのパーティションを一緒に接続する構成を除去することはプラグインが担う。

たとえば、ＷＬＳパーティションがＯＴＤパーティション構成から分離される場合、ＯＴＤにおいて構成されたルーティング情報が除去され、パーティションへのトラフィックはＯＴＤを介するようルーティングされなくなる。パーティションプラグインのdissociateメソッドは、メソッドコールへ渡される順に呼び出される。

パーティション移動
実施形態に従うと、パーティションの移動をサポートするランタイムは、パーティションプラグインのmigrateメソッドを実現する必要がある。パーティションを移動させる場合、当該パーティションに関連付けられる他のパーティションもアクションを行う必要があり得る。これに対応するために、migrateメソッドは環境に対して作用する。ライフサイクルマネージャインフラストラクチャは、最初に移動されているパーティションのmigrateメソッドを呼び出し、次いで、当該環境に存在する他のパーティションのmigrateメソッドを呼び出さなければならない。

実施形態に従うと、パーティションの移動は異なるフェーズを有し得る。そのようなシナリオにおいて、パーティションプラグインのmigrateメソッドは１回より多く呼び出され得、migrateメソッドにおけるフェーズパラメータを介する移動フェーズを示す。

たとえば、パーティション移動フェーズが開始していることを示す「start_migration」フェーズが存在し得る。移動がなされた後、その後のコールは、パーティションが移動されたことを示す「end_migration」フェーズというフェーズを有する。パーティションが付加的なフェーズをサポートする場合、それらのフェーズは、完全な機能を保証するようパーティションプラグインによってサポートされ得る。

「start_migration」、「end_migration」は、パーティションがサポートし得るフェーズの例であり、すべてのパーティションがサポートしなければならないフェーズの標準リストではない。パーティションがmigrationをサポートしない場合、UnsupportedOperationExceptionが投入されなければならない。パーティションがフェーズをサポートしない場合、ヌル値は、migrateメソッドに渡される有効な値である。

パーティションの静止
実施形態に従うと、パーティションの静止をサポートするランタイムは、パーティションプラグインのquiesceメソッドを実現する必要がある。ライフサイクルマネージャは、パーティションを静止することを試みる前に、パーティションが適合状態であることを保証するよう、パーティションの状態をチェックする。

構成モジュール
実施形態に従うと、ライフサイクルマネージャは、そのオペレーションについて必要とされるさまざまな構成要素を管理する構成モジュールを含む。構成モジュールは、ここで記載されるさまざまなシナリオについての必要な構成インフラストラクチャを提供する。構成モジュールは２つのモードで機能する。すなわち、ライフサイクルがアドミンサーバ上で実行されるローカルモード（構成はＷＬＳコンフィグディレクトリにおけるＸＭＬファイルにおいて永続化される）と、ライフサイクルがクラスタ上で実行され得るＨＡモード（構成がデータベースにおいて永続化される）とで機能する。いずれの場合も、ライフサイクル構成は、構成を管理するためにＨＫ２フレームワークを使用する。

ライフサイクル構成ファイル伝播
実施形態に従うと、アドミンサーバ上の構成ファイルに変更がなされると、それらの変更はすべての管理されるサーバに伝播されなければならない。管理されるサーバはライフサイクル構成を使用して、当該管理されるサーバ上で実行されるアプリケーションについて適切なテナントコンテキストを確立する。ＨＫ２コンフィグオブジェクトは、ｘｍｌ構成ファイルのリパーシングを許可しない。代わりに、新しいオブジェクトはインスタンス化され、更新されたｘｍｌファイルは新しくパースされなければならない。構成変更が行われる場合、ＸＭＬファイルは特別のディレクトリへ保存される。すなわちドメインのためのペンディングディレクトリへ保存される。

管理されるサーバへのファイル転送
実施形態に従うと、変更が行われるたびに、LifecycleConfigDocument save()メソッドがＨＫ２によって呼び出される。このメソッドはさらに、ペンディングディレクトリにファイルのコピーを保存し、その後、管理されるサーバへの当該変更されたファイルのアップロードをトリガする以下のＡＰＩを呼び出す。

変更の監視
実施形態に従うと、構成ファイルの第１のパース上で起動されたFileWatcherデーモンがｘｍｌファイルが変更されたことを検出する。その後、FileWatcherデーモンは、新しいコンフィグオブジェクトを作成し、ｘｍｌファイルをパースする。任意の呼出元が、パーシング中に情報にアクセスすること試みることがブロックされることになる。パーシングが完了するとすぐに、修正データが呼出元に利用可能になる。

構成されたデータへのアクセス
実施形態に従うと、LifecycleConfigFactoryクラスによりＨＫ２構成が公開され得る。たとえば、

編集セッション
実施形態に従うと、ＷＬＳ構成における変更を必要とするＲＥＳＴ要求のために、各ＲＥＳＴコールはユーザに代わって編集セッションを作成および管理する。これは、コンソールにおける開発モードでの「暗黙的変更（implicit change）」と同様である。

LifecycleTask
ライフサイクルマネージャを介して実行されるあるオペレーションが存在する。これらのオペレーションは、本来長く実行される非同期オペレーションである。そのようなオペレーションの例は、quiescing Server (runtime manager.quiesce)、または、starting a Server (runtime manager.quiesce)である。そのようなシナリオにおいて、ライフサイクルマネージャＡＰＩのセマンティックは、これらのＡＰＩからLifecycleTaskオブジェクトを返すよう、非同期にされ得る。

LifecycleTaskManager
一般に、ユーザが非同期オペレーションを実行しLifecycleTaskオブジェクトを受信する場合、ライフサイクルタスクによって表わされる非同期オペレーションのステータスを取得すること、または、ライフサイクルタスクによって表わされる非同期オペレーションをキャンセルすることのうちの１つをそのオブジェクトにより行うことができる。実施形態に従うと、上記のオペレーションはLifecycleTaskManagerによって公開されるインターフェイスによって実行される。

ライフサイクルＡＰＩおよびクラス
さまざまな実施形態に従うと、ライフサイクルインターフェイスおよびクラスの例が以下に記載される。他の実施形態に従うと、他のタイプのインターフェイスおよびクラスが提供され得る。

ライフサイクルマネージャ
実施形態に従うと、例示的なライフサイクルマネージャインターフェイスが以下のように記載される。

Runtime Manager.Java
実施形態に従うと、例示的なRuntime Manager.Javaインターフェイスが以下のように記載される。

ライフサイクルランタイム
実施形態に従うと、例示的なライフサイクルランタイム（Lifecycle Runtime）インターフェイスが以下のように記載される。

ライフサイクルパーティション
実施形態に従うと、例示的なライフサイクルパーティション（Lifecycle Partition）パッケージが以下のように記載される。

ランタイムプラグイン
実施形態に従うと、例示的なランタイムプラグイン（Runtime Plugin）クラスが以下のように記載される。

パーティションプラグイン
実施形態に従うと、例示的なパーティションプラグイン（Partition Plugin）クラスは以下のように記載される。

環境
実施形態に従うと、例示的な環境（Environment）インターフェイスが以下のように記載される。

ライフサイクルコンテキスト
実施形態に従うと、例示的なライフサイクルコンテキスト（Lifecycle Context）インターフェイスが以下のように記載される。

ライフサイクルオペレーションタイプ
実施形態に従うと、例示的なライフサイクルオペレーションタイプ（Lifecycle Operation Type）列挙子が以下のように記載される。

ライフサイクルタスク
実施形態に従うと、例示的なライフサイクルタスク（Lifecycle Task）インターフェイスは以下のように記載される。

ライフサイクルタスクマネージャ
実施形態に従うと、例示的なライフサイクルタスクマネージャ（Lifecycle Task Manager）インターフェイスが以下のように記載される。

図１０は、実施形態に従った、マルチテナントアプリケーションサーバ環境においてエンドツーエンドライフサイクルを提供するための方法のフローチャートを示す。

図１０に示されるように、ステップ５１０において、１つ以上のパーティションをサポートする、ソフトウェアアプリケーションの実行のためのドメインを含むアプリケーションサーバ環境が１つ以上のコンピュータにおいて提供される。各パーティションはドメインの管理およびランタイム区分を提供し、パーティションは、デプロイ可能なアプリケーションまたはリソースの集合を有しおよび／またはリソースグループテンプレートを参照する１つ以上のリソースグループを随意に含み得る。

ステップ５１２において、ライフサイクルマネージャが提供される。ライフサイクルマネージャは、たとえばアプリケーションサーバ、トラフィックディレクタまたはロードバランサ、および、データベースまたは他のコンポーネントといった、自身のパーティションに特有の構成を有し得る異なるコンポーネントにわたる構成インテグレーションを可能にする。

ステップ５１４において、複数のコンポーネントが提供される。当該複数のコンポーネントの各々は、ライフサイクルマネージャとそのコンポーネントとの間にブリッジを提供するライフサイクルプラグインを含む。

ステップ５１６において、パーティションの作成中または構成中に、ライフサイクルマネージャは、プラグインインターフェイスを呼び出し得るライフサイクルオペレーションを実行し、これにより、プラグインインターフェイスは、たとえばパーティションとの使用のためのトラフィックディレクタインスタンスの作成またはデータベースインスタンスの作成といった、コンポーネントの実際の作成または構成を実行する。

テナントオンボーディング
実施形態に従うと、システムは、あるサービスのためのテナントを特定のパーティションにオンボードするのに使用され得るテナントオンボーディング機能のためのサポートを含む。

たとえば、フュージョンアプリケーション（ＦＡ：Fusion application）を含む実施形態に従うと、システムは、所与のパーティションに対してサービスのためのＦＡテナントをオンボードするメカニズムを提供し得る。実施形態に従うと、各環境は、上位スタックにおけるサービスに関連付けられ得る。テナントをオンボードする場合、ＦＡサービスが使用しているのはどのパーティションであるか、当該サービスに関連付けられるテナントのデータベース、および、トップレベルテナントディレクトリといった情報が特定され得る。

実施形態に従うと、システムは、所与のパーティションにテナントをマッピングするようＡＰＩを提供する。入力される要求について、システムは、構成からテナントを決定し得、その情報を使用してランタイムにてテナンシコンテキストを確立する。たとえばJava Required Files（ＪＲＦ）ＡＰＩを使用してクエリ送信された場合、適切なテナンシコンテキストが当該アプリケーションに利用可能になり得る。

たとえば、上述したように、システムは、たとえばＦＡテナントがオンボードされ得るように、かつ、オラクルプラットフォームセキュリティサービス（ＯＰＳＳ：Oracle Platform Security Services）のような上位スタックコンポーネントおよびサービス指向アーキテクチャ（ＳＯＡ：Service Oriented Architecture）が環境をプロビジョニングするようアクセスを取得可能であるように、環境を作成するために使用され得るので、最終的に構成される環境は、テナントが必要とするコンポーネントのすべてを有することになる。

実施形態に従うと、テナントは１つ以上の異なるサービスを有し得る。たとえば、テナントはカスタマーリレーションシップマネジメント（ＣＲＭ：Customer Relationship Management）サービスおよび／またはＳＯＡサービスを有し得る。一般に、上位スタックにおける各サービスはアプリケーションサーバにおける１つ以上の環境に関連付けられ得る。これは、上位スタックにおいて２つのサービスにサインアップするテナントは一般に２つの環境を受け取り、当該環境はテナントレベルにおいてリンクされるということを意味する。

たとえば、テナントがＳＯＡとビジネスプロセスマネージメント（ＢＰＭ：Business Process Management）サービスにサインアップする場合、テナントはＳＯＡ環境およびＢＰＭ環境を受け取り、これらの環境は両方とも当該テナントによってリンクされる。環境内の各アプリケーションは、たとえばＨＴＴＰまたはＴ３コールとして、必要ならば、そのテナントに関連付けられる別の環境への各リモートコールを使用し得る。

上述したように、実施形態に従うと、システムは、テナンシコンテキストおよびパーティションコンテキストの概念を認識し、前者は一般により多くの情報を含んでいる。特定のサービスは、たとえばアプリケーションサーバ（たとえばＷｅｂＬｏｇｉｃ，ＷＬＳ）、データベース（たとえばDatabase）、および、トラフィックディレクタまたは他のロードバランサ（たとえばオラクルトラフィックディレクタ，ＯＴＤ（Oracle Traffic Director））といったさまざまなコンポーネントのいくつかのスライスまたはパーティションを含み得る。テナントコンテキストは、サービスと、どのように当該サービスがパーティションコンテキストにマッピングするかとを示す態様で、特定のテナントのためのパーティションコンテキストにマッピングする。

図１１は、実施形態に従うと、マルチテナントアプリケーションサーバ環境におけるテナントオンボーディングを示す。

図１１に示されるように、実施形態に従うと、テナントオンボーディングＡＰＩ５５０および構成インターフェイス５６０は、アドミニストレータ５６２がテナント構成５６４を提供することを可能にする。その後、テナントオンボーディングプロセスはその情報を使用してＵＵＩＤおよび環境５６６を有するテナント５６５を作成し、そのテナントの環境を適切なパーティションまたはドメインレベルリソースにマッピングし得る（５７０）。

実施形態に従うと、各テナントはグローバルユニークＩＤ（ＵＵＩＤ）に関連付けられ得、各サービスは同様にＵＵＩＤに関連付けられ得る。これは、テナントコンテキストをルックアップするようどのサービスが呼び出されていてもというコンテキストにおいてシステムが動作することを可能にする。システムはさらに、特定のタスクを実行するために異なるテナントコンテキスト同士の間でスイッチングする能力を提供する。これは一般に、本願明細書におけるさまざまな実施形態においてExecuteAs機能と称される。

たとえば、アプリケーションサーバ（たとえばＷＬＳ）環境において、さらに以下に記載されるように、グローバルまたはドメインレベルのランタイムが提供され得る。上位スタックにおけるプロダクトまたはコンポーネント（たとえばＦＡ、ＳＯＡまたはＢＰＭ）は、たとえば特定のテナントを特定のサービスにオンボードするために所与のテナントコンテキストにスイッチングすることを望み得る。そのテナントがオンボードされると、グローバルまたはドメインレベルで実行される上位スタックソフトウェアは一時的にそのテナントにスイッチングし得、たとえばトラフィックディレクタまたはデータベースにより任意の必要なタスクを実行する。

一般に、システムは、executeAsオペレーションがグローバルからテナントコンテキストへのみ実行され得るがテナントからテナントコンテキストへは実行され得ないように、グローバルレベルコンテキストからテナントコンテキストにのみスイッチングし、反対にはスイッチングしない。

テナンシコンテキストのスイッチング
実施形態に従うと、システムは、要求を現在処理している可能性があるターゲットコンポーネントのような、要求属性に基づいて自動的にパーティションコンテキストを決定し得る。スレッドのパーティションコンテキストは一般に、異なるパーティションにデプロイされるコンポーネントに要求が入る毎に変化する。

たとえば、１つのパーティションにおいて実行されるサーブレットが、Enterprise Java Bean（ＥＪＢ）または別のパーティションにおいてデプロイされるサーブレットもしくはウェブサービスのようなリモートコンポーネントを呼び出す場合、リモートコールは、ターゲットコンポーネントをホストするパーティションにおいて実行される。

この場合、ターゲットコンポーネントのビジネスメソッドを呼び出す前に、存在するプラットフォームは、適切なパーティションコンテキストをセットすることを担う。アプリケーションデベロッパは、異なるパーティションコンテキスト下でコードを実行したい場合、この能力を利用できる。

実施形態に従うと、テナンシコンテキストスイッチングはさらにシンプルなユースケースをサポートする。たとえば、アプリケーションが、呼出元のコンポーネントコンテキストを共有する同じスレッドにおいて実行され得る共有サービスにコールを行う前にコンテキストをセットする場合をサポートする。そのような場合、パーティションコンテキストスイッチングは必要ではないかまたは望まれていない。

特権オペレーションとしてのテナンシコンテキストスイッチング
実施形態に従うと、グローバルランタイムのような特権アプリケーションコードだけがテナンシコンテキストをスイッチングすることができる。したがって、ＡＰＩはアクセスを許可する前に適切なセキュリティ許可チェックを実施しなければならない。セットされているターゲットテナンシを含む許可が与えられ得る。

イリーガルなテナンシスイッチングからの保護
実施形態に従うと、下記のテーブルは、コードのセキュリティ特権に従ってどのコンテキストスイッチが許可されるかを説明する。

実施形態に従うと、たとえばＦＡシナリオにおいて、テナントオンボーディングのプロセスは、プロビジョニングシステムと通信することによって開始され得る。ＷＬＳサーバのようなマルチテナントアプリケーションサーバ上で実行されるＦＡの場合のようないくつかの状況において、テナントオンボーディングのプロセスは、プロビジョニングサブシステムによってセットアップされるランタイム上でのパーティションの作成を必要とする。

実施形態に従うと、テナントをオンボードする前に、テナントがサインアップするサービスを表わす環境が作成されなければならない。ＦＡプロビジョニングサブシステムは、まず環境を作成するために、ライフサイクルマネージャＡＰＩへと呼び出しすることができる。ひとたび環境が作成されると、テナントがテナントアドミン（たとえばTenantAdmin）クラスを介してオンボードされ得、その例が以下に示される。その後、テナントアドミンは、テナントを登録するためにＡＰＩ（たとえばregisterTenant）を公開し得る。

ひとたびテナントが登録されると、プロビジョニングインフラストラクチャによって作成されたデータベースが、所与のテナントについてテナントアドミンに登録され得る。この点において、システムはテナントをその環境にオンボードし得る。テナントをオンボードすることは、環境に対するテナントについてのマッピングを維持するために、サービス名およびサービスタイプ（ＦＡから利用可能）が渡されることを必要とする。テナントマッピングはlifecycle-config.xmlに格納され得る。

実施形態に従うと、lifecycle-config.xmlに格納されたテナントマッピングについての例示的なコードを以下に示す。

実施形態に従うと、ランタイムにおいて、テナントコンテキスト（たとえばTenantContext）がTenantContext/TenantContextFactoryを介して利用可能である。所与のパーティションまたはテナントデータベースについてTenantContextを得るＡＰＩが以下に定義されるTenantManagerクラスにおいて定義される。テナントならびに対応するテナントデータベースおよび環境を登録するためのテナントアドミンＡＰＩのすべてが、ＷＬＳにおいて実行される場合、ＲＥＳＴ ＡＰＩを介して公開され得る。Ｊａｖａ ＳＥ上で実行される場合、Ｊａｖａ ＡＰＩが直接的に使用され得る。ＷＬＳ環境上にテナントをオンボードするよう上記プロセスを記述する例示的な擬似コードが以下に示される。

上記のコードにおいて、ライフサイクルマネージャを使用してＤＢパーティションが作成されず、その代わりにプロビジョニングによって実行される場合、プロビジョニングは、ＤＢ１ランタイムオブジェクト上で、createPartitionとは反対のregisterDatabaseを呼び出す。

テナントコンテキスト
実施形態に従うと、アプリケーション自体がマルチテナント認識型であることが期待され得るＦＡ／ＳａａＳおよび同様のシナリオにおいて、パーティションＩＤおよびパーティション名に加えて、その代わりにあるオペレーションが実行されているテナントを知る必要がある。テナントコンテキスト（たとえばTenantContext）ＡＰＩは、適切なテナントコンテキストを取得するよう使用するために、上位スタックＦＭＷ／ＦＡについてＪＲＦレイヤーにおいて利用可能になり得る。

ひとたびテナントコンテキストが決定されると、コンポーネントは、所与のサービスについて環境に関連付けられるパーティションをルックアップし得る。

テナントマッピングのためのＪａｖａ ＳＥのサポート
実施形態に従うと、以下は、テナントコンテキストを抽出するためにＳＥにおいて使用され得る例示的なコードである。

Ｊａｖａ ＳＥの場合、テナントＩＤ、サービス名およびサービスタイプに基づいてテナントコンテキストをフェッチするメソッドがTenantManagerにおいて公開され得る。テナントコンテキストのセットアップは、getTenantContext()が初めて呼び出される場合、TenantContextFactoryによって暗示的に行うことができる。

ＳＥにおけるコンフィグファイルブートストラップ
実施形態に従うと、上記のセクションにおいて言及されたように、テナントマッピングはlifecycle-config.xmlに格納され得る。ＳＥでは、システムは、（ａ）環境変数lifecycle.configDirによって示される位置、または、（ｂ）lifecycle.configDir変数がセットされていない場合、

を用いて読み出され得るユーザワーキングディレクトリにおいて、このファイルをルックアップすることができる。

ＳＥにおけるテナント情報の特定
実施形態に従うと、ＪＡＶＡ（登録商標） ＳＥモードにおいて実行する場合、システムプロパティlifecycle.tenantId lifecycle.serviceName lifecycle.serviceTypeを使用して、または、システムプロパティlifecycle.serviceIdを介してサービスＵＵＩＤを特定することによって、テナントを識別する情報が読み出され得る。

上記の情報は、一意にテナントを識別し、ライフサイクル構成に存在するユニークテナントプラスサービスの組合せを識別するために使用され得る。ＳＥアプリケーションはアイデンティティを想定し、TenantContextFcatory.getTenantContextが呼び出されると、それが表わされる。

ＳＥにおけるテナントコンテキスト
実施形態に従うと、ＳＥにおけるテナントコンテキストはInheritableThreadLocal上に格納される。getTenantContext()メソッドは、初めて呼び出される場合、システムプロパティを使用してテナントコンテキストを計算し、InheritableThreadLocal上にもそれを格納する。

同じメソッドに対するさらに別のコールの際、システムは、テナントコンテキストがInheritableThreadLocal上に格納されているかどうか確かめるようチェックし、保存されているものを返す。プログラム実行の最中にシステムプロパティが変更される場合、これらの変更は、InheritableThreadLocal上のテナントコンテキストをリフレッシュするよう、検出および使用される場合があるかまたは検出および使用されない場合がある。

switchTenantContext（executeAsとしても知られる）によるスイッチング
図１２はさらに、実施形態に従った、マルチテナントアプリケーションサーバ環境におけるテナントオンボーディングを示す。

図１２に示されるように、実施形態に従うと、ＦＡ−ＭＴのランタイムビューは、１つ以上のグローバルデータソース５８２またはプロキシデータソース５８４へのアクセスを提供するアドミンランタイム５８０と、各々が自身のグローバルデータソース５９２，６０２を有する複数のテナントランタイム５９０，６００と、テナントデータソース５９４，６０４と、グローバルＰＤＢ６１０と、いくつかのテナントＰＤＢ６１２，６１４とを含む。これらのコンポーネントの各々は、たとえばhttp://tenant1.opc、http://tenant2.opcおよびhttp://internal.opcといった複数のＵＲＩを介して上位スタックコンポーネントにアクセス可能になり得る。

さまざまな実施形態に従うと、ＦＡＭＴランタイムにおいてテナンシのいくつかの異なる使用法があり、そのいくつかの例を以下のように記載する。MetaDataServiceによって使用され、テナントデータベースパーティションを選択していくつかのメタデータのテナント特有のカスタマイゼーションを選出するために使用する。

たとえば、実施される必要があるセキュリティポリシーを選出するようテナントデータベースパーティションを選択するために、ＯＰＳＳによって使用され得る。さらに、テナントのための監査ポリシーを決定し、テナントデータベースパーティションを選択して監査ログを格納するようAudit Serviceによって使用され得る。すべてのそのような場合において、共有サービスが呼び出される前に、正しいテナンシが実行スレッドに関連付けられる必要性がある。

テナンシコンテキストは、明示的にセットされていない場合、以下に記載されるようにスレッドの現在のパーティションコンテキストから導き出される。要求がＷＬＳに入ると、適切なコンテナが、当該要求のターゲットコンポーネントのさまざまな詳細を決定し、当該呼出を表わすようComponentInvocationContextオブジェクトを作成する。同様に、ＷＬＳは、タイマー終了のような何らかの非同期オペレーションの部分としてコールバックオブジェクトを呼び出す場合、スレッドにおける正しい呼出コンテキストをセットする。ComponentInvocationContextの部分として、パーティション情報も維持される。上に記載されたオンボーディングプロセスは、テナンシコンテキストを介して利用可能な現在のテナント値に対して現在のパーティションに必要なマッピングを提供する。

グローバルテナンシ
典型的に、システムのアドミニストレーションコードは通常、すべてのテナントを代表するＭＴアドミニストレータのコンテキストにおいて実行される必要性を有する。実施形態に従うと、この特別の状態は、現在の要求に関連付けられるテナントコンテキストが存在しないということを示すヌルのテナントＩＤと異なる「GLOBAL」と称される特別なテナントＩＤによって表わされる。

GLOBALデータベースを使用することを望む如何なるソフトウェアコードも、GLOBALデータベースに常に接続するDataSourceに対する固定された参照を維持しなければならない。GLOBALランタイムにおいて実行されるコードは、特定のテナントＤＢに対して固定された結合を有していないが、その代わりに、オペレーションのコンテキストに依存するテナントＤＢからデータにアクセスする。システムにおいてテナントＤＢはあらかじめプロビジョニングされていないので、現在のテナントコンテキストに基づいて特定の存在するＤＢを選択する、プロキシデータソースへの固定されたＪＮＤＩ参照をコードが有し続け得るプロキシデータソース（たとえばProxyDataSource）が使用され得る。

ＦＭＷ／ＦＡコードが以下に記載されるようにＷＬＳの外部で実行される必要がある２つの異なるユースケースが存在する。あるライフサイクルオペレーションおよびアドミニストラティブオペレーションがＪａｖａ ＳＥ環境において行われる。ビジネスプロセスマネージメントの部分として、サーバコードは時に、特定のテナントのコンテキストに作用している長く実行されているＪａｖａプロセスを分岐させる。

ＪＮＤＩおよびプロキシデータソースを介して利用可能になる、プロキシデータソースに対する単一の参照を有することにより、テナンシコンテキストを使用して、適切な存在するデータベースへのコールを代表することに対応する。上記が動作するために、テナンシコンテキストは、Ｊａｖａ ＳＥプロセスにおけるスレッドにおいて正確にセットされなければならない。Ｊａｖａ ＳＥプロセスは、テナント名およびテナントｉｄについてシステムプロパティを使用してGLOBALテナントコンテキストにおいて渡すことによって、起動されなければならない。分岐したＪａｖａプロセスは、この情報を使用するとともにswitchTenantContextを呼び出して実行スレッドにおいてテナンシコンテキストを確立する。

Ｊａｖａ ＳＥにおけるグローバルテナンシチェック
実施形態に従うと、executeAsを実行することを可能とするために、システムは、現在のテナントコンテキストがグローバルであることを保証しなければならない。これは、現在のテナントコンテキストについて、テナントＩＤが０に等しいことをチェックすることにより行われ得る。

図１３は、実施形態に従った、マルチテナントアプリケーションサーバ環境においてテナントオンボーディングを提供するための方法のフローチャートを示す。

図１３に示されるように、ステップ６３０において、１つ以上のパーティションをサポートする、ソフトウェアアプリケーションの実行のためのドメインを含むアプリケーションサーバ環境が１つ以上のコンピュータにおいて提供される。各パーティションはドメインの管理およびランタイム区分を提供し、パーティションは、デプロイ可能なアプリケーションもしくはリソースの集合を有しおよび／またはリソースグループテンプレートを参照する１つ以上のリソースグループを随意に含み得る。

ステップ６３２では、ライフサイクルマネージャが提供される。ライフサイクルマネージャは、たとえばアプリケーションサーバ、トラフィックディレクタまたはロードバランサ、および、データベースまたは他のコンポーネントといった、自身のパーティションに特有の構成を有し得る異なるコンポーネントにわたる構成インテグレーションを可能にする。

ステップ６３４において、システムにテナントがオンボードされるためのテナント構成の定義を可能にするテナントオンボーディングおよび／または構成インターフェイスが提供される。

ステップ６３６では、テナントオンボーディング中に、システムは、一意識別子を有するテナントと、環境と、特定のテナントについてパーティションコンテキストをマッピングするテナントコンテキストとを作製するようテナント構成情報を使用する。

ステップ６３８では、システムは随意に、テナントスイッチングインターフェイスを介してテナントのコンテキストにスイッチングを行い、テナントオンボーディング中にそのテナントとしてまたはそのテナントに代わって関数を実行し得る。

コンポ―ネントライフサイクルプラグイン
実施形態に従うと、エンドツーエンドライフサイクルインフラストラクチャは、マルチテナントアプリケーションサーバ環境内の異なるコンポーネントが自身のコンポーネントに特有のライフサイクル機能を提供するよう、ライフサイクルプラグインを使用することを可能にするプラグインベースのメカニズムを含む。

図１４は、実施形態に従った、マルチテナントアプリケーションサーバ環境におけるライフサイクルプラグインを示す。

上述したように、実施形態に従うと、システムは、ライフサイクルマネージャ（ＬＣＭ）およびライフサイクルインターフェイスを含むライフサイクルコーディネーションフレームワークを含み得、これにより、パーティションと、トラフィックディレクタコンポーネント、データベースコンポーネントまたは他のコンポーネントといった他のコンポーネントとのライフサイクル管理が可能になる。

たとえば、図１４に示されるように、ライフサイクルインターフェイスは、パーティションライフサイクルプラグイン６５０、アプリケーションサーバライフサイクルプラグイン６５２、トラフィックディレクタライフサイクルプラグイン６５４、および、データベースライフサイクルプラグイン６５６、または、他のタイプのプラグインの使用をサポートし得る。

各ライフサイクルプラグインは、たとえばＷｅｂＬｏｇｉｃ（ＷＬＳ）といったアプリケーションサーバ、または、たとえばオラクルトラフィックディレクタ（ＯＴＤ）インスタンスライフサイクルのようなトラフィックディレクタもしくは他のロードバランサについて、ライフサイクルニーズをカプセル化し得る。ライフサイクルインターフェイスは、その所与のコンポーネントのライフサイクルを管理するよう、各プラグインについて共通または一般的なプロセスを提供する。

図１５はさらに、実施形態に従った、マルチテナントアプリケーションサーバ環境におけるライフサイクルプラグインを示す。

図１５に示されるように、ライフサイクルプラグインは、パーティションライフサイクル管理６６０、または、データベースライフサイクル管理６６２に寄与し得る。

たとえば、ＯＴＤインスタンスは、特定のドメイン上でパーティションを作成するのに使用されるＷＬＳランタイムを作成するよう、ライフサイクルマネージャを要求し得る。ライフサイクルマネージャは、実質的にドメインの指示を提供し、かつ、そのドメイン上にパーティションを作成するようプラグインに要求するよう、各プラグイン作成メソッドを実質的に代表する。

さまざまな実施形態に従うと、同様のプラグイン機能が、たとえば他のデータベース、トラフィックディレクタまたは他のコンポーネントをサポートし、利用可能な場合にサーバを作成、削除、停止、開始、静止、移動させるよう提供され得る。各プラグインは、ライフサイクルマネージャを通じてサポートされた各コンポーネントについて実現され得る。

Ａ．アプリケーションサーバプラグイン
実施形態に従うと、システムは、アプリケーションサーバ（たとえばＷｅｂＬｏｇｉｃ，ＷＬＳ）ライフサイクルプラグインを含み得、ライフサイクルＡＰＩを実現し、アプリケーションサーバ（たとえばＷＬＳ）パーティションの作成または構成を管理する。

ライフサイクルマネージャとの相互作用
実施形態に従うと、アプリケーションサーバプラグインは、レジスタプラグインオペレーションを使用して、ライフサイクルマネージャに登録され得る。その後、ライフサイクルマネージャへのアプリケーションサーバ（たとえばＷＬＳ）ランタイムの登録の際、ライフサイクルマネージャと相互作用するクライアントは、ライフサイクルマネージャに登録された特定されたランタイム上でパーティションを作成／更新／削除するよう、ライフサイクルマネージャにＲＥＳＴコールを行うことができる。アプリケーションサーバ（たとえばＷＬＳ）プラグインは、その特定のアプリケーションサーバ（たとえばＷＬＳ）ランタイム上でライフサイクルオペレーションを実行するために呼び出され得る。

アプリケーションサーバとの通信
実施形態に従うと、アプリケーションサーバプラグインは、サーバと相互作用するために、アプリケーションサーバ（たとえばＷＬＳ）によって公開されるＪＭＸ／ＲＥＳＴ ＡＰＩを使用し得る。プラグインは、ターゲットとされたアプリケーションサーバランタイムに対するライフサイクルオペレーションがアプリケーションサーバパーティション上でＣＲＵＤオペレーションを行うことを可能にするよう、ライフサイクルマネージャからのパーティションプラグインコントラクトを実現し得る。以下は、パーティションについてたとえばＷＬＳランタイム上で行われ得るいくつかの例示的な動作である。

実施形態に従うと、アプリケーションサーバプラグインは、たとえばターゲットとされたアプリケーションサーバ（たとえばＷＬＳ）ランタイム上でライフサイクルオペレーションを可能にするよう、ライフサイクルマネージャからランタイムプラグインコントラクトを実現することができる。

パーティション上のライフサイクルオペレーションのランタイムプロパティ
実施形態に従うと、アプリケーションサーバプラグインは以下のプロパティを使用してアプリケーションサーバ、たとえばＷＬＳランタイム、に接続する。これらのプロパティは、上記のコントラクトにおいて特定されたように、ライフサイクルランタイムオブジェクトを介してライフサイクルオペレーションに渡される。

ＷＬＳプラグインについてのライフサイクルコンテキスト
実施形態に従うと、アプリケーションサーバプラグインを使用して行われた任意のＣＲＵＤオペレーションは、ライフサイクルコンテキストにおけるプラグインに提供される情報／データに基づいてカスタマイズされ得る。クライアントはＲＥＳＴコールの部分としてプロパティを特定し得る。ライフサイクルマネージャはライフサイクルコンテキストへデータをポピュレート（populate）し、プラグインにプロパティを戻す。たとえば、クライアントは、ＷＬＳパーティションに対してcreatePartitionについてのＲＥＳＴコールを行う場合、パーティションの属性を特定するためにプロパティを特定し得る。

パーティションの作成／更新のためのライフサイクルコンテキスト
実施形態に従うと、以下は、パーティションオペレーションを作成／更新しつつクライアントによって特定され得るいくつかの例示的なプロパティである。これらの構成はパーティション作成／更新の部分として作成され、パーティションに特有である。

実施形態に従うと、以下は、パーティションを作成／更新しつつクライアントによって特定され得るいくつかの例示的なプロパティである。アプリケーションサーバ（たとえばＷＬＳサーバ）におけるこれらのエンティティを発見することに失敗すると、アプリケーションサーバプラグインから例外が投入される。

Delete Partitionについてのライフサイクルコンテキスト
実施形態に従うと、パーティション名以外の付加的なプロパティは、アプリケーションサーバ（たとえばＷＬＳ）パーティションを削除するためには必要ではない。

Associate Partitionについてのライフサイクルコンテキスト
実施形態に従うと、別のコンポーネントとのアプリケーションサーバインスタンスの関連付けは、いくつかの新しいプロパティによるアプリケーションサーバ（たとえばＷＬＳ）パーティションを更新することを伴い得るか、または、関連付けのために、必要なプロパティを他のコンポーネントに提供することを伴い得る。

関連付けに参加することを望む如何なるコンポーネントも、上で特定されたフォーマットでライフサイクルコンテキストにおけるプロパティの正しいセットを確実に渡す必要がある。

ＷＬＳ−ＯＴＤ関連付けの場合、ＯＴＤパーティションは、この場合、関連付けを行うためにクラスタ名、クラスタメンバーおよびターゲット情報を予想する。アプリケーションサーバプラグインは、パーティション名に基づいて正しいターゲット情報をフェッチするよう、アプリケーションサーバランタイムにＪＭＸ／ＲＥＳＴコールを行う。これらのプロパティは、associatePartitionインプリメンテーションの部分として、アプリケーションサーバのlifecycleContextに追加される。プラグインに対する関連付けコールの部分として、ターゲット構成の完全なスナップショットがライフサイクルコンテキストに追加される。その後、ライフサイクルマネージャは、ＯＴＤプラグインのassociatePartitionインプリメンテーションを呼び出し、当該associatePartitionインプリメンテーションは、（ＷＬＳターゲットのプロパティを有する）ライフサイクルコンテキストを使用して、発信元サーバプールとアプリケーションサーバパーティションとの接続を行う。

実施形態に従うと、アプリケーションサーバ（たとえばＷＬＳ）パーティションがＯＴＤパーティションに関連付けられる場合、かつ、構成されたクラスタにパーティションがターゲットとされ、サーバが実行されていない場合、ライフサイクルマネージャは、サーバのListenAddressおよびPortについて利用可能な構成情報を取得し、ＯＴＤに送信する。サーバが実行されている場合、RuntimeMBeanから利用可能なサーバについてのランタイム情報が取得され、当該ランタイム情報はコンテキスト情報を介してＯＴＤへ渡される。

動的なクラスタにおいて、動的なサーバのためのポートについて構成時間情報が利用可能であるが、ListenAddressについて利用可能な構成情報は存在しない。associateコールが発生する際に動的なサーバが実行されていなければ、ライフサイクルマネージャは構成されたポートおよびノードマネージャのListenAddress（動的なサーバがマシンと関連付けられている場合）を取得し、他のプラグインにこれを送信する。associateコールが発生する際に動的なサーバが実行されていれば、ライフサイクルマネージャはRuntimeMBeanからサーバのリスンアドレスおよびポートを取得し、ＯＴＤプラグインにそれを送信する。

ＷＬＳ−ＤＢ関連付けの場合には、アプリケーションサーバ（たとえばＷＬＳ）プラグインのassociatePartitionメソッドは、この場合、ＤＢパーティションのlifecycleContextを使用して、ＰＤＢ情報をポピュレートし、当該ＰＤＢ情報によりＷＬＳパーティションを更新する。

パーティション分離についてのライフサイクルコンテキスト
実施形態に従うと、別のコンポーネントとのアプリケーションサーバ（たとえばＷＬＳ）の分離は、あるＷＬＳパーティション構成を除去／更新することを伴い得る。分離に参加することを望む如何なるコンポーネントも、上で特定されたフォーマットでライフサイクルコンテキストにおけるプロパティの正しいセットを確実に渡す必要がある。以下は、ＷＬＳとＤＢパーティションとの間の分離を説明する例である。

ＷＬＳ−ＤＢ分離：この場合、ＷＬＳプラグインのdissociatePartitionメソッドは、ＤＢパーティションのlifecycleContextを使用して、ＰＤＢ情報名をポピュレートし、ＰＤＢ情報を除去することによりＷＬＳパーティションを更新する。ＷＬＳプラグインは、lifecycleContextにおいてＰＤＢ情報名を予想する。

ＷＬＳ−ＯＴＤ分離：この場合、ＯＴＤパーティションは、分離を行うために、クラスタ名、クラスタメンバーおよびターゲット情報を予期する。ＷＬＳプラグインは、パーティション名に基づいて正しいターゲット情報をフェッチするよう、ＷＬＳランタイムにＪＭＸ／ＲＥＳＴコールを行う。これらのプロパティは、ＷＬＳプラグインのdissociatePartitionインプリメンテーションの部分として、ＷＬＳのlifecycleContextに追加される。

ＬＣＭ環境におけるＷＬＳパーティション構成の発見および関連付け
実施形態に従うと、パーティション構成は、ライフサイクルマネージャ環境／範囲の外部で作成／更新／削除され得る。たとえば、アドミニストレータがパーティションを作成するようＷＬＳＴコマンドを呼び出すか、または、パーティションを更新するためにＷＬＳアドミンコンソールを使用し得る。任意の状況において、ライフサイクルマネージャとともに存在するパーティション情報は最近のものであり最も更新されたものであることが確実である必要がある。

アプリケーションサーバ構成上でのライフサイクルマネージャランタイムスケーリングの影響
実施形態に従うと、アプリケーションサーバ（たとえばＷＬＳ）プラグインにおけるScaleUpおよびscaleDownオペレーションは、動的なクラスタの部分であるサーバインスタンスを開始および停止する機能を提供するよう使用され得る。ＷＬＳプラグインは、サーバを開始／停止するようマシン／サーバと相互作用するようノードマネージャを使用し得る。

エラスティシティフレームワークは、クラスタ情報によりライフサイクルマネージャにスケールアップまたはスケールダウンコールを行い、scaleUp/scaleDownに登録されるスケールファクタ、ランタイムタイプ（すなわちＷＬＳ）インターセプタは、スケールアップすべきクラスタについて必要とされる必要なインフラストラクチャを有効化および実行するスケールアップ／スケールダウンオペレーションの前に呼び出される。

たとえば、クラスタにおいて立ち上げるべき新しいサーバに必要とされるデータソースの数を決定／作成するよう、ＷＬＳランタイムに必要なコールを行う。ひとたびクラスタをスケールアップ／スケールダウンする前提条件が満たされれば（すなわちインターセプタの事前呼出が満足されれば）、実際のスケールアップまたはスケールダウンが行われる。インターセプタは、後呼出要件を満足するよう、オペレーションがプラグインにおいて完了した後、再び呼び出される。

たとえば、多くのインターセプタがＷＬＳクラスタをスケーリングするために使用されると仮定して、１つのそのようなシーケンスが以下に記載される。

エラスティシティモジュールからのWLSScaleDownActionがlcm.scaleDown(clusterName, factor, payload)を呼び出す際に、ＷＬＳインターセプタ、ＯＴＤインターセプタ、ＪＭＳインターセプタ、データソースインターセプタといったインターセプタが追加されたと仮定する。すなわち、
１．ＷＬＳインターセプタは、スケーリングがクラスタ限界内であるかどうかチェックする。その後、ＷＬＳインターセプタはctx.proceed()を呼び出す。
２．ＯＴＤインターセプタは、ドレインされるべき選択されたターゲットをマークするよう、必要なＯＴＤコンフィグ変更を行う。要求がドレインされたことをＯＴＤメトリックが示すまで、ＯＴＤインターセプタは待機する。その後、ＯＴＤインターセプタはctx.proceed()を呼び出す。
３．ＪＭＳインターセプタは、ＪＭＳバックログがドレインするのを待機する。その後、ＪＭＳインターセプタはctx.proceed()を呼び出す。
４．データソースインターセプタは、すべてのＪＤＢＣ接続がプールに返されたことを保証する。その後、データソースインターセプタはctx.proceed()を呼び出す。
５．サービスがスケールダウンされる（最後のインターセプタの後にElasticServiceManagerによって呼び出される）。

インターセプタコールチェーンのリターンパス上で、
１．データソースインターセプタは、残存する稼働している管理されたサーバについて最大接続プールサイズ（max-connection-pool-size）を適切に増加し、
２．ＪＭＳインターセプタは何もせず、
３．ＯＴＤインターセプタは何もせず、
４．ＷＬＳインターセプタは何もしない。

ＲＥＳＴ要求を使用するアプリケーションサーバプラグインの呼出
実施形態に従うと、ライフサイクルマネージャクライアントは、ＲＥＳＴ要求を使用してＷＬＳ上でたとえば以下のオペレーションを行い得る。すなわち、当該オペレーションは、
１．ＲＥＳＴ要求において渡されるべきＷＬＳランタイムおよびプロパティを登録することと、
２．空のＷＬＳパーティションを作成することと、
３．リソースグループおよびターゲティングによりＷＬＳパーティションを作成することと、
４．（環境テスト１が既に作成されていると仮定して）環境にＷＬＳパーティションを追加することと、
５．別のパーティションにＷＬＳパーティションを関連付けることと、
６．別のパーティションとＷＬＳパーティションを分離することと、
６．ＷＬＳパーティションを削除することと、
７．ＷＬＳパーティションを更新することと
を含む。

Ｂ．データベースプラグイン
実施形態に従うと、システムは、ライフサイクルＡＰＩを実現するとともにデータベース（たとえばDatabase）パーティションの作成または構成を管理するデータベース（たとえばオラクルデータベース）ライフサイクルプラグインを含み得る。

実施形態に従うと、オラクルデータベース（Oracle Database）のようなデータベースコンポーネントのマルチテナント認識型アーキテクチャによって、顧客が作成したプラガブルデータベース（ＰＤＢ：pluggable database）を含むマルチテナントコンテナデータベース（ＣＤＢ）として機能することが可能になる。各ＰＤＢは、スキーマ、スキーマオブジェクトおよびノンスキーマオブジェクトのポータブルな集合として作用する。ライフサイクルマネージャモジュールの観点から、データベースコンポーネントは、データベースマシナリに組み込まれたＰＤＢ機能を使用して、自身のパーティション構成を管理する。データベースライフサイクルプラグインは、ライフサイクルマネージャによって呼び出されると、ＰＤＢ管理オペレーションを実行するために、この機能にレバレッジをかけ得る。

ライフサイクルマネージャとの相互作用
実施形態に従うと、データベースプラグインは、ライフサイクルマネージャパーティションプラグインインターフェイスのインプリメンテーションであり、任意のオペレーションを実行し得る前に、ライフサイクルマネージャに登録される。結果、ライフサイクルマネージャへのデータベースランタイムの登録の際、ライフサイクルマネージャと相互作用するクライアントは、ライフサイクルマネージャに対するＲＥＳＴコールを行い、ライフサイクルマネージャに登録された特定されたランタイム上でＰＤＢオペレーションを実行する。

ランタイム登録
実施形態に従うと、データベース上でオペレーションが実行され得る前に、ライフサイクルマネージャに登録されなければならない。登録プロセスは、データベースに接続するために使用される情報を必要とする。たとえば、データベースランタイムは以下のプロパティに登録され得る。

データベース上のライフサイクルオペレーション
実施形態に従うと、データベースライフサイクルプラグインは、ＪＤＢＣを介してリモートＳＱＬ接続を使用してデータベースと通信する。ランタイム登録中に特定されるプロパティはデータベースに接続するために使用される。多くのライフサイクルオペレーションは、対応するＳＱＬコマンドにマッピングし、そのさまざまなクローズ（clause）はたとえば、ライフサイクルコンテキストオブジェクトに渡されるとともにプラグインに渡されるプロパティから決定される。

実施形態に従うと、以下は、例による上記のオペレーションの詳細である。
Create
実施形態に従うと、createオペレーションは以下のタスクを実行する。すなわち、（１）特定されたデータベースランタイム上でプラガブルデータベースを作成する。新しく作成されたＰＤＢのパーティションＩＤがＶ＄ＰＤＢＳテーブルから取得される。パーティション名はＰＤＢ名と同じである。（２）随意に、データベースユーザを作成する。（３）随意に、既存のＣＤＢプランを使用してＰＤＢにＣＤＢプランディレクティブを作成する。上記のタスクについて多くのオプションが利用可能である。これらのオプションは、ライフサイクルコンテキストオブジェクトにおけるプロパティとして、プラグインに渡される。

Delete
実施形態に従うと、deleteオペレーションは以下のタスクを実行し得る。（１）ＰＤＢ名を使用してプラガブルデータベースをドロップする。ＰＤＢユーザも自動的にドロップされる。（２）随意に、上記のタスクについてプラグインによって実行されるＰＤＢサンプルＳＱＬに対するＣＤＢプランディレクティブをドロップする。

Update
実施形態に従うと、updateオペレーションは、ＰＤＢに対する更新を実行するようALTER PLUGGABLE DATABASEコマンドを実行することによって、プラガブルデータベースの属性を修正する。

Associate
実施形態に従うと、associateオペレーションは、ＷＬＳパーティションがＰＤＢに関連付けられる際に重要である。データベースプラグインは、関連付け中に、ＷＬＳプラグインにデータベース接続ＵＲＬを渡す。ライフサイクルマネージャによってＰＤＢを作成する間にユーザが作成されると、そのユーザのユーザ名およびパスワードもＷＬＳパーティションプラグインに渡される。

Quiesce
実施形態に従うと、quiesceオペレーションは、ALTER PLUGGABLE DATABASEコマンドを使用して、特定されたＰＤＢを閉じる。

Start
実施形態に従うと、startオペレーションは、ALTER PLUGGABLE DATABASEコマンドを使用して、特定されたＰＤＢを開始する。

ライフサイクルコンテキストスキーマ
実施形態に従うと、ライフサイクルコンテキストオブジェクトを介してプラグインへと渡されるプロパティからさまざまなＳＱＬクローズが形成され得る。共有のリソースのうちのいくつかは以下を含む。

実施形態に従うと、ＳＱＬコマンドおよびさまざまなクローズは、ライフサイクルコンテキストプロパティとして特定され得る。データベースにおけるサポートに依存して、ＰＤＢを変更させる場合にもこれらのうちのほとんどが使用され得る。

リソースマネージャプロパティ
実施形態に従うと、ＰＤＢを作成する場合、ＣＤＢプランディレクティブも作成され得る。これに関係するプロパティは、キー「resourceManager」の下で特定されるべきである。以下は「resourceManager」についての例示的なプロパティである。

ユーザプロパティ
実施形態に従うと、ＰＤＢを作成する場合、ユーザも作成され得る。ユーザに関係するプロパティは、キー「databaseUser」の下で特定されるべきである。

図１６は、実施形態に従った、マルチテナントアプリケーションサーバ環境においてライフサイクルプラグインをサポートするための方法のフローチャートを示す。

図１６に示されるように、ステップ６８０では、１つ以上のパーティションをサポートする、ソフトウェアアプリケーションの実行のためのドメインを含むアプリケーションサーバ環境が１つ以上のコンピュータにおいて提供される。各パーティションはドメインの管理およびランタイム区分を提供し、パーティションは、デプロイ可能なアプリケーションまたはリソースの集合を有しおよび／またはリソースグループテンプレートを参照する１つ以上のリソースグループを随意に含み得る。

ステップ６８２では、ライフサイクルマネージャが提供される。当該ライフサイクルマネージャは、たとえばアプリケーションサーバ、トラフィックディレクタまたはロードバランサ、および、データベースまたは他のコンポーネントといった、自身のパーティションに特有の構成を有し得る異なるコンポーネントにわたる構成インテグレーションを可能にする。

ステップ６８４において、複数のコンポーネントが提供される。当該複数のコンポーネントの各々は、ライフサイクルマネージャとそのコンポーネントとの間にブリッジを提供するライフサイクルプラグインを含む。

ステップ６８６では、パーティションの作成中または構成中に、複数のライフサイクルプラグインは、ライフサイクルマネージャがプラグインを呼び出すことができるライフサイクルオペレーションを実行することを可能にするインターフェイスを実現する。そのため、プラグインは、コンポーネントの実際の作成または構成を実行するために、その関連するコンポーネントにより動作し得る。

グローバルランタイム
実施形態に従うと、システムは、マルチテナントアプリケーションサーバ環境内のグローバルランタイムの使用をサポートする。

上述したように、フュージョンアプリ（Fusion Apps）またはフュージョンミドルウェア（Fusion Middleware）を使用するもののようなさまざまな実施形態に従うと、すべてのパーティションについてグローバルコンテキストでものを実行するための要件が存在し得る。

たとえば、フュージョンミドルウェア（ＦＭＷ）の部分として提供されるメタデータサービス（ＭＤＳ）コンポーネントにおいて、シェアされたドキュメントのすべてについての１つのグローバルキャッシュと、テナントに特有のカスタマイゼーションについてパーティションに特有のキャッシュとが存在するべきであるという要件がある。そのようなグローバルキャッシュを有することに加えて、キャッシュがパージまたは更新された場合、パーティションにおいて実行されるＭＤＳインスタンスが、更新されたキャッシュにカスタマイゼーションを適用することができるように、すべてのパーティションに通知するための要件がさらに存在する。

さらに、マルチテナント環境におけるハイレベルでは、本願明細書においてグローバルアーティファクトと称される任意のパーティションを含む全ドメインにわたって共有される必要があるアーティファクトまたは他のコンポーネントが存在し得る。これらのアーティファクトは、グローバルランタイムと称されるマルチテナントコンテナにおいてグローバルまたはドメインレベルで存在または実行される。パーティション特有のアーティファクトまたはコンポーネントは、パーティションのコンテキストにおいて存在または実行されるものである。

実施形態に従うと、グローバルランタイムは任意の特定のパーティションにおいて実行されないが、その代りにドメインへ範囲指定される。たとえばJava Required Files（ＪＲＦ）ドメインにおいて実行される場合、フュージョンアプリケーション（ＦＡ：Fusion Application）ためのテナントマッピングおよびマルチテナンシフラグを有効化した状態で、グローバルランタイムで実行されるコードは、テナントのコンテキストにスイッチングされ、テナントスイッチング（たとえばswitchTenant）ＡＰＩを介してテナントに代わって何かを実行することができる。

実施形態に従うと、１つ以上のリソースグループも、グローバルランタイムで使用されるドメインレベルにて特定され得る。ドメインレベルのリソースグループのターゲティングは、リソースグループ内の個別のリソースではなく、リソースグループにセットされる。グループにおけるすべてのリソースは、リソースグループについて指定されるすべてのターゲットに対してターゲットとされる。クラスタにターゲットとされると、アプリケーションは、当該クラスタにおけるすべての管理されるサーバ上で実行される。

実施形態に従うと、ドメインレベルにおいて、リソースグループは、グループに関連するリソースへの簡便な方法である。システムは、グループ化されていないリソースと同じドメインレベルリソースグループにおいて宣言されたリソースを管理する。たとえば、リソースは、システムスタートアップ中にスタートされ、システムシャットダウン中に停止される。さらに、アドミニストレータは、グループ内の任意の単一のリソースを個々に停止させるか、開始させるかまたは除去することができ、グループ上で動作させることによって暗黙的にグループ内のすべてのリソースに対して機能することができる。

たとえば、グループを停止することにより、まだ停止されていないグループにおけるすべてのリソースが停止される。グループをスタートすることにより、まだスタートされていないグループにおける任意のリソースがスタートされる。グループを除去することにより、グループに含まれるすべてのリソースが除去される。

実施形態に従うと、パーティションにおいて定義される他のすべてのリソースグループの前に、グローバルランタイムリソースグループがスタートされなければならない。これは、パーティションのいずれかの前に、グローバルランタイムが初期化されることを可能にし、また、必要ならば、シェアされたクラスローダを使用して、シェアされたクラスをロードして、シェアすることが可能であるパーティションまたは他のアプリケーション／リソースグループの間で、パーティションを初期化する前にシェアする。

実施形態に従うと、グローバルランタイムで実行する場合、パーティション名はGLOBALを返し、ｉｄは０となる。

マルチテナンシフラグが有効化された状態でＪＲＦドメインにおいて実行する場合、テナントコンテキストはGLOBALとしてセットされるテナンシを有し、テナントｉｄも０になる。

実施形態に従うと、グローバルランタイムにて定義されるリソースグループは、グローバルランタイムにおいて実行されるアプリケーションが動作することを望み得るまたはクラスを共有することを望み得るパーティションと同じ管理されるサーバ／クラスタにターゲットとされなければならない。あるクラスタから別のクラスタにパーティション（リソースグループ）を移動させる場合、グローバルランタイムは、パーティションが移動されているグローバルランタイム上で実行されなければならないか、または、移動機能は、グローバルランタイムにおいて定義されたリソースグループは、パーティションのリソースグループを移動させる前に移動されることを保証しなければならない。

図１７は、実施形態に従った、マルチテナントアプリケーションサーバ環境においてグローバルランタイムの使用を示す。

実施形態に従うと、グローバルランタイムは、ドメインレベルで実行するように意図されるアプリケーションに使用され得る。特定のコンポーネントまたはアプリケーションは、executeAsを使用することを望む場合、グローバルランタイムのドメインレベルで実行されなければならない。その場合、グローバルランタイムは、ドメインランタイムと同じであるか、または、ドメインランタイムとして作用する。

実施形態に従うと、ExecuteAsおよびテナントオンボーディングは、上位スタックの使用のために、ＪＲＦタイプ機能として提供される。グローバルランタイムにおいて実行されるアプリケーションは、パーティションに提供されるセキュリティセッティングに依存して、さまざまなパーティションによって見られ得る。同様に、自身のＵＵＩＤを有するドメイン（グローバル）レベルで実行されるアプリケーションがパーティションに利用可能になり得る。

たとえば、グローバルＰＤＢはテナントにわたってシェアされ得る。グローバルＰＤＢは、上位スタックによってセットアップされ、ＳａａＳユースケースと共に使用される共通の構成セットアップであって、コンソリデーションまたはＰａａＳユースケースと共通して使用されるものではない。

図１７に示されるように、実施形態に従うと、グローバルランタイム７００は、１つ以上のアプリケーションを含み得、テナントに代わってexecuteAsオペレーション７０４，７０５を実行するためにテナントスイッチングＡＰＩ７０２を使用して、１つ以上のパーティション７１０，７１２，７１４にアクセスするか、または、１つ以上のパーティション７１０，７１２，７１４に代わって動作し得る。

フュージョンアプリおよびフュージョンミドルウェアシナリオにおいて、すべてのパーティションについてグローバルコンテキストでものを実行するための要件が存在する。たとえば、メタデータサービス（ＭＤＳ：Metadata Service）のコンテキストにおいて上述したように、すべてのシェアされたドキュメントについての１つのグローバルキャッシュと、テナントに特有のカスタマイゼーションについてのパーティション特有キャッシュとが存在するべきであるという要件がある。さらに、キャッシュがパージまたは更新された場合、パーティションにおいて実行されるＭＤＳインスタンスが、更新されたキャッシュにカスタマイゼーションを適用し得るように、パーティションのすべてが通知されるべきであるという要件がある。

パーティションおよびテナント名およびＩＤ
上述したように、実施形態に従うと、グローバルランタイムで実行される場合、パーティション名はGLOBALを返し、ＩＤは０になる。マルチテナンシフラグを有効化した状態でＪＲＦドメインにおいて実行される場合、テナントコンテキストはGLOBALとしてセットされるテナンシを有し、テナントＩＤも０となる。

移動およびグローバルランタイム
上述したように、実施形態に従うと、グローバルランタイムにおいて定義されるリソースグループは、グローバルランタイムにおいて実行されるアプリケーションが、動作するかまたはクラスをシェアすることを望み得るパーティションであるので、同じ管理されたサーバ／クラスタにターゲットとされなければならない。

実施形態に従うと、あるクラスタから別のクラスタにパーティション（またはそのリソースグループ）を移動させる場合、グローバルランタイムは、パーティションが移動されているクラスタ上で実行されなければならないか、または、移動機能は、グローバルランタイムにおいて定義されたリソースグループが、パーティションのリソースグループを移動させる前に移動されることを保証しなければならない。

ＳａａＳシナリオ例
下記の例は、ＳａａＳシナリオにおいてドメインレベルでのリソースグループの使用を示す。カスタマーリレーションシップマネジメント（ＣＲＭ：Customer Relationship Management）アプリケーションはグローバルランタイムにデプロイされる。ドメインレベルで定義されたリソースグループテンプレートは、パーティションおよびグローバルランタイムの両方によって使用され得る。読みやすさのために、下記の例はドメインレベルでのリソースグループのみを示す。

実施形態に従うと、アプリケーションおよびシェアされたライブラリも、ドメインレベルにてリソースグループにデプロイされ得る。

グローバルＰＤＢおよびテナント特有のＰＤＢ
実施形態に従うと、たとえばオラクル１２ｃデータベース（Oracle 12c Database）を実行する場合、多くのＰＤＢが１つのコンテナデータベース（ＣＤＢ：container database）において実行され得る。テナントのためのパーティションの作成により、ＰＤＢが作成され、使用するべきパーティションについてデータソースが構成される。

実施形態に従うと、テナントに特有なＰＤＢに加えて、すべてのテナントにわたって共有されるグローバルＰＤＢが随意に存在し得る。たとえば、ＭＤＳにおけるメタデータ（ドキュメント）は、グローバルＰＤＢに格納され得、テナントに特有のカスタマイゼーションはテナントに特有のＰＤＢに格納され得る。

実施形態に従うと、グローバルＰＤＢからシェアされたデータを使用することができるようにするために、パーティションは、両方のＰＤＢ（グローバルおよびテナント特有）へのアクセスを必要とする。各パーティションは、シェアされたデータにアクセスすることができるべきグローバルＰＤＢへの付加的な読取専用データソースと、さらに、テナントに特有なデータを格納するために使用されるテナントに特有なＰＤＢへのデータソースとを有するように構成され得る。グローバルランタイムで実行されているシェアされたアプリケーションコードは、グローバルＰＤＢに書き込むことができ、グローバルＰＤＢへの読込／書込データソースを有するように構成される。

図１８はさらに、実施形態に従った、マルチテナントアプリケーションサーバ環境におけるグローバルランタイムの使用を示す。

図１８に示されるように、実施形態に従うと、各パーティションは、１つ以上のデータソース７０１，７１１，７２１を有するように構成され得、たとえば、グローバルランタイムがデータソースＤＳ２を介するグローバルＰＤＢ７０２へのアクセスを有するということを含む。

図１８においてさらに示されるように、パーティション１（７１０）およびパーティション２（７２０）において実行されるテナントは、ＤＳ１を介してそれらの特有のＰＤＢ（それぞれ７１２および７２２）への読込／書込アクセスを有しており、グローバルＰＤＢにおける読込専用データにアクセスするために読込専用ＤＳ２（すべてのパーティションにわたってシェアされる同じデータソース）を介する。

データソース
実施形態に従うと、各パーティションは、テナントに特有なデータを書き込むために、そのＰＤＢインスタンスを指すデータソースを有することになる。たとえばＷＬＳといったアプリケーションサーバにおいてパーティションにおいて実行される場合、データソースの名称は各パーティションについて変更する必要はない。代わりに、アプリケーションサーバは、各パーティションベースで、ＪＮＤＩツリーにおけるデータソースを分離する。これらのデータソースは、各テナントのパーティションについてリソースグループから参照されるリソースグループテンプレートにおいて定義され得る。

グローバルランタイムおよびパーティションでの実行
実施形態に従うと、グローバルランタイムに再デプロイされるアプリケーションまたはシェアされたライブラリは、パーティションにおいて実行されるすべてのテナントに特有なアプリケーションとシェアされ得る。パーティションにわたってシェアされることに加えて、グローバルランタイムで実行されるアプリケーションは、特定されたテナントのコンテキストにおいて実行されるパーティションのコンテキストにおいても実行することができる。しかしながら、逆は真ではない。すなわち、パーティションにおいて実行されるテナントに特有のアプリケーションは、グローバルランタイムのコンテキストにおいて実行することができない。下記のテーブルは、どのコンテキストスイッチングが許可されるか示す。

図１９は、実施形態に従った、マルチテナントアプリケーションサーバ環境においてグローバルランタイムをサポートするための方法のフローチャートを示す。

図１９に示されるように、ステップ７４０では、１つ以上のパーティションをサポートする、ソフトウェアアプリケーションの実行のためのドメインを含むアプリケーションサーバ環境が１つ以上のコンピュータにおいて提供される。各パーティションはドメインの管理およびランタイム区分を提供し、パーティションは、デプロイ可能なアプリケーションまたはリソースの集合を有しおよび／またはリソースグループテンプレートを参照する１つ以上のリソースグループを随意に含み得る。

ステップ７４２では、如何なる特定のパーティションにおいても実行されないグローバルランタイムが提供されるが、その代りにドメインへ範囲指定される。１つ以上のリソースグループが随意に、グローバルランタイムによる使用のためにドメインレベルにて特定され得る。

ステップ７４４では、テナントに代わってグローバルランタイムによって関数を実行する要求を受信すると、グローバルランタイムはテナントスイッチングインターフェイスを介してテナントのコンテキストにスイッチングし、そのテナントとして、または、そのテナントに代わって、関数を実行し得る。

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

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

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

Claims (14)

1. マルチテナントアプリケーションサーバ環境においてグローバルランタイムをサポートするためのシステムであって、その上で実行されるアプリケーションサーバ環境を含む１つ以上のコンピュータを含み、それとともに、
   前記アプリケーションサーバ環境内において使用することが可能である複数のリソースと、
   １つ以上のパーティションとを含み、各パーティションは、テナントに関連付けられることが可能であるドメインの区分を提供しており、さらに、
   グローバルランタイムを含み、前記グローバルランタイムは、１つ以上のリソースまたはリソースグループを、前記グローバルランタイムで使用されるドメインレベルで特定できるように、前記ドメインに範囲指定される、システム。
2. 前記ドメイン内のデプロイ可能なリソースのグルーピングを定義するよう、１つ以上のリソースグループテンプレートが使用される、請求項１に記載のシステム。
3. ドメインレベルのリソースグループのターゲティングは、リソースグループに、前記リソースグループ内のすべてのリソースが前記リソースグループについて指定されたすべてのターゲットに対してターゲティングされるように、セットすることが可能である、請求項１〜２のいずれか１項に記載のシステム。
4. リソースグループがクラスタに対してターゲティングされるとき、前記リソースグループ内のアプリケーションは、前記クラスタ内の管理されるすべてのサーバ上で実行される、請求項１〜３のいずれか１項に記載のシステム。
5. マルチテナントアプリケーションサーバ環境においてグローバルランタイムをサポートするための方法であって、
   その上で実行されるアプリケーションサーバ環境を含む１つ以上のコンピュータにおいて、
   前記アプリケーションサーバ環境内において使用することが可能である複数のリソースと、
   １つ以上のパーティションとを提供することを含み、各パーティションは、テナントに関連付けられることが可能であるドメインの区分を提供しており、さらに、
   グローバルランタイムを提供することを含み、前記グローバルランタイムは、１つ以上のリソースまたはリソースグループを、前記グローバルランタイムで使用されるドメインレベルで特定できるように、前記ドメインに範囲指定される、方法。
6. 前記ドメイン内のデプロイ可能なリソースのグルーピングを定義するよう、１つ以上のリソースグループテンプレートが使用される、請求項５に記載の方法。
7. ドメインレベルのリソースグループのターゲティングは、リソースグループに、前記リソースグループ内のすべてのリソースが前記リソースグループについて指定されたすべてのターゲットに対してターゲティングされるように、セットすることが可能である、請求項５〜６のいずれか１項に記載の方法。
8. リソースグループがクラスタに対してターゲティングされるとき、前記リソースグループ内のアプリケーションは、前記クラスタ内の管理されるすべてのサーバ上で実行される、請求項５〜７のいずれか１項に記載の方法。
9. 命令が格納された非一時的なコンピュータ読取可能記憶媒体であって、前記命令が１つ以上のコンピュータによって読取られて実行されると、前記１つ以上のコンピュータに、
   アプリケーションサーバ環境と、それとともに、
   前記アプリケーションサーバ環境内において使用することが可能である複数のリソースと、１つ以上のパーティションとを提供する方法を実行させ、各パーティションは、テナントに関連付けられることが可能であるドメインの区分を提供しており、さらに、前記１つ以上のコンピュータに、
   グローバルランタイムを提供することを含む方法を実行させ、前記グローバルランタイムは、１つ以上のリソースまたはリソースグループを、前記グローバルランタイムで使用されるドメインレベルで特定できるように、前記ドメインに範囲指定される、非一時的なコンピュータ読取可能記憶媒体。
10. 前記ドメイン内のデプロイ可能なリソースのグルーピングを定義するよう、１つ以上のリソースグループテンプレートが使用される、請求項９に記載の非一時的なコンピュータ読取可能記憶媒体。
11. ドメインレベルのリソースグループのターゲティングは、リソースグループに、前記リソースグループ内のすべてのリソースが前記リソースグループについて指定されたすべてのターゲットに対してターゲティングされるように、セットすることが可能である、請求項９〜１０のいずれか１項に記載の非一時的なコンピュータ読取可能記憶媒体。
12. リソースグループがクラスタに対してターゲティングされるとき、前記リソースグループ内のアプリケーションは、前記クラスタ内の管理されるすべてのサーバ上で実行される、請求項９〜１１のいずれか１項に記載の非一時的なコンピュータ読取可能記憶媒体。
13. １つ以上のコンピュータシステム上での実行のためのプログラム命令を含むコンピュータプログラムであって、実行された際のプログラム命令は、前記１つ以上のコンピュータシステムに請求項５〜８のいずれか１項に記載の方法を実行させる、コンピュータプログラム。
14. 非一時的なマシン読取可能データ記憶媒体上に格納される、請求項１３に記載のコンピュータプログラムを含む、コンピュータプログラムプロダクト。