3 JMSメッセージに対するSAFの構成

この項では、JMS SAF (ストア・アンド・フォワード)機能は、WebLogic SAFサービス上に構築され、高可用性を備えたJMSメッセージ生産を行う方法について説明します。たとえば、ローカルのサーバー・インスタンスに接続されたJMSメッセージ・プロデューサは、メッセージ送信時にリモートのJMS宛先が一時的に使用できない場合でも、そのリモート宛先に確実にメッセージを転送できます。JMS SAFはJMSアプリケーションからは透過的なので、JMSクライアント・コードは既存のJMS APIを使用して、リモート宛先にアクセスできます。

以下の節では、構成の詳細について説明します。

JMSモジュールのSAFリソース
JMS SAFリソースの作成
JMS宛先のSAFリソースを構成する主な手順

JMSメッセージに対するSAFの設計

注意:

WebLogic SAFクライアントが提供するメカニズムにより、ネットワークに接続できない(一時的なエラー、ネットワーク障害など)ためにSAFクライアントがJMS宛先にアクセスできない場合でも、スタンドアロン・クライアントはサーバー側のJMS宛先にJMSメッセージを確実に送信できます。接続が切断されている間、SAFクライアントによって送信されたメッセージはクライアント上でローカルに格納され、クライアントが再接続されたときにサーバー側のJMS宛先に転送されます。『Oracle WebLogic Serverスタンドアロン・クライアントの開発』のJMS SAFクライアントによる確実なメッセージ送信に関する項を参照してください。

JMSモジュールのSAFリソース

JMS構成リソースは、WebLogicドメインの外部のモジュール記述子ファイルに格納されます。これらのファイルは、weblogic-jmsmd.xsdスキーマに準拠するXMLドキュメントによって定義されます。JMSモジュールには、WebLogic ServerでのJMSメッセージの格納と転送を可能にする、SAFリソースの構成も含まれます。JMSモジュールの詳細は、『Oracle WebLogic Server JMSリソースの管理』のJMSリソースの構成の理解に関する項を参照してください。

JMSモジュールに対してSAFリソースを構成する場合には、JMSシステム・モジュールまたはアプリケーション・モジュールで以下のリソースを構成する必要があります。

SAFインポート済み宛先
SAFリモート・コンテキスト
SAFエラー処理

JMS SAFリソースが構成されると、構成されたSAF送信エージェントによって、受信側へのメッセージの転送、確認応答が時間内に戻らなかった場合のメッセージの再送信、およびメッセージの永続性が必要になる場合の永続ストレージへのメッセージの一時的な格納が行われます。SAFエージェントの構成の詳細は、第2章「ストア・アンド・フォワード・サービスの理解」を参照してください。

JMS SAFはJMSアプリケーションからは透過的です。既存のJMSアプリケーションは、コードを変更することなく、この機能を利用できます。実際には、JMSモジュールでインポート済みJMS宛先を構成し、その後、リモートのJMS宛先をローカルのJNDI名に関連付ける必要があるだけです。JMSクライアント・コードは既存のJMS APIを使用して、インポート済み宛先にアクセスします。メッセージの生産のみがJMSストア・アンド・フォワードの対象となるので、JMSクライアントは引き続き、インポート済み宛先から直接メッセージを消費する必要があります。

SAFインポート済み宛先

SAF宛先(キューまたはトピック)は、リモートのサーバー・インスタンスやクラスタに関連付けられたJMSモジュール内のJMS宛先(キューまたはトピック)をローカルに表現したものです。このようなリモート宛先は、ローカルのクラスタやサーバー・インスタンスに「インポート」されます。これにより、ローカルのサーバー・インスタンスやクラスタから、リモートのサーバー・インスタンスやクラスタにメッセージを送信することが可能になります。宛先に対する「SAFエクスポート・ポリシー」パラメータが明示的に無効化されていない限り、デフォルトではすべてのJMS宛先が自動的にエクスポートされます。

インポートされたSAF宛先の集合は、SAFインポート済み宛先と呼ばれます。インポート済み宛先の各集合は、SAFリモート・コンテキストと関連付けられます。また、それらは同じJNDI接頭辞、存続時間のデフォルト(メッセージの有効期限)、およびSAFエラー処理オブジェクトを共有します。

JMSプロデューサがSAF宛先にメッセージを送信すると、これらのメッセージは後の配信に備えてSAF宛先に格納されます。SAFエージェントは、(インポート済み宛先が表す)リモートJMS宛先へ、その宛先がアクセス可能であればSAFリモート・コンテキストを使用してメッセージを転送します。

SAFリモート・コンテキスト

SAFリモート・コンテキストでは、JMS宛先のエクスポート元である、リモートのサーバー・インスタンスまたはクラスタのURLが定義されます。また、リモート・クラスタまたはサーバーで認証および認可されるセキュリティ資格証明も含まれます。インポート済み宛先を使用する場合は、SAFリモート・コンテキストの構成が必須です。SAFリモート・コンテキストは、複数のSAFインポート済み宛先の構成で再利用できます。

次に示すURLは、SAFリモート・コンテキストで、スタンドアロンJMS宛先をインポートするリモート管理対象サーバーを1つ定義した場合の例です。

<URL>
t3://123.0.0.1:7001
</URL>

リモート・クラスタから分散宛先をインポートする場合は、DNSサーバー名またはIPアドレスをカンマで区切って指定します。次に示すURLは、SAFリモート・コンテキストで、分散宛先のメンバーをインポートするリモート・クラスタを定義した場合の例です。

<URL>
t3://123.0.0.1:7001,123.0.0.1:7002,123.0.0.1:7003
</URL>

WebLogicクラスタとの最初の接続ポイントを指定する方法は、『Oracle WebLogic Server JNDIアプリケーションの開発』のクラスタ環境でのWebLogic JNDIの使用に関する項を参照してください。

SAFエラー処理

SAFエラー処理リソースでは、SAFサービスがリモート宛先へのメッセージ転送に失敗した場合に行うアクションを定義します。SAFエラー処理リソースは、SAFインポート済み宛先を使用する場合でも必須ではありませんが、ベスト・プラクティスとしてお薦めします。

構成オプションには、以下のパラメータが含まれます。

エラー処理ポリシー:
- 「破棄」 - デフォルトでは、期限切れのメッセージは単にシステムから削除されます。削除はログに記録されず、メッセージは別の場所にリダイレクトされません。
- 「ログ」 - 期限切れのメッセージを削除し、メッセージがシステムから削除されたことを示すエントリをサーバー・ログ・ファイルに書き込みます。実際にログに記録される情報は、「ログ・フォーマット」フィールドで定義します。
- 「リダイレクト」 - 期限切れのメッセージを現在の位置から、インポート済みのSAF宛先に定義されているエラー宛先へ移動します。
- 「常に転送」 - インポート済みの宛先に対して設定されたSAFデフォルト存続時間と、メッセージに対して設定された存続時間を無視するので、期限が切れた後でもメッセージをリモート宛先へ転送します。このオプションは、アプリケーションでリモート宛先に有効期限ポリシーが設定されていても、それらのメッセージをリモート宛先の有効期限プロセスで処理したい場合に便利です。
「ログ・フォーマット」 - 「ログ」ポリシーを選択した場合は、このフィールドを使用して、メッセージのどの情報をログに記録するかを定義します。
「エラー宛先」 - 「リダイレクト」ポリシーを選択した場合は、このフィールドを使用して、期限切れメッセージをリダイレクトするローカルのSAF宛先を選択します。

SAF JMSの仕組み

図3-1に、Domain1のDomain1Module-jms.xmlモジュール内のQueueSendキューに生成されたJMSメッセージが、SAFエージェントによってDomain2のDomain2Module-jms.xmlモジュール内のQueueReceiveキューに転送される仕組みを示します。

図3-1 JMSメッセージのストア・アンド・フォワード

「図3-1 JMSメッセージのストア・アンド・フォワード」の説明

JMS SAFリソースの作成

JMSモジュールのSAFリソースは、以下のいずれかの方法で作成できます。

WebLogic Server管理コンソールを使用します。これにより、使用している環境のJMSシステム・モジュールおよびJMSシステム・リソースを構成、変更、ターゲット指定、モニター、および削除できます。JMS SAFリソースの構成の手順は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのJMS SAFの構成に関する項を参照してください。
WebLogic Scripting Tool (WLST)を使用します。これにより、JMSサーバーとJMSシステム・リソースを作成および管理できます。詳細は、『Oracle WebLogic Server JMSリソースの管理』のWLSTを使用したJMSサーバーとJMSシステム・モジュール・リソースの管理に関する項を参照してください。
WebLogic Java Management Extensions (JMX)を使用します。これにより、SAFImportedDestinationsBean、SAFRemoteContextBean、およびSAFErrorHandlingBean管理MBeanにアクセスして、JMSモジュールのSAFリソースを作成および管理できます。詳細は、『Oracle WebLogic Server JMXによるカスタム管理ユーティリティの開発』のWebLogic ServerサブシステムMBeanの概要に関する項を参照してください。
JMSモジュール・ヘルパー拡張APIを使用します。これにより、JMS実行時MBeanの検索と、特定のモジュール内のJMSシステム・モジュール構成リソースの管理(検索、作成、削除)を行うことができます。詳細は、『Oracle WebLogic Server JMSアプリケーションの開発』のJMSモジュール・ヘルパーを使用したアプリケーションの管理に関する項またはOracle WebLogic Server Java APIリファレンスのJMSModuleHelperに関する項を参照してください。

JMS宛先のSAFリソースを構成する主な手順

管理コンソールを使用して、リモート宛先にJMSメッセージを転送するためにSAFリソースを構成する主な手順は次のとおりです。

送信側のローカル・ドメインでSAF送信エージェントを構成します。Oracle WebLogic Server管理コンソール・オンライン・ヘルプのストア・アンド・フォワード・エージェントの作成に関する項を参照してください。
必要に応じて、送信側と受信側の両方でJMS宛先リソースを格納するJMSシステム・モジュールを作成します。Oracle WebLogic Server管理コンソール・オンライン・ヘルプのJMSシステム・モジュールの構成に関する項を参照してください。

詳細は、『Oracle WebLogic Server JMSリソースの管理』のJMSシステム・モジュールに関する項を参照してください。
送信側のJMSモジュールで、リモート・キューまたはトピックのエクスポート元である受信側のURLを定義するSAFリモート・コンテキスト・リソースを構成します。手順は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのSAFリモート・コンテキストの作成に関する項を参照してください。
必要に応じて、送信側のJMSモジュールで、SAFサービスがリモート宛先へのメッセージ転送に失敗した場合に行うアクションを定義するSAFエラー処理構成を構成します。手順は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのSAFエラー処理リソースの作成に関する項を参照してください。
送信側のJMSモジュールで、SAFインポート済宛先を構成し、それをモジュールで作成したSAFリモート・コンテキストおよびSAFエラー処理リソースに関連付けます。手順は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのJMSシステム・モジュールにおけるSAFインポート済宛先の作成に関する項を参照してください。
作成したSAFインポート済み宛先を再び開いて、受信側のリモート・キューまたはトピックを表すSAFキューまたはトピックを構成します。SAFキューまたはトピックは、リモート・キューまたはトピックと同じJNDI名を使用します。手順については、以下を参照してください。
- Oracle WebLogic Server管理コンソール・オンライン・ヘルプのSAFキューの作成に関する項
- Oracle WebLogic Server管理コンソール・オンライン・ヘルプのSAFトピックの作成に関する項
デフォルトでは、すべてのJMS宛先は、SAFインポート済み宛先としてアクセス可能です。ただし、宛先のSAFエクスポート・ポリシーのパラメータ値を「なし」に変更することで、その宛先をエクスポートしないように明示的に指定できます。これで、リモート・ユーザーは、ストア・アンド・フォワードを使用して宛先にメッセージを送信できなくなります。

JMSメッセージに対するSAFの設計

以下の節では、JMSメッセージを格納および転送するためにWebLogic SAFを設計および構成する場合に役立つ情報について説明します。

サービスの品質(QOS)レベルの選択

永続JMSメッセージは、SAFサービスによって常に「必ず1回」のQOSで転送されます。非永続メッセージでは、SAFインポート済みキューとトピックに対して以下の3種類のQOSレベルを定義できます。

「必ず1回」 - もっとも高レベルのQOS。メッセージがリモート・エンドポイントに1回だけ送信されます。「必ず1回」を指定すると、サーバーのクラッシュ時やネットワークのダウン時にもメッセージは存続し、各メッセージがエンドポイントに1つだけ存在する状態にできます。
「1回以上」 - メッセージはリモート・エンドポイントに少なくとも1回は転送されますが、重複する可能性があります。「1回以上」を指定すると、メッセージの転送中に発生したネットワーク障害やサーバーのクラッシュにより、そのメッセージの複数のコピーがリモートのエンドポイントに現れることがあります。
「最大1回」 - もっとも低レベルのQOS。各メッセージがリモート・エンドポイントに(送信できた場合には) 1回だけ送信されます。メッセージが重複してエンドポイントに届くことはありません。「最大1回」を指定していると、ネットワーク障害やサーバーのクラッシュによってメッセージが失われることがあります。メッセージが重複してエンドポイントに届くことはありません。

SAFによる配信モードの処理方法

SAFアプリケーションでは、メッセージごとに配信モードを指定することもできます。

永続メッセージは、受信側に正常に転送され、確認応答されるまで送信側の永続ストアに保存されます。
非永続メッセージは、受信側がそれらを確認応答するまで送信側のメモリー内に存在し続けます(つまり、非永続メッセージは送信側がクラッシュすると失われるおそれがあります)。

メッセージ順序単位の使用

クラスタ内では、JMSプロデューサをメッセージ順序単位に関連付けることができます。これにより、スタンドアロンのメッセージ・プロデューサまたは1つのプロデューサとして機能するプロデューサのグループは、処理順序に関して複数のメッセージを1つの単位にグループ化できるようになります。JMS順序単位の詳細は、『Oracle WebLogic Server JMSアプリケーションの開発』のメッセージ順序単位の使用に関する項を参照してください。

SAFインポート済宛先ではハッシュ・マップまたはパス・サービスのいずれかを使用して、クラスタ内の順序付けされたメッセージをグループ化できます。ただし、パス・サービスを構成するのがベスト・プラクティスです。パス・サービスは、メッセージのグループとメッセージング・リソース(SAFエージェントなど)との間のマッピングを格納できる永続マップです。パス・サービスの構成の詳細は、『Oracle WebLogic Server JMSリソースの管理』のWebLogicパス・サービスの使用に関する項を参照してください。

トランザクション・メッセージ

アプリケーションのメッセージがトランザクション内にある場合、「必ず1回」のセマンティクスを維持するために、永続ストレージへのメッセージの保存はそのユーザー・トランザクションの一環として行われます。

特に、メッセージの永続ストレージからの削除は、アプリケーションでトランザクションのロールバックが決定された場合にトランザクション・ロールバックの一環として行われます。一方、転送はアプリケーション・トランザクションの一環としては行われません。トランザクションがコミットされるまで、トランザクション・メッセージは送信エージェントによって転送されません。トランザクション内では、メッセージの順序はメッセージが送信された時間に基づいて保持されます。

SAF境界を越えるメッセージの圧縮

JMSストア・アンド・フォワードでは、別々のクラスタ間でメッセージが転送される場合、メッセージを圧縮できます。メッセージ圧縮のしきい値は、WLMessageProducerインタフェースのJMS API拡張機能を使用することによってプログラム的に設定するか、接続ファクトリまたはJMS SAFリモート・コンテキストで「デフォルト圧縮しきい値」を指定することによって管理的に設定できます。

JMSメッセージ圧縮の使用の詳細は、『Oracle WebLogic Serverのパフォーマンスのチューニング』のメッセージの圧縮に関する項を参照してください。

SAFリモート・コンテキストの圧縮しきい値を超える非圧縮メッセージは、SAF境界を越えて転送されるときに圧縮されます。メッセージは、リモート・エンドポイントで受信されるまで、圧縮されたままです。接続ファクトリで圧縮が有効になっているためにSAF境界を越えるときにメッセージがすでに圧縮されている場合は、SAF圧縮がトリガーされるかどうかに関係なく、メッセージは圧縮されたままSAF境界を越えて転送されます。

分散宛先に対するSAF

リモート・エンドポイントは分散宛先であってもかまいません。一般的に、リモート分散宛先へのメッセージは、スタンドアロンのリモート宛先に転送されるメッセージと同様に格納および転送されます。しかし、ロード・バランシングは他の分散宛先と別に処理されます。詳細は、「SAFロード・バランシング」を参照してください。

分散宛先の構成の詳細は、『Oracle WebLogic Server JMSリソースの管理』の分散宛先の構成に関する項を参照してください。

SAFロード・バランシング

ロード・バランシングでは、メッセージがインポート済のSAF宛先に送信される場合、またはリモート宛先に転送される場合のメッセージ経路が決定されます。SAFメッセージのメッセージ経路を決定するようWebLogic Serverを構成する際には、次の2つの状況を考慮してください。

インポート済宛先へのメッセージの送信
SAFエージェントによるリモート宛先へのメッセージの転送

インポート済宛先へのメッセージの送信

JMSクライアントによって送信されたメッセージは、次のいずれかのメッセージ経路を使用して、インポート済宛先にロード・バランシングされます。

単一のSAFエージェントの場合、ロード・バランシングは通常のJMS宛先への送信と同様に処理されます。
複数のSAFエージェントの場合、インポート済宛先は分散宛先と同様に機能します。接続ファクトリのロード・バランシング設定に従って、メッセージが複数のSAFエージェントにロード・バランシングされます。「接続と接続ファクトリ」を参照してください。

SAFエージェントによるリモート宛先へのメッセージの転送

メッセージの転送は、各SAFエージェントが個別に行います。この場合、メッセージを転送するSAFエージェントはロード・バランシングの対象とならず、メッセージ経路は宛先タイプによって決まります。

宛先が分散されていない通常の宛先の場合、ロード・バランシングやフェイルオーバーは行われません。
ターゲットとなる宛先が分散宛先の場合、メッセージ経路とフェイルオーバーの動作は、順序単位が設定されていないExactly-onceメッセージ(persistentまたはnon-persistentで、QoSがExactlyOnceのメッセージ)に対するSAFエージェントの構成によって決まります。メッセージ経路は、使用可能な分散宛先メンバーのリストの中から、ラウンドロビン方式のロード・バランシング・メッセージによって決定されます。使用できなくなったメンバーは、リストから動的に削除されます。使用可能になったメンバーは、リストに動的に追加されます。

単一メッセージの観点から、フェイルオーバーは行われません。SAFエージェントが宛先メンバーへのメッセージの配信に失敗した場合、別のメンバーに再配信するのではなく、元のメンバーへの配信を定期的に再試行します。ExactlyOnce QoSを維持するため、メッセージのターゲット・メンバーは変更されません。
その他すべてのメッセージ・タイプについては、デフォルト接続ファクトリ(loadBalancingEnabled=trueおよびserverAffinityEnabled=true)によってメッセージ経路が決まります。

注意:

JMS接続ファクトリのデフォルト設定は変更もオーバーライドもできません。

SAFでのJMSReplyToフィールドの使用

一般的に、JMSアプリケーションはJMSReplyToヘッダー・フィールドを使用して、一時的な宛先の名前を他のアプリケーションに対して公開できます。ただし、JMSReplyToフィールドを使用した一時的な宛先の使用は、SAFインポート済み宛先ではサポートされていません。

JMS一時宛先の使用の詳細は、『Oracle WebLogic Server JMSアプリケーションの開発』の一時的な宛先の使用に関する項を参照してください。

SAF宛先の保護

SAFインポート済み宛先では、以下のセキュリティ対策が適用されています。

SAFインポート済キューとトピックに対してセキュアなロールとポリシーを設定できます。ロールとポリシーの構成の詳細は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプの次の項を参照してください。
SAFサービスでは、メッセージのJMSXUserIDがSAF境界を越えて保持されることはありません。JMSXUserIDとは、メッセージの送信者であるユーザーを識別するシステム生成のプロパティです。JMSXUserIDは、公開しているJMS仕様(http://www.oracle.com/technetwork/java/jms/index.html)で定義されています。

接続と接続ファクトリ

JMSメッセージは、クライアントから接続ホストを通じて、WebLogic JMSサーバーまたはSAFエージェントがホストするJMS宛先インスタンスへと転送されます。クライアントは、JNDIを使用して接続ファクトリを取得し、それを使用してWebLogicへのJMS接続を作成します。各接続インスタンスは、特定のWebLogicサーバー(接続ホスト)に関連付けられています。

接続ファクトリとは、クライアント接続の構成パラメータを定義するもので、クライアントの宛先と同じサーバーまたはクラスタでホストされる必要があります。WebLogic JMSは、デフォルト接続ファクトリとカスタム接続ファクトリを提供します。デフォルト接続ファクトリは構成できません。一方、カスタム接続ファクトリは構成可能ですが、デフォルト接続ファクトリと同じJNDI名では構成できません。接続ファクトリは、WebLogicクラスタ内の1つ以上のサーバーでホストできます。

デフォルト接続ファクトリは、常にクラスタ内のすべてのサーバーでホストされます。
カスタム接続ファクトリのホストは、ターゲット構成に基づいて設定されます。

クライアントの接続ファクトリ・インスタンスは、実際にはWebLogic RMIのレプリカ対応スタブであり、接続ファクトリをホストするすべてのアクティブ・サーバーを暗黙的に追跡します。サーバーがクラスタ内で利用可能および利用不可になると、接続ファクトリ・インスタンスはこの情報で自動的に更新されます。クライアントが、接続ファクトリ・インスタンスを使用して接続を作成すると、いずれかのサーバーがクライアントの接続ホストとなります。接続ホストは接続の存続期間中ずっと変わりません。

分散宛先およびインポート済宛先に対するプロデューサのロード・バランシング動作をチューニングする接続ファクトリ設定が2つあります。

Server Affinity: 接続ホストが存在する場合に、送信リクエストを分散宛先またはインポート済宛先のすべてのメンバーではなく、接続ホストのローカル・メンバーの間でのみロード・バランシングするかどうかを指定します。デフォルトでは有効になっています。
Load Balancing: 非匿名のプロデューサを呼出しごとにメンバー間でロード・バランシングするかどうかを指定します。有効にすると、メッセージはsend()またはpublish()ごとにすべてのメンバーの間でロード・バランシングされます。無効にすると、最初のsend()またはpublish()でロード・バランシングの決定が行われ、その後のメッセージはすべて同じ宛先に送信されます。デフォルトでは有効になっています。

注意:

Server AffinityとLoad Balancingは、次の場合には無視されます。

通常の宛先への生成の場合。
順序単位および作業単位のメッセージに対して使用し、順序に関するサービス品質を厳密に維持する場合。