原文はこちら。
https://blogs.oracle.com/WebLogicServer/entry/introducing_wls_jms_multi_tenancy
この記事では、WebLogic Serverのメッセージングコンポーネントである、WebLogic JMSのマルチテナントサポートのMulti-tenancyサポートについてご紹介します。
パーティションは、概念としてWebLogic Serverのドメインをスライスしたもので、様々なテナントのリソースやアプリケーションを同一WebLogic Serverや同一クラスタで分離しながら構成、デプロイできます。これにより、全体としての集積度が向上します。パーティションはJNDI、セキュリティ、ランタイムMBean、アプリケーション永続データ、ワークマネージャ、ログの分離境界を定義します。さらに、同一サーバインスタンスで動作するパーティションには各々のライフサイクルがあります。例えば、パーティションを任意のタイミングで停止しても他のパーティションに影響を与えることはありません。
リソースグループは、リソースやアプリケーションに関連するシンプルな機能の集合体です。リソースグループは、同一パーティション内の他のリソース・グループとは独立してターゲットに指定したり、管理したりすることができます。リソースグループをパーティション内部で定義するだけでなく、ドメインレベルでも定義することができます。パーティションと同じように、同一サーバ上で動作する同一パーティションもしくはドメインレベルのリソースグループには、独自のライフサイクルがあります。
リソースグループ・テンプレートは、例えば同じリソースやアプリケーションが複数のパーティションで実行される必要がある、SaaSのような利用形態におけるWebLogic Serverリソースやアプリケーション構成に関わる管理のオーバーヘッドを削減するテンプレートのしくみを提供します。リソースグループ・テンプレートは、configure-once-and-use-everywhere（1回の構成でどこででも利用できる）機能を提供します。構成アーティファクトの共通セットをRGTで指定することができ、異なるパーティションのリソースグループから参照することができます。リソースグループ・テンプレートは、ターゲット指定できません。そして、デプロイ済みのリソースグループが参照しなければリソースグループ・テンプレートのリソースはデプロイされません。
（直接リソースグループ内で、もしくは直接リソースグループ・テンプレートを参照するリソースグループを通じて）パーティション内で構成、デプロイされているリソースやアプリケーションは、当該パーティションに範囲が限定されることにご注意ください。
異なるパーティション内のリソースやアプリケーションは互いに分離されています。例えば、同じクラスタ内で実行されている複数のパーティションに同じJNDI名を持つJMS宛先を設定することができ、これらの宛先を、独立したランタイムMBeanインスタンスを使って管理し、独立したパーティション固有のセキュリティレルムを使って保護することができます。非永続的な状態に加えて、JMS宛先などの永続的なデータ（例えば、永続メッセージと永続サブスクリプション）も互いに分離されています。
![]()
ご覧になるとおわかりになる通り、パーティションスコープのJMSリソースはパーティションのリソースグループに埋め込まれています（代わりにリソースグループ・テンプレートに埋め込むこともできます。その場合、リソースグループがそれを参照します）。
さらに、リソースグループのリソースは決して個別にターゲットとして指定されず、リソースグループ全体を仮想ターゲットを介してターゲットとして指定します。これが通常のターゲット指定の方法です。リソースグループが仮想ターゲットに対して割り付けられると、WebLogic Serverのクラスタにも割り付けられます。リソースグループのすべてのJMSリソースやアプリケーションもクラスタに割り付けられます。
後でご覧に入れますが、仮想ターゲットはだけでなく、リソースグループのターゲット情報を提供するだけではなく、パーティションのアクセス・ポイントをも定義します。リソースグループの割り付けと仮想ターゲットに関する詳細は、以下のJoeのエントリをご覧ください。
様々な検証およびターゲティングルールは、WebLogicマルチテナントのJMS構成が分離されていて自己完結しており、簡単に管理できることを保証するために強制されています。マルチテナント環境でJMSを構成する上でのある基本的かつハイレベルなルールは、JMS構成アーティファクトが同じスコープの他の構成アーティファクトを参照するのみである、というものです。例えば、JMSサーバーに範囲限定されたリソースグループは、同じリソース・グループで定義されている永続ストアを参照することだけができます。これらのルールは、構成の検証チェックによって実施され、エラーや警告は実行時にログに記載されます。
マルチテナントのアプリケーションは、同じWebLogicクラスタを参照しても異なるパーティションにスコープ限定されている、複数のJNDIコンテキストを持つことができます。初期コンテキストは、一度作成されるとクローズするまでそのスコープ範囲に限定されます。これは、パーティションスコープのJNDIコンテキスト・インスタンスを使うすべてのJNDIの操作を、パーティション固有のJNDI空間の領域を使用してを使用して、すべてのJNDI操作は、JNDIスペースのパーティション固有の領域を使用して実行することを意味します。
JNDIコンテキストのスコープは、初期コンテキスト作成時に提供されるプロバイダURLによって決定されます。
アプリケーションがパーティションスコープのJNDI初期コンテキストを確立すると、このコンテキストを使ってJMS接続ファクトリや宛先を非マルチテナント環境と同じやり方で検索することができます。違うのは、アプリケーションがパーティションスコープのJMSリソースにのみアクセスできる、という点です。
では具体的なユースケースを通じて、アプリケーションがどのように特定パーティションへの初期コンテキストを確立できるのかを見ていきましょう。
Using Partition Scoped JNDI Names
JNDI名を名前空間の接頭辞で装飾し、スコープを示すことができます。
Example 2.1: 上の例で示されたパーティション構成の場合、以下のコードを使ってpartition1にて構成されたJMS宛先にアクセスすることができます。
Using a provider URL with the "local:" Protocol
特定パーティションへの初期コンテキスト作成時に"local:"プロバイダURLを指定することもできます。
Example 2.2: 上の例で示されたパーティション構成の場合、以下のコードを使ってpartition1にて構成されたJMS宛先にアクセスすることができます。
同様に、パーティション内のJava EEアプリケーションは、同一クラスタ内のドメインレベルのJNDIリソースに local://?partitionName=DOMAIN をプロバイダURLとして指定するとアクセスできます。
パーティションURLは、WebLogic Server 12.2.1以後を使うJava EEアプリケーションやクライアントのみが使うことができます。旧バージョンの場合、下記のように専用パーティションポートを使います。
Example 3: 上の例で示されたパーティション構成の場合、以下のコードを使ってpartition1にて構成されたJMS宛先にアクセスすることができます。
注意いただきたいのは、以下のプロバイダURLにある"/partition1"はpartition1の仮想ターゲットで設定されたURI接頭辞です。
このような古いクライアントやアプリケーションの場合、ホスト名とURI接頭辞を使ってパーティションにアクセスすることはサポートしていませんので、旧来のクライアントからこれらを使おうとする試みは単に失敗するか、無言のうちにドメインレベルのJNDI名前空間にアクセスするかのどちらかでしょう。
この記事がマルチテナントにおけるJMSの基本を理解する上での助けになることを願っています。この新しい面白い機能の探索は始まったばかりです。マルチテナントにおけるメッセージングに関する情報は以下のドキュメントでたくさん見つけることができます。
https://blogs.oracle.com/WebLogicServer/entry/introducing_wls_jms_multi_tenancy
Introduction
Multi-tenancy (MT)はWebLogic Server 12.2.1の主要なテーマで、SaaSやPaaS用途のためにOracle Platformがこの機能により機能強化されています。WebLogic Server Multi-Tenancyの主要なメリットは、集積度の向上、テナントの分離、クラウド構成や管理のシンプル化があげられます。この記事では、WebLogic Serverのメッセージングコンポーネントである、WebLogic JMSのマルチテナントサポートのMulti-tenancyサポートについてご紹介します。
Key MT Concepts
例えばTimの以下のブログなどですでにWebLogic Server Multi Tenancyの主要なコンセプトはご存じかもしれませんが、幅広い皆様にとってのメリットをJMSの内容に入る前にさらっとご紹介します。Domain Partitions for Multi-tenancy in WebLogic Server 12.2.1WebLogic Multi-tenancyでは、ドメイン・パーティション（もしくはパーティション）、リソースグループ（RG）、リソースグループ・テンプレート（RGT）というコンセプトが導入されています。
https://blogs.oracle.com/WebLogicServer/entry/domain_partitions_for_multi_tenancy
http://orablogs-jp.blogspot.jp/2015/11/domain-partitions-for-multi-tenancy-in.html
パーティションは、概念としてWebLogic Serverのドメインをスライスしたもので、様々なテナントのリソースやアプリケーションを同一WebLogic Serverや同一クラスタで分離しながら構成、デプロイできます。これにより、全体としての集積度が向上します。パーティションはJNDI、セキュリティ、ランタイムMBean、アプリケーション永続データ、ワークマネージャ、ログの分離境界を定義します。さらに、同一サーバインスタンスで動作するパーティションには各々のライフサイクルがあります。例えば、パーティションを任意のタイミングで停止しても他のパーティションに影響を与えることはありません。
リソースグループは、リソースやアプリケーションに関連するシンプルな機能の集合体です。リソースグループは、同一パーティション内の他のリソース・グループとは独立してターゲットに指定したり、管理したりすることができます。リソースグループをパーティション内部で定義するだけでなく、ドメインレベルでも定義することができます。パーティションと同じように、同一サーバ上で動作する同一パーティションもしくはドメインレベルのリソースグループには、独自のライフサイクルがあります。
リソースグループ・テンプレートは、例えば同じリソースやアプリケーションが複数のパーティションで実行される必要がある、SaaSのような利用形態におけるWebLogic Serverリソースやアプリケーション構成に関わる管理のオーバーヘッドを削減するテンプレートのしくみを提供します。リソースグループ・テンプレートは、configure-once-and-use-everywhere（1回の構成でどこででも利用できる）機能を提供します。構成アーティファクトの共通セットをRGTで指定することができ、異なるパーティションのリソースグループから参照することができます。リソースグループ・テンプレートは、ターゲット指定できません。そして、デプロイ済みのリソースグループが参照しなければリソースグループ・テンプレートのリソースはデプロイされません。
（直接リソースグループ内で、もしくは直接リソースグループ・テンプレートを参照するリソースグループを通じて）パーティション内で構成、デプロイされているリソースやアプリケーションは、当該パーティションに範囲が限定されることにご注意ください。
Understanding JMS Resources in MT
他のWebLogic構成アーティファクトと同様に、JMSサーバ、SAFエージェント、パスサービス、永続ストア、メッセージングブリッジ、JMSシステムモジュール、アプリケーション・デプロイメントJMSモジュール、Java EE 7リソース定義モジュール、およびJMSアプリケーションといったJMSリソースは、直接またはリソースグループ・テンプレートを通じてだけではなく、以前からの方法（常にドメインレベルでは直接設定です）であっても、すべてリソースグループで構成、デプロイできます。パーティション構成と昔ながらの設定を同一ドメインで組み合わせて使うことも可能です。異なるパーティション内のリソースやアプリケーションは互いに分離されています。例えば、同じクラスタ内で実行されている複数のパーティションに同じJNDI名を持つJMS宛先を設定することができ、これらの宛先を、独立したランタイムMBeanインスタンスを使って管理し、独立したパーティション固有のセキュリティレルムを使って保護することができます。非永続的な状態に加えて、JMS宛先などの永続的なデータ（例えば、永続メッセージと永続サブスクリプション）も互いに分離されています。
Configuring JMS Resources in MT
以下の構成スニペットでは、マルチテナント環境で構成されたJMSリソースと旧来の非マルチテナント環境におけるJMS構成の違いを示しています。
ご覧になるとおわかりになる通り、パーティションスコープのJMSリソースはパーティションのリソースグループに埋め込まれています（代わりにリソースグループ・テンプレートに埋め込むこともできます。その場合、リソースグループがそれを参照します）。
さらに、リソースグループのリソースは決して個別にターゲットとして指定されず、リソースグループ全体を仮想ターゲットを介してターゲットとして指定します。これが通常のターゲット指定の方法です。リソースグループが仮想ターゲットに対して割り付けられると、WebLogic Serverのクラスタにも割り付けられます。リソースグループのすべてのJMSリソースやアプリケーションもクラスタに割り付けられます。
後でご覧に入れますが、仮想ターゲットはだけでなく、リソースグループのターゲット情報を提供するだけではなく、パーティションのアクセス・ポイントをも定義します。リソースグループの割り付けと仮想ターゲットに関する詳細は、以下のJoeのエントリをご覧ください。
Partition Targeting and Virtual Targets in WebLogic Server 12.2.1WebLogicクラスタ内の各サーバに対する個別のJMSリソース設定について説明せず、「移行可能なターゲット」を構成して高可用性を担保することに言及しなかったことに気付いてらっしゃるかもしれませんが、いいお知らせがあります。どちらも必要なく、MTでサポートされていません。これらの機能は、大幅に強化されたWebLogic JMSのクラスタ・ターゲティングおよびHAサポートに置き換えられています。同郷のKathiravanがこの件に関するエントリを出しています。
https://blogs.oracle.com/dipol/entry/partition_targeting_and_virtual_targets
http://orablogs-jp.blogspot.jp/2015/11/partition-targeting-and-virtual-targets.html
12.2.1 WebLogic JMS: Dynamic Scalability and High Availability Made SimpleシステムレベルのJMSリソース（JMSサーバ、SAFエージェント、永続ストア、メッセージング・ブリッジ、パス・サービス、JMSモジュール）がマルチテナント構成で様々に範囲付けられていますが、それぞれの属性は旧来の非マルチテナント構成と全く同じやり方で指定します。
https://blogs.oracle.com/WebLogicServer/entry/12_2_1_weblogic_jms
http://orablogs-jp.blogspot.jp/2015/12/1221-weblogic-jms-dynamic-scalability.html
様々な検証およびターゲティングルールは、WebLogicマルチテナントのJMS構成が分離されていて自己完結しており、簡単に管理できることを保証するために強制されています。マルチテナント環境でJMSを構成する上でのある基本的かつハイレベルなルールは、JMS構成アーティファクトが同じスコープの他の構成アーティファクトを参照するのみである、というものです。例えば、JMSサーバーに範囲限定されたリソースグループは、同じリソース・グループで定義されている永続ストアを参照することだけができます。これらのルールは、構成の検証チェックによって実施され、エラーや警告は実行時にログに記載されます。
Accessing JMS Resources in MT
マルチテナント用に設計されたJMSアプリケーションは、JNDI名前空間でJMSリソースを検索することにより、旧来のJMSアプリケーションと同じ方法でJMSリソースにアクセスします。違いは、MTの環境では、WebLogic JNDI InitialContextが作成時に特定のスコープ（ドメインまたはパーティション）に関連付けられていることです。マルチテナントのアプリケーションは、同じWebLogicクラスタを参照しても異なるパーティションにスコープ限定されている、複数のJNDIコンテキストを持つことができます。初期コンテキストは、一度作成されるとクローズするまでそのスコープ範囲に限定されます。これは、パーティションスコープのJNDIコンテキスト・インスタンスを使うすべてのJNDIの操作を、パーティション固有のJNDI空間の領域を使用してを使用して、すべてのJNDI操作は、JNDIスペースのパーティション固有の領域を使用して実行することを意味します。
JNDIコンテキストのスコープは、初期コンテキスト作成時に提供されるプロバイダURLによって決定されます。
アプリケーションがパーティションスコープのJNDI初期コンテキストを確立すると、このコンテキストを使ってJMS接続ファクトリや宛先を非マルチテナント環境と同じやり方で検索することができます。違うのは、アプリケーションがパーティションスコープのJMSリソースにのみアクセスできる、という点です。
では具体的なユースケースを通じて、アプリケーションがどのように特定パーティションへの初期コンテキストを確立できるのかを見ていきましょう。
Use Case 1 - Local Intra-partition Access
Java EEアプリケーションが同一クラスタ（または同じクラスタ構成ではない管理対象サーバ）のローカルパーティションのJMS宛先にアクセスする必要がある場合は、アプリケーションはプロバイダURLを使わずに初期コンテキストを作成すればよいです。Example 1: Null Provider URLこの初期コンテキストはアプリケーションがデプロイされたパーティションに範囲が限定されます。Context ctx = new InitialContext();
Object cf = ctx.lookup("jms/mycf1");
Object dest = ctx.lookup("jms/myqueue1");
Use Case 2 - Local Inter-partition Access
Java EEアプリケーションが、自分のデプロイされているパーティション以外に存在するJMS宛先やその他のリソースにアクセスする必要があって、パーティションが同じクラスタにある、もしくは同一管理対象サーバにある場合、パーティションスコープのJNDI名もしくは"local:"プロトコルを使うプロバイダURLを使うことができます。Using Partition Scoped JNDI Names
JNDI名を名前空間の接頭辞で装飾し、スコープを示すことができます。
Example 2.1: 上の例で示されたパーティション構成の場合、以下のコードを使ってpartition1にて構成されたJMS宛先にアクセスすることができます。
同様にパーティションのJava EEアプリケーションは、同一クラスタ内のドメインレベルのJNDIリソースに"domain:"という名前空間の接頭辞を付けると、パーティションスコープの初期コンテキストを使ってアクセスすることができます（例： "domain:jms/mycf2"）。Context ctx = new InitialContext();
Object cf = ctx.lookup("partition:partition1/jms/mycf1");
Object dest = ctx.lookup("partition:partition1/jms/myqueue1");
Using a provider URL with the "local:" Protocol
特定パーティションへの初期コンテキスト作成時に"local:"プロバイダURLを指定することもできます。
Example 2.2: 上の例で示されたパーティション構成の場合、以下のコードを使ってpartition1にて構成されたJMS宛先にアクセスすることができます。
初期コンテキストはそのライフタイムが"partition1"と関連付けられています。Hashtable<String, String> env = new Hashtable<>();
env.put(Context.PROVIDER_URL, "local://?partitionName=partition1");
env.put(Context.SECURITY_PRINCIPAL, "weblogic");
env.put(Context.SECURITY_CREDENTIALS, "welcome1");
Context ctx = new InitialContext(env);
Object cf = ctx.lookup("jms/mycf1");
Object dest = ctx.lookup("jms/myqueue1");
同様に、パーティション内のJava EEアプリケーションは、同一クラスタ内のドメインレベルのJNDIリソースに local://?partitionName=DOMAIN をプロバイダURLとして指定するとアクセスできます。
Use Case 3 - General Partition Access
Java EEアプリケーションやクライアントがパーティションのJMS宛先にアクセスする三個目の方法は、パーティションURLを使う、というものです。JMS宛先がリモートクラスタ（もしくは非クラスタ環境のリモートの管理対象サーバ）にある場合に、パーティションURLを使うことを意図しています。通常パーティションURLはt3://hostnake:portもしくはt3://hos:port/{URI接頭辞}です。パーティションURLは、WebLogic Server 12.2.1以後を使うJava EEアプリケーションやクライアントのみが使うことができます。旧バージョンの場合、下記のように専用パーティションポートを使います。
Example 3: 上の例で示されたパーティション構成の場合、以下のコードを使ってpartition1にて構成されたJMS宛先にアクセスすることができます。
注意いただきたいのは、以下のプロバイダURLにある"/partition1"はpartition1の仮想ターゲットで設定されたURI接頭辞です。
ベストプラクティスではありませんが、パーティションURLを使って同一JVM/クラスタの別のパーティションにアクセスすることもできます。Hashtable<String, String> env = new Hashtable<>();
env.put(Context.PROVIDER_URL, "t3://abcdef00:7001/partition1");
env.put(Context.SECURITY_PRINCIPAL, "weblogic");
env.put(Context.SECURITY_CREDENTIALS, "welcome1");
Context ctx = new InitialContext(env);
Object cf = ctx.lookup("jms/mycf1");
Object dest = ctx.lookup("jms/myqueue1");
Use Case 4– Dedicated Partition Ports
最後の方法は、専用ポートを各パーティションに設定することです。これらの構成はJoeの以下のエントリに説明があります。Partition Targeting and Virtual Targets in WebLogic Server 12.2.1パーティション専用ポートを構成すると、旧来のURLを使うアプリケーションがパーティションにアクセスすることができます。このポートは、12.2.1以前のWebLogic Serverで動作するクライアントやアプリケーションが12.2.1以後のドメイン内のパーティションにアクセスできるようにすることを主目的としています。
https://blogs.oracle.com/dipol/entry/partition_targeting_and_virtual_targets
http://orablogs-jp.blogspot.jp/2015/11/partition-targeting-and-virtual-targets.html
このような古いクライアントやアプリケーションの場合、ホスト名とURI接頭辞を使ってパーティションにアクセスすることはサポートしていませんので、旧来のクライアントからこれらを使おうとする試みは単に失敗するか、無言のうちにドメインレベルのJNDI名前空間にアクセスするかのどちらかでしょう。
What’s next?
この記事がマルチテナントにおけるJMSの基本を理解する上での助けになることを願っています。この新しい面白い機能の探索は始まったばかりです。マルチテナントにおけるメッセージングに関する情報は以下のドキュメントでたくさん見つけることができます。
Oracle® Fusion Middleware Using WebLogic Server Multitenant 12c (12.2.1)
Configuring Messaging
http://docs.oracle.com/middleware/1221/wls/WLSMT/config_jms.htm#WLSMT617