JP2017520861A - マルチテナントアプリケーションサーバ環境でネームスペースをサポートするためのシステムおよび方法 - Google Patents

Abstract

ある実施形態に従うと、マルチテナントアプリケーションサーバ環境でネームスペースをサポートするためのシステムおよび方法が本明細書に記載される。アプリケーションサーバ環境は、複数のパーティションを有するドメインを含み得る。ドメインレベルのリソースにバインドされるグローバルネームスペースまたはＪＮＤＩツリーはパーティションルートノードのコレクションを維持することができ、各パーティションルートノードはパーティションＪＮＤＩツリーのルートノードである。パーティションＪＮＤＩツリー内の各ノードは、特定のパーティションに特有のプロパティを含むことによってパーティション認識型にさせられる。パーティションについての最初のコンテキストは、リソースルックアップ要求を当該パーティションにディスパッチする際に用いるために作成され得、当該パーティション内のリソースにアクセスする際に他のアプリケーションによって再利用され得る。

Description

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

発明の分野：
本発明の実施形態は概してアプリケーションサーバおよびクラウドプラットフォーム環境に関し、特に、マルチテナントアプリケーションサーバ環境でネームスペースをサポートするためのシステムおよび方法に関する。

背景：
ソフトウェアアプリケーションサーバは、その例として、Oracle WebLogic Server（ＷＬＳ）およびGlassfishを含み、エンタープライズソフトウェアアプリケーションを実行するための管理環境を一般に提供する。近年、ユーザまたはテナントが自身のアプリケーションをクラウド環境内で開発して実行すること、および当該環境によって提供される分散リソースを利用することを可能にする、クラウド環境で用いる技術も開発されている。

要約：
一実施形態に従うと、マルチテナントアプリケーションサーバ環境でネームスペースをサポートするためのシステムおよび方法が本明細書に記載される。アプリケーションサーバ環境は、複数のパーティションを有するドメインを含むことができる。ドメインレベルのリソースにバインドされるグローバルネームスペースまたはＪＮＤＩツリーはパーティションルートノードのコレクションを維持することができ、各パーティションルートノードはパーティションＪＮＤＩツリーのルートノードである。パーティションＪＮＤＩツリー内の各ノードは、特定のパーティションに特有のプロパティを含むことによってパーティション認識型にさせられる。パーティションについての最初のコンテキストは、リソースルックアップ要求を当該パーティションにディスパッチする際に用いるために作成され得、当該パーティション内のリソースにアクセスする際に他のアプリケーションによって再利用され得る。

一実施形態に従う、アプリケーションサーバ、クラウド、または他の環境でマルチテナンシをサポートするためのシステムを示す図である。 一実施形態に従う、アプリケーションサーバ、クラウド、または他の環境でマルチテナンシをサポートするためのシステムをさらに示す図である。 一実施形態に従う、アプリケーションサーバ、クラウド、または他の環境でマルチテナンシをサポートするためのシステムをさらに示す図である。 一実施形態に従う、例示的なマルチテナント環境とともに用いるドメイン設定を示す図である。 一実施形態に従う、例示的なマルチテナント環境をさらに示す図である。 一実施形態に従う、アプリケーションサーバ環境、クラウドまたは他の環境で、ドメイン内の複数のパーティションＪＮＤＩツリーをサポートするためのシステムを示す図である。 一実施形態に従う、アプリケーションサーバ環境、クラウドまたは他の環境で、ドメイン内の複数のパーティションＪＮＤＩツリーをサポートするためのシステムをさらに示す図である。 一実施形態に従う、アプリケーションサーバ環境、クラウドまたは他の環境で、ドメイン内の複数のパーティションＪＮＤＩツリーをサポートするための方法を示す図である。 一実施形態に従う、アプリケーションサーバ環境、クラウドまたは他の環境で、ドメイン内の複数のパーティションＪＮＤＩツリーをサポートするための例示的なシステムを示す図である。

詳細な説明：
一実施形態に従うと、マルチテナントアプリケーションサーバ環境でネームスペースをサポートするためのシステムおよび方法が本明細書に記載される。アプリケーションサーバ環境は、複数のパーティションを有するドメインを含むことができる。ドメインレベルのリソースにバインドされるグローバルネームスペースまたはＪＮＤＩツリーはパーティションルートノードのコレクション(collection：集まり）を保ち維持することができ、各パーティションルートノードはパーティションＪＮＤＩツリーのルートノードである。パーティションＪＮＤＩツリー内の各ノードは、特定のパーティションに特有のプロパティを含むことによってパーティション認識型にさせられる。パーティションについての最初のコンテキストは、リソースルックアップ要求を当該パーティションにディスパッチ（出力）する際に用いるために作成され得、当該パーティション内のリソースにアクセスする際に他のアプリケーションによって再利用され得る。

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

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

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

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

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

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

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

図２に示されるリソースグループテンプレートは一例として提供されており、他の実施形態に従うと、異なる種類のリソースグループテンプレートおよび要素が提供され得る。

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

同様に、一実施形態に従うと、特定のパーティションと関連付けられた仮想ターゲット情報が用いられ、たとえばbaylandurgentcare.comなどの、当該パーティションによって用いるためのパーティション特有の仮想ターゲット２４０を定義２３９することができ、これは次に、たとえばhttp://baylandurgentcare.comなどの統一資源位置指定子（ＵＲＬ）を介してアクセス可能にされ得る。

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

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

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

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

上記の例のいくつかはＣＤＢおよびＰＤＢの使用を例示しているが、他の実施形態に従うと、他の種類のマルチテナントまたは非マルチテナントデータベースをサポートすることができ、たとえばスキーマを用いて、または異なるデータベースを用いて、特定の設定をパーティションごとに提供することができる。

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

パーティション
一実施形態に従うと、パーティションは、パーティション識別子（ＩＤ）およびコンフィグレーション情報と関連付けられることができ、かつアプリケーションを含むことができる、ならびに／またはリソースグループおよびリソースグループテンプレートを用いてドメインワイドのリソースを参照することができる、ドメインのランタイムおよび管理サブディビジョンまたはスライスである。

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

一実施形態に従うと、パーティション内の各リソースグループは１つ以上のリソースグループテンプレートを参照することができる。各パーティションは、当該パーティションのリソースグループが参照するリソースグループテンプレート内に指定されていない設定データについてのプロパティを定義することができる。これによって、当該パーティションは、そのパーティションとともに用いる特定値への、リソースグループテンプレート内に定義されるデプロイ可能なリソースのバインディングとして機能することができる。場合によっては、パーティションは、リソースグループテンプレートによって指定されるコンフィグレーション情報をオーバーライドすることができる。

一実施形態に従うと、たとえばconfig.xmlコンフィグレーションファイルによって定義されるようなパーティションのコンフィグレーション情報は、たとえば、パーティションを定義する属性および子要素を含む「パーティション（partition）」、パーティションにデプロイされるアプリケーションおよびリソースを含む「リソース・グループ（resource-group）」、そのテンプレートによって定義されるアプリケーションおよびリソースを含む「リソース・グループ・テンプレート（resource-group-template）」、データベース特有のサービス名、ユーザ名、およびパスワードを含む「ｊｄｂｃ・システム・リソース・オーバーライド（jdbe-system-resource-override）」、ならびにリソースグループテンプレート内のマクロ置換のために用いられ得るプロパティキー値を含む「パーティション・プロパティ（partition-properties）」などの、複数のコンフィグレーション要素を含むことができる。

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

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

システムアドミニストレータはドメインレベルで、またはパーティションレベルでリソースグループを宣言することができる。ドメインレベルでは、リソースグループは関連のリソースをグループ化する便利な方法を提供する。システムは、グループ化されていないリソースと同じドメインレベルのリソースグループ内に宣言されるリソースを管理することができるため、リソースをシステム始動時に開始し、システムのシャットダウン（停止）時に停止することができる。アドミニストレータはさらに、グループ内のリソースを個別に停止、開始、または除去することができ、グループに対して動作することによって当該グループ内のすべてのリソースに対して暗黙的に作用することができる。たとえば、リソースグループを停止すると、まだ停止されていない当該グループ内のすべてのリソースが停止され、リソースグループを開始すると、まだ開始されていない当該グループ内のすべてのリソースが開始され、リソースグループを除去すると、当該グループに含まれているすべてのリソースが除去される。

パーティションレベルでは、システムまたはパーティションアドミニストレータは、パーティション内の１つ以上のリソースグループを、任意のセキュリティ制限を受けるようにコンフィグレーションすることができる。たとえば、ＳａａＳを用いる場合は、さまざまなパーティションレベルのリソースグループがドメインレベルのリソースグループテンプレートを参照することができるのに対して、ＰａａＳを用いる場合は、リソースグループテンプレートを参照せず、代わりに、パーティション内のみで利用可能にされるアプリケーションおよびそれらの関連リソースを表わす、パーティションレベルのリソースグループを作成することができる。

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

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

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

たとえば、ＳａａＳを用いる場合、システムは、同じアプリケーションおよびリソースを複数回起動することができ、これは、同じアプリケーションおよびリソースを用いることになるパーティションごとに一回起動することを含む。アドミニストレータがリソースグループテンプレートを定義すると、リソースグループテンプレートはトークンを用いて、他の場所で供給されることになる情報を表わすことができる。たとえば、ＣＲＭ関連のデータリソースに接続する際に用いるユーザ名を、＼＄｛ＣＲＭＤａｔａＵｓｅｒｎａｍｅ｝としてリソースグループテンプレート内に示すことができる。

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

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

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

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

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

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

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

図４は、一実施形態に従う、例示的なマルチテナント環境とともに用いるドメイン設定を示す。

一実施形態に従うと、システムがパーティションを開始すると、パーティションは、提供されたコンフィグレーション情報に従って、それぞれのデータベースインスタンスに仮想ターゲット（たとえば仮想ホスト）および接続プールを作成し、これは、パーティションごとに１つずつ作成することを含む。

典型的に、各リソースグループテンプレートは、１つ以上の関連のアプリケーションと、それらのアプリケーションが依存するリソースとを含むことができる。各パーティションは、場合によっては、リソースグループテンプレートによって指定されている一定のコンフィグレーション情報をオーバーライドすることを含む、当該パーティションと関連付けられた特定値への、リソースグループテンプレート内のデプロイ可能なリソースのバインディングを提供することによって、自身が参照するリソースグループテンプレート内に指定されていないコンフィグレーションのデータを提供することができる。これによって、システムは、各パーティションが定義したプロパティ値を用いて、リソースグループテンプレートによって表わされるアプリケーションをパーティションごとに異なって起動することができる。

場合によっては、パーティションは、リソースグループテンプレートを参照しない、または自身のパーティションにスコープされたデプロイ可能なリソースを直接定義する、リソースグループを含み得る。あるパーティション内に定義されるアプリケーションおよびデータソースは、一般にはそのパーティションのみが利用可能である。

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

ドメインレベルでデプロイ可能なリソースとは対照的に、リソースグループテンプレート内に宣言されるデプロイ可能なリソースは、いくつかのコンフィグレーション情報が欠けているため、テンプレート内に完全に設定され得ないか、またはそのまま起動されることができない。

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

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

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

複数のパーティションＪＮＤＩツリーのサポート
たとえば、マルチテナント、クラウドまたは他の環境などのアプリケーションサーバ環境は、複数のパーティションを含むことができる。たとえばデータソース、ＪＭＳまたはメールセッションなどのリソースを、１つよりも多いパーティション内にデプロイすることができる。

典型的に、リソースは、アプリケーションサーバ内のネーミングサービスを介してリソース名にマッピングされる１つ以上のオブジェクトを含むことができるため、アプリケーションがこれらのオブジェクトにアクセスする必要がある場合は、アプリケーションはリソースの名前によってオブジェクトの位置を突止めることができる。

一実施形態に従うと、理想的には、ネーミングサービスはパーティション認識型であり、ネーミングサービス内にパーティション分離を提供して、リソースルックアップ要求を特定のパーティションにディスパッチする。

一実施形態に従うと、マルチテナントアプリケーションサーバ環境でネームスペースをサポートするためのシステムおよび方法が本明細書に記載される。アプリケーションサーバ環境は、複数のパーティションを有するドメインを含むことができる。ドメインレベルのリソースにバインドされるグローバルネームスペースまたはＪＮＤＩツリーはパーティションルートノードのコレクションを維持することができ、各パーティションルートノードはパーティションＪＮＤＩツリーのルートノードである。パーティションＪＮＤＩツリー内の各ノードは、特定のパーティションに特有のプロパティを含むことによってパーティション認識型にさせられる。パーティションについての最初のコンテキストは、リソースルックアップ要求を当該パーティションにディスパッチする際に用いるために作成され得、当該パーティション内のリソースにアクセスする際に他のアプリケーションによって再利用され得る。

一実施形態に従うと、パーティションＪＮＤＩツリーのライフサイクルはその関連付けられたパーティションのライフサイクルと同じである。パーティションが作成されると、パーティションＪＮＤＩツリーを作成することができる。たとえばパーティション名およびパーティションＩＤなどのパーティション情報を、作成されたパーティションＪＮＤＩツリーにバインドすることができる。パーティションが破棄されると、そのパーティションについてのパーティションＪＮＤＩツリーは破棄される。

一実施形態に従うと、各パーティションＪＮＤＩツリーをアプリケーションによって用いて、関連付けられたパーティション内のリソースにアクセスすることができる。当該アプリケーションは、ドメインのスタンドアロンアプリケーションクライアント、ドメイン内の管理サーバ内のアプリケーション、パーティション内にデプロイされるアプリケーション、または異なるパーティションにデプロイされるアプリケーション、のいずれかであり得る。

上述のアプリケーションの各々が特定のパーティションからのリソースを要求すると、そのアプリケーションはアプリケーションと関連付けられたＪＮＤＩコンテキストを開始し、当該ＪＮＤＩコンテキストを用いて、アプリケーションからのリソース要求をパーティションＪＮＤＩツリーに委譲することができる。

一実施形態に従うと、ＪＮＤＩコンテキストは、一旦作成されると、ＪＮＤＩコンテキスト内のすべてのその後のＪＮＤＩオペレーションを関連付けられたパーティションに委譲することができ、そのパーティションのコンテキスト内で実行することができるように、パーティションと関連付けられたままであり得る。ＪＮＤＩコンテキストは、ＪＮＤＩコンテキストを作成するのに用いられるスレッドとは異なるスレッド上で１つ以上のアプリケーションによって用いられ得る。

図６は、一実施形態に従う、アプリケーションサーバ環境、クラウドまたは他の環境で、ドメイン内の複数のパーティションＪＮＤＩツリーをサポートするためのシステムを示す。

図６に示されるように、ドメインまたはグローバルＪＮＤＩツリー６２０はドメインルートネーミングノード６６１を含むことができ、ノード６６１はさらに、たとえばパーティションＡルートネーミングノード６６３、パーティションＢルートネーミングノード６６５、およびパーティションＮルートネーミングノード６６７などのパーティションルートネーミングノードのコレクションを含む。パーティションルートネーミングノードの各々は、たとえばＪＮＤＩツリーＡ６４１、ＪＮＤＩツリーＢ６４５、およびＪＮＤＩツリーＮ６４９などの、パーティションＪＮＤＩツリーについてのルートネーミングノードであり得る。

一実施形態に従うと、グローバルＪＮＤＩツリーはドメインレベルのリソース６２８にバインドされる。各パーティションＪＮＤＩツリーはパーティション（たとえばパーティションＡ６３５、パーティションＢ６３７またはパーティションＮ６３９）と関連付けられ、そのパーティションにデプロイされるリソース（たとえばリソースＡ６５５、リソースＢ６５７およびリソースＮ６５９）にバインドされる。

アプリケーションが特定のパーティション内のリソースにアクセスする必要がある場合、当該アプリケーションは、パーティションＪＮＤＩツリーへの開始点として、最初のＪＮＤＩコンテキストを作成することができる。要求しているアプリケーションがどこに位置しているかに基づいて、最初のＪＮＤＩコンテキストを作成する際に用いるためのパラメータとしてプロバイダＵＲＬが提供され得る。要求しているアプリケーションが要求されているリソースと同じパーティション内にある場合は、プロバイダＵＲＬは不要である。そうでなく、たとえば、要求しているアプリケーションがアプリケーションサーバドメインへのクライアントアプリケーションである場合は、プロバイダＵＲＬを提供する必要がある。

図６に示されるように、クライアントアプリケーション６１７がパーティションＡ内のリソースにアクセスする必要がある場合、最初のＪＮＤＩコンテキストＡ６１８を、パーティションを指定するプロバイダＵＲＬとともに作成することができる。

リスティング１は、プロバイダＵＲＬがともに提供される最初のＪＮＤＩコンテキストを作成する例を示す：
Hashtable h = new Hashtable();
h.put(Context.INITIAL_CONTEXT_FACTORY,
"weblogic.jndi.WLInitialContextFactory");
h.put(Context.PROVIDER_URL, "t3://server-2:7001/partition-A");
h.put(Context.SECURITY_PRINCIPAL, "partition-A-user");
h.put(Context.SECURITY_CREDENTIALS, "partition-A-password");
Context ctx = null;
try {
ctx = new InitialContext(h);
} catch (NamingException e) {
e.printStackTrace();
} finally {
try {
ctx.close();
} catch (NamingException e) {
e.printStackTrace();
}
}
リスティング１
上に示されるように、リスティング１は、パーティションＡ内にデプロイされるリソースを要求し、かつそのパーティションをパラメータとして指定するプロバイダＵＲＬとともに最初のＪＮＤＩコンテキストを作成するアプリケーションを示す。

一実施形態に従うと、ＪＮＤＩシステムが最初のＪＮＤＩコンテキストを作成する要求を受信すると、ＪＮＤＩサブシステムはプロバイダＵＲＬを用いて、たとえば指定されたパーティションの情報をどのパーティションルートネーミングノードが含むかを調べることによって、最初のコンテキストをプロバイダＵＲＬ内に指定されているパーティションと関連付けることができる。プロバイダＵＲＬが提供されない場合、ＪＮＤＩシステムは現在のコンポーネント呼出しコンテキストを最初のＪＮＤＩコンテキストと関連付けることができる。現在のコンポーネント呼出しコンテキストは、要求しているアプリケーションが実行されている現在のパーティションと関連付けられ得る。

一実施形態に従うと、最初のＪＮＤＩコンテキストが一旦作成されると、要求しているアプリケーションによって開始されるＪＮＤＩオペレーションを、最初のＪＮＤＩコンテキストと関連付けられたパーティションＪＮＤＩツリー内で実行することができる。最初のＪＮＤＩコンテキストからの要求を、パーティションと関連付けられたＪＮＤＩリソースに委譲することができる。

加えて、最初のコンテキストおよびパーティションＡとの関連付け６３４を、他のアプリケーションによって再利用するために、ドメイン内のコンテキストオブジェクトＡ６１９として維持６２１することができる。

図７は、一実施形態に従う、アプリケーションサーバ環境、クラウドまたは他の環境で、ドメイン内の複数のパーティションＪＮＤＩツリーをサポートするためのシステムをさらに示す。

図７に示されるように、上記に作成されたコンテキストオブジェクトを、複数のアプリケーションによって、たとえば、異なるクライアントアプリケーションＢ７１７、パーティションＢ内のアプリケーション７３７、およびドメイン内の管理サーバ内のアプリケーション７６１によって再利用７４３，７４５，７４７するために維持することができる。

一実施形態に従うと、これらのアプリケーションは、パーティションＡ内のリソースにアクセスする際、コンテキストオブジェクトを呼出すことができる。これらのアプリケーションからのＪＮＤＩオペレーションを、パーティションＡと関連付けられたＪＮＤＩツリーに自動的に委譲し、パーティションＡのコンテキスト内で実行することができる。

一実施形態に従うと、コンテキストオブジェクトとパーティションとの関連付けを、コンテキストオブジェクトをパーティションのネームスペースに関連付けることによって維持することができる。複数のコールバック機能がＪＮＤＩサブシステム内に提供されて、ＪＮＤＩオペレーションを、現在のコンポーネント呼出しコンテキストではなく、コンテキストオブジェクトと関連付けられたパーティションのコンポーネント呼出しコンテキストにおいて処理または実行することを可能にする。

図８は、一実施形態に従う、アプリケーションサーバ環境、クラウドまたは他の環境で、ドメイン内の複数のパーティションＪＮＤＩツリーをサポートするための方法を示す。

ステップ８１１において、アプリケーションサーバ環境におけるドメインが提供され、当該ドメインは、複数のパーティションと、パーティションルートネーミングノードのコレクションを維持するグローバルＪＮＤＩツリーとを含み、各パーティションルートネーミングノードは、パーティションに特有のパーティションＪＮＤＩツリーと関連付けられている。

８１３において、最初のＪＮＤＩコンテキストを作成する要求が、ドメイン内のＪＮＤＩサブシステムにおいてアプリケーションから受信される。

ステップ８１５において、ＪＮＤＩサブシステムは、当該要求からの情報と、パーティションルートネーミングノードのコレクションとを調べて、特定のパーティションと関連付けられた最初のコンテキストを作成する。

８１７において、アプリケーションからのＪＮＤＩオペレーションが、特定のパーティションと関連付けられたＪＮＤＩツリーに委譲される。

図９は、一実施形態に従う、アプリケーションサーバ環境、クラウドまたは他の環境で、ドメイン内の複数のパーティションＪＮＤＩツリーをサポートするための例示的なシステムを示す。

一実施形態に従うと、アプリケーションサーバ環境は、パーティション内にデプロイされるリソースについてパーティション認識型ＪＮＤＩルックアップおよびバインディングを実行することができる。そのような環境では、アプリケーションは、当該アプリケーションがデプロイされるパーティションの範囲内のＪＮＤＩリソースのみにアクセス可能である。たとえば、あるパーティション内にデプロイされるアプリケーションは、別のパーティションのＪＮＤＩリソースまたはドメインのＪＮＤＩリソースにはアクセスできない。

一実施形態に従うと、システムは、パーティションルートネーミングノードのコレクションを維持することによってＪＮＤＩリソースを分離することができ、各パーティションルートネーミングノードはパーティションネームスペース（たとえばパーティションＡネームスペース９３５およびパーティションＢネームスペース９３７）と関連付けられている。

一実施形態に従うと、パーティションネームスペース（たとえばパーティションレベルのＪＮＤＩツリー）内の各ノードを、パーティションに特有の１つ以上の値にバインドすることによってパーティション認識型にすることができる。同じＪＮＤＩ名を、異なるパーティションについての異なるネームスペースにバインドすることができる。

たとえば、同じＪＮＤＩリソース（たとえばセッションリソース）を、パーティションＡネームスペース、パーティションＢネームスペース、およびグローバルネームスペース９２０にバインドすることができる。当該リソースについてのＪＮＤＩルックアップを、パーティションＡまたはパーティションＢ内にデプロイされるアプリケーションから受信することができる。パーティションＡ内にデプロイされるアプリケーションについて、セッション９４５を戻すことができる。パーティションＢ内にデプロイされるアプリケーションについて、セッション９５５を戻すことができる。

一実施形態に従うと、ＪＮＤＩリソースがパーティションのネームスペースにバインドされない場合、当該パーティション内にデプロイされるアプリケーションから受信されるリソースルックアップは、たとえばNameNotFoundExceptionなどのエラーを生成し得る。

図９にさらに示されるように、グローバルネームスペース９２０はドメインルートノード９３０、および複数のリソースノードを含むことができる。グローバルＪＮＤＩツリー内のノードはパーティション認識型ではなく、すなわち、それらはパーティション特有の情報にバインドされない。

一実施形態に従うと、パーティション認識型ネーミングノードおよびパーティション非認識型ノードは同じＪＮＤＩ名（たとえば、グローバルネームスペース内のセッションノード９７５およびパーティションＡネームスペース内のセッションノード９４５）を有し得るが、それらは異なるリソースを戻すことができる。

したがって、パーティション認識型ノードは向上したルックアップ／バインド／リバインド／アンバインド機能を提供し、マルチテナントアプリケーションサーバ環境の要件を満たす。

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

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

本発明の上記の記載は、例示および説明目的で与えられている。網羅的であることまたは開示されたそのものの形態に本発明を限定することを意図したものではない。当業者にとっては、多くの修正および変形が明確であろう。上記の実施形態は、本発明の原理およびその実際的な適用をもっともよく説明するために選択および記載されたものであり、これにより他の当業者が、特定の使用に好適なさまざまな修正を考慮して、さまざまな実施形態について本発明を理解するのが可能になる。本発明の範囲は、添付の特許請求の範囲およびそれらの均等物によって定義されることが意図される。

Claims (22)

1. アプリケーションサーバ環境で複数のＪａｖａネーミングおよびディレクトリインターフェイス（ＪＮＤＩ）ツリーをサポートするためのシステムであって、
   １つ以上のコンピュータを備え、各コンピュータは１つ以上のマイクロプロセッサを含み、前記システムはさらに、
   前記コンピュータ上のアプリケーションサーバ環境を備え、前記アプリケーションサーバ環境は、複数のパーティションを有するドメインと、パーティションルートネーミングノードのコレクションを維持するグローバルＪＮＤＩツリーとを含み、各パーティションネーミングノードはパーティションＪＮＤＩツリーと関連付けられており、
   前記システムは、特定のパーティション内のリソースにアクセスする要求をアプリケーションから受信すると、
   前記特定のパーティションと関連付けられた最初のＪＮＤＩコンテキストを作成し、
   前記アプリケーションからのＪＮＤＩオペレーションを前記特定のパーティションと関連付けられたＪＮＤＩツリーに委譲するように動作する、システム。
2. 前記システムはさらに、前記要求からの情報と、前記パーティションルートネーミングノードのコレクションとを調べて、前記パーティションＪＮＤＩツリーを識別するように動作する、請求項１に記載のシステム。
3. 前記要求からの情報は、前記特定のパーティションについての情報を指定するプロバイダＵＲＬを含む、請求項１または２に記載のシステム。
4. パーティション内にデプロイされるリソースは、関連付けられたパーティションＪＮＤＩツリーにバインドされ、関連付けられた前記ＪＮＤＩツリー内の各ノードはパーティション認識型である、請求項１から３のいずれか１項に記載のシステム。
5. 前記最初のコンテキストは、一旦作成されると、１つ以上の他のアプリケーションによって再利用されるためにコンテキストオブジェクトとして維持され、前記アプリケーションからのＪＮＤＩオペレーションは、前記コンテキストオブジェクトと関連付けられた前記パーティションに向けられる、請求項１から４のいずれか１項に記載のシステム。
6. 前記コンテキストオブジェクトと前記パーティションとの関連付けは、前記コンテキストオブジェクトを前記パーティションのネームスペースと関連付けることによって維持される、請求項５項に記載のシステム。
7. 複数のコールバック機能が前記ＪＮＤＩのサブシステム内に提供されて、前記ＪＮＤＩオペレーションを前記パーティションのコンポーネント呼出しコンテキストにおいて処理することを可能にする、請求項１から６のいずれか１項に記載のシステム。
8. アプリケーションサーバ環境で複数のＪａｖａネーミングおよびディレクトリインターフェイス（ＪＮＤＩ）ツリーをサポートするための方法であって、
   アプリケーションサーバ環境でドメインを提供することを備え、前記ドメインは、複数のパーティションと、パーティションルートネーミングノードのコレクションを維持するグローバルＪＮＤＩツリーとを含み、各パーティションルートネーミングノードは、パーティションに特有のパーティションＪＮＤＩツリーと関連付けられており、前記方法はさらに、
   特定のパーティション内のリソースにアクセスする要求をアプリケーションから受信することと、
   前記特定のパーティションと関連付けられた最初のＪＮＤＩコンテキストを作成することと、
   前記アプリケーションからのＪＮＤＩオペレーションを前記特定のパーティションと関連付けられたＪＮＤＩツリーに委譲することとを備える、方法。
9. 前記システムはさらに、前記要求からの情報と、前記パーティションルートネーミングノードのコレクションとを調べて、前記パーティションＪＮＤＩツリーを識別するように動作する、請求項８に記載の方法。
10. 前記要求からの情報は、前記特定のパーティションについての情報を指定するプロバイダＵＲＬを含む、請求項８または９に記載の方法。
11. パーティション内にデプロイされるリソースは、関連付けられたパーティションＪＮＤＩツリーにバインドされ、関連付けられた前記ＪＮＤＩツリー内の各ノードはパーティション認識型である、請求項８から１０のいずれか１項に記載の方法。
12. 前記最初のコンテキストは、一旦作成されると、１つ以上の他のアプリケーションによって再利用されるためにコンテキストオブジェクトとして維持され、前記アプリケーションからのＪＮＤＩオペレーションは、前記コンテキストオブジェクトと関連付けられた前記パーティションに向けられる、請求項８から１１のいずれか１項に記載の方法。
13. 前記コンテキストオブジェクトと前記パーティションとの関連付けは、前記コンテキストオブジェクトを前記パーティションのネームスペースと関連付けることによって維持される、請求項１２に記載の方法。
14. 複数のコールバック機能が前記ＪＮＤＩのサブシステム内に提供されて、前記ＪＮＤＩオペレーションを前記パーティションのコンポーネント呼出しコンテキストにおいて処理することを可能にする、請求項８から１３のいずれか１項に記載の方法。
15. 機械読取可能なフォーマットの命令を備えるコンピュータプログラムであって、前記命令は、コンピュータシステムによって実行されると、前記コンピュータシステムに請求項８から１４のいずれか１項に記載の方法を実行させる、コンピュータプログラム。
16. 非一時的な機械読取可能なデータ記憶媒体に格納された請求項１５に記載のコンピュータプログラムを備える、コンピュータプログラムプロダクト。
17. 命令が格納された非一時的なコンピュータ読取可能な記憶媒体であって、前記命令は、１つ以上のコンピュータによって読取られて実行されると、前記１つ以上のコンピュータにステップを実行させ、前記ステップは、
    アプリケーションサーバ環境でドメインを提供することを備え、前記ドメインは、複数のパーティションと、パーティションルートネーミングノードのコレクションを維持するグローバルＪＮＤＩツリーとを含み、各パーティションルートネーミングノードは、パーティションに特有のパーティションＪＮＤＩツリーと関連付けられており、前記ステップはさらに、
    特定のパーティション内のリソースにアクセスする要求をアプリケーションから受信することと、
    前記特定のパーティションと関連付けられた最初のＪＮＤＩコンテキストを作成することと、
    前記アプリケーションからのＪＮＤＩオペレーションを前記特定のパーティションと関連付けられたＪＮＤＩツリーに委譲することとを備える、記憶媒体。
18. 前記システムはさらに、前記要求からの情報と、前記パーティションルートネーミングノードのコレクションとを調べて、前記パーティションＪＮＤＩツリーを識別するように動作する、請求項１７に記載の非一時的なコンピュータ読取可能な記憶媒体。
19. 前記要求からの情報は、前記特定のパーティションについての情報を指定するプロバイダＵＲＬを含む、請求項１７または１８に記載の非一時的なコンピュータ読取可能な記憶媒体。
20. パーティション内にデプロイされるリソースは、関連付けられたパーティションＪＮＤＩツリーにバインドされ、関連付けられた前記ＪＮＤＩツリー内の各ノードはパーティション認識型である、請求項１７から１９に記載の非一時的なコンピュータ読取可能な記憶媒体。
21. 前記最初のコンテキストは、一旦作成されると、１つ以上の他のアプリケーションによって再利用されるためにコンテキストオブジェクトとして維持され、前記アプリケーションからのＪＮＤＩオペレーションは、前記コンテキストオブジェクトと関連付けられた前記パーティションに向けられる、請求項１７から２０に記載の非一時的なコンピュータ読取可能な記憶媒体。
22. 前記コンテキストオブジェクトと前記パーティションとの関連付けは、前記コンテキストオブジェクトを前記パーティションのネームスペースと関連付けることによって維持される、請求項２１に記載の非一時的なコンピュータ読取可能な記憶媒体。

Images