16 メッセージングの構成

この章では、WebLogic Server Multitenant (MT)でメッセージングがどのようにサポートされているか、および次の事項について説明します。

• 永続ストア(ファイルおよびJDBCストア)

• JMSサーバー

• ストア・アンド・フォワード(SAF)エージェント

• パス・サービス

• メッセージング・ブリッジ

• JMSシステム・モジュールおよびJMSアプリケーション・モジュール

• JMS接続プール

また、この章では、同じWebLogicサーバー・インスタンスまたはクラスタの他のパーティション、およびリモート・クライアントJVMまたはリモート・サーバーJVMから、パーティション化されたJMSリソースにアクセスする方法についても説明します。

マルチテナント環境でJMSを構成する前に、次について熟知し、それらをすでに作成していることを前提としています。

• 仮想ターゲット。詳細は、「仮想ターゲットの構成」を参照してください。

• ドメイン・パーティション。詳細は、「ドメイン・パーティションの構成」を参照してください。

• パーティションに固有のセキュリティ・レルム(必要な場合)。詳細は、セキュリティの構成を参照してください。

• リソース・グループ・テンプレート(必要な場合)。詳細は、「リソース・グループ・テンプレートの構成」を参照してください。

• リソース・グループ。詳細は、「リソース・グループの構成」を参照してください。

この章では、既存のWLSメッセージング構成を熟知していることを前提としています。次のドキュメントを参照してください。

• Oracle WebLogic Server JMSリソースの管理

• WebLogic永続ストアの管理

• Oracle WebLogic Server WebLogicメッセージング・ブリッジの管理

• Oracle WebLogic Serverストア・アンド・フォワード・サービスの管理

• Oracle WebLogic ServerメッセージドリブンBeanの開発

この章の内容は次のとおりです。

• メッセージング構成のスコープについて

• 構成検証およびターゲット指定のルールについて

• メッセージング・コンポーネントの構成

• パーティション固有のJMSオーバーライドの構成

• JNDIを使用したパーティション・スコープのメッセージング・リソースへのアクセス

• JMSでのパーティション関連付け

• パーティション・スコープのメッセージング・コンポーネントの管理

• ベスト・プラクティス

• 制限事項

メッセージング構成のスコープについて

非パーティション環境でWebLogic Serverを操作する場合、ドメイン・レベルでJMSアーティファクトを構成およびデプロイできます。JMSアーティファクトの例には、永続ストア(ファイルまたはJDBCストア)、JMSサーバー、ストア・アンド・フォワード・エージェント、パス・サービスおよびメッセージング・ブリッジが含まれ、これらは、JMX PersistentStoreMBean、JMSServerMBean、SAFAgentMBean、PathServiceMBeanおよびMessagingBridgeMBeanを使用して、WebLogic Serverドメインのconfig.xmlファイルで直接構成されます。

また、接続ファクトリや宛先などのJMSリソースは、JMSモジュールと呼ばれる外部ディスクリプタ・ファイルで構成されます。JMSモジュールは、最もよくJMSシステム・リソースとして構成されます(JMSSystemResourceMBeanを使用)。一般的ではありませんが、JMSモジュールは、デプロイ済アプリケーションに含まれるスタンドアロンまたはアプリケーション・スコープのXMLファイル(それぞれスタンドアロン・スコープのモジュールおよびアプリケーション・スコープのモジュールと呼ばれる)として、またはJava EE 7接続ファクトリおよび宛先注釈(アプリケーション・スコープのモジュールで定義された外部リソースと同じ基本的なセマンティクスを持つ)によって間接的に、組み込むことができます。

WebLogic Server MTで作業する場合、前述のすべてのJMSアーティファクトは、次のスコープで定義およびデプロイできます。

• ドメイン・スコープ - 非パーティションWLS環境の場合とまったく同じ構成を使用。

• リソース・グループ・スコープ - パーティション・レベルまたはドメイン・レベルで作成されたリソース・グループの一部として。

• リソース・グループ・テンプレート・スコープ - ドメイン・レベルで作成されたリソース・グループ・テンプレートの一部として。

リソース・グループは、オプションで、リソース・グループ・テンプレート・スコープのJMS構成を継承できます。パーティションにつき1つのリソース・グループのみが特定のリソース・グループ・テンプレートを参照でき、同様に、1つのドメイン・レベルのリソース・グループのみがリソース・グループ・テンプレートを参照できます。

まとめると、JMSメッセージング・アーティファクトのドメイン構成の構造は、次のとおりです。

• ドメイン・レベルのJMS構成

• JMS構成を含むドメイン・レベルのリソース・グループ

• JMS構成を含むドメイン・レベルのリソース・グループ・テンプレート

• リソース・グループ・テンプレートに基づいたドメイン・レベルのリソース・グループ

• パーティション

  • JMS構成を含むパーティション・レベルのリソース・グループ

  • リソース・グループ・テンプレートに基づいたパーティション・レベルのリソース・グループ

構成検証およびターゲット指定のルールについて

検証およびターゲット指定のルールでは、WebLogic Server MTのJMS構成が、分離しており、自己完結型で、管理しやすいことを確認します。これらのルールは、次の目標を実現するのに役立ちます。

• リソース・グループが、他のリソース・グループまたはドメイン・レベルのリソースで失敗の原因となることなく、独立して停止または移行できる。

• リソース・グループ・テンプレートが、リソース・グループ、ドメイン構成または他のリソース・グループ・テンプレートに直接依存しない、完全にカプセル化され、独立した構成ユニットである。

• リソース・グループが単一のサーバーのターゲットとして指定されているか、クラスタのターゲットとして指定されているか、ターゲット指定されていないかに関係なく、同じ構成が有効である。

• 以前のリリースで有効だったドメイン・レベルの構成の動作に変更がない。たとえば、非リソース・グループ/リソース・グループ・テンプレートのドメイン・レベルの動作は、下位互換性のために変更されません。

これらの目標を実現するのに役立つ基本的で高レベルのルールでは、JMS構成MBeanは、同じスコープにある別の構成MBeanのみを参照できます。たとえば、リソース・グループ・テンプレートが定義されたJMSサーバーは、同じリソース・グループ・テンプレートでも定義されたストアのみを参照できます。これらのルールは、構成検証チェック、および実行時に記録されるエラーと警告によって施行されます。

メッセージング・コンポーネントの構成

次の各項では、マルチテナント環境でJMSアーティファクトを構成する際の考慮事項について説明します。

JDBCまたはファイル永続ストアの構成

JMSサーバー、SAFエージェントまたはパス・サービスを構成する前に、永続ストアを作成する手順が必要です。これは、リソース・グループおよびリソース・グループ・テンプレート・スコープのJMSサーバー、SAFエージェントおよびパス・サービスは、既存の永続ストアを参照する必要があるためです。

ドメインまたはパーティションにスコープされたリソース・グループ内のカスタム・ファイルまたはJDBC永続ストアの作成は、ドメイン・レベルの永続ストアの作成と似ています。ただし、追加の手順として、スコープを指定する必要があります。WLS管理コンソールおよびFusion Middleware Control (FMWC)では、永続ストアの作成に使用できるスコープがリストされた作成プロセスの最初の手順に、「スコープ」ドロップダウン・メニューがあります。WLSTでは、所有者MBean (ドメイン、リソース・グループまたはリソース・グループ・テンプレートのMBean)でcreatePersistentStoreを使用して、永続ストアを作成する必要があります。

次の分散および移行ポリシー・ルールは、すべてのリソース・グループおよびリソース・グループ・テンプレート・スコープの永続ストアに適用されます。

• JMSサーバー分散宛先またはSAFエージェント・インポート済宛先をホストするために使用されるリソース・グループまたはリソース・グループ・テンプレート・スコープのストアは、Distributed分散ポリシー(デフォルト)を指定する必要があります。この設定により、クラスタ内のWebLogic Serverインスタンスごとにストア・インスタンスがインスタンス化されます。さらに、Distributed分散ポリシーが指定されたリソース・グループまたはリソース・グループ・テンプレート・スコープのストアは、オプションで、On-failureまたはAlways移行ポリシーで構成できます。

• パス・サービスによって使用される、またはJMSサーバー・スタンドアロン(非分散)宛先をホストするために使用される、リソース・グループまたはリソース・グループ・テンプレート・スコープのストアは、Singleton分散ポリシーを指定する必要があります。この設定により、クラスタ内の単一のストア・インスタンスがインスタンス化されます。さらに、Singleton分散ポリシーが指定されたリソース・グループまたはリソース・グループ・テンプレート・スコープのストアは、移行ポリシーとしてOffではなくOn-failureまたはAlwaysを指定する必要があります。デフォルトはOffです。

• On-failureまたはAlways移行ポリシーが指定された、クラスタのターゲットとして指定されたストアでは、クラスタが、データベース・リーシングまたはデータベース・リーシングがベスト・プラクティスとして推奨されているクラスタ・リーシングのいずれかで構成される必要があります。

これらのポリシーは、クラスタをターゲット指定するストアおよびJMSアーティファクトの分散および高可用性の動作を制御します。詳細は、『Oracle WebLogic Server JMSリソースの管理』の簡素化されたJMSクラスタおよび高可用性の構成に関する項を参照してください。

ファイルとJDBCストアの両方に施行された構成検証およびターゲット指定のルールを次に示します。

• リソース・グループまたはリソース・グループ・テンプレート・レベルのJMSサーバー、SAFエージェントまたはパス・サービスは、構成されたストアを参照する必要があります。これらはnullを参照できません。

• リソース・グループ・テンプレート・スコープのJMSサーバー、SAFエージェントまたはパス・サービスは、同じリソース・グループ・テンプレートで定義されたストアのみを参照できます。子リソース・グループ・レベルで定義されたストアを参照できません。

• リソース・グループ・スコープのJMSサーバー、SAFエージェントまたはパス・サービスは、同じリソース・グループ、またはオプションでリソース・グループによって参照されるリソース・グループ・テンプレートで定義されたストアのみを参照できます。

• ドメイン・レベルのJMSサーバー、SAFエージェントまたはパス・サービスは、ドメイン・スコープのストアのみを参照できます。

JDBCストアに固有の追加のルールを次に示します。

• リソース・グループ・テンプレート・スコープのJDBCストアは、同じリソース・グループ・テンプレートにあるデータ・ソースのみを参照できます。

• リソース・グループ・スコープのJDBCストアは、同じリソース・グループ、またはオプションでリソース・グループによって参照されるリソース・グループ・テンプレートにあるデータ・ソースのみを参照できます。

• ドメイン・スコープのJDBCストアは、ドメイン・スコープのデータ・ソースのみを参照できます。

JMSサーバーの構成

ドメイン・レベルのリソース・グループまたはパーティション内にスコープされたJMSサーバーの作成は、ドメイン・レベルでのJMSサーバーの作成と似ています。追加の手順は、スコープを指定することです。WLS管理コンソールおよびFusion Middleware Control (FMWC)では、JMSサーバーの作成に使用できるスコープがリストされた作成プロセスの最初の手順に、「スコープ」ドロップダウン・メニューがあります。WLSTでは、所有者MBean (ドメイン、リソース・グループまたはリソース・グループ・テンプレートのMBean)でcreateJMSServerを使用して、JMSサーバーを作成する必要があります。

他に必要な手順は、JMSサーバーと同じスコープで構成された永続ストアを参照するように、JMSサーバーを構成することです。

最後に、JMSサーバーが分散宛先をホストするために使用される場合、そのストアはDistributed分散ポリシーで構成される必要があります。JMSサーバーがスタンドアロン(非分散)宛先をホストする場合、ストアはSingleton分散ポリシーで構成される必要があります。

ストア・アンド・フォワード(SAF)エージェントの構成

ドメイン・レベルのリソース・グループまたはパーティション内にスコープされたSAFエージェントの作成は、ドメイン・レベルでのSAFエージェントの作成と似ています。追加の手順は、スコープを指定することです。WLS管理コンソールおよびFusion Middleware Control (FMWC)では、SAFエージェントの作成に使用できるスコープがリストされた作成プロセスの最初の手順に、「スコープ」ドロップダウン・メニューがあります。WLSTでは、所有者MBean (ドメイン、リソース・グループまたはリソース・グループ・テンプレートのMBean)でcreateSAFAgentを使用して、SAFエージェントを作成する必要があります。

他に必要な手順は、SAFエージェントと同じスコープで構成された永続ストアを参照するように、SAFエージェントを構成することです。このストアは、Distributed分散ポリシー(デフォルト)で構成される必要があります。

注意: サービス・タイプがReceiving Onlyのリソース・グループまたはリソース・グループ・テンプレート・レベルのSAFエージェントは、許可されません。このような構成を設定しようとすると、例外がスローされるか、エラー・メッセージが記録されます。このモードは、古い形式のJAX-RPC Webサービスの信頼性のあるメッセージングに固有のものです。かわりに、JAX-WS RMを使用します。

分散宛先による順序単位の使用をサポートするパス・サービスの構成

リソース・グループまたはリソース・グループ・テンプレートが、順序単位(UOO)メッセージをホストするために使用される分散宛先も構成する場合、パス・サービスは、リソース・グループまたはリソース・グループ・テンプレートで構成する必要があります。また、ハッシュ・ベースのUOOルーティングがリソース・グループまたはリソース・グループ・テンプレート・スコープでサポートされていないため、このような分散宛先は、HashではなくPathServiceに設定された順序単位ルーティング・ポリシーで構成される必要があります。リソース・グループまたはリソース・グループ・テンプレート・スコープの分散宛先は、ルーティングUOOメッセージの同じリソース・グループまたはリソース・グループ・テンプレートで構成されたパス・サービスのみを使用します。PathService順序単位ルーティング・ポリシーを構成しないリソース・グループまたはリソース・グループ・テンプレート・スコープの分散宛先にメッセージを送信しようとすると、例外で失敗します。

ドメイン・レベルのリソース・グループまたはパーティション内にスコープされたパス・サービスの作成は、ドメイン・レベルでのパス・サービスの作成と似ています。追加の手順は、スコープを指定することです。WLS管理コンソールおよびFusion Middleware Control (FMWC)では、パス・サービスの作成に使用できるスコープがリストされた作成プロセスの最初の手順に、「スコープ」ドロップダウン・メニューがあります。WLSTでは、所有者MBean (ドメイン、リソース・グループまたはリソース・グループ・テンプレートのMBean)でcreatePathServiceを使用して、パス・サービスを作成する必要があります。

他に必要な手順は、パス・サービスと同じスコープで構成された永続ストアを参照するように、パス・サービスを構成することです。このストアは、Singleton分散ポリシーおよびAlwaysまたはOn-Failure移行ポリシーで構成される必要があります。

メッセージング・ブリッジの構成

ドメイン・レベルのリソース・グループまたはパーティション内にスコープされたメッセージング・ブリッジの作成は、ドメイン・レベルでのメッセージング・ブリッジの作成と似ています。追加の手順は、スコープを指定することです。WLS管理コンソールおよびFusion Middleware Control (FMWC)では、メッセージング・ブリッジの作成に使用できるスコープがリストされた作成プロセスの最初の手順に、「スコープ」ドロップダウン・メニューがあります。WLSTでは、所有者MBean (ドメイン、リソース・グループまたはリソース・グループ・テンプレートのMBean)でcreateMessagingBridgeを使用して、メッセージング・ブリッジを作成する必要があります。

次の分散および移行ポリシー・ルールは、すべてのリソース・グループまたはリソース・グループ・テンプレート・スコープのメッセージング・ブリッジに適用されます。

• ブリッジでDistributed分散ポリシー(デフォルト)を指定して、クラスタのターゲットとして指定されたブリッジがクラスタ内のサーバーごとにインスタンスをデプロイするようにします。Distributed分散ポリシーが指定されたメッセージング・ブリッジは、オプションでOn-failure移行ポリシーを構成して、高可用性のサポートを追加することもできます。

• ブリッジでSingleton分散ポリシーを指定して、クラスタのターゲットとして指定されたブリッジがクラスタごとに1つのインスタンスをデプロイするように制限します。Singleton分散ポリシーが指定されたメッセージング・ブリッジには、OffではなくOn-failure移行ポリシーを指定する必要があります。デフォルトはOffです。

• On-failure移行ポリシーが指定された、クラスタのターゲットとして指定されたブリッジでは、クラスタが、データベース・リーシングまたはデータベース・リーシングがベスト・プラクティスとして推奨されているクラスタ・リーシングのいずれかで構成される必要があります。

これらのポリシーは、クラスタをターゲット指定するメッセージング・ブリッジの高可用性の動作および分散動作を制御します。分散および移行ポリシーの詳細は、『Oracle WebLogic Server JMSリソースの管理』の簡素化されたJMSクラスタおよび高可用性の構成に関する項を参照してください。

メッセージング・ブリッジに固有の構成検証ルールを次に示します。

• リソース・グループ・テンプレート・スコープのメッセージング・ブリッジは、同じスコープのメッセージング・ブリッジ宛先のみを参照できます。

• リソース・グループ・スコープのメッセージング・ブリッジは、同じリソース・グループ、またはオプションでリソース・グループによって参照されるリソース・グループ・テンプレートにあるメッセージング・ブリッジ宛先のみを参照できます。

• ドメイン・スコープのメッセージング・ブリッジは、ドメイン・スコープのメッセージング・ブリッジ宛先のみを参照できます。

JMSシステム・リソースおよびアプリケーション・スコープのJMSモジュールの構成

ドメイン・レベルのリソース・グループまたはパーティション内にスコープされたJMSシステム・リソースの作成は、ドメイン・レベルでのJMSシステム・リソースの作成と似ています。追加の手順は、スコープを指定することです。WLS管理コンソールおよびFusion Middleware Control (FMWC)では、JMSシステム・リソースの作成に使用できるスコープがリストされた作成プロセスの最初の手順に、「スコープ」ドロップダウン・メニューがあります。WLSTでは、所有者MBean (ドメイン、リソース・グループまたはリソース・グループ・テンプレートのMBean)でcreateJMSSystemResourceを使用して、JMSシステム・リソースを作成する必要があります。

ドメイン・レベルのリソース・グループ・スコープを持つ、またはパーティション内にあるアプリケーション・スコープのJMSモジュールの作成は、ドメイン・レベルでの作成と似ています。アプリケーション・デプロイメントには、JMSモジュール・ファイル、またはJMSモジュール・ファイルを含むアプリケーションEARファイルを含めることができます。追加の手順は、リソース・グループまたはリソース・グループ・テンプレート・スコープを指定することです。詳細は、「アプリケーションのデプロイ」を参照してください。

注意: JMSサーバーを作成し、サブモジュール・ターゲットを指定するアプリケーションを同じ構成編集セッション内ですべてこのJMSサーバーにデプロイする場合、デプロイメントは成功しない可能性があります。JMSサーバーを個別の編集セッションに構成することをお薦めします。

注意: アプリケーション・リソース・モジュールに構成を組み込むのではなく、システム・リソース・モジュールを使用してJMSを構成することを強くお薦めします。アプリケーション・スコープの構成とは異なり、システム・リソース構成は、管理者または開発者が、WLS管理コンソール、WLSTまたはMBeanを使用して、動的に調整し、簡単にモニターできます。

リソース・グループまたはリソース・グループ・テンプレート・スコープのJMSモジュールのリソースに関連付けられた構成検証およびターゲット指定のルールを次に示します。

サブデプロイメントの定義

• リソース・グループまたはリソース・グループ・テンプレート・スコープのサブデプロイメントは、なし(null)、単一のJMSサーバー、または単一のSAFエージェントのみをターゲット指定できます。

• リソース・グループ・テンプレート・スコープのサブデプロイメントは、同じリソース・グループ・テンプレートで定義されたJMSサーバーまたはSAFエージェントのみを参照できます。

• リソース・グループ・スコープのサブデプロイメントは、同じリソース・グループ、またはオプションでリソース・グループによって参照されるリソース・グループ・テンプレートで定義されたJMSサーバーまたはSAFエージェントのみを参照できます。

JMSモジュールのリソース

次の表は、JMSモジュールのリソース・タイプのターゲット指定のルールを示しています。

リソース・タイプ	サブデプロイメントの使用	デフォルトのターゲット指定の使用
スタンドアロン(シングルトン)宛先	Singleton分散ポリシーが指定されたストアを参照するJMSサーバーをターゲット指定するサブデプロイメントのみをターゲット指定できます。	Singleton分散ポリシー・ストアを参照する同じリソース・グループまたはリソース・グループ・テンプレート・スコープに構成された単一のJMSサーバーがある場合のみ、デプロイが行われます。この場合、宛先は、この特定のJMSサーバーにデプロイします。Distributed分散ポリシー・ストアを参照するJMSサーバーは無視され、スコープの外部(たとえば、ドメイン・レベルまたは別のリソース・グループまたはリソース・グループ・テンプレート)に定義されたJMSサーバーも無視されます。
共通分散宛先*	Distributed分散ポリシーが指定されたストアを参照するJMSサーバーをターゲット指定するサブデプロイメントのみをターゲット指定できます	Distributed分散ポリシー・ストアを参照する同じリソース・グループまたはリソース・グループ・テンプレート・スコープに構成された単一のJMSサーバーがある場合のみ、デプロイが行われます。この場合、宛先は、この特定のJMSサーバーにデプロイします。Singleton分散ポリシー・ストアを参照するJMSサーバーは無視され、スコープの外部(たとえば、ドメイン・レベルまたは別のリソース・グループまたはリソース・グループ・テンプレート)に定義されたJMSサーバーも無視されます。
SAFインポート済宛先	SAFエージェントをターゲット指定するサブデプロイメントのみをターゲット指定できます。	同じリソース・グループまたはリソース・グループ・テンプレート・スコープに構成された単一のSAFエージェントがある場合のみ、デプロイが行われます。スコープの外部(たとえば、ドメイン・レベルまたは別のリソース・グループまたはリソース・グループ・テンプレート)に定義されたSAFエージェントも無視されます。
接続ファクトリ	サブデプロイメントをターゲット指定できます。	リソース・グループのターゲットによって囲まれたすべてのWLSサーバー・インスタンスにデプロイします。
外部サーバー	Distributed分散ポリシーが指定されたストアを参照するJMSサーバーをターゲット指定するサブデプロイメントのみをターゲット指定できます。ベスト・プラクティスとして、かわりにデフォルトのターゲット指定を使用します	リソース・グループのターゲットによって囲まれたすべてのWLSサーバー・インスタンスにデプロイします。

* 注意: リソース・グループまたはリソース・グループ・テンプレート・スコープの共通分散トピックは、Partitioned転送ポリシーを指定する必要があります。たとえば、パーティション化された分散トピック(PDT)である必要があります。PDTの「パーティション化された」という単語は、WebLogic Server MTパーティションの「パーティション」という単語と同じ意味ではないことに注意してください。PDTとWebLogic Server MTのパーティションは、2つの独立した概念です。PDTを使用するためのトレードオフの詳細は、「制限事項」を参照してください。

パーティション固有のJMSオーバーライドの構成

リソース・グループ・テンプレート・スコープのJMS構成アーティファクトは、リソース・グループ・テンプレートを使用するパーティションに固有の値が不足しているか正しくないため、完全ではない可能性があります。各パーティションには、パーティション・ランタイムへの正しいデプロイメントのテンプレートから導出された値をカスタマイズするために指定された適切なオーバーライド値が必要な可能性があります。パーティション固有でリソース・グループ・スコープのJMS構成は、リソース・デプロイメント・プランまたはアプリケーション・デプロイメント・プランを使用してパーティションごとにカスタマイズできます。また、JMSシステム・モジュール内のJMS外部サーバー構成は、JMSSystemResourceOverrideMBeansを使用してカスタマイズできます。

リソース・オーバーライドによって、システム管理者は、JMSリソースおよびデータ・ソースなどの他のリソースをパーティション・レベルでカスタマイズできます。リソース・グループ・テンプレートを拡張するリソース・グループを含むパーティションを作成する場合は、そのリソース・グループ・テンプレートで定義されている特定のリソースの設定をオーバーライドできます。リソース・グループ・テンプレートを拡張しないリソース・グループをパーティション内に作成し、このリソース・グループ内にリソースを作成する場合、オーバーライドは不要で、これらのリソースにパーティション固有の値を設定します。

オーバーライドは、主にリソースに共通の定義が存在する場合に、リソースを使用する各パーティションがリモートに格納された状態を分離する必要がある、リソース・グループ・テンプレートなどで使用されます。たとえば、同じJMSサーバー、JDBCストア、データ・ソースおよびJMSモジュールの構成は、単一のリソース・グループ・テンプレートで構成し、リソース・グループ・テンプレートを参照する各パーティションでリソース・グループを構成することによって、同じクラスタ内の複数のパーティションにデプロイできます。その後、パーティション・リソース・グループをパーティションごとにオーバーライドして、それぞれのデータ・ソースが異なるデータベースまたは同じデータベース内の異なるスキーマに接続していることを確認できます。

詳細には、システム管理者は、次の特定の手法を使用して、パーティションのリソース定義をオーバーライドできます。

• リソース・オーバーライド構成MBean - 既存のリソース構成MBeanの属性のサブセットを公開する構成MBean。オーバーライド構成MBeanのインスタンス上の属性セットは、対応するリソース構成MBeanインスタンス内のその属性の値を置き換えます。JMSシステム・モジュールの外部JMSサーバーおよび関連する構成アーティファクトは、オーバーライドMBeanを使用して、ユーザー、パスワードおよびプロバイダURLの設定をオーバーライドできます。オーバーライドMBeanを使用する場合、対応する外部JMSサーバーおよび関連するデプロイメントBeanごとに個別のオーバーライドMBeanを定義する必要があります。JMSモジュールがすでにデプロイされた後の実行時に行われたこれらの属性への構成変更は、パーティションまたはJVMを再起動して、変更を有効にする必要があります。

• リソース・デプロイメント・プラン - パーティション内で構成された任意のリソースを識別し、それらのリソースの属性設定をオーバーライドするXMLファイル。永続ストア、JMSサーバー、SAFエージェント、メッセージング・ブリッジ、ブリッジ宛先およびパス・サービスは、リソース・デプロイメント・プランのconfig-resource-override要素を使用し、キュー、トピックおよび接続ファクトリなどのJMSシステム・モジュールのJMSリソースは、external-resource-override要素を使用します。

• パーティション固有のアプリケーション・デプロイメント・プラン - 既存のアプリケーション・デプロイメント・プランと同様に、これにより、管理者は、パーティション内のアプリケーション・デプロイメントごとに、パーティション固有のアプリケーション・デプロイメント・プランを指定できます。パーティション固有のアプリケーション・デプロイメント・プランの詳細は、「パーティション固有のデプロイメント・プランの使用方法」を参照してください。

管理者は、これらのリソース・オーバーライド手法を任意に組み合せることができます。システムでは、次に示す昇順の優先度でこれらが適用されます。

• パーティション固有のアプリケーション・デプロイメント・プランを含む、config.xmlおよび外部ディスクリプタ。

• リソース・デプロイメント・プラン。

• オーバーライド構成MBean。

  属性がリソース・デプロイメント・プランおよびオーバーライド構成MBeanの両方で参照される場合、オーバーライド構成MBeanが優先されます。

オーバーライドの詳細は、「リソース・オーバーライドの構成」を参照してください。

JNDIを使用したパーティション・スコープのメッセージング・リソースへのアクセス

パーティションのJMSリソースにアクセスするには、アプリケーションでは、まずパーティションへのJNDI初期コンテキストを確立する必要があります。パーティションのコンテキストを作成すると、コンテキスト・オブジェクトはパーティションのネームスペースに固定され、それ以降のJNDI操作はすべて、そのパーティションのスコープの中で行われます。java.naming.provider.urlプロパティを設定してコンテキストが作成されると、JNDIはパーティションを認識するためにパーティション情報をプロバイダURLの値の中で探します。次の4つの異なるURLタイプは、特定のパーティションにコンテキストを関連付けます。

• URLを指定しない。

• パーティションの仮想ホストまたはURIを指定するURLの使用。

• パーティションの専用ポートを指定するURLの使用。

• 特別なlocal: URLの使用。「local: URLまたは修飾されたJNDI名を使用したローカル・クロス・パーティションのユースケース」を参照してください。

また、JNDI名の先頭に特別なスコープ文字列を付加することによって、既存のコンテキストを使用して別のパーティションのリソースを参照できます。

これらのそれぞれの方法について、次の各項で説明します。

URLを指定しない

プロバイダURLを指定せずにローカル初期コンテキストを作成するだけで、WebLogic Serverインスタンス上のパーティションで実行中のアプリケーションは、独自のローカル・パーティションのJMSリソースにアクセスできます。この方法は、ローカルにスコープされたコンテキストを作成するためのベスト・プラクティスです。

パーティション仮想ホストまたはパーティションURIの指定

コンテキストURLがパーティションに構成された仮想ホストURLまたはURIと一致する場合、JNDIはそのパーティションのコンテキストを作成し、コンテキストからのすべてのリクエストは、パーティションのJNDIネームスペースに委任されます。

そのため、JMSアプリケーションは、次の形式のURLを指定することによってt3またはHTTPプロトコルを使用して、異なるJVMまたはWLSクラスタで実行中のWLS JMSリソースにアクセスできます。

• t3://virtualhost:port

• t3://host:port/URI

注意: URIにスペルミスがあるかURIが存在しないと、コンテキストはドメイン・レベルにスコープされ、警告はありません。

専用ポートURLの指定

特定のポートまたはアドレスをパーティション内のチャネル専用にすることが可能で、この場合、URL形式はt3://host:portになります。

これは、12.2.1以前のクライアントがパーティション・スコープのリソースと相互運用するためにのみサポートされている方法です。

詳細は、「仮想ターゲットの構成」を参照してください。

注意: この方法では、SSLは、以前のリリースとの相互運用性のために使用される場合、現在サポートされていません。

local: URLまたは修飾されたJNDI名を使用したローカル・クロス・パーティションのユースケース

あるパーティションのアプリケーションは、前の項で説明したURLのいずれかを使用して、同じWebLogic Serverインスタンスまたは同じクラスタの別のパーティションにアクセスできます。

ただし、特定のホスト、ポートまたはURIを指定する必要なく、同じサーバーに存在するパーティション間のより効率的なアクセスをサポートするために、アプリケーションには次のオプションがあります。

• local:プロトコルURLを指定したコンテキストを作成します。

  • local:// - コンテキストを現在のパーティション上に作成します(パーティションまたはドメインのいずれか)。

  • local://?partitionName=DOMAIN - コンテキストをドメイン上に作成します。

  • local://?partitionName=partition_name - コンテキストをパーティションpartition_name上に作成します。

• URLを指定せずにコンテキストを作成し、JNDI名を指定する際に明示的なスコープを接頭辞として付けます。

  • domain:<JNDIName> - ドメイン・レベルのJNDIエントリをルックアップします。

  • partition:<partition_name>/<JNDIName> - 指定したパーティションのJNDIエントリをルックアップします。

JMSでのパーティション関連付け

次の各項では、様々なJMSパーティション関連付けについて説明します。

接続ファクトリとその接続またはJMSコンテキストとの間のパーティション関連付け

JMSクライアント接続およびJMSコンテキストは、その接続ファクトリが取得されたパーティションに永久に関連付けられ、現在のスレッドに関連付けられたパーティションに基づいてパーティションを変更しません。

非同期コールバックとのパーティション関連付け

JMSがメッセージまたは例外を非同期リスナーにプッシュするか、同様にイベントを宛先可用性リスナーまたは非同期送信完了リスナーにプッシュすると、リスナーのローカル・パーティションID (宛先のパーティションではない)がコールバック・スレッドに関連付けられます。ローカル・パーティションIDは、非同期リスナーを作成したスレッドに関連付けられたパーティションです。

一致するスコープが必要な接続ファクトリおよび宛先

接続ファクトリは、接続ファクトリと同じパーティションに定義された宛先とのみ相互作用できます。たとえば、QueueBrowser、MessageConsumer/JMSConsumer、TopicSubscriberまたはMessageProducer/JMSProducerクライアント・オブジェクトは、これらのクライアント・オブジェクトの作成に使用された接続ファクトリが宛先と同じパーティションに定義された場合にのみ、宛先と通信できます。さらに、接続ファクトリは、接続ファクトリと同じクラスタまたはサーバーJVMから取得された宛先とのみ相互作用できます。

一時宛先のスコープ

12.2.1リリースより前は、JMSサーバーはドメイン・レベルでのみデプロイされ、一時宛先は、次の両方を満たすJMSサーバーによってのみホストされました。

• Hosting Temporary Destinationsがtrue (デフォルト)に設定されている。

• 一時宛先の作成に使用された接続ファクトリと同じWLSサーバー・インスタンスまたは同じクラスタでホストされている。

WebLogic Server MTで一時宛先を作成する動作は、次のとおりです。

• WLS (非MT)の場合のように、Hosting Temporary Destinationsが有効で、一時宛先の作成に使用される接続ファクトリと同じWLSサーバー・インスタンスまたは同じクラスタにホストされるJMSサーバーによってのみ、一時宛先をホストできます。

• リソース・グループまたはリソース・グループ・テンプレート・スコープ(ドメイン・リソース・グループなど)で構成された接続ファクトリを使用してJMS接続が作成された場合、一時宛先は、同じスコープで構成されたJMSサーバーによってのみホストされます。

• 非リソース・グループまたはリソース・グループ・テンプレート・スコープのパーティション・レベルの接続ファクトリを使用してJMS接続が作成された場合、接続ファクトリと同じパーティションのJMSサーバーで一時宛先を作成できます。非リソース・グループまたはリソース・グループ・テンプレート・スコープのパーティション・レベルの接続ファクトリは、単にデフォルトの接続ファクトリで、たとえばJNDI名がweblogic.jms.ConnectionFactoryやweblogic.jms.XAConnectionFactoryの接続ファクトリです。

• 非リソース・グループまたはリソース・グループ・テンプレート・スコープのドメイン・レベルの接続ファクトリを使用してJMS接続が作成された場合、ドメイン・レベルのJMSサーバー(ドメイン・レベルのリソース・グループにスコープされたJMSサーバーなど)で一時宛先を作成できます。

許可されたスコープ内に修飾されたJMSサーバーが見つからない場合、一時宛先を作成しようとすると、例外が返されます。

パーティション・スコープのメッセージング・コンポーネントの管理

次の各項では、パーティション・スコープのメッセージングの特定の状況の管理について説明します。

ランタイム・モニタリングおよびランタイム・コントロール

既存のすべてのメッセージング・ランタイムMBeanは、パーティション・スコープのJMS構成およびデプロイメントのモニタリングおよび制御でサポートされ、JMXベースの管理クライアントにアクセスできます。パーティション・スコープのJMSランタイムMBeanは、対応するParititionRuntimeMBeanインスタンスの下にあります。

次に例を示します。

• JMSサーバー、接続、およびPooledConnectionランタイムMBeanは、serverRuntime/PartitionRuntimes/partition/JMSRuntimeの下のランタイムMBean階層にあります

• SAFランタイムMBeanは、serverRuntime/PartitionRuntimes/partition/SAFRuntimeMBeanの下のランタイムMBean階層にあります

• メッセージング・ブリッジおよびパス・サービス・ランタイムMBeanは、serverRuntime/PartitionRuntimes/partitionの直下のランタイムMBean階層にあります

詳細は、「パーティションのモニタリングおよびデバッグ」を参照してください。

パーティション・スコープのセキュリティの管理

パーティション・メッセージング構成に関連するセキュリティ・ロールおよびポリシー定義は、WLSシステム管理者が担当します。

WebLogic Server MTでは、従来のWebLogic Serverセキュリティ・サポートを次の2つの重要な方法で拡張しています。

• 複数のレルム - WebLogic Server MTでは、複数のアクティブなセキュリティ・レルムをサポートし、異なるレルムに対して各パーティションを実行できます。

• アイデンティティ・ドメイン - アイデンティティ・ドメインは、ユーザーおよびグループの論理ネームスペースであり、通常は、物理データ・ストア内のユーザーとグループの1つの個別セットを表します。アイデンティティ・ドメインを使用して、特定のパーティションに関連付けられているユーザーを識別します。

その他の点では、パーティション・スコープのメッセージングのセキュリティの構成は、ドメイン・レベルのメッセージングのセキュリティの設定と似ています。詳細は、セキュリティの構成を参照してください。

トランザクションの管理

JVMのすべてのJTAトランザクションは、スコープに関係なく、単一のJTAトランザクション・マネージャによって処理されます。パーティション・スコープのXAリソース・マネージャ名は、パーティション名で自動的に修飾され、リソース・マネージャがトランザクション・マネージャに対して一意に識別され、独立して管理されるようにします。リソース・マネージャの1つの例として、永続ストアがあります。

トランザクション構成および制限の詳細は、「トランザクションの構成」を参照してください。

パーティションおよびリソース・グループのライフサイクル操作の管理

パーティションまたはリソース・グループに関連付けられたJMSアーティファクトは、そのパーティションまたはリソース・グループを起動および停止することによって起動および停止できます。これらの操作を実行する権限は、WLSシステム管理者およびオペレータに自動的に提供されます。

パーティション・スコープのJMS診断イメージのソース

メッセージング・コンポーネントは、診断イメージをパーティションにスコープする機能をサポートしていません。詳細は、「パーティション・スコープの診断イメージ・キャプチャの構成」を参照してください。

パーティション・スコープのJMSロギング

ドメイン・ログ・フォーマットが構成されていない場合、パーティション・スコープのJMSログ・メッセージは、パーティションIDと名前で修飾されます。ロギングの詳細は、「パーティションのモニタリングおよびデバッグ」を参照してください。

メッセージ・ライフサイクル・ロギング

オプションで有効化されたJMSサーバーおよびSAFエージェント・メッセージ・ライフサイクル・ロギングは、これらのサービスがパーティションにスコープされた場合と異なる場所に配置されます。ロギング・ファイルは、そのパーティションのディレクトリにあります。さらに、クラスタのターゲットとして指定されたJMSサーバーまたはSAFエージェントの異なるランタイムJMSサーバーおよびSAFエージェント・インスタンスのログ・ファイル名は、明確化されていることが保証されます。

絶対パス、相対パスまたはデフォルトを構成する場合に予期される新しいログの場所を、次にまとめます。

	構成なし(デフォルト)	/<absolute-path>/<file>	/<relative-path>/<file>
ドメイン・レベル	<domain-log>/<log-suffix>/<instance>-jms.messages.log	/<absolute-path>/<instance>-<file>	<domain-log>/<relative-path>/<instance>-<file>
パーティション	<partition-log>/<log-suffix>/<instance>-jms.messages.log	<relative-path>*と同じ	<partition-log>/<relative-path>/<instance>-<file>

* 注意: パーティション・スコープの構成は、絶対パスを相対パスとして処理します。

<domain-log> = <domain>/servers/<wl-server-name>

<partition-log> = <domain>/partitions/<partition-name>/system/servers/<wl-server-name>

<log-suffix> = logs/jmsservers/<configured-name> (JMSサーバーの場合)

<log-suffix> = logs/safagents/<configured-name> (SAFエージェントの場合)

<instance> =

• <configured-name> (JMSサーバーまたはSAFエージェントが単一のサーバーのターゲットとして指定された場合。)

• <configured-name>_<wl-server-name> (クラスタのターゲットとして指定され、ストアの分散ポリシーがDistributedの場合。)

  (あるWLSサーバー・インスタンスから別のWLSサーバー・インスタンスに移行しても、インスタンスは古い名前を保持することに注意してください。)

• <configured-name>_01 (クラスタのターゲットとして指定され、ストアの分散ポリシーがSingletonの場合。)

管理ヘルパー

JMSリソースを構成およびモニターするためのヘルパー・メソッドを提供するJMS固有のJava管理プログラミング・ユーティリティが2つあります。

JMSModuleHelperには、(モニターする) JMSランタイムMBeanを検索するヘルパー・メソッド、および特定のモジュールでJMSモジュール構成エンティティ(ディスクリプタBean)を管理(検索/作成/削除)するメソッドが含まれています。

JMSRuntimeHelperは、接続、宛先、セッション、メッセージ・プロデューサまたはメッセージ・コンシューマなどのJMSオブジェクトが指定された、対応するJMXランタイムMBeanを取得するための便利なメソッドを提供します。

12.2.1では、ドメイン・スコープのJMSリソースと、リソース・グループまたはリソース・グループ・テンプレート・スコープのJMSリソースの両方を処理するためのヘルパーの拡張バージョンが提供されます。

既存のJMSRuntimeHelperは、パーティション対応になるように拡張されます。ランタイム・ヘルパー・メソッドを呼び出す際には、指定したJNDIコンテキストと指定したJMSオブジェクトが同じパーティションに属している必要があります(それ以外の場合、例外がスローされます)。

拡張されたJMSModuleHelperは、スコープ対応で、次のインタフェースおよびクラスが含まれています。

• weblogic.jms.extensions.IJMSModuleHelper - すべてのヘルパー・メソッドを定義するインタフェース。

• weblogic.jms.extensions.JMSModuleHelper - 12.2.1より前のバージョンのJMSモジュール・ヘルパー。これはドメイン・レベルのJMSリソースのみを処理します。

• weblogic.jms.extensions.JMSModuleHelperFactory - 管理サーバーへの初期コンテキスト、スコープ・タイプ(ドメイン、リソース・グループまたはリソース・グループ・テンプレート)、およびスコープの名前が指定された特定のスコープで機能するJMSモジュール・ヘルパーのインスタンスを作成するファクトリ。

次のコードの抜粋は、3つの異なるスコープごとにJMSモジュール・ヘルパーを作成する方法を示しています。

   Context ctx = getContext(); // get an initial JNDI context
 
   JMSModuleHelperFactory factory = new JMSModuleHelperFactory();
 
      // create a JMS module helper for domain level
 
   IJMSModuleHelper domainHelper = factory.getHelper(ctx, IJMSModuleHelper.ScopeType.DOMAIN, null); 
 
      // create a JMS module helper for Resource Group "MyResourceGroup"
 
   IJMSModuleHelper rgHelper = factory.getHelper(ctx, IJMSModuleHelper.ScopeType.RG, "MyResourceGroup");
 
      // create a JMS module helper for Resource Group Template "MyResourceGroupTemplate"
 
   IJMSModuleHelper rgtHelper = factory.getHelper(ctx, IJMSModuleHelper.ScopeType.RGT, "MyResourceGroupTemplate");

JMSモジュール・ヘルパー・インスタンスが作成されると、それを使用して、対応するスコープにスコープされたJMSリソースを作成できます。たとえば、次のコード例では、リソース・グループMyResourceGroupのJMSサーバーMyJMSServerにJMSQueueを使用したJMSシステム・リソースを作成しています。(JMSサーバーおよびリソース・グループはすでに作成されていることを前提としています。)

   String jmsServer = "MyJMSServer";
 
   String jmsSystemModule = "MyJMSSystemModule";
 
   String queue = "MyQueue";
 
   String queueJNDI = "jms/myQueue";
 
   rgHelper.createJMSSystemResource(jmsSystemModule, null);
 
   rgHelper.createQueue(jmsSystemModule, jmsServer, queue, queueJNDI, null);

ファイルの場所

永続ストアは、様々な目的のためにファイル・システムに多数のファイルを作成します。これらのファイルには、ファイル・ストア・データ・ファイル、ファイル・ストア・キャッシュ・ファイル(DirectWriteWithCache同期書込みポリシーが指定されたファイル・ストア用)、およびJMSサーバーとSAFエージェントのページング・ファイルがあります。

12.2.1より前のファイルの場所の動作は、ドメイン・スコープの永続ストアの場合と同じままです。これにより、永続データがアップグレード後にリカバリされ、予期された場所に格納されます。パーティション・スコープの構成では、異なるパーティションの同じ名前のストア間のファイルの衝突を防ぐために、これらのファイルは、パーティション・ファイル・システム内の分離したディレクトリに配置されます。

次に、WebLogic Server MTのファイル・ストア・システムで使用される様々なファイルの場所のサマリーを示します。partitionStem = partitions/<partitionName>/systemです

ストア・タイプ	構成されないストア・パス	相対ストア・パス	絶対ストア・パス	ファイル名
カスタム・ファイル	<domainRoot>/<partitionStem>/store/<storeName>	<domainRoot>/<partitionStem>/store/<relativePath>/<storeName>	<absolutePath>/<partitionStem>/store/<storeName>	<storeName>NNNNNN.DAT
キャッシュ	${java.io.tmpdir}/WLStoreCache/${domainName}/<partitionStem>/tmp	<domainRoot>/<partitionStem>/<tmp>/<relativePath>	<absolutePath>/<partitionStem>/tmp	<storeName>NNNNNN.CACHE
EJBタイマー	<domainRoot>/<partitionStem>/store/_WLS_EJBTIMER_<serverName>	<domainRoot>/<partitionStem>/store/<relativePath>/_WLS_EJBTIMER_<serverName>	<absolutePath>/<partitionStem>/store/_WLS_EJBTIMER_<serverName>	_WLS_EJBTIMER_<serverName>NNNNNN.dat
ページング	<domainRoot>/<partitionStem>/paging	<domainRoot>/<partitionStem>/paging/<relativePath>	<absolutePath>/<partitionStem>/paging	<jmsServerName>NNNNNN.TMP <safAgentName>NNNNNN.TMP

次に、前述の各ストア・タイプがディレクトリの場所を構成する方法のサマリーを示します。

ストア・タイプ	ディレクトリ構成
カスタム・ファイル	ファイル・ストアに構成されたディレクトリ。
キャッシュ	DirectWriteWithCache同期書込みポリシーを持つファイル・ストアに構成されたキャッシュ・ディレクトリ。
デフォルトEJBタイマー・ストア	WLSデフォルト・ストアの構成に構成されたディレクトリ。(パーティションEJBタイマー・デフォルト・ストアは、デフォルト・ストアから構成をコピーします。)
ページング	SAFエージェントまたはJMSサーバーに構成されたページング・ディレクトリ。

ベスト・プラクティス

この項では、MT環境のJMS初級ユーザーとJMS上級ユーザーのためのアドバイスおよびベスト・プラクティスを示します。

• MT関連の既知の問題については、『Oracle WebLogic Serverリリース・ノート』の構成の問題および回避策に関する項をすべてのユーザーが確認することをお薦めします。

• なんらかの理由で、新しく作成または更新されたJMSリソースが、実行中のパーティションでアクセスできない場合は、WebLogic Serverログ・ファイルで警告およびエラー・ログ・メッセージがないか確認してください。サーバー・ログ・メッセージに役立つ情報がない場合、パーティションを再起動すると、問題が解決することがよくあります。新しく作成されたパーティションは、いずれかのリソースが外部的にアクセス可能になる前に、明示的に起動する必要があります。

• 次のルールは、リソース・グループおよびリソース・グループ・テンプレート・スコープで常に適用されます。

  • スタンドアロン宛先をホストするパス・サービスとJMSサーバーに対して、Distribution Policy=Singletonストアを使用します。

  • 分散宛先をホストするSAFエージェントとJMSサーバーに対して、Distribution Policy=Distributedストアを使用します。

  • 次のものを持つクラスタのクラスタ・リーシングを構成します。

    • Distribution Policy=Singletonのストアまたはブリッジ。

    • Migration Policy=On-FailureまたはAlwaysのストアまたはブリッジ。

• JMSの使用に関連するより一般的なベスト・プラクティスは、『Oracle WebLogic Server JMSリソースの管理』のJMSの初級ユーザーおよび上級ユーザー向けのベスト・プラクティスに関する項を参照してください。

制限事項

次のJMSの機能または関連コンポーネントは、WebLogic Server MTで現在サポートされていません。

• パーティションへのクライアントSAF転送。

  • 追加した場合の動作は不明です。

  • サーバー側のSAFエージェントのパーティションへの転送は、サポートされていません。

• リソース・グループまたはリソース・グループ・テンプレート・スコープのJMSリソースへのCクライアント・アクセス。動作が定義されていません。

• .NETクライアント - .NETクライアントがパーティションのJMSリソースにアクセスした場合、例外がスローされます。

• レプリケートされた分散トピック(RDT)

  • レプリケートされた分散トピック(RDT)を含むリソース・グループまたはリソース・グループ・テンプレートへのJMSモジュールのデプロイメントは、例外で失敗します。

  • RDTは共通分散トピックのデフォルト・タイプで、Replicatedの転送ポリシーで構成されます。

  • 回避策は次のとおりです。

    • スタンドアロン(シングルトン)トピックを構成します。

    • パーティション化された分散トピック(PDT)を構成します。

      * PDTは、転送ポリシーをPartitionedに設定することによって構成されます。

      * PDTの利点および制限事項は、『Oracle WebLogic Server JMSリソースの管理』のパーティション化された分散トピックの構成に関する項を参照してください。

      * PDTの「パーティション化された」という単語は、WebLogic Server MTパーティションの「パーティション」という単語と同じ意味ではないことに注意してください。PDTとWebLogic Server MTのパーティションは、2つの独立した概念です。

• デフォルト・ストア

  • パーティションでのWebLogic Serverのデフォルト・ストアの使用は、許可されません。

  • リソース・グループまたはリソース・グループ・テンプレートのすべてのJMSサーバー、SAFエージェントおよびパス・サービスは、カスタム・ストアを参照する必要があります。

• 重み付けされた分散宛先(WDD)

  • WDDを含むリソース・グループまたはリソース・グループ・テンプレートへのJMSモジュールのデプロイメントは、例外で失敗します。

  • WDDは非推奨です。

• 接続コンシューマおよびサーバー・セッション・プール

  • パーティション・スコープの接続コンシューマまたはサーバー・セッション・プールを作成しようとすると、失敗します。

  • MDBは同様の目的を果たすため、ベスト・プラクティスとしてメッセージドリブンBean (MDB)を使用します。

• ロギング・ラスト・リソース・データ・ソース(LLR)

  • トランザクション・システムは、パーティション・スコープのLLR機能をサポートしていません。

  • 可能性のある回避策など、詳細は、「トランザクションの構成」を参照してください。

• SSLを使用する専用パーティション・チャネルを使用したクライアント相互運用性

  • 古いクライアントのみが、パーティションの専用チャネルを構成することによって、パーティションと相互運用できます。

  • この方法は、現在SSLをサポートしていません。