Oracle® Fusion Middleware Oracle WebLogic ServerメッセージドリブンBeanのプログラミング 11g リリース1(10.3.3) B61425-01 |
|
前 |
次 |
この節では、「MDBのプログラミングと構成:主な手順」の手順を補足します。
EJBのデプロイメント記述子に論理メッセージ宛先を宣言して、実際のメッセージ宛先(JMSキュー、JMSトピック、MDBなど)にマップできます。論理メッセージ宛先を宣言したら、その宛先にリンクするメッセージ宛先の参照を作成できます。EJBは、論理メッセージ宛先の名前を使用してJNDIルックアップを実行し、実際のメッセージ宛先にアクセスします。論理JMSメッセージ宛先は、個々のMDBまたはアプリケーション全体を対象として定義できます。
未解決および使用不可なメッセージ宛先の処理方法については、『Oracle Fusion Middleware Oracle WebLogic Server Enterprise JavaBeansのプログラミング』の「EJBとメッセージ宛先のリファレンス」を参照してください。
個々のMDBの論理JMSメッセージ宛先を構成できます。
MDBを構成して、実際のメッセージ宛先にリンクする論理メッセージ宛先を使用するには:
weblogic-ejb-jar.xml
のmessage-destination-descriptor
要素でメッセージ宛先を宣言します。
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
要素で定義する宛先と一致する必要があります。
このリリースの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を構成するには:
weblogic-ejb-jar.xml
のmessage-destination-descriptor
要素でメッセージ宛先を宣言します。
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
要素で構成します。
トピックを指定するには、destination-type
をjavax.jms.Topic
に設定します。宛先がトピックの場合は、subscription-durability
をDurable
またはNonDurable
のいずれかで指定します。
キューを指定するには、destination-type
をjavax.jms.Queue
に設定します。
詳細については、「恒久トピック・サブスクリプションの構成」を参照してください。
MDBは独自にトランザクションを管理するか、トランザクション管理をコンテナに委ねることができます。
コンテナ・レベルのトランザクション管理を構成するには:
ejb-jar.xml
ファイルのmessage-driven
要素のtransaction-type
要素をContainer
に設定します。
ejb-jar.xml
のcontainer-transaction
要素のtrans-attribute
要素をRequired
に設定します。
注意: transaction-type がContainer に設定されていて、trans-attribute が設定されていない場合は、デフォルトのtransaction-attribute 値が適用されます(EJB 3.0 MDBの場合はrequired 、EJB 3.0以前のMDBの場合はNotSupported )。WebLogic Serverでは、MDBをデプロイでき、準拠エラーをログに記録することもできます。ただし、この構成エラーを犯した場合、MDBはトランザクション的には実行されません。トランザクションの途中で障害が発生した場合、その障害の前に行われた更新はロールバックされません。 |
トランザクションのタイムアウト期間を変更するには、weblogic-ejb-jar.xml
のtransaction-descriptor
要素のtrans-timeout-seconds
を設定します。トランザクションがタイムアウトになると、そのトランザクションはロールバックされ、メッセージは再配信されます。デフォルトでは、トランザクションは30秒後にタイムアウトになります。トランザクションの時間が長いアプリケーションでは、タイムアウトの期間を長くする方がいいかもしれません。
Beanレベルのトランザクション管理を構成するには:
ejb-jar.xml
ファイルのmessage-driven
要素のtransaction-type
要素をBean
に設定します。
acknowledge-mode
要素で、目的のJMS確認応答セマンティクスを以下のいずれかに設定します。
AUTO_ACKNOWLEDGE
(デフォルト)。http://java.sun.com/products/jms/javadoc-102a/javax/jms/Session.html#AUTO_ACKNOWLEDGE
を参照してください。
DUPS_OK_ACKNOWLEDGE
。http://java.sun.com/products/jms/javadoc-102a/javax/jms/Session.html#DUPS_OK_ACKNOWLEDGE
を参照してください。
詳細は、『Oracle Fusion Middleware Oracle WebLogic Server JMSのプログラミング』の「Session」を参照してください。
このリリースのWebLogic Serverでは、EJBコンテナがJMSリソースの停止を検出したときのMDBの動作(同じ例外を10回連続でスローする)を構成できます。
次のように構成できます。
EJBコンテナがJMSリソースの停止を検出したときに、MDBはJMS接続を中断し、以後のメッセージの受信を停止します。この構成を選択した場合、以下を指定できます。
MDBがメッセージの受信を再開するまで待機する初期秒数
MDBがメッセージの受信を再開するまで待機する最大秒数
EJBコンテナがJMSリソースの停止を検出したときに、MDBはJMS接続を中断しません。
JMS接続が中断されると、その接続に関連付けられているすべてのJMSセッションでのメッセージ配信が中断されます。デフォルトによって、JMSリソースの停止を検出したEJBコンテナは、MDBのJMS接続をinit-suspend-seconds
秒中断します。
リソースが停止している間JMS接続を中断したい場合は、MDBから同じ例外が10回連続でスローされるように定義します。
MDBのJMS接続を中断するには、weblogic-ejb-jar.xm
ファイル内の以下の要素を構成します。
init-suspend-seconds
- EJBコンテナがJMSリソースの停止を検出した場合にMDBのJMS接続を中断する初期秒数です。デフォルト値は5
です。
max-suspend-seconds
- EJBコンテナがJMSリソースの停止を検出した場合にMDBのJMS接続を中断する最大秒数です。デフォルト値は60
です。
EJBコンテナでは、init-suspend-seconds
とmax-suspend-seconds
に基づき、次のアルゴリズムでJMS接続の中断時間を決定します。
まず、EJBコンテナがJMSリソースの停止を検出します。
MDBのJMS接続を、init-suspend-seconds
に指定された時間だけ中断します。
接続をチェックします。リソースが利用可能になっている場合はステップ12に進みます。
init-suspend-seconds
の値がmax-suspend-seconds
以上である場合はステップ9に進みます。
前回の中断時間に2を掛けて、次回の中断時間(Xseconds)を算出します。
MDBのJMS接続を、Xsecondsに指定された時間だけ中断します。
接続をチェックします。リソースが利用可能になっている場合はステップ12に進みます。
init-suspend-seconds
の値がmax-suspend-seconds
以上である場合はステップ9に進みます。
ステップ4に進みます。
MDBのJMS接続を、max-suspend-seconds
に指定された時間だけ中断します。
接続をチェックします。リソースが利用可能になっている場合はステップ12に進みます。
ステップ9に進みます。
処理を続行します。
管理コンソールを使用して、デプロイされているMDBへのメッセージ配信を手動で中断および再開できます。詳細は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのMDBのJMS接続の中断と再開に関する項を参照してください。
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
の以下の主な要素の構成方法はある程度決定します。
initial-context-factory
provider-url
destination-jndi-name
connection-factory-jndi-name
外部でリモートの宛先の場合、もっともシンプルな構成方式は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
は、MDBがリスニングする宛先のJMSプロバイダで使用されるJNDIサービスのURLを指定します。
JMSプロバイダがMDBにとってローカルである場合は(つまりWebLogic JMSであるということ)、provider-url
を指定しないでください。
JMSプロバイダがリモートであり(WebLogic JMSか外部プロバイダに関係なく)、
ラッパーを使用しない場合は、provider-url
を指定します。
ラッパーを使用する場合は、provider-url
は指定しないでください。URLはラッパーで暗黙的に暗号化されます。
initial-context-factory
は、JMSプロバイダで使用される初期コンテキスト・ファクトリを実装するクラスを指定します。
JMSプロバイダがWebLogic JMSの場合は、ローカルかリモートかに関係なく、initial-context-factory
は指定しないでください。
JMSプロバイダが外部の場合で、
ラッパーを使用しない場合は、JMSプロバイダで使用される初期コンテキスト・ファクトリを指定します。
ラッパーを使用する場合は、initial-context-factory
を指定しないでください。
destination-jndi-name
は、MDBがリスニングする宛先のJNDI名を指定します。
JMSプロバイダがローカルの場合は、宛先のローカルJNDIツリーでバインドされた名前を指定します。
JMSプロバイダが外部の場合で、
ラッパーを使用しない場合は、外部プロバイダのJNDIツリーでバインドされている宛先の名前を指定します。
ラッパーを使用する場合は、リモートまたは外部宛先に対応するローカルJNDIツリーで設定した外部宛先の名前を指定します。
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-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で恒久トピック・サブスクリプションを構成するには、次の手順に従います。
ejb-jar.xml
のdestination-type
をjavax.jms.Topic
に構成します。
ejb-jar.xml
のmessage-driven-destination
要素で、次のように設定します:
destination-type
をjavax.jms.Topic
に設定
subscription-durability
をDurable
に設定します。
必要に応じて、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は、以下のいずれかの方法で物理的な宛先をサブスクライブできます。
以下のトピックでは、メッセージの配信に関連する動作のガイドラインを示します。
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()の完了とコンテナによる配信の確認応答の間のサーバー・クラッシュ
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のプログラミング』の「ロールバック、リカバリ、再配信、または期限切れメッセージの管理」を参照してください。
WebLogic Serverは、setMessageDrivenContext()
を呼び出してMDBインスタンスとコンテナ・コンテキストを関連付けます。これはクライアント・コンテキストではありません。クライアント・コンテキストは、JMSメッセージと一緒には渡されません。
MDBインスタンス内からコンテナ・コンテキストのプロパティにアクセスするには、MessageDrivenContext
インタフェースの以下のメソッドを使用します。
getCallerPrincipal()
- EJBContext
インタフェースからの継承であり、MDBインスタンスから呼び出してはなりません。
isCallerInRole()
- EJBContext
インタフェースからの継承であり、MDBインスタンスから呼び出してはなりません。
setRollbackOnly()
- コンテナ管理によるトランザクションを使用するEJBでのみ使用できます。
getRollbackOnly()
- コンテナ管理によるトランザクションを使用するEJBでのみ使用できます。
getUserTransaction()
- Bean管理によるトランザクションの境界設定を使用するEJBでのみ使用できます。
注意: getEJBHome() もMessageDrivenContext インタフェースの一部として継承されますが、メッセージドリブンBeanにはホーム・インタフェースがありません。MDBのインスタンスからgetEJBHome() を呼び出すと、IllegalStateException がスローされます。 |
メッセージドリブンBean (MDB)がJMSキューまたはトピックからメッセージを受信すると、EJBコンテナは資格証明マッピング・プロバイダおよび資格証明マップを使用して、JMS接続の確立時に使用するセキュリティID (ユーザー名とパスワード)を取得し、onMessage()メソッドを実行します。この資格証明マッピングは、MDBの起動時に一度だけ行われます。
EJBコンテナが一度接続されると、JMSプロバイダは確立されたセキュリティIDを使用してすべてのメッセージを受信します。
MDBのセキュリティIDを構成するには:
MDBのWebLogicユーザーを作成します。Oracle Fusion Middleware Oracle WebLogic Serverロールおよびポリシーによるリソースの保護のユーザー、グループ、セキュリティ・ロールに関する項を参照してください。JMS接続を確立するためにOracle以外のJMSプロバイダが要求するユーザー名とパスワードをユーザーに割り当てます。
ejb-jar.xml
デプロイメント記述子で、次のようにMDBのrun-as
IDを定義します。
<security-identity> <run-as> <role-name>admin</role-name> </run-as> </security-identity>
security-identity
を作成するために、以下のようにejb-jar.xml
のassembly-descriptor
要素の中にsecurity-role
を定義する必要があります。
<assembly-descriptor> <security-role> <role-name>jmsrole</role-name> </security-role> .... </assembly-descriptor>
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で作成したユーザーのユーザー名です。
JMSプロバイダがWebLogic JMSではない場合は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのEJBコンポーネントの資格証明マッピングの作成に関する項の説明に従って資格証明マッパーを構成します。
注意: JMSプロバイダがWebLogic JMSの場合は、資格証明マッパーを構成する必要はありません。 |
MDBでは、クロス・ドメイン・セキュリティを構成する必要はありません。ただし、MDBを実装する場合には、以下のガイドラインを念頭に置いてください。
MDBでトランザクション・メッセージを処理する必要がある場合には、すべての参加ドメインについて、クロス・ドメイン・セキュリティまたはセキュリティの相互運用モードのいずれかを適切に構成する必要があります。
プロセスで使用されるすべてのドメインに関して、クロス・ドメイン・セキュリティおよびセキュリティの相互運用モードの構成を統一します。どちらの設定もドメイン・レベルで設定されるため、ドメインがクロス・ドメイン・セキュリティとセキュリティの相互運用モードの両方が設定された混在モードになる可能性があります。詳細は、『Oracle Fusion Middleware Oracle WebLogic Server JTAのプログラミング』の「ドメイン間トランザクションに対するドメインの構成」を参照してください。
非トランザクション・メッセージを処理するMDBでは、クロス・ドメイン・セキュリティを構成する必要はありません。ただし、1つのドメインにクロス・ドメイン・セキュリティが構成されていて、任意のドメインでMDBがリスニングする分散宛先のメンバーシップが変更される場合には、プロセスの通信対象となるすべてのドメインに対して、クロス・ドメイン・セキュリティを構成する必要があります。
ベスト・プラクティスは、プロセスで使用されるすべてのドメインに関してクロス・ドメイン・セキュリティの構成を統一することです。つまり、すべてのドメインがクロス・ドメイン・セキュリティを使用する(または、適切な例外リストに含まれる)か、どのドメインについてもクロス・ドメイン・セキュリティを有効にしないかのいずれかにします。『Oracle Fusion Middleware Oracle WebLogic Serverの保護』の「WebLogicドメインのセキュリティの構成」を参照してください。