ナビゲーションをスキップ

eDocs ホーム > BEA WebLogic Server 9.0 ドキュメント > WebLogic JMS プログラマーズ ガイド > WebLogic JMS を EJB やサーブレットと組み合わせて使用するために拡張された J2EE サポート

WebLogic JMS プログラマーズ ガイド

  前 次 前/次ボタンと目次ボタンとの区切り線 目次  

WebLogic JMS を EJB やサーブレットと組み合わせて使用するために拡張された J2EE サポート

J2EE 標準では通常隠されているユーザビリティ機能が拡張され、WebLogic JMS またはサードパーティの JMS プロバイダを使用して、EJB コンテナおよびサーブレット コンテナに簡単にアクセスできるようになりました。実際に、この節の説明に従ってこの「JMS ラッパー」サポートを実装することは、EJB またはサーブレットの内部から WebLogic JMS メッセージを送信する最良の方法です。

「リモートまたは外部 JMS プロバイダへのアクセスの簡略化」では、Administration Console での外部 JMS プロバイダのサポートについて簡単に説明します。この機能を使用すると、外部 JMS プロバイダ (別のクラスタまたはドメインにある WebLogic Server のリモート インスタンスを含む) を簡単にマップして、ローカルの JNDI ツリーにローカルの JMS オブジェクトとして表示できます。

 

WebLogic JMS ラッパーの有効化

WebLogic Server では、JMS ラッパーを用いることで、EJB やサーブレットなどの J2EE コンポーネント内部で WebLogic JMS を簡単に使用できるようにするとともに、次のような多数の拡張されたユーザビリティ機能とパフォーマンス機能を提供しています。

「JMS ラッパーの内部での処理」では、WebLogic Server の背後でこれらの機能がどのように実装されているかを説明します。

EJB またはサーブレットのデプロイメント記述子における JMS オブジェクトのリソースとしての宣言

これらの拡張された J2EE 機能を有効にするには、EJB またはサーブレットのデプロイメント記述子に JMS 接続ファクトリを resource-ref として宣言します (「ラップされた JMS 接続ファクトリの宣言」を参照)。たとえば、接続ファクトリを resource-ref として宣言した場合、JMS アプリケーションでは、各 EJB または各サーブレットに対して作成される java:comp/env/ サブツリーを使用して、JNDI からその接続ファクトリをルックアップできます。上記の機能は、デプロイメント記述子の内部で JMS リソースを使用している場合にのみ有効化される点に注意してください。EJB およびサーブレットのプログラマは、接続ファクトリまたは送り先の直接 JNDI ルックアップを実行することによって、従来どおり JMS プロバイダに直接アクセスすることもできます。

詳細については、「エンタープライズ JavaBean の実装」を参照してください。サブレットのプログラミングの詳細については、「Creating and Configuring Servlets」を参照してください。

ラップされた JMS 接続ファクトリの宣言

ejb-jar.xml または web.xml ファイルに resource-ref 要素を定義することによって、EJB またはサーブレットの一部として JMS 接続ファクトリを宣言できます。この処理によって、「ラップされた」JMS 接続ファクトリが作成され、「プールによるパフォーマンスの向上」で説明している、より高度なセッション プーリング、自動トランザクション登録、接続のモニタ、およびコンテナ管理によるセキュリティ機能のメリットを得ることができます。

このような接続ファクトリ要素の例を次に示します。

<resource-ref>
 <res-ref-name>jms/QCF</res-ref-name>
 <res-type>javax.jms.QueueConnectionFactory</res-type>
 <res-auth>Container</res-auth>
 <res-sharing-scope>Shareable</res-sharing-scope>
</resource-ref>

この要素は、JMS オブジェクト QueueConnectionFactory を JNDI の次の場所にバインドすることを宣言しています。

java:comp/env/QCF

この JNDI 名は、resource-ref を宣言した EJB またはサーブレットのコンテキスト内部でのみ有効です。JNDI コンテキスト java:comp/env はこのコンテキストを表します。

この要素以外にも、その場所に配置する JMS 接続ファクトリを J2EE コンテナに指示するために、対応する resource-description 要素が weblogic-ejb-jar.xml (EJB 用) ファイルまたは weblogic.xml (サーブレット用) ファイルになければなりません。次に例を示します。

<resource-description>
  <res-ref-name>jms/QCF</res-ref-name>
  <jndi-name>weblogic.jms.ConnectionFactory</jndi-name>
</resource-description>

ここで指定する接続ファクトリは、グローバル JNDI ツリーにすでに存在している必要があります (この例では、組み込みの WebLogic JMS サーバを使用した場合に自動的に作成されるデフォルト JMS 接続ファクトリの 1 つを使用しています)。同じクラスタにある別の WebLogic JMS 接続ファクトリを使用するには、その接続ファクトリの JNDI 名を jndi-name 要素の内側に追加します。別のベンダまたは別の WebLogic Server クラスタから接続ファクトリを使用するには、外部 JMS サーバを作成します。

resource-description 要素に指定した JNDI 名が正しくない場合でも、アプリケーションはデプロイされます。ただし、接続ファクトリを使用しようとしたときにエラーが返されます。

JMS の送り先の宣言

JMS キューまたはトピックの送り先を JNDI ツリー java:comp/env/jms にバインドすることもできます。そのためには、その送り先を ejb-jar.xml または web.xml のデプロイメント記述子に resource-env-ref 要素として宣言します。トランザクション登録、プーリング、接続モニタの機能は、送り先ではなく接続ファクトリ内で実行されます。ただし、この機能は一貫性を維持し、特定の WebLogic Server コンフィグレーションに対するアプリケーションの依存性を低減するために有用です。対応する resource-env-ref の記述を変更するだけで簡単に送り先を変更でき、ソース コードを再コンパイルする必要がないからです。

このようなキュー送り先要素の例を次に示します。

<resource-env-ref>
  <resource-env-ref-name>jms/TESTQUEUE</resource-env-ref-name>
  <resource-env-ref-type>javax.jms.Queue</resource-env-ref-type>
</resource-env-ref>

この要素は、JMS 送り先オブジェクト Queue を JNDI の次の場所にバインドすることを宣言しています。

java:comp/env/TESTQUEUE

参照される接続ファクトリと同様に、この JNDI 名は、resource-ref を宣言した EJB またはサーブレットのコンテキスト内部でのみ有効です。

また、対応する resource-env-description 要素を weblogic-ejb-jar.xml または weblogic.xml ファイルに定義する必要があります。これによって間接レイヤが提供され、対応する resource-env-ref デプロイメント記述子を変更するだけで、参照される送り先を簡単に変更できます。

<resource-env-description>
  <res-env-ref-name>jms/TESTQUEUE</res-env-ref-name>
  <jndi-name>jmstest.destinations.TESTQUEUE</jndi-name>
</resource-env-description>

ここで指定するキューまたはトピック送り先は、グローバル JNDI ツリーにすでに存在している必要があります。送り先が存在しない場合でも、アプリケーションはデプロイされますが、送り先を使用しようとすると例外が送出されます。

J2EE コンテナによる JMS メッセージの送信

JMS 接続ファクトリおよび送り先リソースを JNDI ツリー java:comp/env にマップするようにデプロイメント記述子で宣言した後、それらを使用して EJB またはサーブレットの内部で JMS メッセージを送受信できます。

たとえば、次のコード例ではメッセージを送信しています。

InitialContext ic = new InitialContext();
QueueConnectionFactory qcf = 
  (QueueConnectionFactory)ic.lookup("java:comp/env/jms/QCF");
Queue destQueue =
  (Queue)ic.lookup("java:comp/env/jms/TESTQUEUE");
ic.close();
QueueConnection connection = qcf.createQueueConnection();
try {
  QueueSession session = connection.createQueueSession(0, false);
  QueueSender sender = session.createSender(destQueue);
  TextMessage msg = session.createTextMessage("This is a test");
  sender.send(msg);
} finally {
  connection.close();
}

これは J2EE 仕様に準拠した標準的なコードであり、J2EE を適切にサポートする任意の EJB またはサーブレット製品上で動作します。違いは、WebLogic Server ではさまざまなオブジェクトが背後でプールされるため、さらに効率的に実行できる点です (「プールされた JMS 接続オブジェクト」を参照)。

このコード例では、try...finally ブロックを使用して、ブロックの内側にある文で例外が発生した場合でも、JMS 接続オブジェクトの close() メソッドが確実に実行されるようにしている点に注意してください。接続プーリングが行われていない場合は、接続をクローズするため、およびサーバ リソースの消費を避けるために、このブロックが必要です。しかし、WebLogic Server はこのコードによって作成されたオブジェクトの一部をプールに入れるため、close() を呼び出すことがさらに重要です。そうしないと、EJB コンテナまたはサーブレット コンテナに、オブジェクトをプールにいつ戻すかが通知されません。

また、JMS API のトランザクション XA 拡張機能はこのコード例では使用されていません。代わりに、トランザクション コンテキスト内で JMS コードが使用されている場合、コンテナはそれらの拡張機能を内部的に使用します。しかし、XA が内部的に使用されるかどうかにかかわらず、ユーザが記述するコードは同じであり、JMS XA クラスを使用しません。これは J2EE の仕様です。EJB コードをこのように記述すると、デプロイメント記述子を変更するだけで、トランザクションが存在する環境または非トランザクション環境で EJB を実行できます。

警告 : ラップされた JMS 接続ファクトリは、resource-ref 機能を使用して取得し、java:comp/env/jms JNDI ツリー コンテキストを使用してルックアップします。ラップされた JMS 接続ファクトリを使用する場合は、EJB でトランザクション XA インタフェースを使用することはできません。

 

JMS ラッパーの内部での処理

この節では、WebLogic Server が JMS オブジェクトを包むラッパーを作成するときに実際に行われる処理について説明します。たとえば、「J2EE コンテナによる JMS メッセージの送信」にあるコード例では、接続ファクトリが JNDI ツリー java:comp/env からルックアップされたため、実際の JMS 接続ファクトリではなく WebLogic 固有のラッパー クラスのインスタンスが返されています。このラッパー オブジェクトは JMS プロバイダへの特定の呼び出しをインターセプトし、正しい J2EE の動作を挿入します。これについて以下の節で説明します。

トランザクションの自動登録

この機能は、WebLogic JMS の実装に対して、または 2 フェーズ コミット トランザクション (XA プロトコル) をサポートするサードパーティの JMS プロバイダに対して有効です。ラップされた JMS 接続のトランザクション コンテキスト内部でメッセージが送受信されるとき、メッセージの送受信に使用されている JMS セッションが JMS プロバイダの XA 機能によってトランザクションに自動的に登録されます。コンテナ管理によるトランザクションを有効にして EJB 内部で JMS コードを呼び出し、トランザクションを暗黙的に開始したか、Bean 管理のトランザクションをサポートするサーブレットまたは EJB で、UserTransaction インタフェースを使用してトランザクションを手動で開始したかにかかわらず、この処理が行われます。

ただし、EJB またはサーブレットがトランザクション コンテキストの内部でメッセージの送受信を試みた場合、JMS プロバイダが XA をサポートしていないと、send() または receive() 呼び出しは以下の例外を送出します。

[J2EE:160055] 2 フェーズ コミットを利用できないため、ラップされた JMS セッションをトランザクションで使用できません。

したがって、トランザクション内部でメッセージを送受信する XA をサポートしていない JMS プロバイダを使用する場合は、トランザクション モードとして NotSupported を指定して EJB を宣言するか、いずれかの JTA API を使用してトランザクションを中断します。

コンテナ管理のセキュリティ

WebLogic JMS では、EJB コンテナまたはサーブレット コンテナを呼び出したときにスレッド上に存在するセキュリティ資格が使用されます。ただし、外部 JMS プロバイダでは、weblogic-ejb-jar.xml または web.xml ファイルで resource-ref 要素を使用して JMS 接続ファクトリを宣言する場合、res-auth というオプションのサブ要素があります。この要素には次に示す 2 つのオプションのいずれかを設定できます。

Container - res-auth 要素に Container を設定すると、JMS プロバイダに対するセキュリティは J2EE コンテナによって管理されます。この場合、JMS 接続ファクトリが Foreign JMS Connection Factory コンフィグレーション MBean を使用して JNDI ツリーにマップされた後、MBean のユーザ名とパスワードが使用されます (「リモートまたは外部 JMS プロバイダへのアクセスの簡略化」を参照)。それ以外の場合、WebLogic Server はユーザ名またはパスワードの指定なしでプロバイダに接続します。このモードでは、JMS 接続ファクトリの createConnection() メソッドにユーザ名とパスワードを渡すとエラーになります。

Application - res-auth 要素に Application を設定すると、MBean のユーザ名またはパスワードは無視されます。その代わりに、アプリケーション コードでは、JMS 接続ファクトリの createConnection() メソッドに対してユーザ名とパスワードを指定するか、ユーザ名またはパスワードが必要ない場合はそれらを指定しない createConnection() のバージョンを使用する必要があります。

接続テスト

JMS ラッパー クラスは、JMS プロバイダに対して確立された各接続をモニタします。これは次の 2 つの方法で行われます。

J2EE の準拠

J2EE 仕様では、特定の JMS API 呼び出しを J2EE アプリケーションの内部で実行してはならないとされています。制約違反があった場合、JMS ラッパーは以下の例外を送出して制約を適用します。

さらに、createSession() メソッドと、関連する createQueueSession() および createTopicSession() メソッドは扱いが異なります。createSession() メソッドには、「確認応答」モードと「トランザクション化」フラグの 2 つのパラメータを指定します。EJB の内部で使用した場合、これらの 2 つのパラメータは無視されます。トランザクションが存在する場合は、JMS セッションがトランザクションに登録されます (「トランザクションの自動登録」を参照)。存在しない場合は登録されません。デフォルトでは、確認応答モードは「自動確認」に設定されます。この動作は J2EE 仕様で規定されています。

注意 : この仕様のため、EJB 内部からのメッセージ受信はいっそう難しくなりますが、EJB 内部からメッセージを受信するには、MDB を使用することをお勧めします (『WebLogic エンタープライズ JavaBeans (EJB) プログラマーズ ガイド』の「メッセージ駆動型 EJB」を参照)。

サーブレットの内部では、createQueueSession() および createTopicSession() のパラメータが正常に処理され、さまざまなメッセージ確認応答モードがすべて使用できます。

プールされた JMS 接続オブジェクト

「J2EE コンテナによる JMS メッセージの送信」に示した例のようなコードをより効率的にするために、JMS ラッパーはさまざまなセッション オブジェクトをプールします。プールされた JMS 接続は、デプロイメント記述子で resource-ref 要素を使用して JMS 接続ファクトリを定義している EJB およびサーブレットによって使用されるセッション プールです (「ラップされた JMS 接続ファクトリの宣言」を参照)。

 

プールによるパフォーマンスの向上

JMS ラッパーによって接続オブジェクトおよびその他のオブジェクトが自動的にプールされるため、「J2EE コンテナによる JMS メッセージの送信」に示すようにコードを記述すると効率的です。この例では、メッセージを送信するたびに接続ファクトリ、接続、およびセッションの各オブジェクトが作成されます。実際には、これら 3 つのクラスは連携して動作し、例のような使い方をした場合、これらのオブジェクトが実行する動作はほとんどプールからセッション オブジェクトを取得することだけです。

セッション オブジェクトのプールによる JNDI ルックアップの高速化

接続ファクトリ オブジェクトと送り先オブジェクトの JNDI ルックアップでは、パフォーマンスの負荷が大きくなる可能性があります。送り先オブジェクトが外部 JMS 送り先 MBean を指していて、そのためローカルでない JNDI プロバイダをルックアップする場合は、特にその可能性があります。接続ファクトリ オブジェクトと送り先オブジェクトはスレッドセーフであるため、作成時に EJB またはサーブレットの内部で 1 回ルックアップすることができます。毎回ルックアップを行う必要がなく、時間を節約できます。

サーブレットの内部では、このようなルックアップを init() メソッドの内部で実行できます。次に接続ファクトリ オブジェクトと送り先オブジェクトをインスタンス変数に割り当て、メッセージ送信時に再利用できます。

EJB の内部では、このようなルックアップを ejbCreate() メソッドの内部で実行し、インスタンス変数に割り当てることができます。セッション Bean の場合、Bean の各インスタンスに専用のコピーがあります。ステートレス セッション Bean はプールされるので、このメソッドは非常に効率的でもあります (さらに J2EE 仕様完全準拠)。JMS 接続オブジェクトをプールすることによって、ルックアップ発生回数が大幅に削減されるからです (これらのオブジェクトを EJB クラスの静的メンバーにキャッシュすることもできますが、J2EE 仕様では推奨されていません)。

ただし、これらのオブジェクトを ejbCreate() または init() メソッドの内部にキャッシュする場合は、エラーが発生したときにオブジェクトを再作成する方法を EJB またはサーブレットが備えている必要があります。この方法が必要な理由は、WebLogic JMS のように一部の JMS プロバイダは、サーバ障害発生後に送り先オブジェクトを無効化するためです。そのため、EJB が Server A で動作していて、JMS が Server B で動作している場合、Server A の EJB は、Server B のオブジェクトをサーバ回復後に再度 JNDI ルックアップを実行しなければなりません。「PoolTestBean.java」の例は、このキャッシング後の再ルックアップ処理を適切に実行するサンプル EJB を示しています。

キャッシングによるオブジェクト作成の高速化

接続ファクトリ オブジェクトや送り先オブジェクトのプールが確立された後、接続オブジェクト、セッション オブジェクト、プロデューサ オブジェクトなどの他のオブジェクトを ejbCreate() メソッドの内部でキャッシュしようとする場合があります。この方法は機能しますが、必ずしも最も効率的な解決策ではありません。基本的に、この方法ではセッション オブジェクトをキャッシュから削除し、特定の EJB に永続的に割り当てます。これに対し、設計どおりに JMS ラッパーを使用すると、他の EJB およびサーブレットもセッション オブジェクトを共有できます。さらに、ラッパーは、JMS プロバイダとの通信障害が発生した場合に JMS 接続の再確立と新しいセッション オブジェクトの作成を試みますが、セッション オブジェクトを独自にキャッシュすると、この機能は動作しません。

適切なトランザクション モードの登録

JMS の send() または receive() 操作をトランザクション内部で実行する場合、EJB またはサーブレットは自動的に JMS プロバイダをトランザクションに登録します。トランザクションは、コンテナ管理のトランザクションを持つ EJB またはサーブレットの内部で自動的に開始するか、UserTransaction インタフェースを使用して明示的に開始できます。いずれの場合も、コンテナは JMS プロバイダを自動的に登録します。ただし、EJB またはサーブレットが使用する基底の JMS 接続ファクトリが XA をサポートしていない場合、コンテナは例外を送出します。

トランザクション登録の実行はオーバーヘッドを伴います。さらに、XA 接続ファクトリを使用していても、send() または receive() メソッドをトランザクションの外部で呼び出す場合は、どの JMS プロバイダを使用するかにかかわらず操作が適切に実行されるように、コンテナは JTA トランザクションを作成して send() または receive() メソッドをラップする必要があります。これは 1 フェーズのみのコミットですが、サーバの処理速度が低下する場合があります。

したがって、JMS リソースを非トランザクション形式で使用する EJB またはサーブレットを記述する場合、最適な方法は、XA をサポートするようにコンフィグレーションされていない JMS 接続ファクトリを使用することです。

 

JMS ラッパー関数の例

次のファイルは、EJB が呼び出されたときに WebLogic JMS ラッパー関数を使用してトランザクション メッセージ (sendXATransactional) を送信する、簡単なスレートレス EJB セッション Bean を記述しています。この例ではセッション Bean を使用していますが、同じ XML 記述子と Bean クラスを (ほとんど変更を加えることなく) メッセージ駆動型 Bean にも使用できます。

ejb-jar.xml

このセクションには EJB コンポーネントを記述します。この節に抜粋した JMS ラッパーのコード例では、ラップされた JMS 接続ファクトリ (QueueConnectionFactory) と参照される JMS 送り先 (TESTQUEUE) の resource-ref および resource-env-ref 要素をこのセクションに宣言しています。

<?xml version="1.0"?>

<!DOCTYPE ejb-jar PUBLIC 
  "-//Sun Microsystems, Inc.//DTD Enterprise JavaBeans 2.0//EN"
  "http://java.sun.com/dtd/ejb-jar_2_0.dtd">

<ejb-jar>
 <enterprise-beans>
  <session>
   <ejb-name>PoolTestBean</ejb-name>
   <home>weblogic.jms.pool.test.PoolTestHome</home>
   <remote>weblogic.jms.pool.test.PoolTest</remote>
   <ejb-class>weblogic.jms.pool.test.PoolTestBean</ejb-class>
   <session-type>Stateless</session-type>
   <transaction-type>Container</transaction-type>

   <resource-ref>
      <res-ref-name>jms/QCF</res-ref-name>
      <res-type>javax.jms.QueueConnectionFactory</res-type>
      <res-auth>Container</res-auth>
      <res-sharing-scope>Shareable</res-sharing-scope>
   </resource-ref>

   <resource-env-ref>
    <resource-env-ref-name>jms/TESTQUEUE</resource-env-ref-name>
     <resource-env-ref-type>javax.jms.Queue</resource-env-ref-type>
   </resource-env-ref>
  </session>
 </enterprise-beans>
 
 <assembly-descriptor>
  <container-transaction>
   <method>
     <ejb-name>PoolTestBean</ejb-name>
     <method-name>*</method-name>
    </method>
    <trans-attribute>Required</trans-attribute>
    </container-transaction>
  </assembly-descriptor>
</ejb-jar>

weblogic-ejb-jar.xml

このセクションでは、キュー接続ファクトリおよびキュー送り先に対応する resource-description 要素を宣言します。この要素は、その位置に格納する JMS 接続ファクトリと送り先を J2EE コンテナに指示します。

<?xml version="1.0"?>

<!DOCTYPE weblogic-ejb-jar PUBLIC 
  "-//BEA Systems, Inc.//DTD WebLogic 8.1.0 EJB//EN"
  "http://www.bea.com/servers/wls810/dtd/weblogic-ejb-jar.dtd">

<weblogic-ejb-jar>
  <weblogic-enterprise-bean>
    <ejb-name>PoolTestBean</ejb-name>
    <stateless-session-descriptor>
      <pool>
        <max-beans-in-free-pool>8</max-beans-in-free-pool>
        <initial-beans-in-free-pool>2</initial-beans-in-free-pool>
      </pool>
    </stateless-session-descriptor>
    
    <reference-descriptor>
      <resource-description>
        <res-ref-name>jms/QCF</res-ref-name>
        <jndi-name>weblogic.jms.XAConnectionFactory</jndi-name>
      </resource-description>
      <resource-env-description>
        <res-env-ref-name>jms/TESTQUEUE</res-env-ref-name>
        <jndi-name>TESTQUEUE</jndi-name>
      </resource-env-description>
    </reference-descriptor>
    <jndi-name>PoolTest</jndi-name>
  </weblogic-enterprise-bean>
</weblogic-ejb-jar>

PoolTest.java

このセクションでは、PoolTest Bean に使用するリモート インタフェースを定義します。sendXATransactional というメソッドを 1 つ宣言します。 

package weblogic.jms.pool.test;

import java.rmi.*;
import javax.ejb.*;
public interface PoolTest extends EJBObject
{
  public String sendXATransactional(String text)
    throws RemoteException;
}

PoolTestHome.java

このセクションでは、PoolTest Bean に使用する「ホーム」インタフェースを定義します。EJB 仕様ではこのセクションは必須です。

package weblogic.jms.pool.test;

import java.rmi.*;
import javax.ejb.*;

public interface PoolTestHome
  extends EJBHome
{
  PoolTest create()
    throws CreateException, RemoteException;
}

PoolTestBean.java

このセクションでは実際の EJB コードを定義します。 sendXATransactional メソッドが呼び出されたときは常にメッセージを送信します。

package weblogic.jms.pool.test;

import java.lang.reflect.*;
import java.rmi.*;
import javax.ejb.*;
import javax.jms.*;
import javax.naming.*;
import javax.transaction.*;

public class PoolTestBean
  extends PoolTestBeanBase
  implements SessionBean
{ 
  private SessionContext context;
  private QueueConnectionFactory qcf;
  private Queue destination;
  
  public void ejbActivate()
  {
  }
  
  public void ejbRemove()
  {
  }
  
  public void ejbPassivate()
  {
  }
  
  public void setSessionContext(SessionContext ctx)
  {
    context = ctx;
  }

  private void lookupJNDIObjects()
    throws NamingException
  {
    InitialContext ic = new InitialContext();
    try {
      qcf =
       (QueueConnectionFactory)ic.lookup
                                       ("java:comp/env/jms/QCF");
      destination =
       (Queue)ic.lookup("java:comp/env/jms/TESTQUEUE");
     } finally {
       ic.close();
     }
  }
  
  public void ejbCreate()
    throws CreateException
  {
    try {
      lookupJNDIObjects();
    } catch (NamingException ne) {
      throw new CreateException(ne.toString());
    }
  }
  
  public String sendXATransactional(String text)
    throws RemoteException
  {
    String id = "Not sent yet";
    try {
      if ((qcf == null) || (destination == null)) {
        lookupJNDIObjects();
      }
      QueueConnection connection = qcf.createQueueConnection();
      try {
        QueueSession session = connection.createQueueSession
                                                     (false, 0);
        TextMessage message = session.createTextMessage
                                                     (text);
        QueueSender sender = session.createSender(destination);
        sender.send(message);
        id = message.getJMSMessageID();
      } finally {
        connection.close();
      }
    } catch (Exception e) {
      // エラー発生時は JNDI オブジェクトを無効化
      // これが必要な理由は、送り先オブジェクトは
      // 送り先サーバが停止されると無効になる可能性が
      // あるため
      qcf = null;
      destination = null;
      throw new RemoteException("Failure in EJB: " + e);
    }
    return id;
  }
}

 

リモートまたは外部 JMS プロバイダへのアクセスの簡略化

外部 JMS プロバイダの別の機能セットを使用すると、サードパーティの JNDI プロバイダ内の JMS 接続ファクトリまたは送り先オブジェクトと、ローカルの WebLogic Server 内部のオブジェクトとのシンボリック リンクを作成できます。この機能を使用すると、ローカルの WebLogic JNDI ツリーで別のクラスタまたはドメインにある WebLogic Server のリモート インスタンスを参照することもできます。

このタスクに使用する 3 つのシステム モジュール MBean があります。

Administration Console を使用した外部リソースのコンフィグレーション方法については、『WebLogic JMS のコンフィグレーションと管理』の「外部サーバ リソース」を参照してください。

これらの外部システム モジュール MBean をデプロイすると、ローカル サーバの JNDI ツリーにオブジェクトが作成され、外部システム モジュール MBean がルックアップされる場合は常に、参照されているリモートの JMS オブジェクトのルックアップが実行されます。つまり、ローカル サーバとリモートの JNDI ディレクトリの同期が常に維持されます。ただし、パフォーマンスの観点では、これらの MBean の JNDI ルックアップは負荷が大きくなる可能性があります。「プールによるパフォーマンスの向上」には、これらのリモート ルックアップのパフォーマンスを向上させるいくつかの方法が示されています。

 

フッタのナビゲーションのスキップ  ページの先頭 前 次