ヘッダーをスキップ
Oracle® Fusion Middleware Oracle WebLogic ServerメッセージドリブンBeanのプログラミング
12c リリース1 (12.1.1)
B65955-02
  ドキュメント・ライブラリへ移動
ライブラリ
製品リストへ移動
製品
目次へ移動
目次

前
 
次
 

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

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


注意:

この章では、EJB 3.0以前のデプロイメント記述子を使用して基本MDB構成を説明します。EJB 3.1アノテーションを使用する場合は、第11章「MDBのデプロイメント要素とアノテーション」を参照してください。また、同等の設定に関しては、第7章「EJB 3.1準拠のMDBの使用」を参照してください。


宛先タイプの構成

MDBがリスニングする宛先のタイプは、ejb-jar.xmlmessage-driven-destination要素のdestination-type要素で、またはアノテーションを使用して、構成します。

MDBのトランザクション管理戦略の構成

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

記述子の要素を使用してコンテナ・レベルのトランザクション管理を構成するには、次の手順を従います。

EJBアノテーションを使用してコンテナ・レベルのトランザクション管理を構成するには、次の手順を従います。

  import javax.ejb.TransactionAttribute;
  import javax.ejb.TransactionAttributeType;
  ...
  @TransactionAttribute(value = TransactionAttributeType.REQUIRED)
  public void onMessage(Message msg) {
  ...

記述子の要素を使用してBeanレベルのトランザクション管理を構成するには、次の手順を従います。

詳細は、『Oracle WebLogic Server 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コンテキストに含まれるように構成されていないかぎり)。その手法については、「外部JMSサーバー・マッピングを使用するかどうか」を参照してください。

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

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

外部JMSサーバー・マッピングをいつ使用するのか、およびweblogic-ejb-jar.xmlmessage-driven-descriptorを構成するルールの詳細は、次の項を参照してください。

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

外部JMSサーバー・マッピングを使用するかどうか

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

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

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

マッピングを使用するかどうかで、次に説明するようにinitial-context-factorydestination-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.xmlmessage-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がメッセージを受信するとは仮定しないでください。

WebLogic JMS宛先を使用するとき、厳密な順序付けが必要な場合は「順序単位」機能を使用することをお薦めします。この機能を使用すると、MDBを変更せずにあらゆる状況で順序付けを強制したり、同一宛先内に存在する下位順序の同時実行処理を可能にしたりします。なおこの機能は、構成を介して有効化するか、または必要に応じてプログラムを介して有効にできます。『Oracle WebLogic Server JMSのプログラミング』のメッセージ順序単位の使用に関する項を参照してください。

受信順序がクライアントによるメッセージの送信順序に一致することを保証するために、順序単位を使用するWebLogic宛先を使用しない場合、次の操作を実行する必要があります。

  • MDBのmax-beans-in-free-pool1に設定します。これで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は、そのシナリオを示しています。

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

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

再配信と例外処理

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のプログラミング』のロールバック、リカバリ、再配信、または期限切れメッセージの管理に関する項を参照してください。

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

WebLogic Serverは、setMessageDrivenContext()を呼び出してMDBインスタンスとコンテナ・コンテキストを関連付けます。また、EJB 3.1 MDBアプリケーションはMDBコンテキストを注入するアノテーションを指定できます。これはクライアント・コンテキストではありません。クライアント・コンテキストは、JMSメッセージと一緒には渡されません。

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

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

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

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

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

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

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

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

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

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

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

EJBコンテナでは、init-suspend-secondsmax-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の値は無視されます。

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

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

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

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

  1. MDBのWebLogicユーザーを作成します。『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.xmlassembly-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を実装する場合には、次のガイドラインを念頭に置いてください。

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


注意:

論理宛先およびアプリケーション・スコープの宛先は、通常は使用されず、上級ユーザー向けのみとなります。大半のユーザーの場合、「宛先用のMDBの構成」で説明したメソッドの使用をお薦めします。


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

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

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

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

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

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

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

    • message-destination-ref

    • message-destination-ref-name: java:comp/envに関連して、メッセージ宛先のエンタープライズBeanコードで使用される環境名。例えば、<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 WebLogic Server JMSのプログラミング』および『Oracle WebLogic Server JDBCのプログラミング』を参照してください。

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

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

  1. weblogic-ejb-jar.xmlmessage-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要素で定義する宛先と一致する必要があります。