WebLogic JMS プログラマーズ ガイド
![]() |
![]() |
![]() |
![]() |
J2EE 標準では通常隠されているユーザビリティ機能が拡張され、WebLogic JMS またはサードパーティの JMS プロバイダを使用して、EJB コンテナおよびサーブレット コンテナに簡単にアクセスできるようになりました。実際に、この節の説明に従ってこの「JMS ラッパー」サポートを実装することは、EJB またはサーブレットの内部から WebLogic JMS メッセージを送信する最良の方法です。
「リモートまたは外部 JMS プロバイダへのアクセスの簡略化」では、Administration Console オンライン ヘルプの「リモートまたは外部 JMS プロバイダへの単純なアクセス」で解説されている、外部 JMS プロバイダに対する Administration Console サポートについて簡単に説明します。この機能を使用すると、外部 JMS プロバイダ (別のクラスタまたはドメインにある WebLogic Server のリモート インスタンスを含む) を簡単にマップして、ローカルの JNDI ツリーにローカルの JMS オブジェクトとして表示できます。
WebLogic Server では、JMS ラッパーを用いることで、EJB やサーブレットなどの J2EE コンポーネント内部で WebLogic JMS を簡単に使用できるようにするとともに、次のような多数の拡張されたユーザビリティ機能とパフォーマンス機能を提供しています。
「JMS ラッパーの内部での処理」では、WebLogic Server の背後でこれらの機能がどのように実装されているかを説明します。
これらの拡張された J2EE 機能を有効にするには、EJB またはサーブレットのデプロイメント記述子に JMS 接続ファクトリを resource-ref
として宣言します (「ラップされた JMS 接続ファクトリを宣言する」を参照)。たとえば、接続ファクトリを resource-ref
として宣言した場合、JMS アプリケーションでは、各 EJB または各サーブレットに対して作成される java:comp/env/
サブツリーを使用して、JNDI からその接続ファクトリをルックアップできます。上記の機能は、デプロイメント記述子の内部で JMS リソースを使用している場合にのみ有効化される点に注意してください。EJB およびサーブレットのプログラマは、接続ファクトリまたは送り先の直接 JNDI ルックアップを実行することによって、従来どおり JMS プロバイダに直接アクセスすることもできます。
詳細については、『WebLogic エンタープライズ JavaBeans (EJB) プログラマーズ ガイド』の「エンタープライズ JavaBean の実装」を参照してください。サーブレットのプログラミングに関する詳細については、『WebLogic HTTP サーブレット プログラマーズ ガイド』の「プログラミング タスク」を参照してください。
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/jms/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>
Administration Console オンライン ヘルプの「JMS 接続ファクトリのタスク」で説明しているように、ここで指定する接続ファクトリは、グローバル JNDI ツリーにすでに存在している必要があります (この例では、組み込みの WebLogic JMS サーバを使用した場合に自動的に作成されるデフォルト JMS 接続ファクトリの 1 つを使用しています)。同じクラスタにある別の WebLogic JMS 接続ファクトリを使用するには、その接続ファクトリの JNDI 名を jndi-name
要素の内側に追加します。別のベンダまたは別の WebLogic Server クラスタの接続ファクトリを使用するには、外部 JMS サーバを作成します (Administration Console オンライン ヘルプの「JMS 接続ファクトリのタスク」を参照)。
resource-description
要素に指定した JNDI 名が正しくない場合でも、アプリケーションはデプロイされます。 ただし、接続ファクトリを使用しようとしたときにエラーが返されます。
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/jms/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 ツリーにすでに存在している必要があります (Administration Console オンライン ヘルプの「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 インタフェースを使用することはできません。
この節では、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 接続ファクトリのコンフィグレーション属性に関する詳細については、Administration Console オンライン ヘルプの「[JMS 接続ファクトリ] --> [コンフィグレーション] --> [トランザクション]」を参照してください。
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 つの方法で行われます。
ExceptionListener
を接続に登録する。注意 : WebLogic JMS サーバへの接続をテストするための一時的なキューまたはトピックを作成するには、一時的な送り先をホストするように JMS サーバをコンフィグレーションする必要があります。詳細については、『WebLogic JMS プログラマーズ ガイド』の「一時的な送り先の使い方」を参照してください。
J2EE 仕様では、特定の JMS API 呼び出しを J2EE アプリケーションの内部で実行してはならないとされています。制約違反があった場合、JMS ラッパーは以下の例外を送出して制約を適用します。
createConnectionConsumer()
、createDurableConnectionConsumer()
、setClientID()
、setExceptionListener()
、stop()
の各メソッドを呼び出してはならない。getMessageListener()
および setMessageListener()
メソッドを呼び出してはならない。QueueReceiver
または TopicSubscriber
オブジェクト) では、getMessageListener()
および setMessageListener()
メソッドを呼び出してはならない。さらに、createSession()
メソッドと、関連する createQueueSession()
および createTopicSession()
メソッドは扱いが異なります。createSession()
メソッドには、「確認応答」モードと「トランザクション化」フラグの 2 つのパラメータを指定します。EJB の内部で使用した場合、これらの 2 つのパラメータは無視されます。トランザクションが存在する場合は、JMS セッションがトランザクションに登録されます (「トランザクションの自動登録」を参照)。存在しない場合は登録されません。デフォルトでは、確認応答モードは「自動確認」に設定されます。この動作は J2EE 仕様で規定されています。
注意 : この仕様のため、EJB 内部からのメッセージ受信はいっそう難しくなりますが、EJB 内部からメッセージを受信するには、MDB を使用することをお勧めします (『WebLogic エンタープライズ JavaBeans (EJB) プログラマーズ ガイド』の「メッセージ駆動型 EJB」を参照)。
サーブレットの内部では、createQueueSession()
および createTopicSession()
のパラメータが正常に処理され、さまざまなメッセージ確認応答モードがすべて使用できます。
「J2EE コンテナにより JMS メッセージを送信する」に示した例のようなコードをより効率的にするために、JMS ラッパーはさまざまなセッション オブジェクトをプールします。プールされた JMS 接続は、デプロイメント記述子で resource-ref
要素を使用して JMS 接続ファクトリを定義している EJB およびサーブレットによって使用されるセッション プールです (「ラップされた JMS 接続ファクトリを宣言する」を参照)。
プールされた JMS セッションのモニタは、[プール済み JMS 接続] タブから行います。このタブを表示するには、[サーバ|モニタ|JMS] ノードを選択します (Administration Console オンライン ヘルプの「[サーバ] --> [モニタ] --> [JMS]」を参照)。
JMS ラッパーによって接続オブジェクトおよびその他のオブジェクトが自動的にプールされるため、「J2EE コンテナにより JMS メッセージを送信する」に示すようにコードを記述すると効率的です。この例では、メッセージを送信するたびに接続ファクトリ、接続、およびセッションの各オブジェクトが作成されます。実際には、これら 3 つのクラスは連携して動作し、例のような使い方をした場合、これらのオブジェクトが実行する動作はほとんどプールからセッション オブジェクトを取得することだけです。
接続ファクトリ オブジェクトと送り先オブジェクトの 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 接続ファクトリを使用することです。WebLogic JMS 接続ファクトリのコンフィグレーションの詳細については、Administration Console オンライン ヘルプの「JMS 接続ファクトリのコンフィグレーション」を参照してください。
次のファイルは、EJB が呼び出されたときに WebLogic JMS ラッパー関数を使用してトランザクション メッセージ (sendXATransactional
) を送信する、簡単なステートレス EJB セッション Bean を記述しています。この例ではセッション Bean を使用していますが、同じ XML 記述子と Bean クラスを (ほとんど変更を加えることなく) メッセージ駆動型 Bean にも使用できます。
このセクションには 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>
このセクションでは、キュー接続ファクトリおよびキュー送り先に対応する 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
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;
}
このセクションでは、PoolTest
Bean に使用する「ホーム」インタフェースを定義します。 EJB 仕様ではこのセクションは必須です。
package weblogic.jms.pool.test;
import java.rmi.*;
import javax.ejb.*;
public interface PoolTestHome
extends EJBHome
{
PoolTest create()
throws CreateException, RemoteException;
}
このセクションでは実際の 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 プロバイダの別の機能セットを使用すると、サードパーティの JNDI プロバイダ内の JMS 接続ファクトリまたは送り先オブジェクトと、ローカルの WebLogic Server 内部のオブジェクトとのシンボリック リンクを作成できます。この機能を使用すると、ローカルの WebLogic JNDI ツリーで別のクラスタまたはドメインにある WebLogic Server のリモート インスタンスを参照することもできます。
このタスクに使用する 3 つのコンフィグレーション MBean があります。
resource-reference
の内側に、Container モード authentication を指定して使用している場合にのみ、使用されます。その場合、親の Foreign JMS Connection Factory MBean の対象となっている各 WebLogic Server インスタンスに非レプリケート JNDI オブジェクトが作成されます (クラスタの各ノードに JNDI オブジェクトを作成するには、そのクラスタを親 MBean の対象にします)。Administration Console でこれらの MBean をコンフィグレーションする手順については、Administration Console オンライン ヘルプの「リモートまたは外部 JMS プロバイダへの単純なアクセス」を参照してください。
これらの外部 JMS MBean をデプロイすると、ローカル サーバの JNDI ツリーにオブジェクトが作成され、外部 JMS MBean がルックアップされる場合は常に、参照されているリモートの JMS オブジェクトのルックアップが実行されます。つまり、ローカル サーバとリモートの JNDI ディレクトリの同期が常に維持されます。ただし、パフォーマンスの観点では、これらの MBean の JNDI ルックアップは負荷が大きくなる可能性があります。「プールによるパフォーマンスの向上」には、これらのリモート ルックアップのパフォーマンスを向上させるいくつかの方法が示されています。
![]() ![]() |
![]() |
![]() |