|
|
以下の節では、Java Message Service (JMS) のさまざまな概念と機能を簡単に紹介し、それらと他のアプリケーション オブジェクトおよび WebLogic Server との連携の仕組みについて説明します。
この章は、Java のプログラミングおよび JMS 1.1 の概念と機能に精通している読者を対象としています。
WebLogic JMS は、WebLogic Server プラットフォームに緊密に統合されたエンタープライズ クラスのメッセージング システムです。JMS 仕様を完全にサポートし、標準の JMS API ではサポートされていないさまざまな WebLogic JMS 拡張を提供します。
エンタープライズ メッセージング システムを使用すると、複数のアプリケーションがメッセージの交換を通じて通信できます。メッセージとは、異なるアプリケーション間の通信を調整するために必要な情報が含まれているリクエスト、レポート、またはイベントのことです。メッセージで提供される抽象化の階層により、送り先システムについての詳細情報をアプリケーション コードから切り離すことができます。
Java Message Service (JMS) は、エンタープライズ メッセージング システムにアクセスするための標準の API です。具体的な JMS の特長は以下のとおりです。
次の図は、WebLogic JMS メッセージングの仕組みを示しています。
上の図に示すとおり、WebLogic JMS はプロデューサ アプリケーションからメッセージを受信し、それらをコンシューマ アプリケーションに送信します。
WebLogic Server は次の Java 仕様に準拠しています。
WebLogic Server は Sun Microsystems の J2EE 1.4 仕様に準拠しています。
WebLogic Server は JMS 1.1 仕様に完全に準拠しており、プロダクション環境で使用できます。
次の図は、WebLogic JMS のアーキテクチャを示しています。
図 2-2 に示されているように、WebLogic JMS Server のアーキテクチャは主に以下の要素で構成されています。
weblogic-jmsmd.xsd スキーマに準拠する XML ドキュメントによって定義される JMS モジュール
JMS では、ポイント ツー ポイント (PTP) とパブリッシュ/サブスクライブ (pub/sub) の 2 つのメッセージング モデルがサポートされています。それらのメッセージング モデルは非常に似ていますが、以下の点で異なります。
各モデルは、共通の基本クラスを拡張したクラスで実装されます。たとえば、PTP クラス javax.jms.Queue と pub/sub クラス javax.jms.Topic は、ともに javax.jms.Destination クラスを拡張します。
各メッセージング モデルについては、以降の節で詳しく説明します。
| 注意 : | プロデューサおよびコンシューマという用語は、メッセージング モデルに関係なく、それぞれメッセージを送信および受信するアプリケーションを表すために汎用的に使用します。ただし、各メッセージング モデルでは、それぞれに固有のユニークな用語でプロデューサとコンシューマを表します。 |
ポイント ツー ポイント (PTP) メッセージング モデルでは、アプリケーションが別の 1 つのアプリケーションにメッセージを送信できます。PTP メッセージング アプリケーションでは、名前付きのキューを使用してメッセージが送信および受信されます。メッセージは、キュー センダ (プロデューサ) によって特定のキューに送信されます。キュー レシーバ (コンシューマ) では、特定のキューからメッセージを受信します。
複数のキュー センダおよびキュー レシーバを 1 つのキューに関連付けることができますが、個々のメッセージは 1 つのキュー レシーバにしか配信できません。
複数のキュー レシーバがキューのメッセージをリスンしている場合、次のメッセージを受信するキュー レシーバは先着順で決定されます。リスンしているキュー レシーバがない場合は、キュー レシーバがキューにアタッチされるまでメッセージはキューにとどまります。
パブリッシュ/サブスクライブ (pub/sub) メッセージング モデルでは、アプリケーションが複数のアプリケーションにメッセージを送信できます。pub/sub メッセージング アプリケーションでは、トピックをサブスクライブすることでメッセージが送信および受信されます。トピック パブリッシャ (プロデューサ) によって、特定のトピックにメッセージが送信されます。トピック サブスクライバ (コンシューマ) では、特定のトピックからメッセージが受信されます。
次の図は、pub/sub メッセージングの仕組みを示しています。
PTP メッセージング モデルの場合と違って、pub/sub メッセージング モデルでは複数のトピック サブスクライバが同じメッセージを受信できます。メッセージは、すべてのトピック サブスクライバが受信するまで維持されます。
pub/sub メッセージング モデルでは恒久サブスクライバがサポートされるので、トピック サブスクライバに名前を割り当て、ユーザまたはアプリケーションと関連付けることができます。恒久サブスクライバの詳細については、「恒久サブスクリプションの設定」を参照してください。
JMS 仕様の「Message Delivery Mode」の節に従って、メッセージを永続的または非永続的として指定できます。
システム レベルの WebLogic 永続ストアの詳細については、「WebLogic 永続ストアの使い方」を参照してください。
WebLogic JMS は WebLogic Server プラットフォームと密接に統合されているため、非常にセキュアな J2EE アプリケーションを構築して、WebLogic Server コンソールで簡単にモニタしたり管理したりできます。XA トランザクションが完全にサポートされているだけでなく、クラスタ機能とサービス移行機能による高い可用性を特長としています。加えて、他のバージョンの WebLogic Server やサードパーティのメッセージ プロバイダとのシームレスな相互運用性も提供されます。
これらの付加価値機能の詳細については、『WebLogic JMS のコンフィグレーションと管理』の「WebLogic Server の付加価値 JMS 機能」を参照してください。
WebLogic Server には、JMS 仕様で指定されている標準 JMS API に加え、次の表で説明するクラスやメソッドを含むさまざまな weblogic.jms.extensions API が用意されています。
|
|
|||
|
この API では、NO_ACKNOWLEDGE と MULTICAST_NO_ACKNOWLEDGE の確認応答モード、および以下のような例外の送出を含む拡張例外もサポートされています。
JMS アプリケーションを作成するには、javax.jms API を使用します。この API では、JMS への接続やメッセージの送受信に必要なクラス オブジェクトを作成できます。JMS クラス インタフェースは、共通の親クラスのキュー バージョンとトピック バージョンを提供するサブクラスとして作成されます。
次の表は、以降の節で詳しく説明する JMS クラスを示しています。すべての JMS クラスの詳細については、javax.jms または weblogic.jms.extensions の Javadoc を参照してください。
|
JMS リソースのコンフィグレーションについては、『WebLogic JMS のコンフィグレーションと管理』の「基本 JMS システム リソースのコンフィグレーション」を参照してください。JMS アプリケーションを設定する手順については、「JMS アプリケーションの設定」を参照してください。
ConnectionFactory は、接続のコンフィグレーション情報をカプセル化し、JMS アプリケーションが Connection を作成できるようにします。接続ファクトリでは同時使用がサポートされており、複数のスレッドがオブジェクトに同時にアクセスできます。WebLogic JMS が提供するあらかじめコンフィグレーションされたデフォルト接続ファクトリを使用するか、1 つまたは複数の接続ファクトリをコンフィグレーションすることで、アプリケーションに適したあらかじめ定義された属性で接続を作成できます。
WebLogic JMS では 2 つのデフォルト接続ファクトリが定義されています。これらの接続ファクトリは、次の JNDI 名を使用してルックアップできます。
ユーザ定義の接続ファクトリは、デフォルト ファクトリの設定がアプリケーションに適さない場合にのみ作成します。デフォルト接続ファクトリのコンフィグレーション済み設定との主な違いは、次の表に示すように、JTA トランザクションを有効にするために使用する [XA コネクション ファクトリを有効化] 属性のデフォルト値です。
XA ファクトリは、JMS アプリケーションで JTA ユーザ トランザクションを使用する場合に必要となりますが、トランザクション セッションの場合は必要ありません。WebLogic JMS でのトランザクションの使用については、「WebLogic JMS によるトランザクションの使い方」を参照してください。
その他のすべてのデフォルト コンフィグレーション属性は、ユーザ定義の接続ファクトリと同じデフォルト値に設定されます。
[XA コネクション ファクトリを有効化] 属性と、その他の接続ファクトリ属性のデフォルト値については、Administration Console オンライン ヘルプの「JMS 接続ファクトリ : コンフィグレーション : トランザクション」を参照してください。
デフォルトの接続ファクトリを使用する場合のもう 1 つの違いは、接続ファクトリがデプロイされる可能性のある WebLogic Server を限定できない点です。ただし、デフォルトの接続ファクトリはサーバ単位で無効にできます。
デフォルト接続ファクトリの有効化または無効化については、Administration Console オンライン ヘルプの「サーバ : コンフィグレーション : サービス」を参照してください。
特定の独立したサーバ、クラスタ内の特定のサーバ、またはクラスタ全体に接続ファクトリをデプロイするには、新しい接続ファクトリを作成し、適切な対象を指定する必要があります (「接続ファクトリのコンフィグレーションとデプロイメント」を参照)。
| 注意 : | 下位互換性を維持するため、WebLogic JMS では非推奨の 2 つのデフォルト接続ファクトリを現在もサポートしています。該当するファクトリの JNDI 名は次のとおりです。javax.jms.QueueConnectionFactory および javax.jms.TopicConnectionFactory。 |
システム管理者が 1 つまたは複数の接続ファクトリを定義およびコンフィグレーションして、あらかじめ定義された属性で接続を作成すると、WebLogic Server では起動時にそれらの接続ファクトリが JNDI スペースに追加されます。アプリケーションでは、WebLogic JNDI を使用して接続ファクトリを取り出します。ユーザ定義の接続ファクトリにはユニークな名前を付ける必要があります。
接続ファクトリのコンフィグレーションについては、Administration Console オンライン ヘルプの「接続ファクトリのコンフィグレーション」を参照してください。
システム管理者は、クラスタに対象指定するか、クラスタ内の 1 つまたは複数のサーバ インスタンスに対象指定することで、クラスタ内のあらゆるサーバから JMS 送り先への透過的なアクセスをクラスタ全体にわたって確立します。これにより、各接続ファクトリを複数の WebLogic Server インスタンスにデプロイできます。JMS のクラスタ化の詳細については、『WebLogic JMS のコンフィグレーションと管理』の「拡張 JMS システム リソースのコンフィグレーション」を参照してください。
ConnectionFactory クラスではメソッドは定義されませんが、そのサブクラスでは各メッセージング モデルのメソッドが定義されます。接続ファクトリでは同時使用がサポートされており、複数のスレッドがオブジェクトに同時にアクセスできます。
| 注意 : | このリリースでは、JMS 1.1 仕様の接続ファクトリを使用できます。または、そのサブクラスを使用することもできます。 |
次の表は、ConnectionFactory のサブクラスを説明しています。
アプリケーションで ConnectionFactory クラスを使用する方法については、「基本的な JMS アプリケーションの開発」または javax.jms.ConnectionFactory Javadoc を参照してください。
Connection は、アプリケーションとメッセージング システムの間の開いている通信チャネルを表し、メッセージを生成および消費するための Session を作成するために使用します。接続では、アプリケーションと JMS の間のメッセージングを管理するサーバサイドとクライアントサイドのオブジェクトが作成されます。接続では、ユーザの認証も提供されます。
Connection は、JNDI ルックアップを通じて取得する ConnectionFactory によって作成されます。
ユーザの認証や通信の設定に関わるリソースのオーバーヘッドがあるため、ほとんどのアプリケーションではすべてのメッセージングで 1 つの接続を確立します。WebLogic Server では、JMS トラフィックはサーバとのクライアント接続で他の WebLogic サービスと多重化されます。JMS のために、新たな TCP/IP 接続が作成されることはありません。サーブレットや他のサーバサイド オブジェクトもまた、JMS Connection を使用する場合があります。
デフォルトでは、接続は停止モードで作成されます。停止している接続を開始する方法とタイミングについては、「接続の開始、停止、クローズ」を参照してください。
接続では同時使用がサポートされており、複数のスレッドがオブジェクトに同時にアクセスできます。
| 注意 : | このリリースでは、JMS 1.1 仕様の connection オブジェクトを使用できます。または、そのサブクラスを使用することもできます。 |
次の表は、Connection のサブクラスを説明しています。
アプリケーションで Connection クラスを使用する方法については、「基本的な JMS アプリケーションの開発」または javax.jms.Connection Javadoc を参照してください。
Session オブジェクトでは、生成および消費されるメッセージの順序を定義し、複数のメッセージ プロデューサとメッセージ コンシューマを作成できます。メッセージの生成と消費には同じスレッドを使用できます。アプリケーションでメッセージの生成と消費に別々のスレッドが必要な場合は、そのアプリケーションで機能ごとに個別のセッションを作成する必要があります。
Session は、Connection で作成されます。
JMS 1.1 仕様では、汎用セッションであらゆる型の Destination オブジェクトの MessageConsumer を使用することが許可されています。しかし、WebLogic JMS では、単一のセッションで QueueConsumer 型と TopicSubscriber 型の MessageConsumer を一緒に使用することはできません。また、単一のセッションで複数のコンシューマを使用するのは、あまり一般的ではありません。以下の一般的な使用方法がサポートされています。
| 警告 : | セッションおよびそのメッセージのプロデューサとコンシューマには、一度に 1 つのスレッドしかアクセスできません。それらに複数のスレッドが同時にアクセスした場合、それらの動作は定義されません。 |
アプリケーションで Session クラスを使用する方法については、「基本的な JMS アプリケーションの開発」、または javax.jms.Session Javadoc および weblogic.jms.extensions.WLSession Javadoc を参照してください。
非トランザクション セッションでは、セッションを作成するアプリケーションで、次の表で定義されている 5 つの確認応答モードのいずれかが選択されます。
Session オブジェクトの動作は、アプリケーションによる確認応答メソッドの呼び出しに依存する。メソッドが呼び出されると、セッションでは、前回の確認応答以降に受信されたすべてのメッセージに対して確認応答が行われる。
|
|||
|
|||
NO_ACKNOWLEDGE セッションに送信されたメッセージは、サーバから即座に削除される。このモードで受信されたメッセージは回復されないので、メッセージを配信する最初の試行が失敗した場合はメッセージが失われたり、重複メッセージが配信されたりする。
|
|||
|
トランザクション セッションでは、一度に 1 つのトランザクションしかアクティブになりません。トランザクション中に送信または受信されたメッセージ数に関係なく、最小の単位として処理されます。
トランザクション セッションを作成すると、確認応答モードは無視されます。アプリケーションでトランザクションがコミットされると、そのトランザクションの間にアプリケーションで受信されたすべてのメッセージがメッセージング システムによって確認応答され、アプリケーションで送信されたメッセージは配信されるべく受け入れられます。アプリケーションでトランザクションがロールバックされると、そのトランザクションの間にアプリケーションで受信されたメッセージは確認応答されず、アプリケーションで送信されたメッセージは破棄されます。
JMS は、Java Transaction API (JTA) を使用する他の Java サービス (EJB など) との分散トランザクションに参加できます。トランザクションはそのトランザクションに関連付けられたメッセージへのアクセスが制限されているため、トランザクション セッションではこの機能をサポートしません。JTA の利用の詳細については、「JTA ユーザ トランザクションの使い方」を参照してください。
Destination オブジェクトはキューまたはトピックになり、特定プロバイダのアドレス構文をカプセル化します。プロバイダによって構文はさまざまであるため、JMS 仕様では標準のアドレス構文は定義されていません。
接続ファクトリの場合と同じように、管理者が送り先を定義し、コンフィグレーションすると、WebLogic Server の起動時にそれが JNDI スペースに追加されます。また、アプリケーションでは、それが作成された JMS 接続の間だけ存在する一時的な送り先を作成することもできます。
| 注意 : | 管理者は、分散送り先をコンフィグレーションすることもできます。分散送り先は、単一の論理的な送り先としてクライアントからアクセス可能な 1 つの送り先セット (キューまたはトピック) です。詳細については、「送り先の分散」を参照してください。 |
クライアントサイドでは、Queue オブジェクトと Topic オブジェクトは、サーバ上のオブジェクトへのハンドルとして機能します。それらのメソッドは、それらの名前のみを返します。メッセージングを目的としてアクセスするには、それらにアタッチするメッセージ プロデューサとメッセージ コンシューマを作成します。
送り先では同時使用がサポートされており、複数のスレッドがオブジェクトに同時にアクセスできます。JMS の Queues と Topic は、javax.jms.Destination を拡張します。
| 注意 : | このリリースでは、JMS 1.1 仕様の destination オブジェクトを使用できます。または、そのサブクラスを使用することもできます。 |
次の表は、Destination のサブクラスを説明しています。
| 注意 : | アプリケーションでは、キュー セッションで QueueBrowser オブジェクトを作成することによりキューを参照することができます。このオブジェクトでは、キュー ブラウザが作成された時点におけるキュー内のメッセージのスナップショットが生成されます。アプリケーションではキュー内のメッセージを表示できますが、メッセージは「読み込まれた」とは判断されず、したがってキューから削除されることはありません。キューの参照の詳細については、「メッセージ ヘッダ フィールドおよびメッセージ プロパティ フィールドの設定と参照」を参照してください。 |
アプリケーションで Destination クラスを使用する方法については、「基本的な JMS アプリケーションの開発」または javax.jms.Destination Javadoc を参照してください。
分散送り先リソースは、単一の論理的な送り先としてクライアントからアクセス可能な 1 つの送り先セット (キューまたはトピック) です (たとえば分散トピックは独自の JNDI 名を持ちます)。このセットのメンバーは通常、クラスタ内の複数のサーバに分散されており、各メンバーは別々の JMS サーバに属しています。分散送り先を使用するアプリケーションは、スタンドアロンの送り先を使用するアプリケーションより可用性が高くなります。これは、WebLogic JMS に、クラスタ内の分散送り先メンバーのためのロード バランシングおよびフェイルオーバ機能があるためです。
MessageProducer では、メッセージがキューまたはトピックに送信されます。MessageConsumer では、メッセージがキューまたはトピックから受信されます。メッセージ プロデューサとメッセージ コンシューマは、互いに独立して機能します。メッセージ コンシューマが作成されてメッセージを待っているかどうかに関係なく、メッセージ プロデューサではメッセージが生成および送信されます (この逆も同様)。
Session では、キューおよびトピックにアタッチされる MessageProducers と MessageConsumers が作成されます。
メッセージ センダ オブジェクトとメッセージ レシーバ オブジェクトは、MessageProducer クラスおよび MessageConsumer クラスのサブクラスとして作成されます。
| 注意 : | このリリースでは、JMS 1.1 仕様の MessageProducer および MessageConsumer オブジェクトを使用できます。または、そのサブクラスを使用することもできます。 |
次の表は、MessageProducer と MessageConsumer のサブクラスを説明しています。
ポイント ツー ポイント (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 を参照してください。
次の表は、メッセージ ヘッダのフィールドを説明し、各フィールドで値がどのように定義されるのかを示しています。
JMSMessageID (この表内で後述)、アプリケーション固有の文字列、または byte[] 配列のいずれかを指定する。JMSCorrelationID はメッセージを相関させるために使用する。send() の前に、アプリケーションによってメッセージに直接設定される。
|
||
PERSISTENT または NON_PERSISTENT を指定する。このフィールドは、プロデューサに設定されるか、send() の前にアプリケーションによって送信されるパラメータとして設定される。
send() 処理は、メッセージの配信を保証できるまで成功とは判断されない。永続的なメッセージは少なくとも 1 回は確実に配信される。
|
||
send() の前にアプリケーションによって設定される。プロデューサに設定されるか、アプリケーションが send() に送信するパラメータとして設定される timeToLive に依存する。
|
||
|
|
||
|
||
メッセージのプロパティ フィールドには、送信側アプリケーションによって追加されたヘッダ フィールドが格納されます。プロパティは、標準的な Java の名前と値の組み合わせです。プロパティ名は、javax.jms.Message Javadoc で定義されているメッセージ セレクタの構文仕様に準拠していなければなりません。有効な値は、boolean、byte、double、float、int、long、および String です。
WebLogic Server では、JMS 1.1.仕様での定義に従って、以下の JMS (JMSX) 定義済みプロパティの使用をサポートしています。
メッセージ プロパティ フィールドは、アプリケーション固有の目的に使用できますが、それらは基本的にはメッセージ セレクタで使用するために用意されています。JMS プロパティをそれぞれの環境でどのように使用するかはユーザが決定します。たとえば、処理条件に応じて一部のメッセージにだけ含め、その他のメッセージでは省略することもできます。詳細については以下を参照してください。
メッセージ本文は、プロデューサからコンシューマに配信される内容です。
次の表は、JMS で定義されているメッセージ タイプを説明しています。すべてのメッセージ タイプは、メッセージ ヘッダとメッセージ プロパティ (メッセージ本文はなし) で構成される javax.jms.Message を拡張します。
詳細については、javax.jms.Message Javadoc を参照してください。特定のメッセージ タイプのアクセス メソッドや変換表については、そのメッセージ タイプの Javadoc を参照してください。
| 注意 : | セッション プールおよび接続コンシューマのコンフィグレーション オブジェクトは、WebLogic Server の本リリースでは非推奨となっています。これらは、J2EE 仕様の必須コンポーネントではなく、JTA ユーザ トランザクションもサポートしていないためです。代わりに、より単純で可用性が高く、管理も容易なメッセージ駆動型 Bean (MDB) が主に使用されています。MDB の設計の詳細については、『WebLogic エンタープライズ JavaBeans (EJB) プログラマーズ ガイド』の「メッセージ駆動型 EJB」を参照してください。 |
サーバ セッション プールは、メッセージの並行処理を実現する WebLogic 固有の JMS 機能です。サーバ セッション プール ファクトリは、サーバサイドの ServerSessionPool を作成するために使用します。
WebLogic JMS では、デフォルトで次のような ServerSessionPoolFactory オブジェクトが定義されています。weblogic.jms.extensions.ServerSessionPoolFactory:<name>。ここで <name> には、セッション プールの作成先になる JMS サーバの名前を指定します。WebLogic Server ではデフォルトのサーバ セッション プール ファクトリが起動時に JNDI スペースに追加され、アプリケーションでは WebLogic JNDI を使用してサーバ セッション プール ファクトリが取り出されます。
アプリケーションでサーバ セッション プール ファクトリを使用する方法については、「サーバ セッション プールの定義」または weblogic.jms.extnesions.ServerSessionPoolFactory Javadoc を参照してください。
ServerSessionPool アプリケーション サーバ オブジェクトでは、メッセージを並行処理するために接続コンシューマで取り出すことができるサーバ セッションのプールが提供されます。
ServerSessionPool は、JNDI ルックアップで取得される ServerSessionPoolFactory オブジェクトによって作成されます。
アプリケーションでサーバ セッション プールを使用する方法については、「サーバ セッション プールの定義」または javax.jms.ServerSessionPool Javadoc を参照してください。
ServerSession アプリケーション サーバ オブジェクトでは、メッセージを作成、送信、および受信するためのコンテキストが提供され、スレッドと JMS セッションを関連付けることができます。
ServerSession は、ServerSessionPool オブジェクトによって作成されます。
アプリケーションでサーバ セッションを使用する方法については、「サーバ セッション プールの定義」または javax.jms.ServerSession Javadoc を参照してください。
ConnectionConsumer オブジェクトでは、サーバ セッションを使用して受信メッセージを処理します。メッセージ トラフィックが大きい場合は、スレッド コンテキストの切り替えを最小限に抑えるために、接続コンシューマでは複数のメッセージで各サーバ セッションをロードすることができます。
ConnectionConsumer は、Connection オブジェクトによって作成されます。
アプリケーションで接続コンシューマを使用する方法については、「サーバ セッション プールの定義」または javax.jms.ConnectionConsumer Javadoc を参照してください。
| 注意 : | 接続コンシューマ リスナは、サーバと同じ JVM で動作します。 |
  
|
