Oracle® Fusion Middleware Oracle WebLogic Server JMSのプログラミング 11g リリース1(10.3.4) B61629-02 |
|
前 |
次 |
以下の節では、Java Message Service (JMS)の様々な概念と機能を簡単に紹介し、それらと他のアプリケーション・オブジェクトおよびWebLogic Serverとの連携の仕組みについて説明します。
この章は、JavaのプログラミングおよびJMS 1.1の概念と機能に精通している読者を対象としています。
WebLogic JMSは、WebLogic Serverプラットフォームに緊密に統合されたエンタープライズ・クラスのメッセージング・システムです。JMS仕様(http://java.sun.com/products/jms/docs.html
)を完全にサポートし、標準JMS APIを超える機能を持つWebLogic JMS拡張が数多く用意されています。
エンタープライズ・メッセージング・システムを使用すると、複数のアプリケーションがメッセージの交換を通じて通信できます。メッセージとは、異なるアプリケーション間の通信を調整するために必要な情報が含まれている、リクエスト、レポート、およびイベントです。メッセージで提供される抽象化の階層により、宛先システムについての詳細情報をアプリケーション・コードから切り離すことができます。
Java Message Service (JMS)は、エンタープライズ・メッセージング・システムにアクセスするための標準のAPIです。具体的なJMSの特長は以下のとおりです。
メッセージング・システムを共有するJavaアプリケーション同士でメッセージを交換できます
メッセージを作成、送信、および受信するための標準インタフェースによりアプリケーションの開発が容易になります
次の図は、WebLogic JMSメッセージングの仕組みを示しています。
上の図に示すとおり、WebLogic JMSはプロデューサ・アプリケーションからメッセージを受信し、それらをコンシューマアプリケーションに送信します。
WebLogic Serverは次のJava仕様に準拠しています。
WebLogic Serverは、http://java.sun.com/javaee/5/docs/api/
に示すように、Java Platform、Enterprise Edition (Java EE)バージョン5.0仕様に準拠しています。
次の図は、WebLogic JMSのアーキテクチャを示しています。
図2-2に示されているように、WebLogic JMS Serverのアーキテクチャは主に以下の要素で構成されています。
定義済みのモジュールのセットをホストできるJMSサーバー、およびそれらに関連付けられた永続ストレージ(WebLogic Serverインスタンスに配置)。
構成リソース(問合せ、トピック、接続ファクトリなど)を含み、 http://xmlns.oracle.com/weblogic/weblogic-jms/1.0/weblogic-jms.xsd
スキーマに準拠するXMLドキュメントによって定義されるJMSモジュール。
クライアントJMSアプリケーション。宛先へのメッセージを生成するか、または宛先からのメッセージを消費します。
リソース・ルックアップ機能を提供するJNDI (Java Naming and Directory Interface)。接続ファクトリ、宛先などのJMSリソースの構成ではJNDI名を使用します。これらのリソースの実行時実装は、特定の名前を使用してJNDIにバインドされます。
永続的なメッセージ・データを格納するためのWebLogic永続ストレージ(ファイル・ストアまたはJDBC対応データベース)。
JMSでは、ポイント・ツー・ポイント(PTP)とパブリッシュ/サブスクライブ(pub/sub)の2つのメッセージング・モデルがサポートされています。それらのメッセージング・モデルは非常に似ていますが、以下の点で異なります。
PTPメッセージング・モデルでは、1つの宛先に対してメッセージが配信されます。
pub/subメッセージング・モデルでは、複数の宛先に対してメッセージが配信されます。
各モデルは、共通のベース・クラスを拡張したクラスで実装されます。たとえば、PTPクラスjavax.jms.Queue
(http://java.sun.com/javaee/5/docs/api/javax/jms/Queue.html
)とpub/subクラスjavax.jms.Topic
(http://java.sun.com/javaee/5/docs/api/javax/jms/Topic.html
)は、ともにjavax.jms.Destination
(http://java.sun.com/javaee/5/docs/api/javax/jms/Destination.html
)クラスを拡張します。
各メッセージング・モデルについては、以降の節で詳しく説明します。
注意: プロデューサおよびコンシューマという用語は、メッセージング・モデルに関係なく、それぞれメッセージを送信および受信するアプリケーションを表すために汎用的に使用します。ただし、各メッセージング・モデルでは、それぞれに固有の一意の用語でプロデューサとコンシューマを表します。 |
ポイント・ツー・ポイント(PTP)メッセージング・モデルでは、アプリケーションが別の1つのアプリケーションにメッセージを送信できます。PTPメッセージング・アプリケーションでは、名前付きのキューを使用してメッセージが送信および受信されます。メッセージは、キュー・センダー(プロデューサ)によって特定のキューに送信されます。キュー・レシーバ(コンシューマ)では、特定のキューからメッセージを受信します。
次の図は、PTPメッセージングの仕組みを示しています。
複数のキュー・センダーおよびキュー・レシーバを1つのキューに関連付けることができますが、個々のメッセージは1つのキュー・レシーバにしか配信できません。
複数のキュー・レシーバがキューのメッセージをリスニングしている場合、次のメッセージを受信するキュー・レシーバは先着順で決定されます。リスニングしているキュー・レシーバがない場合は、キュー・レシーバがキューにアタッチされるまでメッセージはキューにとどまります。
パブリッシュ/サブスクライブ(pub/sub)メッセージング・モデルでは、アプリケーションが複数のアプリケーションにメッセージを送信できます。pub/subメッセージング・アプリケーションでは、トピックをサブスクライブすることでメッセージが送信および受信されます。トピック・パブリッシャ(プロデューサ)によって、特定のトピックにメッセージが送信されます。トピック・サブスクライバ(コンシューマ)では、特定のトピックからメッセージが受信されます。
次の図は、pub/subメッセージングの仕組みを示しています。
PTPメッセージング・モデルの場合と違って、pub/subメッセージング・モデルでは複数のトピック・サブスクライバが同じメッセージを受信できます。メッセージは、すべてのトピック・サブスクライバが受信するまで維持されます。
pub/subメッセージング・モデルでは恒久サブスクライバがサポートされるので、トピック・サブスクライバに名前を割り当て、ユーザーまたはアプリケーションと関連付けることができます。恒久サブスクライバの詳細は、「恒久サブスクリプションの設定」を参照してください。
JMS仕様(http://java.sun.com/products/jms/docs.html
)の「Message Delivery Mode」の節に従って、メッセージを永続的または非永続的として指定できます。
永続的なメッセージは確実に1回だけ配信されます。JMSプロバイダの障害が原因でメッセージが失われたり、2回配信されることはありません。メッセージは、ファイルまたはデータベースに正常に書き込まれるまで送信されたとは判断されません。永続的メッセージは、構成時に各JMSサーバーによって必要に応じてターゲット指定されたWebLogic永続ストア(ディスク・ベース・ファイルまたはJDBCによるアクセスが可能なデータベース)に書き込まれます。
非永続的メッセージは格納されません。メッセージは最大で1回配信が保証されますが、JMSプロバイダに障害が発生すると失われる場合があります。ただし、2回配信されることはありません。接続をクローズするか回復すると、確認応答されていないすべての非永続的メッセージが再配信されます。非永続的メッセージは確認応答されると再配信されません。
システム全体の使用の詳細は、『Oracle Fusion Middleware Oracle WebLogic Serverサーバー環境の構成』の「WebLogic永続ストアの使い方」を参照してください。
WebLogic JMSはWebLogic Serverプラットフォームと密接に統合されているため、非常にセキュアなJava EEアプリケーションを構築して、WebLogic Serverコンソールで簡単にモニターしたり管理したりできます。XAトランザクションが完全にサポートされているだけでなく、クラスタ機能とサービス移行機能による高可用性を特長としています。加えて、他のバージョンのWebLogic Serverやサード・パーティのメッセージ・プロバイダとのシームレスな相互運用性も提供されます。
これらの付加価値機能の詳細は、『Oracle Fusion Middleware Oracle WebLogic Server JMSの構成と管理』の「WebLogic Serverの付加価値JMS機能」を参照してください。
WebLogic Serverには、JMS仕様で指定されている標準JMS APIに加え、次の表で説明するクラスやメソッドを含む様々なweblogic.jms.extensions
APIが用意されています。
表2-1 WebLogic JMSパブリックAPIの拡張機能
インタフェース/クラス | 機能 |
---|---|
コンシューマおよび宛先の情報を、CompositeData形式で管理クライアントに提供します。 |
|
以下を作成するためのファクトリおよびメソッドを提供します。
|
|
JMXを使用したメッセージの表示と操作を提供します。 |
|
JMS実行時MBeanをモニターし、JMSモジュール内のJMSモジュール構成エントリを管理します。 |
|
JMS実行時JMX MBeanをモニターします。 |
|
MDB (メッセージドリブンBean)に配信されたメッセージとトランザクションを関連付けます。 |
|
宛先がキューであるかトピックであるかを識別します。 |
|
メッセージの配信時間、再配信制限、および送信タイムアウトを設定します。 |
|
プロデューサのメッセージ配信時間、および順序単位の名前を設定します。 |
|
|
|
XMLメッセージを作成します。 |
|
メッセージのスケジューリング済み配信時間を設定します。 |
|
JMS実行時MBeanをモニターします。 このリリースのWebLogic Serverでは非推奨です。JMSModuleHelperに置き換えられました。 |
|
サーバー・セッション・プールおよびメッセージ・リスナーを作成するためのインタフェースを提供します。 注意: セッション・プールの構成オブジェクトは、このリリースのWebLogic Serverでは非推奨となっています。これらは、Java EE仕様の必須コンポーネントではなく、JTAユーザー・トランザクションもサポートしていません。かわりに、Java EEの必須コンポーネントであるメッセージドリブンBean (MDB)が主に使用されています。MDBの設計の詳細は、『Oracle Fusion Middleware Oracle WebLogic ServerメッセージドリブンBeanのプログラミング』を参照してください。 |
このAPIでは、NO_ACKNOWLEDGE
とMULTICAST_NO_ACKNOWLEDGE
の確認応答モード、および以下のような例外のスローを含む拡張例外もサポートされています。
サーバー障害または管理上の介入によってコンシューマの1つがサーバーによってクローズされたときにセッション例外リスナー(設定されている場合)に例外をスローする
セッションで受信されたが、まだメッセージ・リスナーに配信されていないメッセージの数がそのセッションの最大メッセージ許容数を超えたときにマルチキャスト・セッションから例外をスローする
データ・ストリームでシーケンスの欠陥(シーケンスの異なる受信メッセージ)が検出されたときにマルチキャスト・コンシューマから例外をスローする
JMSアプリケーションを作成するには、javax.jms
API(http://java.sun.com/javaee/5/docs/api/javax/jms/package-summary.html
)を使用します。このAPIでは、JMSへの接続やメッセージの送受信に必要なクラス・オブジェクトを作成できます。JMSクラス・インタフェースは、共通の親クラスのキュー・バージョンとトピック・バージョンを提供するサブクラスとして作成されます。
次の表は、以降の項で詳しく説明するJMSクラスを示しています。すべてのJMSクラスの詳細は、javax.jms
(http://java.sun.com/javaee/5/docs/api/javax/jms/package-summary.html
)またはweblogic.jms.extensions
のJavadocを参照してください。
表2-2 WebLogic JMSのクラス
JMSクラス | 説明 |
---|---|
|
接続の構成情報をカプセル化します。接続ファクトリは接続を作成するために使用します。接続ファクトリはJNDIを使用してルックアップします。 |
|
メッセージング・システムへの開いている通信チャネルを表します。接続はセッションを作成するために使用します。 |
|
生成および消費されるメッセージの順序を定義します。 |
|
特定のプロバイダのアドレスをカプセル化して、キューまたはトピックを識別します。キューとトピックでは、それぞれPTPメッセージング・モデルおよびpub/subメッセージング・モデルから配信されるメッセージが管理されます。 |
MessageProducerとMessageConsumer |
メッセージを送信および受信するためのインタフェースを提供します。メッセージ・プロデューサではキューまたはトピックにメッセージが送信されます。メッセージ・コンシューマではキューまたはトピックからメッセージが受信されます。 |
|
送信または受信される情報をカプセル化します。 |
メッセージ・コンシューマのサーバー管理のプールに関する構成情報をカプセル化します。サーバー・セッション・プール・ファクトリはサーバー・セッション・プールを作成するために使用します。 |
|
メッセージを並行処理するために使用できるサーバー・セッションのプールを接続コンシューマに提供します。 |
|
スレッドとJMSセッションを関連付けます。 |
|
メッセージを並行処理するためにサーバー・セッションを取り出すコンシューマを指定します。 |
脚注 1 複数のメッセージを並行して処理するためのオプションのJMSインタフェースがサポートされます。
脚注 2 複数のメッセージを並行して処理するためのオプションのJMSインタフェースがサポートされます。
脚注 3 複数のメッセージを並行して処理するためのオプションのJMSインタフェースがサポートされます。
脚注 4 複数のメッセージを並行して処理するためのオプションのJMSインタフェースがサポートされます。
JMSリソースの構成については、『Oracle Fusion Middleware Oracle WebLogic Server JMSの構成と管理』の「基本JMSシステム・リソースの構成」を参照してください。JMSアプリケーションを設定する手順については、「JMSアプリケーションの設定」を参照してください。
ConnectionFactory
は、接続の構成情報をカプセル化し、JMSアプリケーションがConnection
(「Connection」を参照)を作成できるようにします。接続ファクトリでは同時使用がサポートされており、複数のスレッドがオブジェクトに同時にアクセスできます。WebLogic JMSが提供するあらかじめ構成されたデフォルト接続ファクトリを使用するか、1つまたは複数の接続ファクトリを構成することで、アプリケーションに適したあらかじめ定義された属性で接続を作成できます。
WebLogic JMSでは2つのデフォルト接続ファクトリが定義されています。これらの接続ファクトリは、次のJNDI名を使用してルックアップできます。
weblogic.jms.ConnectionFactory
weblogic.jms.XAConnectionFactory
ユーザー定義の接続ファクトリは、デフォルト・ファクトリの設定がアプリケーションに適さない場合にのみ作成します。デフォルト接続ファクトリの構成済み設定との主な違いは、次の表に示すように、JTAトランザクションを有効にするために使用する「XA接続ファクトリを有効化」属性のデフォルト値です。
表2-3 デフォルト接続ファクトリ用のXAトランザクション設定
デフォルト接続ファクトリ | 「XA接続ファクトリを有効化」の設定値 |
---|---|
weblogic.jms.ConnectionFactory |
False |
weblogic.jms.XAConnectionFactory |
True |
XAファクトリは、JMSアプリケーションでJTAユーザー・トランザクションを使用する場合に必要となりますが、トランザクション・セッションの場合は必要ありません。WebLogic JMSでのトランザクションの使用については、第12章「WebLogic JMSによるトランザクションの使い方」を参照してください。
その他のすべてのデフォルト構成属性は、ユーザー定義の接続ファクトリと同じデフォルト値に設定されます。
「XA接続ファクトリの有効化」属性と、その他の接続ファクトリ属性のデフォルト値については、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのJMS接続ファクトリ: 構成: トランザクションに関する項を参照してください。
デフォルトの接続ファクトリを使用する場合のもう1つの違いは、接続ファクトリがデプロイされる可能性のあるWebLogic Serverを限定できない点です。ただし、デフォルトの接続ファクトリはサーバー単位で無効にできます。
デフォルト接続ファクトリの有効化または無効化については、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのサーバー: 構成: サービスに関する項を参照してください。
特定の独立したサーバー、クラスタ内の特定のサーバー、またはクラスタ全体に接続ファクトリをデプロイするには、新しい接続ファクトリを構成し、適切なターゲットを指定する必要があります(『Oracle Fusion Middleware Oracle WebLogic Server JMSの構成と管理』の「接続ファクトリの構成」を参照)。
注意: 下位互換性を維持するため、WebLogic JMSでは非推奨の2つのデフォルト接続ファクトリを現在もサポートしています。該当するファクトリのJNDI名は次のとおりです。javax.jms.QueueConnectionFactory およびjavax.jms.TopicConnectionFactory 。 |
システム管理者が1つまたは複数の接続ファクトリを定義および構成して、あらかじめ定義された属性で接続を作成すると、WebLogic Serverでは起動時にそれらの接続ファクトリがJNDIスペースに追加されます。アプリケーションでは、WebLogic JNDIを使用して接続ファクトリを取り出します。ユーザー定義の接続ファクトリには一意の名前を付ける必要があります。
接続ファクトリの構成については、Oracle WebLogic Server管理コンソール・オンライン・ヘルプの接続ファクトリの構成に関する項を参照してください。
システム管理者は、クラスタにターゲット指定するか、クラスタ内の1つまたは複数のサーバー・インスタンスにターゲット指定することで、クラスタ内のあらゆるサーバーからJMS宛先への透過的なアクセスをクラスタ全体にわたって確立します。これにより、各接続ファクトリを複数のWebLogic Serverインスタンスにデプロイできます。JMSのクラスタリングの詳細は、『Oracle Fusion Middleware Oracle WebLogic Server JMSの構成と管理』の「拡張WebLogic JMSリソースの構成」を参照してください。
ConnectionFactory
クラスではメソッドは定義されませんが、そのサブクラスでは各メッセージング・モデルのメソッドが定義されます。接続ファクトリでは同時使用がサポートされており、複数のスレッドがオブジェクトに同時にアクセスできます。
注意: このリリースでは、JMS 1.1仕様の接続ファクトリを使用できます。または、そのサブクラスを使用することもできます。 |
次の表は、ConnectionFactory
のサブクラスを説明しています。
表2-4 ConnectionFactoryのサブクラス
サブクラスは... | メッセージング・モデルで... | 次を作成するために使用されます... |
---|---|---|
QueueConnectionFactory |
PTP |
JMS PTPプロバイダへの |
TopicConnectionFactory |
pub/sub |
JMS pub/subプロバイダへの |
アプリケーションでConnectionFactory
クラスを使用する方法については、第5章「基本的なJMSアプリケーションの開発」またはjavax.jms.ConnectionFactoryのJavadoc(http://java.sun.com/javaee/5/docs/api/javax/jms/ConnectionFactory.html
)を参照してください。
Connection
は、アプリケーションとメッセージング・システムの間の開いている通信チャネルを表し、メッセージを生成および消費するためのSession
(「Session」を参照)を作成するために使用します。接続では、アプリケーションとJMSの間のメッセージングを管理するサーバー側とクライアント側のオブジェクトが作成されます。接続では、ユーザーの認証も提供されます。
Connection
は、JNDIルックアップを通じて取得するConnectionFactory
(「ConnectionFactory」を参照)によって作成されます。
ユーザーの認証や通信の設定に関わるリソースのオーバーヘッドがあるため、ほとんどのアプリケーションではすべてのメッセージングで1つの接続を確立します。WebLogic Serverでは、JMSトラフィックはサーバーとのクライアント接続で他のWebLogicサービスと多重化されます。JMSのために、新たなTCP/IP接続が作成されることはありません。サーブレットや他のサーバー側オブジェクトもまた、JMS Connectionを使用する場合があります。
デフォルトでは、接続は停止モードで作成されます。停止している接続を開始する方法とタイミングについては、「接続の開始、停止、クローズ」を参照してください。
接続では同時使用がサポートされており、複数のスレッドがオブジェクトに同時にアクセスできます。
注意: このリリースでは、JMS 1.1仕様のconnectionオブジェクトを使用できます。または、そのサブクラスを使用することもできます。 |
次の表は、Connection
のサブクラスを説明しています。
表2-5 Connectionのサブクラス
サブクラスは... | メッセージング・モデルで... | 次を作成するために使用されます... |
---|---|---|
QueueConnection |
PTP |
|
TopicConnection |
pub/sub |
|
アプリケーションでConnection
クラスを使用する方法については、第5章「基本的なJMSアプリケーションの開発」またはjavax.jms.ConnectionのJavadoc(http://java.sun.com/javaee/5/docs/api/javax/jms/Connection.html
)を参照してください。
Sessionオブジェクトでは、生成および消費されるメッセージの順序を定義し、複数のメッセージ・プロデューサとメッセージ・コンシューマを作成できます。メッセージの生成と消費には同じスレッドを使用できます。アプリケーションでメッセージの生成と消費に別々のスレッドが必要な場合は、そのアプリケーションで機能ごとに個別のセッションを作成する必要があります。
Sessionは、Connection
(「Connection」を参照)で作成されます。
JMS 1.1仕様(http://java.sun.com/products/jms/docs.html
)では、汎用セッションであらゆる型のDestinationオブジェクトのMessageConsumerを使用することが許可されています。しかし、WebLogic JMSでは、単一のセッションでQueueConsumer型とTopicSubscriber型のMessageConsumerを一緒に使用することはできません。また、単一のセッションで複数のコンシューマを使用するのは、あまり一般的ではありません。以下の一般的な使用方法がサポートされています。
単一のセッションで、QueueSender型とTopicSubscriber型(またはQueueConsumer型とTopicPublisher型)を1つずつ使用します。
MessageProducerを複数使用します。MessageProducerは型に関係なく複数使用できます。
注意: セッションおよびそのメッセージのプロデューサとコンシューマには、一度に1つのスレッドしかアクセスできません。それらに複数のスレッドが同時にアクセスした場合、それらの動作は不明確になります。 |
次の表は、Sessionのサブクラスを説明しています。
表2-6 Sessionのサブクラス
サブクラスは... | メッセージング・モデルで... | 次のためにコンテキストを提供します... |
---|---|---|
QueueSession |
PTP |
JMS PTPプロバイダのメッセージを生成および消費します。QueueConnectionで作成されます。 |
TopicSession |
pub/sub |
JMS pub/subプロバイダのメッセージを生成および消費します。TopicConnectionによって作成されます。 |
アプリケーションでSessionクラスを使用する方法については、第5章「基本的なJMSアプリケーションの開発」、またはjavax.jms.Session
のJavadoc(http://java.sun.com/javaee/5/docs/api/javax/jms/Session.html
)およびweblogic.jms.extensions.WLSessionのJavadocを参照してください。
非トランザクション・セッションでは、セッションを作成するアプリケーションで、次の表で定義されている5つの確認応答モードのいずれかが選択されます。
表2-7 非トランザクション・セッションで使用する確認応答モード
確認応答モード | 説明 |
---|---|
AUTO_ACKNOWLEDGE |
受信側アプリケーションのメソッドが処理を終えたときに、 |
CLIENT_ACKNOWLEDGE |
このモードを使用すると、アプリケーションでは1回の呼出しで複数メッセージの受信、処理、および確認応答を行うことができます。 注意: 管理コンソールでは、接続ファクトリの「確認応答ポリシー」属性が 「確認応答ポリシー」属性の詳細は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのJMS接続ファクトリ: 構成: 全般に関する項を参照してください。 |
DUPS_OK_ACKNOWLEDGE |
受信側アプリケーションのメソッドが処理を終えたときに、 このモードでは、最も効率的にリソースが利用されます。 注意: アプリケーションで重複メッセージを処理できない場合は、このモードは使用しません。重複メッセージは、メッセージを配信する最初の試行が失敗した場合に送信されます。 |
NO_ACKNOWLEDGE |
確認応答を必要としません。 このモードは、セッションの確認応答で提供されるサービスの質を必要とせず、それに関連するオーバーヘッドを避ける必要があるアプリケーションで使用します。 注意: アプリケーションで、失われたメッセージや重複メッセージを処理できない場合は、このモードは使用しないようにします。重複メッセージは、メッセージを配信する最初の試行が失敗した場合に送信されます。 |
MULTICAST_NO_ACKNOWLEDGE |
確認応答を必要としないマルチキャスト・モード。
このモードは、マルチキャストをサポートし、セッションの確認応答で提供されるサービスの質を必要としないアプリケーションで使用します。マルチキャストの詳細は、第8章「WebLogic JMSでのマルチキャストの使い方」を参照してください。 注意: トピックでのみ使用します。アプリケーションで、失われたメッセージや重複メッセージを処理できない場合は、このモードは使用しないようにします。重複メッセージは、メッセージを配信する最初の試行が失敗した場合に送信されます。 |
トランザクション・セッションでは、一度に1つのトランザクションしかアクティブになりません。トランザクション中に送信または受信されたメッセージ数に関係なく、最小の単位として処理されます。
トランザクション・セッションを作成すると、確認応答モードは無視されます。アプリケーションでトランザクションがコミットされると、そのトランザクションの間にアプリケーションで受信されたすべてのメッセージがメッセージング・システムによって確認応答され、アプリケーションで送信されたメッセージは配信されるべく受け入れられます。アプリケーションでトランザクションがロールバックされると、そのトランザクションの間にアプリケーションで受信されたメッセージは確認応答されず、アプリケーションで送信されたメッセージは破棄されます。
JMSは、Java Transaction API (JTA)を使用する他のJavaサービス(EJBなど)との分散トランザクションに参加できます。トランザクションはそのトランザクションに関連付けられたメッセージへのアクセスが制限されているため、トランザクション・セッションではこの機能をサポートしません。JTAの利用の詳細は、「JTAユーザー・トランザクションの使い方」を参照してください。
Destination
オブジェクトはキューまたはトピックになり、特定プロバイダのアドレス構文をカプセル化します。プロバイダによって構文はさまざまであるため、JMS仕様では標準のアドレス構文は定義されていません。
接続ファクトリの場合と同じように、管理者が宛先を定義し、構成すると、WebLogic Serverの起動時にそれがJNDIスペースに追加されます。また、アプリケーションでは、それが作成されたJMS接続の間だけ存在する一時的な宛先を作成することもできます。
注意: 管理者は、分散宛先を構成することもできます。分散宛先は、単一の論理的な宛先としてクライアントからアクセス可能な1つの宛先セット(キューまたはトピック)です。詳細については、「宛先の分散」を参照してください。 |
クライアント側では、Queue
オブジェクトとTopic
オブジェクトは、サーバー上のオブジェクトへのハンドルとして機能します。それらのメソッドは、それらの名前のみを返します。メッセージングを目的としてアクセスするには、それらにアタッチするメッセージ・プロデューサとメッセージ・コンシューマを作成します。
宛先では同時使用がサポートされており、複数のスレッドがオブジェクトに同時にアクセスできます。JMSのQueues
とTopics
は、javax.jms.Destination
(http://java.sun.com/javaee/5/docs/api/javax/jms/Destination.html
)を拡張します。
注意: このリリースでは、JMS 1.1仕様のdestinationオブジェクトを使用できます。または、そのサブクラスを使用することもできます。 |
次の表は、Destination
のサブクラスを説明しています。
表2-8 Destinationのサブクラス
サブクラス | メッセージング・モデル | 管理するメッセージ |
---|---|---|
Queue |
PTP |
JMSポイント・ツー・ポイント・プロバイダ |
TemporaryQueue |
PTP |
JMSポイント・ツー・ポイント・プロバイダのメッセージ。メッセージが作成されたJMS接続の間だけ存在します。一時的なキューはそれを作成したキュー接続によってのみ消費されます。 |
Topic |
pub/sub |
JMS pub/subプロバイダのメッセージ。 |
TemporaryTopic |
pub/sub |
JMS pub/subプロバイダのメッセージ。メッセージが作成されたJMS接続の間だけ存在します。一時的なトピックはそれを作成したトピック接続によってのみ消費されます。 |
注意: アプリケーションでは、キュー・セッションでQueueBrowser オブジェクトを作成することによりキューを参照することができます。このオブジェクトでは、キュー・ブラウザが作成された時点におけるキュー内のメッセージのスナップショットが生成されます。アプリケーションではキュー内のメッセージを表示できますが、メッセージは「読み込まれた」とは判断されず、したがってキューから削除されることはありません。キューの参照の詳細は、「メッセージ・ヘッダー・フィールドおよびメッセージ・プロパティ・フィールドの設定と参照」を参照してください。 |
アプリケーションでDestination
クラスを使用する方法については、第5章「基本的なJMSアプリケーションの開発」またはjavax.jms.Destination
のJavadoc(http://java.sun.com/javaee/5/docs/api/javax/jms/Destination.html
)を参照してください。
分散宛先リソースは、単一の論理的な宛先としてクライアントからアクセス可能な1つの宛先セット(キューまたはトピック)です(たとえば分散トピックは独自のJNDI名を持ちます)。このセットのメンバーは通常、クラスタ内の複数のサーバーに分散されており、各メンバーは別々のJMSサーバーに属しています。分散宛先を使用するアプリケーションは、スタンドアロンの宛先を使用するアプリケーションより可用性が高くなります。これは、WebLogic JMSに、クラスタ内の分散宛先メンバーのためのロード・バランシングおよびフェイルオーバー機能があるためです。
ご使用のアプリケーションにおける分散宛先の詳細は、第9章「分散宛先の使用」を参照してください。
分散キュー宛先の構成手順については、Oracle WebLogic Server管理コンソール・オンライン・ヘルプの共通分散キューの構成に関する項を参照してください。
分散トピック宛先の構成手順については、Oracle WebLogic Server管理コンソール・オンライン・ヘルプの共通分散トピックの構成に関する項を参照してください。
MessageProducer
では、メッセージがキューまたはトピックに送信されます。MessageConsumer
では、メッセージがキューまたはトピックから受信されます。メッセージ・プロデューサとメッセージ・コンシューマは、互いに独立して機能します。メッセージ・コンシューマが作成されてメッセージを待っているかどうかに関係なく、メッセージ・プロデューサではメッセージが生成および送信されます(この逆も同様)。
Session
(「Session」を参照)では、キューおよびトピックにアタッチされるMessageProducers
とMessageConsumers
が作成されます。
メッセージ・センダー・オブジェクトとメッセージ・レシーバ・オブジェクトは、MessageProducer
クラスおよびMessageConsumer
クラスのサブクラスとして作成されます。
注意: このリリースでは、JMS 1.1仕様のMessageProducerおよびMessageConsumerオブジェクトを使用できます。または、そのサブクラスを使用することもできます。 |
次の表は、MessageProducer
とMessageConsumer
のサブクラスを説明しています。
表2-9 MessageProducerとMessageConsumerのサブクラス
サブクラスは... | メッセージング・モデルで... | 次の機能を実行します... |
---|---|---|
QueueSender |
PTP |
JMSポイント・ツー・ポイント・プロバイダのメッセージを送信します。 |
QueueReceiver |
PTP |
JMSポイント・ツー・ポイント・プロバイダのメッセージを受信します。 |
TopicPublisher |
pub/sub |
JMS pub/subプロバイダのメッセージを送信します。 |
TopicSubscriber |
pub/sub |
JMS pub/subプロバイダのメッセージを受信します。 |
図2-3で示されているように、PTPモデルでは複数のセッションが同じキューからメッセージを受信できます。ただし、メッセージは、1つのキュー・レシーバにしか配信できません。複数のキュー・レシーバがある場合、次にメッセージを受信するキュー・レシーバは先着順で決まります。
図2-4で示されているように、pub/subモデルではメッセージを複数のトピック・サブスクライバに配信できます。トピック・サブスクライバは、「恒久サブスクリプションの設定」で説明されているように恒久にも非恒久にもなります。
アプリケーションでは、トピックのパブリッシュとサブスクライブに同じJMS接続を使用できます。トピック・メッセージはすべてのサブスクライバに配信できるので、アプリケーションは自身がパブリッシュしたメッセージを受信する可能性があります。メッセージがパブリッシュ元のクライアントで受信されるのを防ぐために、JMSアプリケーションではトピック・サブスクライバに対してnoLocal
属性を設定できます。詳細は、「ステップ5: メッセージ・プロデューサとメッセージ・コンシューマを作成する」を参照してください。
アプリケーションでMessageProducer
クラスとMessageConsumer
クラスを使用する方法については、「JMSアプリケーションの設定」、またはjavax.jms.MessageProducer
のJavadoc(http://java.sun.com/javaee/5/docs/api/javax/jms/MessageProducer.html
)およびjavax.jms.MessageConsumer
のJavadoc(http://java.sun.com/javaee/5/docs/api/javax/jms/MessageConsumer.html
)を参照してください。
Message
では、アプリケーション間で交換される情報がカプセル化されます。この情報は、以下の3つの要素で構成されます。
すべてのJMSメッセージには、デフォルトで挿入され、メッセージ・コンシューマで利用できる標準のヘッダー・フィールドがあります。一部のフィールドは、メッセージ・プロデューサで設定できます。
メッセージ・ヘッダー・フィールドの設定については、「メッセージ・ヘッダー・フィールドおよびメッセージ・プロパティ・フィールドの設定と参照」、またはjavax.jms.Message
のJavadoc(http://java.sun.com/javaee/5/docs/api/javax/jms/Message.html
)を参照してください。
次の表は、メッセージ・ヘッダーのフィールドを説明し、各フィールドで値がどのように定義されるのかを示しています。
表2-10 メッセージ・ヘッダー・フィールド
フィールド | 説明 | 次によって定義されます |
---|---|---|
JMSCorrelationID |
WebLogic このフィールドには2つの一般的な用途があります。 第1の用途は、次のようなリクエストとレスポンスの方式を設定してメッセージをリンクすることです。
第2の用途は、選択した文字列を |
アプリケーション |
JMSDeliveryMode |
永続的なメッセージが送信された場合、そのメッセージはWebLogic永続ストアに格納されます。 非永続的メッセージは永続ストアに格納されません。このモードでは、処理のオーバーヘッドが最小限に抑えられます。メッセージは最低1回は配信が保証されますが、システム障害が発生すると失われる場合があります。接続をクローズするか回復すると、確認応答されていないすべての非永続的メッセージが再配信されます。非永続的メッセージは確認応答されると再配信されません。 この値は、 |
|
JMSDeliveryTime |
メッセージをコンシューマに配信できる最も早い絶対時間を定義します。このフィールドは、プロデューサに設定された このフィールドは、宛先でのメッセージのソート、またはメッセージの選択に使用できます。データ型変換の目的で、 |
|
JMSDestination |
メッセージが配信される宛先(キューまたはトピック)を指定します。このフィールドは、プロデューサの作成時に設定されるか、 この値は、 |
|
JMSExpiration |
メッセージの有効期限(存続時間値)を指定します。このフィールドは、
期限の切れたメッセージは、誤って配信されないようにシステムから削除されます。 |
|
JMSMessageID |
JMSプロバイダによって送信される各メッセージを一意に識別する文字列値を格納します。このフィールドは、 すべての この値は、 |
|
JMSPriority |
優先順位のレベルを指定します。このフィールドは、プロデューサに設定されるか、 JMSでは、0 - 9の10段階で優先順位が定義されています(0が最低の優先順位)。レベル0 - 4は通常の範囲に属し、レベル5 - 9は至急の範囲に属します。 メッセージが受信されるときには、メッセージを送信するメソッドで指定された値が格納されています。 宛先キーを構成すれば、優先順位を基準に宛先をソートできます。詳細は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプの宛先キーの構成に関する項を参照してください。 |
|
JMSRedelivered |
確認応答がないためメッセージが再配信されるときに設定されるフラグを指定します。このフラグは受信側アプリケーションに関係があります。 フラグが設定されている場合は、以下のいずれかの理由のために、同じメッセージが以前に配信されている可能性があります。
|
WebLogic JMS |
JMSReplyTo |
応答メッセージが送信されるキューまたはトピックを指定します。このフィールドは、 この機能は
|
アプリケーション |
JMSTimestamp |
メッセージが送信されたときの時刻を格納します。タイムスタンプは、アプリケーションでメッセージが送信されたときではなく、WebLogic JMSで配信用にメッセージが受け付けられたときにメッセージに書き込まれます。 メッセージが受信されるときには、タイムスタンプが格納されています。 このフィールドには、Javaのミリ時間の値が格納されます。 |
WebLogic JMS |
JMSType |
JMS仕様では、多様なJMSプロバイダに適応するため、このフィールドに若干の柔軟性を持たせています。一部のメッセージング・システムでは、アプリケーション固有のメッセージ・タイプを使用できます。そのようなシステムの場合、 WebLogic JMSでは、このフィールドの使用に制限を設けていません。 |
アプリケーション |
メッセージのプロパティ・フィールドには、送信側アプリケーションによって追加されたヘッダー・フィールドが格納されます。プロパティは、標準的なJavaの名前と値の組合せです。プロパティ名は、javax.jms.Message
のJavadoc(http://java.sun.com/javaee/5/docs/api/javax/jms/Message.html
)で定義されているメッセージ・セレクタの構文仕様に準拠していなければなりません。有効な値は、boolean、byte、double、float、int、long、およびStringです。
WebLogic Serverでは、JMS 1.1仕様(http://java.sun.com/products/jms/docs.html
)での定義に従って、以下のJMS (JMSX)定義済みプロパティの使用をサポートしています。
表2-11 JMSXプロパティ
タイプ | 説明 |
---|---|
JMSXUserID |
メッセージの送信者であるユーザーを識別するシステム生成のプロパティ。「JMSXUserIDプロパティの使用」を参照してください。 |
JMSXDeliveryCount |
メッセージの配信試行回数を指定するシステム生成のプロパティ。1回目の試行を1とします。 |
JMSXGroupID |
メッセージ・グループのID。 |
JMSXGroupSeq |
グループ内のメッセージの連続番号。 |
メッセージ・プロパティ・フィールドは、アプリケーション固有の目的に使用できますが、それらは基本的にはメッセージ・セレクタで使用するために用意されています。JMSプロパティをそれぞれの環境でどのように使用するかはユーザーが決定します。たとえば、処理条件に応じて一部のメッセージにだけ含め、その他のメッセージでは省略することもできます。詳細については、以下を参照してください。
メッセージ本文は、プロデューサからコンシューマに配信される内容です。
次の表は、JMSで定義されているメッセージ・タイプを説明しています。すべてのメッセージ・タイプは、メッセージ・ヘッダーとメッセージ・プロパティ(メッセージ本文はなし)で構成されるjavax.jms.Message
(http://java.sun.com/javaee/5/docs/api/javax/jms/Message.html
)を拡張します。
表2-12 JMSメッセージ・タイプ
タイプ | 説明 |
---|---|
javax.jms.BytesMessage |
未解釈バイトのストリーム。センダーとレシーバによって理解される必要があります。このメッセージ・タイプのアクセス・メソッドは、 |
javax.jms.MapMessage |
名前が文字列であり、値がJavaプリミティブ型である、複数の名前と値の組合せ。名前と値の組合せは、名前を指定することによって順次的にもランダムにも読み込むことができます。 |
javax.jms.ObjectMessage |
1つのシリアライズ可能なJavaオブジェクト。 |
javax.jms.StreamMessage |
Javaプリミティブ型のみがストリームで読み書きされること以外は、BytesMessageと同じ。 |
javax.jms.TextMessage |
1つのString。TextMessageではXMLコンテンツも格納できます。 |
weblogic.jms.extensions.XMLMessage |
XMLコンテンツ。XMLMessageタイプを使用すると、TextMessageで送信されるXMLコンテンツでは処理しにくいメッセージのフィルタ処理を容易に行うことができます。 |
詳細は、javax.jms.Message
のJavadoc(http://java.sun.com/javaee/5/docs/api/javax/jms/Message.html
)を参照してください。特定のメッセージ・タイプのアクセス・メソッドや変換チャートについては、そのメッセージ・タイプのJavadocを参照してください。
注意: セッション・プールおよび接続コンシューマの構成オブジェクトは、WebLogic Serverの本リリースでは非推奨となっています。これらは、Java EE仕様の必須コンポーネントではなく、JTAユーザー・トランザクションもサポートしていないためです。かわりに、より単純で可用性が高く、管理も容易なメッセージドリブンBean (MDB)が主に使用されています。MDBの設計の詳細は、『Oracle Fusion Middleware Oracle WebLogic Server Enterprise JavaBeansのプログラミング』の「メッセージドリブン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オブジェクト(「ServerSessionPoolFactory」を参照)によって作成されます。
アプリケーションでサーバー・セッション・プールを使用する方法については、「サーバー・セッション・プールの定義」またはjavax.jms.ServerSessionPool
のJavadoc(http://java.sun.com/javaee/5/docs/api/javax/jms/ServerSessionPool.html
)を参照してください。
ServerSession
アプリケーション・サーバー・オブジェクトでは、メッセージを作成、送信、および受信するためのコンテキストが提供され、スレッドとJMSセッションを関連付けることができます。
ServerSession
は、ServerSessionPool
オブジェクト(「ServerSessionPool」を参照)によって作成されます。
アプリケーションでサーバー・セッション・プールを使用する方法については、「サーバー・セッション・プールの定義」またはjavax.jms.ServerSession
のJavadoc(http://java.sun.com/javaee/5/docs/api/javax/jms/ServerSession.html
)を参照してください。
ConnectionConsumer
オブジェクトでは、サーバー・セッションを使用して受信メッセージを処理します。メッセージ・トラフィックが大きい場合は、スレッド・コンテキストの切替えを最小限に抑えるために、接続コンシューマでは複数のメッセージで各サーバー・セッションをロードすることができます。ConnectionConsumer
は、Connectionオブジェクト(「Connection」を参照)によって作成されます。
アプリケーションで接続コンシューマを使用する方法については、「サーバー・セッション・プールの定義」またはjavax.jms.ConnectionConsumer
のJavadoc(http://java.sun.com/javaee/5/docs/api/javax/jms/ConnectionConsumer.html
)を参照してください。
注意: 接続コンシューマ・リスナーは、サーバーと同じJVMで動作します。 |