| ドキュメントのダウンロード | サイト マップ | Glossary | |
|
|||
| BEA ホーム | 製品 | dev2dev | support | askBEA |
|
|
|
|||||||
 |
| e-docs > WebLogic Server > WebLogic JMS プログラマーズ ガイド > WebLogic JMS の基礎 |
|
WebLogic JMS プログラマーズ ガイド
|
以下の節では、WebLogic JMS コンポーネントと機能について説明します。
注意: この節で説明する JMS クラスの詳細については、Sun Microsystems の Java Web サイトにある以下の JMS 仕様と Javadoc を参照してください。
http://java.sun.com/products/jms/docs.html
JMS では、ポイント ツー ポイント (PTP) とパブリッシュ/サブスクライブ (Pub/sub) の 2 つのメッセージング モデルがサポートされています。それらのメッセージング モデルは非常に似ていますが、以下の点で異なります。
各モデルは、共通の基本クラスを拡張したクラスで実装されます。たとえば、PTP クラスの avax.jms.Queue と Pub/sub クラスの javax.jms.Topic は両方とも avax.jms.Destination を拡張したクラスです。
各メッセージング モデルについては、以降の節で詳しく説明します。
注意: プロデューサおよびコンシューマという用語は、メッセージング モデルに関係なく、それぞれメッセージを送信および受信するアプリケーションを表すために汎用的に使用します。ただし、各メッセージング モデルでは、それぞれに固有のユニークな用語でプロデューサとコンシューマを表します。
ポイント ツー ポイント (PTP) メッセージング モデルでは、アプリケーションが別の 1 つのアプリケーションにメッセージを送信できます。PTP メッセージング アプリケーションでは、名前付きのキューを使用してメッセージが送信および受信されます。キュー センダ (プロデューサ) では、特定のキューに対してメッセージが送信されます。キュー レシーバ (コンシューマ) では、特定のキューからメッセージが受信されます。
図2-1 ポイント ツー ポイント (PTP) メッセージング
複数のキュー センダおよびキュー レシーバを 1 つのキューに関連付けることができますが、個々のメッセージは 1 つのキュー レシーバにしか配信できません。
複数のキュー レシーバがキューのメッセージをリスンしている場合、次のメッセージを受信するキュー レシーバは先着順で決定されます。リスンしているキュー レシーバがない場合は、キュー レシーバがキューにアタッチされるまでメッセージはキューにとどまります。
パブリッシュ/サブスクライブ (Pub/sub) メッセージング モデルでは、アプリケーションが複数のアプリケーションにメッセージを送信できます。Pub/sub メッセージング アプリケーションでは、トピックをサブスクライブすることでメッセージが送信および受信されます。トピック パブリッシャ (プロデューサ) では、特定のトピックに対してメッセージが送信されます。トピック サブスクライバ (コンシューマ) では、特定のトピックからメッセージが受信されます。
次の図は、Pub/sub メッセージングの仕組みを示しています。
図2-2 パブリッシュ/サブスクライブ (Pub/sub) メッセージング
PTP メッセージング モデルの場合と違って、Pub/sub メッセージング モデルでは複数のトピック サブスクライバが同じメッセージを受信できます。メッセージは、すべてのトピック サブスクライバが受信するまで維持されます。
Pub/sub メッセージング モデルでは恒久サブスクライバがサポートされるので、トピック サブスクライバに名前を割り当て、ユーザまたはアプリケーションと関連付けることができます。恒久サブスクライバの詳細については、恒久サブスクリプションの設定を参照してください。
永続的メッセージは、少なくともは 1 回は確実に配信されます。永続的メッセージは、ファイルまたはデータベースに正常に書き込まれるまで送信されたとは判断されません。永続的メッセージは、コンフィグレーション時に各 JMS サーバに割り当てられた永続的なバッキング ストア (ファイルまたは JDBC データベース) に書き込まれます。
非永続的メッセージは格納されません。メッセージは最低 1 回は配信が保証されますが、システム障害が発生すると失われる場合があります。接続を閉じるか回復すると、確認応答されていないすべての非永続的メッセージが再配信される。非永続的メッセージは確認応答されると再配信されない。
JMS アプリケーションを作成するには、javax.jms API を使用します。この API では、JMS への接続やメッセージの送受信に必要なクラス オブジェクトを作成できます。JMS クラス インタフェースは、共通の親クラスのキュー バージョンとトピック バージョンを提供するサブクラスとして作成されます。
次の表は、以降の節で詳しく説明する JMS クラスを示しています。すべての JMS クラスの詳細については、javax.jms、weblogic.jms.ServerSessionPoolFactory、または weblogic.jms.extensions Javadoc を参照してください。
JMS オブジェクトのコンフィグレーションについては、WebLogic JMS の管理を参照してください。JMS アプリケーションを設定する手順については、JMS アプリケーションの設定を参照してください。
ConnectionFactory オブジェクトは、接続のコンフィグレーション情報をカプセル化し、JMS アプリケーションが Connection を作成できるようにします。接続ファクトリでは同時使用がサポートされており、複数のスレッドがオブジェクトに同時にアクセスできます。
システム管理者は 1 つまたは複数の接続ファクトリを定義およびコンフィグレーションして、あらかじめ定義された属性で接続を作成します。ただしこれは、各接続ファクトリにユニークな名前が付けられている場合にかぎります。WebLogic Server では起動時にそれらの接続ファクトリが JNDI スペースに追加されます。アプリケーションでは、WebLogic JNDI を使用して接続ファクトリを取り出します。
システム管理者は、複数の接続ファクトリをコンフィグレーションし、対象を使用してそれらを WebLogic Server に割り当てることで、クラスタ内のあらゆるサーバから送り先へのクラスタワイドで透過的なアクセスを確立できます。ただし、複数の WebLogic Server に正常にデプロイするには、各接続ファクトリの名前がユニークであることが必要です。JMS クラスタ化の詳細については、WebLogic JMS のクラスタ化のコンフィグレーションを参照してください。
WebLogic JMS では、次のデフォルト接続ファクトリが 1 つ用意されています。このファクトリは、JNDI 名 weblogic.jms.ConnectionFactory でルックアップできます。接続ファクトリは、WebLogic JMS で用意されるデフォルトがアプリケーションに適さない場合にのみ定義する必要があります。接続ファクトリのコンフィグレーションについては、『管理者ガイド』の「JMS の管理」を参照してください。
注意: 下位互換性を維持するため、WebLogic JMS では非推奨の 2 つのデフォルト接続ファクトリを現在もサポートしています。該当するファクトリの JNDI 名は、javax.jms.QueueConnectionFactory と javax.jms.TopicConnectionFactory です。
非推奨の接続ファクトリから新しいデフォルトまたはユーザ定義の接続ファクトリへの移行については、WebLogic JMS アプリケーションの移植を参照してください。
ConnectionFactory クラスではメソッドは定義されませんが、そのサブクラスでは各メッセージング モデルのメソッドが定義されます。接続ファクトリでは同時使用がサポートされており、複数のスレッドがオブジェクトに同時にアクセスできます。
次の表は、ConnectionFactory のサブクラスを説明しています。
アプリケーションで ConnectionFactory クラスを使用する方法については、WebLogic JMS アプリケーションの開発または javax.jms.ConnectionFactory Javadoc を参照してください。
Connection オブジェクトは、アプリケーションとメッセージング システムの間の開いている通信チャネルを表し、メッセージを生成および消費するための Session を作成するために使用します。接続では、アプリケーションと JMS の間のメッセージングを管理するサーバサイドとクライアントサイドのオブジェクトが作成されます。接続では、ユーザの認証も提供されます。
Connection は、JNDI ルックアップを通じて取得する ConnectionFactory によって作成されます。
ユーザの認証や通信の設定に関わるリソースのオーバーヘッドがあるため、ほとんどのアプリケーションではすべてのメッセージングで 1 つの接続を確立します。WebLogic Server では、JMS トラフィックはサーバとのクライアント接続で他の WebLogic サービスと多重化されます。JMS のために、新たな TCP/IP 接続が作成されることはありません。サーブレットや他のサーバサイド オブジェクトもまた、JMS Connection を使用する場合があります。
デフォルトでは、接続は停止モードで作成されます。停止状態の接続をいつどのように開始するのかについては、接続の開始、停止、クローズを参照してください。
接続では同時使用がサポートされており、複数のスレッドがオブジェクトに同時にアクセスできます。
次の表は、Connection のサブクラスを説明しています。
|
QueueSession。QueueConnectionFactory で作成された JMS PTP プロバイダへの接続で構成される。 |
||
|
TopicSession。TopicConnectionFactory で作成された JMS Pub/sub プロバイダへの接続で構成される。 |
アプリケーションで Connection クラスを使用する方法については、WebLogic JMS アプリケーションの開発または avax.jms.Connection Javadoc を参照してください。
Session オブジェクトでは、生成および消費されるメッセージの順序を定義し、複数のメッセージ プロデューサとメッセージ コンシューマを作成できます。メッセージの生成と消費に同じスレッドを使用できます。アプリケーションでメッセージの生成と消費に別々のスレッドが必要な場合は、そのアプリケーションで機能ごとに個別のセッションを作成する必要があります。
Session は、Connection によって作成されます。
注意: セッションおよびそのメッセージのプロデューサとコンシューマには、一度に 1 つのスレッドしかアクセスできません。それらに複数のスレッドが同時にアクセスした場合、それらの動作は定義されません。
アプリケーションで Session クラスを使用する方法については、WebLogic JMS アプリケーションの開発、または javax.jms.Session Javadoc および weblogic.jms.extensions.WLSession Javadoc を参照してください。
非トランザクション セッションでは、セッションを作成するアプリケーションで、次の表で定義されている 5 つの確認応答モードのいずれかが選択されます。
|
受信側アプリケーションのメソッドが処理を終えたときに、Session オブジェクトでメッセージ受信の確認応答が行われる。 |
|
|
Session オブジェクトの動作は、アプリケーションによる確認応答メソッドの呼び出しに依存する。メソッドが呼び出されると、セッションでは、前回の確認応答以降に受信されたすべてのメッセージに対して確認応答が行われる。 このモードを使用すると、アプリケーションでは 1 回の呼び出しで複数メッセージの受信、処理、および確認応答を行うことができる。 注意: Administration Console では、接続ファクトリの [確認応答ポリシー] 属性が Previous に設定されているのに対し、指定のセッションでのすべての受信メッセージを確認応答したい場合、最後のメッセージを使用して確認応答メソッドを呼び出します。[確認応答ポリシー] 属性の詳細については、Administration Console オンライン ヘルプの「[JMS 接続ファクトリ]」を参照。 |
|
|
受信側アプリケーションのメソッドが処理を終えたときに、Session オブジェクトでメッセージ受信の確認応答が行われる。確認応答の重複が許可される。 注意: アプリケーションで重複メッセージを処理できない場合は、このモードは使用しない。重複メッセージは、メッセージを配信する最初の試行が失敗した場合に送信されます。 |
|
|
確認応答を必要としない。NO_ACKNOWLEDGE セッションに送信されたメッセージは、サーバから即座に削除される。このモードで受信されたメッセージは回復されないので、メッセージを配信する最初の試行が失敗した場合はメッセージが失われたり、重複メッセージが配信されたりする。 このモードは、セッションの確認応答で提供されるサービスの質を必要とせず、それに関連するオーバーヘッドを避ける必要があるアプリケーションで使用する。 注意: アプリケーションで、失われたメッセージや重複メッセージを処理できない場合は、このモードは使用しないでください。重複メッセージは、メッセージを配信する最初の試行が失敗した場合に送信されます。 |
|
|
MULTICAST_NO_ACKNOWLEDGE セッションに送信されたメッセージでは、前述の NO_ACKNOWLEDGE モードと同じ特性が共有される。 このモードは、マルチキャストをサポートし、セッションの確認応答で提供されるサービスの質を必要としないアプリケーションで使用する。マルチキャストの詳細については、マルチキャストの使い方を参照。 注意: アプリケーションで、失われたメッセージや重複メッセージを処理できない場合は、このモードは使用しないでください。重複メッセージは、メッセージを配信する最初の試行が失敗した場合に送信されます。 |
トランザクション セッションでは、一度に 1 つのトランザクションしかアクティブになりません。トランザクション時に送信または受信されたメッセージは、最小の単位として処理されます。
トランザクション セッションを作成すると、確認応答モードは無視されます。アプリケーションでトランザクションがコミットされると、そのトランザクションの間にアプリケーションで受信されたすべてのメッセージがメッセージング システムによって確認応答され、アプリケーションで送信されたメッセージは配信されるべく受け入れられます。アプリケーションでトランザクションがロールバックされると、そのトランザクションの間にアプリケーションで受信されたメッセージは確認応答されず、アプリケーションで送信されたメッセージは破棄されます。
JMS は、Java Transaction API (JTA) を使用する他の Java サービス (EJB など) との分散トランザクションに参加できます。トランザクションはそのトランザクションに関連付けられたメッセージへのアクセスが制限されているため、トランザクション セッションではこの機能をサポートしません。JTA の利用の詳細については、JTA ユーザ トランザクションの使い方を参照してください。
Destination オブジェクトはキューまたはトピックになり、特定プロバイダのアドレス構文をカプセル化します。プロバイダによって構文はさまざまであるため、JMS 仕様では標準のアドレス構文は定義されていません。
接続ファクトリの場合と同じように、管理者が送り先を定義し、コンフィグレーションすると、WebLogic Server の起動時にそれが JNDI スペースに追加されます。また、アプリケーションでは、それが作成された JMS 接続の間だけ存在する一時的な送り先を作成することもできます。
注意: 管理者は、サーバのクラスタ内の単一の分散送り先セットのメンバーとして、複数の物理的な送り先をコンフィグレーションすることもできます。詳細については、送り先の分散を参照してください。
クライアントサイドでは、Queue オブジェクトと Topic オブジェクトは、サーバ上のオブジェクトへのハンドルとして機能します。それらのメソッドでは、それらの名前が返されるだけです。メッセージングを目的としてアクセスするには、それらにアタッチするメッセージ プロデューサとメッセージ コンシューマを作成します。
送り先では同時使用がサポートされており、複数のスレッドがオブジェクトに同時にアクセスできます。JMS の Queue と Topic は、javax.jms.Destination を拡張します。次の表は、Destination のサブクラスを説明しています。
|
JMS PTP プロバイダのメッセージ。メッセージが作成された JMS 接続の間だけ存在する。一時的なキューはそれを作成したキュー接続によってのみ消費される。 |
||
|
JMS PTP プロバイダのメッセージ。メッセージが作成された JMS 接続の間だけ存在する。一時的なトピックはそれを作成したトピック接続によってのみ消費される。 |
注意: アプリケーションでは、キュー セッションで QueueBrowser オブジェクトを作成することによりキューを参照することができます。このオブジェクトでは、キュー ブラウザが作成された時点におけるキュー内のメッセージのスナップショットが生成されます。アプリケーションではキュー内のメッセージを表示できますが、メッセージは「読み込まれた」とは判断されず、したがってキューから削除されることはありません。キューの参照の詳細については、メッセージ ヘッダ フィールドおよびメッセージ プロパティ フィールドの参照を参照してください。
アプリケーションで Destination クラスを使用する方法については、WebLogic JMS アプリケーションの開発または javax.jms.Destination Javadoc を参照してください。
管理者は、WebLogic Server のクラスタ内の単一の分散送り先セットのメンバーとして、複数の物理的な送り先をコンフィグレーションすることができます。適切に構成すると、プロデューサとコンシューマがその分散送り先に対して送受信できるようになります。WebLogic JMS は、分散送り先内で利用可能な全送り先メンバーにメッセージの負荷を分散します。
MessageProducer と MessageConsumer
MessageProducer オブジェクトでは、メッセージがキューまたはトピックに送信されます。MessageConsumer オブジェクトでは、メッセージがキューまたはトピックから受信されます。メッセージ プロデューサとメッセージ コンシューマは、互いに独立して機能します。メッセージ コンシューマが作成されてメッセージを待っているかどうかに関係なく、メッセージ プロデューサではメッセージが生成および送信されます (この逆も同じ)。
Session では、キューおよびトピックにアタッチされる MessageProducer と MessageConsumer が作成されます。
メッセージ センダ オブジェクトとメッセージ レシーバ オブジェクトは、MessageProducer クラスおよび MessageConsumer クラスのサブクラスとして作成されます。次の表は、MessageProducer と MessageConsumer のサブクラスを説明しています。
|
JMS Pub/sub プロバイダのメッセージを受信し、メッセージの作成された JMS 接続が閉じるまで存続する。メッセージの送り先は、適切な JNDI インタフェースを使用して明示的にバインドしなければならない。 |
ポイント ツー ポイント (PTP) メッセージングの図で示されているように、PTP モデルでは複数のセッションが同じキューからメッセージを受信できます。ただし、メッセージは、1 つのキュー レシーバにしか配信できません。複数のキュー レシーバがある場合、次にメッセージを受信するキュー レシーバは先着順で決まります。
パブリッシュ/サブスクライブ (Pub/sub) メッセージングの図で示されているように、Pub/sub モデルではメッセージを複数のトピック サブスクライバに配信できます。トピック サブスクライバは、恒久サブスクリプションの設定で説明されているように恒久にも非恒久にもなります。
アプリケーションでは、1 つのトピックのパブリッシュとサブスクライブに同じ JMS 接続を使用できます。トピック メッセージはすべてのサブスクライバに配信されるので、アプリケーションは自身がパブリッシュしたメッセージを受信する可能性があります。メッセージがパブリッシュ元のクライアントで受信されるのを防ぐために、JMS アプリケーションではトピック サブスクライバに対して noLocal 属性を設定できます。詳細については、手順 5 :セッションと送り先を使用してメッセージ プロデューサとメッセージ コンシューマを作成するを参照してください。
アプリケーションで MessageProducer クラスと MessageConsumer クラスを使用する方法については、JMS アプリケーションの設定、または javax.jms.MessageProducer Javadoc および javax.jms.MessageConsumer Javadoc を参照してください。
Message オブジェクトでは、アプリケーション間で交換される情報がカプセル化されます。この情報は、標準ヘッダ フィールド、アプリケーション固有のプロパティ、およびメッセージ本文という 3 つの要素で構成されます。以降の節では、これらの構成要素について説明します。
すべての JMS メッセージには、デフォルトで挿入され、メッセージ コンシューマで利用できる標準のヘッダ フィールドがあります。一部のフィールドは、メッセージ プロデューサで設定できます。
メッセージ ヘッダ フィールドの設定については、メッセージ ヘッダ フィールドおよびメッセージ プロパティ フィールドの設定と参照または javax.jms.Message Javadoc を参照してください。
次の表は、メッセージ ヘッダのフィールドを説明し、各フィールドで値がどのように定義されるのかを示しています。
|
WebLogic JMSMessageID (この表内で後述)、アプリケーション固有の文字列、または byte[] 配列のいずれかを指定する。JMSCorrelationID はメッセージを相互に関連させるために使用する。 最初の用途は、次のような要求と応答の方式を設定してメッセージをリンクすること。 2 番目の用途は、選択した文字列を JMSCorrelationID フィールドに格納し、一連のメッセージをアプリケーション指定の値でリンクできるようにすること。 すべての JMSMessageID は ID: というプレフィックスで始まる。他のアプリケーション固有の文字列で JMSCorrelationID を使用する場合は、文字列の先頭にプレフィクス ID: が付いてはならない。 |
||
|
PERSISTENT または NON_PERSISTENT を指定する。 永続的なメッセージが送信された場合、そのメッセージは JMS ファイルまたは JDBC データベースに格納される。send() 処理は、メッセージの配信を保証できるまで成功とは判断されない。永続的なメッセージは少なくとも 1 回は確実に配信される。 非永続的メッセージは JMS データベースに格納されない。このモードでは、処理のオーバーヘッドが最小限に抑えられる。メッセージは最低 1 回は配信が保証されるが、システム障害が発生すると失われる場合がある。接続を閉じるか回復すると、確認応答されていないすべての非永続的メッセージが再配信される。非永続的メッセージは確認応答されると再配信されない。 メッセージが送信されるときには、この値は無視される。メッセージが受信されるときには、送信側のメソッドで指定された配信モードが格納されている。 |
||
|
メッセージをコンシューマに配信できる最も早い絶対時間を定義する。このフィールドは、送り先でのメッセージのソート、またはメッセージの選択に使用できる。データ型変換の目的で、JMSDeliveryTime は 長整数として保存される。 |
||
|
メッセージが配信される送り先 (キューまたはトピック) を指定する。このフィールドの値は、メッセージの送信時にアプリケーションのメッセージ プロデューサで設定される。 メッセージが送信されるときには、この値は無視される。メッセージが受信されるとき、その送り先の値は送信時に割り当てられた値と同じでなければならない。 |
||
|
JMSExpiration の値は、アプリケーションの存続時間とその時点の GMT の合計として算出される。アプリケーションで存続時間が 0 として指定されると、JMSExpiration は 0 に設定され、メッセージは無期限になる。 |
||
|
JMS プロバイダによって送信される各メッセージをユニークに識別する文字列値を格納する。 すべての JMSMessageID は ID: というプレフィックスで始まる。 メッセージが送信されるときには、この値は無視される。メッセージが受信されるときには、プロバイダの割り当てた値が格納されている。 |
||
|
優先順位のレベルを指定する。このフィールドはメッセージが送信される前に設定される。 JMS では、0 〜 9 の 10 段階で優先順位が定義されている (0 が最低の優先順位)。レベル 0 〜 4 は通常の範囲に属し、レベル 5 〜 9 は至急の範囲に属する。 メッセージが受信されるときには、メッセージを送信するメソッドで指定された値が格納されている。 送り先キーをコンフィグレーションすれば、優先順位を基準に送り先をソートすることができる。詳細については、『管理者ガイド』の「JMS の管理」を参照。 |
||
|
確認応答がないためメッセージが再配信されるときに設定されるフラグを指定する。このフラグは受信側アプリケーションのみに関係がある。 フラグが設定されている場合は、以下のいずれかの理由のために、同じメッセージが以前に配信されている可能性がある。
|
||
|
応答メッセージが送信されるキューまたはトピックを指定する。このフィールドはメッセージの送信前に送信側アプリケーションで設定される。 この機能は JMSCorrelationID ヘッダ フィールドと共に使用して要求と応答のメッセージを連係させることができる。 JMSReplyTo フィールドをただ設定するだけでは応答は保証されない。受信側アプリケーションに応答させるには、そのように選択する必要がある。 JMSReplyTo は NULL に設定することもできる。それは、受信側アプリケーションにとって通知イベントなどの意味を持つ場合がある。 |
||
|
メッセージが送信されたときの時刻を格納する。タイムスタンプは、アプリケーションでメッセージが送信されたときではなく、WebLogic JMS で配信用にメッセージが受け付けられたときにメッセージに書き込まれる。 |
||
|
送信側アプリケーションで設定されたメッセージ タイプ識別子 (String) を示す。 JMS 仕様では、多様な JMS プロバイダに適応するため、このフィールドに若干の柔軟性を持たせている。一部のメッセージング システムでは、アプリケーション固有のメッセージ タイプを使用できる。そのようなシステムの場合、JMSType フィールドは、格納されている型定義にアクセスするためのメッセージ タイプ ID を保持するために使用できる。 |
メッセージのプロパティ フィールドには、送信側アプリケーションによって追加されたヘッダ フィールドが格納されます。プロパティは、標準的な Java の名前と値の組み合わせです。プロパティ名は、javax.jms.Message Javadoc で定義されているメッセージ セレクタの構文仕様に準拠していなければなりません。有効な値は、boolean、byte、double、float、int、long、および String です。
メッセージ プロパティ フィールドは、アプリケーション固有の目的に使用できますが、それらは基本的にはメッセージ セレクタで使用するために用意されています。メッセージ セレクタの詳細については、メッセージのフィルタ処理を参照してください。
メッセージ プロパティ フィールドの設定については、メッセージ ヘッダ フィールドおよびメッセージ プロパティ フィールドの設定と参照または javax.jms.Message Javadoc を参照してください。
メッセージ本文は、プロデューサからコンシューマに配信される内容です。
次の表は、JMS で定義されているメッセージ タイプを説明しています。すべてのメッセージ タイプは、メッセージ ヘッダとメッセージ プロパティ (メッセージ本文はなし) で構成される javax.jms.Message を拡張します。
詳細については、javax.jms.Message Javadoc を参照してください。特定のメッセージ タイプのアクセス メソッドや変換表については、そのメッセージ タイプの Javadoc を参照してください。
サーバ セッション プールは、メッセージの並行処理を実現する WebLogic 固有の JMS 機能です。サーバ セッション プール ファクトリは、サーバサイドの ServerSessionPool を作成するために使用します。
WebLogic JMS では、デフォルトで次のような ServerSessionPoolFactory オブジェクトが定義されています。weblogic.jms.ServerSessionPoolFactory:<name>。ここで <name> には、セッション プールの作成先になる JMS サーバの名前を指定します。WebLogic Server ではデフォルトのサーバ セッション プール ファクトリが起動時に JNDI スペースに追加され、アプリケーションでは WebLogic JNDI を使用してサーバ セッション プール ファクトリが取り出されます。
アプリケーションでサーバ セッション プール ファクトリを使用する方法については、サーバ セッション プールの定義または weblogic.jms.ServerSessionPoolFactory Javadoc を参照してください。
ServerSessionPool アプリケーション サーバ オブジェクトでは、メッセージを並行処理するために接続コンシューマで取り出すことができるサーバ セッションのプールが提供されます。
ServerSessionPool は、JNDI ルックアップで取得される ServerSessionPoolFactory オブジェクトによって作成されます。
アプリケーションでサーバ セッション プールを使用する方法については、サーバ セッション プールの定義または javax.jms.ServerSessionPool Javadoc を参照してください。
ServerSession アプリケーション サーバ オブジェクトでは、メッセージを作成、送信、および受信するためのコンテキストが提供され、スレッドと JMS セッションを関連付けることができます。
ServerSession は、ServerSessionPool オブジェクトによって作成されます。
アプリケーションでサーバ セッションを使用する方法については、サーバ セッション プールの定義または avax.jms.ServerSession Javadoc を参照してください。
ConnectionConsumer オブジェクトでは、サーバ セッションを使用して受信メッセージを処理します。メッセージ トラフィックが大きい場合は、スレッド コンテキストの切り替えを最小限に抑えるために、接続コンシューマでは複数のメッセージで各サーバ セッションをロードすることができます。
ConnectionConsumer は、Connection オブジェクトによって作成されます。
アプリケーションで接続コンシューマを使用する方法については、サーバ セッション プールの定義または
javax.jms.ConnectionConsumer Javadoc を参照してください。
注意: 接続コンシューマ リスナは、サーバと同じ JVM で動作します。
|
|
|
|
||
 |
|
|
 |
 |
 |
|
||
