ヘッダーをスキップ
Oracle® Fusion Middleware Oracle WebLogic Server JMSのプログラミング
12cリリース(12.1.1)
B65902-02
  ドキュメント・ライブラリへ移動
ライブラリ
製品リストへ移動
製品
目次へ移動
目次

前
 
次
 

2 WebLogic JMSについて

この章では、Java Message Service (JMS)の様々な概念と機能を紹介し、それらと他のアプリケーション・オブジェクトおよびWebLogic Serverとの連携の仕組みについて説明します。

この章は、JavaのプログラミングおよびJMS 1.1の概念と機能に精通している読者を対象としています。

Java Message ServiceとWebLogic JMSの概要

WebLogic JMSは、WebLogic Serverプラットフォームに緊密に統合されたエンタープライズ・クラスのメッセージング・システムです。JMS仕様(http://www.oracle.com/technetwork/java/jms/index.html)を完全にサポートし、標準JMS APIを超える機能を持つWebLogic JMS拡張が数多く用意されています。

Java Message Serviceとは

エンタープライズ・メッセージング・システムを使用すると、複数のアプリケーションがメッセージの交換を通じて通信できます。メッセージとは、異なるアプリケーション間の通信を調整するために必要な情報が含まれている、リクエスト、レポート、およびイベントです。メッセージで提供される抽象化の階層により、宛先システムについての詳細情報をアプリケーション・コードから切り離すことができます。

Java Message Service (JMS)は、エンタープライズ・メッセージング・システムにアクセスするための標準のAPIです。具体的なJMSの特長は以下のとおりです。

  • メッセージング・システムを共有するJavaアプリケーション同士でメッセージを交換できます

  • メッセージを作成、送信、および受信するための標準インタフェースによりアプリケーションの開発が容易になります

次の図は、WebLogic JMSメッセージングの仕組みを示しています。

図2-1 WebLogic JMSメッセージング

図2-1の説明が続きます
「図2-1 WebLogic JMSメッセージング」の説明

上の図に示すとおり、WebLogic JMSはプロデューサ・アプリケーションからメッセージを受信し、それらをコンシューマアプリケーションに送信します。

Java仕様の実装

WebLogic Serverは次のJava仕様に準拠しています。

Java EE仕様

WebLogic Serverは、http://download.oracle.com/javaee/5/api/に示すように、Java Platform、Enterprise Edition (Java EE)バージョン5.0仕様に準拠しています。

JMS仕様

WebLogic ServerはJMS 1.1仕様(http://www.oracle.com/technetwork/java/jms/index.html)に完全に準拠しており、本番環境で使用できます。

WebLogic JMSのアーキテクチャ

次の図は、WebLogic JMSのアーキテクチャを示しています。

図2-2 WebLogic JMSのアーキテクチャ

図2-2の説明が続きます
「図2-2 WebLogic JMSのアーキテクチャ」の説明

主要な構成要素

図2-2に示されているように、WebLogic JMS Serverのアーキテクチャは主に以下の要素で構成されています。

  • 定義済みのモジュールのセットをホストできるJMSサーバー、およびそれらに関連付けられた永続ストレージ(WebLogic Serverインスタンスに配置)。

  • 構成リソース(問合せ、トピック、接続ファクトリなど)を含み、 http://xmlns.oracle.com/weblogic/weblogic-jms/1.2/weblogic-jms.xsdスキーマに準拠するXMLドキュメントによって定義されるJMSモジュール。

  • クライアントJMSアプリケーション。宛先へのメッセージを生成するか、または宛先からのメッセージを消費します。

  • リソース・ルックアップ機能を提供するJNDI (Java Naming and Directory Interface)。接続ファクトリ、宛先などのJMSリソースの構成ではJNDI名を使用します。これらのリソースの実行時実装は、特定の名前を使用してJNDIにバインドされます。

  • 永続的なメッセージ・データを格納するためのWebLogic永続ストレージ(ファイル・ストアまたはJDBC対応データベース)。

メッセージング・モデルについて

JMSでは、ポイント・ツー・ポイント(PTP)とパブリッシュ/サブスクライブ(pub/sub)の2つのメッセージング・モデルがサポートされています。それらのメッセージング・モデルは非常に似ていますが、以下の点で異なります。

各モデルは、共通のベース・クラスを拡張したクラスで実装されます。たとえば、PTPクラスjavax.jms.Queue (http://download.oracle.com/javaee/5/api/javax/jms/Queue.html)とpub/subクラスjavax.jms.Topic (http://download.oracle.com/javaee/5/api/javax/jms/Topic.html)は、ともにjavax.jms.Destination (http://download.oracle.com/javaee/5/api/javax/jms/Destination.html)クラスを拡張します。

各メッセージング・モデルについては、以降の節で詳しく説明します。


注意:

「プロデューサ」および「コンシューマ」という用語は、メッセージング・モデルに関係なく、それぞれメッセージを送信および受信するアプリケーションを表すために汎用的に使用します。ただし、各メッセージング・モデルでは、それぞれに固有の一意の用語でプロデューサとコンシューマを表します。


ポイント・ツー・ポイント・メッセージング

ポイント・ツー・ポイント(PTP)メッセージング・モデルでは、アプリケーションが別の1つのアプリケーションにメッセージを送信できます。PTPメッセージング・アプリケーションでは、名前付きのキューを使用してメッセージが送信および受信されます。メッセージは、キュー・センダー(プロデューサ)によって特定のキューに送信されます。キュー・レシーバ(コンシューマ)では、特定のキューからメッセージを受信します。

次の図は、PTPメッセージングの仕組みを示しています。

図2-3 ポイント・ツー・ポイント(PTP)メッセージング

図2-3の説明が続きます
「図2-3 ポイント・ツー・ポイント(PTP)メッセージング」の説明

複数のキュー・センダーおよびキュー・レシーバを1つのキューに関連付けることができますが、個々のメッセージは1つのキュー・レシーバにしか配信できません。

複数のキュー・レシーバがキューのメッセージをリスニングしている場合、次のメッセージを受信するキュー・レシーバは先着順で決定されます。リスニングしているキュー・レシーバがない場合は、キュー・レシーバがキューにアタッチされるまでメッセージはキューにとどまります。

パブリッシュ/サブスクライブ・メッセージング

パブリッシュ/サブスクライブ(pub/sub)メッセージング・モデルでは、アプリケーションが複数のアプリケーションにメッセージを送信できます。pub/subメッセージング・アプリケーションでは、トピックをサブスクライブすることでメッセージが送受信されます。トピック・パブリッシャ(プロデューサ)によって、特定のトピックにメッセージが送信されます。トピック・サブスクライバ(コンシューマ)では、特定のトピックからメッセージが受信されます。

次の図は、pub/subメッセージングの仕組みを示しています。

図2-4 パブリッシュ/サブスクライブ(pub/sub)メッセージング

図2-4の説明が続きます
「図2-4 パブリッシュ/サブスクライブ(pub/sub)メッセージング」の説明

PTPメッセージング・モデルの場合と違って、pub/subメッセージング・モデルでは複数のトピック・サブスクライバが同じメッセージを受信できます。メッセージは、すべてのトピック・サブスクライバが受信するまで維持されます。

pub/subメッセージング・モデルでは恒久サブスクライバがサポートされるので、トピック・サブスクライバに名前を割り当て、ユーザーまたはアプリケーションと関連付けることができます。恒久サブスクライバの詳細は、「恒久サブスクリプションの設定」を参照してください。

メッセージの永続性

JMS仕様(http://www.oracle.com/technetwork/java/jms/index.html)の「Message Delivery Mode」の節に従って、メッセージを永続的または非永続的として指定できます。

  • 永続的なメッセージは確実に1回だけ配信されます。JMSプロバイダの障害が原因でメッセージが失われたり、2回配信されることはありません。メッセージは、ファイルまたはデータベースに正常に書き込まれるまで送信されたとは判断されません。永続的メッセージは、構成時に各JMSサーバーによって必要に応じてターゲット指定されたWebLogic永続ストア(ディスク・ベース・ファイルまたはJDBCによるアクセスが可能なデータベース)に書き込まれます。

  • 非永続的メッセージは格納されません。メッセージは最大で1回配信が保証されますが、JMSプロバイダに障害が発生すると失われる場合があります。ただし、2回配信されることはありません。接続をクローズするか回復すると、確認応答されていないすべての非永続的メッセージが再配信されます。非永続的メッセージは確認応答されると再配信されません。

システム全体の使用の詳細は、『Oracle WebLogic Serverサーバー環境の構成』のWebLogic永続ストアの使い方に関する項を参照してください。

JMSパブリックAPIの付加価値拡張機能

WebLogic JMSはWebLogic Serverプラットフォームと密接に統合されているため、非常にセキュアなJava EEアプリケーションを構築して、WebLogic Serverコンソールで簡単にモニターしたり管理したりできます。XAトランザクションが完全にサポートされているだけでなく、クラスタ機能とサービス移行機能による高可用性を特長としています。加えて、他のバージョンのWebLogic Serverやサード・パーティのメッセージ・プロバイダとのシームレスな相互運用性も提供されます。

これらの付加価値機能の詳細は、『Oracle WebLogic Server JMSの構成と管理』のWebLogic Serverの付加価値JMS機能に関する項を参照してください。

WebLogic Serverの付加価値JMS機能

WebLogic Serverには、JMS仕様で指定されている標準JMS APIに加え、次の表で説明するクラスやメソッドを含む様々なweblogic.jms.extensions APIが用意されています。

表2-1 WebLogic JMSパブリックAPIの拡張機能

インタフェース/クラス 機能

ConsumerInfo

DestinationInfo

コンシューマおよび宛先の情報を、CompositeData形式で管理クライアントに提供します。

JMSMessageFactoryImpl

WLMessageFactory

以下を作成するためのファクトリおよびメソッドを提供します。

  • JMSメッセージ

  • JMSバイト・メッセージ

  • JMSマップ・メッセージ

  • JMSオブジェクト・メッセージ

  • JMSストリーム・メッセージ

  • JMSテキスト・メッセージ

  • JMS XMLメッセージ

JMSMessageInfo

JMXを使用したメッセージの表示と操作を提供します。

JMSModuleHelper

JMSNamedEntityModifier

JMS実行時MBeanをモニターし、JMSモジュール内のJMSモジュール構成エントリを管理します。

JMSRuntimeHelper

JMS実行時JMX MBeanをモニターします。

MDBTransaction

MDB (メッセージドリブンBean)に配信されたメッセージとトランザクションを関連付けます。

WLDestination

宛先がキューであるかトピックであるかを識別します。

WLMessage

メッセージの配信時間、再配信制限、および送信タイムアウトを設定します。

WLMessageProducer

プロデューサのメッセージ配信時間、および順序単位の名前を設定します。

WLQueueSession

WLSession

WLTopicSession

javax.jms.QueueSessionjavax.jms.Session、およびjavax.jms.TopicSessionでサポートされない追加のフィールドやメソッドを提供します。

XMLMessage

XMLメッセージを作成します。

Schedule

メッセージのスケジューリング済み配信時間を設定します。

JMSHelper

JMS実行時MBeanをモニターします。

このリリースのWebLogic Serverでは非推奨です。JMSModuleHelperに置き換えられました。

ServerSessionPoolFactory

ServerSessionPoolListener

サーバー・セッション・プールおよびメッセージ・リスナーを作成するためのインタフェースを提供します。

注意:セッション・プールの構成オブジェクトは、このリリースのWebLogic Serverでは非推奨となっています。これらは、Java EE仕様の必須コンポーネントではなく、JTAユーザー・トランザクションもサポートしていません。代わりに、Java EEの必須コンポーネントであるメッセージドリブンBean (MDB)が主に使用されています。MDBの設計の詳細は、『Oracle WebLogic ServerメッセージドリブンBeanのプログラミング』を参照してください。


このAPIでは、NO_ACKNOWLEDGEMULTICAST_NO_ACKNOWLEDGEの確認応答モード、および以下のような例外のスローを含む拡張例外もサポートされています。

  • サーバー障害または管理上の介入によってコンシューマの1つがサーバーによってクローズされたときにセッション例外リスナー(設定されている場合)に例外をスローする

  • セッションで受信されたが、まだメッセージ・リスナーに配信されていないメッセージの数がそのセッションの最大メッセージ許容数を超えたときにマルチキャスト・セッションから例外をスローする

  • データ・ストリームでシーケンスの欠陥(シーケンスの異なる受信メッセージ)が検出されたときにマルチキャスト・コンシューマから例外をスローする

JMS APIについて

JMSアプリケーションを作成するには、javax.jms API (http://download.oracle.com/javaee/5/api/javax/jms/package-summary.html)を使用します。このAPIでは、JMSへの接続やメッセージの送受信に必要なクラス・オブジェクトを作成できます。JMSクラス・インタフェースは、共通の親クラスのキュー・バージョンとトピック・バージョンを提供するサブクラスとして作成されます。

次の表は、以降の項で詳しく説明するJMSクラスを示しています。すべてのJMSクラスの詳細は、javax.jms (http://download.oracle.com/javaee/5/api/javax/jms/package-summary.html)またはweblogic.jms.extensionsのJavadocを参照してください。

表2-2 WebLogic JMSのクラス

JMSクラス 説明

ConnectionFactory


接続の構成情報をカプセル化します。接続ファクトリは接続を作成するために使用します。接続ファクトリはJNDIを使用してルックアップします。

Connection


メッセージング・システムへの開いている通信チャネルを表します。接続はセッションを作成するために使用します。

Session


生成および消費されるメッセージの順序を定義します。

Destination


特定のプロバイダのアドレスをカプセル化して、キューまたはトピックを識別します。キューとトピックでは、それぞれPTPメッセージング・モデルおよびpub/subメッセージング・モデルから配信されるメッセージが管理されます。

MessageProducerとMessageConsumer


メッセージを送信および受信するためのインタフェースを提供します。メッセージ・プロデューサではキューまたはトピックにメッセージが送信されます。メッセージ・コンシューマではキューまたはトピックからメッセージが受信されます。

Message


送信または受信される情報をカプセル化します。

ServerSessionPoolFactory脚注 1 

メッセージ・コンシューマのサーバー管理のプールに関する構成情報をカプセル化します。サーバー・セッション・プール・ファクトリはサーバー・セッション・プールを作成するために使用します。

ServerSessionPool脚注 2 

メッセージを並行処理するために使用できるサーバー・セッションのプールを接続コンシューマに提供します。

ServerSession脚注 3 

スレッドとJMSセッションを関連付けます。

ConnectionConsumer脚注 4 

メッセージを並行処理するためにサーバー・セッションを取り出すコンシューマを指定します。


脚注 1 複数のメッセージを並行して処理するためのオプションのJMSインタフェースがサポートされます。

脚注 2 複数のメッセージを並行して処理するためのオプションのJMSインタフェースがサポートされます。

脚注 3 複数のメッセージを並行して処理するためのオプションのJMSインタフェースがサポートされます。

脚注 4 複数のメッセージを並行して処理するためのオプションのJMSインタフェースがサポートされます。

JMSリソースの構成については、『Oracle WebLogic Server JMSの構成と管理』の基本JMSシステム・リソースの構成に関する項を参照してください。JMSアプリケーションを設定する手順については、JMSアプリケーションの設定に関する項を参照してください。

ConnectionFactory

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 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 WebLogic Server JMSの構成と管理』の拡張WebLogic JMSリソースの構成に関する項を参照してください。

ConnectionFactoryクラス

ConnectionFactoryクラスではメソッドは定義されませんが、そのサブクラスでは各メッセージング・モデルのメソッドが定義されます。接続ファクトリでは同時使用がサポートされており、複数のスレッドがオブジェクトに同時にアクセスできます。


注意:

このリリースでは、JMS 1.1仕様の接続ファクトリを使用できます。または、そのサブクラスを使用することもできます。


次の表は、ConnectionFactoryサブクラスを説明しています。

表2-4 ConnectionFactoryサブクラス

サブクラスは... メッセージング・モデルで... 次を作成するために使用されます...
QueueConnectionFactory

PTP

JMS PTPプロバイダへのQueueConnection

TopicConnectionFactory

pub/sub

JMS pub/subプロバイダへのTopicConnection


アプリケーションでConnectionFactoryクラスを使用する方法については、第5章「基本的なJMSアプリケーションの開発」またはjavax.jms.ConnectionFactoryのJavadoc (http://download.oracle.com/javaee/5/api/javax/jms/ConnectionFactory.html)を参照してください。

Connection

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

QueueSessionQueueConnectionFactoryで作成されたJMS PTPプロバイダへの接続で構成されます。

TopicConnection

pub/sub

TopicSessionTopicConnectionFactoryで作成されたJMS pub/subプロバイダへの接続で構成されます。


アプリケーションでConnectionクラスを使用する方法については、第5章「基本的なJMSアプリケーションの開発」またはjavax.jms.ConnectionのJavadoc (http://download.oracle.com/javaee/5/api/javax/jms/Connection.html)を参照してください。

Session

Sessionオブジェクトでは、生成および消費されるメッセージの順序を定義し、複数のメッセージ・プロデューサとメッセージ・コンシューマを作成できます。メッセージの生成と消費には同じスレッドを使用できます。アプリケーションでメッセージの生成と消費に別々のスレッドが必要な場合は、そのアプリケーションで機能ごとに個別のセッションを作成する必要があります。

Sessionは、Connection (「Connection」を参照)で作成されます。

WebLogic JMSセッションのガイドライン

JMS 1.1仕様(http://www.oracle.com/technetwork/java/jms/index.html)では、汎用セッションであらゆる型のDestinationオブジェクトのMessageConsumerを使用することが許可されています。しかし、WebLogic JMSでは、単一のセッションでQueueConsumer型とTopicSubscriber型のMessageConsumerを一緒に使用することはできません。また、単一のセッションで複数のコンシューマを使用するのは、あまり一般的ではありません。以下の一般的な使用方法がサポートされています。

  • 単一のセッションで、QueueSender型とTopicSubscriber型(またはQueueConsumer型とTopicPublisher型)を1つずつ使用します。

  • MessageProducerを複数使用します。MessageProducerは型に関係なく複数使用できます。


    注意:

    セッションおよびそのメッセージのプロデューサとコンシューマには、一度に1つのスレッドしかアクセスできません。それらに複数のスレッドが同時にアクセスした場合、それらの動作は不明確になります。


Sessionサブクラス

次の表は、Sessionサブクラスを説明しています。

表2-6 Sessionサブクラス

サブクラスは... メッセージング・モデルで... 次のためにコンテキストを提供します...
QueueSession

PTP

JMS PTPプロバイダのメッセージを生成および消費します。QueueConnectionで作成されます。

TopicSession

pub/sub

JMS pub/subプロバイダのメッセージを生成および消費します。TopicConnectionによって作成されます。


アプリケーションでSessionクラスを使用する方法については、第5章「基本的なJMSアプリケーションの開発」、またはjavax.jms.SessionのJavadoc(http://download.oracle.com/javaee/5/api/javax/jms/Session.html)およびweblogic.jms.extensions.WLSessionのJavadocを参照してください。

非トランザクション・セッション

非トランザクション・セッションでは、セッションを作成するアプリケーションで、次の表で定義されている5つの確認応答モードのいずれかが選択されます。

表2-7 非トランザクション・セッションで使用する確認応答モード

確認応答モード 説明
AUTO_ACKNOWLEDGE

受信側アプリケーションのメソッドが処理を終えたときに、Sessionオブジェクトでメッセージ受信の確認応答が行われます。

CLIENT_ACKNOWLEDGE 

Sessionオブジェクトの動作は、アプリケーションによる確認応答メソッドの呼出しに依存します。メソッドが呼び出されると、セッションでは、前回の確認応答以降に受信されたすべてのメッセージに対して確認応答が行われます。

このモードを使用すると、アプリケーションでは1回の呼出しで複数メッセージの受信、処理、および確認応答を行うことができます。

注意: 管理コンソールでは、接続ファクトリの「確認応答ポリシー」属性がPreviousに設定されているのに対し、指定のセッションでのすべての受信メッセージを確認応答したい場合、最後のメッセージを使用して確認応答メソッドを呼び出します。

「確認応答ポリシー」属性の詳細は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプ「JMS接続ファクトリ: 構成: 全般」を参照してください。

DUPS_OK_ACKNOWLEDGE

受信側アプリケーションのメソッドが処理を終えたときに、Sessionオブジェクトでメッセージ受信の確認応答が行われます。確認応答の重複が許可されます。

このモードでは、最も効率的にリソースが利用されます。

注意: アプリケーションで重複メッセージを処理できない場合は、このモードは使用しません。重複メッセージは、メッセージを配信する最初の試行が失敗した場合に送信されます。

NO_ACKNOWLEDGE

確認応答を必要としません。NO_ACKNOWLEDGEセッションに送信されたメッセージは、サーバーから即座に削除されます。このモードで受信されたメッセージは回復されないので、メッセージを配信する最初の試行が失敗した場合はメッセージが失われたり、重複メッセージが配信されたりします。

このモードは、セッションの確認応答で提供されるサービスの質を必要とせず、それに関連するオーバーヘッドを避ける必要があるアプリケーションで使用します。

注意: アプリケーションで、失われたメッセージや重複メッセージを処理できない場合は、このモードは使用しないようにします。重複メッセージは、メッセージを配信する最初の試行が失敗した場合に送信されます。

MULTICAST_NO_ACKNOWLEDGE

確認応答を必要としないマルチキャスト・モード。

MULTICAST_NO_ACKNOWLEDGEセッションに送信されたメッセージでは、前述の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のQueuesTopicsは、javax.jms.Destination (http://download.oracle.com/javaee/5/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://download.oracle.com/javaee/5/api/javax/jms/Destination.html)を参照してください。

宛先の分散

分散宛先リソースは、単一の論理的な宛先としてクライアントからアクセス可能な1つの宛先セット(キューまたはトピック)です(たとえば分散トピックは独自のJNDI名を持ちます)。このセットのメンバーは通常、クラスタ内の複数のサーバーに分散されており、各メンバーは別々のJMSサーバーに属しています。分散宛先を使用するアプリケーションは、スタンドアロンの宛先を使用するアプリケーションより可用性が高くなります。これは、WebLogic JMSに、クラスタ内の分散宛先メンバーのためのロード・バランシングおよびフェイルオーバー機能があるためです。

MessageProducerとMessageConsumer

MessageProducerでは、メッセージがキューまたはトピックに送信されます。MessageConsumerでは、メッセージがキューまたはトピックから受信されます。メッセージ・プロデューサとメッセージ・コンシューマは、互いに独立して機能します。メッセージ・コンシューマが作成されてメッセージを待っているかどうかに関係なく、メッセージ・プロデューサではメッセージが生成および送信されます(この逆も同様)。

Session (「Session」を参照)では、キューおよびトピックにアタッチされるMessageProducersMessageConsumersが作成されます。

メッセージ・センダー・オブジェクトとメッセージ・レシーバ・オブジェクトは、MessageProducerクラスおよびMessageConsumerクラスのサブクラスとして作成されます。


注意:

このリリースでは、JMSバージョン1.1仕様のメッセージ・プロデューサおよびメッセージ・コンシューマ・オブジェクトを使用できます。または、そのサブクラスを使用することもできます。


次の表は、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モデルではメッセージを複数のトピック・サブスクライバに配信できます。トピック・サブスクライバは、「恒久サブスクリプションの設定」で説明されているように恒久にも非恒久にもなります。

アプリケーションでは、1つのトピックのパブリッシュとサブスクライブに同じJMS接続を使用できます。トピック・メッセージはすべてのサブスクライバに配信されるので、アプリケーションは自身がパブリッシュしたメッセージを受信できます。メッセージがパブリッシュ元のクライアントで受信されるのを防ぐために、JMSアプリケーションではトピック・サブスクライバに対してnoLocal属性を設定できます。詳細は、「ステップ5: メッセージ・プロデューサとメッセージ・コンシューマを作成する」を参照してください。

アプリケーションでMessageProducerクラスとMessageConsumerクラスを使用する方法については、「JMSアプリケーションの設定」、またはjavax.jms.MessageProducerのJavadoc (http://download.oracle.com/javaee/5/api/javax/jms/MessageProducer.html)およびjavax.jms.MessageConsumerのJavadoc (http://download.oracle.com/javaee/5/api/javax/jms/MessageConsumer.html)を参照してください。

Message

Messageでは、アプリケーション間で交換される情報がカプセル化されます。この情報は、以下の3つの要素で構成されます。

メッセージ・ヘッダー・フィールド

すべてのJMSメッセージには、デフォルトで挿入され、メッセージ・コンシューマで利用できる標準のヘッダー・フィールドがあります。一部のフィールドは、メッセージ・プロデューサで設定できます。

メッセージ・ヘッダー・フィールドの設定については、「メッセージ・ヘッダー・フィールドおよびメッセージ・プロパティ・フィールドの設定と参照」、またはjavax.jms.MessageのJavadoc (http://download.oracle.com/javaee/5/api/javax/jms/Message.html)を参照してください。

次の表は、メッセージ・ヘッダーのフィールドを説明し、各フィールドで値がどのように定義されるのかを示しています。

表2-10 メッセージ・ヘッダー・フィールド

フィールド 説明 次によって定義されます
JMSCorrelationID

WebLogic JMSMessageID (この表内で後述)、アプリケーション固有の文字列、またはbyte[]配列のいずれかを指定します。JMSCorrelationIDはメッセージを相関させるために使用します。send()の前に、アプリケーションによってメッセージに直接設定されます。

このフィールドには2つの一般的な用途があります。

第1の用途は、次のようなリクエストとレスポンスの方式を設定してメッセージをリンクすることです。

  1. メッセージを送信するときに、アプリケーションではそのメッセージに割り当てられたJMSMessageID値を格納します。

  2. そのメッセージを受信したアプリケーションでは、送信側アプリケーションに送り返すレスポンス・メッセージのJMSCorrelationIDフィールドにJMSMessageIDをコピーします。

第2の用途は、選択した文字列をJMSCorrelationIDフィールドに格納し、一連のメッセージをアプリケーション指定の値でリンクできるようにすることです。

アプリケーション

JMSDeliveryMode

PERSISTENTまたはNON_PERSISTENTを指定します。このフィールドは、プロデューサに設定されるか、send()の前にアプリケーションによって送信されるパラメータとして設定されます。

永続的なメッセージが送信された場合、そのメッセージはWebLogic永続ストアに格納されます。send()処理は、メッセージの配信を保証できるまで成功とは判断されません。永続的なメッセージは少なくとも1回は確実に配信されます。

非永続的メッセージは永続ストアに格納されません。このモードでは、処理のオーバーヘッドが最小限に抑えられます。メッセージは最低1回は配信が保証されますが、システム障害が発生すると失われる場合があります。接続をクローズするか回復すると、確認応答されていないすべての非永続的メッセージが再配信されます。非永続的メッセージは確認応答されると再配信されません。

この値は、producer.send()への呼出しによって上書きされます。この値をメッセージに直接設定しても無効となります。プロデューサによって設定された値は、producer.send()に提供されたメッセージを使用して問い合わせるか、コンシューマがメッセージを受信したときに問い合わせることができます。

send()メソッド

JMSDeliveryTime

メッセージをコンシューマに配信できる最も早い絶対時間を定義します。このフィールドは、プロデューサに設定されたtimeToDeliverに応じて、send()の前にアプリケーションによって設定されます。

このフィールドは、宛先でのメッセージのソート、またはメッセージの選択に使用できます。データ型変換の目的で、JMSDeliveryTimeは長整数として保存されます。

send()メソッド

JMSDestination

メッセージが配信される宛先(キューまたはトピック)を指定します。このフィールドは、プロデューサの作成時に設定されるか、send()の前にアプリケーションによって送信されるパラメータとして設定されます。

この値は、producer.send()への呼出しによって上書きされます。この値をメッセージに直接設定しても無効となります。プロデューサによって設定された値は、producer.send()に提供されたメッセージを使用して問い合わせるか、コンシューマがメッセージを受信したときに問い合わせることができます。メッセージが受信されるとき、その宛先の値は送信時に割り当てられた値と同じでなければなりません。

send()メソッド

JMSExpiration

メッセージの有効期限(存続時間値)を指定します。このフィールドは、send()の前にアプリケーションによって設定されます。プロデューサに設定されるか、アプリケーションがsend()に送信するパラメータとして設定されるtimeToLiveに依存します。

JMSExpirationの値は、アプリケーションの存続時間とその時点のGMTの合計として算出されます。アプリケーションで存続時間が0として指定されると、JMSExpirationは0に設定され、メッセージは無期限になります。

期限の切れたメッセージは、誤って配信されないようにシステムから削除されます。

send()メソッド

JMSMessageID

JMSプロバイダによって送信される各メッセージを一意に識別する文字列値を格納します。このフィールドは、send()によって内部的に設定されます。

すべてのJMSMessageIDID:という接頭辞で始まります。

この値は、producer.send()への呼出しによって上書きされます。この値をメッセージに直接設定しても無効となります。プロデューサによって設定された値は、producer.send()に提供されたメッセージを使用して問い合わせるか、コンシューマがメッセージを受信したときに問い合わせることができます。メッセージが受信されるときには、プロバイダの割り当てた値が格納されています。

send()メソッド

JMSPriority

優先度のレベルを指定します。このフィールドは、プロデューサに設定されるか、send()の前にアプリケーションによって送信されるパラメータとして設定されます。

JMSでは、0 - 9の10段階で優先度が定義されています(0が最低の優先度)。レベル0 - 4は通常の範囲に属し、レベル5 - 9は至急の範囲に属します。

メッセージが受信されるときには、メッセージを送信するメソッドで指定された値が格納されています。

宛先キーを構成すれば、優先度を基準に宛先をソートできます。詳細は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプ宛先キーの構成に関する項を参照してください。

send()メソッド

JMSRedelivered

確認応答がないためメッセージが再配信されるときに設定されるフラグを指定します。このフラグは受信側アプリケーションに関係があります。

フラグが設定されている場合は、以下のいずれかの理由のために、同じメッセージが以前に配信されている可能性があります。

  • アプリケーションではすでにメッセージが受信されていますが、確認応答が行われていません。

  • セッションのrecover()メソッドが呼び出されて、最後に確認応答されたメッセージの後からセッションが再起動されました。recover()メソッドの詳細は、「受信メッセージの回復」を参照してください。

WebLogic JMS

JMSReplyTo

応答メッセージが送信されるキューまたはトピックを指定します。このフィールドは、send()の前に、アプリケーションによって直接メッセージに設定されます。

この機能はJMSCorrelationIDヘッダー・フィールドと共に使用してリクエストとレスポンスのメッセージを連係させることができます。

JMSReplyToフィールドをただ設定するだけでは、受信側アプリケーションの応答が有効になるだけで、レスポンスが保証されるわけではありません。

アプリケーション

JMSTimestamp

メッセージが送信されたときの時刻を格納します。タイムスタンプは、アプリケーションでメッセージが送信されたときではなく、WebLogic JMSで配信用にメッセージが受け付けられたときにメッセージに書き込まれます。

メッセージが受信されるときには、タイムスタンプが格納されています。

このフィールドには、Javaのミリ時間の値が格納されます。

WebLogic JMS

JMSType

send()の前にアプリケーションによって直接メッセージに設定されたメッセージ・タイプ識別子(String)を示します。

JMS仕様では、多様なJMSプロバイダに適応するため、このフィールドに若干の柔軟性を持たせています。一部のメッセージング・システムでは、アプリケーション固有のメッセージ・タイプを使用できます。そのようなシステムの場合、JMSTypeフィールドは、格納されている型定義にアクセスするためのメッセージ・タイプIDを保持するために使用できます。

WebLogic JMSでは、このフィールドの使用に制限を設けていません。

アプリケーション


メッセージ・プロパティ・フィールド

メッセージのプロパティ・フィールドには、送信側アプリケーションによって追加されたヘッダー・フィールドが格納されます。プロパティは、標準的なJavaの名前と値の組合せです。プロパティ名は、javax.jms.MessageのJavadoc (http://download.oracle.com/javaee/5/api/javax/jms/Message.html)で定義されているメッセージ・セレクタの構文仕様に準拠していなければなりません。有効な値は、boolean、byte、double、float、int、long、およびStringです。

WebLogic Serverは、JMS 1.1で定義されているとおり次のJMS (JMSX)定義プロパティの使用をサポートします。仕様はhttp://www.oracle.com/technetwork/java/jms/index.htmlにあります。

表2-11 JMSXプロパティ

タイプ 説明

JMSXUserID

メッセージの送信者であるユーザーを識別するシステム生成のプロパティ。「JMSXUserIDプロパティの使用」を参照してください。

JMSXDeliveryCount

メッセージの配信試行回数を指定するシステム生成のプロパティ。1回目の試行を1とします。

JMSXGroupID

メッセージ・グループのID。

JMSXGroupSeq

グループ内のメッセージの連続番号。


メッセージ・プロパティ・フィールドは、アプリケーション固有の目的に使用できますが、それらは基本的にはメッセージ・セレクタで使用するために用意されています。JMSプロパティをそれぞれの環境でどのように使用するかはユーザーが決定します。たとえば、処理条件に応じて一部のメッセージにだけ含め、その他のメッセージでは省略することもできます。詳細については、以下を参照してください。

メッセージ本文

メッセージ本文は、プロデューサからコンシューマに配信される内容です。

次の表は、JMSで定義されているメッセージ・タイプを説明しています。すべてのメッセージ・タイプは、メッセージ・ヘッダーとメッセージ・プロパティ(メッセージ本文はなし)で構成されるjavax.jms.Message (http://download.oracle.com/javaee/5/api/javax/jms/Message.html)を拡張します。

表2-12 JMSメッセージ・タイプ

タイプ 説明
javax.jms.BytesMessage

未解釈バイトのストリーム。センダーとレシーバによって理解されなければなりません。このメッセージ・タイプのアクセス・メソッドは、java.io.DataInputStreamおよびjava.io.DataOutputStreamに基づくストリーム対応のリーダーとライター。http://download.oracle.com/javaee/5/api/javax/jms/BytesMessage.htmlを参照してください。

javax.jms.MapMessage

名前が文字列であり、値がJavaプリミティブ型である、複数の名前と値の組合せ。名前と値の組合せは、名前を指定することによって順次的にもランダムにも読み込むことができます。

javax.jms.ObjectMessage

1つのシリアライズ可能なJavaオブジェクト。http://download.oracle.com/javaee/5/api/javax/jms/ObjectMessage.htmlを参照してください。

javax.jms.StreamMessage

Javaプリミティブ型のみがストリームで読み書きされること以外は、BytesMessageと同じです。http://download.oracle.com/javaee/5/api/javax/jms/StreamMessage.htmlを参照してください。

javax.jms.TextMessage

1つのString。TextMessageではXMLコンテンツも格納できます。http://download.oracle.com/javaee/5/api/javax/jms/TextMessage.htmlを参照してください。

weblogic.jms.extensions.XMLMessage 

XMLコンテンツ。XMLMessageタイプを使用すると、TextMessageで送信されるXMLコンテンツでは処理しにくいメッセージのフィルタ処理を容易に行うことができます。


詳細は、javax.jms.MessageのJavadoc (http://download.oracle.com/javaee/5/api/javax/jms/Message.html)を参照してください。特定のメッセージ・タイプのアクセス・メソッドや変換チャートについては、そのメッセージ・タイプのJavadocを参照してください。

ServerSessionPoolFactory


注意:

セッション・プールおよび接続コンシューマの構成オブジェクトは、WebLogic Serverの本リリースでは非推奨となっています。これらは、Java EE仕様の必須コンポーネントではなく、JTAユーザー・トランザクションもサポートしていないためです。かわりに、より単純で可用性が高く、管理も容易なメッセージドリブンBean (MDB)が主に使用されています。MDBの設計の詳細は、『Oracle WebLogic Server Enterprise JavaBeansバージョン2.1のプログラミング』のメッセージドリブン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アプリケーション・サーバー・オブジェクトでは、メッセージを並行処理するために接続コンシューマで取り出すことができるサーバー・セッションのプールが提供されます。

ServerSessionPoolは、JNDIルックアップで取得されるServerSessionPoolFactoryオブジェクト(「ServerSessionPoolFactory」を参照)によって作成されます。

アプリケーションでサーバー・セッション・プールを使用する方法については、「サーバー・セッション・プールの定義」またはjavax.jms.ServerSessionPoolのJavadoc (http://download.oracle.com/javaee/5/api/javax/jms/ServerSessionPool.html)を参照してください。

ServerSession

ServerSessionアプリケーション・サーバー・オブジェクトでは、メッセージを作成、送信、および受信するためのコンテキストが提供され、スレッドとJMSセッションを関連付けることができます。

ServerSessionは、ServerSessionPoolオブジェクト(「ServerSessionPool」を参照)によって作成されます。

アプリケーションでサーバー・セッション・プールを使用する方法については、「サーバー・セッション・プールの定義」またはjavax.jms.ServerSessionのJavadoc (http://download.oracle.com/javaee/5/api/javax/jms/ServerSession.html)を参照してください。

ConnectionConsumer

ConnectionConsumerオブジェクトでは、サーバー・セッションを使用して受信メッセージを処理します。メッセージ・トラフィックが大きい場合は、スレッド・コンテキストの切替えを最小限に抑えるために、接続コンシューマでは複数のメッセージで各サーバー・セッションをロードすることができます。ConnectionConsumerは、Connectionオブジェクト(「Connection」を参照)によって作成されます。

アプリケーションで接続コンシューマを使用する方法については、「サーバー・セッション・プールの定義」またはjavax.jms.ConnectionConsumerのJavadoc(http://download.oracle.com/javaee/5/api/javax/jms/ConnectionConsumer.html)を参照してください。


注意:

接続コンシューマ・リスナーは、サーバーと同じJVMで動作します。