注意:
この章では、EJB 3.0以前のデプロイメント記述子を使用して基本MDB構成を説明します。EJB 3.2アノテーションを使用する場合は、MDBのデプロイメント要素とアノテーションを参照してください。また、同等の設定に関しては、EJB 3.2準拠MDBの使用を参照してください。
この章には次の項が含まれます:
MDBがリスニングする宛先のタイプは、ejb-jar.xml
のmessage-driven-destination
要素のdestination-type
要素で、またはアノテーションを使用して、構成します。
トピックを指定するには、destination-type
をjavax.jms.Topic
に設定します。宛先がトピックの場合は、subscription-durability
をDurable
またはNonDurable
のいずれかで指定します。トピック関連の重要な追加設定は、JMSトピックを使用してMDBの構成とデプロイおよびMDBのデプロイメント要素とアノテーションを参照してください。
キューを指定するには、destination-type
をjavax.jms.Queue
に設定します。キュー関連設定の詳細は、MDBのデプロイメント要素とアノテーションを参照してください。
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.2 MDBの場合はrequired
、EJB 3.0より前のMDBの場合はNotSupported
です。Oracle WebLogic Serverでは、MDBをデプロイでき、準拠エラーをログに記録することもできます。ただし、この構成エラーを犯した場合、MDBはトランザクション的には実行されません。トランザクションの途中で障害が発生した場合、その障害の前に行われた更新はロールバックされません。
トランザクションのタイムアウト期間を変更するには、weblogic-ejb-jar.xml
のtransaction-descriptor
要素のtrans-timeout-seconds
を設定します。タイムアウトしたトランザクションはロールバックされ、メッセージが再配信されます。デフォルトでは、トランザクションは30秒後にタイムアウトになります。トランザクションの時間が長いアプリケーションでは、タイムアウトの期間を長くする方がいいかもしれません。
EJBアノテーションを使用してコンテナ・レベルのトランザクション管理を構成するには、次の手順を従います。
import javax.ejb.TransactionAttribute; import javax.ejb.TransactionAttributeType; ... @TransactionAttribute(value = TransactionAttributeType.REQUIRED) public void onMessage(Message msg) { ...
記述子の要素を使用してBeanレベルのトランザクション管理を構成するには、次の手順を従います。
ejb-jar.xml
ファイルのmessage-driven
要素のtransaction-type
要素をBean
に設定します。
acknowledge-mode
要素で、目的のJMS確認応答セマンティクスを以下のいずれかに設定します。
AUTO_ACKNOWLEDGE
(デフォルト)。http://www.oracle.com/technetwork/java/jms/index.html#AUTO_ACKNOWLEDGE
を参照してください。
DUPS_OK_ACKNOWLEDGE
。http://www.oracle.com/technetwork/java/jms/index.html#DUPS_OK_ACKNOWLEDGE
を参照してください。
詳細は、『Oracle WebLogic Server JMSアプリケーションの開発』のセッションに関する項を参照してください。
Oracle WebLogic Server MDBは、WebLogic JMS宛先と外部(非Oracle) JMSプロバイダの宛先をサポートしています。
ローカル宛先とは、MDBと同じマシンまたは同じクラスタで動作する宛先のことです。リモート宛先とは、別のマシンで動作しており、MDBと同じクラスタのメンバーではない宛先のことです。宛先がローカルであるかリモートであるかは、その宛先とMDBが同じJNDIコンテキストを共有しているかどうかに依存します。
お互いがお互いをローカルと見なすようにするには、MDBとその関連するJMS宛先が両方とも同じマシン上、または同じOracle WebLogic Serverクラスタ内で動作する必要があります。同じOracle WebLogic Serverクラスタ内のサーバー・インスタンス上のMDBとJMS宛先は、それらが別々のマシン上にあってもお互いにローカルな存在です。Oracle WebLogic Serverクラスタ内のサーバー・インスタンスはそれぞれ同じクラスタ全体のJNDIツリーのコピーを所有しているからです。
非OracleのJMSプロバイダで動作する宛先は、外部と表現されます。外部JMSプロバイダにはそれ専用のJNDIプロバイダがあり、外部JMSオブジェクトはOracle WebLogic Server MDBと同じコンテキストを共有しません(外部JMSオブジェクトがラッパーを使用してMDBのJNDIコンテキストに含まれるように構成されていないかぎり)。その手法については、「外部JMSサーバー・マッピングを使用するかどうか」を参照してください
宛先の性質(ローカルかリモートか、WebLogic JMSか非Oracleか)によって利用可能な構成オプションが決まり、weblogic-ejb-jar.xml
のMDBのmessage-destination-descriptor
の以下の主な要素の構成方法はある程度決定します。
initial-context-factory
provider-url
destination-jndi-name
connection-factory-jndi-name
外部でリモートの宛先の場合、もっともシンプルな構成戦略はOracle WebLogic Server JMS外部JMSサーバー・マッピングを使用することです。これらのマッピングを使用すると、サード・パーティJNDIプロバイダあるいは別のOracle WebLogic ServerクラスタまたはドメインのJMSオブジェクトとローカルWebLogic JNDIツリーのオブジェクトの間に「シンボリック・リンク」を作成できます。
外部JMSサーバー・マッピングをいつ使用するのか、およびweblogic-ejb-jar.xml
でmessage-driven-descriptor
を構成するルールの詳細は、次の項を参照してください。
特定のシナリオでmessage-driven-descriptor
の要素を構成するには、「一般的な宛先のシナリオ:イラストと主な要素の設定」を参照してください
マッピングを使用するということは、リモートJMSオブジェクト(非OracleまたはWebLogic JMS)に対応する外部接続ファクトリおよび外部宛先をローカルJNDIツリーのエントリとして構成するということです。
外部JMSプロバイダまたはリモートWebLogic JMSプロバイダを使用する場合には、マッピングの使用をお薦めします。JMSマッピング・クラスの詳細は、『Oracle WebLogic Server JMSアプリケーションの開発』の「WebLogic JMSをEJBやサーブレットと使用するための拡張サポート」のリモートまたは外部JMSプロバイダへの簡略化されたアクセスに関する項を参照してください。
接続ファクトリまたは宛先のいずれかでマッピングを使用する場合は、それらのオブジェクトの両方でマッピングを作成する必要があります。
マッピングを使用するかどうかで、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
を指定しないでください。
カスタム接続ファクトリは、デフォルトのOracle 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. リモートOracle 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がメッセージを受信するとは仮定しないでください。
WebLogic JMS宛先を使用するとき、厳密な順序付けが必要な場合は「順序単位」機能を使用することをお薦めします。この機能を使用すると、MDBを変更せずにあらゆる状況で順序付けを強制したり、同一宛先内に存在する下位順序の同時実行処理を可能にしたりします。なおこの機能は、構成を介して有効化するか、または必要に応じてプログラムを介して有効にできます。『Oracle WebLogic Server JMSアプリケーションの開発』のメッセージ順序単位の使用に関する項を参照してください。
受信順序がクライアントによるメッセージの送信順序に一致することを保証するために、順序単位を使用するWebLogic宛先を使用しない場合、次の操作を実行する必要があります。
MDBのmax-beans-in-free-pool
を1
に設定します。これでMDBがメッセージの唯一のコンシューマになります。
MDBをクラスタにデプロイする場合は、それらをクラスタの1つのノードにデプロイします。図6-5を参照してください。
トランザクションのロールバックおよびリカバリ時にメッセージの順序付けを保証するには、MessagesMaximum
を1に設定したカスタム接続ファクトリを構成し、再配信遅延が構成されていないことを確認します。外部ベンダーは、同等の設定に対して異なる名前を持ちます。この設定は、コンシューマが現在のメッセージ処理を完了する前に、ベンダーがコンシューマにプッシュできるメッセージ数を管理します。
詳細は、『Oracle WebLogic Server JMSアプリケーションの開発』の順序付けられたメッセージの再配信に関する項を参照してください。
MessageListener
インタフェース(javax.jms MessageListener.onMessage()
)に関するJavaのドキュメント(http://download.oracle.com/javaee/1.2.1/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は、そのシナリオを示しています。
MDBがメッセージを消費している最中に予期しないエラーが発生した場合、MDBはシステム例外をスローできます。その例外により、JMSの構成に応じてJMSは再送信、遅延後に再送信、または放棄を行います。
トランザクションMDBでメッセージの再配信を強制するには、Beanのコンテキストを使用して setRollbackOnly()
を使用します。
トランザクション対応かどうかに関係なく、MDBでメッセージの再配信を強制するには、MDBによってスローされるRuntimeException
またはError
から派生した例外をスローできます。このようにすると、MDBインスタンスは破棄および再作成され、パフォーマンスの低下につながります。実行例外をスローする一方で、破棄や再作成のオーバーヘッドを避ける場合は、WebLogic拡張機能を使用できます。たとえば、次のようにweblogic.ejb.NonDestructiveRuntimeException
のインスタンスをスローします。
throw new weblogic.ejb.NonDestructiveRuntimeException("force redelivery");
再配信遅延は、MDBのonMessage()
メソッドが実行するタスクの種類に基づいて構成できます。場合によっては、たとえばニュース・サービスに速報を流すアプリケーションなどで、再配信は即時に行うことが必要になります。その他の場合、たとえばデータベースのダウンが原因でMDBが例外をスローする場合、再配信はデータベースが復帰した後でないかぎりすぐでなくてもかまいません。
注意:
順序単位機能を使用しない、完全に順序付けられたMDBの場合、再配信遅延を設定しないでください。
再配信遅延と、MDBで使用できる他のJMS例外処理機能の構成手順については、『Oracle WebLogic Server JMSアプリケーションの開発』のロールバック、リカバリ、再配信、または期限切れメッセージの管理に関する項を参照してください。
Oracle WebLogic Serverは、setMessageDrivenContext()
を呼び出してMDBインスタンスとコンテナ・コンテキストを関連付けます。また、EJB 3.2 MDBアプリケーションはMDBコンテキストを注入するアノテーションを指定できます。これはクライアント・コンテキストではありません。クライアント・コンテキストは、JMSメッセージと一緒には渡されません。
MDBインスタンス内からコンテナ・コンテキストのプロパティにアクセスするには、MessageDrivenContext
インタフェースの以下のメソッドを使用します。
getCallerPrincipal()
- EJBContext
インタフェースからの継承であり、MDBインスタンスから呼び出してはなりません。
isCallerInRole()
- EJBContext
インタフェースからの継承であり、MDBインスタンスから呼び出してはなりません。
setRollbackOnly()
- コンテナ管理によるトランザクションを使用するEJBでのみ使用できます。
getRollbackOnly()
- コンテナ管理によるトランザクションを使用するEJBでのみ使用できます。
getUserTransaction()
- Bean管理によるトランザクションの境界設定を使用するEJBでのみ使用できます。
注意:
getEJBHome()
もMessageDrivenContext
インタフェースの一部として継承されますが、メッセージドリブンBeanにはホーム・インタフェースがありません。MDBのインスタンスからgetEJBHome()
を呼び出すと、IllegalStateException
がスローされます。
このリリースのOracle 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
秒中断します。
WebLogic Server管理コンソールを使用して、デプロイされているMDBへのメッセージ配信を手動で中断および再開できます。詳細は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのMDBのJMS接続の中断と再開に関する項を参照してください。
リソースが停止している間JMS接続を中断したい場合は、MDBから同じ例外が10回連続でスローされるように定義します。
MDBのJMS接続を中断するには、weblogic-ejb-jar.xm
ファイル内の以下の要素を構成します。
init-suspend-seconds
- EJBコンテナがJMSリソースの停止を検出したときにJMS接続を中断する時間(秒数)の初期値です。デフォルト値は5
です。
max-suspend-seconds
- EJBコンテナがJMSリソースの停止を検出したときにJMS接続を中断する時間(秒数)の最大値です。デフォルト値は60
です。
EJBコンテナでは、init-suspend-seconds
とmax-suspend-seconds
に基づき、次のアルゴリズムでJMS接続の中断時間を決定します。
まず、EJBコンテナがJMSリソースの停止を検出します。
init-suspend-seconds
に指定された時間だけ中断します。init-suspend-seconds
の値がmax-suspend-seconds
以上である場合はステップ9に進みます。init-suspend-seconds
の値がmax-suspend-seconds
以上である場合はステップ9に進みます。max-suspend-seconds
に指定された時間だけ中断します。メッセージドリブンBean (MDB)がJMSキューまたはトピックからメッセージを受信すると、EJBコンテナは資格証明マッピング・プロバイダおよび資格証明マップを使用して、JMS接続の確立時に使用するセキュリティID (ユーザー名とパスワード)を取得し、onMessage()メソッドを実行します。この資格証明マッピングは、MDBの起動時に一度だけ行われます。
EJBコンテナが一度接続されると、JMSプロバイダは確立されたセキュリティIDを使用してすべてのメッセージを受信します。
MDBのセキュリティIDを構成するには:
MDBでは、クロス・ドメイン・セキュリティを構成する必要があります。ただし、MDBを実装する場合には、次のガイドラインを念頭に置いてください。
MDBでトランザクション・メッセージを処理する必要がある場合には、すべての参加ドメインについて、クロス・ドメイン・セキュリティまたはセキュリティの相互運用モードのいずれかを適切に構成する必要があります。
クロス・ドメイン・セキュリティ構成およびセキュリティの相互運用モードに関して、プロセスで使用されるすべてのドメインの対称性を維持します。どちらの設定もドメイン・レベルで設定されるため、ドメインが混在モードになる(つまり、ドメインがクロス・ドメイン・セキュリティとセキュリティの相互運用モードの組合せを持つ)可能性があります。詳細は、『Oracle WebLogic Server JTAアプリケーションの開発』のセキュアなドメイン間およびドメイン内トランザクション通信の構成に関する項を参照してください。
MDBが異なるドメインの分散宛先をリスニングする場合には、クロス・ドメイン・セキュリティを構成する必要があります。
非トランザクション・メッセージを処理するMDBでは、クロス・ドメイン・セキュリティを構成する必要はありません。ただし、1つのドメインにクロス・ドメイン・セキュリティが構成されていて、任意のドメインでMDBがリスニングする分散宛先のメンバーシップが変更される場合は、プロセスの通信対象となるすべてのドメインに対して、クロス・ドメイン・セキュリティを構成する必要があります。別のドメインにある分散宛先がリスニングするMDBの場合、クロス・ドメイン・セキュリティを構成する必要があります。
ベスト・プラクティスは、クロス・ドメイン・セキュリティ構成およびセキュリティの相互運用モードに関して、プロセスで使用されるすべてのドメインの対称性を維持することです - つまり、すべてのドメインがクロス・ドメイン・セキュリティを使用する(適切な例外リストに含まれる)か、または、どのドメインについてもクロス・ドメイン・セキュリティを構成しないかです。『Oracle WebLogic Serverセキュリティの管理12c (12.2.1)』のクロス・ドメイン・セキュリティの構成に関する項を参照してください。
注意:
論理宛先およびアプリケーション・スコープの宛先は、通常は使用されず、上級ユーザー向けのみとなります。大半のユーザーの場合、「宛先用のMDBの構成」で説明したメソッドの使用をお薦めします
EJBのデプロイメント記述子に論理メッセージ宛先を宣言して、実際のメッセージ宛先(JMSキュー、JMSトピック、MDBなど)にマップできます。論理メッセージ宛先を宣言したら、その宛先にリンクするメッセージ宛先の参照を作成できます。EJBは、論理メッセージ宛先の名前を使用してJNDIルックアップを実行し、実際のメッセージ宛先にアクセスします。論理JMSメッセージ宛先は、個々のMDBまたはアプリケーション全体を対象として定義できます。
未解決および使用不可なメッセージ宛先の処理方法については、『Oracle WebLogic Server Enterprise JavaBeansバージョン2.1の開発』のEJBとメッセージ宛先のリファレンスに関する項を参照してください
このリリースのOracle WebLogic Serverでは、アプリケーションのリソースを構成できます。構成するアプリケーション全体のリソースを、アプリケーション・スコープ・リソースと呼びます。この項では、EJBアプリケーションのアプリケーション・スコープ論理JMS宛先について説明します。JMSやJDBCなどのアプリケーション・スコープ・リソースの詳細は、『Oracle WebLogic Server JMSアプリケーションの開発』および『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
要素で定義する宛先と一致する必要があります。