(57)【特許請求の範囲】
【請求項１】
アプリケーションサーバ、クラウドまたは他の環境においてマルチテナンシをサポートするためのシステムであって、
アプリケーションサーバまたはその上で実行される他の環境を含むコンピュータを含み、前記コンピュータは、ソフトウェアアプリケーションを実行するためのドメインと、前記ソフトウェアアプリケーションが使用すべき前記ドメインにデプロイすることができる１つ以上のリソースとを有し、前記システムはさらに、
１つ以上のリソースグループテンプレートを含み、各々のリソースグループテンプレートは、ドメインレベルで、リソースグループから参照することができるリソースの集合を規定し、前記システムはさらに、
１つ以上のリソースグループを含み、各々のリソースグループは、リソースグループテンプレートを参照することができ、リソースの完全修飾型集合（fully-qualifiedcollection）を規定することができ、前記システムはさらに、
１つ以上のパーティションを含み、各々のパーティションは、前記ドメインのサブディビジョンを提供し、１つ以上のリソースグループを含むことができ、１つ以上のリソースグループテンプレートを参照することができ、
特定のパーティションのために、リソースグループテンプレートは、そのパーティションにおけるリソースグループによって参照することができ、それが参照するリソースグループテンプレートで使用するためのコンフィギュレーションデータを提供し、参照する前記パーティションまたはそれに関連付けられるソフトウェアアプリケーションが使用できるように、前記リソースグループテンプレートのリソースをパーティション特有の値にバインドし、
テナントは、そのテナントが使用すべきパーティションに関連付けることができる、システム。
【請求項２】
前記１つ以上のリソースグループテンプレート、リソースグループおよびパーティションは、コンフィギュレーションファイルによって規定される、請求項１に記載のシステム。
【請求項３】
前記複数のデプロイ可能なリソースは、１つ以上のパーティション認識リソース（partition-awareresource）および１つ以上のパーティション非認識リソース（partition-unawareresource）を含む、請求項１または２に記載のシステム。
【請求項４】
前記システムは前記アプリケーションサーバまたはクラウド環境は、Ｊａｖａアプリケーションサーバを含み、各々のリソースグループテンプレートは、１つ以上の関連するＪａｖａアプリケーションを、これらのアプリケーションが依存する前記リソースとともに含む、請求項１〜３のいずれか１項に記載のシステム。
【請求項５】
前記システムはクラウド環境内に設けられ、前記クラウド環境内で動作する複数のテナントをサポートする、請求項１〜４のいずれか１項に記載のシステム。
【請求項６】
前記システムは前記ドメインに対応するマルチテナントコンテナデータベース（ＣＤＢ）をさらに含み、前記マルチテナントコンテナデータベース（ＣＤＢ）は、１つ以上のプラグ接続可能なデータベース（ＰＤＢ）を含み、前記１つ以上のプラグ接続可能なデータベース（ＰＤＢ）は各々、特定のパーティションに対応している、請求項１〜５のいずれか１項に記載のシステム。
【請求項７】
前記システムは複数のテナントをサポートし、各々のテナントは、それら自体のパーティションおよびＰＤＢに関連付けられる、請求項６に記載のシステム。
【請求項８】
アプリケーションサーバ、クラウドまたは他の環境においてマルチテナンシをサポートする方法であって、
コンピュータにおいて、アプリケーションサーバまたはその上で実行される他の環境を設けるステップを含み、前記コンピュータは、ソフトウェアアプリケーションを実行するためのドメインと、前記ソフトウェアアプリケーションが使用すべき前記ドメインにデプロイすることができる１つ以上のリソースとを有し、前記方法はさらに、
１つ以上のリソースグループテンプレートを規定するステップを含み、各々のリソースグループテンプレートは、ドメインレベルで、リソースグループから参照することができるリソースの集合を規定し、前記方法はさらに、
１つ以上のリソースグループを規定するステップを含み、各々のリソースグループはリソースグループテンプレートを参照し、リソースの完全修飾型集合を規定することができ、前記方法はさらに、
１つ以上のパーティションを規定するステップを含み、各々のパーティションは、前記ドメインのサブディビジョンを提供し、１つ以上のリソースグループを含むことができ、１つ以上のリソースグループテンプレートを参照することができ、
特定のパーティションのために、リソースグループテンプレートは、そのパーティションにおけるリソースグループによって参照することができ、それが参照する前記リソースグループテンプレートで使用するためのコンフィギュレーションデータを提供し、参照する前記パーティションまたはそれに関連付けられるソフトウェアアプリケーションが使用できるように、前記リソースグループテンプレートのリソースをパーティション特有の値にバインドし、
テナントは、そのテナントが使用すべきパーティションに関連付けることができる、方法。
【請求項９】
前記１つ以上のリソースグループテンプレート、リソースグループおよびパーティションは、コンフィギュレーションファイルによって規定される、請求項８に記載の方法。
【請求項１０】
前記複数のデプロイ可能なリソースは、１つ以上のパーティション認識リソースおよび１つ以上のパーティション非認識リソースを含む、請求項８または９に記載の方法。
【請求項１１】
前記アプリケーションサーバまたはクラウド環境は、Ｊａｖａアプリケーションサーバを含み、各々のリソースグループテンプレートは、１つ以上の関連するＪａｖａアプリケーションを、それらのアプリケーションが依存する前記リソースとともに含む、請求項８〜１０のいずれか１項に記載の方法。
【請求項１２】
前記方法は、クラウド環境内において提供され、前記クラウド環境内で動作する複数のテナントをサポートする、請求項８〜１１のいずれか１項に記載の方法。
【請求項１３】
前記ドメインに対応するマルチテナントコンテナデータベース（ＣＤＢ）をさらに含み、前記マルチテナントコンテナデータベース（ＣＤＢ）は、１つ以上のプラグ接続可能なデータベース（ＰＤＢ）を含み、前記１つ以上のプラグ接続可能なデータベース（ＰＤＢ）は各々、特定のパーティションに対応している、請求項８〜１２のいずれか１項に記載の方法。
【請求項１４】
前記方法は、複数のテナントをサポートし、各々のテナントはそれら自体のパーティションおよびＰＤＢに関連付けられる、請求項１３に記載の方法。
【請求項１５】
命令を含むコンピュータプログラムであって、１つ以上のコンピュータによって読取られて実行されると、前記コンピュータに以下のステップを実行させ、前記以下のステップは、
アプリケーションサーバまたはその上で実行される他の環境を設けるステップを含み、ソフトウェアアプリケーションを実行するためのドメインと、前記ソフトウェアアプリケーションが使用すべき前記ドメインにデプロイすることができる１つ以上のリソースとを有し、前記以下のステップはさらに、
１つ以上のリソースグループテンプレートを規定するステップを含み、各々のリソースグループテンプレートは、ドメインレベルで、リソースグループから参照することができるリソースの集合を規定し、前記以下のステップはさらに、
１つ以上のリソースグループを規定するステップを含み、各々のリソースグループはリソースグループテンプレートを参照し、リソースの完全修飾型集合を規定することができ、前記以下のステップはさらに、
１つ以上のパーティションを規定するステップを含み、各々のパーティションは、前記ドメインのサブディビジョンを提供し、１つ以上のリソースグループを含むことができ、１つ以上のリソースグループテンプレートを参照することができ、
特定のパーティションのために、リソースグループテンプレートは、そのパーティションにおけるリソースグループによって参照することができ、それが参照する前記リソースグループテンプレートで使用するためのコンフィギュレーションデータを提供し、参照する前記パーティションまたはそれに関連付けられるソフトウェアアプリケーションが使用できるように、前記リソースグループテンプレートのリソースをパーティション特有の値にバインドし、
テナントは、そのテナントが使用すべきパーティションに関連付けることができる、コンピュータプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
著作権表示：
この特許文献の開示の一部は、著作権保護の対象となる題材を含んでいる。著作権の所有者は、特許商標庁の包袋または記録に掲載されるように特許文献または特許情報開示を誰でも複製できることに対して異議はないが、その他の点ではすべての如何なる著作権をも保有する。
【０００２】
発明の分野：
本発明の実施形態は、概して、アプリケーションサーバおよびクラウド環境に関し、特に、このような環境においてマルチテナンシをサポートするためのシステムおよび方法に関する。
【背景技術】
【０００３】
背景：
アプリケーションサーバは、概して、ソフトウェアアプリケーションをデプロイおよび実行することができる管理された環境を提供する。クラウドベースの環境では、アプリケーションをその内部で実行することが可能となり、クラウドによって提供される分散型リソースが利用される。このような環境は、多数のユーザまたはテナントをサポートすることができ、それらユーザまたはテナントのうちいくつかは、それら特有の特定条件を有する可能性がある。これらは、本発明の実施形態が使用可能となるタイプの環境のうちいくつかの例に該当する。
【発明の概要】
【課題を解決するための手段】
【０００４】
概要：
一実施形態に従うと、アプリケーションサーバ、クラウド、オンプレミスまたは他の環境においてマルチテナンシをサポートするためのシステムおよび方法がこの明細書中に記載される。当該システムおよび方法は、コンポーネントおよびコンフィギュレーションのカテゴリを特定のアプリケーションのインスタンスまたはパーティションに関連付けることを可能にする。リソースグループテンプレートは、ドメインレベルで、リソースグループから参照することができるデプロイ可能な（deployable）リソースの集合を規定する。各々のリソースグループは、リソースグループテンプレートを参照することができるデプロイ可能なリソースの、命名された完全修飾型集合（named, fully-qualified collection）である。パーティションは、ドメインの管理およびランタイムサブディビジョン（subdivision）を提供し、１つ以上のリソースグループを含む。各々のリソースグループは、リソースグループテンプレートを参照して、デプロイ可能なリソースをパーティション特有の値にバインドして、参照するパーティションが使用できるようにし得る。アプリケーションサーバまたはクラウド環境のテナントは、そのテナントが使用すべきパーティションまたはそこにデプロイされるアプリケーションに関連付けることができる。
【図面の簡単な説明】
【０００５】
【図１】一実施形態に従った、アプリケーションサーバ、クラウドまたは他の環境においてマルチテナンシをサポートするためのシステムを示す図である。
【図２】一実施形態に従った、アプリケーションサーバ、クラウドまたは他の環境においてマルチテナンシをサポートするためのシステムをさらに示す図である。
【図３】一実施形態に従った、アプリケーションサーバ、クラウドまたは他の環境においてマルチテナンシをサポートするためのシステムをさらに示す図である。
【図４】一実施形態に従ったリソースグループテンプレートの例示的な使用を示す図である。
【図５】一実施形態に従った例示的なマルチテナント環境を示す図である。
【図６】一実施形態に従った、パーティション非認識コンポーネントおよびパーティション認識コンポーネントをサポートするシステムを示す図である。
【図７】一実施形態に従った、アプリケーションサーバ、クラウドまたは他の環境におけるパーティションに対する複数のテナントによるアクセスを示す図である。
【図８】一実施形態に従った、アプリケーションサーバ、クラウドまたは他の環境においてマルチテナンシをサポートする方法を示す図である。
【発明を実施するための形態】
【０００６】
詳細な説明：
上述のとおり、アプリケーションサーバは、概して、ソフトウェアアプリケーションをデプロイおよび実行することができる管理された環境を提供する。クラウドベースの環境では、アプリケーションをその内部で実行することが可能となり、クラウドによって提供される分散型リソースが利用される。このような環境は、多数のユーザまたはテナントをサポートすることができ、それらユーザまたはテナントのうちいくつかは、それら特有の特定条件を有する可能性がある。
【０００７】
このような環境のニーズに対処するために、一実施形態に従って、アプリケーションサーバ、クラウド、オンプレミスまたは他の環境においてマルチテナンシをサポートするためのシステムおよび方法をこの明細書中において記載する。当該システムおよび方法は、コンポーネントおよびコンフィギュレーションのカテゴリを特定のアプリケーションのインスタンスまたはパーティションに関連付けることを可能にする。リソースグループテンプレートは、ドメインレベルで、リソースグループから参照することができるデプロイ可能なリソースの集合を規定する。各々のリソースグループは、リソースグループテンプレートを参照することができるデプロイ可能なリソースの、命名された完全修飾型集合である。パーティションは、ドメインの管理およびランタイムサブディビジョンを提供し、１つ以上のリソースグループを含む。各々のリソースグループは、リソースグループテンプレートを参照して、デプロイ可能なリソースをパーティション特有の値にバインドして、参照するパーティションによって使用できるようにする。アプリケーションサーバまたはクラウド環境のテナントは、そのテナントが使用すべきパーティションまたはそこにデプロイされるアプリケーションに関連付けることができる。
【０００８】
たとえば、オラクルＷｅｂＬｏｇｉｃサーバ（WebLogic Server：ＷＬＳ）およびＧｌａｓｓｆｉｓｈなどのＪａｖａ（登録商標）ＥＥアプリケーションサーバは、ある程度独立してＪａｖａアーカイブを実行することができる。一実施形態に従うと、ソフトウェアアプリケーションは、システムレベルまたはドメインレベルで管理されるＪａｖａアーカイブまたは他のコンポーネントのセットであるコンポーネントまたはコンフィギュレーションの第１のカテゴリと、それらのアーカイブを実行するのに必要とされるとともにアプリケーションレベルで管理されるコンフィギュレーションである第２のカテゴリとを含むものと見なすことができる。システムコンポーネントまたはドメインコンポーネントのインスタンスは、特定のパーティションが特定のテナントにマップされている状態で、アプリケーションコンポーネントのインスタンスまたはパーティションのいくつかのセットとともに実行させることができる。
【０００９】
一実施形態に従うと、システムは、マルチテナントのユースケースをサポートすることができる。このマルチテナントのユースケースは、ソフトウェア・アズ・ア・サービス（Software as a Service：ＳａａＳ）またはプラットフォーム・アズ・ア・サービス（Platform as a Service：ＰａａＳ）の能力を提供し、さまざまなテナント同士を区別する手段を必要とする。
【００１０】
たとえば、ＳａａＳユースケースにおいては、システムは、異なるテナントを認識するテナント認識アプリケーションを用いて、複数のテナント間でアプリケーションサーバインフラストラクチャを共有することを可能にし得る。ユーザのアイデンティティに基づき、テナント認識アプリケーションは、ユーザが属する特定のテナントを決定することができ、その情報を用いて、その特定のテナントに関するリソース、たとえばテナント特有のデータベース接続またはＪＭＳキューなど、にアクセスすることができる。
【００１１】
別の例として、ＰａａＳユースケースにおいては、システムは、さまざまなテナント環境間でオーバーラップがほとんどないか全くない状態で、複数のテナントがさまざまなアプリケーションを実行させることを可能にし、さらに、その特定のテナントに関連付けられたそれらのユーザのためにアプリケーションをデプロイするなどして、それら自体のランタイム環境のいくつかの局面を各々の特定のテナントが管理することができるようにする。
【００１２】
別の例として、オラクルフュージョンアプリケーションなどのエンタープライズソフトウェアアプリケーション環境の場合には、それら自体がテナント認識型ではないアプリケーションを含み得るが、アプリケーションのライフサイクルを単純化することが望まれている。この場合、システムは、実行時に複数の異なるコピーとして実現することができるアプリケーションインストールの単回コピーの使用をサポートすることができる。各々のコピーは、それ自体のパーティション内で実行可能であり、異なるクラスローダを用いることができ、これにより、各々のコピーが同じコンテナデータベース（container database：ＣＤＢ）内で実行されるさまざまなデータベースまたはさまざまなポータブルデータベース（portable database：ＰＤＢ）に接続することを可能にする。
【００１３】
他の実施形態に従うと、システムはまた、従来のユースケースに対処することができ、このため、ユーザは、それらが従来行なっていたのと同様の態様でマルチテナントバージョンのアプリケーションサーバを用いることができるが、そのマルチテナンシ特徴のいずれも用いることは必要とされていない。
【００１４】
例示の目的で（この明細書中において、ＷＬＳ−ＭＴと称される）マルチテナントＷＬＳアプリケーションサーバ環境の実施形態を含め、他のさまざまなユースケースおよび例を以下においてさらに詳細に説明する。他の実施形態に従うと、他のアプリケーションサーバ、クラウド、オンプレミスまたは他の環境で使用するための同様の機能および特徴も提供され得る。
【００１５】
マルチテナント環境
図１は、一実施形態に従った、アプリケーションサーバ、クラウドまたは他の環境においてマルチテナンシをサポートするためのシステムを示す。
【００１６】
図１に示されるように、一実施形態に従うと、マルチテナントアプリケーションサーバ環境１００、たとえば、環境内でソフトウェアアプリケーションをデプロイおよび実行することを可能にするアプリケーションサーバおよび他のコンポーネントは、アプリケーションサーバドメインを規定するために実行時に用いられるアプリケーションサーバドメインコンフィギュレーション１０２を含み、かつアプリケーションサーバドメインコンフィギュレーション１０２に従って動作するように構成され得る。
【００１７】
一実施形態に従うと、アプリケーションサーバはさらに、実行時に使用するために規定される１つ以上のパーティション１０４を含み得る。各々のパーティションは、パーティション識別子（identifier：ＩＤ）およびコンフィギュレーションに関連付けることができ、さらに、リソースグループテンプレート１２６および／または他のパーティション特有のアプリケーションもしくはリソース１２８に共に関連付けられる１つ以上のリソースグループ１２４を含み得る。
【００１８】
一実施形態に従うと、追加のリソースグループ、アプリケーションおよび／またはリソース１４０はまた、任意には、リソースグループテンプレートに共に関連付けられて、ドメインレベルで規定することができる。
【００１９】
一実施形態に従うと、アプリケーションサーバはさらに、実行時に使用するために規定される１つ以上のリソースグループテンプレート１６０を含み得る。各々のリソースグループテンプレートは、１つ以上のアプリケーションデプロイメント１６２、１６４、リソース１６６、１６８および／または他のデプロイ可能なアプリケーションもしくはリソース１７０を含み得る。
【００２０】
一実施形態に従うと、各々のリソースグループはリソースグループテンプレートを参照することができる。たとえば、パーティション１０４における図示されるリソースグループ１２４は、リソースグループテンプレート１６０を参照することができる（１９０）。
【００２１】
概して、システムアドミニストレータはパーティションを作成または削除することができ、ドメインレベルのリソースグループは、パーティション、領域およびドメインレベルのリソースグループテンプレートから参照可能である。パーティションアドミニストレータは、典型的には、それら自体のパーティションのさまざまな局面を管理することができ、たとえば、リソースグループを作成し、アプリケーションをパーティションにデプロイし、パーティションのための特定の領域を参照することができる。
【００２２】
いくつかの実施形態に従うと、テナントレベルの管理タスクをサポートするためにテナントアドミニストレータの役割を規定することができるが、このようなタスクは、代替的には、コンポーネント自体によって駆動可能であり、その後、対応するシステムレベルまたはパーティションレベルの動作にマップすることができる。
【００２３】
図２は、一実施形態に従った、アプリケーションサーバ、クラウドまたは他の環境においてマルチテナンシをサポートするためのシステムをさらに示す。
【００２４】
図２に示されるように、一実施形態に従うと、パーティション２０２は、たとえば、リソースグループテンプレート２０６、仮想ターゲット／仮想ホスト情報２０７およびＰＤＢ情報２０８に関連付けられたリソースグループ２０５を含み得る。リソースグループテンプレート２１０は、たとえば、ＪＭＳサーバ２１３、ＪＭＳシステムリソース２１４、ＳＡＦエージェント２１５、メールセッションコンポーネント２１６およびＪＤＢＣシステムリソース２１７などのデプロイ可能なリソースとともに、複数のアプリケーションデプロイメントＡ２１１およびＢ２１２を含み得る。図２に示されるパーティションおよびリソースグループテンプレートは単なる一例に過ぎず、他の実施形態に従うと、さまざまなパーティションおよび／またはリソースグループテンプレート要素を提供することができる。
【００２５】
一実施形態に従うと、パーティション（たとえば、パーティション２０２）は、特定のリソースグループテンプレート（たとえば、リソースグループテンプレート２１０）を参照するかまたは拡張する（２２０）ことができる。このような参照により、たとえば、特定のパーティションに関連付けられたＰＤＢ情報を、参照されたリソースグループテンプレートと組合わせて使用して、パーティションに関するパーティション特有の情報２３０、たとえばパーティション特有のＰＤＢ情報など、を示すことが可能となる。次いで、パーティション特有のＰＤＢ情報がアプリケーションサーバによって用いられて、パーティションが使用するためのリソースを構成することができる。
【００２６】
たとえば、図２に示されるように、パーティション２０２に関連付けられたパーティション特有のＰＤＢ情報がアプリケーションサーバによって用いられることにより、そのパーティションが使用するためのコンテナデータベース２３６を適切なＰＤＢ２３８で構成する（２３２）ことができる。
【００２７】
同様に、一実施形態に従うと、特定のパーティションに関連付けられた仮想ターゲット／仮想ホスト情報を用いて、パーティションが使用すべきパーティション特有の仮想ターゲット／仮想ホスト２４０を規定する（２３９）ことができる。これは、図示される例においては、baylandurgentcare.com.でアクセス可能となる。
【００２８】
図３は、一実施形態に従った、アプリケーションサーバ、クラウドまたは他の環境においてマルチテナンシをサポートするためのシステムをさらに示す。
【００２９】
一実施形態に従うと、たとえば、config.xmlファイルなどのコンフィギュレーションファイルによって規定されるコンフィギュレーションを用いて、そのパーティション、データベースおよび／または他のパーティション特性に関連付けられるリソースグループのための要素を含むパーティションを規定することができる。値は、たとえば、リソースグループにおける特性名／値の対を用いて、パーティションごとに指定することができる。リソースグループは、ドメインレベルで世界規模で規定することができるか、またはパーティションに特有であってもよい。
【００３０】
図３に示されるように、一実施形態に従うと、管理されたサーバ／クラスタ２４２内で、または、コンテナデータベース２４３にアクセスできるとともにウェブ層２４４を介してアクセス可能な同様の環境内で、複数のパーティションを実行することができる。一実施形態に従うと、ドメインは、概してコンテナデータベースに対応可能であって、各々のパーティションまたはテナントは、コンテナデータベースのＰＤＢのうち１つ以上に暗黙的に関連付けられている。
【００３１】
一実施形態に従うと、複数のパーティションの各々、この例においてはパーティションＡ２５０およびパーティションＢ２６０は、そのパーティションに関連付けられる複数のリソースを含むように構成することができる。図示される例においては、パーティションＡは、コンテナデータベースにおいてＰＤＢ  Ａ  ２５９に関連付けられているデータソースＡ  ２５７とともにアプリケーションＡ１  ２５２、アプリケーションＡ２  ２５４およびＪＭＳ  Ａ  ２５６を含むリソースグループ２５１を備えるように構成することができる。この場合、パーティションは仮想ターゲット／仮想ホストＡ２５８を介してアクセス可能である。同様に、この例においては、パーティションＢ２６０は、コンテナデータベースにおいてＰＤＢ  Ｂ  ２６９に関連付けられているデータソースＢ  ２６７とともに、アプリケーションＢ１  ２６２、アプリケーションＢ２  ２６４およびＪＭＳ  Ｂ  ２６６を含むリソースグループ２６１を備えるように構成することができる。この場合、パーティションは仮想ターゲット／仮想ホストＢ２６８を介してアクセス可能である。
【００３２】
上述の例のうちいくつかは他の実施形態に従ったＣＤＢおよびＰＤＢの使用を示しているが、他のタイプのマルチテナントおよび非マルチテナントデータベースもサポートすることができる。この場合、たとえば、スキーマの使用によって、またはさまざまなデータベースによって、各パーティションごとに特有のコンフィギュレーションを提供することができる。
【００３３】
テナント
一実施形態に従うと、テナントは、１つ以上のパーティションおよび／もしくは１つ以上のテナント認識アプリケーションによって表現され得るエンティティ、または、１つ以上のパーティションおよび／もしくは１つ以上のテナント認識アプリケーションに関連付けられ得るエンティティである。
【００３４】
たとえば、一実施形態に従うと、テナントは、別個のユーザ組織、たとえば、さまざまな外部会社、または特定の企業内のさまざまな部署（たとえばＨＲ部門および財務部門）などを表わすことができ、これら各々はさまざまなパーティションに関連付けることができる。テナントアイデンティティ（ＩＤ）は、時間における特定の瞬間において特定のテナントに特定のユーザを関連付けるものである。システムは、特定のユーザがどのテナントに属しているかを、ユーザアイデンティティから、たとえばユーザアイデンティティ格納部を参照することによって、導き出すことができる。ユーザアイデンティティはまた、システムがこれらの動作を実施することを可能にする。これらの動作は、ユーザがどのテナントに属し得るかを含めて、但しこれらに限定されることなく、システム全体にわたって進行するのに応じてユーザが実行することが認可される動作である。
【００３５】
一実施形態に従うと、システムは、互いに異なるテナントの管理およびランタイムの切離しを可能にする。たとえば、テナントは、それらのアプリケーションのいくつかの挙動と、それらがアクセスするリソースとを構成することができる。システムは、特定のテナントが別のテナントに属するアーティファクトを管理することができないことを確実にし、かつ、実行時に、特定のテナントの代わりに機能するアプリケーションが、他のテナントに関連付けられるリソースではなく、そのテナントに関するリソースのみを参照することを確実にすることができる。
【００３６】
一実施形態に従うと、テナント非認識アプリケーションは、テナントを明確に処理する論理を含まないアプリケーションである。アプリケーションが用いているいずれのリソースも、アプリケーションが応答する要求を提出したのがどのユーザであるかにかかわらず、機能している。対照的に、テナント認識アプリケーションは、テナントを明確に処理する論理を含む。たとえば、ユーザのアイデンティティに基づいて、当該アプリケーションは、ユーザが属するテナントを導き出すことができ、その情報を用いて、テナント特有のリソースにアクセスすることができる。
【００３７】
一実施形態に従うと、システムは、テナント認識型と明確に書込まれているアプリケーションをユーザがデプロイすることを可能にし、これにより、アプリケーション開発者が現在のテナントのテナントＩＤを取得することができるようにする。次いで、テナント認識アプリケーションは、テナントＩＤを用いて、アプリケーションの単一のインスタンスを用いている複数のテナントを処理することができる。
【００３８】
たとえば、以下においてさらに詳細に記載される具体的な実施形態に従うと、サンプルテナント認識アプリケーション「ＭｅｄＲｅｃ」は、単一の診療室または病院をサポートするものであって、２つの異なるテナント、たとえばBayland Urgent CareおよびValley Healthに公開することができる。これら２つのテナントの各々は、基礎をなすアプリケーションコードを変更することなく、別個のＰＤＢなどの別個のテナント特有のリソースにアクセスすることができる。
【００３９】
リソース
一実施形態に従うと、リソースは、環境のドメインにデプロイすることができるシステムリソース、アプリケーションまたは他のリソースもしくはオブジェクトである。たとえば、一実施形態に従うと、リソースは、アプリケーション、ＪＭＳ、ＪＤＢＣ、ＪａｖａＭａｉｌ、ＷＬＤＦ、データソースもしくは他のシステムリソース、または、サーバ、クラスタもしくは他のアプリケーションサーバターゲットにデプロイすることができる他のタイプのオブジェクトであり得る。
【００４０】
パーティション
一実施形態に従うと、パーティションは、パーティションＩＤおよびコンフィギュレーションに関連付けることができるドメインのランタイムおよび管理スライスであって、アプリケーションを含み得る、および／または、リソースグループおよびリソースグループテンプレートを使用することによってドメイン全体に渡るリソースを参照し得る。
【００４１】
概して、システムは、テナントが、そのテナントに関連付けられたパーティションの管理局面およびランタイム局面にアクセスできるように構成され得る。パーティションは、それ自体のアプリケーションを含むことができ、リソースグループテンプレートを介してドメイン全体にわたるアプリケーションを参照することができ、それ自体のコンフィギュレーションを有することができる。パーティション可能なエンティティは、ＪＮＤＩ名前空間、ネットワークトラフィック、ワークマネージャ、ならびにセキュリティポリシーおよび領域などの他のコンポーネントに加えて、上述のようなリソース、たとえばＪＭＳ、ＪＤＢＣ、ＪａｖａＭａｉｌ、ＷＬＤＦリソースを含み得る。
【００４２】
一実施形態に従うと、パーティション内の各リソースグループは０以上のリソースグループテンプレートを参照することができ、特定のリソースグループテンプレートは複数のパーティションから参照することができる。各々のパーティションはまた、パーティションのリソースグループが参照するリソースグループテンプレートにおいて指定されていないコンフィギュレーションデータについての特性を規定することができる。これにより、リソースグループテンプレートにおいて規定されたデプロイ可能なリソースを、そのパーティション内で使用するための特有の値にバインドするものとしてパーティションを動作させることが可能となる。場合によっては、パーティションはまた、リソースグループテンプレートによって指定される何らかのコンフィギュレーション情報を無効にすることができる。
【００４３】
一実施形態に従うと、パーティションコンフィギュレーションは、たとえば、コンフィギュレーションファイル（たとえば、config.xml）によって規定されるように、複数のコンフィギュレーション要素、たとえば：パーティションを規定する属性および子要素を含む「パーティション（partition）」；パーティションにデプロイされるアプリケーションおよびリソースを含む「リソースグループ（resource-group）」；アプリケーションおよびリソースを含む「リソースグループテンプレート（resource-group-template）」；ＤＢ特有のサービス名、ユーザ名およびパスワードを含む「ｊｄｂｃシステムリソースオーバーライド（jdbc-system-resource-override）」；ならびに、リソースグループテンプレートにおいてマクロ置換のために用いることができる特性キー値を含む「パーティション特性（partition-properties）」を含み得る。
【００４４】
ＭｅｄＲｅｃアプリケーションとともに使用されるコンフィギュレーションファイルの例示的な断片を以下に例示しており、パーティションのためにコンフィギュレーションファイルがどのように表示され得るかを示している。この場合、リソースグループテンプレートは、いくつかのアプリケーションデプロイメント、ＪＭＳサーバ、メールセッション、ＪＭＳシステムリソース、ＪＤＢＣシステムリソース、およびＳＡＦエージェントを含む。システムは、起動されると、コンフィギュレーションファイルによって提供される情報を用いて、リソースグループテンプレートから、各々のリソースごとにパーティション特有のコンフィギュレーション要素を生成することができる：
<partition>
<name>Partition-0</name>
<resource-group>
<name>PartitionResourceGroup-0</name>
<app-deployment>
<name>shoppingcart</name>
<module-type>war</module-type>
<source-path>/Users/chanpate/Downloads/shoppingcart.war</source-path>
<security-dd-model>DDOnly</security-dd-model>
<staging-mode xsi:nil="true"></staging-mode>
<plan-staging-mode xsi:nil="true"></plan-staging-mode>
<cache-in-app-directory>false</cache-in-app-directory>
</app-deployment>
<target>VirtualTarget-0</target>
</resource-group>
<jdbc-system-resource-override>
<name>JDBCSystemResourceOverride-0</name>
<data-source-name>JDBC1</data-source-name>
<url>jdbc:oracle:thin:@system.slc07gwu:8989</url>
<user>sys</user>
<password-encrypted>{AES}oCk9VWCKfua2xZ/fWffclORE9Yj6JHnHfOM/TAI3gco=</password-encrypted>
</jdbc-system-resource-override>
<available-target>VirtualTarget-0</available-target>
<partition-id>71838f74-c7e8-46f0-9a94-c20dfe346d37</partition-id>
<system-file-system>
<root>/Users/chanpate/wls-setup/partitions/Partition-0/system</root>
<create-on-demand>true</create-on-demand>
<preserved>true</preserved>
</system-file-system>
</partition>
<partition>
<name>partition1</name>
<resource-group>
<name>partition1-rg</name>
<resource-group-template>MedrecRGT</resource-group-template>
<target>partition1</target>
</resource-group>
<jdbc-system-resource-override>
<name>MedRecGlobalDataSourceXA</name>
<data-source-name>MedRecGlobalDataSourceXA</data-source-name>
<url>jdbc:derby://localhost:1528/mtdb2;create=true</url>
<user>scott</user>
<password-encrypted>{AES}TxJOS7kX8M6G2ICNa6EYX2Lno/GoeF1UaLT4gL88x6U=</password-encrypted>
</jdbc-system-resource-override>
<default-target>partition1</default-target>
<available-target>partition1</available-target>
<realm>partition1-realm</realm>
<partition-id>a2eee77e-4340-403a-947e-fa3932f4a04f</partition-id>
</partition>
<partition>
<name>partition2</name>
<resource-group>
<name>partition2-rg</name>
<resource-group-template>MedrecRGT</resource-group-template>
<target>partition2</target>
</resource-group>
<jdbc-system-resource-override>
<name>MedRecGlobalDataSourceXA</name>
<data-source-name>MedRecGlobalDataSourceXA</data-source-name>
<url>jdbc:derby://localhost:1529/mtdb3;create=true</url>
<user>scott</user>
<password-encrypted>{AES}6AY+so/KxRKZckcjuS6vwnlG+WAAfuqsGGfMuIE3JjY=</password-encrypted>
</jdbc-system-resource-override>
<default-target>partition2</default-target>
<available-target>partition2</available-target>
<realm>partition2-realm</realm>
<partition-id>96f1b8c6-0337-4f44-a321-6d6911671fc2</partition-id>
</partition>
<resource-group-template>
<name>MedrecRGT</name>
<app-deployent>
<name>medrec</name>
<module-type>ear</module-type>
<source-path>
/scratch/stjpg/weblogic/src1214_build/Oracle_Home
/dev.install-12.2.1.0.0-20150120233607.460/wlserver
/samples/server/medrec/dist/standalone/medrec.ear
</source-path>
<plan-path>
/scratch/stjpg/weblogic/dev/src1214/wlstest/integration
/mt/common/apps/medrec/plans/plan.xml
</plan-path>
<security-dd-model>DDOnly</security-dd-model>
<staging-mode xsi:nil="true"/>
<plan-staging-mode xsi:nil="true"/>
<cache-in-app-directory>false</cache-in-app-directory>
</app-deployment>
<app-deployment>
<name>physician</name>
<module-type>ear</module-type>
<source-path>
/scratch/stjpg/weblogic/src1214_build/Oracle_Home
/dev.install-12.2.1.0.0-20150120233607.460/wlserver
/samples/server/medrec/dist/
standalone/physician.ear
</source-path>
<security-dd-model>DDOnly</security-dd-model>
<staging-mode xsi:nil="true"/>
<plan-staging-mode xsi:nil="true"/>
<cache-in-app-directory>false</cache-in-app-directory>
</app-deployment>
<app-deployment>
<name>chat</name>
<module-type>war</module-type>
<source-path>
/scratch/stjpg/weblogic/src1214_build/Oracle_Home
/dev.install-12.2.1.0.0-20150120233607.460/wlserver
/samples/server/medrec/dist/standalone/chat.war
</source-path>
<security-dd-model>DDOnly</security-dd-model>
<staging-mode xsi:nil="true"/>
<plan-staging-mode xsi:nil="true"/>
<cache-in-app-directory>false</cache-in-app-directory>
</app-deployment>
<jms-server>
<name>MedRecJMSServer</name>
</jms-server>
<mail-session>
<name>myMailSession</name>
<jndi-name>mail/MedRecMailSession</jndi-name>
<properties>
mail.smtp.host=sca00bfc.us.oracle.com;mail.smtp.port=9872
</properties>
</mail-session>
<jms-system-resource>
<name>MedRec-jms</name>
<sub-deployment>
<name>MedRecJMSSubD</name>
<target>MedRecJMSServer</target>
</sub-deployment>
<descriptor-file-name>
resource-group-templates/MedrecRGT/jms/medrec-jms.xml
</descriptor-file-name>
</jms-system-resource>
<jdbc-system-resource>
<name>MedRecGlobalDataSourceXA</name>
<descriptor-file-name>
resource-group-templates/MedrecRGT/jdbc/
MedRecGlobalDataSourceXA-9669-jdbc.xml
</descriptor-file-name>
</jdbc-system-resource>
</resource-group-template>
リソースグループ
一実施形態に従うと、リソースグループは、ドメインレベルまたはパーティションレベルで規定することができるデプロイ可能なリソースについての命名された完全修飾型集合であり、リソースグループテンプレートを参照することができる。リソースグループにおけるリソースは、完全に修飾されていると見なされる。なぜなら、アドミニストレータが、それらのリソースを開始させるかまたはそれらのリソースに接続するために必要とされるすべての情報、たとえばデータソースに接続するためのクレデンシャルまたはＪａｖａアプリケーションについての対象となる情報、を提供してしまっているからである。
【００４５】
一実施形態に従うと、システムアドミニストレータは、ドメインレベルで０以上のリソースグループを公表し、パーティションレベルで１つ以上のリソースグループを公表することができる。
【００４６】
ドメインレベルでは、リソースグループは、関連するリソースをグループ化するための好適な方法を提供する。システムは、ドメインレベルのリソースグループにおいて、グループ化されていないリソースと同じものであると公表されたリソースを管理することができる。このため、システムの起動中にリソースを開始させることができ、システムの停止中にリソースを停止させることができる。アドミニストレータはまた、グループにおけるリソースを個々に停止させるか、開始させるかまたは削除することができ、グループ上で動作させることによって暗黙的にグループにおけるすべてのリソース上で機能することができる。
【００４７】
たとえば、リソースグループを停止させることにより、そのグループ内でまだ停止させていないすべてのリソースを停止させ、リソースグループを開始させることにより、そのグループ内でまだ開始させていないいずれのリソースも開始させ、リソースグループを削除することにより、そのグループに含まれるリソースをすべて削除する。
【００４８】
パーティションレベルでは、パーティションアドミニストレータは、それらのパーティションにおいて１つ以上のリソースグループを、いずれかのセキュリティ制限下で構成することができる。たとえば、ＳａａＳユースケースにおいては、ドメインレベルのリソースグループテンプレートを規定することができ、さまざまなパーティションレベルのリソースグループはそれらのテンプレートを参照することができる。ＰａａＳユースケースにおいて作成することができるパーティションレベルのリソースグループは、テンプレートを参照するものではなく、代わりに、そのパーティション内でのみ利用可能にされるべきアプリケーションおよびそれらの関連リソースを表わす。
【００４９】
一実施形態に従うと、リソースグループ化を用いて、Ｊａｖａアプリケーションと、それらアプリケーションがドメイン内において別個の管理ユニットとして用いているリソースとを一まとめにすることができる。たとえば、ＭｅｄＲｅｃアプリケーションにおいては、リソースグループ化によってＭｅｄＲｅｃアプリケーションおよびそのリソースが規定され得る。複数のパーティションは同じＭｅｄＲｅｃリソースグループを実行することができるが、それら複数のパーティションは、何らかのテナント特有のコンフィギュレーション情報を用いており、このため、各々のＭｅｄＲｅｃアプリケーションリソースインスタンスの一部であるＪａｖａアプリケーションが各々のテナント特有のものにされる。
【００５０】
リソースグループテンプレート
一実施形態に従うと、リソースグループテンプレートは、ドメインレベルで規定されたデプロイ可能なリソースの集合であって、リソースグループから参照することができ、パーティションレベルコンフィギュレーションの規格をサポートする。すべてのコンフィギュレーションを必ずしもドメインレベルで指定する必要はなく、代わりに、パーティションレベルコンフィギュレーションが、たとえば、特性名／値の対として、マクロを使用することによって、リソースグループテンプレートにおいて指定可能となる。
【００５１】
一実施形態に従うと、リソースグループテンプレートはデプロイ可能なリソースの集合であって、そのリソースを起動させるのに必要な情報のうちの少なくともいくらかが、テンプレート自体の一部として記憶されない可能性もある。このようなリソースについての情報のうちいくらかは、すべてのテナントにわたって同じであってもよく、他の情報はテナントごとに異なっていてもよい。
【００５２】
たとえば、ＳａａＳユースケースの一実施形態に従うと、システムは、同じアプリケーションおよびリソースを、これらアプリケーションおよびリソースを用いるパーティションごとに１回につき複数回、起動させることができる。アドミニストレータは、リソースグループテンプレートを規定すると、トークンを用いて、他のところに供給されるであろう情報を表わすことができる。たとえば、ＣＲＭ関連のデータリソースに接続する際に用いられるユーザ名は、リソースグループテンプレートにおいて＼＄｛ＣＲＭＤａｔａＵｓｅｒｎａｍｅ｝として示すことができる。
【００５３】
一実施形態に従うと、特定のリソースグループテンプレートは０以上のリソースグループによって参照され得る。たとえばドメインまたはパーティションといったリソースグループを含むオブジェクトは、特性名／値の割当てを用いて、リソースグループテンプレートにおける如何なるトークンの値をも設定することができる。システムが、参照するリソースグループを用いてリソースグループテンプレートを起動させると、当該システムは、それらのトークンを、リソースグループの含有オブジェクトにおいて設定された値と置換えることができる。
【００５４】
場合によっては、システムはまた、静的に構成されたリソースグループテンプレートおよびパーティションを用いて、各々のパーティション／テンプレートの組合せごとにランタイムコンフィギュレーションを生成することができる。
【００５５】
一実施形態に従うと、ドメインは、リソースグループテンプレートをいくつでも含むことができ、リソースグループテンプレートの各々は、たとえば、１つ以上の関連するＪａｖａアプリケーションと、それらのアプリケーションが依存するリソースとを含み得る。
【００５６】
ネットワーキング層
一実施形態に従うと、システムは、入力された要求をパーティションＩＤに関連付けるネットワーキング層を含み得る。たとえば、要求ＵＲＬ（たとえば、任意の経路に加えて仮想ターゲット／仮想ホスト）に基づいて、ネットワーキング層は、要求についての目標パーティションを決定し、決定されたパーティションＩＤを要求の実行コンテキストに追加することができる。一実施形態に従うと、各々のパーティションが固有の仮想ターゲット／仮想ホストとネットワークアクセスポイント（network access point：ＮＡＰ）との組合せを用いるように構成される場合、システムは、特定の仮想ターゲット／仮想ホスト上におけるすべての要求を、対応するパーティションにマップすることができる。代わりに、パーティションが仮想ターゲット／仮想ホストを共有するように構成されている場合、仮想ターゲット／仮想ホストのための経路を規定することができ、これにより、システムは、構成された経路に加えて仮想ターゲット／仮想ホストに基づいて適切なパーティションを決定することができるようになる。
【００５７】
ワークマネージャ
一実施形態に従うと、システムは、パーティション認識ワークマネージャを含み得る。各々のワークマネージャは、相対的にワークロードを優先させ、同時に、デッドロックを回避するようにとの作業要求を処理するためのスレッドが常に利用可能であることを確実にするためにスレッド制約を最小にし、同時発生的なスレッド実行要求の数を制限するためにスレッド制約を最大にするように構成することができる。パーティション特有のワークマネージャは、各パーティション毎に作成することができ、これにより、各々のパーティション内のアプリケーションが、そのパーティションに関するスレッドリソース使用のために構成された公平な割当分を超過しないようにすることを確実にし得る。
【００５８】
セキュリティ領域
一実施形態に従うと、各々のパーティションはセキュリティ領域を参照することができる。領域はまた、複数のパーティションによって参照され得る。上述のとおり、要求がシステムに入力されると、システムは、仮想ターゲット／仮想ホストから適切なパーティションを決定し、パーティションＩＤを要求の実行コンテキストに記憶することができる。その後、認証動作または認可動作が必要になると、システムは、パーティションＩＤを利用して、使用できる適切な領域を決定することができる。
【００５９】
ＪＮＤＩ
一実施形態に従うと、パーティション認識ＪＮＤＩフレームワークは、アプリケーションが命名済みオブジェクトをバインドし、それらをパーティション単位で検索することを可能にする。起動およびデプロイメント時間中、アプリケーションサーバコンテナは、各々のパーティション特有のアプリケーションを、対応するパーティションＩＤに関連付けることができる。次いで、ＪＮＤＩフレームワークは、命名されたオブジェクトのバインド中または照合中にそのパーティションＩＤを利用することができる。パーティション特有のオブジェクトは、他のパーティションから分離することができ、これにより、同じアプリケーションのうち異なるインスタンスが、パーティション特有のオブジェクトを同じＪＮＤＩ名で登録することが可能となる。
【００６０】
エンド・ツー・エンドライフサイクル管理
一実施形態に従うと、プロバイダを用いて、特定のアプリケーション、たとえば、オラクル・トラフィック・ディレクタ（Oracle Traffic Director：ＯＴＤ）、データベース、コヒーレンスまたはＪＭＳコンポーネントを実行するために必要とされるインフラストラクチャコンポーネントを接続することができる。
【００６１】
たとえば、いくつかの実施形態においては、特定のアプリケーションのうちパーティション特有のインスタンスは同じデータベースインスタンスを共有することができる。リソースグループテンプレートは、単一のデータベースインスタンスについてのドメインレベルのＪＤＢＣシステムリソースを参照することができ、そのリソースグループテンプレートを参照するすべてのパーティションは同じデータベースインスタンスを用いることができる。
【００６２】
一実施形態に従うと、アプリケーションのうちいくつかのパーティション特有のインスタンスは、共通のスキーマまたは互換性のあるスキーマを用いて、異なるデータベースインスタンスに接続することができる。リソースグループテンプレートは、コンフィギュレーションファイル（たとえば、config.xml）のそれぞれのパーティション区域においてコンフィギュレーションのうちのいくらかを指定されたままの状態にして、ＪＤＢＣシステムリソースを公表することができる。データソースについてのこのようなパーティションレベルコンフィギュレーションの例は、接続先を示すＵＲＬ、ならびに／または、参照されたデータベースインスタンスへのアクセスを認証および認可するためのユーザクレデンシャルを含み得る。
【００６３】
一実施形態に従うと、データソースインプリメンテーションは、コンテナデータベース内において割当てられたＰＤＢに対する各々のパーティションについての別個の物理的接続プールを作成することができ、これにより、ＰＤＢがアプリケーションサーバに対して別個のデータベースとして表示されることを可能にし、さらに、各々のパーティション特有のクレデンシャルを用いて、そのパーティションのプール内のパーティションのために１つ以上の接続を確立することを可能にする。
【００６４】
代替的には、システムはＰＤＢにわたる接続の切換えをサポートすることができる。この場合、別個のＰＤＢは各々のパーティションごとに提供することができるが、データソースインプリメンテーションは、ＰＤＢを所有するコンテナデータベースに対して単一の接続プールを共有する。アプリケーションがデータ要求を提出すると、このアプリケーションはパーティションのコンテキストにおいてこの要求を実行する。次いで、システムは、パーティションＩＤを用いて、共有された接続を正確なパーティションコンテキストに切換えてから、その接続に関する要求を実行し得る。
【００６５】
アプリケーションデプロイメントおよびコンフィギュレーション
一実施形態に従うと、アプリケーションは、ドメインレベルでリソースグループテンプレートにデプロイすることができるか、または、パーティションにまで範囲設定されるかもしくはドメインにまで範囲設定されるリソースグループにデプロイすることができる。アプリケーションコンフィギュレーションは、１パーティションにつき、アプリケーションごとに指定されたデプロイメントプランを用いて無効にすることができる。デプロイメントプランはまた、リソースグループの一部として指定することができる。いくつかの例示的なアプリケーションデプロイメントコマンドは以下のとおりである。
【００６６】
ドメインにおけるリソースグループテンプレートへのデプロイ：
java weblogic.Deployer …
-deploy
-resource-group-template healthcareresources-template
-name pharmacy pharmacy-app.ear
パーティションおけるリソースグループへのデプロイ：
java weblogic.Deployer …
-deploy
-partition t1
-resource-group healthcare-resources
-name pharmacy pharmacy-app.ear
デプロイメントプランを用いた、パーティションにおけるリソースグループへのデプロイ：
java weblogic.Deployer …
-deploy
-partition t1
-resource-group healthcare-resources
-plan pharmacy-plan.xml
-name pharmacy pharmacyapp.ear
図４は、一実施形態に従ったリソースグループテンプレートの例示的な使用を示す。
【００６７】
一実施形態に従うと、システムがパーティションを開始させると、当該システムは、提供されるコンフィギュレーションに従って、それぞれのデータベースインスタンスに対する仮想ターゲット／仮想ホストおよび接続プールを、パーティションごとに１つずつ含まれるように作成する。
【００６８】
典型的には、各々のリソースグループテンプレートは、それらのアプリケーションが依存する１つ以上の関連するＪａｖａアプリケーションおよびリソースを含み得る。上述のとおり、各々のパーティションは、リソースグループテンプレートにおけるデプロイ可能なリソースをパーティションに関連付けられた特性値にバインドすることによって、各パーティションが参照するリソースグループテンプレートにおいて指定されない如何なるコンフィギュレーションデータをも提供することができ、場合によっては、リソースグループテンプレートによって指定される何らかのコンフィギュレーション情報を無効にすることができる。これにより、システムは、各々のパーティションが規定した特性値を用いて、各々のパーティションごとにリソースグループテンプレートによってさまざまに表わされるアプリケーションを作動させることができる。
【００６９】
いくつかの例では、パーティションは、リソースグループテンプレートを参照しないかまたはそれら自体のパーティション範囲制限型のデプロイ可能なリソースを直接規定する自己完結型（self-contained）のリソースグループを含んでもよい。パーティション内において規定されるアプリケーションおよびデータソースは、一般に、そのパーティションに対してのみ利用可能である。一実施形態に従うと、システムは実際の操作を必要とすることも実施することもなく、ユーザは、所期のユースケースにかかわらず、それらのパーティション内のどちらかのタイプのリソースグループも用いることができる。
【００７０】
図４に示されるように、たとえば、ＭｅｄＲｅｃアプリケーションは、４つのＪａｖａアプリケーション、データソース、ＪＭＳサーバおよびメールセッションを含み得る。複数のテナントのためにＭｅｄＲｅｃアプリケーションを実行させるために、システムアドミニストレータは、ＭｅｄＲｅｃ２８６のために単一のリソースグループテンプレートを規定して、テンプレートにおいてそれらのデプロイ可能なリソースを公表することができる。
【００７１】
上述のとおり、ドメインレベルのデプロイ可能なリソースとは対照的に、リソースグループテンプレートにおいて公表されたデプロイ可能なリソースは、テンプレートにおいては完全に構成されない可能性もある。
【００７２】
たとえば、ＭｅｄＲｅｃリソースグループテンプレートは、Ｊａｖａアプリケーションによって用いられるデータソースを公表し得るが、データベースに接続するためのＵＲＬを指定しない可能性がある。典型的には、リソースグループテンプレートにおいて公表されるリソースのうちのいくつかは、そのままでは作動させることができない。なぜなら、それらには何らかのコンフィギュレーション情報が欠けているからである。さまざまなテナントに関連付けられたパーティション、たとえば、パーティションＢＵＣ−Ａ２９０（Bayland Urgent Care）およびパーティションＶＨ−Ａ２９３（Valley Health）は、ＭｅｄＲｅｃリソースグループテンプレートを参照する（２９６）ＭｅｄＲｅｃリソースグループ２９５を含め、さまざまなリソースグループテンプレートを参照することができる（２９２，２９４）。
【００７３】
一実施形態に従うと、上述の参照を用いることにより、Bayland Urgent Careテナントが使用すべきＢＵＣ−Ａパーティションに関連付けられた仮想ホストbaylandurgentcare.com３０４と、Valley Healthテナントが使用すべきＶＨ-Ａパーティションに関連付けられた仮想ホストvalleyhealth.com３０６とを含め、各々のテナントのための仮想ターゲット／仮想ホストを作成することができる（３０２，３０６）。
【００７４】
図５は、一実施形態に従った例示的なマルチテナント環境を示す。
図５に示されるように、２つのパーティションがＭｅｄＲｅｃリソースグループテンプレートを参照している上述の例に引き続き、一実施形態に従うと、複数のテナント環境、この例においては、Bayland Urgent Care医師環境３２０およびValley Health医師環境３３０、をサポートするためにサーブレットまたはサーブレットエンジンを用いることができる（３１０）。
【００７５】
一実施形態に従うと、各々のパーティションは、入力トラヒックを受理するための異なる仮想ターゲット／仮想ホストと、そのデータソース、この例においては、bayland urgent careデータベース３２４またはvalley healthデータベース３３４に接続するための異なるＵＲＬ３２２、ＵＲＬ３３２とを規定することができる。２つのデータベースインスタンスは、適合性のあるスキーマを有することができる。なぜなら、同じアプリケーションコードが両方のデータベースに対して実行されるからである。システムは、パーティションを始動させると、各々のパーティションごとに１つずつ、それぞれのデータベースインスタンスに対する仮想ターゲット／仮想ホストおよび接続プールを作成することができる。
【００７６】
一実施形態に従うと、どのユーザがパーティションを管理することができるかについての選択は、全体的なユースケースのいずれが所望されているかに密接に関連している。たとえば、ＳａａＳユースケースにおいては、アプリケーションサーバシステムアドミニストレータがパーティションおよびそれらのリソースインスタンスをすべて管理し得るのに対して、ＰａａＳユースケースにおいては、各々のパーティションアドミニストレータがそれぞれのパーティションおよびそれら内部にあるリソースを管理し得る。
【００７７】
図６は、一実施形態に従った、パーティション非認識コンポーネントおよびパーティション認識コンポーネントをサポートするシステムを示す。
【００７８】
図６に示されるように、一実施形態に従うと、環境は、物理コンピュータリソース、たとえば、ＣＰＵ、物理メモリおよびネットワークコンポーネント３４０、マルチテナントアプリケーションサーバ（たとえば、ＷＬＳ−ＭＴ）パーティションインプリメンテーション３４２、ならびに、１つ以上のパーティション非認識アプリケーションサーバコンポーネント３４４および／またはパーティション認識アプリケーションサーバコンポーネントを含み得る。従来の、たとえばＪａｖａの、アプリケーション３５０は、パーティション非認識コンポーネント、この例においては、サーブレットコンテナコンポーネント３５２およびＥＪＢコンテナコンポーネント３５４だけを含み得る。パーティション認識Ｊａｖａアプリケーション３６０は、パーティション非認識コンポーネントおよびパーティション認識コンポーネントをともに含み得る。パーティション認識コンポーネントは、この例においては、ＪＮＤＩ３６２、コンフィギュレーション３６４、セキュリティ３６６、ネットワーキング３６８、データ３７０、アプリケーションコンテナ３７２または診断３７４のコンポーネントを含み得る。
【００７９】
パーティション識別子
一実施形態に従うと、システムは、パーティション認識型であるシステムいずれかの部分が、どのパーティションのために機能しているのか（すなわち「現在の」パーティション）を検出することを可能にするために使用することのできるパーティション識別子（ＩＤ）のためのサポートを含む。一実施形態に従うと、パーティション識別子は実行コンテキストの一部をなしており、このため、パーティションＩＤを必要とする如何なるコンポーネントも、適切なＡＰＩを用いてこれを取得することができる。一実施形態に従うと、パーティションの代わりに機能し、かつ別のスレッドに作業を発送する如何なるコンポーネントも、新しいスレッドにパーティションＩＤを伝搬させるはずである。
【００８０】
図７は、一実施形態に従った、アプリケーションサーバ、クラウドまたは他の環境におけるパーティションに対する複数のテナントによるアクセスを示す。
【００８１】
図７に示されるように、一実施形態に従うと、パーティションＡ３８０、パーティションＢ３８２およびパーティションＮ３８４を含むパーティションを上述のとおり構成することができる。
【００８２】
たとえば、パーティションＡは、リソースグループテンプレートＡ３９０および／または他のパーティション特有のアプリケーションもしくはリソース３８８に対する参照（３８７）と共に、リソースグループＡ３８６を含み得る。他のパーティションは、同様に、リソースグループテンプレートＢ３９４などの１つ以上のリソースグループテンプレートに対する参照（４０２，４０４，４０６，４０８）を適宜、含み得る。さまざまなパーティションに関連付けられるテナントは、この例においてはテナントＡ４１０、テナントＢ４１２およびテナントＮ４１４を含むものであるが、それら自体のパーティションならびにそこにあるアプリケーションインスタンスおよびリソースにアクセスする（４２０，４２２，４２４）ことができる。
【００８３】
一実施形態に従うと、ネットワーキングサブシステムは、要求がｈｔｔｐ／ｈｔｔｐ、Ｔ３または他のプロトコルを介して到着すると、パーティションＩＤを実行コンテキストに関連付けることができる。たとえば、パーティションは特定の仮想ターゲット／仮想ホストを用いるように構成されてもよい。ネットワーキングサブシステムはその関連付けを認識することができ、この関連付けを用いて、その仮想ターゲット／仮想ホストを介して到達する要求をそのパーティションに関連付け、これにより、システムが、起動中に、リソースのうち必要なパーティション特有のインスタンスを作成し、処理全体にわたって正確なパーティション特有のインスタンス上で動作することを可能にする。
【００８４】
一実施形態に従うと、システムは上述と同様の機能を用いて、アプリケーションサーバ、クラウドまたは他の環境内における何千または何百万もの多数のテナント（これら各々はそれら自体のパーティションならびにその特定のコンフィギュレーションおよびアプリケーションサーバインスタンスに関連付けることができる）をサポートすることができる。
【００８５】
チャネル
一実施形態に従うと、システムは、何らかのキーであると想定した場合に、使用すべきパーティションＩＤを返送するPartitionValidatorServiceの使用を含め、チャネルのためのサポートを含み得る。たとえば、サーバは、ＲＪＶＭおよび構成されたチャネルを用いて通信することができる。一実施形態に従うと、システムは、すべてのパーティションで使用するための１チャネルを提供することができ、各々のパーティションにそれ自体の専用の、たとえばＴ３接続を提供する。これにより、各パーティションごとにチャネルを作成する必要性が低下する。なぜなら、すべてのパーティションが同じポートを共有することができるからである。
【００８６】
代替的には、一実施形態に従うと、複数のチャネルが構成される場合、チャネル選択の手段を用いることができる。たとえば、すべてのテナントトラフィックは、それに関連付けられたチャンネル名を有することができ、パーティションＩＤが利用可能でない場合にはデフォルトチャネルを用いることができる。パーティションおよびチャネルが指定されていない場合、デフォルトチャネルを用いることができる。パーティションが指定されていないが、チャネルが指定されている場合、システムは指定されたチャンネルを用いることができる。パーティションが指定されているが、チャネルが指定されていない場合、パーティションＩＤを用いて適切なチャネルを決定することができる。パーティションおよびチャネルの両方が指定されている場合、チャンネル名は優先順位が高くなり得る。
【００８７】
一実施形態に従うと、クライアントとサーバとの間で通信が提供され、クライアントが最初の要求を行なうことができ、サーバが応答することができた場合には、クライアントが認証されて検証される。次いで、計算されたパーティションをスレッドローカル上で設定して、後で使用できるようにし得る。サーバ側では、ＤＮＳ名や任意のクライアント提供型クレデンシャルをPartitionValidatorServiceに提供することで、パーティションＩＤを取得することができる。有効なパーティションＩＤが取得されると、この有効なパーティションＩＤを実行スレッドのスレッドローカル上に設定することができ、このため、以後のすべての動作が関連するテナントの範囲内で実行されるようになる。
【００８８】
一実施形態に従うと、クライアントは、（たとえば、形式t3://<host>:<port>の）ＰＲＯＶＩＤＥＲ＿ＵＲＬを提供して、最初のコンテキストを調べて、そのピアに接続するべきチャネルを発見することができる。ＲＪＶＭ層は、接続を開始するためにチャネルに加えてパーティションＩＤのマッピングを維持して、特定のＰＲＯＶＩＤＥＲ＿ＵＲＬのために使用すべき適切な接続を発見することができる。パーティションＩＤがスレッド上で利用可能であるとすると、ＲＪＶＭ層は、要求を処理するために、または代替的には新しい接続を作成するために、テナントに関連付けられた既存の接続を発見することができる。
【００８９】
マルチテナンシのサポート方法
図８は、一実施形態に従った、アプリケーションサーバ、クラウドまたは他の環境においてマルチテナンシをサポートする方法を示す。
【００９０】
図８に示されるように、一実施形態に従うと、ステップ４３２において、アプリケーションサーバまたはクラウド環境を含む１つ以上のコンピュータが、ソフトウェアアプリケーションの実行用のドメインと、ドメインにデプロイすることができる１つ以上のリソースとともに、設けられる。
【００９１】
ステップ４３３において、１つ以上のリソースグループテンプレートが設けられる。この場合、各々のリソースグループテンプレートは、リソースグループから参照可能であるとともにドメインレベルで規定されるデプロイ可能なリソースの集合である。
【００９２】
ステップ４３４において、１つ以上のリソースグループが設けられる。この場合、各々のリソースグループは、リソースグループテンプレートを参照することができる、デプロイ可能なリソースからなる命名された完全修飾型集合である。
【００９３】
ステップ４３６において、１つ以上のパーティションが設けられる。この場合、各々のパーティションは、ドメインの管理およびランタイムサブディビジョンを提供し、リソースグループを含むことができ、リソースグループテンプレートを参照することができる。
【００９４】
ステップ４３７において、特定のリソースグループテンプレートは１つ以上のパーティションにおけるリソースグループから参照される。このため、参照するパーティションは、それが参照するリソースグループテンプレートとともに使用される（が、リソースグループテンプレートによっては提供されない）コンフィギュレーションデータを提供して、参照されたリソースグループテンプレートのデプロイ可能なリソースをパーティション特有の値にバインドして、参照するパーティションが使用できるようにする。
【００９５】
ステップ４３８において、アプリケーションサーバまたはクラウド環境の特定のテナントが、当該テナントが使用すべきパーティションに関連付けられる。
【００９６】
パーティションテンプレート
一実施形態に従うと、システムは、パーティションテンプレートのためのサポートを含む。パーティションタイプについてのすべてのインスタンス化が同じハードウェアリソースを共有するとともに、すべてのアプリケーションリソースが同じセットのインフラストラクチャコンポーネントを用いて実施されるように、単一のパーティションタイプを実現することができる。代替的には、さまざまなパーティションタイプによって、さまざまなサービス品質特性を規定することができる。
【００９７】
たとえば、「ゴールド」もしくは「生成」パーティションのインスタンス化を用いて、「ブロンズ」もしくは「開発」パーティションよりも優れたハードウェアを目標にするか、または、他のタイプのパーティションに関連付けられたそれらの対応物に対して、より高い性能または他の利点を提供することができる。
【００９８】
パーティションをさまざまなサービス品質レベルに関連付けるための能力は、テナント認識アプリケーションおよび非テナント認識アプリケーションの両方に役立つものである。なぜなら、これらはともに、基礎をなすハードウェアおよびプロバイダインスタンスの特徴によって影響を受けるからである。単一のパーティションインスタンス内であれば、ワークマネージャースレッド制約を制御することによって、デプロイされた複数のアプリケーションについてのサービス品質を調整することができ、これにより、パーティションにデプロイされた１つのアプリケーションが、同じパーティションにデプロイされた他のアプリケーションよりも良好に動作することを可能にする。システムアドミニストレータは、パーティションのインスタンス化を制御するために割当分（quota）を関連付けることができ、たとえば、「ゴールド」パーティションのインスタンスをわずか数個に制限し、「ブロンズ」パーティションの数をより多くすることができる。
【００９９】
ポータブルパーティション
一実施形態に従うと、システムは、ポータブルパーティションのためのサポートを含む。パーティションはパーティションアーカイブにエクスポートすることができる。パーティションアーカイブは、パーティションのコンフィギュレーション、リソースグループおよびリソースグループテンプレート、ならびに任意にはアプリケーションバイナリおよびデプロイメントプランを含むが、アプリケーションランタイム状態およびアプリケーション特有のランタイムコンフィギュレーションを含まない。これにより、たとえば、PartitionMBean上でのインポート動作およびエクスポート動作を用いて、パーティションを第１、ソース、ドメインからエクスポートし、さらに第２、ターゲット、ドメインにインポートすることが可能となる。
【０１００】
ドメイン特有の依存性は、たとえば、ターゲットクラスタ、セキュリティ領域および仮想ホストのインポート後に更新される必要があるかもしれず、このために、同じ名前を用いるドメインにおいて既に構成されていた要素を備えることによって、または、ターゲットドメインへのインポート後にパーティションを更新することによって、外部接続の解消および再接続が必要となる可能性がある。これにより、Ｔ２Ｐなどの手順がよりきめ細かく制御される。なぜなら、ドメイン全体を移行させるのではなく、ドメインの停止または再始動を必要とすることなく単一のパーティションを移行させることができるからである。
【０１０１】
パーティションをインポートした後、システムアドミニストレータは、たとえば、パーティション特性、ＰＤＢ情報、またはパーティションのリソースグループ内の他のリソースを更新することによって、パーティションコンフィギュレーションをさらに更新して有効にする必要があるかもしれない。ターゲットドメインにパーティションアーカイブをインポートする場合、共有されたリソースグループテンプレートがターゲットドメインに既に存在している可能性もあり得る。この場合、インポート動作は、既存のリソースグループテンプレートがアーカイブに含まれているものと同一であるかどうかを検出することができる。検出することができれば、既存のリソースグループテンプレートが用いられることとなり、検出することができなければ、インポートが失敗し、このため、どのリソースグループテンプレートを使用すべきかを示すインポートを再試行することがユーザに要求されることとなる。
【０１０２】
パーティション移行
一実施形態に従うと、システムは、パーティション移行のためのサポートを含む。たとえば、各々のパーティションは、アプリケーションサーバのクラスタ上で作成することができる。パーティションは、たとえば、パーティションがデータベースなどに依存しているという、他のリソースに対するパーティションの類似性／非類似性といったさまざまな理由から、または、基礎をなすランタイムがメンテナンスを必要とする場合にパーティションに対するダウンタイムを防ぐために、クラスタ毎に移行させることができる。
【０１０３】
パーティション認識ＲＥＳＴ管理ＡＰＩ
一実施形態に従うと、システムは、パーティション認識ＲＥＳＴ管理ＡＰＩのためのサポートを含む。ＲＥＳＴ  ＡＰＩは、ビーン（bean）インターフェイスおよびアノテーションからＲＥＳＴリソースを生成することを含め、マルチテナントコンフィギュレーションおよび管理を含み得る。ＲＥＳＴ  ＡＰＩの他の特徴は、役割ベースの可視性（たとえば、誰がどんな情報を見ることができるか）；セキュリティ（たとえば、誰がどんな構成を変更することができるか）；ＪＭＸと共有されるインフラストラクチャ；パーティションアイデンティティに対してクライアント可視性を提供するための手段を含み得る。ｈｔｔｐ／ｈｔｔｐｓプロトコルの使用は、標準的なファイアウォールおよびフロントエンドホストコンフィギュレーションを用いてアクセスを可能にするとともに制御することができることを意味する。これは、マルチテナント環境において有用である。このマルチテナント環境においては、特定のパーティションアドミニストレータが、アプリケーションサーバドメインによってサポートされるわずか１スライスの薄いポートおよびチャネルだけにアクセス可能にされてもよい。管理ＲＥＳＴリソースの可視性はパーティションアドミニストレータにとって適切なものに制限することができるので、これらのＲＥＳＴ  ＡＰＩを用いるサーバコンフィギュレーションは、そのパーティションに範囲設定されたコンフィギュレーションリソースに制限することができる。
【０１０４】
パーティション認識型診断、ログインおよび監視
一実施形態に従うと、システムは、たとえば、パーティション範囲設定型メトリクス採収；パーティション範囲設定型ＷｅｂＬｏｇｉｃ診断フレームワーク（WebLogic Diagnostic Framework：ＷＬＤＦ）監視ルールおよび通知；パーティション認識型診断画像ダンプ；ならびに、パーティション範囲設定型ログインを用いることによる、パーティション認識型の診断、ログインおよび監視のためのサポートを含む。
【０１０５】
パーティション認識型診断画像の取り込みは、パーティション範囲設定型ＷＬＤＦシステムリソースにおいてパーティションアドミニストレータまたは監視ルールによって開始させることができる。システムは、診断情報についてフィルタリングされた表示を提示することができ、このため、パーティションレベルのアドミニストレータは、システムのうち、他のパーティションに関連付けられた情報を見ることができない部分を監視することができる。
【０１０６】
一実施形態に従うと、各々のパーティション関連ログ記録は関連するパーティションＩＤでタグ付けすることができる。パーティションアドミニストレータがログビューワを用いる場合、システムは表示すべきエントリをフィルタリングして、閲覧しているアドミニストレータが見ることを認可されたログ記録だけを公開することができる。
【０１０７】
一実施形態に従うと、監視をサポートするために、システムは、それが各々のパーティションに代わりに始動させたパーティション特有のリソースに対応するパーティション特有のランタイムＭＢｅａｎｓを作成することができる。ログインと同様に、パーティションアドミニストレータにとって可視となるデータは、アクセスを要求するアドミニストレータのパーティションＩＤと比較して、たとえば、リソースのパーティションＩＤに基づいたセキュリティ制御を用いて、そのアドミニストレータのパーティションからのデータに制限することができる。
【０１０８】
パーティション認識タグ付け
一実施形態に従うと、システムは、パーティション認識タグ付けのためのサポートを含む。タグ付けにより、人が読取り可能な名前をリソースに割当てる一般的なメカニズムが提供される。一実施形態に従うと、タグは、プロバイダランタイムなどのリソースを選択するためのフレキシブルな方法を提供するために、リソースまたはリソースのグループに適用することができる。
【０１０９】
パーティション認識編集セッション
一実施形態に従うと、システムは、パーティション認識編集セッションのためのサポートを含む。たとえば、編集セッションはパーティションごとに提供することができる。パーティションアドミニストレータは、パーティション特有の編集セッション内におけるパーティション関連コンフィギュレーションのうちいずれも変更することができる。
【０１１０】
コンフィギュレーションおよびランタイムＭｂｅａｎｓ
一実施形態に従うと、システムは、コンフィギュレーションおよびランタイム監視の両方のためにＪＭＸおよび管理されたビーン（ＭＢｅａｎｓ）の使用をサポートする。
【０１１１】
たとえば、一実施形態に従うと、コンフィギュレーションＭＢｅａｎｓの階層は、＜partition＞、＜resource-group-template＞およびネストされたリソース要素のための適切なＭＢｅａｎｓを含め、コンフィギュレーションファイル（たとえば、config.xml）におけるコンフィギュレーション要素と一致するように提供することができる。例示的なコンフィギュレーションＭＢｅａｎ階層は以下のとおりであり得る：
Domain MBean
ResourceGroupTemplate MBeans
JDBCSystemResource MBeans
JMSSystemResource MBeans
AppDeployment MBeans
…
Partition MBeans
JDBCSystemResourceOverride MBeans
(Partition-specific resources) MBeans
JDBCSystemResource MBeans
JMSSystemResource MBeans
AppDeployment MBeans
…
一実施形態に従うと、各々のパーティション要素はＭＢｅａｎ  ＡＰＩを用いて規定することができる。他の実施形態に従うと、他のＭＢｅａｎｓおよびＭＢｅａｎ  ＡＰＩを提供することができる。
【０１１２】
一実施形態に従うと、たとえばクラスタ、サーバチャネル、ＪＴＡおよびアプリケーションリソースなどのアプリケーションサーバのためのランタイムＭＢｅａｎｓを含むルートノードとしてのServerRuntimeMBeanを含め、ランタイムＭＢｅａｎｓの階層も提供することができる。パーティション特有のブランチを提供することができる。たとえば、JMSRuntimeMBeanは、JMSConnectionRuntimeMBean、JMSServerRuntimeMBeanおよびJMSPooledConnectionRuntimeMBeanについてのパーティション特有の子ＭＢｅａｎｓを含み得る。
【０１１３】
ServerRuntime MBean
PartitionRuntime MBeans
JMSRuntime MBean
JMSConnectionRuntime MBeans
JMSServerRuntime MBeans
JMSPooledConnectionRuntime MBeans
JDBCServiceRuntime MBean
JDBCDataSourceRuntime MBeans
JDBCMultiDataSourceRuntime MBeans
JDBCDriverRuntime MBeans
ApplicationRuntime MBeans
ComponentRuntime MBeans (component specific)
WorkManagerRuntime MBeans
LibraryRuntime MBean
WLDFRuntime MBean
WLDFAccessRuntime MBean
…
MailSessionRuntime MBeans
PersistentStoreRuntime MBeans
PersistentStoreConnectionRuntime MBeans
ConnectorServiceRuntime MBean
ConnectorComponentRuntime MBeans
PathServiceRuntime MBean
PSAssemblyRuntime MBeans
SAFRuntime MBean
SAFAgentRuntime MBeans
一実施形態に従うと、パーティション特有のリソースについてのランタイムＭＢｅａｎｓはまた、ＳｅｒｖｅｒＲｕｎｔｉｍｅ  ＭＢｅａｎレベルでのグローバルな階層ではなく、パーティション特有の階層において提供することができ、これにより、パーティション特有の監視および統計を可能にする。PartitionRuntimeMBeanは、ＪＭＳ、ＪＤＢＣ、デプロイメント、ＷＬＤＦ、コヒーレンスおよびコネクタなどのサブシステムのためのコンポーネント特有のＭＢｅａｎｓを含み得る。
【０１１４】
例示的コンフィギュレーション−ＳａａＳユースケース
ＭｅｄＲｅｃアプリケーション例についての例示的なコンフィギュレーションファイル（たとえば、config.xml）が以下のとおり提供される。この例示的なコンフィギュレーションファイルは、複数のアプリケーションおよびリソースを備えたリソースグループテンプレート（resource-group-template）を含み、２つのパーティション（この例においては、BayLand Urgent CareのためのパーティションおよびValley Healthのためのパーティション）を有する。各々のパーティションは、テンプレートからアプリケーションおよびリソースを継承するとともにそのパーティションに特有のＰＤＢ情報をも含むリソースグループを規定する。
<domain>
<resource-group-template>
<name>MedRecResourceTemplate</name>
<app-deployment>
<name>medrec</name>
...
</app-deployment>
<app-deployment>
<name>physician</name>
...
</app-deployment>
<app-deployment>
<name>browser-starter</name>
...
</app-deployment>
<app-deployment>
<name>SamplesSearchWebApp</name>
...
</app-deployment>
<jms-server>
<name>MedRecJMSServer</name>
</jms-server>
<mail-session>
<name>mail/MedRecMailSession</name>
<jndi-name>mail/MedRecMailSession</jndi-name>
<properties>mail.user=joe;mail.host=mail.mycompany.com</properties>
</mail-session>
<jms-system-resource>
<name>MedRec-jms</name>
<sub-deployment>
<name>MedRecJMSServer</name>
</sub-deployment>
<descriptor-file-name>jms/MedRec-jms.xml</descriptor-file-name>
</jms-system-resource>
<jdbc-system-resource>
<name>MedRecGlobalDataSourceXA</name>
<descriptor-file-name>jdbc/MedRecGlobalDataSourceXA-9669-jdbc.xml</descriptor-file-name>
</jdbc-system-resource>
<saf-agent>
<name>WsrmAgent</name>
<service-type>Both</service-type>
</saf-agent>
</resource-group-template>
<partition>
<name>BaylandUrgentCare</name>
<resource-group>
<name>BayLandMedRec</name>
<resource-group-template>MedRecResourceTemplate</resource-group-template>
</resource-group>
<partition-pdb-info>
<name>MedrecGlobalDataSourceXA</name>
<data-source-name>MedRecGlobalDataSourceXA</data-source-name>
<url>jdbc:oracle:thin:@(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=adc2111020.us.oracle.com)
(PORT=5521)))(CONNECT_DATA=(SERVICE_NAME=cdb1_pdb1.regress.rdbms.dev.us.oracle.com)))
</url>
<user>BUuser</user>
<password-encrypted>{AES}xyz</password-encrypted>
</partition-pdb-info>
</partition>
<partition>
<name>ValleyHealth</name>
<resource-group>
<name>ValleyHealthMedRec</name>
<resource-group-template>MedRecResourceTemplate</resource-group-template>
</resource-group>
<partition-pdb-info>
<name>MedrecGlobalDataSourceXA</name>
<data-source-name>MedRecGlobalDataSourceXA</data-source-name>
<url>jdbc:oracle:thin:@(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=adc2111020.us.oracle.com)
(PORT=5521)))(CONNECT_DATA=(SERVICE_NAME=cdb1_pdb2.regress.rdbms.dev.us.oracle.com)))
</url>
<user>VHuser</user>
<password-encrypted>{AES}abc</password-encrypted>
</partition-pdb-info>
</partition>
</domain>
例示的コンフィギュレーション−ＰａａＳユースケース
別の例示的なコンフィギュレーションファイル（たとえば、config.xml）が、以下のとおり提供される。この例においては、パーティション特有のアプリケーションおよびリソースを備えたリソースグループ要素のためのコンフィギュレーションを示している。この例においては、ＨＲ部門のための１パーティションおよび財務部門のための別のパーティションを含む２つのパーティションが構成される。各々のパーティションは、該当するパーティションに特有のアプリケーションを規定するリソースグループを規定する。この例においては、リソースグループテンプレートが指定されていない。なぜなら、このユースケースにおいては、マルチテナントアプリケーションがパーティション間で共有されていないからである。
<domain>
<partition>
<name>HR</name>
<resource-group>
<name>HR Apps and Resources</name>
<app-deployment>
<name>HR App</name>
...
</app-deployment>
<jdbc-system-resource>
<name>HR DataSource</name>
<descriptor-file-name>jdbc/HR-Datasource-jdbc.xml</descriptor-file-name>
</jdbc-system-resource>
</resource-group>
</partition>
<partition>
<name>Finance</name>
<resource-group>
<name>Finance Apps and Resources</name>
<app-deployment>
<name>Finance App</name>
...
</app-deployment>
<jdbc-system-resource>
<name>Finance DataSource</name>
<descriptor-file-name>jdbc/Finance-Datasource-jdbc.xml</descriptor-file-name>
</jdbc-system-resource>
</resource-group>
</partition>
</domain>
一実施形態に従うと、コンフィギュレーションはデプロイメントプランを用いて無効にされ得る。デプロイメントプランファイル名要素のための無効化を含め、リソースグループテンプレートについてのＭｅｄＲｅｃアプリケーションのためのコンフィギュレーションを示す例示的コンフィギュレーションが以下のとおり提供される。この例においても、BayLand Urgent CareのためのパーティションおよびValley Healthのためのパーティションを含む２つのパーティションが存在する。これら２つのパーティションは各々、リソースグループテンプレートデプロイメントプランを無効にするアプリケーションを規定する。
<domain>
<resource-group-template>
<name>MedRecResourceTemplate</name>
<app-deployment>
<name>medrec</name>
<source-path>/apps/medrec/medrec.ear</plan-path>
<plan-path>/apps/medrec/plan.xml</plan-path>
</app-deployment>
...
</resource-group-template>
<partition>
<name>BaylandUrgentCare</name>
<resource-group>
<name>BayLandMedRec</name>
<resource-group-template>MedRecResourceTemplate</resource-group-template>
<app-deployment>
<name>medrec</name>
<plan-path>/apps/medrec/bay-land-plan.xml</plan-path>
</app-deployment>
</resource-group>
...
</partition>
<partition>
<name>ValleyHealth</name>
<resource-group>
<name>ValleyHealthMedRec</name>
<resource-group-template>MedRecResourceTemplate</resource-group-template>
<app-deployment>
<name>medrec</name>
<plan-path>/apps/medrec/valley-health-plan.xml</plan-path>
</app-deployment>
</resource-group>
...
</partition>
</domain>
本発明は、本開示の教示に従いプログラムされた、１つ以上のプロセッサ、メモリ、および／またはコンピュータ読取可能な記録媒体を含む、従来の汎用もしくは専用デジタルコンピュータ、コンピューティングデバイス、マシン、またはマイクロプロセッサを１つ以上用いて、適宜実装し得る。適切なソフトウェアコーディングは、熟練したプログラマが本開示の教示に基づいて容易に準備できるものである。これはソフトウェア技術における当業者には明らかであろう。
【０１１５】
実施形態によっては、本発明は、本発明のプロセスのうちいずれかを実行するためにコンピュータをプログラムするのに使用できる命令が格納された非一時的な記録媒体または（１つまたは複数の）コンピュータ読取可能な媒体であるコンピュータプログラムプロダクトを含む。この記録媒体の例は、フロッピー（登録商標）ディスク、光ディスク、ＤＶＤ、ＣＤ−ＲＯＭ、マイクロドライブ、および光磁気ディスクを含む、任意の種類のディスク、ＲＯＭ、ＲＡＭ、ＥＰＲＯＭ、ＥＥＰＲＯＭ、ＤＲＡＭ、ＶＲＡＭ、フラッシュメモリデバイス、磁気もしくは光カード、ナノシステム（分子メモリＩＣを含む）、または、命令および／もしくはデータを格納するのに適した任意の種類の媒体もしくはデバイスを含み得るものの、これらに限定されない。
【０１１６】
本発明のこれまでの記載は例示および説明を目的として提供されている。すべてを網羅するかまたは本発明を開示された形態そのものに限定することは意図されていない。当業者には数多くの変更および変形が明らかであろう。
【０１１７】
たとえば、例示を目的として、上述の実施形態の多くが、ＷｅｂＬｏｇｉｃサーバ（ＷＬＳ）、マルチテナントＷＬＳ（ＷＬＳ−ＭＴ）またはフュージョンアプリケーション環境におけるマルチテナンシの使用を記載しているが、同様の機能および特徴を、他のアプリケーションサーバ、エンタープライズアプリケーション、クラウドまたは他の環境とともに用いることができる。
【０１１８】
実施形態は、本発明の原理およびその実際の応用を最もうまく説明することによって他の当業者がさまざまな実施の形態および意図している特定の用途に適したさまざまな変形を理解できるようにするために、選択され説明されている。本発明の範囲は添付の特許請求の範囲およびそれらの同等例によって規定されるものと意図されている。
【図１】
0006461167.tif 000002
【図２】
0006461167.tif 000003
【図３】
0006461167.tif 000004
【図４】
0006461167.tif 000005
【図５】
0006461167.tif 000006
【図６】
0006461167.tif 000007
【図７】
0006461167.tif 000008
【図８】
0006461167.tif 000009