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 クラスの javax.jms.Queue と pub/sub クラスの javax.jms.Topic はどちらも javax.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 メッセージング モデルでは恒久サブスクライバがサポートされるので、トピック サブスクライバに名前を割り当て、ユーザまたはアプリケーションと関連付けることができます。恒久サブスクリプションの詳細については、「恒久サブスクリプションの設定」を参照してください。
JMS 仕様の「Message Delivery Mode」の節に従って、メッセージを永続的または非永続的として指定できます。
JMS アプリケーションを作成するには、javax.jms API を使用します。この API では、JMS への接続やメッセージの送受信に必要なクラス オブジェクトを作成できます。JMS クラス インタフェースは、共通の親クラスのキュー バージョンとトピック バージョンを提供するサブクラスとして作成されます。
次の表は、以降の節で詳しく説明する JMS クラスを示しています。すべての JMS クラスの詳細については、「javax.jms」または「weblogic.jms.extensions」Javadoc を参照してください。
JMS オブジェクトのコンフィグレーションについては、「WebLogic 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 に関する属性と Administration Console 画面のリファレンス」を参照してください。
デフォルトの接続ファクトリを使用する場合のもう 1 つの違いは、接続ファクトリがデプロイされる可能性のある WebLogic Server を限定できない点です。ただし、デフォルトの接続ファクトリはサーバ単位で無効にできます。デフォルト接続ファクトリの有効化または無効化については、Administration Console オンライン ヘルプの「[サーバ] --> [サービス] --> [JMS]」を参照してください。
特定の独立したサーバ、クラスタ内の特定のサーバ、またはクラスタ全体に接続ファクトリをデプロイするには、新しい接続ファクトリを作成し、適切な対象を指定する必要があります (「接続ファクトリのコンフィグレーションとデプロイメント」を参照)。
注意 : 下位互換性を維持するため、WebLogic JMS では非推奨の 2 つのデフォルト接続ファクトリを現在もサポートしています。該当するファクトリの JNDI 名は次のとおりです。javax.jms.QueueConnectionFactory および javax.jms.TopicConnectionFactory。非推奨の接続ファクトリから新しいデフォルトまたはユーザ定義の接続ファクトリへの移行については、「WebLogic JMS アプリケーションの移植」を参照してください。
システム管理者が 1 つまたは複数の接続ファクトリを定義およびコンフィグレーションして、あらかじめ定義された属性で接続を作成すると、WebLogic Server では起動時にそれらの接続ファクトリが JNDI スペースに追加されます。アプリケーションでは、WebLogic JNDI を使用して接続ファクトリを取り出します。ユーザ定義の接続ファクトリにはユニークな名前を付ける必要があります。そうしないとサーバは起動しません。接続ファクトリのコンフィグレーションの詳細については、Administration Console オンライン ヘルプの「JMS 接続ファクトリのタスク」を参照してください。
システム管理者は、クラスタ内の各サーバ インスタンスのデフォルト接続ファクトリを有効にするか、1 つまたは複数の接続ファクトリをコンフィグレーションしてクラスタ内の 1 つまたは複数のサーバ インスタンスを対象とすることで、クラスタ内のあらゆるサーバから JMS 送り先へのクラスタワイドで透過的なアクセスを確立できます。これにより、各接続ファクトリを複数の WebLogic Server インスタンスにデプロイできます。JMS クラスタ化の詳細については、「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 のサブクラスを説明しています。
|
|
||
|
|
アプリケーションで Connection クラスを使用する方法については、「WebLogic JMS アプリケーションの開発」または「javax.jms.Connection」Javadoc を参照してください。
Session オブジェクトでは、生成および消費されるメッセージの順序を定義し、複数のメッセージ プロデューサとメッセージ コンシューマを作成できます。メッセージの生成と消費に同じスレッドを使用できます。アプリケーションでメッセージの生成と消費に別々のスレッドが必要な場合は、そのアプリケーションで機能ごとに個別のセッションを作成する必要があります。
Session は、Connection オブジェクトで作成されます。
注意 : セッションおよびそのメッセージのプロデューサとコンシューマには、一度に 1 つのスレッドしかアクセスできません。それらに複数のスレッドが同時にアクセスした場合、それらの動作は不明確になります。
アプリケーションで Session クラスを使用する方法については、「WebLogic JMS アプリケーションの開発」、または「javax.jms.Session」および「weblogic.jms.extensions.WLSession」Javadoc を参照してください。
非トランザクション セッションでは、セッションを作成するアプリケーションで、次の表で定義されている 5 つの確認応答モードのいずれかが選択されます。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
トランザクション セッションでは、一度に 1 つのトランザクションしかアクティブになりません。トランザクション時に送信または受信されたメッセージは、最小の単位として処理されます。
トランザクション セッションを作成すると、確認応答モードは無視されます。アプリケーションでトランザクションがコミットされると、そのトランザクションの間にアプリケーションで受信されたすべてのメッセージがメッセージング システムによって確認応答され、アプリケーションで送信されたメッセージは配信されるべく受け入れられます。アプリケーションでトランザクションがロールバックされると、そのトランザクションの間にアプリケーションで受信されたメッセージは確認応答されず、アプリケーションで送信されたメッセージは破棄されます。
JMS は、Java Transaction API (JTA) を使用する他の Java サービス (EJB など) との分散トランザクションに参加できます。トランザクションはそのトランザクションに関連付けられたメッセージへのアクセスが制限されているため、トランザクション セッションではこの機能をサポートしません。JTA の利用の詳細については、「JTA ユーザ トランザクションの使い方」を参照してください。
Destination オブジェクトはキューまたはトピックになり、特定プロバイダのアドレス構文をカプセル化します。プロバイダによって構文はさまざまであるため、JMS 仕様では標準のアドレス構文は定義されていません。
接続ファクトリの場合と同じように、管理者が送り先を定義し、コンフィグレーションすると、WebLogic Server の起動時にそれが JNDI スペースに追加されます。また、アプリケーションでは、それが作成された JMS 接続の間だけ存在する一時的な送り先を作成することもできます。
注意 : 管理者は、サーバのクラスタ内の単一の分散送り先セットのメンバーとして、複数の物理的な送り先をコンフィグレーションすることもできます。詳細については、「送り先の分散」を参照してください。
クライアントサイドでは、Queue オブジェクトと Topic オブジェクトは、サーバ上のオブジェクトへのハンドルとして機能します。それらのメソッドは、それらの名前のみを返します。メッセージングを目的としてアクセスするには、それらにアタッチするメッセージ プロデューサとメッセージ コンシューマを作成します。
送り先では同時使用がサポートされており、複数のスレッドがオブジェクトに同時にアクセスできます。JMS の Queues と Topics は、javax.jms.Destination を拡張します。次の表は、Destination のサブクラスを説明しています。
|
|
||
|
|
注意 : アプリケーションでは、キュー セッションで QueueBrowser オブジェクトを作成することによりキューを参照することができます。このオブジェクトでは、キュー ブラウザが作成された時点におけるキュー内のメッセージのスナップショットが生成されます。アプリケーションではキュー内のメッセージを表示できますが、メッセージは「読み込まれた」とは判断されず、したがってキューから削除されることはありません。キューの参照の詳細については、「メッセージ ヘッダ フィールドおよびメッセージ プロパティ フィールドの参照」を参照してください。
アプリケーションで Destination クラスを使用する方法については、「WebLogic JMS アプリケーションの開発」または「javax.jms.Destination」Javadoc を参照してください。
管理者は、WebLogic Server のクラスタ内の単一の分散送り先セットのメンバーとして、複数の物理的な送り先をコンフィグレーションすることができます。適切に構成すると、プロデューサとコンシューマがその分散送り先に対して送受信できるようになります。WebLogic JMS は、分散送り先内で利用可能な全送り先メンバーにメッセージの負荷を分散します。
MessageProducer オブジェクトでは、メッセージがキューまたはトピックに送信されます。MessageConsumer オブジェクトでは、メッセージがキューまたはトピックから受信されます。メッセージ プロデューサとメッセージ コンシューマは、互いに独立して機能します。メッセージ コンシューマが作成されてメッセージを待っているかどうかに関係なく、メッセージ プロデューサではメッセージが生成および送信されます (この逆も同様)。
Session オブジェクトでは、キューおよびトピックにアタッチされる MessageProducers と MessageConsumers が作成されます。
メッセージ センダ オブジェクトとメッセージ レシーバ オブジェクトは、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 を参照してください。
次の表は、メッセージ ヘッダのフィールドを説明し、各フィールドで値がどのように定義されるのかを示しています。
|
|
||
|
|
||
|
|
||
|
|
||
|
|
||
|
|
||
|
|
||
|
|
||
|
|
||
|
|
||
|
|
メッセージのプロパティ フィールドには、送信側アプリケーションによって追加されたヘッダ フィールドが格納されます。プロパティは、標準的な 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 を参照してください。
注意 : セッション プールは現在ほとんど使用されていません。理由は、J2EE 仕様の必須の部分ではないこと、JTA ユーザ トランザクションをサポートしていないこと、そして大部分がメッセージ駆動型 Bean (MDB) に取って代わられたことです。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 を参照してください。
|
|
|
