JP6703527B2 - マルチテナントアプリケーションサーバ環境におけるパーティション識別子の決定のためのシステムおよび方法 - Google Patents

Description

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

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

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

概要：
一実施形態に従って、アプリケーションサーバ環境におけるパーティション識別子の決定のためのシステムおよび方法が本明細書に記載される。例示的な方法は、アプリケーションサーバ環境が実行される１つ以上のコンピュータに、アプリケーションサーバ環境内で使用可能な複数のデプロイ可能なリソースと、各々がドメインの管理およびランタイム区分を提供する１つ以上のパーティションと、コンポーネント呼び出しコンテキストマネージャとをともに設けるステップから開始することができ、コンポーネント呼び出しコンテキストマネージャはスタックを備える。当該方法は、パーティション認識型コンテナにおいて１つ以上のコンポーネント呼び出しコンテキストを設定することができる。パーティション認識型コンテナは、現在のコンポーネント呼び出しコンテキストをコンポーネント呼び出しコンテキストマネージャに登録すること、または、コンポーネント呼び出しコンテキストマネージャにおいて現在のコンポーネント呼び出しコンテキストを探索することのうちの１つを実行することができる。現在のコンポーネント呼び出しコンテキストは、現在のパーティションに関連付けることができる。

一実施形態に従うと、マルチテナント動作環境のコンテキストにおいて本明細書に記載されている方法およびシステムは、サーブレットがＥＪＢコンテナをコールする例に下記されるように、非マルチテナント動作環境内でも使用することができる。

一実施形態に従うと、WebLogic環境におけるドメイン内のパーティションなどのパーティションは、ドメイン内のテナントとして位置決めすることができる。本システムおよび方法は、一般的な態様（すなわち、当該システムおよび方法がマルチテナントアプリケーションサーバ環境内でも非マルチテナントアプリケーションサーバ環境内でもテナント要求を識別できることを一般的に意味する）でのテナント要求の早期の識別を可能にすることができる。

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

詳細な説明：
一実施形態に従って、アプリケーションサーバ環境におけるパーティション識別子の決定のためのシステムおよび方法が本明細書に記載される。例示的な方法は、アプリケーションサーバ環境が実行される１つ以上のコンピュータに、アプリケーションサーバ環境内で使用可能な複数のデプロイ可能なリソースと、各々がドメインの管理およびランタイム区分を提供する１つ以上のパーティションと、コンポーネント呼び出しコンテキストマネージャとをともに設けるステップから開始することができ、コンポーネント呼び出しコンテキストマネージャはスタックを備える。当該方法は、パーティション認識型コンテナにおいて１つ以上のコンポーネント呼び出しコンテキストを設定することができる。パーティション認識型コンテナは、現在のコンポーネント呼び出しコンテキストをコンポーネント呼び出しコンテキストマネージャに登録すること、または、コンポーネント呼び出しコンテキストマネージャにおいて現在のコンポーネント呼び出しコンテキストを探索することのうちの１つを実行することができる。現在のコンポーネント呼び出しコンテキストは、現在のパーティションに関連付けることができる。

一実施形態に従うと、マルチテナント動作環境のコンテキストにおいて本明細書に記載されている方法およびシステムは、サーブレットがＥＪＢコンテナをコールする例に下記されるように、非マルチテナント動作環境内でも使用することができる。

一実施形態に従うと、WebLogic環境におけるドメイン内のパーティションなどのパーティションは、ドメイン内のテナントとして位置決めすることができる。本システムおよび方法は、一般的な態様（すなわち、当該システムおよび方法がマルチテナントアプリケーションサーバ環境内でも非マルチテナントアプリケーションサーバ環境内でもテナント要求を識別できることを一般的に意味する）でのテナント要求の早期の識別を可能にすることができる。

アプリケーションサーバ（たとえば、マルチテナント（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）」（リソースグループテンプレートにおいてマクロ置換のために使用可能なプロパティキー値を含む）を含む。

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

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

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

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

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

テナント
一実施形態に従うと、テナントは、パーティションＩＤに関連付けることができる。たとえば、テナントは、別個のユーザ組織、たとえばさまざまな外部会社、または特定の企業内のさまざまな部門（たとえばＨＲおよび財務部）などに関連付けることができる。

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

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

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

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

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

いくつかのインスタンスにおいては、パーティションが含み得るリソースグループは、リソースグループテンプレートを参照しないか、または、それら自体のパーティション範囲指定されたデプロイ可能なリソースを直接定義する。パーティション内で定義されるアプリケーションおよびデータソースは、概して、そのパーティションにとってのみ利用可能である。リソースは、パーティション：<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データベースを含むそれぞれのリソース３２４，３３４とに接続するためのものである。同じアプリケーションコードが両方のデータベースに対して実行され得るので、データベースインスタンスは互換性のあるスキーマを用いることができる。システムがパーティションを始動させると、当該システムは、それぞれのデータベースインスタンスに対する接続プールおよび仮想ターゲットを作成することができる。

パーティション識別子
一実施形態に従うと、アプリケーションサーバ環境内で、ＪＮＤＩ（Ｊａｖａネーミングおよびディレクトリインターフェイス）、ＪＭＸ（Ｊａｖａ管理拡張機能）、ロギング、ウェブコンテナおよびＲＣＭ（リソース消費管理）などのコンテナは、現在のまたは実行中の要求のパーティションＩＤをパーティション特有の処理、ロギングおよび分離ニーズに合わせて使用するために当該パーティションＩＤを決定することができる。

一実施形態に従うと、コンポーネント呼び出し要求または一般にアプリケーションサーバで受信されるその他の要求のために、ドメインにおけるパーティション内には当該要求のターゲットリソースが存在し得る。ターゲットリソース（すなわち要求のターゲットリソース）が存在するパーティションは、当該要求のためのパーティションコンテキストを決定することができる。

一実施形態に従うと、内部サーバ動作は、さまざまに処理されることができる。たとえば、内部サーバ動作は、特にドメイン内の特定の／個々のパーティション（たとえばパーティションに属するログファイルの回転）のために実行されることができる。このような内部サーバ動作では、パーティションコンテキストは、ターゲットリソースが存在するパーティションではなく、動作が実行されているパーティションであり得る。

一実施形態に従うと、他の内部サーバ動作は、任意の個々の／特定のパーティションに起因するものではない。このような内部サーバ動作としては、サーバランタイムの初期化および／または終了、コンテナのロードなどが挙げられるが、それらに限定されるものではない。特定のパーティションに起因しないこのような動作では、パーティションコンテキストは一般的な値に設定することができる。

図６は、一実施形態に従ったアプリケーションサーバ環境におけるパーティション識別子の決定を示す。図６に示される実施形態では、アプリケーションサーバ環境６００は、ドメイン６２０を含む。ドメイン６２０は、フロントエンドコンポーネント６３０に関連付けることができ、コンテナ６４０と、ＣＩＣ（コンポーネント呼び出しコンテキスト）ＡＰＩ６４５と、コンポーネント呼び出しコンテキストマネージャ（ＣＩＣマネージャ）６５０と、パーティションＡ６６０と、パーティションＢ６７０と、仮想ターゲットＡ６６２と、仮想ターゲットＢ６７２とを含み得る。フロントエンドコンポーネントは、たとえばオラクル（商標）トラフィックディレクタなどの、入来要求を処理することができる任意のフロントエンドコンポーネントであり得る。コンテナ６４０は、たとえばＪＮＤＩ、ＪＭＸ、ロギング、ＲＣＭなどのパーティション認識型コンテナであり得る。パーティションＡおよびＢは、それぞれリソースグループ６６１および６７１を含み得る。リソースグループ６６１および６７１は、それぞれ仮想ターゲットＡ６６２および仮想ターゲットＢ６７２に関連付けることができる。ＣＩＣマネージャ６５０は、スレッドローカルスタック６５１などのスタックを含み得る。

一実施形態に従うと、ユーザまたはプロセス６１０は、要求６１５を開始することができ、当該要求は、ドメイン６２０内の当該要求のターゲットのためのターゲット情報を含む。たとえば、パーティションＡ６６０の認定ユーザは、パーティションＡ内の特定のアプリケーションを実行するよう要求することができる。この状況において、要求６１５に関連付けられたターゲット情報は、少なくともパーティションＡを要求のターゲットとして識別するであろう。

一実施形態に従うと、ターゲット情報６１５を含む要求などの要求がドメイン６２０に向けられると、当該要求はトラフィックディレクタなどのフロントエンドコンポーネント６３０に転送されることができる。フロントエンドコンポーネント６３０で受信されると、コンテナ６４０は、要求のターゲットコンポーネント／リソースのさまざまな詳細を決定することができる。これらの詳細は、たとえば、要求内に含まれるターゲット情報を調べることによって取得することができる。コンテナ６４０が要求のターゲットコンポーネント／リソースを決定すると、コンテナはコンポーネント呼び出しコンテキスト６５２を作成することができ、当該コンポーネント呼び出しコンテキスト６５２は、呼び出しを表わすオブジェクトとして返すことができる。一実施形態に従うと、決定されたコンポーネント呼び出しコンテキスト６５２は、要求次第で、パーティション識別子６６５または６７５に関連付けることができる。

入来要求の詳細を決定してコンポーネント呼び出しコンテキストオブジェクトを作成するコンテナの一例として、入来要求６１５がＨＴＴＰ要求であるとする。入来ＨＴＴＰ要求のＵＲＩを介して、ウェブ（ＨＴＴＰ）コンテナは、ＨＴＴＰ要求がターゲットとするパーティションＩＤ、アプリケーションＩＤ、モジュールおよびコンポーネントＩＤを決定することができる。この決定は、たとえば、要求のターゲットを区別できるように十分な情報が要求から読取られた後にＨＴＴＰプロトコルハンドラによってソケットリーダスレッドにおいて行うことができる。この情報に基づいて、コンテナは、入来ＨＴＴＰ要求のためのオブジェクト、すなわちコンポーネント呼び出しコンテキストを作成することができる。

一実施形態に従うと、要求がドメイン６２０に向けられると、当該要求はトラフィックディレクタなどのフロントエンドコンポーネント６３０に転送されることができる。フロントエンドコンポーネント６３０で受信されると、コンテナ６４０は、要求のターゲットコンポーネント／リソースのさまざまな詳細を決定することができる。これらの詳細は、たとえば、要求内に含まれるターゲット情報を調べることによって取得することができる。コンテナ６４０が要求のターゲットコンポーネント／リソースを決定すると、コンテナはコンポーネント呼び出しコンテキスト６５２を作成することができ、当該コンポーネント呼び出しコンテキスト６５２は、呼び出しを表わすためのオブジェクトであり得る。一実施形態に従うと、決定されたコンポーネント呼び出しコンテキスト６５２は、パーティション識別子６６５または６７５に関連付けることができる。

一実施形態に従うと、コンテナが決定を行って入来要求のコンポーネント呼び出しコンテキスト、すなわちオブジェクトを作成すると、コンテナは、次いで、コンポーネント呼び出しコンテキストをコンポーネント呼び出しコンテキストマネージャ６５０に登録することができ、当該コンポーネント呼び出しコンテキストマネージャ６５０は、スタック、たとえばスレッドローカルスタック６５１を含み得て、当該スレッドローカルスタック６５１は、さらには、さまざまなコンポーネント呼び出しコンテキスト、たとえばコンポーネント呼び出しコンテキスト（Ａ）〜（Ｄ）６５２〜６５５を含む。なお、スレッドローカルスタック６５１は、コンポーネント呼び出しコンテキストをいくつ含んでもよく、図６に示される４つのコンポーネント呼び出しコンテキストに限定されるものではない。コンポーネント呼び出しコンテキストマネージャ６５０は、現在のコンポーネント呼び出しコンテキストの探索、登録および登録解除を可能にすることができる。

一実施形態に従うと、コンテナは、ＣＩＣ ＡＰＩ６４５を介してコンポーネント呼び出しコンテキストオブジェクトをコンポーネント呼び出しコンテキストマネージャに直接登録することができる。コンテナは、このコンポーネント呼び出しコンテキストの直接的な登録を、要求のための決定されたコンポーネント呼び出しコンテキストをプッシュするためのpushComponentInvocationContextなどのコマンドを用いて実現することができる。このような新たなコンポーネント呼び出しコンテキストをコンポーネント呼び出しコンテキストマネージャに登録する方法を利用するコンテナは、要求に関連付けられた呼び出しが完了するとコンポーネント呼び出しコンテキストの設定解除／登録解除も処理することができる。呼び出しが成功裏に完了して初めてコンテナがコンポーネント呼び出しコンテキストマネージャにおけるコンポーネント呼び出しコンテキストを登録解除／設定解除することは、必要条件ではない。呼び出しの結果として例外処理が実行されるなど、呼び出しが失敗に終わったことによっても、コンテナは、コンポーネント呼び出しマネージャにおけるコンポーネント呼び出しコンテキストの設定解除／登録解除を行うことができる。コンポーネント呼び出しコンテキストマネージャにおけるコンポーネント呼び出しコンテキストの設定解除／登録解除は、コンポーネント呼び出しコンテキストマネージャ上でpopComponentInvocationContetなどのコマンドを介して実行することができる。

一実施形態に従うと、コンテナは、ＣＩＣ ＡＰＩ６４５を介してコンポーネント呼び出しコンテキストオブジェクトをコンポーネント呼び出しコンテキストマネージャに直接登録することができる。コンテナは、実行すべきcallabeを渡すことによってrunAs方法を使用することができる。この状況において、コンポーネント呼び出しコンテキストマネージャは、コンポーネント呼び出しコンテキストを確立することができる。これにより、コンテナは、コンポーネント呼び出しコンテキストのコンテキストにおいて動作を起動し、動作を実行し、呼び出しが完了した後にコンポーネント呼び出しコンテキストを設定解除することが可能になる。

一実施形態に従うと、コンテナは、ＣＩＣ ＡＰＩ６４５を介してコンポーネント呼び出しコンテキストオブジェクトをコンポーネント呼び出しコンテキストマネージャに直接登録することができる。コンテナは、try-with-resourcesスタイルブロック内のsetCurrentComponentInvocationContext方法によって返されるAutoCloseableを使用することができる。この場合、ＣＩＣマネージャは、AutoCloseableによるtryブロックの終了時に自動的に呼び出しコンテキストを設定解除することができる。このアプローチは、作業の実行中にＣＩＣマネージャが正しいＣＩＣコンテキストを確立するという利点がありながらも、呼び出し元が作業をRunnableまたはCloseableに変更する必要がないなどの利点を提供することができる。

図７は、一実施形態に従ったアプリケーションサーバ環境におけるパーティション識別子の決定を示す。図７に示される実施形態では、アプリケーションサーバ環境６００は、ドメイン６２０を含む。ドメイン６２０は、フロントエンドコンポーネント６３０に関連付けることができ、コンテナ６４０を含み得て、当該コンテナ６４０は、サービスプロバイダインターフェイス７２０を含み得る。ドメインは、ワークマネージャ７３０と、コンポーネント呼び出しコンテキストマネージャ（ＣＩＣマネージャ）６５０と、パーティションＡ６６０と、パーティションＢ６７０と、仮想ターゲットＡ６６２と、仮想ターゲットＢ６７２とをさらに含み得る。フロントエンドコンポーネントは、たとえばオラクル（商標）トラフィックディレクタなどの、入来要求を処理することができる任意のフロントエンドコンポーネントであり得る。コンテナ６４０は、たとえばＪＮＤＩ、ＪＭＸ、ロギング、ＲＣＭなどのパーティション認識型コンテナであり得る。パーティションＡおよびＢは、それぞれリソースグループ６６１および６７１を含み得る。リソースグループ６６１および６７１は、それぞれ仮想ターゲットＡ６６２および仮想ターゲットＢ６７２に関連付けることができる。ＣＩＣマネージャ６５０は、スレッドローカルスタック６５１などのスタックを含み得る。

一実施形態に従うと、ユーザは、要求６１５を開始することができ、当該要求は、ドメイン６２０内の要求のターゲットのターゲット情報を含む。たとえば、ユーザ、プロセッサ、またはパーティションＡ６６０へのアクセスを有する他のアプリケーションは、パーティションＡ内の特定のアプリケーションを実行するよう要求することができる。この状況において、要求６１５に関連付けられたターゲット情報は、少なくともパーティションＡを要求のターゲットとして識別するであろう。要求が（同一のドメイン内または別のドメインからの）別のパーティションから生じる状況においては、発生元のパーティションのコンポーネント呼び出しコンテキストは要求に含まれない。

一実施形態に従うと、ターゲット情報６１５を含む要求などの要求がドメイン６２０に向けられると、当該要求はトラフィックディレクタなどのフロントエンドコンポーネント６３０に転送されることができる。フロントエンドコンポーネント６３０で受信されると、コンテナ６４０は、要求のターゲットコンポーネント／リソースのさまざまな詳細を決定することができる。これらの詳細は、たとえば、要求内に含まれるターゲット情報を調べることによって取得することができる。コンテナ６４０が要求のターゲットコンポーネント／リソースを決定すると、コンテナはコンポーネント呼び出しコンテキスト６５２を作成することができ、当該コンポーネント呼び出しコンテキスト６５２は、呼び出しを表わすためのオブジェクトであり得る。一実施形態に従うと、決定されたコンポーネント呼び出しコンテキスト６５２は、要求次第で、パーティション識別子６６５または６７５に関連付けることができる。

一実施形態に従うと、コンテナが決定を行って入来要求のコンポーネント呼び出しコンテキスト、すなわちオブジェクトを作成すると、コンテナは、コンポーネント呼び出しコンテキストをコンポーネント呼び出しコンテキストマネージャ６５０に間接的に登録することができ、当該コンポーネント呼び出しコンテキストマネージャ６５０は、スレッドローカルスタック６５１などのスタックを含み得て、当該スレッドローカルスタック６５１は、さらには、さまざまなコンポーネント呼び出しコンテキスト、たとえばコンポーネント呼び出しコンテキスト（Ａ）〜（Ｄ）６５２〜６５５を含む。スレッドローカルスタック６５１は、コンポーネント呼び出しコンテキストをいくつ含んでもよく、図７に示される４つのコンポーネント呼び出しコンテキストに限定されるものではない。コンポーネント呼び出しコンテキストマネージャ６５０は、現在のコンポーネント呼び出しコンテキストの探索、登録および登録解除を可能にすることができる。

一実施形態に従うと、コンポーネント呼び出しコンテキストの間接的な登録は、ワークマネージャ７３０によって実行することができる。たとえば、コンテナ６４０は、ワークマネージャ７３０を介して別個のスレッドにおいて非同期的に要求の次のレベルの処理をディスパッチすることができる。ＳＰＩは、スレッドにおけるコンポーネントコンテキストの設定を容易にすることができる。コンポーネント要求インターフェイス７１０は、コンテナ６４０によって提供されることができ、それ自体のコンポーネント呼び出しコンテキストに従って、要求に関連付けられた作業を実行することを可能にすることができる。コンポーネント要求インターフェイス７１０は、コンテナがターゲットコンポーネントの詳細（すなわちコンポーネント呼び出しコンテキスト戻り値）を提供するためのgetComponentInvocationContextなどのコマンドも含み得る。コンポーネント要求７１０インスタンスが実行される前に、ワークマネージャ７３０は、コンポーネント呼び出しコンテキストマネージャ６５０を探索して、getComponentInvocationContextコマンドによって提供されるコンポーネント呼び出しコンテキストを用いて新たなコンポーネント呼び出しコンテキストを登録することができる。コンポーネント要求７１０インスタンスの実行が完了すると、ワークマネージャ７３０は、コンポーネント呼び出しコンテキストマネージャからコンポーネント呼び出しコンテキストを自動的に除去することができる。

一実施形態に従うと、ＣＩＣマネージャは、現在の呼び出し要求のためのスレッドローカルスタックを用いることによってスレッドごとにＣＩＣ状態を維持することができる。なぜなら、要求は一般に単一のスレッドに関連付けられるからである。要求に対する作業が複数のスレッドによって処理される状況においては、異なるスレッドにおいて作業を実行するコンテナは、上記のgetComponentInvocationContextコマンドを利用して、スレッドのＣＩＣを新たなスレッドに渡すことを確実にすることができる。

図８は、一実施形態に従ったアプリケーションサーバ環境におけるパーティション識別子の決定を示す。図８に示される実施形態では、アプリケーションサーバ環境６００は、ドメイン６２０を含む。ドメイン６２０は、フロントエンドコンポーネント６３０と、コンテナ６４０と、ＣＩＣ ＡＰＩ６４５と、コンポーネント呼び出しコンテキストマネージャ（ＣＩＣマネージャ）６５０と、パーティションＡ６６０と、パーティションＢ６７０と、仮想ターゲットＡ６６２と、仮想ターゲットＢ６７２とを含む。フロントエンドコンポーネントは、たとえばオラクル（商標）トラフィックディレクタなどの、入来要求を処理することができる任意のフロントエンドコンポーネントであり得る。コンテナ６４０は、たとえばＪＮＤＩ、ＪＭＸ、ロギング、ＲＣＭなどのパーティション認識型コンテナであり得る。パーティションＡおよびＢは、それぞれリソースグループ６６１および６７１を含み得る。リソースグループ６６１および６７１は、それぞれ仮想ターゲットＡ６６２および仮想ターゲットＢ６７２に関連付けることができる。ＣＩＣマネージャ６５０は、スレッドローカルスタック６５１などのスタックを含み得る。

一実施形態に従うと、コンテナ６４０は、getCurrentComponentInvocationなどのコマンドによってＡＰＩ６４５を介してコンポーネント呼び出しマネージャから現在のコンポーネント呼び出しコンテキストを検索することができる。たとえば、図８に示されるように、コンポーネント呼び出しコンテキストマネージャは、考えられるコンポーネント呼び出しコンテキスト、たとえばコンポーネント呼び出しコンテキスト（Ａ）〜（Ｄ）６５２〜６５５の中から、現在はコンポーネント呼び出しコンテキスト６５２に設定されている。コンテナ６４０は、ＡＰＩ６４５を介してコンポーネント呼び出しコンテキストマネージャ６５０から現在のコンポーネント呼び出しコンテキスト８１０を得ることができる。

図９は、一実施形態に従ったマルチテナントアプリケーションサーバ環境におけるパーティション識別子の決定のための方法をフローチャートによって示す。例示的な方法９００は、ステップ９１０から開始することができ、ステップ９１０では、アプリケーションサーバ環境が実行される１つ以上のコンピュータに、アプリケーションサーバ環境内で使用可能な複数のデプロイ可能なリソースと、各々がドメインの管理およびランタイム区分を提供する１つ以上のパーティションと、コンポーネント呼び出しコンテキストマネージャとをともに設け、コンポーネント呼び出しコンテキストマネージャはスタックを備える。当該方法はステップ９２０に進み、ステップ９２０では、当該方法は、パーティション認識型コンテナにおいて、１つ以上のコンポーネント呼び出しコンテキストを設定することができる。ステップ９３０において、当該例示的な方法は、続いて、パーティション認識型コンテナによって、現在のコンポーネント呼び出しコンテキストをコンポーネント呼び出しコンテキストマネージャに登録すること、または、コンポーネント呼び出しコンテキストマネージャにおいて現在のコンポーネント呼び出しコンテキストを探索することのうちの１つを実行する。当該例示的な方法は、ステップ９４０において終了することができ、ステップ９４０では、現在のコンポーネント呼び出しコンテキストを現在のパーティションに関連付ける。

コンポーネント呼び出しコンテキストの伝搬
一実施形態に従うと、コンポーネント呼び出しコンテキストマネージャは、関連付けられた要求の期間中ずっと、コンポーネント呼び出しコンテキストの詳細の伝搬を担当することができる。パーティションコンテキスト情報は、ローカル呼び出し全体に伝搬することができる。コンポーネント呼び出しコンテキストの他のサブコンテキストは、どのコンポーネントが要求の処理に関与するかに基づいてそれぞれのコンテナによって決定することができる。コンポーネント呼び出しコンテキストは、どのＡＰＩを用いてスレッドを生成するかにかかわらず、新たなスレッドが生成されるたびに自動的に受け継がれることができる。

コンポーネント呼び出しコンテキストの検索
上記のように、一実施形態に従うと、コンポーネント呼び出しコンテキストの詳細（たとえばパーティションＩｄ）を必要とするいかなる内部コードまたは（ＪＮＤＩなどの）コンテナも、コンポーネント呼び出しコンテキストマネージャを探索して、getCurrentComponentInvocationなどの方法を介して現在のコンポーネント呼び出しコンテキストを決定することができる。コンポーネント呼び出しコンテキストのパーティションＩＤは、グローバルパーティションＩＤおよびユーザパーティションＩＤを含むいくつかの値を有することができる。

一実施形態に従うと、グローバルパーティションＩＤは、以下の状況で使用することができる。要求のターゲットコンポーネントがグローバルパーティション（すなわちドメイン）に存在するとサーバが判断すると、コンテナは、パーティションＩＤをグローバルパーティションのＩＤに設定することができる。また、グローバルパーティションＩＤは、ユーザパーティションに特有でない内部サーバ動作（たとえば、サーバランタイムの初期化／終了、コンテナのロードなど）で使用することができる。サーバランタイム時のこのような動作が特にパーティションを代表して行われているのではない場合、コンテナは、パーティションＩＤをグローバルパーティションのＩＤに設定することができる。他の実施形態では、グローバルパーティション作業と、パーティションｉｄが共有システムパーティションを表わすようにすることによる共有作業とを区別することができる。

一実施形態に従うと、ユーザパーティションＩＤは、以下の状況で使用することができる。要求がユーザパーティションに存在するコンポーネントをターゲットとする場合、サーバは、パーティションＩＤをユーザパーティションのＩＤに設定することができる。また、任意のサーバ動作が或るパーティション（たとえば、特定のパーティションのためのログファイルの自動回転）のために特別に実行される場合、コンポーネント呼び出しコンテキストにおいてパーティションのＩＤを設定することができる。

一実施形態に従うと、現在のコンポーネント呼び出しコンテキストは、ヌルでない値である。たとえば、スレッドがコンテキストを確立させない状況においては、グローバルパーティションを表わす（すなわち、アプリケーション、モジュール、ならびにコンポーネントＩＤおよび名前のためのヌル値を有する）ヌルでないコンポーネント呼び出しコンテキストを返すことができる。別の例として、スレッドが作成されるが当該スレッドにおいて新たなコンテキストが確立されない状況においては、スレッドは、作成されたスレッドのコンテキストを自動的に受け継ぐことができる。

コンポーネント呼び出しコンテキストスタック
一実施形態に従うと、要求が（たとえば、別のコンポーネントに対するローカルコールとして、たとえばenterprise JavaBean（ＥＪＢ）をコールするサーブレットとして）複数のコンポーネントにまたがる状況においては、ターゲットコンテナ（この例においては、ＥＪＢコンテナ）は、ＥＪＢ呼び出しを処理する前に、新たなモジュールおよびコンポーネントＩＤを含む新たなコンポーネント呼び出しコンテキストを確立することができる。また、ターゲットコンテナは、ＥＪＢコールが成功裏に完了すると、コンポーネント呼び出しコンテキストを設定解除することができる。コンポーネント呼び出しコンテキストマネージャは、コンポーネント呼び出しのリストをスタックとして内部で管理することができる。当該スタックは、呼び出しのコンテキスト内でなされるローカルコールに関連付けられたコンポーネント呼び出しコンテキストを表わすことができる。

一例として、サーブレットＳ１がローカルＥＪＢ Ｅ１をコールする状況においては、コンポーネント呼び出しコンテキストマネージャは、サーブレットＳ１およびＥＪＢ Ｅ１に対応するコンポーネント呼び出しコンテキストのスタックを内部に維持することができる。ＥＪＢ Ｅ１の実行中、componentinvocationcmanager.getCurrentComponentInvocationContext()に対するコールは、Ｅ１に対応するコンポーネント呼び出しコンテキストを現在のコンポーネント呼び出しコンテキストとして返すことができる。ＥＪＢ Ｅ１の実行が完了するとすぐに、ＥＪＢコンテナは、Ｅ１に対応するコンポーネント呼び出しコンテキストを設定解除することができ、コンポーネント呼び出しコンテキストマネージャは、次いで、componentinvocationcontextmanager.getCurrentComponentInvocationContext()に対するいかなる後続のコールについても、Ｓ１に対応するコンポーネント呼び出しコンテキストを現在の呼び出しコンテキストとして確立するであろう。

一実施形態に従うと、スタック内の全ての呼び出しオブジェクトを検索するための内部方法も利用可能にすることができる。

ＡＰＩ
ここで、一実施形態に従って、ＡＰＩクラスおよびインターフェイスの例を列挙する。

一実施形態に従って、ＡＰＩクラスComponentInvocationContextManagerの例示的なインプリメンテーションを以下に記載する。

ここで、さらなる例示的なＡＰＩを記載する。

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

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

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

Claims (15)

1. アプリケーションサーバ環境におけるパーティション識別子の決定のためのシステムであって、
   １つ以上のコンピュータを備え、前記１つ以上のコンピュータは、前記１つ以上のコンピュータ上で実行されるアプリケーションサーバ環境を、
   前記アプリケーションサーバ環境内で使用可能な複数のデプロイ可能なリソースと、
   各々がドメインの管理およびランタイム区分を提供する１つ以上のパーティションとともに含み、
   前記システムはさらに、
   １つ以上のコンポーネント呼び出しコンテキストを設定するように構成されたパーティション認識型コンテナと、
   コンポーネント呼び出しコンテキストマネージャとを備え、前記コンポーネント呼び出しコンテキストマネージャは、スタックを含み、
   前記パーティション認識型コンテナは、現在のコンポーネント呼び出しコンテキストを前記コンポーネント呼び出しコンテキストマネージャに登録すること、および、前記コンポーネント呼び出しコンテキストマネージャにおける現在のコンポーネント呼び出しコンテキストを探索することのうちの一方を実行し、
   前記現在のコンポーネント呼び出しコンテキストは、現在のパーティションに関連付けられる、システム。
2. 前記現在のコンポーネント呼び出しコンテキストを登録することは、
   フロントエンドコンポーネントにおいて、ターゲット情報を含む要求を受信することを備え、前記ターゲット情報は、前記現在のパーティションを示し、前記登録することはさらに、
   前記パーティション認識型コンテナによって前記現在のコンポーネント呼び出しコンテキストを決定することと、
   前記パーティション認識型コンテナによって、アプリケーションプログラムインターフェイスを介して、前記現在のコンポーネント呼び出しコンテキストを前記コンポーネント呼び出しコンテキストマネージャに登録することとを備える、請求項１に記載のシステム。
3. 前記パーティション認識型コンテナは、前記現在のコンポーネント呼び出しコンテキストを前記コンポーネント呼び出しコンテキストマネージャに登録した後、前記要求の完了時に、前記コンポーネント呼び出しコンテキストマネージャにおける前記現在のコンポーネント呼び出しコンテキストを登録解除するように構成され、前記登録解除することは、
   前記パーティション認識型コンテナによって、前記アプリケーションプログラムインターフェイスを介して、前記コンポーネント呼び出しコンテキストマネージャにおける前記現在のコンポーネント呼び出しコンテキストを登録解除することを備える、請求項２に記載のシステム。
4. ワークマネージャをさらに備え、
   前記パーティション認識型コンテナによって前記現在のコンポーネント呼び出しコンテキストを前記コンポーネント呼び出しコンテキストマネージャに登録することは、前記現在のコンポーネント呼び出しコンテキストを前記コンポーネント呼び出しコンテキストマネージャに登録するために前記パーティション認識型コンテナによって前記ワークマネージャに命令を渡すことを備える、請求項１から３のいずれか１項に記載のシステム。
5. 前記現在のコンポーネント呼び出しコンテキストを探索することは、
   前記パーティション認識型コンテナによって、前記コンポーネント呼び出しコンテキストマネージャに前記現在のコンポーネント呼び出しコンテキストを要求することと、
   前記パーティション認識型コンテナ内で前記現在のコンポーネント呼び出しコンテキストを設定することとを備える、請求項１から４のいずれか１項に記載のシステム。
6. 前記現在のパーティションは、前記１つ以上のパーティションのうちの１つからなる群またはグローバルパーティションのうちの１つであり、前記グローバルパーティションは、前記ドメインに関連付けられる、請求項１から５のいずれか１項に記載のシステム。
7. 前記アプリケーションサーバ環境は、マルチテナントアプリケーションサーバ環境を備え、前記システムは、テナントによる使用のために前記１つ以上のパーティションを前記テナントに関連付けることができる、請求項１から６のいずれか１項に記載のシステム。
8. アプリケーションサーバ環境におけるパーティション識別子の決定のための方法であって、
   １つ以上のコンピュータ上で実行されるアプリケーションサーバ環境を含む１つ以上のコンピュータにおいて、
   前記アプリケーションサーバ環境内で使用可能な複数のデプロイ可能なリソースと、
   各々がドメインの管理およびランタイム区分を提供する１つ以上のパーティションと、
   コンポーネント呼び出しコンテキストマネージャとをともに設けるステップを備え、前記コンポーネント呼び出しコンテキストマネージャは、スタックを備え、前記方法はさらに、
   パーティション認識型コンテナにおいて、１つ以上のコンポーネント呼び出しコンテキストを設定するステップと、
   前記パーティション認識型コンテナによって、現在のコンポーネント呼び出しコンテキストを前記コンポーネント呼び出しコンテキストマネージャに登録すること、および、前記コンポーネント呼び出しコンテキストマネージャにおける現在のコンポーネント呼び出しコンテキストを探索することのうちの一方を実行するステップと、
   前記現在のコンポーネント呼び出しコンテキストを現在のパーティションに関連付けるステップとを備える、方法。
9. 前記現在のコンポーネント呼び出しコンテキストを登録することは、
   フロントエンドコンポーネントにおいて、ターゲット情報を含む要求を受信することを備え、前記ターゲット情報は、前記現在のパーティションを示し、前記登録することはさらに、
   前記パーティション認識型コンテナによって前記現在のコンポーネント呼び出しコンテキストを決定することと、
   前記パーティション認識型コンテナによって、アプリケーションプログラムインターフェイスを介して、前記現在のコンポーネント呼び出しコンテキストを前記コンポーネント呼び出しコンテキストマネージャに登録することとを備える、請求項８に記載の方法。
10. 前記パーティション認識型コンテナは、前記現在のコンポーネント呼び出しコンテキストを前記コンポーネント呼び出しコンテキストマネージャに登録した後、前記要求の完了時に、前記コンポーネント呼び出しコンテキストマネージャにおける前記現在のコンポーネント呼び出しコンテキストを登録解除するように構成され、前記登録解除することは、
    前記パーティション認識型コンテナによって、前記アプリケーションプログラムインターフェイスを介して、前記コンポーネント呼び出しコンテキストマネージャにおける前記現在のコンポーネント呼び出しコンテキストを登録解除することを備える、請求項９に記載の方法。
11. アプリケーションサーバ環境が実行される前記１つ以上のコンピュータにワークマネージャをさらに設けるステップをさらに備え、
    前記パーティション認識型コンテナによって前記現在のコンポーネント呼び出しコンテキストを前記コンポーネント呼び出しコンテキストマネージャに登録することは、前記現在のコンポーネント呼び出しコンテキストを前記コンポーネント呼び出しコンテキストマネージャに登録するために前記パーティション認識型コンテナによって前記ワークマネージャに命令を渡すことを備える、請求項８から１０のいずれか１項に記載の方法。
12. 前記現在のコンポーネント呼び出しコンテキストを探索することは、
    前記パーティション認識型コンテナによって、前記コンポーネント呼び出しコンテキストマネージャに前記現在のコンポーネント呼び出しコンテキストを要求することと、
    前記パーティション認識型コンテナ内で前記現在のコンポーネント呼び出しコンテキストを設定することとを備える、請求項８から１１のいずれか１項に記載の方法。
13. 前記現在のパーティションは、前記１つ以上のパーティションのうちの１つからなる群またはグローバルパーティションのうちの１つであり、前記グローバルパーティションは、前記ドメインに関連付けられる、請求項８から１２のいずれか１項に記載の方法。
14. 前記アプリケーションサーバ環境は、マルチテナントアプリケーションサーバ環境を備え、前記方法は、
    テナントによる使用のために前記１つ以上のパーティションを前記テナントに関連付けるステップをさらに備える、請求項８から１３のいずれか１項に記載の方法。
15. １つ以上のコンピュータシステム上で実行されるプログラム命令を備えるコンピュータプログラムであって、前記プログラム命令は、実行されたときに、前記１つ以上のコンピュータシステムに、請求項８から１４のいずれか１項に記載の方法を実行させる、コンピュータプログラム。