ヘッダーをスキップ
Oracle® Fusion Middleware Oracle WebLogic ServerメッセージドリブンBeanのプログラミング
11g リリース1(10.3.3)
B61425-01
  ドキュメント・ライブラリへ移動
ライブラリ		 製品リストへ移動
製品		 目次へ移動
目次
前
前 		 次
次		  

6 MDBのプログラミングと構成: 詳細

この節では、「MDBのプログラミングと構成:主な手順」の手順を補足します。

EJBの構成による論理メッセージ宛先の使用

EJBのデプロイメント記述子に論理メッセージ宛先を宣言して、実際のメッセージ宛先(JMSキュー、JMSトピック、MDBなど)にマップできます。論理メッセージ宛先を宣言したら、その宛先にリンクするメッセージ宛先の参照を作成できます。EJBは、論理メッセージ宛先の名前を使用してJNDIルックアップを実行し、実際のメッセージ宛先にアクセスします。論理JMSメッセージ宛先は、個々のMDBまたはアプリケーション全体を対象として定義できます。

未解決および使用不可なメッセージ宛先の処理方法については、『Oracle Fusion Middleware Oracle WebLogic Server Enterprise JavaBeansのプログラミング』の「EJBとメッセージ宛先のリファレンス」を参照してください。

個々のMDBの論理JMSメッセージ宛先を構成する

個々のMDBの論理JMSメッセージ宛先を構成できます。

MDBを構成して、実際のメッセージ宛先にリンクする論理メッセージ宛先を使用するには:

  1. weblogic-ejb-jar.xmlのmessage-destination-descriptor要素でメッセージ宛先を宣言します。

  2. ejb-jar.xmlの以下の要素で、メッセージ宛先の参照を宣言します。

    • message-destination-ref

    • message-destination-ref-name - メッセージ宛先のエンタープライズBeanコードで使用される環境名。 java:comp/envを基準とします(例: <message-destination-ref>jms/StockQueue</message-destination-ref>)。

    • message-destination-type - 参照される宛先の期待されるタイプ(例: <message-destination-type>javax.jms.Queue</message-destination-type>)。

    • message-destination-usage - メッセージが宛先から消費されるか、宛先用に生成されるか、またはその両方かを指定します(例: <message-destination-usage>Produces<message-destination-usage>)。

    • message-destination-link - メッセージ宛先の参照を実際のメッセージ宛先にリンクします。この値は、weblogic-ejb-jar.xmlファイルのmessage-destination-name要素で定義する宛先と一致する必要があります。

アプリケーション・スコープの論理JMSメッセージ宛先を構成する

このリリースのWebLogic Serverでは、アプリケーションのリソースを構成できます。構成するアプリケーション全体のリソースを、アプリケーション・スコープ・リソースと呼びます。この項では、EJBアプリケーションのアプリケーション・スコープ論理JMS宛先について説明します。アプリケーション・スコープ・リソース(JMS、JDBCなど)の詳細は、『Oracle Fusion Middleware Oracle WebLogic Server JMSのプログラミング』および『Oracle Fusion Middleware Oracle WebLogic Server JDBCのプログラミング』を参照してください。

EJBのアプリケーション・スコープ・リソース(論理JMSメッセージ宛先など)は、アプリケーションのすべてのMDBに適用されます。個々のMDBのアプリケーション・スコープJMSをオーバーライドするには、MDBを構成して、実際のメッセージ宛先にリンクする論理メッセージ宛先を使用します(「個々のMDBの論理JMSメッセージ宛先を構成する」を参照)。

EJBのアプリケーション・スコープJMSを構成するには:

  1. weblogic-ejb-jar.xmlのmessage-destination-descriptor要素でメッセージ宛先を宣言します。

  2. ejb-jar.xmlの以下の要素で、メッセージ宛先の参照を宣言します。

  • message-driven

    • message-destination-type - 参照される宛先の期待されるタイプ(例: <message-destination-type>javax.jms.Queue</message-destination-type>)。

    • message-destination-usage - メッセージが宛先から消費されるか、宛先用に生成されるか、またはその両方かを指定します(例: <message-destination-usage>Produces<message-destination-usage>)。

    • message-destination-link - メッセージ宛先の参照を実際のメッセージ宛先にリンクします(例: <message-destination-link>ExpenseProcessingQueue<message-destination-link>)。この値は、weblogic-ejb-jar.xmlファイルのmessage-destination-name要素で定義する宛先と一致する必要があります。

  • message-destination

    • message-destination-name - メッセージ宛先の名前(例: <message-destination-name>ExpenseProcessingQueue<message-destination-name>)。この値は、weblogic-ejb-jar.xmlのmessage-destination-name要素で定義する宛先と一致する必要があります。

宛先タイプの構成

MDBがリスニングする宛先のタイプは、ejb-jar.xmlのmessage-driven-destination要素のdestination-type要素で構成します。

詳細については、「恒久トピック・サブスクリプションの構成」を参照してください。

MDBのトランザクション管理方式の構成

MDBは独自にトランザクションを管理するか、トランザクション管理をコンテナに委ねることができます。

コンテナ・レベルのトランザクション管理を構成するには:

Beanレベルのトランザクション管理を構成するには:

詳細は、『Oracle Fusion Middleware Oracle WebLogic Server JMSのプログラミング』の「Session」を参照してください。

JMSリソース停止中のメッセージ配信の中断の構成

このリリースのWebLogic Serverでは、EJBコンテナがJMSリソースの停止を検出したときのMDBの動作(同じ例外を10回連続でスローする)を構成できます。

次のように構成できます。

JMS接続が中断されると、その接続に関連付けられているすべてのJMSセッションでのメッセージ配信が中断されます。デフォルトによって、JMSリソースの停止を検出したEJBコンテナは、MDBのJMS接続をinit-suspend-seconds秒中断します。

JMS接続を中断する秒数の構成

リソースが停止している間JMS接続を中断したい場合は、MDBから同じ例外が10回連続でスローされるように定義します。

MDBのJMS接続を中断するには、weblogic-ejb-jar.xmファイル内の以下の要素を構成します。

EJBコンテナによってJMS接続の中断時間が決定される仕組み

EJBコンテナでは、init-suspend-secondsとmax-suspend-secondsに基づき、次のアルゴリズムでJMS接続の中断時間を決定します。

まず、EJBコンテナがJMSリソースの停止を検出します。

  1. MDBのJMS接続を、init-suspend-secondsに指定された時間だけ中断します。

  2. 接続をチェックします。リソースが利用可能になっている場合はステップ12に進みます。

  3. init-suspend-secondsの値がmax-suspend-seconds以上である場合はステップ9に進みます。

  4. 前回の中断時間に2を掛けて、次回の中断時間(Xseconds)を算出します。

  5. MDBのJMS接続を、Xsecondsに指定された時間だけ中断します。

  6. 接続をチェックします。リソースが利用可能になっている場合はステップ12に進みます。

  7. init-suspend-secondsの値がmax-suspend-seconds以上である場合はステップ9に進みます。

  8. ステップ4に進みます。

  9. MDBのJMS接続を、max-suspend-secondsに指定された時間だけ中断します。

  10. 接続をチェックします。リソースが利用可能になっている場合はステップ12に進みます。

  11. ステップ9に進みます。

  12. 処理を続行します。

JMS接続の中断を無効化する

EJBコンテナがリソースの停止を検出したときにMDBのJMS接続が中断しないようにするには、max-suspend-secondsの値を0に設定します。max-suspend-secondsの値が0の場合、init-suspend-secondsの値は無視されます。

メッセージ配信の手動による中断と再開

管理コンソールを使用して、デプロイされているMDBへのメッセージ配信を手動で中断および再開できます。詳細は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのMDBのJMS接続の中断と再開に関する項を参照してください。

宛先を考慮したMDBの構成

WebLogic Server MDBは、Weblogic JMS宛先と外部(非Oracle) JMSプロバイダの宛先をサポートしています。

ローカル宛先とは、MDBと同じマシンまたは同じクラスタで動作する宛先のことです。リモート宛先とは、別のマシンで動作しており、MDBと同じクラスタのメンバーではない宛先のことです。宛先がローカルであるかリモートであるかは、その宛先とMDBが同じJNDIコンテキストを共有しているかどうかに依存します。

お互いがお互いをローカルと見なすようにするには、MDBとその関連するJMS宛先が両方とも同じマシン上、または同じWebLogic Serverクラスタ内で動作する必要があります。同じWebLogic Serverクラスタ内のサーバー・インスタンス上のMDBとJMS宛先は、それらが別々のマシン上にあってもお互いにローカルな存在です。WebLogic Serverクラスタ内のサーバー・インスタンスはそれぞれ同じクラスタ全体のJNDIツリーのコピーを所有しているからです。

非OracleのJMSプロバイダで動作する宛先は、「外部」と表現されます。外部JMSプロバイダにはそれ専用のJNDIプロバイダがあり、外部JMSオブジェクトはWebLogic Server MDBと同じコンテキストを共有しません(外部JMSオブジェクトがラッパーを使用してMDBのJNDIコンテキストに含まれるように構成されていない限り)。その手法については、「ラッパーを使用するかどうか」を参照してください。

宛先の性質(ローカルかリモートか、WebLogic JMSか非Oracleか)によって利用可能な構成オプションが決まり、weblogic-ejb-jar.xmlのMDBのmessage-destination-descriptorの以下の主な要素の構成方法はある程度決定します。

外部でリモートの宛先の場合、もっともシンプルな構成方式はWebLogic Server JMSラッパーを使用することです。ラッパーを使用すると、サード・パーティJNDIプロバイダあるいは別のWebLogic ServerクラスタまたはドメインのJMSオブジェクトとローカルWebLogic JNDIツリーのオブジェクトの間に「シンボリック・リンク」を作成できます。

ラッパーをいつ使うのか、およびweblogic-ejb-jar.xmlでmessage-driven-descriptorを構成するルールの詳細は、以下の節を参照してください。

特定のシナリオでmessage-driven-descriptorの要素を構成するには、「一般的な宛先のシナリオ:イラストと主な要素の設定」を参照してください。

ラッパーを使用するかどうか

ラッパーを使用するということは、リモートJMSオブジェクト(非OracleまたはWebLogic JMS)に対応する外部接続ファクトリおよび外部宛先をローカルJNDIツリーのエントリとして構成するということです。

  • 外部JMSプロバイダまたはリモートWebLogic JMSプロバイダを使用する場合には、ラッパーの使用をお薦めします。JMSラッパー・クラスの詳細は、『Oracle Fusion Middleware Oracle WebLogic Server JMSのプログラミング』の「WebLogic JMSをEJBやサーブレットと組み合せて使用するために拡張されたサポート」を参照してください。

  • 接続ファクトリまたは宛先のいずれかでラッパーを使用する場合は、それらのオブジェクトの両方でラッパーを使用する必要があります。

ラッパー・クラスを使用するかどうかで、以下に説明するようにinitial-context-factoryとdestination-jndi-nameの構成方法が決まります。

provider-urlの設定方法

provider-urlは、MDBがリスニングする宛先のJMSプロバイダで使用されるJNDIサービスのURLを指定します。

  • JMSプロバイダがMDBにとってローカルである場合は(つまりWebLogic JMSであるということ)、provider-urlを指定しないでください。

  • JMSプロバイダがリモートであり(WebLogic JMSか外部プロバイダに関係なく)、

    • ラッパーを使用しない場合は、provider-urlを指定します。

    • ラッパーを使用する場合は、provider-urlは指定しないでください。URLはラッパーで暗黙的に暗号化されます。

initial-context-factoryの設定方法

initial-context-factoryは、JMSプロバイダで使用される初期コンテキスト・ファクトリを実装するクラスを指定します。

  • JMSプロバイダがWebLogic JMSの場合は、ローカルかリモートかに関係なく、initial-context-factoryは指定しないでください。

  • JMSプロバイダが外部の場合で、

    • ラッパーを使用しない場合は、JMSプロバイダで使用される初期コンテキスト・ファクトリを指定します。

    • ラッパーを使用する場合は、initial-context-factoryを指定しないでください。

destination-jndi-nameの設定方法

destination-jndi-nameは、MDBがリスニングする宛先のJNDI名を指定します。

  • JMSプロバイダがローカルの場合は、宛先のローカルJNDIツリーでバインドされた名前を指定します。

  • JMSプロバイダが外部の場合で、

    • ラッパーを使用しない場合は、外部プロバイダのJNDIツリーでバインドされている宛先の名前を指定します。

    • ラッパーを使用する場合は、リモートまたは外部宛先に対応するローカルJNDIツリーで設定した外部宛先の名前を指定します。

connection-factory-jndi-nameの設定方法

connection-factory-jndi-nameは、JMSプロバイダで使用される接続ファクトリのJNDI名を指定します。

  • JMSプロバイダがローカルの場合は、MDBが使用するカスタム接続ファクトリを構成していない限りconnection-factory-jndi-nameを指定しないでください。

    カスタム接続ファクトリは、デフォルトのWebLogic Server接続ファクトリではアプリケーションの要件を満たせない場合に使用します。たとえば、MessagesMaximum属性で特定の必要な値を指定するためにカスタム接続ファクトリを構成する場合もあります。接続ファクトリの構成手順については、Oracle WebLogic Server管理コンソール・オンライン・ヘルプの接続ファクトリの構成に関する項を参照してください。


    注意:

    MDBのカスタムJMS接続ファクトリを構成する場合は、必ず確認応答ポリシー属性をPreviousに設定し、UserTransactionsEnabled属性が有効であるようにしてください。

  • JMSプロバイダがリモートまたは外部の場合で、

    • ラッパーを使用しない場合は、リモートJNDIツリーでバインドされている、JMSプロバイダで使用される接続ファクトリの名前を指定します。

    • ラッパーを使用する場合は、リモートまたは外部のJMSプロバイダの接続ファクトリに対応するローカルJNDIツリーで設定した外部接続ファクトリを指定します。

一般的な宛先のシナリオ:イラストと主な要素の設定

この節の図は、一般的な宛先の構成を示しています。リモートおよび外部の宛先については、ラッパー「あり」と「なし」のシナリオが用意されています。

表6-1は、各シナリオのweblogic-ejb-jar.xmlのmessage-driven-descriptor要素に含まれる要素の構成方法を示しています。

図6-1 A.ローカルWebLogic JMSサーバーの宛先

図6-1の説明が続きます
「図6-1 A.ローカルWebLogic JMSサーバーの宛先」の説明

図6-2 B.リモートWebLogic JMSサーバーの宛先(ラッパーなし)

図6-2の説明が続きます
「図6-2 B.リモートWebLogic JMSサーバーの宛先(ラッパーなし)」の説明

図6-3 C.外部JMSサーバーの宛先(ラッパーなし)

図6-3の説明が続きます
「図6-3 C.外部JMSサーバーの宛先(ラッパーなし)」の説明

図6-4 D.リモートWebLogic Serverまたは外部JMSサーバーの宛先(ラッパーあり)

図6-4の説明が続きます
「図6-4 D.リモートWebLogic Serverまたは外部JMSサーバーの宛先(ラッパーあり)」の説明

表6-1 一般的な構成シナリオ

シナリオ 宛先が次に存在する場合... ラッパーは構成されるか destination-jndi-name initial-context-factory provider-url connection-factory-jndi-name

A

ローカルWebLogic JMSサーバー

ローカルWebLogic JMSサーバーには適用なし

ローカルのJNDIツリーでバインドされている、ローカル宛先の名前

指定しません

指定しません

カスタム接続ファクトリを使用する場合のみ指定します

B

リモートWebLogic JMSサーバー

ラッパーは構成されません

リモートのJNDIツリーでバインドされている、リモート宛先の名前

指定しません

リモートWebLogic JMSサーバーのURLまたはクラスタ・アドレス

リモート・プロバイダでカスタム接続ファクトリを使用する場合のみ指定します

C

外部JMSプロバイダ

ラッパーは構成されません

リモートのJNDIツリーでバインドされている、リモート宛先の名前

リモートのJNDIツリーでバインドされている、リモート初期コンテキスト・ファクトリの名前

外部JMSプロバイダにアクセスするためのURL

外部接続ファクトリのJNDI名

D

リモートWeblogic JMSサーバー

または

外部JMSサーバー

ラッパーは構成されます

リモートまたは外部宛先に対応する、ローカルJNDIツリーでバインドされている外部宛先の名前

指定しません

指定しません

リモートまたは外部接続ファクトリに対応する、ローカルJNDIツリーでバインドされている外部接続ファクトリの名前

恒久トピック・サブスクリプションの構成

恒久サブスクリプションを使用すると、MDBはそのMDBが接続されていないときにトピックに配信されたメッセージを受信できます。

クラスタリングされていないサーバーで恒久トピック・サブスクリプションを構成する

クラスタリングされていないサーバー・インスタンスにデプロイされたMDBで恒久トピック・サブスクリプションを構成するには、次の手順に従います。

  1. ejb-jar.xmlのdestination-typeをjavax.jms.Topicに構成します。

  2. ejb-jar.xmlのmessage-driven-destination要素で、次のように設定します:

    • destination-typeをjavax.jms.Topicに設定

    • subscription-durabilityをDurableに設定します。

  3. 必要に応じて、MDBのClientIdを構成します。

    Oracle WebLogic Server管理コンソール・オンライン・ヘルプにある接続ファクトリの構成に関する項の説明に従って、アプリケーションの特定の要件に合せて独自の接続ファクトリを構成する場合は、接続ファクトリを構成するときにMDBのClientIDを定義できます。

    接続ファクトリを設定しても、それにClientIDを割り当てないか、デフォルトの接続ファクトリを使用する場合、MDBはweblogic-ejb-jar.xmlのjms-client-idの値をクライアントIDとして使用します。jms-client-idが指定されていない場合、デフォルト値はMDBのejb-nameです。

クラスタで恒久トピック・サブスクリプションを構成する

クラスタでは、JMS恒久サブスクリプションはMDBの以下のIDの組合せで一意に識別されます。

  • 接続ID - 接続ファクトリのClientIdであり、クラスタ内で一意です。

  • サブスクリプションID - MDBのjms-client-idです。サブスクリプションIDはそのトピックで一意でなければならないので、恒久トピック・サブスクリプションのあるMDBはクラスタ内の複数のサーバー・インスタンスで実行できません。MDBの最初のインスタンスがクラスタ内のサーバー・インスタンスで起動した後、MDBの追加インスタンスを別のクラスタリングされたサーバーに正常にデプロイできますが、MDBが起動すると競合が検出され、MDBのそのインスタンスはJMSに完全には接続できません。

恒久サブスクライバMDBをクラスタ内の複数のサーバー・インスタンスで実行できるようにするには(各MDBインスタンスが各トピック・メッセージのコピーを受信する)、各MDBインスタンスを一意のjms-client-IDでデプロイする必要があります(jms-client-IDが指定されていない場合はejb-name)。

ローカル・クラスタでは、恒久サブスクライバが分散宛先トピックを直接サブスクライブします。MDBは、サーバーに分散宛先が存在する場合にのみデプロイされます。

リモート・クラスタで恒久サブスクライバが分散宛先トピックを直接サブスクライブする場合は、MDBがすべての分散宛先メンバーに一度ずつデプロイされます。

MDBは、以下のいずれかの方法で物理的な宛先をサブスクライブできます。

  • 分散宛先トピックの各物理的宛先を一意のJNDI名で構成し、対応するdestination-jndi-nameで各恒久サブスクライバMDBプールを構成します。

  • 各物理的宛先を同じJNDI名で構成し、

    • 各物理的宛先でLocalJNDIName属性を設定します。詳細は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのJMSトピック: 構成: 全般に関する項を参照してください。

    • サーバー・インスタンスごとに物理的宛先が1つだけになるようにします。

恒久トピック・サブスクリプションの自動削除を構成する

MDBを構成することで、MDBがサーバーからアンデプロイまたは削除されるときに恒久トピック・サブスクリプションが自動的に削除されるようにできます。恒久トピック・サブスクリプションを自動的に削除するようにMDBを構成するには、durable-subscription-deletionをTrueに設定します。

デフォルトでは、durable-subscription-deletionはFalseに設定されています。

メッセージ処理動作の構成

以下のトピックでは、メッセージの配信に関連する動作のガイドラインを示します。

メッセージ受信順序の保証

MDBのビジネス・ロジックが非同期のメッセージ処理に対応できるようにしておきます。MDBは必ずしも、クライアントが発行した順序でメッセージを受信するわけではありません。受信順序がクライアントのメッセージ送信順序と一致するようにするには、次を行う必要があります:

  • MDBのmax-beans-in-free-poolを1に設定します。これでMDBがメッセージの唯一のコンシューマになります。

  • MDBをクラスタにデプロイする場合は、それらをクラスタの1つのノードにデプロイします。図6-5を参照してください。

トランザクションのロールバックとリカバリのときにメッセージの順序付けを守るには、カスタム接続ファクトリを値1のMessagesMaximumで構成し、再配信遅延が構成されないようにします。詳細は、『Oracle Fusion Middleware Oracle WebLogic Server JMSのプログラミング』の「メッセージの再配信の順序付け」を参照してください。

MessageListenerインタフェース(javax.jms MessageListener.onMessage())に関するSunのドキュメント(http://java.sun.com/j2ee/sdk_1.2.1/techdocs/api/javax/jms/MessageListener.html)を参照してください。

重複メッセージの防止と処理

JMSプロデューサは、MDBが受信メッセージの確認応答をするのを待ち受けます。MDBがメッセージを受信したが、確認応答の送信に失敗した場合、JMSプロデューサは同じメッセージを再送信します。

MDBの設計は、重複メッセージの可能性を考慮に入れているはずです。重複メッセージは、特定の状況では有害になります。たとえば、MDBのonMessage() メソッドに銀行口座の借方に記入するコードが含まれている場合、そのメッセージを2回受信して処理すると借方への記入が2回行われることになります。また、メッセージが再送信されると、処理リソースがより多く消費されることになります。

重複メッセージの配信を防止する最適な方法は、コンテナ管理によるトランザクションを使用することです。コンテナ管理によるトランザクションでは、トランザクションの中でメッセージの受信と確認応答が行われます(つまり両方行われるか、両方とも行われません)。ただし、これはBean管理のトランザクションを使用するよりも信頼性が高くなりますが、パフォーマンスは犠牲になります。コンテナ管理によるトランザクションでは、より多くのCPUリソースとディスク・リソースが使用されるからです。

MDBがそれ自身のトランザクションを管理する場合は、受信と確認応答がトランザクションの外で行われるので、onMessage()のコードで重複メッセージを処理する必要があります。一部のアプリケーションは、重複メッセージの受信と処理に対応しています。上の銀行口座のシナリオのような他のケースでは、トランザクションがBean管理の場合は、Beanのコードで重複メッセージの処理を防止する必要があります。たとえば、MDBではデータベースですでに消費されているメッセージを追跡できます。

MDBのonMessage()メソッドが正常に完了する場合でも、onMessage()の完了とコンテナによるメッセージ配信の確認応答の間にサーバーがクラッシュすると、MDBは重複メッセージを受信することになります。図6-5は、そのシナリオを示しています。

図6-5 onMessage()の完了とコンテナによる配信の確認応答の間のサーバー・クラッシュ

図6-5の説明が続きます
「図6-5 onMessage()の完了とコンテナによる配信の確認応答の間のサーバー・クラッシュ」の説明

再配信と例外処理

MDBがメッセージを消費している最中に予期しないエラーが発生した場合、MDBはシステム例外をスローできます。その例外により、JMSの構成に応じてJMSは再送信、遅延後に再送信、または放棄を行います。

トランザクションMDBでメッセージの再配信を強制するには、Beanのコンテキストを使用して setRollbackOnly()を使用します。

トランザクション対応かどうかに関係なく、MDBでメッセージの再配信を強制するには、MDBによってスローされるRuntimeExceptionまたはErrorから派生した例外をスローできます。このようにすると、MDBインスタンスは破棄および再作成され、パフォーマンスの低下につながります。

再配信遅延は、MDBのonMessage()メソッドが実行するタスクの種類に基づいて構成します。場合によっては、たとえばニュース・サービスに速報を流すアプリケーションなどで、再配信は即時に行うことが必要になります。その他の場合、たとえばデータベースのダウンが原因でMDBが例外をスローする場合、再配信はデータベースが復帰した後でない限りすぐでなくてもかまいません。


注意:

正確に順序付けされているMDBの場合は、再配信遅延を設定しないでください。

再配信遅延と、MDBで使用できる他のJMS例外処理機能の構成手順については、『Oracle Fusion Middleware Oracle WebLogic Server JMSのプログラミング』の「ロールバック、リカバリ、再配信、または期限切れメッセージの管理」を参照してください。

メッセージドリブンBeanコンテキストの使用

WebLogic Serverは、setMessageDrivenContext()を呼び出してMDBインスタンスとコンテナ・コンテキストを関連付けます。これはクライアント・コンテキストではありません。クライアント・コンテキストは、JMSメッセージと一緒には渡されません。

MDBインスタンス内からコンテナ・コンテキストのプロパティにアクセスするには、MessageDrivenContextインタフェースの以下のメソッドを使用します。

メッセージドリブンBeanのセキュリティIDの構成

メッセージドリブンBean (MDB)がJMSキューまたはトピックからメッセージを受信すると、EJBコンテナは資格証明マッピング・プロバイダおよび資格証明マップを使用して、JMS接続の確立時に使用するセキュリティID (ユーザー名とパスワード)を取得し、onMessage()メソッドを実行します。この資格証明マッピングは、MDBの起動時に一度だけ行われます。

EJBコンテナが一度接続されると、JMSプロバイダは確立されたセキュリティIDを使用してすべてのメッセージを受信します。

MDBのセキュリティIDを構成するには:

  1. MDBのWebLogicユーザーを作成します。Oracle Fusion Middleware Oracle WebLogic Serverロールおよびポリシーによるリソースの保護のユーザー、グループ、セキュリティ・ロールに関する項を参照してください。JMS接続を確立するためにOracle以外のJMSプロバイダが要求するユーザー名とパスワードをユーザーに割り当てます。

  2. ejb-jar.xmlデプロイメント記述子で、次のようにMDBのrun-as IDを定義します。

    <security-identity> 
    <run-as> 
        <role-name>admin</role-name> 
    </run-as>
</security-identity>

  3. security-identityを作成するために、以下のようにejb-jar.xmlのassembly-descriptor要素の中にsecurity-roleを定義する必要があります。

    <assembly-descriptor>
    <security-role>
        <role-name>jmsrole</role-name>
    </security-role>
    ....
</assembly-descriptor>

  4. weblogic-ejb-jar.xmlデプロイメント記述子で、次のように、ステップ2で定義されたユーザーにrun-as IDをマップします。

    <security-role-assignment>
    <role-name>admin</role-name> 
    <principal-name>username</principal-name> 
</security-role-assignment>

    usernameは、ステップ1で作成したユーザーのユーザー名です。

  5. JMSプロバイダがWebLogic JMSではない場合は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのEJBコンポーネントの資格証明マッピングの作成に関する項の説明に従って資格証明マッパーを構成します。


    注意:

    JMSプロバイダがWebLogic JMSの場合は、資格証明マッパーを構成する必要はありません。

クロス・ドメイン・セキュリティとMDBの使い方

MDBでは、クロス・ドメイン・セキュリティを構成する必要はありません。ただし、MDBを実装する場合には、以下のガイドラインを念頭に置いてください。

  前
前 		 次
次
  ドキュメント・ライブラリへ移動
ライブラリ		 製品リストへ移動
製品		 目次へ移動
目次