(57)【特許請求の範囲】
【請求項１】
アプリケーションサーバ環境で複数のＪａｖａ（登録商標）ネーミングおよびディレクトリインターフェイス（ＪＮＤＩ）ツリーをサポートするためのシステムであって、
１つ以上のコンピュータを備え、各コンピュータは１つ以上のマイクロプロセッサを含み、前記システムはさらに、
前記コンピュータ上のアプリケーションサーバ環境を備え、前記アプリケーションサーバ環境は、複数のパーティションを有するドメインと、パーティションルートネーミングノードのコレクションを維持するグローバルＪＮＤＩツリーとを含み、各パーティションネーミングノードはパーティションＪＮＤＩツリーと関連付けられており、
前記システムは、特定のパーティション内のリソースにアクセスする要求をアプリケーションから受信すると、
前記特定のパーティションと関連付けられた最初のＪＮＤＩコンテキストを作成し、
前記アプリケーションからのＪＮＤＩオペレーションを前記特定のパーティションと関連付けられたＪＮＤＩツリーに委譲するように動作する、システム。
【請求項２】
前記システムはさらに、前記要求からの情報と、前記パーティションルートネーミングノードのコレクションとを調べて、前記パーティションＪＮＤＩツリーを識別するように動作する、請求項１に記載のシステム。
【請求項３】
前記要求からの情報は、前記特定のパーティションについての情報を指定するプロバイダＵＲＬを含む、請求項１または２に記載のシステム。
【請求項４】
パーティション内にデプロイされるリソースは、関連付けられたパーティションＪＮＤＩツリーにバインドされ、関連付けられた前記ＪＮＤＩツリー内の各ノードはパーティション認識型である、請求項１から３のいずれか１項に記載のシステム。
【請求項５】
前記最初のコンテキストは、一旦作成されると、１つ以上の他のアプリケーションによって再利用されるためにコンテキストオブジェクトとして維持され、前記アプリケーションからのＪＮＤＩオペレーションは、前記コンテキストオブジェクトと関連付けられた前記パーティションに向けられる、請求項１から４のいずれか１項に記載のシステム。
【請求項６】
前記コンテキストオブジェクトと前記パーティションとの関連付けは、前記コンテキストオブジェクトを前記パーティションのネームスペースと関連付けることによって維持される、請求項５に記載のシステム。
【請求項７】
複数のコールバック機能が前記ＪＮＤＩのサブシステム内に提供されて、前記ＪＮＤＩオペレーションを前記パーティションのコンポーネント呼出しコンテキストにおいて処理することを可能にする、請求項１から６のいずれか１項に記載のシステム。
【請求項８】
アプリケーションサーバ環境で複数のＪａｖａネーミングおよびディレクトリインターフェイス（ＪＮＤＩ）ツリーをサポートするための方法であって、
アプリケーションサーバ環境でドメインを提供することを備え、前記ドメインは、複数のパーティションと、パーティションルートネーミングノードのコレクションを維持するグローバルＪＮＤＩツリーとを含み、各パーティションルートネーミングノードは、パーティションに特有のパーティションＪＮＤＩツリーと関連付けられており、前記方法はさらに、
特定のパーティション内のリソースにアクセスする要求をアプリケーションから受信することと、
前記特定のパーティションと関連付けられた最初のＪＮＤＩコンテキストを作成することと、
前記アプリケーションからのＪＮＤＩオペレーションを前記特定のパーティションと関連付けられたＪＮＤＩツリーに委譲することとを備える、方法。
【請求項９】
前記方法はさらに、前記要求からの情報と、前記パーティションルートネーミングノードのコレクションとを調べて、前記パーティションＪＮＤＩツリーを識別することを備える、請求項８に記載の方法。
【請求項１０】
前記要求からの情報は、前記特定のパーティションについての情報を指定するプロバイダＵＲＬを含む、請求項８または９に記載の方法。
【請求項１１】
パーティション内にデプロイされるリソースは、関連付けられたパーティションＪＮＤＩツリーにバインドされ、関連付けられた前記ＪＮＤＩツリー内の各ノードはパーティション認識型である、請求項８から１０のいずれか１項に記載の方法。
【請求項１２】
前記最初のコンテキストは、一旦作成されると、１つ以上の他のアプリケーションによって再利用されるためにコンテキストオブジェクトとして維持され、前記アプリケーションからのＪＮＤＩオペレーションは、前記コンテキストオブジェクトと関連付けられた前記パーティションに向けられる、請求項８から１１のいずれか１項に記載の方法。
【請求項１３】
前記コンテキストオブジェクトと前記パーティションとの関連付けは、前記コンテキストオブジェクトを前記パーティションのネームスペースと関連付けることによって維持される、請求項１２に記載の方法。
【請求項１４】
複数のコールバック機能が前記ＪＮＤＩのサブシステム内に提供されて、前記ＪＮＤＩオペレーションを前記パーティションのコンポーネント呼出しコンテキストにおいて処理することを可能にする、請求項８から１３のいずれか１項に記載の方法。
【請求項１５】
機械読取可能なフォーマットの命令を備えるコンピュータプログラムであって、前記命令は、コンピュータシステムによって実行されると、前記コンピュータシステムに請求項８から１４のいずれか１項に記載の方法を実行させる、コンピュータプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
著作権表示
この特許文献の開示の一部は、著作権保護の対象となる題材を含んでいる。著作権の所有者は、特許商標庁の特許包袋または記録に掲載されるように特許文献または特許開示を誰でも複製できることに対して異議はないが、その他の点ではすべての如何なる著作権をも保有する。
【０００２】
発明の分野：
本発明の実施形態は概してアプリケーションサーバおよびクラウドプラットフォーム環境に関し、特に、マルチテナントアプリケーションサーバ環境でネームスペースをサポートするためのシステムおよび方法に関する。
【背景技術】
【０００３】
背景：
ソフトウェアアプリケーションサーバは、その例として、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などのエラーを生成し得る。
【００８３】
図９にさらに示されるように、グローバルネームスペース９２０はドメインルートノード９３０、および複数のリソースノードを含むことができる。グローバルＪＮＤＩツリー内のノードはパーティション認識型ではなく、すなわち、それらはパーティション特有の情報にバインドされない。
【００８４】
一実施形態に従うと、パーティション認識型ネーミングノードおよびパーティション非認識型ノードは同じＪＮＤＩ名（たとえば、グローバルネームスペース内のセッションノード９７５およびパーティションＡネームスペース内のセッションノード９４５）を有し得るが、それらは異なるリソースを戻すことができる。
【００８５】
したがって、パーティション認識型ノードは向上したルックアップ／バインド／リバインド／アンバインド機能を提供し、マルチテナントアプリケーションサーバ環境の要件を満たす。
【００８６】
本発明は、１つ以上のプロセッサ、メモリ、および／または本開示の教示に従いプログラムされたコンピュータ読取可能な記憶媒体を含む、１つ以上の従来の汎用もしくは専用デジタルコンピュータ、コンピューティングデバイス、マシン、またはマイクロプロセッサを用いて、適宜実現され得る。適切なソフトウェアコーディングは、本開示の教示に基づいて熟練したプログラマによって容易に準備され得る。これはソフトウェア技術の当業者には明らかであろう。
【００８７】
いくつかの実施形態において、本発明は、本発明の処理のいずれかを実行するようコンピュータをプログラムするのに用いられ得る命令が格納された非一時的な記憶媒体またはコンピュータ読取可能な媒体であるコンピュータプログラムプロダクトを含む。当該記憶媒体は、フロッピー（登録商標）ディスク、光ディスク、ＤＶＤ、ＣＤ−ＲＯＭ、マイクロドライブ、および光磁気ディスクを含む任意のタイプのディスク、ＲＯＭ、ＲＡＭ、ＥＰＲＯＭ、ＥＥＰＲＯＭ、ＤＲＡＭ、ＶＲＡＭ、フラッシュメモリ素子、磁気もしくは光学カード、ナノシステム（分子メモリＩＣを含む）、または命令および／もしくはデータを格納するのに好適な任意のタイプの媒体もしくは装置を含み得るが、これらに限定されない。
【００８８】
本発明の上記の記載は、例示および説明目的で与えられている。網羅的であることまたは開示されたそのものの形態に本発明を限定することを意図したものではない。当業者にとっては、多くの修正および変形が明確であろう。上記の実施形態は、本発明の原理およびその実際的な適用をもっともよく説明するために選択および記載されたものであり、これにより他の当業者が、特定の使用に好適なさまざまな修正を考慮して、さまざまな実施形態について本発明を理解するのが可能になる。本発明の範囲は、添付の特許請求の範囲およびそれらの均等物によって定義されることが意図される。
【図１】
0006505823.tif 000002
【図２】
0006505823.tif 000003
【図３】
0006505823.tif 000004
【図４】
0006505823.tif 000005
【図５】
0006505823.tif 000006
【図６】
0006505823.tif 000007
【図７】
0006505823.tif 000008
【図８】
0006505823.tif 000009
【図９】
0006505823.tif 000010