Oracle® Fusion Middleware

Oracle WebLogic Server JMSリソースの管理

12c (12.2.1.2.0)

E82889-02(原本部品番号:E77972-03)

2016年12月

このドキュメントは、JMSサーバー、スタンドアロンの宛先(キューとトピック)、分散宛先、接続ファクトリなどのWebLogic JMSリソースの構成、管理、およびモニターを担当するシステム管理者を対象としています。

Oracle Fusion Middleware Oracle WebLogic Server JMSリソースの管理, 12c (12.2.1.2.0)

E82889-02

Copyright © 2007, 2016, Oracle and/or its affiliates All rights reserved.

このソフトウェアおよび関連ドキュメントの使用と開示は、ライセンス契約の制約条件に従うものとし、知的財産に関する法律により保護されています。ライセンス契約で明示的に許諾されている場合もしくは法律によって認められている場合を除き、形式、手段に関係なく、いかなる部分も使用、複写、複製、翻訳、放送、修正、ライセンス供与、送信、配布、発表、実行、公開または表示することはできません。このソフトウェアのリバース・エンジニアリング、逆アセンブル、逆コンパイルは互換性のために法律によって規定されている場合を除き、禁止されています。

ここに記載された情報は予告なしに変更される場合があります。また、誤りが無いことの保証はいたしかねます。誤りを見つけた場合は、オラクル社までご連絡ください。

このソフトウェアまたは関連ドキュメントを、米国政府機関もしくは米国政府機関に代わってこのソフトウェアまたは関連ドキュメントをライセンスされた者に提供する場合は、次の通知が適用されます。

U.S. GOVERNMENT END USERS: Oracle programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, delivered to U.S. Government end users are "commercial computer software" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations. As such, use, duplication, disclosure, modification, and adaptation of the programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, shall be subject to license terms and license restrictions applicable to the programs. No other rights are granted to the U.S. Government.

このソフトウェアもしくはハードウェアは様々な情報管理アプリケーションでの一般的な使用のために開発されたものです。このソフトウェアもしくはハードウェアは、危険が伴うアプリケーション(人的傷害を発生させる可能性があるアプリケーションを含む)への用途を目的として開発されていません。このソフトウェアもしくはハードウェアを危険が伴うアプリケーションで使用する際、安全に使用するために、適切な安全装置、バックアップ、冗長性(redundancy)、その他の対策を講じることは使用者の責任となります。このソフトウェアもしくはハードウェアを危険が伴うアプリケーションで使用したことに起因して損害が発生しても、オラクル社およびその関連会社は一切の責任を負いかねます。

OracleおよびJavaはOracle Corporationおよびその関連企業の登録商標です。その他の名称は、それぞれの所有者の商標または登録商標です。

Intel、Intel Xeonは、Intel Corporationの商標または登録商標です。すべてのSPARCの商標はライセンスをもとに使用し、SPARC International, Inc.の商標または登録商標です。AMD、Opteron、AMDロゴ、AMD Opteronロゴは、Advanced Micro Devices, Inc.の商標または登録商標です。UNIXは、The Open Groupの登録商標です。

このソフトウェアまたはハードウェア、そしてドキュメントは、第三者のコンテンツ、製品、サービスへのアクセス、あるいはそれらに関する情報を提供することがあります。適用されるお客様とOracle Corporationとの間の契約に別段の定めがある場合を除いて、Oracle Corporationおよびその関連会社は、第三者のコンテンツ、製品、サービスに関して一切の責任を負わず、いかなる保証もいたしません。適用されるお客様とOracle Corporationとの間の契約に定めがある場合を除いて、Oracle Corporationおよびその関連会社は、第三者のコンテンツ、製品、サービスへのアクセスまたは使用によって損失、費用、あるいは損害が発生しても一切の責任を負いかねます。

目次

タイトルおよび著作権情報

はじめに

- ドキュメントのアクセシビリティについて

- 表記規則

1 概要とロードマップ

- ドキュメントのスコープおよび対象読者

- このドキュメントの手引き

- 関連ドキュメント

- JMS管理者向けのサンプルとチュートリアル

- Avitek Medical Recordsアプリケーション(MedRec)とチュートリアル

- WebLogic Server配布キットのJMSサンプル

- WebLogic Serverの付加価値JMS機能

- エンタープライズ・レベルの信頼性

- エンタープライズ・レベルの機能

- パフォーマンス

- WebLogic Serverとの緊密な統合

- 他のメッセージング・サービスとの相互運用性

- JMSに関する新機能と変更された機能

- WebLogic Server 12.2.1の新しく変更された機能

2 JMSリソースの構成の理解

- JMSとOracle WebLogic Serverの概要

- Java Message Serviceとは

- WebLogic JMSのアーキテクチャと環境

- ドメインの構成

- JMS構成リソースとは

- JMSサーバーの概要

- WebLogic Server 9.x以降でのJMSサーバーの動作

- JMSモジュールの概要

- JMSシステム・モジュール

- JMSアプリケーション・モジュール

- JMSシステム・モジュールとアプリケーション・モジュールを比較する

- モジュールに構成できるJMSリソース

- JMSスキーマ

- JMS相互運用モジュール(非推奨)

- WebLogic JMSの他の環境関連システム・リソース

- 永続ストア

- JMSストア・アンド・フォワード

- パス・サービス

3 基本JMSシステム・リソースの構成

- JMSシステム・リソースの構成方法

- 基本JMSシステム・リソースの構成の主な手順

- JMSシステム・モジュールの拡張リソース

- JMS構成のネーミング要件

- JMSサーバーの構成

- JMSサーバーの構成パラメータ

- JMSサーバーのターゲット指定

- JMSサーバーのモニター・パラメータ

- セッション・プールと接続コンシューマ

- JMSシステム・モジュールの構成

- JMSシステム・モジュールとリソースのサブデプロイメントのターゲット指定

- デフォルトのターゲット指定

- 高度な(サブデプロイメント)ターゲット指定

- 接続ファクトリのマップされないリソース参照モードの指定

- 接続ファクトリの構成

- Java EE 7で定義されているデフォルトのJMS接続ファクトリの使用

- WebLogic Serverで定義されたデフォルト接続ファクトリの使用

- 接続ファクトリの構成パラメータ

- 接続ファクトリのターゲット指定

- キューおよびトピック宛先の構成

- キューおよびトピックの構成パラメータ

- エラー宛先を作成する

- 分散宛先を作成する

- キューおよびトピックのターゲット指定

- 宛先のモニターと管理パラメータ

- JMSテンプレートの構成

- JMSテンプレートの構成パラメータ

- 宛先キーの構成

- 割当ての構成

- 外部サーバーの構成

- 分散宛先の構成

- JMSストア・アンド・フォワード(SAF)の構成

4 拡張JMSシステム・リソースの構成

- WebLogic JMSクラスタリングの構成

- JMSクラスタリングの利点

- JMSクラスタリングの仕組み

- JMSクラスタリングのネーミング要件

- クラスタ内での分散宛先

- クラスタ内での移行可能なサービスとしてのJMSサービス

- JMSクラスタリングの構成のガイドライン

- フェイルオーバーの場合

- JMS関連サービスの移行

- JMSサービスの自動移行

- JMSサービスの手動移行

- 永続ストアの高可用性

- WebLogicパス・サービスの使用

- パス・サービスによる高可用性

- メッセージUOOとパス・サービスの実装

- 外部サーバー・リソースからサード・パーティJMSプロバイダへのアクセスの構成

- WebLogic JMSから外部JMSプロバイダへのアクセス

- 外部サーバー・リソースを作成する

- 外部接続ファクトリ・リソースを作成する

- 外部宛先リソースを作成する

- MQSeries JNDI用のサンプル構成

- 分散宛先リソースの構成

- 共通分散宛先と重み設定された分散宛先

- 共通分散宛先の作成

- 共通分散キューおよびトピックをターゲット指定する

- UDDメンバーに対するメッセージ処理を休止、再開する

- UDDメンバーをモニターする

- パーティション化された分散トピックの構成

- パーティション化された分散トピックのロード・バランシング

- 重み設定された分散宛先の作成

- 分散宛先でのメッセージのロード・バランシング

- ロード・バランシングのオプション

- ラウンドロビン分散

- ランダム分散

- コンシューマをロード・バランシングする

- プロデューサをロード・バランシングする

- ロード・バランシングのヒューリスティック

- トランザクション・アフィニティ

- サーバー・アフィニティ

- コンシューマのないキュー

- 分散宛先メンバーの休止

- ロード・バランシングを回避する

- 接続ファクトリ

- サーバー・アフィニティを有効化した場合の分散宛先ロード・バランシング

- 分散宛先の移行

- 分散宛先のフェイルオーバー

- 無制限ClientIDの構成

- 共有サブスクリプションの構成

5 簡略化されたJMSクラスタと高可用性の構成

- JMSのWebLogicクラスタリング・オプションとは

- 簡略化されたJMSクラスタ構成の理解

- クラスタのターゲットとして指定されたJMSサーバーと永続ストアの併用

- JMSのモジュール・リソースのターゲット指定

- 簡略化されたJMS構成と高可用性の拡張機能

- JMSサービスのための分散ポリシーの定義

- JMSサービスのための移行ポリシーの定義

- JMSサービスのための追加の構成オプション

- クラスタ化されたJMSの考慮事項と制限事項

- クラスタのターゲットとして指定されたJMSサーバーの相互運用性とアップグレードに関する考慮事項

- クラスタ化されたJMSサービスを使用する場合のベスト・プラクティス

- 実行時MBeanインスタンスの名前付け構文

- .DATファイルのインスタンスの名前付け構文

- .RGNファイルのインスタンスの名前付け構文

- JDBCストアの名前付け構文

6 JMSアプリケーション・モジュールのデプロイメントの構成

- JMSアプリケーション・モジュールの構成方法

- JMSスキーマ

- Java EEリソース定義を使用したJMSリソースの定義

- アノテーションを使用するリソース定義

- デプロイメント記述子におけるリソース定義

- JMSリソース定義の考慮事項とベスト・プラクティス

- JMSアプリケーション・モジュールのエンタープライズ・アプリケーションへのパッケージ化

- パッケージ化JMSアプリケーション・モジュールを作成する

- パッケージ化JMSアプリケーション・モジュールの要件

- パッケージ化JMSアプリケーション・モジュールの主な作成手順

- EJBアプリケーション内のパッケージ化JMSアプリケーション・モジュールのサンプル

- weblogic-application.xmlでパッケージ化JMSアプリケーション・モジュールを参照する

- ejb-jar.xmlでパッケージ化JMSアプリケーション・モジュールを参照する

- weblogic-ejb-jar.xmlでパッケージ化JMSアプリケーション・モジュールを参照する

- エンタープライズ・アプリケーションをJMSアプリケーション・モジュールと共にパッケージ化する

- パッケージ化JMSアプリケーション・モジュールをデプロイする

- スタンドアロンJMSアプリケーション・モジュールをデプロイする

- スタンドアロンJMSモジュール

- スタンドアロンJMSアプリケーション・モジュールを作成する

- スタンドアロンJMSアプリケーション・モジュールの要件

- スタンドアロンJMSアプリケーション・モジュールの主な作成手順

- 単純なスタンドアロンJMSアプリケーション・モジュールのサンプル

- スタンドアロンJMSアプリケーション・モジュールをデプロイする

- スタンドアロンJMSアプリケーション・モジュールをチューニングする

- JMSリソースの一意の実行時JNDI名の生成

- ローカル・アプリケーションの一意の実行時JNDI名

- アプリケーション・ライブラリの一意の実行時JNDI名

- スタンドアロンJMSモジュールの一意の実行時JNDI名

- ${APPNAME}文字列の使用場所

- 使用事例

- JMSサービスのための追加の構成オプション

7 WLSTを使用したJMSサーバーとJMSシステム・モジュール・リソースの管理

- JMSシステム・モジュールとサブデプロイメントの理解

- JMSサーバーとJMSシステム・モジュール・リソースの作成方法

- JMSサーバーとJMSシステム・モジュール・リソースの変更およびモニター方法

- WLSTを使用したJMSリソース構成時のベスト・プラクティス

8 Oracle AQ JMSとの相互運用

- 概要

- 外部宛先としてのAQ宛先の使用

- ドライバ・サポート

- トランザクション・サポート

- Oracle RAC

- MBeanおよびConsoleサポート

- OC4Jからの移行

- AQ JMSとの相互運用のためのWebLogic Serverの構成

- データベース内でのOracle AQの構成

- ユーザーの作成および許可の付与

- AQキュー表の作成

- JMSキューまたはトピックの作成

- JMSキューまたはトピックの開始

- AQ JMS用のWebLogic Serverの構成

- AQ JMS用のWebLogicデータ・ソースの構成

- AQ JMS用の汎用データ・ソースの構成

- AQ JMS用のAGLデータ・ソースの構成

- AQ JMS用の汎用データ・ソースの構成

- AQ JMS用のAGLデータ・ソースの構成

- JMSシステム・モジュールの構成

- JMS外部サーバーの構成

- データ・ソースの参照

- JMS外部サーバーの接続ファクトリの構成

- AQ JMS外部サーバーの宛先の構成

- Oracle 12cデータベースとの相互運用のための追加構成

- プログラミングの考慮事項

- AQ JMSとの相互運用のためのメッセージドリブンBeanの設定

- AQトピックをリスニングするクラスタ化されたWebLogic MDBのスケーラビリティ

- AQ JMS拡張

- AdtMessageの使用

- リソース参照

- JDBC接続の利用

- Oracle RACサポート

- デバッグ

- パフォーマンスの考慮事項

- 高度なトピック

- セキュリティの考慮事項

- AQ宛先のセキュリティの構成

- JNDIで公開された宛先および接続ファクトリへのアクセス

- JMS APIでルックアップされる宛先へのアクセスの制御

- スタンドアロン・クライアント向けのその他のセキュリティ構成

- WebLogicメッセージング・ブリッジ

- メッセージング・ブリッジ・インスタンスを作成する

- スタンドアロンのWebLogic AQ JMSクライアント

- データベースのJDBC URLを使用した外部サーバーの構成

- スタンドアロンのWebLogic AQ JMSクライアント使用時の制限事項

- 関連ドキュメント

9 JMS統計のモニターとメッセージの管理

- JMS統計のモニター

- JMSサーバーのモニター

- クラスタのターゲットとして指定されたJMSサーバーのモニター

- アクティブなJMS宛先をモニターする

- アクティブなJMSトランザクションをモニターする

- アクティブなJMS接続、セッション、コンシューマ、プロデューサをモニターする

- アクティブなJMSセッション・プールをモニターする

- キューのモニター

- トピックのモニター

- トピックの恒久サブスクライバのモニター

- 共通分散キューのモニター

- 共通分散トピックのモニター

- プール済みJMS接続のモニター

- JMSメッセージの管理

- Java APIを使用したJMSメッセージの管理

- 管理コンソールを使用したJMSメッセージの管理

- メッセージの実行時情報をモニターする

- メッセージに問合せを実行する

- メッセージを移動する

- メッセージを削除する

- 新しいメッセージを作成する

- メッセージをインポートする

- メッセージをエクスポートする

- トランザクションの管理

- 恒久トピック・サブスクライバの管理

10 JMS初級ユーザーおよび上級ユーザーのベスト・プラクティス

- 構成のベスト・プラクティス

- JMSサーバーと永続ストアの構成

- JMSモジュールの構成

- JMSリソースの構成

- SAFエージェント、ストア、インポート宛先の構成

- ターゲット指定のベスト・プラクティス

- 統合およびマルチドメインのベスト・プラクティス

- WebLogic JMSクライアント・オプションの理解

- WebLogic URLの理解

- URL構文

- 厳密なメッセージの順序付けのベスト・プラクティス

- 高可用性のベスト・プラクティス

- 分散キューと分散トピック

- JMS外部サーバーの構成

- JMSのパフォーマンスとチューニング

11 WebLogic JMSのトラブルシューティング

- JMSの通知の構成

- JMSのデバッグ

- デバッグの有効化

- コマンド・ラインを使用してデバッグを有効化する

- WebLogic Server管理コンソールを使用してデバッグを有効化する

- WebLogic Scripting Toolを使用してデバッグを有効化する

- config.xmlファイルへの変更

- JMSのデバッグ・スコープ

- メッセージング・カーネルとパス・サービスのデバッグ・スコープ

- リクエストの仕分け

- メッセージ・ライフ・サイクルのロギング

- JMSメッセージ・ライフ・サイクルのイベント

- メッセージ・ログの場所

- JMSメッセージ・ロギングの有効化

- JMSメッセージ・ログの内容

- JMSメッセージ・ログ・レコードのフォーマット

- サンプル・ログ・ファイル・レコード

- コンシューマ作成イベント

- コンシューマ破棄イベント

- メッセージ生成イベント

- メッセージ消費イベント

- メッセージ期限切れイベント

- 再試行超過イベント

- メッセージ削除イベント

- JMSサーバー・ログ・ファイルの管理

- メッセージ・ログ・ファイルのローテーション

- メッセージ・ログ・ファイル名の変更

- 保存するメッセージ・ログ・ファイル数の制限

- 宛先でのメッセージ処理の制御

- メッセージの生成、挿入、および消費とは

- 休止と再開をロギングする

- 生成の休止と生成の再開

- 起動時に生成を休止、再開する

- 実行時に生成を休止、再開する

- 生成の休止、再開と分散宛先

- 生成の休止、再開とJMS接続の停止、開始

- 挿入の休止と挿入の再開

- 起動時に挿入を休止、再開する

- 実行時に挿入を休止、再開する

- 挿入の休止、再開と分散宛先

- 挿入の休止、再開とJMS接続の停止、開始

- 消費の休止と消費の再開

- 起動時に消費を休止、再開する

- 実行時に消費を休止、再開する

- 消費の休止、再開とキュー・ブラウザ

- 消費の休止、再開と分散宛先

- 消費の休止、再開とメッセージドリブンBean

- 消費の休止、再開とJMS接続の停止、開始

- 処理中の作業とは

- プロデューサに関連付けられる処理中の作業

- コンシューマに関連付けられる処理中の作業

- 起動時のメッセージ処理の休止と再開の優先順位

- セキュリティ

A JMSリソース定義要素リファレンス

- JMSコネクション・ファクトリの定義要素とプロパティ

- JMS宛先定義要素とプロパティ

はじめに

ここでは、このガイド(Oracle WebLogic Server JMSリソースの管理)で使用されるドキュメントのアクセシビリティ機能および表記規則について説明します。

ドキュメントのアクセシビリティについて

Oracleのアクセシビリティについての詳細情報は、Oracle Accessibility ProgramのWebサイトhttp://www.oracle.com/pls/topic/lookup?ctx=acc&id=docaccを参照してください。

Oracleサポートへのアクセス

サポートをご購入のOracleのお客様は、My Oracle Supportにアクセスして電子サポートを受けることができます。詳細情報はhttp://www.oracle.com/pls/topic/lookup?ctx=acc&id=infoか、聴覚に障害のあるお客様はhttp://www.oracle.com/pls/topic/lookup?ctx=acc&id=trsを参照してください。

表記規則

このマニュアルでは次の表記規則を使用します。

規則

意味

太字

太字は、操作に関連するGraphical User Interface要素、または本文中で定義されている用語および用語集に記載されている用語を示します。

斜体

イタリックは、ユーザーが特定の値を指定するプレースホルダー変数を示します。

固定幅フォント

固定幅フォントは、段落内のコマンド、URL、サンプル内のコード、画面に表示されるテキスト、または入力するテキストを示します。

1 概要とロードマップ

この章では、『Oracle WebLogic Server JMSリソースの管理』の内容と構成について説明します。

この章の内容は次のとおりです。

- ドキュメントのスコープおよび対象読者

- このドキュメントの手引き

- 関連ドキュメント

- JMS管理者向けのサンプルとチュートリアル

- WebLogic Serverの付加価値JMS機能

- 新機能と変更点

ドキュメントのスコープおよび対象読者

このガイドは、JMSサーバー、スタンドアロンの宛先(キューとトピック)、分散宛先、接続ファクトリなどのOracle WebLogic Java Messaging Service (JMS)リソースの構成、管理、およびモニターを担当するシステム管理者を対象としています。

この情報は、本番フェーズにおける管理、モニター、およびパフォーマンス・チューニングについて取り扱います。ソフトウェア・プロジェクトの本番前の開発またはテスト・フェーズについては説明しません。

このドキュメントは、WebLogic Serverのシステム管理に精通している読者を対象としています。このガイドでは、WebLogic Server JMSの付加価値機能と、WebLogic Server機能とコンポーネントを使用してWebLogic JMSを本番環境で管理するための主要な情報を重点的に扱います。

このドキュメントの手引き

- この章(「概要とロードマップ」)では、このガイドの構成について説明します。

- 「JMSリソースの構成の理解」では、WebLogic JMSのアーキテクチャと機能について概説します。

- 「基本JMSシステム・リソースの構成」では、JMSサーバー、宛先(キューおよびトピック)、接続ファクトリなどの基本的なWebLogic JMSリソースを構成する方法について説明します。

- 「拡張JMSシステム・リソースの構成」では、JMSサーバー、移行可能ターゲット、分散宛先などのJMSクラスタリング機能を構成する方法について説明します。

- 「簡略化されたJMSクラスタと高可用性の構成」では、構成プロセスを簡略化する新しいクラスタ・ターゲティング・オプションについて説明します。

- 「JMSアプリケーション・モジュールのデプロイメントの構成」では、グローバルに使用可能なスタンドアロン・リソースとしてデプロイできるアプリケーション・モジュール用として、またはパッケージ化したエンタープライズ・アプリケーションでのみ使用できるエンタープライズ・アプリケーションの一部として、JMSリソースを準備する方法を説明します。

- 「WLSTを使用したJMSサーバーおよびJMSシステム・モジュール・リソースの管理」では、WebLogic Scripting Toolを使用してJMSリソースをプログラムで作成および管理する方法について説明します。

- 「Oracle AQ JMSとの相互運用」では、Oracle AQ JMSとの相互運用の方法について説明します。

- 「JMS統計のモニターとメッセージの管理」では、WebLogic Server管理コンソールを使用してJMSオブジェクトの実行時統計をモニターおよび管理する方法について説明します。

- 「JMS初級および上級ユーザーのベスト・プラクティス」では、初級および上級のJMSユーザーにアドバイスとベスト・プラクティスを提供します。

- 「WebLogic JMSのトラブルシューティング」では、メッセージ・ログを構成および管理する方法と、宛先に対するメッセージ処理を一時的に休止する方法について説明します。

- 付録A「JMSリソース定義要素リファレンス」では、JavaプラットフォームのEnterprise Edition (EE) JMSリソース定義要素とプロパティについて説明します。

関連ドキュメント

このガイドには、JMS固有の構成および管理上の情報が含まれています。

WebLogic Serverアプリケーションの開発、デプロイメント、モニターの総合的な情報については、以下を参照してください。

- 『Oracle WebLogic Server JMSアプリケーションの開発』は、WebLogic Serverを使用したJMS APIアプリケーションのプログラミング用ガイドです。

- Oracle WebLogic Serverクラスタの使用のWebLogic Serverのクラスタリングの理解では、WebLogic Serverのクラスタリングの仕組みを説明しています。

- 『Oracle WebLogic Serverへのアプリケーションのデプロイ』は、WebLogic Serverアプリケーションのデプロイに関するもっとも詳細なガイドです。スタンドアロンまたはアプリケーション・スコープのJMSリソース・モジュールに関する説明があります。

- Oracle WebLogic Serverサーバー環境の管理のWebLogic永続ストアの使用方法では、システム全体を対象としたWebLogic永続ストアの利点と使用について説明します。

- 『Oracle WebLogic Serverストア・アンド・フォワード・サービスの管理』では、JMSメッセージを使用したストア・アンド・フォワード・サービスの利点と使用について説明します。

- 『Oracle WebLogic Server WebLogic Tuxedo Connectorの管理』では、任意の2つのメッセージング製品間にメッセージング・ブリッジを構成する方法と、それによって様々なリリースのWebLogic JMS実装間やWebLogic JMSと他のメッセージング製品間で相互運用性を実現する方法について説明します。

- 『Oracle WebLogic Serverのパフォーマンスのチューニング』には、WebLogic Serverアプリケーションのパフォーマンスをモニターし、向上させるための情報が記載されています。WebLogic JMSで使用できる管理パフォーマンス・チューニング機能によって、JMSアプリケーションの能力を最大限に引き出す方法についても説明しています。

JMS管理者向けのサンプルとチュートリアル

JMSコードのサンプルとチュートリアルが用意されています。チュートリアルでは、JMSの構成、APIの使用方法、およびJMSの主要な開発タスクについて説明します。独自のシステムを構成する前に、まずJMSサンプルの一部またはすべてを実行することをお薦めします。

Avitek Medical Recordsアプリケーション(MedRec)とチュートリアル

MedRecはWebLogic Serverに付属したエンドツーエンドのサンプルJava EEアプリケーションであり、一元的で独立した医療記録管理システムをシミュレートします。MedRecアプリケーションを使用すると、患者、医師、および管理者が、様々なクライアントから患者のデータを管理できます。

MedRecはWebLogic ServerとJava EEの機能を例示し、Oracle推奨のベスト・プラクティスを重要点として示します。MedRecは、WebLogic Serverのインストール時に任意でインストールできます。MedRecはORACLE_HOME\user_projects\domains\medrecディレクトリから起動できます。ORACLE_HOMEは、Oracle WebLogic ServerをインストールしたときにOracleホームとして指定したディレクトリです。詳細は、『Oracle WebLogic Serverの理解』のサンプル・アプリケーションおよびサンプル・コードに関する項 を参照してください。

WebLogic Server配布キットのJMSサンプル

このリリースのWebLogic Serverでは、APIコードのサンプルをORACLE_HOME\wl_server\samples\server\examples\src\examples ディレクトリにオプションでインストールできます。ここで、ORACLE_HOMEはOracle Fusion Middlewareのホーム・ディレクトリを表します。

詳細は、『Oracle WebLogic Serverの理解』のサンプル・アプリケーションおよびサンプル・コードに関する項 を参照してください。

WebLogic Serverの付加価値JMS機能

WebLogic JMSには、JMS 1.1および2.0仕様で指定された標準JMS APIよりも高度なWebLogic JMS拡張APIが数多く用意されています。これらはhttp://www.oracle.com/technetwork/java/jms/index.htmlで取得できます(新しいウィンドウを開きます)。また、WebLogic JMSはWebLogic Serverプラットフォームに緊密に統合されているため、セキュリティで保護されたJava EEアプリケーションを構築し、それらをWebLogic Serverコンソールで容易にモニターおよび管理できます。XAトランザクションが完全にサポートされているだけでなく、クラスタ機能とサービス移行機能による高可用性を特長としています。さらに、他のリリースのWebLogic Serverやサード・パーティのメッセージ・プロバイダとの相互運用性も提供されます。

以下の節では、WebLogic JMSの一意かつ強力な機能について概説します。

エンタープライズ・レベルの信頼性

WebLogic JMSには、信頼性に関する以下の機能があります。

- 即時使用可能なトランザクション・サポート:

- JTA (Java Transaction API)の使用により、JMSアプリケーションとその他のトランザクション対応リソースの間のトランザクション(分散トランザクションを含む)を完全にサポート(Oracle WebLogic Server JMSアプリケーションの開発のWebLogic JMSによるトランザクションの使用方法を参照)。

- 完全に統合されたトランザクション・マネージャ(Oracle WebLogic Server JTAアプリケーションの開発のトランザクションの概要を参照)。

- ファイルまたはデータベースの永続メッセージ・ストレージ(どちらもXAトランザクションに完全対応)。WebLogic永続ストアの管理のWebLogic永続ストアの使用方法を参照してください。

- メッセージのストア・アンド・フォワード(SAF)。この機能はクラスタ化可能で、利用不可能なリモートの送り先に送信されたメッセージをローカルに格納することにより信頼性を向上させます。『Oracle WebLogic Serverストア・アンド・フォワード・サービスの管理』のストア・アンド・フォワード・サービスの理解に関する項を参照してください。

- サーバーまたはネットワークの障害が発生した場合、JMSプロデューサ・オブジェクトとコンシューマ・オブジェクトは別のサーバー・インスタンスに透過的にフェイルオーバーを試みます(使用可能なものがある場合)。Oracle WebLogic Server JMSアプリケーションの開発のJMSクライアントの自動フェイルオーバーを参照してください。

- 複数のWebLogic Serverでターゲットとされる接続ファクトリを使用した接続クラスタリングのサポート。「WebLogic JMSクラスタリングの構成」を参照してください

- クラスタで高可用性、ロード・バランシング、およびフェイルオーバー・サポートを提供する共通分散キュー、複製された分散トピック、およびパーティション化された分散トピックのシステム支援による構成。Oracle WebLogic Server JMSアプリケーションの開発の分散宛先の使用および高度なパブリッシュ/サブスクライブ・アプリケーションの開発を参照してください。

- サーバー全体の自動移行。高度なクラスタの信頼性とサーバー移行機能を提供します。現在、WebLogic Serverでは、クラスタリングされたサーバー・インスタンスとそこでホストされるすべてのサービスについて、1つのマシンから別のマシンへの自動および手動での移行をサポートしています。「WebLogic JMSクラスタリングの構成」を参照してください

- 失敗したメッセージや期限切れメッセージのエラー宛先へのリダイレクト。Oracle WebLogic Server JMSアプリケーションの開発のロールバックまたは回復されたメッセージ、再配信されたメッセージまたは期限切れメッセージの管理を参照してください。

- JMS配信回数メッセージ・プロパティ(JMSXDeliveryCount)をサポート。このプロパティでは、メッセージの配信試行回数を指定できます。1回目の試行が1、2回目の試行が2 (以降同様)になります。WebLogic Serverでは、可能なかぎり配信回数を永続化することで、サーバーの再起動後に配信回数が1にリセットされないようにしています。Oracle WebLogic Server JMSアプリケーションの開発のメッセージを参照してください。

- 3つのレベルでのロード・バランシングが可能です。ネットワーク・レベル、JMS接続、および分散宛先におけるロード・バランシングができます。

エンタープライズ・レベルの機能

WebLogic JMSに備わっているエンタープライズ・レベルの機能は以下のとおりです。

- WebLogic Serverは、JMS 1.1およびJMS 2.0仕様(http://www.oracle.com/technetwork/java/jms/index.htmlで参照可能。新しいウィンドウを開きます)を完全にサポートし、Java EE 7.0仕様に準拠します。また、標準JMS APIよりも高度なWebLogic JMS拡張が数多く用意されています。

- メッセージおよび宛先の堅牢な管理機能を提供します。

- 管理者は、WebLogic Server管理コンソールまたは実行時APIを使用して、実行中のJMSサーバーのほとんどのメッセージを操作可能です。「JMSメッセージの管理」を参照してください

- 管理者は、WebLogic Server管理コンソールまたは実行時APIを使用して、所定のJMS宛先または単一のJMSサーバーでホストされるすべての宛先においてメッセージの生成、挿入(処理中のメッセージ)、および消費操作の休止と再開を行うことができます。「宛先でのメッセージ処理の制御」を参照してください

- メッセージドリブンBeans (MDBs)、EJBでもメッセージの休止および再開機能が提供され、エラー状態での自動的な一時休止も可能です。Oracle WebLogic ServerメッセージドリブンBeanの開発のMDBのプログラミングと構成の詳細を参照してください。

- JMSリソースのモジュール形式のデプロイメント。eXtensible Markup Language (XML)ファイルで定義されます。これにより、エンタープライズ・アプリケーション・ファイルを開いたり、手動によるJMSの膨大な再構成を行う必要なしに、アプリケーションおよび必要なJMS構成をある環境から別の環境に移行できます。「JMSモジュールの概要」を参照してください

- JMSメッセージ・プロデューサは順序付けされたメッセージを単一の順序単位にグループ化できます。これにより、このようなすべてのメッセージが作成された順序で確実に連続処理されます。『Oracle WebLogic Server JMSアプリケーションの開発』のメッセージ順序単位の使用に関する項を参照してください。

- メッセージ順序単位機能よりもさらに限定的なグループを定義するため、メッセージ作業単位(UOW)機能があります。これによってJMSプロデューサは特定のメッセージをUOWメッセージ・グループのコンポーネントとして識別でき、JMSコンシューマでもそうしたメッセージをそのようなものとして処理できます。たとえば、JMSプロデューサでメッセージが1つの単位として処理されるように、1つのクライアントに中断なしで配信する必要のあるメッセージの集合を指定できます。Oracle WebLogic Server JMSアプリケーションの開発の作業単位メッセージ・グループの使用を参照してください。

- メッセージ・ライフ・サイクルのロギング。この機能を利用すると、管理者はJMSサーバーの観点から、具体的にはメッセージの生成、消費、削除などの基本的なライフ・サイクル・イベントによって、JMSメッセージの存在をより正確に把握できるようになります。「メッセージ・ライフ・サイクルのロギング」を参照してください

- スケジュールされたメッセージ配信用のタイマー・サービスを使用できます。Oracle WebLogic Server JMSアプリケーションの開発のメッセージ配信時間の設定を参照してください。

- 柔軟な期限切れメッセージ・ポリシーで期限切れメッセージを処理できます。Oracle WebLogic Serverのパフォーマンスのチューニングの期限切れメッセージの処理を参照してください。

- XMLを含むメッセージをサポートします。Oracle WebLogic Server JMSアプリケーションの開発のXMLセレクタ・メソッドを使用したXMLメッセージ・セレクタの定義を参照してください。

- WebLogic Thin T3クライアントjar (wlthint3client.jar)は、wlfullclient.jarおよびwlclient.jar (IIOP)リモート・クライアントjarにかわる軽量の高性能な機能です。Thin T3クライアントは、クライアントの使用に適したAPIリッチ・セットへのアクセスを提供しながら、フットプリントは最小限で済みます。詳細は、Oracle WebLogic Serverスタンドアロン・クライアントの開発のWebLogic Thin T3クライアントの開発を参照してください。

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

- JMS resource-referenceプーリングによる、サーバー側アプリケーション内のJMSクライアント・リソースの自動プーリング。サーバー側アプリケーションで標準JMS APIを使用しながら、リソースを自動的にプーリングできます。Oracle WebLogic Server JMSアプリケーションの開発のEJBとサーブレットにWebLogic JMSを使用するための拡張Java EEサポートを参照してください。

パフォーマンス

WebLogic JMSには、自動的なメッセージ・ページング、メッセージ圧縮、およびXMLメッセージ用のDocument Object Model (DOM)のサポートなどを含む、次のようなエンタープライズ・クラスのパフォーマンス機能があります。

- WebLogic Serverは高度に最適化されたディスク・アクセス・アルゴリズムや他の内部拡張を使用して、JMSベースおよびWebサービスのメッセージングのパフォーマンスを向上させる統一されたメッセージング・カーネルを提供しています。『Oracle WebLogic Serverサーバー環境の管理』のWebLogic永続ストアの使用に関する項を参照してください。

- 一方向メッセージ送信を使用すると、一般的な非永続メッセージングのパフォーマンスが大幅に改善される可能性があります。接続ファクトリに構成されている場合、関連するプロデューサはターゲット宛先のホストJMSサーバーからのレスポンスを内部的に待機せずに、メッセージを送信できます。キュー・センダーおよびトピック・パブリッシャに一方向送信を許可したり、この機能をトピック・パブリッシャのみに制限したりできます。「一方向ウィンドウ・サイズ」を指定して、追加の一方向送信を続行する前に、プロデューサを制御するために双方向メッセージが必要になる時期を決定することもできます。Oracle WebLogic Server管理コンソール・オンライン・ヘルプの接続ファクトリのフロー制御の構成を参照してください。

- 負荷ピーク時に仮想メモリーを自動的に解放するメッセージ・ページング。Oracle WebLogic Serverのパフォーマンスのチューニングのメッセージのページングによるメモリーの解放を参照してください。

- 管理者は、WebLogic Server管理コンソールまたは実行時APIを使用して、指定したしきい値サイズを超えるメッセージを圧縮することにより、Java仮想マシン(JVM)の境界を超えて移動するメッセージの送信パフォーマンスを向上できます。Oracle WebLogic Serverのパフォーマンスのチューニングのメッセージの圧縮を参照してください。

- WebLogic Server管理コンソールまたは実行時APIを使用して、コンシューマのJMS接続ファクトリの「同期コンシューマのプリフェッチ・モード」オプションを有効にすることにより、同期コンシューマでも非同期コンシューマと同じ効率的な動作を利用できます。Oracle WebLogic Server JMSアプリケーションの開発のプリフェッチ・モードを使用した同期メッセージ・パイプラインの作成を参照してください。

- JMSメッセージ用に、様々なパフォーマンス・チューニング・オプションがあります。Oracle WebLogic ServerのパフォーマンスのチューニングのWebLogic JMSのチューニングを参照してください。

- 単一トランザクションで複数のメッセージを処理することによってサポートされるMDBトランザクションのバッチ処理があります。Oracle WebLogic ServerメッセージドリブンBeanの開発のメッセージドリブンBeanでのバッチの使用を参照してください。

- JMS SAFにより、クラスタ間に渡るWebLogicメッセージング・ブリッジ以上のパフォーマンスが実現します。Oracle WebLogic ServerのパフォーマンスのチューニングのWebLogic JMSのストア・アンド・フォワードのチューニングを参照してください。

- DOM (Document Object Model)によるXMLメッセージ送信のサポートにより、アプリケーションでXMLメッセージの送信前にDOMをフラット化する必要がなくなるため、すでにDOMを使用している実装のパフォーマンスが大幅に向上します。Oracle WebLogic Server JMSアプリケーションの開発のXMLメッセージの送信を参照してください。

- 負荷ピーク時のメッセージ・フロー制御。過度にアクティブな送信者のブロックもできます。Oracle WebLogic ServerのパフォーマンスのチューニングのJMSサーバーおよび宛先のメッセージのフロー制御と割当ての定義を参照してください。

- JMS resource-referenceプーリングを使用したJMSラッパーによる接続および他のオブジェクトの自動的なプーリング。Oracle WebLogic Server JMSアプリケーションの開発のEJBとサーブレットにWebLogic JMSを使用するための拡張Java EEサポートを参照してください。

- メッセージのマルチキャスト。IPマルチキャストを使用して多数のクライアントに同時配信できます。Oracle WebLogic Server JMSアプリケーションの開発のWebLogic JMSでのマルチキャストの使用方法を参照してください。

WebLogic Serverとの緊密な統合

WebLogic JMSは、WebLogic Serverとの緊密な統合を実現するため、以下の機能を備えています。

- 宛先を同じサーバーにアプリケーションとして配置できるため、サーバー側アプリケーションからJMSにネットワーク呼び出しなしでローカルにアクセス可能です。

- WebLogic Serverと同じポート、プロトコル、ユーザーIDを使用(T3、IIOP、およびHTTPトンネリング・プロトコル、必要に応じてSecure Socket Layer (SSL))。

- WebLogic Serverによって提供されるWebサービス、Enterprise Java Beans (MDBを含む)、およびサーブレットをJMSと緊密に連携させることが可能です。

- 同じWebLogic Server管理コンソール、またはJMS APIを使用して構成とモニターが可能です。

- WebLogic Scripting Tool (WLST)のサポートにより、対話形式で、または実行可能なスクリプトを使用して構成の変更の開始、管理、および永続化が可能です。「WLSTを使用したJMSサーバーとJMSシステム・モジュール・リソースの管理」を参照してください。

- 完全なJava Management Extensions (JMX)の管理APIとモニターAPIを提供します。『Oracle WebLogic Server JMXによるカスタム管理ユーティリティの開発』を参照してください。

- 完全に統合されたトランザクション・マネージャ(Oracle WebLogic Server JTAアプリケーションの開発のトランザクションの概要を参照)。

- WebLogic Serverに組み込まれた高度なセキュリティ・モデル(ポリシー・エンジン)を利用します。Oracle WebLogic Serverロールおよびポリシーによるリソースの保護のWebLogicセキュリティの理解とポリシーで保護できるリソースのタイプを参照してください。

他のメッセージング・サービスとの相互運用性

WebLogic JMSは、他のメッセージング・サービスとの相互運用性のため、以下の機能を備えています。

- 以前のリリースのWebLogic Serverとの直接の相互運用を完全にサポートします。Oracle WebLogic Serverインフォメーション・ロードマップのWebLogic Serverの互換性を参照してください。

- WebLogicメッセージング・ブリッジにより、トランザクションを介してメッセージを他のJMSプロバイダへ転送します。WebLogic JMSの他のインスタンスやリリースへも同様に転送します。『Oracle WebLogic Server WebLogicメッセージング・ブリッジの管理』を参照してください。

- 他のJMSプロバイダのマッピングをサポートします - これにより、他のJMSプロバイダのオブジェクトがWebLogic JNDIツリーにローカルJMSオブジェクトとして表示されます。ローカルのJava Naming and Directory Interface (JNDI)ツリー内の他のクラスタまたはドメインで、WebLogic Serverのリモート・インスタンスも参照してください。「外部サーバーの構成」を参照してください

- MDBを使用することで、複数のJMSプロバイダからのメッセージをトランザクションとして受信可能です。Oracle WebLogic ServerメッセージドリブンBeanの開発のMDBのプログラミングと構成の詳細を参照してください。

- トランスポートとしての、WebサービスとJMSの信頼できる統合を提供します。Oracle WebLogic Server JAX-RPC Webサービスの高度な機能のプログラミングのWebサービスの信頼性のあるメッセージングの使用を参照してください。

- JMS resource-referenceプーリングを使用した、サーバー側アプリケーション内の非WebLogic JMSクライアント・リソースの自動トランザクション登録を提供します。Oracle WebLogic Server JMSアプリケーションの開発のEJBとサーブレットにWebLogic JMSを使用するための拡張Java EEサポートを参照してください。

- WebLogic Tuxedo Connectorで提供されるOracle Tuxedoメッセージングとの統合を提供します。Oracle WebLogic Server WebLogic Tuxedo Connectorの管理のOracle Tuxedoキュー・ブリッジの構成方法を参照してください。

- Weblogic JMS C APIにより、「C」で記述されたプログラムがJMSアプリケーションに参加可能です。このJMS C APIの実装では、Java仮想マシン(JVM)へのアクセスにJNIを使用します。Oracle WebLogic Server JMSアプリケーションの開発のWebLogic JMS C APIを参照してください。

- Oracle Streams Advanced Queuing (AQ)を使用して、データベース統合型メッセージ・キューイング機能を提供します。この機能は、Oracleデータベース機能を利用してメッセージを管理します。WebLogic Serverは、WebLogic Serverドメインで外部JMSおよびJava Database Connectivity (JDBC)データ・ソース構成を使用して、Oracle AQを相互運用します。ローカル/リモートJMSクライアントの両方がWebLogic JNDIからOracle AQ宛先を使用できます。「Oracle AQ JMSとの相互運用」を参照してください

JMSに関する新機能と変更された機能

この項では、WebLogic Serverの次以降のリリースのための新機能と変更された機能について説明します。

- WebLogic Server 12.2.1の新しく変更された機能

WebLogic Serverのこのリリースに追加された新機能の一覧については、「Oracle WebLogic Serverの新機能」 12.2.1.2.0を参照してください

WebLogic Server 12.2.1の新しく変更された機能

このリリースには、次の新しい機能と変更された機能が含まれています。

- 簡略化されたJMSクラスタと高可用性(HA)の構成「簡略化されたJMSクラスタと高可用性の構成」を参照してください。

- 動的ロード・バランシングおよび自動フェイルオーバーなどのJMS高可用性の拡張。「簡略化されたJMS構成と高可用性の拡張機能」を参照してください

- JMS 2.0仕様で定義された、簡略化されたAPIおよび新しいメッセージング機能。Oracle WebLogic Server JMSアプリケーションの開発の簡略化APIを使用したJMSアプリの開発を参照してください。

- JNDI名 java:comp/DefaultJMSConnectionFactoryでアクセスできる、Java EE 7事前構成済デフォルト接続ファクトリ。詳細は、Java EE 7で定義されているデフォルトのJMS接続ファクトリの使用を参照してください。

- メッセージの非同期送信。『Oracle WebLogic Server JMSアプリケーションの開発』のメッセージの非同期送信を参照してください。

- Java EE 7仕様で定義されたリソースを作成するためのJMSリソース定義の使用。「Java EEリソース定義を使用したJMSリソースの定義」を参照してください。

- 共有された恒久サブスクリプションおよび非恒久サブスクリプション。「共有サブスクリプションの構成」を参照してください

- MDBとともに使用するための、新しいアクティブ化プロパティ。

2 JMSリソースの構成の理解

この章では、WebLogic JMSの基本的な概念と機能を簡単に紹介し、それらと他のアプリケーション・コンポーネントおよびWebLogic Server 12.2.1.1.0との連携の仕組みについて説明します。この章は、JavaのプログラミングおよびJMS 1.1の概念と機能をよく理解している読者を対象としています。

この章の内容は次のとおりです。

- JMSとWebLogic Serverの概要

- ドメインの構成

- JMS構成リソースとは

- JMSサーバーの概要

- JMSモジュールの概要

- WebLogic JMSの他の環境関連システム・リソース

JMSとOracle WebLogic Serverの概要

JMSのWebLogic Server実装は、WebLogic Serverプラットフォームに緊密に統合されたエンタープライズ・クラスのメッセージング・システムです。JMS 1.1仕様(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は、プロデューサ・アプリケーションからメッセージを受信し、そのメッセージをコンシューマ・アプリケーションに配信します。WebLogic Serverを使用したJMS APIプログラミングの詳細は、Oracle WebLogic Server JMSアプリケーションの開発で、簡略化されたAPIプログラミング・モデルを参照してください。

WebLogic JMSのアーキテクチャと環境

図2-1にWebLogic JMSのアーキテクチャを示します。

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

図2-1では、A1およびB1が接続ファクトリ、B2がキューです。

WebLogic JMSアーキテクチャの主要コンポーネントは以下のとおりです。

- JMSサーバーは環境関連の構成エンティティであり、特定のJMSサーバーのターゲットとして指定されたJMSモジュール内のJMSキューおよびトピック・リソースの管理コンテナとして機能します。JMSサーバーの最も重要な役割は、JMSサーバーの宛先が受信するすべての永続メッセージに使用される永続ストアに関する情報を管理し、また、JMSサーバーの宛先で作成される恒久サブスクライバの状態を管理することです。ドメインごとに1つまたは複数のJMSサーバーを構成でき、1つのJMSサーバーでは1つまたは複数のJMSモジュールを管理できます。詳細については、「JMSサーバーの概要」を参照してください

- スタンドアロンのキューおよびトピック宛先、分散宛先、接続ファクトリなどの構成リソースを含み、weblogic-jms.xsdスキーマに準拠するXMLドキュメントによって定義されるJMSモジュール。詳細については、「JMS構成リソースとは」を参照してください。

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

- JNDI (Java Naming and Directory Interface)は、サーバー・ルックアップ機能を提供します。

- WebLogic永続ストレージ(サーバー・インスタンスのデフォルト・ストア、ユーザー定義のファイル・ストア、またはJDBCでアクセス可能なユーザー定義ストア)。永続メッセージ・データを保持します。

ドメインの構成

一般に、WebLogic Serverドメイン構成ファイル(config.xml)には、ドメインに必要な構成情報が記述されています。この構成情報は、環境関連の情報とアプリケーション関連の情報にさらに分類できます。環境関連の情報には、JMSサーバーのIDと定義、JDBCデータ・ソース、WebLogic永続ストア、サーバー・ネットワーク・アドレスなどがあります。通常、これらのシステム・リソースは、ドメインごとに一意です。

これらのシステム・リソースの構成と管理を行うのは、WebLogic管理者です。WebLogic管理者は、組織のシステム管理者またはMIS部門からこの情報を受け取ります。これらのタスクを実行するために、管理者はWebLogic Server管理コンソール、WebLogic Scripting Tool (WLST)などの様々なコマンド・ライン・ツール、またはプログラムによる管理用のJMX APIを使用できます。

ドメイン環境に依存しないアプリケーション関連の定義の例としては、様々なJava EEアプリケーション・コンポーネント構成(EAR、WAR、JAR、RARの各ファイル、JMSおよびJDBCモジュールなど)があります。アプリケーション・コンポーネントは、アプリケーション開発チームによって開発およびパッケージ化され、さらにプログラム(コンパイル済みJavaコード)とその構成情報(記述子とも呼ばれ、そのほとんどはXMLファイルとして格納される)を持つ場合があります。ただし、JMSおよびJDBCモジュールの場合、コンパイル済みJavaコードは含まれません。あらかじめパッケージ化されたこれらのアプリケーションは、WebLogic Server管理者によってWebLogicドメインにデプロイされます。

アプリケーションをデプロイするプロセスによって、アプリケーション・コンポーネントと環境固有のリソース定義がリンクされます。たとえば、特定のアプリケーション・コンポーネントをホストするサーバー・インスタンス(ターゲット指定)や、JMSメッセージを保持するWebLogic永続ストアなどです。

最初のデプロイメントの完了後は、デプロイされたアプリケーションに対する管理者の権限は限定されます。たとえば、管理者はアプリケーションの適切なライフ・サイクルの保持(デプロイ、アンデプロイ、再デプロイ、削除など)とパラメータの調整(クライアントのニーズにあわせてアプリケーションのインスタンス数を増減するなど)しかできません。ライフ・サイクルとチューニング以外の変更は、アプリケーション開発チームによって行われます。

JMS構成リソースとは

JMS構成リソース(宛先、接続ファクトリなど)は、WebLogicドメインの外部にモジュール記述子ファイルとして格納されます。これらのファイルは、weblogic-jms.xsdスキーマに準拠するXMLドキュメントによって定義されます。JMSモジュールにはJMSサーバーの定義は含まれません。「JMSサーバーの概要」で説明するように、JMSサーバーの定義はWebLogicドメインの構成ファイルに格納されます

JMSリソースは、旧リリースの場合と同様の方法で管理するシステム・モジュールか、またはアプリケーション・モジュールとして作成し、管理します。JMSアプリケーション・モジュールは、Java EEモジュールのWebLogic固有の拡張機能であり、Java EEアプリケーションとともに(パッケージ化されたリソースとして)、またはグローバルに使用可能なスタンドアロン・モジュールとしてデプロイできます。「JMSモジュールの概要」を参照してください

JMSサーバーの概要

JMSサーバーは、特定のJMSサーバーのターゲットとして指定されたJMSモジュール内の宛先リソースの管理コンテナとして機能する、環境関連の構成エンティティです。JMSサーバーの最も重要な役割は、JMSサーバーの宛先が受信するすべての永続メッセージに使用される永続ストアに関する情報を管理し、また、JMSサーバーの宛先で作成される恒久サブスクライバの状態を管理することです。また、ターゲット宛先のコンテナとして、JMSサーバーに対して加えられた構成の変更または実行時の変更をすべての宛先に対して有効にできます。

JMSサーバーはドメインのconfig.xmlファイルに保持され、クラスタ内の様々なWebLogic Serverインスタンスで複数のJMSサーバーを構成できます(独自の名前が付けられている場合に限ります)。クライアント・アプリケーションでは、JNDIツリーまたはjava:/comp/envネーミング・コンテキストを使用して接続ファクトリをルックアップし、接続を作成してJMSサーバーとの通信を確立します。各JMSサーバーでは、すべてのターゲット・モジュールの宛先に対するリクエストが処理されます。JMSサーバーによって処理されない宛先に対するリクエストは、適切なサーバー・インスタンスに転送されます。

WebLogic Server 9.x以降でのJMSサーバーの動作

現在のリリースのJMSサーバーでは、JMSサーバーの動作が一部の点で9.xより前のリリースと異なります。

- 宛先リソースはJMSモジュールの中にカプセル化されるので、構成ファイルでJMSサーバーの下にネストされません。しかし、JMSサーバーと宛先の間の下位ターゲット関係も保持されています。これは、JMSモジュール内のスタンドアロンの各宛先リソースが常に単一のJMSサーバーのターゲットになるからです。このように、JMSサーバーは依然として永続メッセージ、恒久サブスクライバ、メッセージ・ページング、およびそのターゲット宛先の割当て(オプション)を管理します。ドメイン内の各JMSサーバーに、複数のJMSモジュールをターゲット指定できます。

- JMSサーバーは、サーバー・インスタンス内の複数のサブシステムとサービスで使用できるデフォルト永続ストアをサポートします(「永続ストア」を参照)。

- 「デフォルト・ストアを使用する」オプションを有効化することで、JMSサーバーはホスト・サーバーのデフォルト・ファイル・ストア内に永続メッセージを格納できます。旧リリースでは、ストアが構成されていない場合、永続メッセージは非永続メッセージに自動的に格下げされました。ただし、「デフォルト・ストアを使用する」オプションを無効化した場合、永続メッセージは非永続になります。

- 非推奨のJMSストア(JMSファイル・ストアとJMS JDBCストア)にかわって、JMSサーバーはユーザー定義のWebLogicファイル・ストアまたはJDBCストアをサポートします。これらのストアは、従来のJMSストアに比べて高いパフォーマンスと多くの機能を備えています(後方互換性を保持するため、従来のJMSストアもサポートされています)。

- JMSサーバーは、進化したメッセージ・ページング・メカニズムをサポートします。メッセージ・ページングの詳細は、Oracle WebLogic Serverのパフォーマンスのチューニングで、メッセージのページングによるメモリーの解放を参照してください。

- 専用のページング・ストアの構成は不要になりました。ページングされるメッセージは、ユーザーのファイル・システム(ユーザー定義のディレクトリか、それが指定されていない場合はデフォルト・ページング・ディレクトリ)に格納されます。

- メッセージの一時ページングは常に有効化され、「メッセージ・バッファ・サイズ」オプションの値によって制御されます。待ち状態ではない、ページングされないメッセージの合計サイズがこの値に達した場合、JMSサーバーはメッセージをページング・ディレクトリにページングすることによってメモリー使用量を減らそうとします。

- 1つのJMSサーバーによってホストされるすべての宛先でのメッセージの生成および消費処理を休止できます。これは、JMXでプログラムによって行うか、またはWebLogic Server管理コンソールから行います。詳細については、「宛先でのメッセージ処理の制御」を参照してください

- JMSサーバーは、WebLogic Serverを再起動せずにアンデプロイおよび再デプロイできます。

- オフライン状態の共通分散トピック・メンバーにパブリッシュされた非永続メッセージは保存され、メンバーが再びオンラインになると使用可能になります。
9.0より前のリリースでは、JMSサーバーに永続ストアを構成していない場合や、永続ストアは定義されているが分散トピック(DT)メンバーにstoredEnabled=falseが設定されている場合、非永続メッセージは破棄され、DTメンバーが再びオンラインになっても使用可能になりません。アプリケーションがこれらのメッセージの破棄に依存している場合は、サーバーの配信タイムアウト値を非常に低い値に設定することで、同様の動作を実現できます。これにより、オフラインDTメンバーが再びオンラインになるまでにメッセージを無視できます。WebLogic Serverリリース10.3.4.0以降で開発された新しいアプリケーションの場合、メッセージ・コンシューマとしてメッセージ・ドリブンBean (MDB)を設定し、パーティション化された分散トピックを使用することで、同様の機能を実現できます。『Oracle WebLogic Server JMSアプリケーションの開発』の上級パブリッシュ/サブスクライブ・アプリケーションの開発に関する項を参照してください。

JMSサーバーの構成の詳細は、「JMSサーバーの構成」を参照してください。

JMSモジュールの概要

JMSモジュールは、ドメイン環境から独立したアプリケーション関連の定義です。システム・モジュールまたはアプリケーション・モジュールのいずれかとして、JMSリソースを作成して管理できます。JMSシステム・モジュールは、通常、WebLogic Server管理コンソールまたはWebLogic Scripting Tool (WLST)を使用して構成され、ドメインのconfig.xmlファイル内にそのモジュールへの参照が追加されます。JMSアプリケーション・モジュールは、Java EEモジュールのWebLogic固有の拡張機能であり、Java EEアプリケーションと共に(パッケージ化されたリソースとして)、またはグローバルに使用可能なスタンドアロン・モジュールとしてデプロイできます。

システム・モジュールとアプリケーション・モジュールの主な相違点は所有権です。システム・モジュールはWebLogic管理者によって所有および変更され、すべてのアプリケーションで利用可能です。アプリケーション・モジュールは、このJMSリソース・モジュールをアプリケーションのEARファイルにパッケージ化するWebLogic開発者によって所有および変更されます。

JMSリソースのモジュール形式のデプロイメントでは、エンタープライズ・アプリケーション・ファイル(EARファイルなど)またはスタンドアロンJMSモジュールを開いたり、JMSを手動で広範囲に再構成したりすることなく、アプリケーションと必要なJMS構成を、ある環境から別の環境に(たとえば、テスト環境から本番環境に)移行できます。

以下の節では、様々なタイプのJMSモジュールと、それらのモジュールに含められるリソースについて説明します。

- JMSシステム・モジュール

- JMSアプリケーション・モジュール

- JMSシステム・モジュールとアプリケーション・モジュールを比較する

- モジュールに構成できるJMSリソース

- JMSスキーマ

- JMS相互運用モジュール(非推奨)

JMSシステム・モジュール

WebLogic管理者は、通常、WebLogic Server管理コンソールまたはWebLogic Scripting Tool (WLST)を使用して、(ターゲット) JMSモジュールの作成とデプロイ、およびモジュールの構成リソース(キュー、トピック、接続ファクトリなど)の構成を行います。

このように構成するJMSモジュールは、システム・モジュールと見なされます。JMSシステム・モジュールは管理者が所有し、管理者はいつでもリソースを削除、変更、または追加できます。システム・モジュールは、ドメインに構成されたサーバーおよびクラスタのターゲット指定に対して全面的に利用できます。つまり、同じターゲットにデプロイされているすべてのアプリケーションおよびクライアント・アプリケーションで利用できます。

JMSシステム・モジュールを作成する場合、ドメイン・ディレクトリのconfig\jmsサブディレクトリにJMSモジュール・ファイルが作成され、ドメインのconfig.xmlファイルにJMSSystemResource要素としてそのモジュールへの参照が追加されます。この参照には、JMSシステム・モジュール・ファイルへのパス、およびこのモジュールがデプロイされるサーバーとクラスタのリストが含まれます。

JMSモジュールは、weblogic-jms.xsdスキーマに準拠します(「JMSスキーマ」を参照)。システム・モジュールは、WebLogic Management Extension (JMX)ユーティリティからもJMSSystemResourceMBeanとしてアクセス可能です。JMSシステム・モジュールのネーミング・ルールは、MyJMSModule-jms.xmlです。

図2-2に、ドメインのconfig.xmlファイルに記述されるJMSシステム・モジュールと、対応するconfig\jmsディレクトリ内のモジュールの例を示します。

図2-2 config.xmlからJMSシステム・モジュールへの参照

JMSシステム・モジュールの構成の詳細は、「基本JMSシステム・リソースの構成」を参照してください

JMSアプリケーション・モジュール

JMS構成リソースは、標準のJava EE記述子ベースのモジュールと同様に、デプロイ可能なアプリケーション・モジュールとしても管理できます。JMSアプリケーション・モジュールは、Java EEアプリケーションと共にパッケージ化されたモジュールとして(この場合、モジュール内のリソースは同梱されたアプリケーションでのみ利用可能(アプリケーション・スコープなど))、またはそのモジュール内のリソースへのグローバル・アクセスを提供するスタンドアロン・モジュールとしてデプロイできます。

通常、アプリケーション開発者が、エンタープライズ・レベルのIDEまたはXML記述子ファイルの編集に対応した開発ツールでアプリケーション・モジュールを作成し、それらのJMSモジュールをアプリケーションの一部としてパッケージ化して、デプロイ、管理、およびチューニングのためにアプリケーションをWebLogic管理者に渡します。

「ドメインの構成」で説明されているように、JMSアプリケーション・モジュールにはコンパイル済のJavaプログラムがパッケージの一部として含まれていないので、管理者またはアプリケーション開発者は必要に応じてJMSリソースを作成および管理できます。

JMSアプリケーション・モジュールの構成の詳細は、JMSアプリケーション・モジュールのデプロイメントの構成を参照してください。

JMSシステム・モジュールとアプリケーション・モジュールを比較する

WebLogic JMS構成および管理を理解する上で鍵となるのは、JMSリソースの作成者およびJMSリソースの作成方法が、リソースのデプロイと変更の方法を決定するという点にあります。JMSモジュールは、WebLogicの管理者とプログラマが構成できます。

システム・モジュールとは対照的に、デプロイされたアプリケーション・モジュールの所有者は、モジュールをデプロイした管理者ではなく、モジュールを作成およびパッケージ化した開発者となります。したがって、デプロイしたリソースに対しては、管理者の制御が及ぶ範囲がより制限されます。アプリケーション・モジュールをデプロイする場合、管理者はモジュールで指定されたリソース・プロパティの変更はできますが、リソースの追加や削除はできません。他のJava EEモジュールのように、アプリケーション・モジュールのデプロイメント構成の変更はモジュールのデプロイメント・プランに格納され、元のモジュール自体は変更されません。

表2-1に、JMSモジュールの種類と、それらがどのように構成および変更されるかを示します。

表2-1 JMSモジュール・タイプと構成および管理オプション

モジュールの種類

作成に使用するツール

モジュールの動的追加/削除

JMXでのリモート変更

デプロイメント・チューニング・プランによる変更(非リモート)

管理コンソールによる変更

スコープ指定

デフォルト・サブ・モジュール・ターゲット指定

システム

管理コンソールまたはWLST

はい

はい

いいえ

はい。JMXを使用

グローバルおよびローカル

いいえ

アプリケーション

IDEまたはXMLエディタ

いいえ。再デプロイが必要

いいえ

はい。デプロイメント計画を使用

はい。デプロイメント計画を使用

グローバル、ローカル、およびアプリケーション

はい

JMSアプリケーション・モジュールのデプロイメントの準備については、JMSアプリケーション・モジュールのデプロイメントの構成とOracle WebLogic Serverへのアプリケーションのデプロイのweblogic.deployerによるアプリケーションおよびモジュールのデプロイを参照してください。

モジュールに構成できるJMSリソース

システム・モジュールまたはアプリケーション・モジュールの一部として、以下の基本構成リソースが定義されます。

- キューおよびトピック宛先。「キューおよびトピック宛先の構成」を参照。

- 接続ファクトリ。「接続ファクトリの構成」を参照。

- テンプレート。「JMSテンプレートの構成」を参照。

- 宛先キー。「宛先キーの構成」を参照。

- 割当て。「割当ての構成」を参照。

- 分散宛先。「分散宛先リソースの構成」を参照。

- 外部サーバー。「外部サーバー・リソースからサード・パーティJMSプロバイダへのアクセスの構成」を参照。

- JMSストア・アンド・フォワード(SAF)構成項目。「JMSストア・アンド・フォワード(SAF)」を参照してください。

これ以外のすべてのJMS環境関連リソースは、ドメイン構成リソースとして管理者が構成する必要があります。これには、以下のものが含まれます。

- JMSサーバー(必須)。「JMSサーバーの概要」を参照してください

- ストア・アンド・フォワード・エージェント(オプション)。「JMSストア・アンド・フォワード(SAF)」を参照してください。

- パス・サービス(オプション)。「パス・サービス」を参照してください

- メッセージング・ブリッジ(オプション)。「メッセージング・ブリッジ」を参照してください

- 永続ストア(オプション)。「永続ストア」を参照してください

JMSシステム・モジュールの構成の詳細は、「基本JMSシステム・リソースの構成」を参照してください

JMSスキーマ

JMSリソースのモジュラ構成モデルのサポートとして、WebLogic JMSオブジェクトのスキーマ、weblogic-jms.xsdが用意されています。JMSリソース・モジュール(記述子)を作成する際は、モジュールをこのスキーマに準拠させる必要があります。IDEや他のツールでは、このスキーマに基づいてJMSリソース・モジュールを検証できます。

weblogic-jms.xsdスキーマは、http://xmlns.oracle.com/weblogic/weblogic-jms/1.4/weblogic-jms.xsdからオンラインで入手できます。

JMS相互運用モジュール(非推奨)

注意:

JMS相互運用モジュールは、WebLogic Server 12.1.1では非推奨です。config.xmlにinterop-jms.xmlという名前のモジュールがある場合は、標準のシステム・モジュールに変換してください。「JMSシステム・モジュールの構成」を参照してください

JMS Interopモジュールは、特殊なタイプのJMSシステム・リソース・モジュールです。このモジュールは、このリリースのためのJMS構成アップグレードの結果として、および旧リリースからWebLogic JMX MBean APIを使用することによって作成および管理されます。

JMS Interopモジュールは、以下に示すように、JMSシステム・リソース・モジュールとは様々な点で異なります。

- JMSモジュール記述子の名前は常にinterop-jms.xmlです。このファイルはドメインのconfig\jmsディレクトリにあります。

- 他のJMSシステム・リソース・モジュールの所有者が主に管理者であるのに対し、Interopモジュールはシステムによって所有されます。

- Interopモジュールは、ドメインのどこでもターゲット指定されます。

- JMS Interopモジュールに存在するJMSリソースは、非推奨のJMX (MBean) APIを使用してアクセスおよび管理できます。

- JMS InteropモジュールのMBeanはJMSInteropModuleMBeanです。これはDomainMBeanの子MBeanであり、ドメイン内の他の子MBeanと同様にDomainMBeanからルックアップできます。

JMS Interopモジュールには、メッセージ順序単位や宛先割当てなどの、WebLogic Server 9.x以降の機能の多くも実装できます。ただし、WebLogic Server 9.x以降の機能のうち次の機能は実装できません。

- 共通分散宛先リソース

- JMSストア・アンド・フォワード・リソース

注意:

JMS Interopモジュールで現在のリリースの新しい機能を使用すると、WebLogic Server 9.xより前のバージョンのJMXクライアントとの互換性が損なわれる場合があります。

WebLogic JMSの他の環境関連システム・リソース

以下の環境関連のリソースは、JMSサーバーおよびJMSモジュールにアクセス可能となるように、管理者によってドメイン構成リソースとして構成される必要があります。

永続ストア

WebLogic永続ストアは、永続性を必要とするすべてのサブシステムとサービスに対し、組込みの高性能なストレージの仕組みを提供します。たとえば、永続JMSメッセージを格納したり、ストア・アンド・フォワード機能を使用して、メッセージを一時的に格納してから送信したりできます。ドメインの各WebLogic Serverインスタンスには、構成が不要で、システムのデフォルト・ストレージを使用する複数のサブシステムで同時に使用できるデフォルトの永続ストアがあります。なお、JMS実装に合せて専用のファイル・ベース・ストアまたはJDBCデータベース対応ストアを作成することもできます。JMSの永続ストアの構成の詳細は、Oracle WebLogic Serverサーバー環境の管理のWebLogic永続ストアの使用方法を参照してください。

JMSストア・アンド・フォワード

SAFサービスを使用すると、複数のWebLogic Serverインスタンスに分散されているアプリケーション間でメッセージを確実に配信できます。たとえば、SAFサービスを利用すると、ローカルのWebLogic Serverインスタンス上で動作するアプリケーション、またはローカルのWebLogic Serverインスタンスに接続するアプリケーションは、リモート・サーバー上の宛先にメッセージを確実に配信できます。ネットワークの問題やシステム障害が原因で、メッセージの送信時に宛先が使用不能になっている場合、メッセージはローカルのサーバー・インスタンスに保存され、リモートの宛先が使用可能になった時点で転送されます。

JMSモジュールはSAFサービスを使用して、ローカルのJMSメッセージ・プロデューサがリモートのJMSキューまたはトピックにメッセージを確実に送信できるようにします。詳細は、Oracle WebLogic Serverストア・アンド・フォワード・サービスの管理のJMSメッセージに対するSAFの構成を参照してください。

パス・サービス

WebLogic Serverパス・サービスは、分散キュー・メンバーまたはストア・アンド・フォワード・パスにメッセージを固定することによってメッセージ・グループとメッセージング・リソースの間のマッピングを格納するための永続マップです。パス・サービスの構成の詳細は、「WebLogicパス・サービスの使用」を参照してください。

メッセージング・ブリッジ

メッセージング・ブリッジを使用すると、2つのメッセージング製品間の転送メカニズムを構成することで、WebLogic JMSの異なる実装間、またはWebLogic JMSと別のメッセージング製品間の相互運用性を実現できます。メッセージング・ブリッジ・インスタンスと、ブリッジのソースおよびターゲット宛先インスタンスは、ドメインのconfig.xmlファイルに保持されます。詳細は、Oracle WebLogic Server WebLogicメッセージング・ブリッジの管理のメッセージング・ブリッジの理解を参照してください。

3 基本JMSシステム・リソースの構成

この章では、WebLogic Server 12.1.3のJMSサーバーやJMSシステム・モジュールといった基本JMSシステム・リソースの構成と管理の方法について説明します。

この章の内容は次のとおりです。

- JMSシステム・リソースの構成方法

- 基本JMSシステム・リソースの構成の主な手順

- JMS構成のネーミング要件

- JMSサーバーの構成

- JMSシステム・モジュールの構成

- 接続ファクトリのマップされないリソース参照モードの指定

- 接続ファクトリの構成

- キューおよびトピック宛先の構成

- JMSテンプレートの構成

- 宛先キーの構成

- 割当ての構成

- 外部サーバーの構成

- 分散宛先の構成

- JMSストア・アンド・フォワードの構成

JMSシステム・リソースの構成方法

WebLogic管理者は次のツールを使用して、JMSサーバーやJMSシステム・モジュールなどのシステム・リソースを作成およびデプロイ(ターゲット指定)できます。

- WebLogic Server管理コンソールを使用すると、次のJMS関連リソースを構成、変更、およびターゲット指定できます。

- JMSサーバー。「JMSサーバーの構成」を参照してください

- JMSシステム・モジュール。「JMSシステム・モジュールの構成」を参照してください

- JMSのストア・アンド・フォワード・サービス。Oracle WebLogic Serverストア・アンド・フォワード・サービスの管理のJMSメッセージに対するSAFの構成を参照してください。

- 永続ストア。Oracle WebLogic Serverサーバー環境の管理のWebLogic永続ストアの使用方法を参照してください。

- WebLogic Scripting Tool (WLST)は、コマンド・ライン形式のスクリプト・インタフェースです。このツールを使用して、システム管理者とオペレータはWebLogic Serverの構成の変更を、対話形式または実行可能なスクリプトで開始、管理、および永続化できます。「WLSTを使用したJMSサーバーとJMSシステム・モジュール・リソースの管理」を参照してください。

- Java Management Extensions (JMX)は、ネットワーク上でリソースをモニターしたり管理したりするためのJava EEソリューション。Oracle WebLogic Server JMXによるカスタム管理ユーティリティの開発のWebLogic ServerサブシステムMBeanの概要を参照してください。

- JMSModuleHelper拡張クラスには、特定のモジュールのJMSモジュール構成リソースを作成および管理するためのメソッドが含まれています。詳細は、Oracle WebLogic Server JMSアプリケーションの開発のJMSモジュール・ヘルパーを使用したアプリケーションの管理またはJMSModuleHelperクラスのJavadocを参照してください。

注意:

エンタープライズ・アプリケーション内でのJMSアプリケーション・モジュールの構成およびデプロイについては、「JMSアプリケーション・モジュールのデプロイメントの構成」を参照してください。

基本JMSシステム・リソースの構成の主な手順

WebLogic Server管理コンソールを使用して、永続ストア、JMSサーバー、および基本的なJMSシステム・モジュールを構成します。WebLogic Server管理コンソールを使用してWebLogic Serverドメインを管理する手順については、Oracle WebLogic Server管理コンソール・オンライン・ヘルプを参照してください。

WebLogic JMSでは、一部の構成オプションに対するデフォルト値が用意されていますが、それ以外のすべての属性に対しては値を指定する必要があります。WebLogic JMSの構成後は、アプリケーションでJMS APIを使用してメッセージの送受信ができるようになります。デフォルト構成パラメータの調整の詳細は、Oracle WebLogic ServerのパフォーマンスのチューニングでWebLogic JMSのチューニングを、またはOracle WebLogic Server MBeanリファレンスでJMSBeanを参照してください。

1. 永続メッセージングが必要な場合は、次のストレージ・オプションのいずれかを使用します。

- 永続メッセージをファイル・ベースのストアに格納するには、サーバーのデフォルトの永続ストアを使用します。これはユーザー側で構成する必要はありません。なお、JMS専用のファイル・ストアを作成することもできます。WebLogic永続ストアの管理のカスタム(ユーザー定義)ファイル・ストアの作成。

- JDBCによるアクセスが可能なデータベースに永続的メッセージを格納するには、JDBCストアを作成する必要があります。WebLogic永続ストアの管理のJDBCストアの使用を参照してください。

2. JMSサーバーを構成して、JMSシステム・モジュール内のキューおよびトピック宛先に届くメッセージを管理します。「JMSサーバーの概要」を参照してください

3. JMSシステム・モジュールを構成して、宛先および他のリソース(キュー、テンプレート、宛先キー、分散宛先、接続ファクトリなど)を含めます。「JMSシステム・モジュール」を参照してください

4. システム・モジュールに任意のキューやトピックを作成する前には、必要に応じてJMSテンプレート、割当て設定、宛先ソート・キーなど、キューまたはトピック内から参照可能な他のJMSリソースをモジュール内に作成できます。

- 宛先に割当てリソースを定義します。宛先に独自の割当てを定義したり、複数の宛先が1つの割当てを共有したり、宛先がJMSサーバーの割当てを共有したりできます。「割当ての構成」を参照してください。

- JMSテンプレートを作成します。このテンプレートは、同様のオプション設定で複数の宛先を定義します。「JMSテンプレートの構成」を参照してください

- 宛先で受信するメッセージのソート順序を独自に定義するための宛先キーを構成します。「宛先キーの構成」を参照してください

これらのリソースを構成すると、その後キューまたはトピック・リソースを構成する際にリソースを選択できます。

5. システム・モジュールに、キューまたはトピック(あるいはその両方)の宛先を構成します。

- 複数の宛先に対するメッセージの配信用(パブリッシュ/サブスクライブ)には、スタンドアロンのトピックを構成します。「キューおよびトピック宛先の構成」を参照してください

- 1つの宛先のみに対するメッセージの配信用(ポイントツーポイント)には、スタンドアロンのキューを構成します。「キューおよびトピック宛先の構成」を参照してください

6. WebLogic Serverに用意されているデフォルトの接続ファクトリがアプリケーションに適さない場合は、接続ファクトリを作成して、JMSクライアントがJMS接続を作成できるようにします。

デフォルト接続ファクトリの使用の詳細は、「WebLogic Serverで定義されたデフォルト接続ファクトリの使用」を参照してください。接続ファクトリの構成の詳細は、「接続ファクトリの構成パラメータ」を参照してください。

WebLogic JMSでは、一部の構成オプションに対するデフォルト値が用意されていますが、それ以外のすべての属性に対しては値を指定する必要があります。WebLogic JMSの構成後は、アプリケーションでJMS APIを使用してメッセージの送受信ができるようになります。

JMSシステム・モジュールの拡張リソース

JMSシステム・モジュールには、基本的なJMSリソース構成以外にも以下の拡張リソースを追加できます。

- 共通分散宛先リソースを作成して、各メンバーが別個のJMSサーバーに属するクラスタ内で分散されるキューまたはトピックのセットを構成できます。「分散宛先リソースの構成」を参照してください

- JMSストア・アンド・フォワード・リソースを作成することで、送信時に宛先が使用不可能な場合にも、メッセージをリモートの宛先へ確実に転送できます。Oracle WebLogic Serverストア・アンド・フォワード・サービスの管理のJMSメッセージに対するSAFの構成を参照してください。

- 外部サーバー・リソースを作成して、ローカルWebLogic Server JNDIツリー内でサード・パーティのJMSプロバイダを参照するようにできます。「外部サーバー・リソースからサード・パーティJMSプロバイダへのアクセスの構成」を参照してください

JMS構成のネーミング要件

ドメインの内部では、サーバー、マシン、クラスタ、仮想ホスト、およびその他のリソース・タイプのそれぞれに一意の名前を付ける必要があります。また、ドメインと同じ名前を使用することはできません。この一意の命名規則は、JMSサーバー、JMSシステム・モジュール、JMSアプリケーション・モジュールなどの構成可能なJMSオブジェクトを含む、すべての構成オブジェクトにも適用されます。

JMSモジュール内のリソースの名前は、リソース・タイプ(キュー、トピック、接続ファクトリなど)ごとに一意でなければなりません。ただし、2つの異なるJMSモジュールに、同じ名前、同じタイプのリソースを作成できます。

JMSモジュール間のバインド可能なJMSリソース(割当て制限、宛先キー、JMSテンプレートを除く)のJNDI名は、次のネーミング要件に従う必要があります。

- グローバル名はクラスタ全体で一意である必要があります。

- ローカル名はサーバー全体で一意である必要があります。

- 名前が競合する場合、JMSリソースはJNDIツリーにバインドされません。確信が持てない場合は、JNDI名をグローバルに一意にします。

注意:

2つの異なるWebLogicドメインが相互運用する場合や、クライアントが複数のWebLogicドメインと通信する場合、WebLogicドメイン、WebLogicサーバー、WebLogic JMSサーバーの名前には、一意のネーミング要件を追加する必要があります。詳細は、「統合およびマルチドメインのベスト・プラクティス」を参照してください

JMSサーバーの構成

JMSサーバーは、それらのターゲットとして指定されたJMSモジュール内のJMSキューおよびトピック・リソースの管理コンテナとして機能する、環境関連の構成エンティティです。JMSサーバーの最も重要な役割は、JMSサーバーの宛先が受信するすべての永続メッセージに使用される永続ストアに関する情報を管理し、また、JMSサーバーの宛先で作成される恒久サブスクライバの状態を管理することです。また、ターゲット宛先のコンテナとして、JMSサーバーに対して加えられた構成の変更または実行時の変更をすべての宛先に対して有効にできます。

注意:

サンプル・サーバーの製品には、examplesJMSServerの構成例が提供されています。基本的なWebLogic JMSアプリケーションの開発の詳細は、Oracle WebLogic Server JMSアプリケーションの開発の基本的なJMSアプリケーションの開発を参照してください。

JMSサーバーの構成パラメータ

WebLogic Server管理コンソールを使用すると、システム・モジュール内のJMSサーバー・リソースを構成、変更、ターゲット指定、および削除できます。JMSサーバー・タスクの手順については、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのJMSサーバーの構成を参照してください。

以下のパラメータをJMSサーバーに構成できます。

- 全般構成パラメータ。永続ストレージ、メッセージ・ページングのデフォルト、アプリケーションが一時的な宛先を作成する場合に使用するテンプレート、および期限切れメッセージのスキャンなどのパラメータがあります。

- 特定のJMSサーバーに割り当てられるJMSシステム・モジュール内の宛先のしきい値および割当てパラメータ。
JMSサーバーと宛先に対するメッセージおよびバイト割当ての構成については、Oracle WebLogic Serverのパフォーマンスのチューニングで、割当ての定義を参照してください。

- JMSサーバーのログ・ファイル用のメッセージ・ロギング・パラメータ。ログ・ファイルには、メッセージの生成、消費、削除など、JMSメッセージが通過する基本的なイベントが記録されます。
JMSサーバーのメッセージ・ライフ・サイクル・ロギングの構成の詳細については「メッセージ・ライフ・サイクルのロギング」を参照してください

- 宛先の休止と再開の制御。これらを使用すると、単一のJMSサーバーによってホストされるすべての宛先でのメッセージの生成、挿入(処理中のメッセージ)、および消費処理を休止できます。
宛先でのメッセージ処理の休止については、「宛先でのメッセージ処理の制御」を参照してください

JMSサーバー・オプションの中には、動的に構成できるものもあります。オプションを実行時に変更した場合、新しく配信されるメッセージにのみ適用され、すでに保存されているメッセージには影響しません。すべてのJMSサーバー・オプションのデフォルト値の詳細は、Oracle WebLogic Server MBeanリファレンスのJMSServerBeanおよびJMSServerRuntimeMBeanを参照してください。

JMSサーバーのターゲット指定

JMSサーバーは、デプロイ先となる独立したWebLogic Serverインスタンス、(動的または混在)クラスタまたは移行可能ターゲット・サーバーのターゲットとして指定できます。

- Weblogicサーバー・インスタンス - JMSサーバーのデプロイ先となるサーバー・ターゲットです。ターゲットWebLogic Serverが起動すると、JMSサーバーも起動します。ターゲットWebLogic Serverが指定されていない場合、JMSサーバーは起動しません。

- クラスタをターゲットに指定したJMS - JMSサービス・アーティファクト(JMSサーバー、SAFエージェント、永続ストアおよびクラスタへのパス・サービス)をターゲットとして指定できます。

注意:
移行可能ターゲットを使用するかわりに、自動サービス移行をサポートする新しいストア構成を持つクラスタ・ターゲティングの使用をお薦めします。詳細は、「簡略化されたJMS構成と高可用性の拡張機能」を参照してください。

- 移行可能ターゲット - 移行可能ターゲットは、JMSサーバーなどの必ず1回のサービスをホストする可能性があるクラスタ内のWebLogic Serverインスタンス・セットを定義します。移行可能ターゲット・サーバーが起動すると、JMSサーバーも、クラスタ内の指定したユーザーの優先サーバー上で起動します。ただし、JMSサーバーとそのすべての宛先は、サーバーの障害に対応するため、または予定されていた移行またはシステム・メンテナンスのためにクラスタ内の別のサーバーに移行できます。JMSサービスの移行可能ターゲットの構成については、「JMS関連サービスの移行」を参照してください。

WebLogic Server管理コンソールを使用したJMSサーバー・ターゲットの指定手順については、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのJMSサーバー・ターゲットの変更を参照してください。JMSサーバー・ターゲット指定のベスト・プラクティスについては、「ターゲット指定のベスト・プラクティス」を参照してください

JMSサーバーのモニター・パラメータ

アクティブなJMSサーバー、宛先、およびサーバー・セッション・プールの実行時統計をモニターできます。

- すべてのアクティブなJMSサーバーのモニター - WebLogic Serverドメイン全体にデプロイされているJMSサーバーのすべてのインスタンスを表示する表。

- すべてのアクティブなJMS宛先のモニター - 現在のドメインのすべてのアクティブなJMS宛先を表示する表。

- すべてのアクティブなJMSセッション・プール・ランタイムのモニター - 現在のドメインのすべてのアクティブなJMSセッション・プールを表示する表。

JMSオブジェクトの監視の詳細は、「JMS統計のモニターとメッセージの管理」を参照してください。

セッション・プールと接続コンシューマ

注意:

セッション・プールおよび接続コンシューマの構成オブジェクトは、WebLogic Server 9.xで非推奨となっています。これらは、Java EE仕様の必須コンポーネントではなく、JTAユーザー・トランザクションもサポートされていません。また、大部分がJava EEの必須コンポーネントであるメッセージドリブンBean (MDB)に取って代わられています。MDBの設計の詳細は、『Oracle WebLogic ServerメッセージドリブンBeanの開発』を参照してください。

サーバー・セッション・プールを使用すると、アプリケーションでメッセージを並行処理できます。JMSサーバーを定義したら、JMSサーバーごとに1つまたは複数のセッション・プールを構成できます。一部のセッション・プール・オプションは動的に構成できますが、新しい値はJMSサーバーを再起動するまで有効になりません。Oracle WebLogic Server JMSアプリケーションの開発のサーバー・セッション・プールの定義を参照してください。

接続コンシューマは、サーバー・セッションを取得してメッセージを処理するキュー(ポイント・ツー・ポイント)またはトピック(パブリッシュ/サブスクライブ)です。セッション・プールを定義したら、セッション・プールごとに1つまたは複数の接続コンシューマを構成します。Oracle WebLogic Server JMSアプリケーションの開発のサーバー・セッション・プールの定義を参照してください。

JMSシステム・モジュールの構成

JMSシステム・モジュールは管理者が所有します。管理者は、いつでもJMSシステム・リソースを削除、変更、または追加できます。単一のJMSサーバーをターゲットとして指定されるスタンドアロンのキューおよびトピック・リソースを除き、システム・モジュール内の接続ファクトリ、分散宛先、外部サーバー、およびJMS SAF宛先リソースは、WebLogicドメインに構成された複数のサーバー・インスタンスとクラスタをターゲットとして指定することによってグローバルに使用できるようになります。このため、これらのリソースは、同じターゲットにデプロイされるすべてのアプリケーションとクライアント・アプリケーションで使用できます。JMSシステム・モジュールの命名規則は、MyJMSModule-jms.xmlです。

WebLogic Server管理コンソールを使用すると、使用している環境のJMSシステム・モジュールを構成、変更、ターゲット指定、監視、および削除できます。JMSシステム・モジュールの構成タスクの手順については、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのJMSシステム・モジュールの構成およびJMSリソースの追加を参照してください。

以下の「基本的な」構成リソースをJMSシステム・モジュールの一部として定義します。

- キューおよびトピック宛先。「キューおよびトピック宛先の構成」を参照。

- 接続ファクトリ。「接続ファクトリの構成」を参照。

- テンプレート。「JMSテンプレートの構成」を参照。

- 宛先キー。「宛先キーの構成」を参照。

- 割当て。「割当ての構成」を参照。

以下の「拡張」クラスタリング構成リソースをJMSシステム・モジュールの一部として定義します。

- 外部サーバー。「外部サーバー・リソースからサード・パーティJMSプロバイダへのアクセスの構成」を参照。

- 分散宛先。「分散宛先リソースの構成」を参照。

- JMSのストア・アンド・フォワードの構成。Oracle WebLogic Serverストア・アンド・フォワード・サービスの管理のJMSメッセージに対するSAFの構成を参照してください。

サンプル・サーバーには、製品と一緒にサンプル・モジュールとしてexamples-jmsが用意されています。サンプル・サーバーの起動の詳細は、Oracle WebLogic Serverサーバーの起動と停止の管理のサーバーの起動と停止を参照してください。

JMSシステム・モジュールを構成するための代替方法(WebLogic Scripting Tool (WLST)を使用する方法など)については、「JMSシステム・リソースの構成方法」を参照してください。

JMSシステム・モジュールとリソースのサブデプロイメントのターゲット指定

JMSシステム・モジュールは、1つまたは複数のWebLogic Serverインスタンスまたは1つのクラスタをターゲットとして指定されている必要があります。ターゲット指定が可能で、システム・モジュールに定義されているJMSリソースは、親モジュールのターゲットの範囲内のJMSサーバーか、WebLogic Serverインスタンスのターゲットでなければなりません。また、ターゲット指定が可能でシステム・モジュール内にあるJMSリソースは、構成またはターゲット指定のプロセス中にサブデプロイメントにグループ化して、WebLogicドメイン内のJMSリソースの結合度を一段と減らすことができます。

デフォルトのターゲット指定

WebLogic Server管理コンソールでJMSシステム・モジュール内にリソースを構成する際には、親モジュールのデフォルトのターゲットを単純に受け入れることも、高度なターゲット指定のページに進んで、サブデプロイメントのメカニズムを使用してリソースをターゲット指定することもできます。ただし、スタンドアロンのキューおよびトピック・リソース・タイプではデフォルトのターゲットを使用できません。これらは単一のJMSサーバーにターゲット指定されているサブデプロイメントにターゲット指定する必要があります。

デフォルトのターゲット指定メカニズムを選択する場合、そのターゲット・ステータスはWebLogic Server管理コンソール上で当該リソース・タイプの「構成: 全般」ページにある「デフォルトのターゲット指定を有効化」チェック・ボックスに反映されます。

JMSシステム・リソースの構成の詳細は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのJMSシステム・モジュールのリソースの構成を参照してください。

注意:

宛先タイプの場合、デフォルトのターゲット指定はお薦めしません。かわりに、サブデプロイメントのターゲット指定を使用します。詳細は、「ターゲット指定のベスト・プラクティス」を参照してください

高度な(サブデプロイメントの)ターゲット指定

スタンドアロンのキューおよびトピック・リソースをターゲット指定する場合、または他のリソース・タイプに対してデフォルトのターゲット指定メカニズムをバイパスする場合、高度なターゲット指定(サブデプロイメントのターゲット指定)を使用する必要があります。サブデプロイメントとは、ターゲット指定できるシステム・モジュール・リソース(スタンドアロンの宛先、分散宛先、接続ファクトリなど)をグループ化して、システム・モジュール内のターゲット指定範囲内の特定のサーバー・リソースに割り当てるメカニズムです。

JMSシステム・モジュールはドメイン内の広範なWebLogic Serverインスタンスにターゲット指定できますが、モジュールのスタンドアロンのキューやトピックは、単一のJMSサーバーにのみ割り当てることができます。接続ファクトリ、共通分散宛先(UDD)、および外部サーバーは、1つまたは複数のJMSサーバー、1つまたは複数のWebLogic Serverインスタンス、あるいはクラスタに割り当てることができます。

したがってスタンドアロンのキューまたはトピックは、サブデプロイメントの他のメンバーが複数のJMSサーバーにターゲット指定されている場合、そのサブデプロイメントに関連付けられません。このような例としては、接続ファクトリがドメイン内のJMSサーバーをホストするクラスタに対してターゲット指定されている場合などが挙げられます。UDDを使用すると、こうしたサブデプロイメントとも関連付けることができます。これは、UDDがドメイン内の複数のJMSサーバーに対してメンバーを分散させることを目的としているためです。

表3-1にJMSシステム・リソースのサブデプロイメントの有効なターゲット指定オプションを示します。

表3-1 JMSシステム・リソースのサブデプロイメントのターゲット指定

JMSリソース

有効なターゲット

キュー

JMSサーバー

トピック

JMSサーバー

接続ファクトリ

JMSサーバー(複数可)、サーバー・インスタンス(複数可)、クラスタ

共通分散キュー

JMSサーバー(複数可)、サーバー・インスタンス(複数可)、クラスタ

共通分散トピック

JMSサーバー(複数可)、サーバー・インスタンス(複数可)、クラスタ

外部サーバー

JMSサーバー(複数可)、サーバー・インスタンス(複数可)、クラスタ

SAFインポート済み宛先

SAFエージェント(複数可)、サーバー・インスタンス(複数可)、クラスタ

注意:

接続ファクトリ、共通分散宛先、外部サーバー、およびSAFインポート済み宛先リソースは、デフォルトでそれらの親モジュールのターゲットを指定するよう構成することもできます。「デフォルトのターゲット指定」を参照してください

デフォルトのターゲット指定、サーバー・インスタンスのターゲット指定、クラスタのターゲット指定は、どのタイプの宛先(非分散宛先、分散宛先、またはSAFインポート宛先)にも推奨されません。かわりに、JMSサーバーを含むサブデプロイメントのターゲット(SAFインポート宛先の場合はSAFエージェントを含むサブデプロイメントのターゲット)を使用します。「ターゲット指定のベスト・プラクティス」を参照してください

スタンドアロンのキューまたはトピックの単純なサブデプロイメントの例として、それらを接続ファクトリとともにグループ化して特定のJMSサーバーに配置することが考えられます。これにより、ネットワーク・トラフィックが減少します。また、ターゲットのJMSサーバーを別のWebLogic Serverインスタンスに移行する必要がある場合、接続ファクトリとそのすべての接続もJMSサーバーの宛先と一緒に移行されます。

たとえば、jmssysmod-jms.xmlという名前のシステム・モジュールが、jmsserver1とjmsserver2という構成済の2つのJMSサーバーを持つWebLogic Serverインスタンスのターゲットとして指定され、2つのキューと1つの接続ファクトリをjmsserver1のみに配置する場合、これらのキューと接続ファクトリをjmsserver1groupという名前の同じサブデプロイメントにグループ化すると、これらのリソースを常にjmsserver1にリンクできます(接続ファクトリが複数のJMSサーバーに関連付けられていない場合)。

<weblogic-jms xmlns="http://xmlns.oracle.com/weblogic/weblogic-jms">
<connection-factory name="connfactory1">
<sub-deployment-name>jmsserver1group</sub-deployment-name>
<jndi-name>cf1</jndi-name>
</connection-factory>
<queue name="queue1">
<sub-deployment-name>jmsserver1group</sub-deployment-name>
<jndi-name>q1</jndi-name>
</queue>
<queue name="queue2">
<sub-deployment-name>jmsserver1group</sub-deployment-name>
<jndi-name>q2</jndi-name>
</queue>
</weblogic-jms>

次に、ドメインの構成ファイルでのjmsserver1groupサブデプロイメントのターゲット指定を示します。

<jms-system-resource>
<name>jmssysmod-jms</name>
<target>wlsserver1</target>
<sub-deployment>
<name>jmsserver1group</name>
<target>jmsserver1</target>
</sub-deployment>
<descriptor-file-name>jms/jmssysmod-jms.xml</descriptor-file-name>
</jms-system-resource>

JMSシステム・モジュールのサブデプロイメントを簡単に管理するため、WebLogic Server管理コンソールにサブデプロイメントの管理用ページが用意されています。詳細は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのJMSシステム・モジュールのサブデプロイメントの構成を参照してください。

スタンドアロンJMSモジュールのデプロイについては、Oracle WebLogic ServerへのアプリケーションのデプロイのJDBC、JMS、およびWLDFアプリケーション・モジュールのデプロイを参照してください。

接続ファクトリのマップされないリソース参照モードの指定

EJBまたはサーブレットで@Resourceアノテーションを使用するか、デプロイメント記述子の resource-ref要素を使用してJMS接続ファクトリを宣言する場合に、このリソース参照が参照属性またはmappedName属性(またはjndi-name)によってJNDI名に直接マップされていないと、WebLogic Serverでは、そのようなJMS接続ファクトリへのマップされないリソース参照の動作を指定できます。JNDI名がリソース参照にマップされている場合、マップされないリソース参照モードは有効になりません。また、リソース参照は、JNDIで指定されたオブジェクトに解決されるか、例外javax.naming.NameNotFoundExceptionを生成します。

リモート参照の詳細は、Oracle WebLogic Server JMSアプリケーションの開発のEJBとサーブレットにWebLogic JMSを使用するための拡張サポートを参照してください

WebLogic Server管理コンソール上で、サーバーの「接続ファクトリのマップされないリソース参照モード」パラメータに指定した値は、JMS接続ファクトリへのリソース参照の動作を決定します。可能な値は次のとおりです。

- ReturnDefault: リソース参照が構成された外部JMSプロバイダのローカルJNDI名と一致しない場合や、JNDIツリーにバインドされたオブジェクトと一致しない場合、java:comp/DefaultJMSConnectionFactoryが戻されます。これはJava EE 7仕様で定義されたデフォルトJMS接続ファクトリです。「Java EE 7で定義されているデフォルトのJMS接続ファクトリの使用」を参照してください。

- FailSafe: リソース参照は、リソース参照名と同じ名前のJNDIツリーにバインドされたオブジェクトに解決されます(JNDIに見つからない場合)。そうでない場合は、例外javax.naming.NameNotFoundExceptionがスローされます。

注意:
参照モードは、FailSafeに構成することをお薦めします。詳細は、JMSリソースの構成を参照してください。

マップされないリソース参照モードの値の詳細は、『Oracle WebLogic Server MBeanリファレンス』の、JMSConnectionFactoryUnmappedResRefMode属性の定義を参照してください。

接続ファクトリの構成

接続ファクトリは、JMSクライアントがJMS接続を作成できるようにするリソースです。接続ファクトリでは同時使用がサポートされており、複数のスレッドがオブジェクトに同時にアクセスできます。WebLogic JMSには、サーバー単位で有効/無効を切り替えられる構成済のデフォルト接続ファクトリが用意されています(「WebLogic Serverで定義されたデフォルト接続ファクトリの使用」を参照)。

デフォルトの接続ファクトリを使用しない場合、1つまたは複数の接続ファクトリを構成して、使用するアプリケーションに合わせて定義したオプションで接続を作成します。各JMSモジュール内では、接続ファクトリ・リソースの名前は一意でなければなりません。また、「JMS構成のネーミング要件」で定義したように、あらゆるJMSモジュールの接続ファクトリのJNDI名もすべて、WebLogicドメイン全体で一意でなければなりませんWebLogic Serverでは、こうした名前が起動時にJNDIスペースへ追加された後、アプリケーションでWebLogic JNDI APIを使用して接続ファクトリが取得されます。

クラスタ内のあらゆるサーバーからJMS宛先へのクラスタ全体で透過的なアクセスを確立するには、サーバー・インスタンスごとにデフォルト接続ファクトリを使用するか、クラスタ内の1つまたは複数のサーバー・インスタンスをターゲットとする1つまたは複数の接続ファクトリを構成します。これにより、各接続ファクトリを複数のWebLogic Serverインスタンスにデプロイできます。JMSのクラスタリングの構成の詳細は、「WebLogic JMSクラスタリングの構成」を参照してください

Java EE 7で定義されているデフォルトのJMS接続ファクトリの使用

WebLogic Serverは、Java EE 7プラットフォーム仕様で定義されたデフォルトJMS接続ファクトリをサポートします。このデフォルト接続ファクトリはjava:comp/DefaultJMSConnectionFactory JNDI名を使用してルックアップできる一方、@Resourceアノテーションを使用してアクセスすることもできます。java:comp/DefaultJMSConnectionFactory JNDI名は、デフォルトのweblogic.jms.XAConnectionFactoryと同等のものに解決されます。

注意:
@ResourceとContext.lookup()を使用したDefaultJMSConnectionFactoryのルックアップは、常にプールおよびラップされた接続ファクトリを戻すため、リソースは確実に十分なパフォーマンスを提供し、サーバー側JMS API使用量のJava EE制限は確実に正しく強制適用されます。

WebLogic Serverで定義されたデフォルト接続ファクトリとは異なり、Java EE 7のデフォルト接続ファクトリは、Java EEアプリケーション内からのみアクセスできます。Java EE 7接続ファクトリは、アプリケーション・クライアント・コンテナ・ファシリティを使用しないかぎり、スタンドアロン・クライアントからはアクセスできません。

注意:

- デフォルトの接続ファクトリはチューニングできないため、デフォルトの接続ファクトリではなく、カスタム接続ファクトリを使用することをお薦めします。チューニング可能なカスタム接続ファクトリは、アプリケーションを本番環境に導入した後でも、アプリケーションのチューニングに役立つことがよくあります

- WebLogic Server管理者がWebLogic ServerごとにデフォルトJMS接続ファクトリを無効にすることはできません。

詳細は、Oracle WebLogic Server JMSアプリケーションの開発のJNDIでの接続ファクトリのルックアップを参照してください。

WebLogic Serverで定義されたデフォルト接続ファクトリの使用

WebLogic Serverは、次のJNDI名を使用してルックアップできる、2つのデフォルト接続ファクトリを定義します。

- weblogic.jms.ConnectionFactory

- weblogic.jms.XAConnectionFactory

新しい接続ファクトリの構成は、デフォルト接続ファクトリの構成済設定がアプリケーションに適さない場合にのみ行います。デフォルトの接続ファクトリの使用の詳細は、Oracle WebLogic Server JMSアプリケーションの開発のWebLogic JMSの理解を参照してください。

デフォルト接続ファクトリの構成済設定とユーザー定義の接続ファクトリの主な違いは、JTAトランザクションを有効にするための「XA接続ファクトリの有効化」オプションのデフォルト値です。「XA接続ファクトリの有効化」オプションの詳細、およびその他の接続ファクトリ・オプションのデフォルト値については、Oracle WebLogic Server MBeanリファレンスのJMSConnectionFactoryBeanを参照してください。

また、デフォルト接続ファクトリを使用する場合、接続ファクトリがデプロイされる可能性のあるWebLogic Serverインスタンスを限定できません。ただし、WebLogic Server単位でデフォルト接続ファクトリを有効化および無効化することはできます。Oracle WebLogic Server管理コンソール・オンライン・ヘルプのサーバー: 構成: サービスを参照してください。

注意:

デフォルトの接続ファクトリはチューニングできないため、デフォルトの接続ファクトリではなく、カスタム接続ファクトリを使用することをお薦めします。カスタム接続ファクトリはチューニング可能であるため、アプリケーションを本番環境にした後でもアプリケーションのチューニングをする場合に役立ちます。

接続ファクトリの構成パラメータ

WebLogic Server管理コンソールを使用すると、システム・モジュール内の接続ファクトリ・リソースを構成、変更、ターゲット指定、および削除できます。JMS接続の構成タスクの手順については、Oracle WebLogic Server管理コンソール・オンライン・ヘルプの接続ファクトリの構成を参照してください。

接続ファクトリの以下のパラメータを変更できます。

- 全般構成パラメータ。デフォルト・クライアント・パラメータの変更、デフォルト・メッセージ配信パラメータ、ロード・バランシング・パラメータ、順序単位パラメータ、セキュリティ・パラメータなどが含まれます。

- トランザクション・パラメータ。これらを使用すると、トランザクション・タイムアウト・オプションの値の定義、XAキューまたはXAトピック接続ファクトリが返されるどうかの指定、および接続ファクトリでJTA対応セッションが作成されるかどうかの指定ができます。

注意:

XA接続ファクトリを有効化オプションを選択して、JDBCストアでJTAトランザクションを有効にした場合は、構成済のJDBCデータ・ソースがXA非対応のJDBCドライバを使用することを確認する必要があります。この制約によって、JDBCストアを使用するレイヤー・サブシステムのXA機能が使用できなくなるわけではありません。たとえば、WebLogic JMSは、ファイル・ストアやJDBCストアを使用するかどうかに関係なく完全にXA機能を使用できます。

- フロー制御パラメータ。これらを使用すると、JMSサーバーまたは宛先で過負荷の状態になりつつあると判断された場合にメッセージ・プロデューサを低速化できます。

接続ファクトリのオプションの中には、動的に構成できるものもあります。オプションを実行時に変更した場合、新しく配信されるメッセージにのみ適用され、すでに保存されているメッセージには影響しません。接続ファクトリのオプションすべてのデフォルト値の詳細は、Oracle WebLogic Server MBeanリファレンスのJMSConnectionFactoryBeanを参照してください。

接続ファクトリのターゲット指定

接続ファクトリは、1つまたは複数のJMSサーバー、1つまたは複数のWebLogic Serverインスタンス、または1つのクラスタのターゲットとして指定できます。

- JMSサーバー - 接続ファクトリは、宛先と共に1つまたは複数のJMSサーバーのターゲットとして指定できます。また、接続ファクトリは、スタンド・アロンのキューまたはトピックとともに、特定のJMSサーバーのターゲットとなるサブデプロイメントにグループ化できます。これにより、グループ化されたすべてのリソースが同じ場所に配置され、余分なネットワーク・トラフィックを回避できます。この構成のもう1つのメリットは、ターゲットのJMSサーバーを別のWebLogic Serverインスタンスに移行する必要がある場合に、接続ファクトリとその接続のすべてがJMSサーバーの宛先と一緒に移行されることです。ただし、スタンドアロンのキューまたはトピックがサブデプロイメントのメンバーの場合は、接続ファクトリを同じJMSサーバー以外に関連付けることはできません。

- WebLogicサーバー・インスタンス - ドメイン内のあらゆるサーバーからJMS宛先への透過的なアクセスを確立するために、接続ファクトリを複数のWebLogic Serverインスタンスに同時に関連付けることができます。

- クラスタ - クラスタ内のすべてのサーバー・インスタンスまたは特定のサーバーに1つの接続ファクトリを関連付けることで、クラスタ内のあらゆるサーバーからJMS宛先へのクラスタ全体で透過的なアクセスを確立できます。

JMSシステム・モジュールのサブデプロイメントのターゲット指定の詳細は、「JMSシステム・モジュールとリソースのサブデプロイメントのターゲット指定」を参照してください。接続ファクトリのターゲット指定のベスト・プラクティスについては、「ターゲット指定のベスト・プラクティス」を参照してください

キューおよびトピック宛先の構成

JMS宛先は、JMSモジュール内のキュー(ポイント・ツー・ポイント)またはトピック(パブリッシュ/サブスクライブ)リソースを識別するものです。各キューおよびトピック・リソースは、特定のJMSサーバーのターゲットとして指定されます。JMSサーバーの最も重要な役割は、JMSサーバーの宛先が受信するすべての永続メッセージに使用される永続ストアに関する情報を管理し、また、JMSサーバーの宛先で作成される恒久サブスクライバの状態を管理することです。

必要な場合、JMSテンプレート、割当て設定、宛先ソート・キーなど、キューまたはトピック内から参照できる他のJMSリソースをモジュール内に作成できます。

- 割当: 割当てを宛先に割り当てたり、複数の宛先が1つの割当てを共有したり、宛先がJMSサーバーの割当てを共有することができます。Oracle WebLogic Serverのパフォーマンスのチューニングで割当ての定義を参照してください。

- JMSテンプレート: 同じようなオプション設定で複数の宛先を定義できます。JMSテンプレートは、一時キューの作成にも必要です。「JMSテンプレートの構成」を参照してください

- 宛先キー: 宛先で受信するメッセージのソート順序を独自に定義できます。「宛先キーの構成」を参照してください

キューおよびトピックの構成パラメータ

JMSキューは、JMSサーバーのポイント・ツー・ポイント宛先タイプを定義します。キューに配信されたメッセージは、1つのコンシューマに配信されます。JMSトピックは、JMSサーバーのパブリッシュ/サブスクライブ宛先タイプを識別します。トピックは、非同期のピア通信に使用されます。トピックに配信されたメッセージは、そのトピックでサブスクライブしているすべてのコンシューマに配信されます。

WebLogic Server管理コンソールを使用すると、システム・モジュール内のキューおよびトピック・リソースを構成、変更、ターゲット指定、および削除できます。キューおよびトピックのタスクの手順については、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのキューの構成およびトピックの構成を参照してください。キューおよびトピック・リソースの名前は、各JMSモジュール内で一意でなければなりません。また、各JMSモジュール内のすべてのキューおよびトピックのJNDI名は、WebLogicドメイン全体にわたって一意でなければなりません(「JMS構成のネーミング要件」を参照)。

以下のパラメータをキューまたはトピックに構成できます。

- 全般構成パラメータ。JNDI名、宛先に届くメッセージをソートする宛先キー、または複数の宛先のプロパティの構成にJMSテンプレートを使用する場合のJMSテンプレートの選択などのパラメータがあります。

注意:

キューおよびトピックのJNDI名は動的に変更できますが、MDBのように長期間存続するプロデューサまたはコンシューマは、変更後もキューまたはトピックの元のJNDI名からメッセージを生成したり、元のJNDI名にメッセージを送信したりしようとすることがあります。

- しきい値および割当てパラメータ。これらのパラメータによって、宛先のメッセージ数またはバイト数の最大および最小しきい値と最大割当てを定義します。「割当ての構成」を参照してください。

- メッセージ・ロギング・パラメータ。メッセージ・タイプ、ユーザー・プロパティ、JMSログ・ファイルに含めるロギング・メッセージのライフ・サイクル情報などがあります。
「メッセージ・ライフ・サイクルのロギング」を参照してくださいメッセージの生成、メッセージの挿入(処理中のメッセージ)、および宛先でのメッセージの消費の処理についての停止と再開を制御します。「宛先でのメッセージ処理の制御」を参照してください

- メッセージ配信オーバーライド・パラメータ。メッセージの優先度や配信時間の値など、メッセージ・プロデューサまたは接続ファクトリによって指定されている値をオーバーライドできます。

- メッセージ配信の失敗に関するパラメータ。再配信の制限の定義、メッセージ有効期限ポリシーの選択、期限切れメッセージのエラー宛先の指定などが含まれます。

- (トピックのみ)マルチキャスト・パラメータ。マルチキャスト・アドレス、存続時間(TTL)、ポートなどがあります。

オプションの中には、動的に構成できるものもあります。オプションが実行時に変更された場合、変更は新しく配信されるメッセージにのみ適用され、格納されているメッセージには影響しません。すべてのオプションのデフォルト値については、Oracle WebLogic Server MBeanリファレンスのQueueBeanおよびTopicBeanを参照してください。

エラー宛先を作成する

リカバリまたはロールバックされるメッセージを管理するために、再配信の制限に達したメッセージのエラー宛先を構成することもできます。エラー宛先はキューまたはトピックのいずれかにできますが、関連付けられている宛先と同じJMSサーバーのターゲットでなければなりません。詳細は、『Oracle WebLogic Server JMSアプリケーションの開発』の配信されなかったメッセージのエラー宛先の構成に関する項を参照してください。

分散宛先を作成する

分散宛先リソースは、単一の論理的な単位としてクライアントからアクセス可能な宛先のグループ(キューまたはトピック)です(たとえば分散トピックは独自のJNDI名を持ちます)。このセットのメンバーは通常、クラスタ内の複数のサーバーに分散されており、各メンバーは別々のJMSサーバーに属しています。「分散宛先の構成」を参照してください

キューおよびトピックのターゲット指定

スタンドアロンのキューおよびトピックは、ドメイン内の特定のJMSサーバーのみにデプロイできます。これは、永続メッセージ、恒久サブスクライバ、およびメッセージ・ページングの管理に関して、キューおよびトピックがターゲット指定されたJMSサーバーに依存するためです。

キューまたはトピックのグループを接続ファクトリとともに特定のJMSサーバーに関連付ける場合、これらの送り先と接続ファクトリを同じサブデプロイメントの対象として指定します。これにより、これらのリソースはサブデプロイメントの対象となるJMSサーバーに関連付けられます。ただし、スタンドアロンの宛先がサブデプロイメントのメンバーの場合は、接続ファクトリを同じJMSサーバー以外に関連付けることはできません。

JMSシステム・モジュールのサブデプロイメントのターゲット指定については、「JMSシステム・モジュールとリソースのサブデプロイメントのターゲット指定」を参照してください接続ファクトリのターゲット指定のベスト・プラクティスについては、「ターゲット指定のベスト・プラクティス」を参照してください

宛先のモニターと管理パラメータ

システム・モジュール内のキューおよびトピックの実行時統計をモニターできます。また、キューのメッセージおよびトピックの恒久サブスクライバを管理できます。

- WebLogic Server管理コンソールを使用したキューのモニターの詳細は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのJMSシステム・モジュールのキューのモニターを参照してください。

- キューのメッセージの管理については、「JMSメッセージの管理」を参照してください。

- WebLogic Server管理コンソールを使用したトピックのモニターの詳細は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのJMSシステム・モジュールのトピックのモニターを参照してください

- トピックの恒久サブスクライバの管理については、「JMSメッセージの管理」を参照してください。

JMSテンプレートの構成

JMSテンプレートを使用すると、同じようなオプション設定を持つ複数の宛先を効率的に定義できます。

- 新しい宛先を定義するたびに、すべてのオプション設定を再入力する必要はありません。JMSテンプレートを使用して、新しい値の割当てが必要な設定のみをオーバーライドします。

- テンプレートを変更するだけで、共有されるオプション設定を動的に変更できます。

- エラー宛先のサブデプロイメントを定義して、任意の数の宛先のサブデプロイメント(キューまたはトピックのグループ)が対応するテンプレート・サブデプロイメントで指定されたエラー宛先のみを使用するようにできます。

JMSテンプレートの構成パラメータ

WebLogic Server管理コンソールを使用すると、システム・モジュール内のJMSテンプレート・リソースを構成、変更、ターゲット指定、および削除できます。JMSテンプレートのタスクの手順については、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのJMSテンプレートの構成を参照してください。

JMSテンプレートに構成できるオプションは、宛先に構成されるオプションと同じです。「キューおよびトピックの構成パラメータ」を参照してください

これらの構成オプションは、それらを使用する宛先によって継承されます。ただし、以下の例外があります。

- JMSテンプレートを使用する宛先でオプションのオーバーライド値が指定される場合は、そのオーバーライド値が使用されます。

- JMSテンプレートを使用する宛先でオプションのメッセージ再配信値が指定される場合は、その再配信値が使用されます。

- 「名前」オプションは、宛先によって継承されません。この名前はJMSテンプレートでのみ有効です。宛先では、個々に一意の名前を明示的に定義しなければなりません。「JMS構成のネーミング要件」を参照してください

- 「JNDI名」、「ストアを有効化」、「テンプレート」の各オプションは、JMSテンプレートでは定義されません。

- 任意の数の宛先のサブデプロイメント(キューまたはトピックのグループ)が、対応するテンプレート・サブデプロイメントで指定されたエラー宛先のみを使用するように、エラー宛先のサブデプロイメントを構成できます。

宛先に対して明示的に定義されないオプションには、デフォルト値が割り当てられます。デフォルト値が存在しない場合は、JMSテンプレート内で値を指定するか、宛先のオプションのオーバーライドとして値を指定します。

テンプレート・オプションの中には、動的に構成できるものもあります。オプションを実行時に変更した場合、新しく配信されるメッセージにのみ適用され、すでに保存されているメッセージには影響しません。すべてのトピック・オプションのデフォルト値の詳細は、Oracle WebLogic Server MBeanリファレンスのTemplateBeanを参照してください。

宛先キーの構成

特定の宛先に到着したメッセージは、デフォルトではFIFO (先入れ先出し)で格納され、各メッセージの一意のJMSMessageIDに基づいて昇順にソートされます。しかし、宛先キーを使用することで、宛先に対してLIFO (後入れ先出し)などの異なるソート方式を構成できます。

WebLogic Server管理コンソールを使用すると、システム・モジュール内の宛先キー・リソースを構成、変更、ターゲット指定、および削除できます。宛先キーのタスクの手順については、Oracle WebLogic Server管理コンソール・オンライン・ヘルプの宛先キーの構成を参照してください。

すべての宛先キー・オプションのデフォルト値については、Oracle WebLogic Server MBeanリファレンスのDestinationKeyBeanを参照してください。

割当ての構成

割当てリソースでは、メッセージおよびバイトの最大数を定義します。これを1つまたは複数の宛先に関連付けることで、定義した最大数を強制することができます。

Oracle WebLogic Serverのパフォーマンスのチューニングで割当ての定義を参照してください。

外部サーバーの構成

外部サーバー・リソースにより、ローカルのWebLogic ServerのJNDIツリー内で、サード・パーティのJMSプロバイダを参照できます。外部サーバー・リソースを使用することで、外部のJMSプロバイダを即座にマップして、関連付けられた接続ファクトリと宛先をローカルJMSオブジェクトのようにWebLogic JNDIツリーに表示できます。また、別のクラスタまたはドメインにあるWebLogic Serverのリモート・インスタンスをローカルWebLogic JNDIツリー内で参照することもできます。

「外部サーバー・リソースからサード・パーティJMSプロバイダへのアクセスの構成」を参照してください

分散宛先の構成

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

「分散宛先リソースの構成」を参照してください

JMSストア・アンド・フォワード(SAF)の構成

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

Oracle WebLogic Serverストア・アンド・フォワード・サービスの管理のJMSメッセージに対するSAFの構成を参照してください。

4 拡張JMSシステム・リソースの構成

この章では、WebLogic Server 12.1.3のクラスタ環境での分散宛先などの拡張WebLogic JMSリソースを構成する方法について説明します。

この章の内容は次のとおりです。

- WebLogic JMSクラスタリングの構成

- JMS関連サービスの移行

- WebLogicパス・サービスの使用

- 外部サーバー・リソースからサード・パーティJMSプロバイダへのアクセスの構成

- 分散宛先リソースの構成

- 無制限ClientIDの構成

- 共有サブスクリプションの構成

WebLogic JMSクラスタリングの構成

WebLogic Serverのクラスタとはドメイン内で連携して動作するサーバーのグループであり、単一のサーバーよりもスケーラブルで信頼性のあるアプリケーション・プラットフォームを提供します。クラスタはそのクライアントからは単一のサーバーに見えますが、実際には一体で機能するサーバー群です。

注意:

JMSクライアントがクラスタに正常にアクセスするには、一意のWebLogic Server名が必要です(WebLogic Serverが別々のドメインに存在する場合にも必要です)。このため、JMSクライアントがアクセスするWebLogic Serverの名前は、すべて一意でなければなりません。

JMSクラスタリングの利点

JMSクラスタリングには、以下のメリットがあります。

- クラスタ内の複数のサーバーにわたる宛先のロード・バランシング
管理者は、次のようにして、クラスタ内の複数のサーバーにわたって宛先のロード・バランシングを設定できます。

- 1つのJMSサーバーを構成し、1つのWebLogicクラスタをターゲットに指定します。「簡略化されたJMSクラスタと高可用性の構成」を参照してください

- 複数のJMSサーバーを構成し、構成済の複数のWebLogic Serverをターゲットに指定する。

- 複数のJMSサーバーを構成し、1つの移行可能なターゲットのセットをターゲットに指定する。

各JMSサーバーは、厳密に1つのWebLogic Serverインスタンスにデプロイされ、宛先の集合に対するリクエストを処理します。

- 宛先の高可用性

- 分散宛先: 分散宛先のキューおよびトピック・メンバーは通常、クラスタ内の複数のサーバーに分散され、各メンバーは個々のJMSサーバーに属します。分散宛先を使用するアプリケーションは、単純な宛先を使用するアプリケーションより可用性が高くなります。WebLogic JMSは、クラスタ内の分散宛先のメンバーのためのロード・バランシングとフェイルオーバーの機能を備えているからです。分散宛先の詳細については、「分散宛先リソースの構成」を参照してください

- ストア・アンド・フォワード: JMSモジュールはSAFサービスを使用して、ローカルのJMSメッセージ・プロデューサがリモートのキューまたはトピックに確実にメッセージを送信できるようにします。ネットワークの問題やシステム障害が原因で、メッセージの送信時に宛先が使用不能になっている場合、メッセージはローカルのサーバー・インスタンスに保存され、リモートの宛先が使用可能になった時点で転送されます。詳細は、Oracle WebLogic Serverストア・アンド・フォワード・サービスの管理のストア・アンド・フォワード・サービスの理解を参照してください。

- 自動フェイルオーバーの場合、WebLogic Serverはサーバー・レベル(サーバー・インスタンス全体)での移行をサポートします。WebLogic Serverがホストするすべてのサービスを別のマシンに自動または手動で移行できます。詳細は、Oracle WebLogic Serverクラスタの管理のサーバー全体の移行を参照してください。

- クラスタ内のあらゆるサーバーからの、宛先へのクラスタ全体で透過的なアクセス
管理者は、クラスタ内の各サーバー・インスタンスのデフォルト接続ファクトリを使用するか、1つまたは複数の接続ファクトリを構成してクラスタ内の1つまたは複数のサーバー・インスタンスまたはクラスタ全体をターゲットとすることで、クラスタ内のあらゆるサーバーから宛先へのクラスタ全体で透過的なアクセスを確立できます。これにより、各接続ファクトリを複数のWebLogic Serverインスタンスにデプロイできます。接続ファクトリについては、「接続ファクトリの構成」を参照してください

- スケーラビリティ

- クラスタ内の複数のサーバーにわたる宛先のロード・バランシング。

- 接続ファクトリを通じた、複数のJMSサーバーでのアプリケーション負荷の分散。その結果として、個々のJMSサーバーでの負荷が削減され、かつ接続先を特定のサーバーに決めることでセッションの集中が可能となります。

- マルチキャストのサポート(オプション)。JMSサーバーで配信しなければならないメッセージの数が削減されます。JMSサーバーでは、サブスクライブしているアプリケーションの数に関係なく、マルチキャストIPアドレスと関連付けられている各ホスト・グループに対してメッセージが1コピーだけ転送されます。

- 移行性
WebLogic Serverはサーバー・レベル(サーバー・インスタンス全体)での移行をサポートします。WebLogic Serverがホストするすべてのサービスを別のマシンに自動または手動で移行できます。詳細は、Oracle WebLogic Serverクラスタの管理のサーバー全体の移行を参照してください。

WebLogic Serverは、クラスタをターゲットとして指定されたJMSサービスの自動サービス移行をサポートします。移行可能なターゲットを使用するかわりに、JMSサービス移行の場合はこの優先メソッドを使用してください。詳細は、「簡略化されたJMS構成と高可用性の拡張機能」を参照してください。

- JMSクライアントに対するサーバー・アフィニティ
クラスタ用に構成したロード・バランシング・アルゴリズム(ラウンドロビン・アフィニティ、重みベース・アフィニティ、またはランダム・アフィニティ)は、JMSクライアント接続のためのサーバー・アフィニティを提供します。JMSアプリケーションから指定したサーバー・インスタンスに接続できる場合、JMSは同じサーバー・インスタンスとの新しいJMS接続を確立しようとします。サーバー・アフィニティの詳細は、Oracle WebLogic Serverクラスタの管理のクラスタでのロード・バランシングを参照してください。

WebLogicクラスタの使用による機能と利点の詳細は、Oracle WebLogic Serverクラスタの管理のWebLogic Serverのクラスタリングの理解を参照してください。

JMSクラスタリングの仕組み

管理者は、クラスタ内の各サーバー・インスタンスのデフォルト接続ファクトリを使用するか、1つまたは複数の接続ファクトリを構成してクラスタ内の1つまたは複数のサーバー・インスタンスまたはクラスタ全体をターゲットとすることで、クラスタ内のあらゆるサーバーからJMS宛先へのクラスタ全体で透過的なアクセスを確立できます。これにより、各接続ファクトリを複数のWebLogic Serverにデプロイできます。接続ファクトリの構成とデプロイメントの詳細は、「接続ファクトリの構成パラメータ」を参照してください。

アプリケーションでは、Java Naming and Directory Interface (JNDI)を使用して接続ファクトリをルックアップし、JMSサーバーとの通信を確立するための接続を作成します。各JMSサーバーでは、複数の宛先に対するリクエストが処理されます。宛先へのリクエストが送信されるWebLogic Serverインスタンスが接続ファクトリのホストであり、JMSサーバーまたは宛先のホストではない場合、リクエストは接続ファクトリによって、JMSサーバーと宛先のホストになっている適切なWebLogic Serverインスタンスに転送されます。

管理者は、クラスタ内の様々なサーバー上の複数のJMSサーバーに一意の名前が付けられているかぎり、それらのJMSサーバーを構成して、JMSキューまたはトピック・リソースを割り当てることができます。または、クラスタの1つのJMSサーバーをターゲットにして、そのクラスタの各サーバーにJMSサーバーのインスタンスが自動的に作成されるようにすることもできます。アプリケーションでは、Java Naming and Directory Interface (JNDI)を使用して接続ファクトリをルックアップし、JMSサーバーとの通信を確立するための接続を作成します。各JMSサーバーでは、複数の宛先に対するリクエストが処理されます。JMSサーバーで処理されない宛先へのリクエストは、適切なWebLogic Serverインスタンスに転送されます。JMSサーバーの構成とデプロイメントの詳細は、「JMSサーバーの構成」を参照してください。

JMSクラスタリングのネーミング要件

単一のWebLogicドメイン環境または複数ドメイン環境でJMSオブジェクトおよびリソース(JMSサーバー、JMSモジュール、JMSリソースなど)がクラスタ化された環境で動作するように構成する際には、いくつかの命名要件があります。詳細については、「JMS構成のネーミング要件」を参照してください

クラスタ内での分散宛先

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

クラスタ内での移行可能なサービスとしてのJMSサービス

JMSサービスは、サーバー全体の移行(サーバーでホストされるすべてのサービスを別のマシンに移行する場合)だけでなく、シングルトン・サービスの移行フレームワークに組み込むこともできます。したがって、たとえばサーバーの障害に対処する場合や定期的な保守を実施する場合に、管理者はJMSサーバーとそのすべての宛先をクラスタ内の別のWebLogic Serverに移行することも可能です。これには、予定されている手動移行のほかに自動移行も含まれます。JMSサービスの移行の詳細は、「JMS関連サービスの移行」を参照してください。

JMSクラスタリングの構成のガイドライン

クラスタ環境でWebLogic JMSを使用するには、次の各ガイドラインに従います。

1. クラスタ化環境を構成します。Oracle WebLogic Serverクラスタの管理のWebLogicクラスタの設定を参照してください。

2. WebLogic Server管理コンソールを使用して、ユーザー定義のJMS接続ファクトリのターゲットを指定します。接続ファクトリ用には、単一のサーバー、クラスタ、または移行可能なターゲットを指定できます。

接続ファクトリの構成属性の詳細は、「接続ファクトリの構成」を参照してください

3. オプションで、高可用性向けの、クラスタ化されたJMSサービス・アーティファクトを構成します。「簡略化されたJMSクラスタと高可用性の構成」を参照してください。移行可能なターゲットを使用するかわりに、自動サービス移行では、クラスタをターゲット指定するJMSを使用してください。

JMSサーバーの構成属性の詳細は、「JMSサーバーの構成」を参照してください

注意:

同じ宛先を複数のJMSサーバーにデプロイすることはできません。また、1つのJMSサーバーを複数のWebLogic Serverにデプロイすることもできません。

4. 必要に応じて、クラスタ内に物理JMS宛先を仮想的な分散宛先セットの一部として構成できます。詳細については、「クラスタ内での分散宛先」を参照してください

5. JMSサーバーは、正しい構成に一致する永続ストアを持つ動的クラスタとして構成することもできます。

フェイルオーバーの場合

サーバーまたはネットワークの障害が発生した場合、JMSメッセージ・プロデューサ・オブジェクトとコンシューマ・オブジェクトは、別のサーバー・インスタンスに透過的にフェイルオーバーを試みます(使用可能なものがある場合)。WebLogic Serverリリース9.1以降では、既存のクライアント・コードを手動で構成または変更しなくても、WebLogic JMSメッセージ・プロデューサは、使用可能なサーバー・インスタンスへ自動的に再接続しようとします。WebLogic Serverリリース9.2以降では、WebLogic Server管理コンソールまたはWebLogic JMS APIを利用して、使用可能なサーバー・インスタンスに自動的に再接続を試行するようにWebLogic JMSメッセージ・コンシューマを構成できます。Oracle WebLogic Serverアプリケーションの開発のJMSクライアントの自動フェイルオーバーを参照してください。

注意:

WebLogic Server 9.x以前のJMSクライアント・アプリケーションについては、Oracle WebLogic Server JMSアプリケーションの開発のWebLogic Server 9.x以前のリリースでの障害に関するプログラミングの考慮事項を参照してください。

さらに、サービスの自動移行機能を実装すると、JMSのような「必ず1回」のサービスによって、クラスタ内の依存するアプリケーションに対するシングル・ポイント障害が発生しなくなります。動的クラスタをターゲットとして指定されたJMSサーバーのフェイルオーバーでは、フェイルバックおよび再起動インプレース機能を利用できます。「JMS関連サービスの移行」を参照してくださいWebLogic Serverでは、サーバー・レベルの移行、つまり、サーバー・インスタンス全体の移行もサポートされています。また、サーバー・インスタンスがホストするすべてのサービスを自動または手動で別のマシンに移行できます。Oracle WebLogic Serverクラスタの管理のサーバー全体の移行を参照してください。

クラスタ化環境では、WebLogic Serverは分散宛先を構成することによって1つのサーバーで障害が発生した場合でもサービスを継続できます。分散宛先では、キューおよびトピック・メンバーは通常、クラスタ内の複数のサーバーに分散され、各メンバーは個々のJMSサーバーに属します。「クラスタ内での分散宛先」を参照してください

また、高可用性クラスタリング・ソフトウェアを実装することをお薦めします。これにより、WebLogic Serverベースのアプリケーションに、統合された使いやすいソリューションがもたらされます。

JMS関連サービスの移行

JMS関連サービスはシングルトン・サービスであるため、クラスタ内のすべてのサーバー・インスタンスでアクティブになるわけではありません。かわりに、サービスがクラスタ内の単一サーバーに固定され、データの一貫性を保持します。シングルトンJMSサービスが原因で、クラスタ内の依存するアプリケーションに対するシングル・ポイント障害が発生しないようにするため、クラスタをターゲットとして指定されたJMSを使用して、JMS関連サービスを高可用性用に構成できます。詳細は、「簡略化されたJMS構成と高可用性の拡張機能」を参照してください。また、定期的なサーバー・メンテナンスを実施する前に、JMSサービスを手動で移行することも可能です。

移行可能なJMS関連サービスには以下が含まれます:

- JMSサーバー: ターゲット指定されているJMSモジュール内のキューおよびトピックの管理コンテナです。「JMSサーバーの構成」を参照してください

- ストア・アンド・フォワード(SAF)サービス: メッセージが送信された時点でリモート・エンドポイントが使用できない場合でも、ローカルの送信エンドポイントとリモートの受信エンドポイントの間でメッセージをストア・アンド・フォワードするサービスです。JMS SAF(送信機能のみ)用に構成された送信SAFエージェントのみを移行できます。『Oracle WebLogic Serverストア・アンド・フォワード・サービスの管理』のストア・アンド・フォワード・サービスの理解に関する項を参照してください。

- パス・サービス: JMSメッセージ順序単位内のメッセージのグループからクラスタ内のメッセージ・リソースへのマッピングの保持に使用できる永続マップです。パス・サービスは、クラスタごとに1つずつ構成します。「WebLogicパス・サービスの使用」を参照してください

- カスタム永続ストア: ユーザーが定義するディスク・ベースのファイル・ストアまたはJDBC対応データベースです。JMSメッセージやストア・アンド・フォワード・メッセージなどのサブシステム・データを格納するために使用します。『Oracle WebLogic Serverサーバー環境の管理』のWebLogic永続ストアの使用に関する項を参照してください。

Oracle WebLogic Serverクラスタの管理のサービスの移行フレームワークの理解を参照してください。

JMSサービスの自動移行

管理者は、ヘルス監視サブシステムを活用することで、障害が発生した現在のホスト・サーバーでホストされているJMSサービスが正常に動作しているサーバーに自動的に移行するよう、移行可能ターゲットを構成できます。JMS関連サービスの自動移行の構成の詳細は、Oracle WebLogic Serverクラスタの管理のJMS関連サービスの自動移行を構成するためのロードマップを参照してください。

JMSサービスの手動移行

ホスト・サーバーで障害が発生した場合や、サーバー・メンテナンスを実施する前には、JMS関連サービスを正常なサーバーに手動で移行できます。JMS関連サービスの手動移行の構成の詳細は、Oracle WebLogic Serverクラスタの管理のJMS関連サービスの手動移行を構成するためのロードマップを参照してください。

永続ストアの高可用性

「フェイルオーバーの場合」で説明されているように、カスタム永続ストアを含むJMSサービスは、「サーバー全体」の移行機能の一部として移行したり、移行可能なJMS関連サービスをターゲットとした「サービス・レベル」の移行の一部として移行できます。移行可能なJMS関連サービスで、デフォルトの永続ファイル・ストアを使用することはできないので、カスタム・ファイル・ストアまたはJDBCストアを構成し、そのストアと関連付けられたJMSサーバーまたはSAFエージェントと同じ移行可能ターゲットにそのストアをターゲット指定する必要があります。(パス・サービスの場合は、専用のカスタム・ストアと移行可能ターゲットを使用するのがベスト・プラクティスです。)

移行可能なカスタム・ファイル・ストアは、クラスタ内の移行可能ターゲット・サーバーから使用できる共有ディスクに構成したり、移行前/移行後スクリプトを使用してバックアップ・サーバー・ターゲットに移行したりできます。永続ストアの移行の詳細は、Oracle WebLogic Serverクラスタの管理のJMSサービスで使用できるカスタム・ストアを参照してください。

WebLogicパス・サービスの使用

WebLogic Serverパス・サービスは、JMSメッセージ順序単位内のメッセージのグループから、クラスタ内のメッセージ・リソースへの、マッピングの保持に使用できる永続マップです。パス・サービスは、サーブレットをホストするクラスタのメンバー、分散キュー・メンバー、またはストア・アンド・フォワード・エージェントにメッセージを固定することによって、順序付けを実現します。パス・サービスは、クラスタごとに1つずつ構成します。メッセージ順序単位機能の詳細は、Oracle WebLogic Server JMSアプリケーションの開発のメッセージ順序単位の使用を参照してください。

クラスタにパス・サービスを構成する方法については、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのパス・サービスの構成を参照してください。

パス・サービスによる高可用性

パス・サービスで高可用性を達成するには、様々な方法があります。

- サーバー全体の移行を使用して、パス・サービスが実行されるWebLogic Serverを再起動できます。『Oracle Fusion Middlewareクラスタの管理』を参照してください。『Oracle WebLogic Serverクラスタの管理』のサーバー全体の移行に関する項を参照してください。

- 自動サービス移行を設定して、パス・サービス・ストアを構成できます。パス・サービスは、シングルトン分散ポリシーを使用して、クラスタをターゲットにしたストアを使用できます。詳細は、「簡略化されたJMSクラスタと高可用性の構成」を参照してください

- パス・サービスとそのストアを構成して、移行可能なターゲットを使用できます。ただし、移行可能なパス・サービスではデフォルト・ストアを使用できないため、カスタム・ストアを構成し、同じ移行可能ターゲットにターゲット指定する必要があります。さらに、ベスト・プラクティスとしては、その移行可能ターゲットのユーザーを、パス・サービスとそのカスタム・ストアに限定する必要があります。『Oracle WebLogic Serverクラスタの管理』のサービスの移行フレームワークの理解に関する項を参照してください。

メッセージUOOとパス・サービスの実装

メッセージ順序単位とパス・サービス・ベースのルーティングを実装する際には、次の点に留意してください。

- 各パス・サービス・マッピングは永続ストアに格納されます。パス・サービスを構成する場合、高可用性ソリューションを使用する永続ストアを選択します。「永続ストアの高可用性」を参照してください

- 複数のプロデューサが同じ順序単位名を使用してメッセージを送信する場合、すべてのメッセージは同じパス・エントリを共有し、同じメンバー・キュー宛先を持ちます。

- 順序単位名に必要なルートにアクセスできない場合、メッセージを送信したプロデューサはJMSOrderExceptionを送出します。この例外がスローされるのは、JMSメッセージ・システムが必要なサービス品質を満たすことができないからです。特定の順序単位名に対しては、1つの分散宛先メンバーのみがメッセージを消費できます。

- パス・エントリは、最後のプロデューサと最後のメッセージ参照が削除されたときに自動的に削除されます。

- システムによっては、パス・サービスを使用するとシステムのスループットが低下する場合があります。これは、パス・エントリを作成、読み取り、および削除するためのリモート・ディスク処理が原因で起こります。

- 分散キューとその個々のメンバーは、一意の宛先を表します。例:
DXQ1は、Q1とQ2というメンバーを持つ分散キューです。またDXQ1はFredという名前の順序単位を持ち、パス・サービスによってQ2メンバーにマップされています。

- メッセージM1がDXQ1に送信されると、パス・サービスによってQ2へのルートが定義されます。

- メッセージM1が直接Q2に送信されると、パス・サービスによるルーティングは行われません。これは、アプリケーションが直接Q2を選択し、分散宛先からメンバーを選択するよう要求されなかったからです。

- パス・サービスを使用する場合は、メッセージを分散宛先に送信します。使用しない場合は、直接メンバーに送信します。

- ある分散キューの中に、同じ順序単位名の宛先が複数存在してもかまわません。例:
Fredという順序単位名のキューQ3が存在するとします。Q3がDXQ1に追加された場合は、分散キューの中に同じ順序単位名の宛先が2つ存在することになります。Q3とDXQ1は同じ順序単位名Fredを共有しますが、それぞれが一意のルートと宛先を持っており、これによりサーバーは宛先ごとに適切なメッセージ順序付けを提供し続けることができます。

- 分散キューからキューを削除する前や、分散キューにキューを追加する前には、キューを空にします。削除されたメンバーのパス・エントリはパス・サービスによって削除されますが、短い遷移期間が発生します。ここでは、キューが削除されているのにパス・エントリがまだ存在する場合に、生成されたメッセージによって例外JMSOrderExceptionがスローされる場合があります。

外部サーバー・リソースからサード・パーティJMSプロバイダへのアクセスの構成

WebLogic JMSでは、サード・パーティJMSプロバイダをローカルWebLogic Server JNDIツリー内で参照できます。JMSモジュール内で外部サーバー・リソースを使用することで、外部のJMSプロバイダを即座にマップして、関連付けられた接続ファクトリと宛先をローカルJMSオブジェクトのようにWebLogic JNDIツリーに表示できます。また、別のクラスタまたはドメインにあるWebLogic Serverのリモート・インスタンスをローカルWebLogic JNDIツリー内で参照することもできます。

リモートおよび外部JMSプロバイダの統合の詳細は、Oracle WebLogic Server JMSアプリケーションの開発のEJBとサーブレットにWebLogic JMSを使用するための拡張2EEサポートを参照してください。

以下の節では、外部サーバーの機能と、リモートMQSeries JNDIプロバイダにアクセスするためのサンプル構成について説明します。

- WebLogic JMSから外部JMSプロバイダへのアクセス

- 外部サーバー・リソースを作成する

- 外部接続ファクトリ・リソースを作成する

- 外部宛先リソースを作成する

- MQSeries JNDI用のサンプル構成

- Oracle AQ JMSとの相互運用

WebLogic JMSから外部JMSプロバイダへのアクセス

外部JMSサーバーがデプロイされると、WebLogic Server JNDIにローカルの接続ファクトリと宛先のオブジェクトが作成されます。外部接続ファクトリまたは宛先のオブジェクトがローカル・サーバーでルックアップされると、そのオブジェクトはリモートJNDIディレクトリで実際のルックアップを実行し、そのディレクトリから外部オブジェクトが返されます。

この方法を使用すると、複数のWebLogicメッセージング・ブリッジ送り先の構成が簡単になります。外部サーバーが、JNDI初期コンテキスト・ファクトリおよび接続URLの構成の詳細をメッセージング・ブリッジ送り先の構成の外側に移すからです。外部接続ファクトリおよび宛先JNDI名をオブジェクトごとに指定するだけで済みます。

メッセージング・ブリッジの構成の詳細は、Oracle WebLogic Server WebLogicメッセージング・ブリッジの管理で、メッセージング・ブリッジの構成と管理を参照してください。

また、この構成の簡素化は、WebLogic JMSでのWebLogicサーブレット、EJB、およびメッセージドリブンBean (MDB)の構成にも当てはまります。たとえば、MDBのweblogic-ejb-jar.xmlファイルではローカルJNDI名を指定でき、外部JMSサーバーを使用してMDBがメッセージを受け取る場所を制御できます。具体的には、あるJMS宛先およびサーバーと通信するためにある環境でMDBをデプロイし、同じweblogic-ejb-jar.xmlファイルを別のサーバーにデプロイして、それを別のJMS宛先と通信させることができます。その際、weblogic-ejb-jar.xmlファイルを復元して編集する必要はありません。

外部サーバー・リソースを作成する

外部サーバーには、ローカルWebLogic ServerインスタンスがリモートJNDIプロバイダにアクセスするための情報が保持されています。外部サーバーには、ローカルWebLogic ServerインスタンスがリモートJNDIプロバイダにアクセスするための情報が保持されています。これにより、1つのJNDIディレクトリに対して複数の外部接続ファクトリと宛先のオブジェクトを定義できます。

WebLogic Server管理コンソールを使用すると、システム・モジュール内の外部サーバー・リソースを構成、変更、ターゲット指定、および削除できます。外部サーバーのタスクの手順については、Oracle WebLogic Server管理コンソール・オンライン・ヘルプの外部サーバーの構成を参照してください。

注意:

エンタープライズ・アプリケーション内でのJMSアプリケーション・モジュールの構成およびデプロイについては、「JMSアプリケーション・モジュールのデプロイメントの構成」を参照してください。

一部の外部サーバー・オプションは、動的に構成できます。オプションが実行時に変更された場合、変更は新しく配信されるメッセージにのみ適用され、格納されているメッセージには影響しません。すべての外部サーバー・オプションのデフォルト値の詳細は、Oracle WebLogic Server MBeanリファレンスのForeignServerBeanを参照してください。

外部サーバーを定義したら、接続ファクトリおよび宛先のオブジェクトを構成できます。各外部サーバーに対して、1つまたは複数の接続ファクトリおよび宛先(キューまたはトピック)を構成できます。

外部接続ファクトリ・リソースを作成する

JMSモジュール内の外部接続ファクトリ・リソースには、リモートJNDIプロバイダの接続ファクトリのJNDI名、ローカルWebLogic Server JNDIツリー内でその接続ファクトリにマップされるJNDI名、およびユーザー名とパスワード(オプション)が定義されます。

外部接続ファクトリは、親の外部サーバーの割当て先となる各WebLogic Serverインスタンスに対してレプリケートされていないJNDIオブジェクトを作成します(クラスタ内の各ノードにJNDIオブジェクトを作成するには、クラスタに外部サーバーを割り当てます)。

外部宛先リソースを作成する

JMSモジュール内の「外部宛先です」リソースは、キューまたはトピックを表します。外部宛先には、外部JNDIプロバイダでルックアップされる宛先のJNDI名、およびローカルWebLogic Serverで宛先がマップされるJNDI名が保持されます。外部宛先がローカル・サーバーでルックアップされる場合、ルックアップはリモートJNDIディレクトリで実行され、そのディレクトリから宛先オブジェクトが返されます。

MQSeries JNDI用のサンプル構成

表4-1に、リモートMQSeries JNDIプロバイダにアクセスする場合のサンプル構成を示します。

表4-1 MQSeriesサンプル構成

外部JMSオブジェクト

オプション名

サンプル構成データ

外部サーバー

名前

JNDI初期コンテキスト・ファクトリ

JNDI接続URL

JNDIプロパティ

MQJNDI

com.sun.jndi.fscontext.RefFSContextFactory

ファイル:/MQJNDI/

(必要な場合、カンマ区切りのname=valueプロパティ・リストを入力します)。

外部

接続ファクトリ

名前

ローカルJNDI名

リモートJNDI名

ユーザー名

パスワード

MQ_QCF

mqseries.QCF

QCF

weblogic_jms

weblogic_jms

外部

宛先1

外部

宛先2

名前

ローカルJNDI名

リモートJNDI名

名前

ローカルJNDI名

リモートJNDI名

MQ_QUEUE1

mqseries.QUEUE1

QUEUE_1

MQ_QUEUE2

mqseries.QUEUE2

QUEUE_2

分散宛先リソースの構成

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

以降の節では、分散宛先の作成、モニター、およびロード・バランシングを行う方法について説明します。

- 共通分散宛先と重み設定された分散宛先

- 共通分散宛先の作成

- 重み設定された分散宛先の作成

- UDDメンバーをモニターする

- 分散宛先でのメッセージのロード・バランシング

- 分散宛先の移行

- 分散宛先のフェイルオーバー

共通分散宛先と重み設定された分散宛先

注意:

重み設定された分散宛先は、WebLogic Server 10.3.4.0では非推奨です。共通分散宛先を使用することをお薦めします。

WebLogic Server 9.x以降には、共通分散宛先と重み設定された分散宛先という2種類の分散宛先が用意されています。WebLogic Server 9.xより前のリリースでは、WebLogic管理者が、物理宛先を分散宛先のメンバーとして機能するように手動で頻繁に構成する必要がありました。この方法は、追加のメッセージ負荷または容量に対応するメンバーを作成できるという柔軟性を備えていました。しかし、このような重み設定された分散宛先はクラスタ内で一貫してデプロイされなかったため、管理上およびアプリケーション上の問題が発生することもよくありました。このタイプの分散宛先は、公式には「重み設定された分散宛先」(WDD)と呼ばれます。

共通分散宛先(UDD)は、分散宛先アプリケーションの管理と開発を大幅に簡略化します。共通分散宛先を使用すると、送り先のメンバーを作成したり指定する必要がなくなりますが、かわりにWebLogic Serverを使用して、必要なメンバーをJMSモジュールの対象となるJMSサーバー上に均等に作成することもできます。この機能によって、重み、セキュリティ、永続性、ページング、割り当てなどに関する分散宛先パラメータのすべてを一貫して構成できます。

分散宛先メンバーを手動で調整する場合は、従来の重み設定された分散宛先の機能も依然として使用できます。ただし、クラスタ内で一貫してデプロイされていない重み設定された分散宛先に起因して起こり得る管理上およびアプリケーションの問題を回避するため、共通分散宛先を構成することをお薦めします。

アプリケーションでの分散宛先の使用の詳細は、Oracle WebLogic Server JMSアプリケーションの開発の分散宛先の使用を参照してください。

共通分散宛先の作成

WebLogic Server管理コンソールを使用すると、次のJMSシステム・モジュールのUDDリソースを構成、変更、ターゲット指定および削除できます。

注意:

UDDリソースをオプションのHA構成設定でホスティングするために、単一クラスタをターゲットとして指定されたJMSサーバーと、関連付けられた永続ストアを作成しておくことをお薦めします。これはUDD構成をシンプル、スケーラブルにし、可用性を高めます。「簡略化されたJMSクラスタと高可用性の構成」を参照してくださいレプリケートされた分散トピックは、クラスタをターゲットとして指定されたJMSサーバーによってサポートされません。

共通分散宛先のタスクの手順については、Oracle WebLogic Server管理コンソール・オンライン・ヘルプの次のトピックを参照してください。

- 共通分散キューの構成

- 共通分散トピックの構成

共通分散宛先オプションの中には、動的に構成できるものもあります。オプションが実行時に変更された場合、変更は新しく配信されるメッセージにのみ適用され、格納されているメッセージには影響しません。すべての共通分散宛先オプションのデフォルト値については、Oracle WebLogic Server MBeanリファレンスの次の項目を参照してください。

- UniformDistributedQueueBean

- UniformDistributedTopicBean

注意:
エンタープライズ・アプリケーション内でのJMSアプリケーション・モジュールの構成およびデプロイについては、「JMSアプリケーション・モジュールのデプロイメントの構成」を参照してください。

次の項では、共通分散宛先の追加情報を説明します。

- 共通分散キューおよびトピックをターゲット指定する

- UDDメンバーに対するメッセージ処理を休止、再開する

- UDDメンバーをモニターする

- パーティション化された分散トピックの構成

共通分散キューおよびトピックをターゲット指定する

ドメイン内の特定のJMSサーバーのみをターゲットとして指定できる、モジュール内のスタンドアロンのキューおよびトピック・リソースとは異なり、UDDは1つまたは複数のJMSサーバー、1つまたは複数のWebLogic Serverインスタンス、または1つのクラスタをターゲットとして指定できます。UDDの目的は、そのメンバーをドメイン内の各JMSサーバーに分散することだからです。たとえば、クラスタをUDDのターゲットとして指定した場合、そのクラスタ内の各JMSサーバーでメンバーが均等に構成されます。

注意:

- UDDのターゲットとして、単一クラスタをターゲットとして指定されたJMSサーバーを指定することをお薦めします。

- UDDのターゲットを変更すると、メンバー宛先が削除され、メッセージが失われてしまうおそれがあります。

また、UDDを構成するときにサブデプロイメント・グループを使用して、特定のリソースを分散メンバーにリンクできます。たとえば、jmssysmod-jms.xmlというシステム・モジュールが、構成済みのJMSサーバーを持つwlserver1、wlserver2、wlserver3という3つのWebLogic Serverインスタンスのターゲットとして指定されている場合に、1つの共通分散キューと接続ファクトリを各サーバー・インスタンスのターゲットとして指定するのであれば、共通分散キューと接続ファクトリをservergroupという名前の1つのサブデプロイメント内でグループ化して、これらのリソースが常にこれらのサーバー・インスタンスにリンクされるようにすることができます。

次に、サブデプロイメント・リソースservergroupをjmssysmod-jms.xmlでどのように指定するのかを示します。

<weblogic-jms xmlns="http://xmlns.oracle.com/weblogic/weblogic-jms">
<connection-factory name="connfactory">
<sub-deployment-name>servergroup</sub-deployment-name>
<jndi-name>jms.connectionfactory.CF</jndi-name>
</connection-factory>
<uniform-distributed-queue name="UniformDistributedQueue">
<sub-deployment-name>servergroup</sub-deployment-name>
<jndi-name>jms.queue.UDQ</jndi-name>
<forward-delay>10</forward-delay>
</uniform-distributed-queue>
</weblogic-jms>

次に、ドメインの構成ファイルでサブデプロイメントservergroupをどのようにターゲット指定するかを示します。

<jms-system-resource>
<name>jmssysmod-jms</name>
<target>cluster1,</target>
<sub-deployment>
<name>servergroup</name>
<target>wlserver1,wlserver2,wlserver3</target>
</sub-deployment>
<descriptor-file-name>jms/jmssysmod-jms.xml</descriptor-file-name>
</jms-system-resource>

UDDメンバーに対するメッセージ処理を休止、再開する

共通分散宛先でのメッセージの生成、挿入、および消費処理は、プログラム的に(JMXと実行時MBean APIを使用)、または管理的に(WebLogic Server管理コンソールを使用)休止および再開できます。外部リソースに障害が発生したとき、JMSサブシステムがメッセージの受け付けと配信(および再配信)を継続すると、システムに過度の負荷がかかることがあります。しかし、メッセージ処理を休止(および再開)することで、外部リソースの障害発生時のJMSサブシステムの動作を制御できます。

「休止と再開」の機能の詳細は、「宛先でのメッセージ処理の制御」を参照してください

UDDメンバーをモニターする

共通分散宛先メンバーの実行時統計は、WebLogic Server管理コンソールを使用してモニターできます。「JMS統計のモニター」を参照してください

パーティション化された分散トピックの構成

共通分散トピック・メッセージのForwarding Policyは、送信済メッセージがすべてのメンバーに転送されるかどうかを指定します。

有効な値は以下のとおりです。

- Replicated: デフォルトです。すべての物理トピック・メンバーは各送信済メッセージを受信します。メッセージが物理トピック・メンバーのいずれかに着信する場合、該当する共通分散トピックの他のメンバーにこのメッセージのコピーが転送されます。いずれかの特定のメンバー上のサブスクリプションは、共通分散トピックの論理名または特定の共通分散トピック・メンバーに送信されたメッセージのコピーを取得します。

- Partitioned: メッセージ受信側の物理メンバーは、メッセージを認識する共通分散トピックの唯一のメンバーです。メッセージがパーティション化された共通分散トピックの論理名にパブリッシュされるとき、特定の1つの物理トピック・メンバー上にのみ着信します。メッセージが物理トピック・メンバー上に着信すると、メッセージは共通分散宛先の残りのメンバーには転送されず、他の物理トピック・メンバー上のサブスクライバは当該メッセージのコピーを取得しません。

大半の新しいアプリケーションでは、次のように構成される共通分散トピック上の論理サブスクリプション・トポロジと組み合せて、Partitioned転送ポリシーを使用します。

- 各物理メンバー上で直接作成された同一名の物理サブスクリプション。

- UnrestrictedのクライアントIDポリシー。

- Sharableのサブスクリプション共有ポリシー。

パーティション化された分散トピックの作成および使用の詳細は、次を参照してください。

- Oracle WebLogic Server管理コンソール・オンライン・ヘルプのシステム・モジュールにおけるパーティション化された共通分散トピックの作成。

- 『Oracle WebLogic ServerメッセージドリブンBeanの開発』の分散トピックを使用したMDBの構成およびデプロイに関する項

- 『Oracle WebLogic Server JMSアプリケーションの開発』の高度なPub/Subアプリケーションの開発に関する項

パーティション化された分散トピックのロード・バランシング

パーティション化されたトピックのパブリッシャには、接続ファクトリのAffinityおよびLoad Balance属性をチューニングすることによって、複数のメンバー全体に渡るメッセージのロード・バランシング・オプションがあります。「順序単位」メッセージは、UOOルーティング・ポリシーおよびサブスクライバ・ステータスに基づいて適切なメンバーにルーティングされます。Oracle WebLogic Server管理コンソール・オンライン・ヘルプの接続ファクトリのロード・バランシング・パラメータの構成に関する項を参照してください。

重み設定された分散宛先の作成

注意:

重み設定された分散宛先(WDD)は、WebLogic Server 10.3.4.0では非推奨です。共通分散宛先を使用することをお薦めします。

WebLogic Server管理コンソールを使用すると、JMSシステム・モジュール内のWDDリソースを構成、変更、ターゲット指定、および削除できます。分散トピックまたはキューを構成する場合、「メンバーの均等割当て」チェック・ボックスのチェックを外すことによって、既存のキューとトピックを手動で選択して分散宛先に追加し、分散宛先メンバーの重みを調整できます。

重み設定された分散宛先のタスクの手順については、Oracle WebLogic Server管理コンソール・オンライン・ヘルプの次のトピックを参照してください。

- システム・モジュール内の重み設定された分散キューの作成

- システム・モジュール内の重み設定された分散トピックの作成

重み設定された分散宛先のオプションには、動的に構成できるものもあります。オプションが実行時に変更された場合、変更は新しく配信されるメッセージにのみ適用され、格納されているメッセージには影響しません。重み設定された分散宛先の、すべてのオプションのデフォルト値の詳細は、Oracle WebLogic Server MBeanリファレンスの次の項目を参照してください。

- DistributedQueueBean

- DistributedTopicBean

UDDとは異なり、WDDメンバーはWebLogic Server管理コンソールまたは実行時MBeanでモニターできません。また、WDDメンバーはドメイン内のJMSサーバーまたはWebLogic Serverインスタンスに均等に割り当てることはできません。かわりに、これらのインスタンス上で新しいWDDメンバーを手動で構成し、手動でWDDに追加する必要があります。

分散宛先でのメッセージのロード・バランシング

JMSは分散宛先を使用して、複数の宛先にメッセージの負荷を分散し、バランスを取ることができます。これによって、リソースがさらに効率的に利用され、レスポンス時間が改善されます。JMSのロード・バランシング・アルゴリズムでは、メッセージの送信先となる物理宛先に加えて、コンシューマの割当て先の物理宛先も決定されます。

ロード・バランシングのオプション

WebLogic JMSは、任意の分散宛先セットに含まれている複数の物理宛先間でメッセージのロード・バランシングを行うための2種類のアルゴリズムをサポートしています。これらのロード・バランシング・オプションのどちらかを選択するには、WebLogic Server管理コンソールで分散トピックまたは分散キューを構成します。

ラウンドロビン分散

ラウンドロビン・アルゴリズムでは、WebLogic JMSは分散宛先内の物理宛先の順序を管理します。メッセージの負荷は、WebLogic Server構成(config.xml)ファイルに定義されている順番で、一度に1つずつ物理宛先に分散されます。各WebLogic Serverは同一の順序を維持しますが、その順序内の位置は異なります。特定の分散宛先を使用して単一のサーバー内で複数のスレッドを実行すると、スレッドからメッセージが生成されるたびに、メンバーが割り当てられている物理宛先に関連して、これらのスレッドが互いに影響し合うことになります。ラウンドロビンはデフォルトのアルゴリズムで、構成の必要はありません。

重み設定された分散宛先のみの場合、セット内の物理宛先のいずれかに重みが割り当てられている場合、それらの物理宛先は順序内に複数回発生します。

ランダム分散

ランダム分散アルゴリズムでは、物理宛先に割り当てられている重みを使用して、一連の物理宛先の重み付き宛先を計算します。メッセージの負荷は、疑似ランダム的に宛先にアクセスすることで、物理宛先に分散されます。短期的には、負荷は重みには直接比例しません。長期的には、極限に近い分散が行われます。純粋なランダム分散は、重みすべてに同じ値を設定することで達成できます。この値は通常1です。

メンバーが追加または削除された(管理者が行うか、WebLogic Serverがシャットダウンまたは再起動した結果発生したもの)場合は、分散を再計算する必要があります。ただし、このようなイベントは頻繁に発生せず、計算は通常単純で、O(n)時間で実行されます。

コンシューマをロード・バランシングする

アプリケーションがコンシューマを作成するときは、宛先を指定する必要があります。その宛先が分散宛先を表す場合、WebLogic JMSではコンシューマのメッセージの受信元になる物理宛先を見つける必要があります。使用する宛先メンバーの選択には、ロード・バランシング・アルゴリズム(「ロード・バランシングのオプション」を参照)のいずれかが使用されます。この選択は、コンシューマの作成時に1度だけ行われます。その後、コンシューマはそのメンバーのみからメッセージを受信するようになります。

プロデューサをロード・バランシングする

プロデューサがメッセージを送信するとき、WebLogic JMSはメッセージが送信される宛先を確認します。宛先が分散宛先である場合は、メッセージの送信先がWebLogic JMSによって決定されます。つまり、プロデューサは「ロード・バランシングのオプション」で説明されているロード・バランシングのアルゴリズムのいずれかに従って、宛先のメンバーのいずれかに送信します。

プロデューサはメッセージを送信するたびにこのような決定を行います。ただし、コンシューマとプロデューサ間の序列の保証が脅かされることはありません。コンシューマのロード・バランシングがいったん行われると、コンシューマは単一の宛先メンバーに固定されるためです。

注意:

プロデューサが永続メッセージを分散宛先に送信しようとする場合、永続ストアを利用している分散メンバーにまずメッセージが転送されるよう、あらゆる努力がなされます。ただし、分散メンバーがいずれも永続ストアを利用していない場合でも、メッセージは選択されているロード・バランシング・アルゴリズムに従って、メンバーのいずれかに送信されます。

ロード・バランシングのヒューリスティック

「ロード・バランシングのオプション」に説明されているアルゴリズムに加えて、WebLogic JMSでは、宛先のインスタンスを選択するときに次のヒューリスティックが使用されます。

トランザクション・アフィニティ

トランザクション・セッション内で複数のメッセージを作成するときは、作成されたメッセージすべてを同じWebLogic Serverに送信しようとします。つまり、セッションが単一の分散宛先に複数のメッセージを送信した場合は、すべてのメッセージが同じ物理宛先に転送されます。セッションによって複数のメッセージが複数の異なる分散宛先に送信された場合は、同じWebLogic Serverがサービスを提供する一連の物理宛先が選択されるようになります。

サーバー・アフィニティ

接続ファクトリの「サーバー・アフィニティの有効化」パラメータでは、分散宛先内にある複数のメンバー宛先の間でコンシューマまたはプロデューサをロード・バランシングしているWebLogic Serverが、同じWebLogic Server上で実行されている他のローカル宛先メンバーの間でロード・バランシングを最初に試みるかどうかを定義します。

注意:

「サーバー・アフィニティの有効化」属性は、キュー・ブラウザには影響しません。したがって、「サーバー・アフィニティの有効化」が有効になっている場合でも、分散キューに作成されたキュー・ブラウザをリモート分散キュー・メンバーに固定できます。

接続ファクトリでサーバー・アフィニティを無効化するには:

1. Oracle WebLogic Server管理コンソール・オンライン・ヘルプの接続ファクトリのロード・バランシング・パラメータの構成の説明に従って、「JMSコネクション・ファクトリ」→「構成」→全般ページに移動します。

2. 「サーバー・アフィニティの有効化」フィールドを次のように定義します。

- 「サーバー・アフィニティの有効化」チェック・ボックスを選択します(trueとします)。この場合、分散宛先セット内にある複数の物理宛先の間でコンシューマまたはプロデューサをロード・バランシングしているWebLogic Serverは、同じWebLogic Server上で実行されている他の物理宛先の間でロード・バランシングを最初に試みます。

- 「サーバー・アフィニティの有効化」チェック・ボックスを選択しない場合(False)、WebLogic Serverは、分散宛先セット内の複数の物理宛先にまたがるコンシューマまたはプロデューサのロード・バランシングを実行し、同じWebLogic Serverで実行されている他の物理宛先を無視します。

3. 「保存」をクリックします。

「サーバー・アフィニティの有効化」の設定が分散宛先のメンバー間のロード・バランシングにどのように影響するかについては、「サーバー・アフィニティを有効化した場合の分散宛先ロード・バランシングへの影響」を参照してください

コンシューマのないキュー

複数のリモートの物理的キュー間でコンシューマのロード・バランシングを行う場合、1つまたは複数のキューにコンシューマがないとき、それらのキューだけがロード・バランシングの対象となります。セット内の物理的キューすべてに少なくとも1つのコンシューマが含まれるようになると、標準のアルゴリズムが適用されます。

また、プロデューサがメッセージを送信するとき、コンシューマのないキューはメッセージ生成の対象にはなりません。ただし、任意のキューのインスタンスのいずれにもコンシューマが含まれていない場合を除きます。

分散宛先メンバーの休止

分散宛先でメッセージの生成または挿入が休止された場合、それらはメッセージ生成の対象とは見なされません。同様に、分散宛先でメッセージの消費が休止された場合、それらはメッセージ生成の対象とは見なされません。

宛先でのメッセージ処理の休止については、「宛先でのメッセージ処理の制御」を参照してください

ロード・バランシングを回避する

アプリケーションは、個別の物理宛先に直接アクセスすることで、ロード・バランシングを回避できます。つまり、物理宛先にJNDI名がない場合でも、createQueue()メソッドまたはcreateTopic()メソッドを使用して参照することができます。

共通分散宛先や重み設定された分散宛先のメンバーに直接アクセスする方法については、Oracle WebLogic Server JMSアプリケーションの開発の分散宛先メンバーへのアクセスを参照してください。

接続ファクトリ

アプリケーションにおいて、分散宛先を使用して、複数の物理宛先間でプロデューサやコンシューマを分散、つまりバランスさせることは行っても、メッセージが作成されるたびにロード・バランシングの決定を行いたくない場合は、「ロード・バランシングの有効化」パラメータを無効化した状態で接続ファクトリを使用します。分散宛先においてメッセージの負荷が適正に分散されるようにするには、プロデューサによって使用される初期の物理宛先(キューまたはトピック)が、物理宛先メンバーによって常にランダムに選択される必要があります。

接続ファクトリでのロード・バランシングを無効化するには:

1. Oracle WebLogic Server管理コンソール・オンライン・ヘルプの接続ファクトリのロード・バランシング・パラメータの構成の説明に従って、「JMSコネクション・ファクトリ」→「構成」→全般ページに移動します。

2. 次のガイドラインに従って、「ロード・バランシングの有効化」フィールドを設定します。

- ロード・バランシングを有効化 = True
Queue.sender.send()メソッドでは、分散キュー・メンバー間での呼出しごとに、匿名でないプロデューサがロード・バランシングされます。

TopicPublish.publish()メソッドでは、「ロード・バランシングの有効化」設定に関係なく、匿名でないプロデューサが呼出しごとに常に同じ物理的なトピックに固定されます。

- ロード・バランシングを有効化 = False

プロデューサは失敗するまで常に同じ物理宛先に対して生成します。失敗すると、新しい物理宛先が選択されます。

3. 「保存」をクリックします。

注意:

実装によっては、「サーバー・アフィニティの有効化」属性の設定が分散宛先のロード・バランシングのプリファレンスに影響することがあります。詳細は、「サーバー・アフィニティを有効化した場合の分散宛先ロード・バランシングへの影響」を参照してください

匿名プロデューサ(作成時に宛先を指定しないプロデューサ)は、宛先を切り替えるたびにロード・バランシングされます。同じ宛先を使用し続けると、匿名でないプロデューサと同じ法則(前述)が適用されます。

サーバー・アフィニティを有効化した場合の分散宛先ロード・バランシングへの影響

表4-2では、接続ファクトリの「サーバー・アフィニティの有効化」パラメータの設定が、分散宛先メンバーのロード・バランシングのプリファレンスに与える影響について説明します。プリファレンス順位は、操作のタイプ、および恒久サブスクリプションまたは永続メッセージが含まれているかどうかによって異なります。

分散宛先の「サーバー・アフィニティを有効化」パラメータは、ClusterMBeanの「デフォルトのロード・バランス・アルゴリズム」属性によって提供されるサーバー・アフィニティとは異なります。後者は、JMS接続ファクトリでクライアント接続用の初期コンテキスト・アフィニティを作成するためにも使用されます。

詳細は、Oracle WebLogic Serverクラスタの管理のEJBとRMIオブジェクトのロード・バランシングとクライアント接続の初期コンテキスト・アフィニティとサーバー・アフィニティを参照してください。

表4-2 サーバー・アフィニティのロード・バランシングのプリファレンス

操作

「サーバー・アフィニティを有効化」の設定

ロード・バランシングのプリファレンス

- キューのcreateReceiver()

- トピックのcreateSubscriber()

True

1. コンシューマを持たないローカル・メンバー

2. ローカル・メンバー

3. コンシューマを持たないリモート・メンバー

4. リモート・メンバー

キューのcreateReceiver()

False

1. コンシューマを持たないメンバー

2. メンバー

トピックのcreateSubscriber()

(注意: 非永続サブスクライバ)

trueまたはfalse

1. コンシューマを持たないローカル・メンバー

2. ローカル・メンバー

- キューのcreateSender()

- トピックのcreatePublisher()

trueまたはfalse

作成されたJMSプロデューサのロード・バランシング用の、独立した機能は存在しません。JMSプロデューサは、JMS接続のロード・バランシングまたは固定が行われるサーバーで作成されます。

接続ファクトリを使用して作成されたJMS接続のロード・バランシングの詳細は、Oracle WebLogic Serverクラスタの管理のEJBとRMIオブジェクトのロード・バランシングとクライアント接続の初期コンテキスト・アフィニティとサーバー・アフィニティを参照してください。

QueueSender.send()を使用する永続メッセージ

True

1. コンシューマとストアを持つローカル・メンバー

2. コンシューマとストアを持つリモート・メンバー

3. ストアを持つローカル・メンバー

4. ストアを持つリモート・メンバー

5. コンシューマを持つローカル・メンバー

6. コンシューマを持つリモート・メンバー

7. ローカル・メンバー

8. リモート・メンバー

QueueSender.send()を使用する永続メッセージ

False

1. コンシューマとストアを持つメンバー

2. ストアを持つメンバー

3. コンシューマを持つメンバー

4. メンバー

QueueSender.send()を使用する非永続メッセージ

True

1. コンシューマを持つローカル・メンバー

2. コンシューマを持つリモート・メンバー

3. ローカル・メンバー

4. リモート・メンバー

非永続メッセージの場合:

- QueueSender.send()

- TopicPublish.publish()

False

1. コンシューマを持つメンバー

2. メンバー

セッション・プール・キューおよびトピックのcreateConnectionConsumer()

trueまたはfalse

ローカル・メンバーのみ

注意: セッション・プールは現在ほとんど使用されていません。理由は、Java EE仕様の必須の部分ではないこと、JTAユーザー・トランザクションをサポートしていないこと、そして大部分がメッセージドリブンBean (MDB)に取ってかわられたことです。MDBの方が簡単で管理しやすく、高機能です。

分散宛先の移行

サービス移行機能を利用するクラスタ化されたJMS実装では、JMSサーバーとその分散宛先メンバーを、クラスタ内の別のWebLogic Serverインスタンスに手動で移行できます。サービスの移行は、定期的なシステム保守の際や、クラスタ内のサーバーに障害が発生した際に実施できます。

ただし、移行先のWebLogic Serverに物理宛先すべてを持つJMSサーバーがすでにホストされている場合もあります。そのような場合には、同じWebLogic Serverインスタンスが単一の分散宛先について2つの物理宛先をホストするような状況が生じます。WebLogic Serverインスタンスでは、そのような分散宛先に対して複数の物理宛先をホストできるため、これは短期的に見れば許容できる状況です。ただし、こうした状況ではロード・バランシングの効率が低下します。

このような状況では、移行先のWebLogic Serverインスタンス上のJMSサーバーは独立して動作します。これは、2つの送り先インスタンスがマージされたり、両方の送り先で1つのインスタンスが無効化されることを回避するために必要です。このようなことが発生すると、メッセージが長時間使用できなくなる場合があります。ただし、長期的な目的は、移行されたJMSサーバーをクラスタ内のさらに別のWebLogic Serverインスタンスに最終的に再移行することにあります。

JMSの移行可能ターゲットの構成については、「JMS関連サービスの移行」を参照してください。

分散宛先のフェイルオーバー

JMSプロデューサおよびJMSコンシューマのJMS接続をホストしているサーバー・インスタンスに障害が発生した場合、これらの接続を使用しているすべてのプロデューサとコンシューマは閉じられ、クラスタ内の別のサーバー・インスタンスで再作成されません。また、JMS宛先をホストしているサーバー・インスタンスに障害が発生した場合、その宛先のすべてのJMSコンシューマが閉じられ、クラスタ内の別のサーバー・インスタンスでは再作成されません。

キュー・プロデューサが作成された分散キュー・メンバーに障害が発生したが、プロデューサのJMS接続が存在するWebLogic Serverインスタンスがまだ実行されている場合、プロデューサはアクティブな状態を維持し、WebLogic JMSはロード・バランシングのオプションが有効になっているかどうかに関係なく、別の分散キュー・メンバーにフェイルオーバーします。

WebLogic Serverの障害から回復する手順については、Oracle WebLogic Server JMSアプリケーションの開発のサーバー障害からの回復を参照してください。

無制限ClientIDの構成

クライアントIDポリシーは、1つ以上のJMS接続がクラスタ内で同一のクライアントIDを使用できるかどうかを指定します。このポリシーの有効な値は次のとおりです。

- RESTRICTED: これはデフォルトです。このポリシーを使用する接続で、特定のクライアントIDのクラスタ内に常時存在できるのは、1つのみです(所定のクライアントIDを使用した接続がすでに存在する場合、このポリシーを同じクライアントIDで使用して新しい接続を作成しようとしても、例外が発生して失敗します)。

- UNRESTRICTED: このポリシーを使用して作成された接続は、他の制限/無制限接続がすでに同一クライアントIDを使用している場合でも、任意のクライアントIDを指定できます。恒久サブスクリプションが無制限クライアントIDを使用して作成されるとき、そのサブスクリプションはweblogic.jms.extensions.WLSession.unsubscribe(Topic topic, String name)を使用してのみクリーン・アップできます。『Oracle WebLogic Server JMSアプリケーションの開発』のサブスクリプションの管理に関する項を参照してください。

特にサブスクリプション(恒久/非恒久)を共有する場合は、新しいアプリケーションに対してクライアントIDポリシーをUnrestrictedを設定することをお薦めします(使用するアプリケーションのアーキテクチャに排他的クライアントIDが必要な場合を除く)。異なるクライアントIDポリシーを使用して作成されたサブスクリプションは、常に単独のサブスクリプションとして扱われます。Oracle WebLogic Server MBeanリファレンスのClientIdPolicyに関する項を参照してください。

WebLogicコンソールを使用した接続ファクトリ上でクライアントIDポリシーを設定する場合、Oracle WebLogic Server管理コンソール・オンライン・ヘルプの同一クライアントIDを使用した複数接続の構成に関する項を参照してください。接続ファクトリ設定は、Oracle WebLogic Server Java APIリファレンスのWLConnectionインタフェースのsetClientIDPolicyメソッドを使用して、プログラム的にオーバーライドできます。

注意:

JMS接続ランタイム・オブジェクト上のクライアントIDポリシーのプログラムによる変更(オーバーライド)は、該当する特定の接続インスタンスおよび当該接続の存続期間中のみ有効です。接続ランタイム・オブジェクトへのいかなる変更も、基礎となるJMSモジュール記述子で定義される対応するJMS接続ファクトリ構成によって保存/反映されません。

クライアントIDポリシーを使用する方法の詳細は、次を参照してください。

- Oracle WebLogic Server管理コンソール・オンライン・ヘルプの同一クライアントIDを使用した複数接続の構成に関する項

- 『Oracle WebLogic Server JMSアプリケーションの開発』の高度なPub/Subアプリケーションの開発に関する項

共有サブスクリプションの構成

サブスクリプション共有ポリシーは、サブスクライバが同一接続上の他のサブスクライバとサブスクリプションを共有できるかどうかを指定します。このポリシーの有効な値は次のとおりです。

- Exclusive: これはデフォルトです。この接続ファクトリを使用して作成されるすべてのサブスクライバは、サブスクリプションを他のサブスクリプションと共有できません。

- Sharable: この接続ファクトリを使用して作成されたサブスクライバは、サブスクライバが同一の接続ファクトリまたは異なる接続ファクトリのどちらを使用して作成されたかに関係なく、サブスクリプションを他のサブスクライバと共有できるようになります。コンシューマは、同一のクライアントIDおよびクライアントIDポリシーを持つ場合にのみ非永続サブスクリプションを共有できます。また、同一のクライアントID、クライアントIDポリシー、およびサブスクリプション名を持つ場合にのみ永続スクリプトを共有できます。

WebLogic JMSアプリケーションは、javax.jms.Connectionインスタンスをweblogic.jms.extension.WLConnectionにキャストしてsetSubscriptionSharingPolicy(String)を呼び出すことによって、接続ファクトリ構成上で指定されるサブスクリプション共有ポリシーをオーバーライドできます。

サブスクリプション共有ポリシーを使用するアプリケーションのほとんどは、無制限クライアントIDポリシーを使用して、同一クライアントIDを使用する複数の接続が存続できようにします。

同一クライアントIDおよびサブスクリプション名を持つ2つの恒久サブスクリプションは、異なるクライアントIDポリシーを持つ場合、2種類の独自のサブスクリプションとして扱われます。同様に、同一クライアントIDを持つ2つの共有可能な非恒久サブスクリプションは、異なるクライアントIDポリシーを持つ場合、2種類の独自のサブスクリプションとして扱われます。

サブスクリプション共有ポリシーを使用する方法の詳細は、以下を参照してください。

- Oracle WebLogic Server管理コンソール・オンライン・ヘルプの接続ファクトリ・サブスクリプション共有ポリシーの構成に関する項。

- 『Oracle WebLogic Server JMSアプリケーションの開発』の高度なPub/Subアプリケーションの開発に関する項

5 簡略化されたJMSクラスタと高可用性の構成

この章では、クラスタ指定の新しい拡張と、それによるJMS構成プロセスの簡略化について説明します。これらの拡張により、クラスタまたはWebLogic Serverマルチテナント環境で、広範囲な構成プロセスの必要なく、JMSサービスを、動的にスケーラブルで、可用性が高くなるようにできます。

この章の内容は次のとおりです。

- JMSのWebLogicクラスタリング・オプションとは

- 簡略化されたJMSクラスタ構成の理解

- 簡略化されたJMS構成と高可用性の拡張機能

- クラスタ化されたJMSの考慮事項と制限事項

- クラスタ化されたJMSサービスを使用する場合のベスト・プラクティス

JMSのWebLogicクラスタリング・オプションとは

WebLogicクラスタには、個別に構成されたサーバー、動的に生成されたサーバー、またはその両方が含まれます。WebLogic Serverには、次のクラスタ・タイプがあります。

- 構成済: 各メンバー・サーバーが個別に構成され、それぞれがそのクラスタにターゲット指定されています。クラスタ構成の「動的クラスタ・サイズ」属性の値は、0です。 WebLogic Server管理コンソール・オンライン・ヘルプのクラスタ: 構成: サーバーに関する項を参照してください。このタイプのクラスタは、静的クラスタとも言います。

- 動的: すべてのメンバー・サーバーがサーバー・テンプレートを使用して作成されるクラスタです。これらのサーバーは動的サーバーと呼ばれます。クラスタ構成の「クラスタ: 構成: サーバー」タブの「動的クラスタ・サイズ」属性の値は、0より大きくなります。

- 混在: 一部のメンバー・サーバーはサーバー・テンプレートを使用して作成され(動的サーバー)、残りのサーバーは手動で構成されます(構成済サーバー)。混在クラスタには動的サーバーが含まれるため、クラスタ構成の「クラスタ: 構成: サーバー」タブの「動的クラスタ・サイズ」属性の値は、0より大きくなります。

動的サーバーの使用方法の詳細は、次を参照してください。

- Oracle WebLogic Serverクラスタの管理の動的クラスタを参照してください。

- Oracle WebLogic Server管理コンソール・オンライン・ヘルプの動的クラスタの作成および動的なクラスタ化JMSの構成を参照してください

簡略化されたJMSクラスタ構成の理解

クラスタ化されたJMSサービスは、JMSサービス・アーティファクト(たとえばJMSサーバー、SAFエージェントおよびパス・サービス)と任意の関連する永続ストアに対して、同じクラスタをターゲットにすることができます。ストアを使用しないJMSアーティファクトであるメッセージング・ブリッジも、クラスタをターゲットにできます。(必須)ここに概要文を記入します。文には概念の定義と目的を含めます。

クラスタ上に分散されるように構成されたJMSサービス・アーティファクトの場合、分散ポリシーにより異なりますが、新しい各サーバーが起動すると、クラスタは各クラスタ・メンバー上でアーティファクト(および該当する場合は関連付けられたストア)の1つのインスタンスを自動的に起動し、そのメンバーはそのインスタンスの優先サーバーと呼ばれます。分散されないアーティファクトの場合、システムはクラスタ内のサーバーを選択し、そのアーティファクトの単一インスタンスを起動します。「簡略化されたJMS構成と高可用性の拡張機能」を参照してください。

動的または混在クラスタの場合、クラスタ・サイズが増大すると、インスタンス数は自動的に増加します。動的クラスタや混在クラスタ、または混在クラスタの動的サーバーのサイズを動的にスケールするには、クラスタ構成の 「クラスタ: 構成: サーバー」タブにある「サーバーの最大数」属性を調整します。

図5-1は、config.xmlファイルにおけるJMSと動的クラスタ構成との関係を示しています。

図5-1 動的なクラスタ化JMS

クラスタをターゲットに指定されたJMSサービス・アーティファクトを持つカスタム永続ストアの使用

JMSサービス・アーティファクトによって使用されるカスタム永続ストアで、クラスタ拡張の利点を活用するには、適切な属性値を構成して、同じクラスタをターゲットとして指定する必要があります。ただし、クラスタをターゲットとして指定されたSAFエージェントおよびJMSサーバーは各クラスタ・メンバーが利用できるデフォルト・ストアを使用し続けることもできますが、その場合、この章で説明する新しい拡張機能は提供されません。「簡略化されたJMS構成と高可用性の拡張機能」を参照してください。

JMSのモジュール・リソースのターゲット指定

JMSシステム・モジュールは、引き続き2タイプのターゲット指定をサポートし、どちらを使用しても簡略化されたクラスタ化構成を利用できます。

- モジュール内でターゲットがデフォルト指定されるJMSリソース(サブデプロイメントに関連付けられていないJMSリソース)は、その親モジュールのターゲット指定を継承します。親モジュールは任意のタイプのクラスタにターゲット指定できます。

- モジュールsubdeploymentターゲットは、通常の宛先またはインポートされた宛先をホスティングするために、それぞれ、クラスタ化されたJMSサーバーまたはSAFエージェントを参照できます。クラスタをターゲットとして指定されたJMSサーバーまたはSAFエージェントをサブデプロイメントで使用すると、サブデプロイメントでJMSサーバーまたはSAFエージェントを個別に作成して、列挙する必要がなくなります。これは特に、共通分散宛先やインポートされた宛先のデプロイメントで便利です。

「ターゲット指定のベスト・プラクティス」を参照してください。

注意:
モジュールまたはそのサブデプロイメントを直接動的クラスタ・メンバー・サーバーにターゲット指定することはできません。

クラスタのターゲットとして指定されたJMSサーバーと永続ストアの併用

クラスタのターゲットとして指定されたJMSサーバーに関連付けられた永続ストアは、同じクラスタにターゲット指定されたカスタム永続ストアである場合も、各クラスタ・メンバー上で使用可能なデフォルト・ストアである場合もあります。

JMSのモジュール・リソースのターゲット指定

JMSシステム・モジュールは、引き続き2タイプのターゲット指定をサポートし、どちらを使用しても簡略化されたクラスタ化構成を利用できます。

- モジュール内でターゲットがデフォルトで指定されるJMSリソース(サブデプロイメントに関連付けられていないJMSリソース)は、その親モジュールのターゲット指定を継承します。親モジュールは任意のタイプのクラスタをターゲットにできます。

- モジュールのサブデプロイメントのターゲットは、クラスタ化されたJMSサーバーを参照できます。サブデプロイメントでクラスタのターゲットとして指定されたJMSサーバーを使用すると、サブデプロイメント内の個々のJMSサーバーを個別に列挙する必要がなくなるため、共通分散宛先デプロイメントでは特に便利です。

「ターゲット指定のベスト・プラクティス」を参照してください

注意:

モジュールまたはそのサブデプロイメントを直接動的クラスタ・メンバーにターゲット指定することはできません。

簡略化されたJMS構成と高可用性の拡張機能

WebLogic Serverは、クラスタにデプロイされたJMSサービス・アーティファクトで、高可用性をサポートします。サーバーおよびサービスの障害のシナリオは、アーティファクトのインスタンスを他の実行中サーバーに自動的に移行することによって処理されます。この過程で、システムは全体のサーバー負荷および可用性を評価し、それに応じてインスタンスを移動します。

WebLogic Serverのこのリリースの、クラスタをターゲットに指定する拡張により、以前のリリースに存在した制限の多くが不要になりました。

- 以前のリリースでは、JMSサーバー、永続ストア、およびSAFエージェント(部分的)だけがクラスタをターゲットに指定できました。このリリースでは、SAFエージェント、パス・サービス、メッセージング・ブリッジなど、すべてのJMSサービス・アーティファクトと、あらゆるタイプのクラスタ(構成済、混在、動的)にまでサポートが拡張されました。

- このリリースでの拡張により、クラスタをターゲットにしたすべてのJMSサービス・アーティファクトで分散の動作やJMS高可用性(JMS自動サービス移行とも呼ばれます)の動作を容易に構成、制御できます。これらの構成はすべて単一の場所、つまり永続ストアに依存するすべてのアーティファクトの場合は永続ストア、ストアを使用しないものについてはメッセージング・ブリッジに集められました。これにより、以前のリリースで使用された移行可能ターゲットが不要になります。

- 論理JMSアーティファクトはクラスタをターゲットにしているため、システムはクラスタの結合時に、必要な「物理」インスタンスをクラスタ・メンバー上に自動的に作成します。これにより、クラスタ・サイズが増大するときに、JMSサービスが自動的にスケール・アップすることが可能になります。オプションの高可用性構成を使用すると、「物理」インスタンスは、サービス障害またはサーバーの障害や停止が生じた場合に再起動または移行できるため、最小構成でのJMSサービスの可用性が向上します。

スケーラビリティおよび高可用性の動作を制御するプライマリ属性は、分散ポリシーと移行ポリシーです。これらのポリシーに加えて、別の場所に移行する前のインスタンスのインプレース再起動(同一サーバー上)など、高可用性動作を微調整するために使用できる追加の属性がいくつかあります。次の各項では、これらのポリシーと属性について説明します。

- JMSサービスのための分散ポリシーの定義

- JMSサービスのための移行ポリシーの定義

- JMSサービスのための追加の構成オプション

JMSサービスのための分散ポリシーの定義

カスタム永続ストアまたはメッセージング・ブリッジのための分散ポリシー設定は、関連付けられたJMSサービス・アーティファクト(JMSサーバー、SAFエージェントおよびパス・サービス)がクラスタに分散される方法を決定し、メッセージング・ブリッジ上の同じ設定がその分散動作を決定します。

次に、JMSサービス・アーティファクトの分散動作を制御するオプションを示します。

- 分散完了: このモードでは、クラスタは自動的に、サーバーごとに最低1つのインスタンスを確保します。クラスタが起動すると、システムはすべてのメッセージング・サービス・インスタンスを稼働状態にします(可能な場合)。また、該当する場合は、インスタンスの均一分散を試みます。また、すべてのインスタンスは、自動的にまずホームまたは優先サーバー上での起動を試みます。移行ポリシーによって、インスタンスは自動的に移行することも、場合によってフェイルバックを行い、クラスタ全体での高可用性と均一なロード・バランシングを確実にすることもできます。

注意:
分散ポリシーは、このポリシーのデフォルト値です。共通分散宛先(UDD)をホスティングする、クラスタをターゲットとして指定されたSAFエージェントとクラスタをターゲットとして指定されたJMSサーバーでも必須です。
このオプションはデフォルト・ポリシーであり、共通分散宛先(UDD)をホスティングする、クラスタをターゲットとして指定されたSAFエージェントとクラスタをターゲットとして指定されたJMSサーバーでも必須です。

- シングルトン: このモードでは、JMSサーバーまたはパス・サービスはクラスタごとに1つのインスタンスを持っています。

注意:
このオプションはパス・サービスで必須です。また、シングルトン宛先またはスタンドアロン(非分散)宛先をホストする、クラスタをターゲットにしたJMSサーバーでも必須です。
分散ポリシーの詳細は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのJDBCストア: HA構成に関する項を参照してください

JMSサービスのための移行ポリシーの定義

移行ポリシーは、クラスタをターゲットとして指定されたJMSサービス・アーティファクト・インスタンスの移行および再起動動作を制御します。高可用性およびサービス移行については、関連付けられたストア上で、移行ポリシーを次のとおりに設定します。

- オフ: このオプションは、インプレースの移行および再起動を無効にします。

- 常時: このオプションを使用すると、システムはすべての状況でインスタンスを自動的に移行できます。これには、ホスティング・サーバーまたはサブシステム・サービスの、管理上の停止、クラッシュまたは状態不良を含みます。このオプションはサービスの移行も有効化します。これは、現在のホスト・サーバー上の障害が発生したストアを自動的に再起動するか、インプレース再起動構成に基づいて別のサーバーに移行します。

- 失敗時: このオプションを使用すると、システムは、ホスティング・サーバーの障害またはクラッシュ(状態不良)が生じた場合のみ、インスタンスを自動的に移行できます。管理上の停止があった場合、インスタンスは移行せず、そのかわりに、サーバーが再起動されたときに再起動します。このオプションはサービスの移行も有効化します。これは、同じホスト・サーバー上の障害が発生したストアを自動的に再起動するか、インプレース再起動構成に基づいて別のサーバーに移行します。

注意:

- クラスタをターゲットとして指定されている、移行ポリシーが「常時」または「失敗時」であるJMSサービス・アーティファクトのサポートを有効化するには、クラスタ・リーシングを構成する必要があります。詳細は、『Oracle WebLogic Serverクラスタの管理』のリースに関する項を参照してください。

- JMSサービス移行とJTA移行は、その移行ポリシーに基づいて独立して動作します。動的クラスタとJTA移行ポリシーの詳細は、サービスの移行フレームワークの理解を参照してください。

- コンセンサス・リーシングでなく、データベース・リーシングのオプションを使用するのがベスト・プラクティスです。

- 分散インスタンスが優先サーバーから移行される場合、優先サーバーが再起動されるときにフェイル・バックを試みます。

移行ポリシーの詳細は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのJDBCストア: HA構成に関する項を参照してください

JMSサービスのための追加の構成オプション

表5-1 JMSサービス移行のための構成プロパティ

プロパティ

デフォルト値

説明

再起動準備完了

True

正常なWebLogic Server内で、システムがJMSサービス障害にどのように応答するかを定義します。サービスが失敗した場合に、このプロパティが有効にされると、まずシステムはそのストアと、同じサーバー上の関連するサービス・アーティファクトの再起動を試行し、その後で別のサーバーに移行します。

注意:
この属性は、サーバー全体に障害が発生したときには適用されません。

再起動間隔

30

Restart In Placeが有効の場合、このプロパティは同じサーバー上での再起動と再起動の間の遅延を秒単位で指定します。

再起動回数

6

Restart In Placeが有効の場合、この数は別のサーバーへのアーティファクト・インスタンス移行を試行する前に、システムが行う再起動試行回数を決定します。

初期起動遅延(秒)

60

最初のインスタンスが起動された後、後続の高速インスタンスがサーバー上でどのように起動されるかを制御します。これにより、システムが起動時に過負荷になるのを防止できます。

値0は、システムが待機する必要はないことを示しますが、これは過負荷状況に導く場合があります。システムのデフォルト値は60秒です。

フェイルバック遅延(秒)

-1

アーティファクトのインスタンスを優先サーバーにフェイルバックする前に待機する時間を指定します。

0より大きい値は、JMSアーティファクトを優先サーバーにフェイルバックする前に、遅延させる時間を秒数で指定します。

値に0を指定した場合、インスタンスはフェイルバックしません。

値に-1を指定した場合、遅延は発生せず、インスタンスはただちにフェイルバックします。

部分クラスタ安定遅延

240

部分的に起動されたクラスタが、「常時」または「失敗時」の移行ポリシーで構成された、クラスタをターゲットとして指定されたすべてのJMSアーティファクト・インスタンスを開始する前に、遅延させる時間を秒数で指定します。

この遅延によって、サーバーが順次起動される場合でも、サービスがクラスタ全体で分散されます。

> 0の値は、部分的に開始されたクラスタが動的に構成されたサービスを開始する前に、遅延させる時間を秒数で指定します。

値0は、利用できるサーバー上でのすべてのインスタンスを遅延なしで起動することを指定します。

遅延のデフォルト値は240秒です。

これらのプロパティの詳細は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのJDBCストア: HA構成に関する項を参照してください。

クラスタ化されたJMSの考慮事項と制限事項

次に示す制限事項とその他の動作では、動的クラスタとクラスタをターゲットにしたJMSサーバーを使用してアプリケーションを開発する前に考慮する必要のある制限事項とその他の動作に関する情報を提供します。

- QOSレベルがExactly-OnceのSAFエージェント・インポート済宛先が、混在または動的クラスタでホストされる分散宛先にメッセージを転送する場合は、特別な考慮が必要です。「クラスタ化されたJMSサービスを使用する場合のベスト・プラクティス」を参照してください。

- WLSTオフラインでは、JMSサーバーを動的クラスタにターゲット指定するassignコマンドはサポートされません。getおよびsetコマンドを使用してください。

- クラスタをターゲットとして指定されたJMSサーバーでは、重み設定された分散宛先(シングルトン宛先のグループで構成された非推奨の分散宛先タイプ)はサポートされません。

- クラスタをターゲットにしたJMSサーバーでホストされているメンバー宛先が1つでもある場合は、複製された分散トピック(RDT)はサポートされません。

- 「シングルトン」分散ポリシーが設定されたカスタム永続ストアおよび「常時」(または「失敗時」)が設定された移行ポリシーが、クラスタをターゲットにしたJMSサーバーでスタンドアロン宛先を使用できるために必要です。

- クラスタをターゲットとして指定されたJMSアーティファクトから生成されたサービス・インスタンスの移行またはフェイルバックを手動で(管理側から)強制することはサポートされていません。

- 順序単位(UOO)メッセージのホストに使用される、なんらかの分散またはインポート済宛先がある場合は、パス・サービスを構成する必要があります。さらに、ハッシュ・ベースのUOOルーティングは、クラスタをターゲットにしたJMSではサポートされないため、そのような宛先は、デフォルトのハッシュされたUOOルーティング・ポリシーでなく、パス・サービスUOOルーティング・ポリシーを使用して構成する必要があります。

クラスタをターゲットとして指定されたJMSサービス上でホスティングされている、分散またはインポートされた宛先にメッセージを送信しようとすると、失敗して例外が発生します。

シングルトン分散ポリシーと常時移行ポリシーを持つストアを参照するには、クラスタをターゲットにしたパス・サービスを構成する必要があります。

クラスタのターゲットとして指定されたJMSサーバーの相互運用性とアップグレードに関する考慮事項

次の項では、クラスタをターゲットにしたJMSサーバーを使用する場合の相互運用性とアップグレードの考慮事項について説明します。

- 以前のリリースのJMSクライアント、ブリッジ、MDB、SAFクライアント、およびSAFエージェントは、クラスタのターゲットとして指定されたJMSサーバーと通信できます。

- QOSレベルがExactly-OnceのSAFエージェント・インポート済宛先が、混在または動的クラスタでホストされる分散宛先にメッセージを転送する場合は、特別な考慮が必要です。「クラスタ化されたJMSサービスを使用する場合のベスト・プラクティス」を参照してください

- データ(メッセージ)を移動するための変換パスはなく、クラスタのターゲットとして指定されていないJMSサーバーからクラスタのターゲットとして指定されたJMSサーバーへの構成やその逆の構成もできません。

移行可能ターゲット・ベースのJMSサービスのサービス移行は、構成済クラスタでサポートされています。

たとえば、JMSサーバーと永続ストアのメッセージング構成では、1つの手動で構成されたWebLogic Serverまたは1つの移行可能なターゲットをターゲットに指定できます。同様に、SAFエージェントは、1つの手動で構成されたWebLogic Server、移行可能なターゲット、またはクラスタをターゲットにできます。

「JMSサービスの自動移行」を参照してください

クラスタ化されたJMSサービスを使用する場合のベスト・プラクティス

次の項では、ベスト・プラクティスとデザイン・パターンに関する情報を提供します。

- 動的クラスタのサイズを縮小したり、混在クラスタ内の動的クラスタ・メンバー数を削減する前に、クラスタをターゲットにしたJMSサーバーでホストされている宛先を削除し、その後でWebLogic Serverインスタンスを停止します。例:

1. 本番用の個々の宛先を休止します。

2. アプリケーションで宛先を削除します。

3. サーバー・インスタンスを停止します。

- クラスタをターゲットにしたJMSサーバーとSAFエージェント用のデフォルト・ストアのかわりに、クラスタをターゲットにしたストアを使用します。

- 高可用性を有効化した場合(つまり、ストア上の移行ポリシーが「失敗時」または「常時」のいずれかに設定されている場合)、クラスタ・リースが構成されていることを確認してください。コンセンサス・リースよりデータベース・リースがベスト・プラクティスになります。詳細は、『Oracle WebLogic Serverクラスタの管理』のリースに関する項を参照してください。

- モジュールでの宛先の構成時に、デフォルトのターゲット指定を使用せずに特定のクラスタ化されたJMSサーバーまたはSAFエージェントをターゲットにするサブデプロイメントを使用します。これにより、宛先では、目的としている正確なJMSサーバー・インスタンス上にメンバーが作成されます。

- QOSレベルがExactly-OnceのSAFエージェントやSAFクライアントを使用する場合、ベスト・プラクティスとして、SAFエージェントに関連付けられたストアが「常時」に設定された移行ポリシーで構成されていることを確認してください。

また、クラスタ・サイズが変更された場合(特に縮小された場合)、バッキング表(JDBCストアの場合)またはファイル(FILEストアの場合)をいずれかの利用できるクラスタ・メンバーに移行して、SAFサービスの連続的な可用性を確保できるように、それらが削除または破棄されていないことを確認してください。

実行時MBeanインスタンスの名前付け構文

クラスタ内に分散されJMSアーティファクト(永続ストア、JMSサーバー、SAFAgent、MessagingBridgeおよびPathServiceなど)のそれぞれに関連付けられている実行時MBeanは、分散ポリシーのセットに基づいて名前が付けられます。これはMBeanチェックによって強制されます。

分散ポリシーのタイプには、次のものがあります。

- 分散完了 — インスタンスは、そのインスタンスのホームまたは優先されるWebLogic Serverの初回起動時に名前を指定することで、自動的に作成され一意の名前が付けられます。形式は<configured-name>@<server-name>になります。

- シングルトン — インスタンスには、構成された名前に「01」を加えた名前が付けられます。形式は<configured-name>–01になります。このインスタンス名にサーバー名は追加されません。

次の項では、永続ストアのインスタンス名前付け構文について概説します。

- .DATファイルのインスタンスの名前付け構文

- .RGNファイルのインスタンスの名前付け構文

- JDBCストアの名前付け構文

.DATファイルのインスタンスの名前付け構文

クラスタをターゲットにしたファイル・ストア(.DATファイル)の場合、インスタンスのデータ・ファイルには、対応するストアのインスタンス名に基づいて一意の名前が付けられます。たとえば、分散完了モードでは、インスタンスのファイルには<Store name>@<Server instance name>NNNNNN.DATという名前が付きます。<NNNNNN>は000000～999999の範囲の数字になります。

注意:
1つのファイルのインスタンスが1つ以上の.DATファイルを作成する場合があります。

.RGNファイルのインスタンスの名前付け構文

クラスタをターゲットにした、レプリケートされたストアのインスタンスのリージョンは、対応するストアのインスタンス名に基づいて、一意の名前が付けられます。たとえば、分散完了モードでは、レプリケートされたストアのインスタンスには、構文<configured Replicated Store name>@<Server instance name>NNNNNN.RGNが含まれます。<NNNNNN>は000000–999999の範囲の数字になります。

JDBCストアの表名の構文

JDBCストアのデータベースの表名は、デフォルトではWLStoreです。表名は、JDBCストアのPrefixName設定を使用して頻繁に変更し、異なるJDBCストアが別の表を使用できるようにする必要があります。JDBCストアの2つの異なるインスタンスは、同じバックアップ表を共有できません。分散ポリシーの設定によって、データベースの表名が生成されます。表5-2を参照してください

表5-2 クラスタをターゲットにした場合のJDBCストアの表名の構文

デフォルト名

prefixName

分散ポリシー

インスタンス名

ストアの表名

WLStore

myPrefix

分散

myServer

myPrefix_myServer_WLStore

該当なし

myPrefix('.'で終わる)

分散

myServer

myPrefix._myServer_WLStore

該当なし

該当なし

分散

myServer

myServer_WLStore

該当なし

myPrefix

シングルトン

01

myPrefix_01_WLStore

該当なし

myPrefix

シングルトン

01

myPrefix.S_01_WLStore

該当なし

該当なし

シングルトン

01

S_01_WLStore

表5-3 非クラスタ(シングル・サーバー)をターゲットにした場合

デフォルト名

接頭辞名

分散ポリシー

インスタンス名

ストアの表名

該当なし

該当なし

該当なし

該当なし

myPrefixWLStore

該当なし

該当なし

該当なし

該当なし

WLStore

6 JMSアプリケーション・モジュールのデプロイメントの構成

この章では、WebLogic Server 12.1.3でJMSアプリケーション・モジュールをデプロイするために構成する方法について説明します。また、Java EEエンタープライズ・アプリケーションでパッケージ化されたJMSアプリケーション・モジュールや、グローバルに使用できるスタンドアロン・アプリケーション・モジュールについても説明します。

この章の内容は次のとおりです。

- JMSアプリケーション・モジュールの構成方法

- JMSスキーマ

- JMSアプリケーション・モジュールのエンタープライズ・アプリケーションへのパッケージ化

- パッケージ化JMSアプリケーション・モジュールの主な作成手順

- パッケージ化JMSアプリケーション・モジュールを作成する

- EJBアプリケーション内のパッケージ化JMSアプリケーション・モジュールのサンプル

- エンタープライズ・アプリケーションをJMSアプリケーション・モジュールと共にパッケージ化する

- パッケージ化JMSアプリケーション・モジュールをデプロイする

- スタンドアロンJMSアプリケーション・モジュールをデプロイする

- JMSリソースの一意の実行時JNDI名の生成

JMSアプリケーション・モジュールの構成方法

注意:
アプリケーションがデプロイされた後で、アプリケーションのスコープ内で構成されたJMSリソースを変更することはできません。また、アプリケーション・モジュールで作成された宛先を直接削除するオプションはありません。アプリケーションをアンデプロイしても、宛先は削除されません。これらの理由から、かわりにJMSシステム・モジュールを使用して接続ファクトリと宛先を構成することをお薦めします。詳細は、 「JMSシステム・モジュールの構成」を参照してください

JMSシステム・モジュールに構成できるすべてのJMSリソースは、標準Java EEモジュールと同様にデプロイ可能なアプリケーション・モジュールとして構成および管理できます。デプロイされたJMSアプリケーション・モジュールの所有者は、モジュールをデプロイした管理者ではなく、モジュールを作成およびパッケージ化した開発者となります。したがって、デプロイしたリソースに対しては、管理者の制御が及ぶ範囲がより制限されます。

たとえば、管理者はデプロイメント時にデプロイメント・プラン(JSR-88)を使用して、モジュール内に指定されたリソースの特定のプロパティのみを修正(オーバーライド)することはできますが、リソースを動的に追加したり削除することはできません。他のJava EEモジュールのように、アプリケーション・モジュールの構成の変更はモジュールのデプロイメント・プランに格納され、元のモジュール自体は変更されません。

アプリケーション開発者は、こうしたツールを使用してシステム・リソースを作成およびデプロイ(ターゲット指定)できます。:

- 「JMSシステム・モジュールの構成」の説明に従ってJMSシステム・モジュールを作成し、生成されるXMLファイルを別のディレクトリにコピーして、ファイル接尾辞として-jms.xmlを付加した名前に変更します。

- エンタープライズ・レベルのIDEまたはXMLファイルの編集に対応した開発ツールでアプリケーション・モジュールを作成し、そのJMSモジュールをアプリケーションの一部としてパッケージ化して、デプロイのためにWebLogic管理者に渡します。

- ソース・コード・アノテーションに基づいて、Java EE接続ファクトリとアプリケーション・モジュールを暗黙的に作成する宛先定義を使用してください。「Java EEリソース定義を使用したJMSリソースの定義」を参照してください。

JMSスキーマ

WebLogic Server 9.x以上では、JMSリソース用にモジュール形式のデプロイメント・モデルをサポートするために、WebLogic JMSリソースの定義に使用するweblogic-jms.xsdというスキーマが用意されています。JMSモジュール(記述子)を作成する際は、モジュールをこのスキーマに準拠させる必要があります。IDEや他のツールでは、このスキーマに基づいてJMSモジュールを検証できます。

weblogic-jms.xsdスキーマは、http://xmlns.oracle.com/weblogic/weblogic-jms/1.4/weblogic-jms.xsdからオンラインで入手できます(新しいウィンドウが開きます)。

スキーマ内のJMSリソース定義については、Oracle WebLogic Server MBeanリファレンスのSystem Module MBeansフォルダ内の対応するシステム・モジュールBeanの説明を参照してください。JMSモジュールのルートBeanはJMSBeanで、JMSモジュール全体を表します。

Java EEリソース定義を使用したJMSリソースの定義

Java EE 7プラットフォーム仕様で定義されているとおり、WebLogic Serverを使用すると、@JMSConnectionFactoryDefinitionおよび@JMSDestinationDefinitionアノテーションを使用するか、<jms-destination>および<jms-connection-factory>要素を使用して、JMSリソースを定義できます。これらのJMSリソース定義を使用すると、アプリケーションを最小管理構成でJava EE環境にデプロイできます。この項では、次の項目について説明します。

- アノテーションを使用するリソース定義

- デプロイメント記述子におけるリソース定義

- JMSリソース定義の考慮事項とベスト・プラクティス

注意:
アプリケーションがデプロイされた後で、アプリケーションのスコープ内で構成されたJMSリソースを変更することはできません。また、アプリケーション・モジュールで作成された宛先を直接削除するオプションはありません。アプリケーションをアンデプロイしても、宛先は削除されません。これらの理由から、かわりにJMSシステム・モジュールを使用して接続ファクトリと宛先を構成することをお薦めします。詳細は、「JMSシステム・モジュールの構成」を参照してください。

アノテーションを使用するリソース定義

Webモジュール、EJBモジュールまたはアプリケーション・クライアント・モジュールの内部で、アノテーション@JMSConnectionFactoryDefinitionおよび@JMSDestinationDefinitionsを定義できます。これらのクラス内部では、アノテーションを使用してリソースを定義することもできます。

- application.xmlデプロイメント記述子の<library-directory>要素で定義されたライブラリで定義されたクラス

- EJB jarファイルまたは.warファイルのClass-pathエントリによって参照されている.jarファイル内のクラス

これが定義されると、コンポーネントは@Resourceアノテーションのlookup要素を使用するか、resource-refデプロイメント・ディスクリプタ要素のlook-up要素を使用して、リソースを参照できます。

例6-1 例: JMS接続ファクトリの定義

@JMSConnectionFactoryDefinition(   name="java:app/MyJMSConnectionFactory",   interfaceName="javax.jms.QueueConnectionFactory").

例6-2 例: JMS宛先の定義

@JMSDestinationDefinition(   name="java:app/MyJMSQueue",   interfaceName="javax.jms.Queue",   destinationName="myQueue1")

リソース定義で使用できる要素とプロパティの詳細は、「JMSリソース定義要素リファレンス」を参照してください

デプロイメント記述子におけるリソース定義

アノテーションを使用するかわりに、デプロイメント記述子内で<jms-destination>および<jms-connection-factory>要素を使用して、リソースを定義できます。

JMSコネクション・ファクトリの定義

ejb-jar.xmlまたはweb.xmlデプロイメント記述子内で、jms-connection-factory要素を使用して、JMS宛先リソースを定義できます。接続ファクトリが作成され、指定されるネームスペースに基づいて適切な名前コンテキストにバインドされます。

次の例は、場所java:app/MyJMSConnectionFactoryでJNDIにバインドされた接続ファクトリを定義します。

<jms-connection-factory>   <description>Sample JMS ConnectionFactory definition</description>   <name>java:app/MyJMSConnectionFactory</name>   <interface-name>javax.jms.QueueConnectionFactory</interface-name>   <user>scott</user>   <password>tiger</password>   <client-id>MyClientId</client-id>   <property>     <name>Property1</name>     <value>10</value>  </property>   <property>     <name>Property2</name>     <value>20</value>   </property>   <transactional>false</transactional>   <max-pool-size>30</max-pool-size>   <min-pool-size>20</min-pool-size> </jms-connection-factory>

jms-connection-factory要素やその属性の詳細は、http://xmlns.jcp.org/xml/ns/javaee/javaee_7.xsdにあるスキーマを参照してください

JMS宛先の定義

ejb-jar.xmlまたはweb.xmlデプロイメント記述子内で、jms-destination要素を使用して、JMS宛先リソースを定義できます。宛先が作成され、指定されるネームスペースに基づいて適切な名前コンテキストにバインドされます。

次の例は、場所java:app/MyJMSDestination:でJNDIにバインドされたキュー宛先myQueue1を定義します

<jms-destination>   <description>JMS Destination definition</description>   <name>java:app/MyJMSDestination</name>   <interface-name>javax.jms.Queue</interface-name>   <destination-name>myQueue1</destination-name>   <property>     <name>Property1</name>     <value>10</value>   </property>   <property>     <name>Property2</name>     <value>20</value>   </property> </jms-destination>

jms-destination要素やその属性の詳細は、http://xmlns.jcp.org/xml/ns/javaee/javaee_7.xsdにあるスキーマを参照してください

JMSリソース定義の考慮事項とベスト・プラクティス

新しいアノテーションを使用して定義されたリソースの考慮事項を以下に示します。

- 次に示す許可されたJNDIネームスペースのいずれかにJMSリソースを定義します。

- java:comp

- java:module

- java:app

- java:global

- JNDI名がjava:で始まるが、前述のネームスペース接頭辞のいずれでも始まっていない場合は、デプロイメント時に例外が発生します。

- JNDI名がjava:で始まらない場合、宛先または接続ファクトリは java:comp/env namespaceで定義されます。たとえば、jms/myDestinationという形式のJNDI名は、java:comp/env/jms/myDestinationと同じと見なされます。

- WebLogic Serverでは、アプリケーションは宛先をapplication.xmlデプロイメント記述子のjava:appおよびjava:globalネームスペースで、または、Webモジュール、EJBモジュールまたはアプリケーション・クライアント・モジュール内のクラス以外のアプリケーション・パッケージにあるクラス上のアノテーションを使用して定義できます。

- @JMSDestinationDefinition を使用して定義された宛先は、内部的に共通分散宛先(キューまたはトピック)として作成されます。デフォルトでは、タイプjavax.jms.Topicの@JMSDestinationDefinition (interfaceNameを指定)を使用して作成される共通分散トピックのForwarding Policyオプションの値は「Partitioned」になります。アプリケーション・デプロイメント時に、値を「レプリケート」に指定できます。ただし、リソース・グループまたはリソース・グループ・テンプレートでForwarding Policyを「replicated」として使用することは、適格性チェックで制限されます。詳細は、Oracle WebLogic Server JMSアプリケーションの開発の分散トピックのベスト・プラクティスを参照してください。

- @JMSDestinationDefinitionを使用してキューを定義するアプリケーションがアンデプロイされている場合、永続ストアは受信または消費されていないメッセージを保持します。これらのメッセージはアプリケーションの再デプロイ時に、宛先の消費者が利用できます。

@JMSConnectionFactoryDefinitionの詳細は、http://docs.oracle.com/javaee/7/api/javax/jms/JMSConnectionFactoryDefinition.htmlを参照してください

@JMSDestinationDefinitionの詳細は、http://docs.oracle.com/javaee/7/api/javax/jms/JMSDestinationDefinition.htmlを参照してください

JMSアプリケーション・モジュールのエンタープライズ・アプリケーションへのパッケージ化

JMSアプリケーション・モジュールは、パッケージ化されたモジュールのように、エンタープライズ・アプリケーション・アーカイブ(EAR)の一部としてパッケージ化できます。パッケージ化されたモジュールは、EARまたは展開されたEARディレクトリにバンドルされ、weblogic-application.xml記述子内で参照されます。

パッケージ化されたJMSモジュールは、エンタープライズ・アプリケーションと一緒にデプロイされます。このモジュールに定義されたリソースは、同梱されたアプリケーションでのみ利用可能(すなわちアプリケーション・スコープのリソース)にすることもできます。このようなモジュールは、JMSリソースを使用するEJB(特にMDB)またはWebアプリケーションとともにパッケージ化すると、非常に役立ちます。パッケージ化モジュールを使用することにより、アプリケーションで必要なリソースを常に使用でき、アプリケーションを新しい環境に移動する処理が簡素化されます。

パッケージ化JMSアプリケーション・モジュールを作成する

パッケージ化JMSモジュールは、エンタープライズ・レベルのIDEまたはXML記述子ファイルの編集をサポートする他の開発ツールを使用して作成します。スタンドアロンのモジュールをデプロイおよび管理するには、weblogic.Deployerユーティリティ、WebLogic Server管理コンソールなど、JSR 88ベースのツールを使用します。

注意:

WebLogic Server管理コンソールを使用してパッケージ化されたJMSモジュールを作成したら、作成されたXMLファイルを別のディレクトリにコピーし、ファイル接尾辞として-jms.xmlを付加してファイル名を変更します。

パッケージ化JMSアプリケーション・モジュールの要件

EARファイル内では、JMSモジュールが以下の条件を満たしている必要があります。

- http://xmlns.oracle.com/weblogic/weblogic-jms/1.4/weblogic-jms.xsdスキーマに準拠している

- ファイル接尾辞として-jms.xmlを使用します(例: MyJMSDescriptor-jms.xml)

- WebLogicドメイン内で一意の名前が付けられており、Java EEアプリケーションのルートからの相対パスが指定されている

パッケージ化JMSアプリケーション・モジュールの主な作成手順

パッケージ化JMSモジュールを構成するには:

1. 必要に応じて、JMSモジュールをターゲット指定するJMSサーバーを作成します。Oracle WebLogic Server管理コンソール・オンライン・ヘルプのJMSサーバーの構成を参照してください。

2. JMSシステム・モジュールを作成し、必要なリソース(キュー、トピックなど)を構成します。Oracle WebLogic Server管理コンソール・オンライン・ヘルプのJMSシステム・モジュールの構成およびJMSリソースの追加を参照してください。

3. システム・モジュールは、ドメイン・ディレクトリのconfig\jmsサブディレクトリに、接尾辞-jms.xmlが付加された形で保存されます。

4. システム・モジュールを新しい場所にコピーしてから以下を行います。

a. モジュールの名前を、ドメイン・ネームスペース内で一意の名前に変更します。

b. JNDI-Name属性を削除して、そのアプリケーションでのみ使用できるアプリケーション・スコープのモジュールにします。

5. 該当するすべてのJava EEアプリケーション・コンポーネントのディスクリプタ・ファイルに、モジュール内のJMSリソースへの参照を追加します。Oracle WebLogic Server JMSアプリケーションの開発のデプロイメント・ディスクリプタ・ファイルにおけるパッケージ化JMSアプリケーション・モジュールの参照を参照してください。

6. EAR内のすべてのアプリケーション・モジュールをパッケージ化します。「エンタープライズ・アプリケーションをJMSアプリケーション・モジュールと共にパッケージ化する」を参照してください

7. EARをデプロイします。「パッケージ化JMSアプリケーション・モジュールをデプロイする」を参照してください

EJBアプリケーション内のパッケージ化JMSアプリケーション・モジュールのサンプル

次のコード・スニペットは、パッケージ化JMSモジュールappscopedejbs-jms.xmlの例です。このモジュールは、図6-1のようにディスクリプタ・ファイルで参照されています。

<weblogic-jms xmlns="http://xmlns.oracle.com/weblogic/weblogic-jms">
<connection-factory name="ACF">
</connection-factory>
<queue name="AppscopeQueue">
</queue>
</weblogic-jms>

図6-1に、パッケージ化JMSモジュールのJMS接続ファクトリ・リソースとキュー・リソースが、EJB EARファイルで参照されている様子を示します。

図6-1 JMSアプリケーション・モジュールとEJBアプリケーションの記述子との関係

weblogic-application.xmlでパッケージ化JMSアプリケーション・モジュールを参照する

エンタープライズ・アプリケーションにJMSモジュールを含める際は、アプリケーションと一緒にパッケージ化されたweblogic-application.xml記述子ファイルで、JMSタイプのモジュール要素として各JMSモジュールを列挙し、アプリケーションのルートからの相対パスを指定する必要があります。例:

<module>
<name>AppScopedEJBs</name>
<type>JMS</type>
<path>jms/appscopedejbs-jms.xml</path>
</module>

ejb-jar.xmlでパッケージ化JMSアプリケーション・モジュールを参照する

アプリケーション内のEJBで、アプリケーションと一緒にパッケージ化されたJMSモジュールを介して接続ファクトリを使用している場合は、JMSモジュールをres-ref要素として列挙し、EJBと一緒にパッケージ化されたejb-jar.xml記述子ファイルにres-ref-nameパラメータとres-typeパラメータを含める必要があります。これにより、アプリケーションのローカル・コンテキストで、EJBがJMS接続ファクトリをルックアップできるようになります。例:

<resource-ref>
<res-ref-name>jms/QueueFactory</res-ref-name>
<res-type>javax.jms.QueueConnectionFactory</res-type>
</resource-ref>

res-ref-name要素により、java:comp/envで使用するリソース名が、EJBから参照されるモジュールにマップされます。res-type要素には、モジュール・タイプ(この例ではjavax.jms.QueueConnectionFactory)を指定します。

アプリケーション内のEJBで、アプリケーションと一緒にパッケージ化されたJMSモジュールを介してキューまたはトピックを使用している場合は、JMSモジュールをresource-env-ref要素として列挙し、EJBと一緒にパッケージ化されたejb-jar.xml記述子ファイルにresource-env-ref-nameパラメータとresource-env-ref-typeパラメータを含める必要があります。これにより、アプリケーションのローカル・コンテキストで、EJBがJMSキューまたはトピックをルックアップできるようになります。例:

<resource-env-ref>
<resource-env-ref-name>jms/Queue</resource-env-ref-name>
<resource-env-ref-type>javax.jms.Queue</resource-env-ref-type>
</resource-env-ref>

resource-env-ref-name要素により、EJBによって参照されるモジュールに宛先名がマップされます。res-type要素には、キューの名前(この例ではjavax.jms.Queue)を指定します。

weblogic-ejb-jar.xmlでパッケージ化JMSアプリケーション・モジュールを参照する

参照されるJMSモジュールをres-ref-name要素として列挙し、EJBと一緒にパッケージ化されているweblogic-ejb-jar.xml記述子ファイルのresource-linkパラメータに含める必要があります。

<resource-description>
<res-ref-name>jms/QueueFactory</res-ref-name>
<resource-link>AppScopedEJBs#ACF</resource-link>
</resource-description>

res-ref-name要素により、EJBによって参照されるモジュールに接続ファクトリ名がマップされます。resource-link要素では、JMSモジュール名の後ろにシャープ記号(#)の区切り文字を付加し、その後ろにモジュール内のリソースの名前を指定します。この例では、接続ファクトリACFを含むJMSモジュールAppScopedEJBsが、AppScopedEJBs#ACFという名前で指定されています。

上の例の続きでは、res-ref-name要素によって、EJBが参照するモジュールにキュー名もマップされます。そのresource-link要素では、次のようにキューAppScopedQueueの名前がAppScopedEJBs#AppScopedQueueになります。

<resource-env-description>
<resource-env-ref-name>jms/Queue</resource-env-ref-name>
<resource-link>AppScopedEJBs#AppScopedQueue</resource-link>
</resource-env-description>

エンタープライズ・アプリケーションをJMSアプリケーション・モジュールと共にパッケージ化する

JDBCモジュールを含むアプリケーションは、他のエンタープライズ・アプリケーションと同じようにパッケージ化します。Oracle WebLogic Serverアプリケーションの開発のwlpackageを使用したアプリケーションのパッケージ化を参照してください。

パッケージ化JMSアプリケーション・モジュールをデプロイする

パッケージ化JMSモジュールのデプロイメントは、アプリケーションの他のコンポーネントと同じモデルに従って行われます。個別のモジュールは、単一のサーバー、クラスタ、またはクラスタの個別のメンバーにデプロイできます。

他のアプリケーション・コンポーネントの推奨ベスト・プラクティスは、Oracle WebLogic Server JMSアプリケーションの開発のデプロイメント・ディスクリプタ・ファイルにおけるパッケージ化JMSアプリケーション・モジュールの参照で説明されているように、java:comp/env JNDI環境を使用してJMSエンティティへの参照を取得することです。(ただし、このプラクティスは必須ではありません。)

パッケージ化JMSモジュールは、定義によってエンタープライズ・アプリケーションに含まれているため、エンタープライズ・アプリケーションをデプロイすると一緒にデプロイされます。パッケージ化JMSモジュールを含むアプリケーションのデプロイメントの詳細は、Oracle WebLogic Serverアプリケーションの開発のwldeployを使用したアプリケーションのデプロイメントを参照してください。

スタンドアロンJMSアプリケーション・モジュールのデプロイ

この節では、以下の内容について説明します。

- スタンドアロンJMSモジュール

- スタンドアロンJMSアプリケーション・モジュールを作成する

- 単純なスタンドアロンJMSアプリケーション・モジュールのサンプル

- スタンドアロンJMSアプリケーション・モジュールをデプロイする

- スタンドアロンJMSアプリケーション・モジュールをチューニングする

スタンドアロンJMSモジュール

JMSアプリケーション・モジュールは、スタンドアロン・モジュールとしてデプロイできます。この場合、アプリケーション・モジュールはデプロイメント・プロセス中にターゲット指定されたサーバーまたはクラスタで使用できます。この方法でデプロイされるJMSモジュールは、weblogic.DeployerユーティリティまたはWebLogic Server管理コンソールで再構成できますが、JMXまたはWLSTでは使用できません。

しかし、WebLogic Serverプラグインに付属の基本的なJSR-88デプロイメント・ツールでは、APIのWebLogic Server拡張を使用せずにスタンドアロンJMSモジュールを使用でき、Java EEアプリケーションやモジュールをWebLogic Serverに構成、デプロイ、および再デプロイできます。WebLogic Serverのデプロイメントについては、Oracle WebLogic ServerへのアプリケーションのデプロイのWebLogic Serverデプロイメントの理解を参照してください。

この方法でデプロイしたJMSモジュールを「スタンドアロン・モジュール」といいます。スタンドアロンJMSモジュール内のリソースは、モジュールがどのようにターゲット指定されているかに応じて、クラスタ内でグローバルに使用できるか、サーバー・インスタンスでローカルに使用できるかが決まります。スタンドアロンJMSモジュールを使用すると、JMSリソースの共有と移植が容易になります。作成したJMSモジュールは他の開発者に配布できます。スタンドアロンJMSモジュールも、ドメイン間でJMS情報を移動するために使用できます。たとえば、JMSを広範囲にわたって手動で再構成することなく、開発ドメインと本番ドメインの間でJMS情報を移動できます。

スタンドアロンJMSアプリケーション・モジュールを作成する

スタンドアロンJMSモジュールは、エンタープライズ・レベルのIDEまたはXML記述子ファイルの編集をサポートする他の開発ツールを使用して作成できます。スタンドアロンのモジュールをデプロイおよび管理するには、weblogic.Deployerユーティリティ、WebLogic Server管理コンソールなどのWebLogic Serverツールを使用します。

注意:

WebLogic Server管理コンソールを使用してJMSアプリケーション・モジュールを作成したら、アプリケーションで使用するテンプレートとしてモジュールをコピーし、ファイル接尾辞として-jms.xmlを付加します。また、ネームスペース内での名前の競合を避けるため、モジュールをアプリケーションと一緒にデプロイする前に、モジュールのName要素とJNDI-Name要素を変更する必要があります。

スタンドアロンJMSアプリケーション・モジュールの要件

スタンドアロンJMSモジュールは、以下の条件を満たしている必要があります。

- http://xmlns.oracle.com/weblogic/weblogic-jms/1.4/weblogic-jms.xsdスキーマに準拠している

- ファイル接尾辞として-jms.xmlを使用します(例: MyJMSDescriptor-jms.xml)

- WebLogicドメイン内で一意の名前を使用します(JMSシステム・モジュールと競合することはできません)

スタンドアロンJMSアプリケーション・モジュールの主な作成手順

スタンドアロンJMSモジュールを構成するには:

1. 必要に応じて、JMSモジュールをターゲット指定するJMSサーバーを作成します。Oracle WebLogic Server管理コンソール・オンライン・ヘルプのJMSサーバーの構成を参照してください。

2. JMSシステム・モジュールを作成し、必要なリソース(キュー、トピックなど)を構成します。Oracle WebLogic Server管理コンソール・オンライン・ヘルプのJMSシステム・モジュールの構成およびJMSリソースの追加を参照してください。

3. システム・モジュールは、ドメイン・ディレクトリのconfig\jmsサブディレクトリに、接尾辞-jms.xmlが付加された形で保存されます。

4. システム・モジュールを新しい場所にコピーしてから以下を行います。

a. モジュールの名前を、ドメイン・ネームスペース内で一意の名前に変更します。

b. モジュールをグローバルに使用できるようにするには、モジュール内のリソースのJNDI-Name属性を一意の名前に変更します。

c. 宛先のしきい値や接続ファクトリのフロー・コントロールのパラメータなど、その他の調整可能な値を必要に応じて修正します。

5. モジュールをデプロイします。「スタンドアロンJMSアプリケーション・モジュールをデプロイする」を参照してください

単純なスタンドアロンJMSアプリケーション・モジュールのサンプル

次のコード・スニペットは、単純なスタンドアロンJMSモジュールの例です。

<weblogic-jms xmlns="http://xmlns.oracle.com/weblogic/weblogic-jms">
<connection-factory name="exampleStandAloneCF">
<jndi-name>exampleStandAloneCF</jndi-name>
</connection-factory>
<queue name="ExampleStandAloneQueue">
<jndi-name>exampleStandAloneQueue</jndi-name>
</queue>
</weblogic-jms>

スタンドアロンJMSアプリケーション・モジュールのデプロイ

weblogic.Deployerユーティリティを使用してスタンドアロンJMSモジュール(前述の例で使用)をデプロイするコマンド・ラインは、次のようになります。

java weblogic.Deployer -adminurl http://localhost:7001 -user weblogic
-password weblogic \
-name ExampleStandAloneJMS \
-targets examplesServer \
-submoduletargets ExampleStandaloneQueue@examplesJMSServer,ExampleStandaloneCF@examplesServer \
-deploy ExampleStandAloneJMSModule-jms.xml

スタンドアロンJMSモジュールのデプロイについては、Oracle WebLogic ServerへのアプリケーションのデプロイのJDBC、JMS、およびWLDFアプリケーション・モジュールのデプロイを参照してください。

スタンドアロンJMSモジュールをデプロイすると、ドメインのconfig.xmlファイルにapp-deploymentエントリが追加されます。例:

<app-deployment>
<name>standalone-examples-jms</name>
<target>MedRecServer</target>
<module-type>jms</module-type>
<source-path>C:\modules\standalone-examples-jms.xml</source-path>
<sub-deployment>
...
</sub-deployment>
<sub-deployment>
...
</sub-deployment>
</app-deployment>

モジュールのsource-pathは、絶対パスでも、domainディレクトリからの相対パスでも構いません。この点は、domain\configディレクトリからの相対パスで指定するシステム・リソース・モジュールのdescriptor-file-nameパスとは異なります。

スタンドアロンJMSアプリケーション・モジュールをチューニングする

スタンドアロン・モジュール内でデプロイされたJMSリソースは、リソースがバインド可能(JNDI名など)または調整可能(宛先のしきい値など)と見なされるかぎり、weblogic.DeployerユーティリティまたはWebLogic Server管理コンソールを使用して再構成できます。ただし、WebLogic JMX APIやWebLogic Scripting Tool (WLST)を介してスタンドアロン・リソースを使用することはできません。

しかし、WebLogic Serverプラグインに付属の基本的なJSR-88デプロイメント・ツールでは、APIのWebLogic Server拡張を使用せずにスタンドアロンJMSモジュールを使用でき、Java EEアプリケーションやモジュールをWebLogic Serverに構成、デプロイ、および再デプロイできます。WebLogic Serverのデプロイメントについては、Oracle WebLogic ServerへのアプリケーションのデプロイのWebLogic Serverデプロイメントの理解を参照してください。

また、どのWebLogic Serverユーティリティを使用しても、スタンドアロン・リソースを動的に追加または削除することはできません。再デプロイする必要があります。

JMSリソースの一意の実行時JNDI名の生成

接続ファクトリ、宛先などのJMSリソースの構成ではJNDI名を使用します。これらのリソースの実行時実装は、特定の名前を使用してJNDIにバインドされます。しかし、状況によっては、これらのリソースに静的なJNDI名を指定することが不可能(または不都合)な場合があります。

たとえば、JMSリソースがアプリケーション・ライブラリ内のJMSモジュールに定義されている場合です。この場合、アプリケーション・ライブラリは複数のアプリケーションから参照できます。各アプリケーションはデプロイ時にライブラリ(およびそれに含まれているJMSモジュール)のコピーを受け取ります。この状況でJMSリソースに静的なJNDI名を使用すると、ライブラリを参照するすべてのアプリケーションが、同じ静的JNDI名で同じJNDIリソースのセットをバインドすることになります。

その結果、最初にデプロイしたアプリケーションではJMSリソースをJNDIに問題なくバインドできますが、それ以降のアプリケーション・デプロイメントではJNDI名がすでにバインドされていることを示す例外が発生します。

この問題を回避するため、WebLogic Serverには以下のJMSリソースのJNDI名を動的に生成する機能が用意されています。

- 接続ファクトリ

- 宛先(キューおよびトピック)

- 重み設定された分散宛先(非推奨)

- 重み設定された分散宛先メンバー

- 共通分散宛先

この機能では、前述のJMSリソースのJNDI名に${APPNAME}という特別な文字シーケンスを含めることで、一意の名前を生成します。JMSリソース(JMSモジュール記述子またはweblogic-ejb-jar.xml記述子)のJNDI名要素に${APPNAME}を含めると、実行時に実際に使用されるJNDI名では、${APPNAME}文字列がそのJMSリソースをホストするアプリケーションの有効なアプリケーションID (名前と、可能であればバージョン)で置き換えられます。

注意:

${APPNAME}機能を使用して独自の変数を定義したり、実行時にそれらの値をJNDI名に代入したりすることはできません。文字列${APPNAME}はJMS実装によって特別に処理されるもので、JMSリソース以外で${<some name>}形式の文字列を使用しても特に効力はありません。

ローカル・アプリケーションの一意の実行時JNDI名

ローカル・アプリケーション内のJMSモジュールの場合は、実行時の${APPNAME}がそのアプリケーションの名前またはIDで置き換えられます。例:

<jndi-name>${APPNAME}/jms/MyConnectionFactory</jndi-name>

MyAppアプリケーション内にデプロイされているとすると、実行時JNDI名は次のようになります。

MyApp/jms/MyConnectionFactory

アプリケーション・ライブラリの一意の実行時JNDI名

アプリケーション・ライブラリ内のJMSモジュールの場合は、実行時の${APPNAME}が、そのライブラリ(ライブラリの名前ではない)を参照するアプリケーションの名前/IDで置き換えられます。例:

<jndi-name>${APPNAME}/jms/MyConnectionFactory</jndi-name>

MyAppLibというアプリケーション・ライブラリ内にデプロイされており、MyAppというアプリケーションから参照されているとすると、実行時JNDI名は次のようになります。

MyApp/jms/MyConnectionFactory

スタンドアロンJMSモジュールの一意の実行時JNDI名

スタンドアロン・モジュールとしてデプロイされているJMSモジュールの場合は、実行時の${APPNAME}がそのスタンドアロン・モジュールの名前/IDで置き換えられます。例:

<jndi-name>${APPNAME}/jms/MyConnectionFactory</jndi-name>

MyJMSModuleというスタンドアロンJMSモジュール内にデプロイされているとすると、実行時JNDI名は次のようになります。

MyJMSModule/jms/MyConnectionFactory

${APPNAME}文字列の使用場所

${APPNAME}文字列は、JMSモジュールのJNDI名を参照する場所であればどこでも使用できます。以下に、使用できる場所の例を示します。

- JMSモジュール記述子のconnection-factory要素のjndi-nameまたはlocal-jndi-name要素

- JMSモジュール記述子のqueueまたはtopic要素のjndi-nameまたはlocal-jndi-name要素

- JMSモジュール記述子のdistributed-queueまたはdistributed-topic要素のjndi-name要素

- JMSモジュール記述子のuniform-distributed-queueまたはuniform-distributed-topic要素のjndi-name要素

- weblogic-ejb-jar.xml記述子のmessage-destination-descriptor要素のdestination-jndi-name要素

注意:

${APPNAME}文字列は、WebLogic EJBでもサポートされています。

- weblogic-ejb-jar.xml記述子のweblogic-enterprise-bean要素のjndi-name

サンプル・ユースケース

シングル・サーバー環境では、モジュール形式のデプロイメント・モデルをサポートするため、WebLogic Integrationワークリストでアプリケーション・スコープのJMSリソース(キュー、接続ファクトリなど)を使用します。Weblogic Integrationでアプリケーション・スコープのJMSを使用すると、ワークリストで必要なEJBやJMSリソースなどをアプリケーション・ライブラリに定義できます。ユーザーはlibrary-refを追加するだけで、アプリケーションにワークリストを含めることができます。ただし、この場合は、ワークリスト・ユーザーがそれらの宛先をアプリケーション・ライブラリからクラスタにスケーリングできなくなります。

クラスタリングされた環境においては、キューのJNDI名の${APPNAME}文字列を実行時に置換して、キューのグローバルJNDI名を一意にすることができるようになりました。JMS ${APPNAME}パラメータは、この方法により、アプリケーション・ライブラリに結合されているホスト・アプリケーションのアプリケーション名で実行時に置き換えられます。

JMSサービスのための追加の構成オプション

表6-1 JMSサービス移行のための構成プロパティ

プロパティ

デフォルト値

説明

再起動準備完了

True

正常なWebLogic Server内で、システムがJMSサービス障害にどのように応答するかを定義します。サービスが失敗した場合に、このプロパティが有効にされると、まずシステムはそのストアと、同じサーバー上の関連するサービス・アーティファクトの再起動を試行し、その後で別のサーバーに移行します。

注意:
この属性は、サーバー全体に障害が発生したときには適用されません。

再起動間隔

30

Restart In Placeが有効の場合、このプロパティは同じサーバー上での再起動と再起動の間の遅延を秒単位で指定します。

再起動回数

6

Restart In Placeが有効の場合、この数は別のサーバーへのアーティファクト・インスタンス移行を試行する前に、システムが行う再起動試行回数を決定します。

初期起動遅延(秒)

60

最初のインスタンスが起動された後、後続の高速インスタンスがサーバー上でどのように起動されるかを制御します。これにより、システムが起動時に過負荷になるのを防止できます。

値0は、システムが待機する必要はないことを示しますが、これは過負荷状況に導く場合があります。システムのデフォルト値は60秒です。

フェイルバック遅延(秒)

-1

アーティファクトのインスタンスを優先サーバーにフェイルバックする前に待機する時間を指定します。

0より大きい値は、JMSアーティファクトを優先サーバーにフェイルバックする前に、遅延させる時間を秒数で指定します。

値に0を指定した場合、インスタンスはフェイルバックしません。

値に-1を指定した場合、遅延は発生せず、インスタンスはただちにフェイルバックします。

部分クラスタ安定遅延

240

部分的に起動されたクラスタが、「常時」または「失敗時」の移行ポリシーで構成された、クラスタをターゲットとして指定されたすべてのJMSアーティファクト・インスタンスを開始する前に、遅延させる時間を秒数で指定します。

この遅延によって、サーバーが順次起動される場合でも、サービスがクラスタ全体で分散されます。

> 0の値は、部分的に開始されたクラスタが動的に構成されたサービスを開始する前に、遅延させる時間を秒数で指定します。

値0は、利用できるサーバー上でのすべてのインスタンスを遅延なしで起動することを指定します。

遅延のデフォルト値は240秒です。

これらのプロパティの詳細は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのJDBCストア: HA構成に関する項を参照してください。

7 WLSTを使用したJMSサーバーとJMSシステム・モジュール・リソースの管理

この章では、WebLogic Scripting Tool (WLST)の使用方法について説明します。これは、WebLogic Server 12.1.3のJMSサーバーおよびJMSシステム・モジュール・リソースの作成と管理に使用できるコマンドライン・スクリプト・インタフェースです。WebLogic Scripting Toolの理解のWebLogic Scripting Toolの使用およびWLSTサンプル・スクリプトを参照してください。

この章の内容は次のとおりです。

- JMSシステム・モジュールとサブデプロイメントの理解

- JMSサーバーとJMSシステム・モジュール・リソースの作成方法

- JMSサーバーとJMSシステム・モジュール・リソースの変更およびモニター方法

- WLSTを使用してJMSリソースを構成するときのベスト・プラクティス

JMSシステム・モジュールとサブデプロイメントの理解

JMSシステム・モジュールは、config.xmlのjms-system-resource MBeanで記述します。jms-system-resource MBeanの基本的なコンポーネントは以下のとおりです。

- name: モジュールの名前。

- target: モジュールをターゲット指定するサーバー、クラスタ、または移行可能ターゲット。

- sub-deployment: JMSシステム・モジュール・リソース(キュー、トピック、接続ファクトリなど)をグループ化し、サーバー・リソース(JMSサーバー・インスタンス、WebLogicサーバー・インスタンス、クラスタなど)にターゲット指定するメカニズム。

- descriptor-file-name: システム・モジュール・ファイルのパスとファイル名。

システム・モジュールのJMSリソースは、weblogic-jmsmd.xmlスキーマに準拠するモジュール記述子ファイル内に配置されます。図7-1のmyModule-jms.xmlというモジュールには、接続ファクトリとキューのJMSシステム・リソース定義が含まれています。sub-deployment-name要素は、myModule-jms.xmlファイル内のJMSリソースをグループ化して、config.xml内のtargetsにターゲット指定するために使用します。WLSTを使用する場合は、sub-deployment-name要素の値を指定する必要があります。サブデプロイメントの詳細は、「JMSシステム・モジュールとリソースのサブデプロイメントのターゲット指定」を参照してください。図7-1では、sub-deployment-nameDeployToJMSServer1を使用して、myModule-jmsモジュールの接続ファクトリとキューCQueueのグループ化とターゲット指定をしています。

JMSリソースの使用方法の詳細は、「JMS構成リソースとは」を参照してください。

図7-1 サブデプロイメント・アーキテクチャ

JMSサーバーとJMSシステム・モジュール・リソースの作成方法

WLSTを使用してJMSシステム・リソースを作成するには、次のタスクを実行する必要があります。

- 編集セッションを開始します。

- JMSリソース(キュー、トピック、接続ファクトリなど)を含むJMSシステム・モジュールを作成します。

- JMSサーバー・リソースを作成します。

編集セッションの確立後、次の手順でJMSサーバーとシステム・モジュール・リソースを構成します。

1. リソースを構成するサーバーのWebLogic Server MBeanオブジェクトを取得します。次に例を示します。

servermb=getMBean("Servers/examplesServer")
if servermb is None:
print '@@@ No server MBean found'

2. システム・リソースを作成します。次に例を示します。

jmsMySystemResource = create(myJmsSystemResource,"JMSSystemResource")

3. このシステム・リソースをWebLogic Serverインスタンスにターゲット指定します。次に例を示します。

jmsMySystemResource.addTarget(servermb)

4. システム・リソース・オブジェクトを取得します。次に例を示します。

theJMSResource = jmsMySystemResource.getJMSResource()

5. モジュールのリソース(キュー、トピック、接続ファクトリなど)を作成します。次に例を示します。

connfact1 = theJMSResource.createConnectionFactory(factoryName)
jmsqueue1 = theJMSResource.createQueue(queueName)

6. リソース属性を構成します。次に例を示します。

connfact1.setJNDIName(factoryName)
jmsqueue1.setJNDIName(queueName)

7. システム・リソースのサブデプロイメント名を作成します。「JMSシステム・モジュールとサブデプロイメントについて」を参照してください次に例を示します。

connfact1.setSubDeploymentName('DeployToJMSServer1')
jmsqueue1.setSubDeploymentName('DeployToJMSServer1')

8. JMSサーバーを作成します。次に例を示します。

jmsserver1mb = create(jmsServerName,'JMSServer')

9. JMSサーバーのターゲットとしてWebLogic Serverのインスタンスまたはクラスタを指定します。次に例を示します。

jmsserver1mb.addTarget(servermb)

10. sub-deployment-name要素に指定した値を使用して、サブデプロイメント・オブジェクトを作成します。これにより、モジュール内のシステム・リソースが、config.xmlの sub-deployment要素にグループ化されます。次に例を示します。

subDep1mb = jmsMySystemResource.createSubDeployment('DeployToJMSServer1')

11. サブデプロイメントをサーバー・リソース(JMSサーバー・インスタンス、WebLogic Serverインスタンス、クラスタなど)にターゲット指定します。次に例を示します。

subDep1mb.addTarget(jmsserver1mb)

例7-1 JMSシステム・リソースを作成するWLSTスクリプト

"""
This script starts an edit session, creates a JMS Server,
targets the jms server to the server WLST is connected to and creates
a JMS System module with a jms queue and connection factory. The
jms queues and topics are targeted using sub-deployments.
"""

import sys
from java.lang import System

print "@@@ Starting the script ..."

myJmsSystemResource = "CapiQueue-jms"
factoryName = "CConFac"
jmsServerName = "myJMSServer"
queueName = "CQueue"

url = sys.argv[1]
usr = sys.argv[2]
password = sys.argv[3]

connect(usr,password, url)
edit()
startEdit()

//Step 1
servermb=getMBean("Servers/examplesServer")
if servermb is None:
print '@@@ No server MBean found'

else:
//Step 2
jmsMySystemResource = create(myJmsSystemResource,"JMSSystemResource")

//Step 3
jmsMySystemResource.addTarget(servermb)

//Step 4
theJMSResource = jmsMySystemResource.getJMSResource()

//Step 5
connfact1 = theJMSResource.createConnectionFactory(factoryName)
jmsqueue1 = theJMSResource.createQueue(queueName)

//Step 6
connfact1.setJNDIName(factoryName)
jmsqueue1.setJNDIName(queueName)

//Step 7
jmsqueue1.setSubDeploymentName('DeployToJMSServer1')
connfact1.setSubDeploymentName('DeployToJMSServer1')

//Step 8
jmsserver1mb = create(jmsServerName,'JMSServer')

//Step 9
jmsserver1mb.addTarget(servermb)

//Step 10
subDep1mb = jmsMySystemResource.createSubDeployment('DeployToJMSServer1')

//Step 11
subDep1mb.addTarget(jmsserver1mb)
.
.
.

JMSサーバーとJMSシステム・モジュール・リソースの変更およびモニター方法

MBeanから利用できる適切なメソッドを使用すると、JMSオブジェクトおよび属性を変更したりモニターしたりできます。「例7-2」を参照してください。

- set、target、untarget、およびdeleteメソッドを使用してJMSオブジェクトおよび属性を変更できます。

- getメソッドを使用してJMS実行時オブジェクトをモニターできます。

詳細は、WebLogic Scripting Toolの理解のMBeanのナビゲート(WLSTオンライン)を参照してください。

例7-2 JMSオブジェクトを変更するWLSTスクリプト

.
.
print '@@@ delete system resource'
jmsMySystemResource = delete("CapiQueue-jms","JMSSystemResource")
print '@@@ delete server'
jmsserver1mb = delete(jmsServerName,'JMSServer')
.
.
.

WLSTを使用したJMSリソース構成時のベスト・プラクティス

WLSTを使用したJMSサーバーおよびJMSシステム・モジュール・リソースの構成時のベスト・プラクティスを次に示します。

- MBeanオブジェクトを操作する前に、Null MBeanオブジェクト(サーバー、JMSサーバー、モジュールなど)をトラップします。

- サブデプロイメント名は理解しやすい名前にします。たとえば、サブデプロイメント名をDeployToJMSServer1にすると、この名前のすべてのサブデプロイメントがJMSServer1にデプロイされることが分かります。

8 Oracle AQ JMSとの相互運用

この章では、Oracle WebLogic Server 12.1.3アプリケーションで、WebLogic Serverリソース(Webアプリケーション、EJB、MDB)またはスタンドアロン・クライアントを使用し、JMS APIを介してOracle Streamsアドバンスト・キューイング(AQ)と相互運用する方法について説明します。

この章の内容は次のとおりです。

- AQ JMS統合について

- AQ JMSとの相互運用のためのWebLogic Serverの構成

- プログラミングの考慮事項

- 高度なトピック

- 関連ドキュメント

詳細は、Oracle Streamsアドバンスト・キューイング・ユーザーズ・ガイドのOracle Databaseアドバンスト・キューイングの概要を参照してください。

注意:

AQ-JMSの統合は、混在クラスタと動的クラスタではサポートされません。この操作を試行しても、例外はスローされません。

概要

AQ JMSでは、WebLogic Serverクラスタ全体にアクセス可能なデータベースに格納されたJMSメッセージと、データベース接続を使用して、データベース機能やデータ操作およびバックアップのツールを利用できるようにします。必要なクラスは、インストールしたWebLogic Serverにすべて含まれているので、Oracle AQ JMSと相互運用するためにWebLogic Serverのクラスパスにファイルを追加する必要はありません。

WebLogic AQ JMSでは、WebLogic JMS外部サーバー・フレームワークが使用されます。これによって、WebLogic Serverアプリケーションやスタンドアロン・クライアントでの標準WebLogic JNDIコンテキストを使用したAQ JMS接続ファクトリおよび宛先のルックアップや、アプリケーションやクライアントでの標準Java EE API群を使用したAQ JMSのロードおよび呼出しが可能になります。必要なデータベースへの参照、JDBCドライバ、およびデータ・ソースは、このフレームワークの一部として構成されています。

WebLogic ServerのJVM内で実行されるアプリケーションのために、次のような仕組みが提供されています。

- 構成済のWebLogicデータ・ソースで、特定のJDBCドライバを参照し、JDBC接続をプールして、AQ JMSをホストするOracleデータベースへの接続を提供します。

- 構成済のWebLogic外部サーバーで、データ・ソースを参照します。

- WebLogic JMS外部サーバー構成の一部として、AQ JMSの接続ファクトリおよび宛先用にローカルJNDI名が定義されます。これらのJNDI名は、既存のAQ接続ファクトリや宛先にマップするように構成されます。

- 言い換えると、MDBなどのWebLogic Serverアプリケーションは、このローカルJNDI名を参照することになります。

外部宛先としてのAQ宛先の使用

AQ外部宛先は、アプリケーションを実行するサーバーや、メッセージを送信または受信するMDBに対してローカルである必要があります。1つのWebLogic Serverインスタンス上で実行中のアプリケーションは、AQ JMS外部サーバーおよび別のWebLogic Serverインスタンス上で登録されるデータ・ソースを参照したり使用したりできません。WebLogic AQ JMSは、リモート接続をサポートしないデータ・ソースまたはDB接続を使用します。あるいは、一方のドメイン上のAQ宛先ともう一方のドメインで実行中のアプリケーションまたはMDB間のメッセージング・ブリッジを使用します。「WebLogicメッセージング・ブリッジ」を参照してください

ドライバ・サポート

WebLogic AQ JMSでは、Oracleデータベースとの通信にOracleシン・ドライバを必要とします。Oracle OCI JDBCドライバや、非Oracle JDBCドライバはサポートされません。Oracle WebLogic Serverの新機能 12.2.1.2.0のサポートされている構成を参照してください。

トランザクション・サポート

グローバルXA (JTA)トランザクションと、ローカルJMSでトランザクション処理されるセッション・トランザクションがサポートされます。グローバル・トランザクションではXAベースの接続ファクトリを使用する必要があり、一方のローカル・トランザクションでは、XAベースでないJMS接続ファクトリが使用されます。

- 非XA JDBCドライバを選択する場合は、ローカル・トランザクションでのみWebLogic AQ JMSを使用できます。

- XA JDBCドライバを選択する場合は、ローカルとグローバルの両方のトランザクションでWebLogic AQ JMSを使用できます。

- このリリースでは、ロギング・ラスト・リソース(LLR)、1相コミット(JTS)、エミュレート2相コミットといったグローバル・トランザクション・オプションを伴う非XA JDBCドライバのデータ・ソースはサポートされません。Supports Global Transactionsが選択されている場合は、警告メッセージがログに記録されます。

- グローバル・トランザクションは、XA JDBCドライバの1フェーズ・コミット最適化でのみサポートされます。AQ JMSとJDBCの処理の両方に同じXA対応データ・ソースを使用した場合、XAトランザクションの動作は、単一のデータ・ソース(トランザクション・マネージャで単一のリソースとして扱われるもの)の中に2つの接続がある状態と同等になります。そのため、同じJTAトランザクションでAQ JMSとJDBCの処理が呼び出され、そのトランザクションに他のリソースが関わらない場合、トランザクションでは2フェーズ・コミットのかわりに1フェーズ・コミット最適化が使用されるか、読取り専用最適化が使用されます。

Oracle WebLogic Server JMSアプリケーションの開発のトランザクションの理解を参照してください。

Oracle RAC

WebLogic AQ JMSでは、Oracle Real Application Clusters (RAC)とWebLogicマルチ・データ・ソースの併用がサポートされ、RAC環境でのフェイルオーバーが提供されます。Oracle WebLogic Server JDBCデータ・ソースの管理のOracle RACでのWebLogic Serverの使用を参照してください。

注意:

AQ JMSを使用するロード・バランシングに複数のデータ・ソースを構成することはお薦めしません。AQ JMSおよびAQを使用するシナリオでは、ロードがOracle RACインスタンス全体に広がるときに過剰な同期が発生する状況が多発します。このような状況では、重要なパフォーマンスの低下が起こる可能性があります。

MBeanおよびコンソールのサポート

JMS外部サーバーを使用したAQ JMSとの相互運用を目的とするものを除き、AQ JMX固有のMBeanや、WebLogic Server管理コンソールでのAQ JMSの構成のサポートはありません。AQのキュー表の作成や削除、宛先の作成や削除、および統計問合せといったAQの管理およびモニターを行うには、SQLスクリプトまたはその他のツールを使用してください。

OC4Jからの移行

Oracle OC4JからOracle WebLogic ServerにAQ JMSアプリケーションを移行する方法については、Oracle Fusion Middleware Java EEアップグレード・ガイドのOEMS JMSデータベース永続性のアップグレードを参照してください。

AQ JMSとの相互運用のためのWebLogic Serverの構成

以下の節では、OracleデータベースにAQ JMSキューおよびトピックを構成し、WebLogic ServerにJMS外部サーバーを構成して、アプリケーションからAQ JMS接続ファクトリや宛先をWebLogic JNDIコンテキストでルックアップできるようにする方法の一例を紹介します。

- データベース内でのOracle AQの構成

- AQ JMS用のWebLogic Serverの構成

- Oracle 12cデータベースとの相互運用のための追加構成

AQ JMSキューおよびトピックの準備ができている場合には、WebLogicコンソールまたはWLSTコマンド・ライン・インタフェースを使用して、以降の構成タスクを実行できます。

データベース内でのOracle AQの構成

WebLogic Serverリソースの構成を開始する前に、Oracleデータベース内にAQ JMSキューおよびトピックが確実にあるようにする必要があります。以下の節では、構成方法の1つを説明します。

- ユーザーの作成および許可の付与

- AQキュー表の作成

- JMSキューまたはトピックの作成

- JMSキューまたはトピックの開始

- JMS外部サーバーの接続ファクトリの構成

- AQ JMS外部サーバーの宛先の構成

AQの使用と構成の詳細は、Oracle Streamsアドバンスト・キューイング・ユーザーズ・ガイドのOracle Databaseアドバンスト・キューイングの概要を参照してください。

ユーザーの作成および許可の付与

データベース内にユーザーを作成し、そのユーザーにAQ JMSの許可を与えます。管理者権限を持つデータベース・ユーザーで、以下のタスクを実行します。

- Oracle SQL*Plus環境を使用して、管理者ログインでログインします。
connect / as sysdba;

- JMSユーザー・スキーマを作成します。以下の例の場合、ユーザー名はjmsuser、パスワードはjmsuserpwd。
Grant connect, resource TO jmsuser IDENTIFIED BY jmsuserpwd;

- jmsuserにAQユーザーのロールを付与します。
Grant aq_user_role TO jmsuser;

- AQパッケージに対する実行権限を付与します。
Grant execute ON sys.dbms_aqadm TO jmsuser;

Grant execute ON sys.dbms_aq TO jmsuser;

Grant execute ON sys.dbms_aqin TO jmsuser;

Grant execute ON sys.dbms_aqjms TO jmsuser;

AQキュー表の作成

AQ JMSの各JMSキューやJMSトピックのデータは、AQキュー表に格納されます。各キュー表が、JMSメッセージのリポジトリの機能を担います。JMSキューまたはJMSトピック(「AQキュー表の作成」を参照)は、基底のAQキュー表への論理的な参照です。

AQキュー表は、個々のJMSユーザー・スキーマ内に作成され、Oracle SQL*PLUSを使用して定義できます。例:

connect jmsuser / jmsuserpwd;

AQキュー表を構成するには、最低でも3つのパラメータが必要です。キュー表の名前、ペイロード・タイプ、そしてAQキュー表で複数のコンシューマを受け入れるかどうかのフラグです。例:

dbms_aqadm.create_queue_table(
queue_table=>"myQueueTable",
queue_payload_type=>'sys.aq$_jms_text_message',
multiple_consumers=>false
);

説明:

- queue_table:キュー表の名前。データベースが10.0の場合、大文字と小文字の混在がサポートされます。ただし、この名前は 二重引用符で囲む必要があります。キュー表の名前は24文字を超えないようにします。

- queue_payload_type: メッセージのタイプ。すべてのJMSメッセージのインタフェース・タイプをサポートするには、sys.aq$_jms_messageを使用します。

- multiple_consumers:キューの場合はfalse、トピックの場合はtrueを設定。

キュー表の作成の詳細は、Oracle Database PL/SQLパッケージおよびタイプ・リファレンスのCREATE_QUEUE_TABLEプロシージャを参照してください。

JMSキューまたはトピックの作成

AQ JMSキューは、キューとトピックの両方を対象としたJMS管理リソースです。AQキュー表の作成後に、Oracle SQL*PLUSを使用して個々のJMSユーザー・スキーマ内に、AQ JMSキューを作成できます。例:

connect jmsuser/jmsuserpwd;

キューまたはトピックを作成するためのPL/SQLプロシージャは、次のような書式になります。

dbms_aqadm.create_queue(
queue_name=>'userQueue',
queue_table=>'myQueueTable'
);

説明:

- queue_nameはJMSキューのユーザー定義名です。

- queue_tableは、既存のAQキュー表を指している必要があります。

キュー表の作成の詳細は、Oracle Database PL/SQLパッケージ・プロシージャおよびタイプ・リファレンスのCREATE_QUEUEプロシージャを参照してください。

JMSキューまたはトピックの開始

初めて使用する際には、事前にAQ JMSキューを開始しておく必要があります。JMSユーザー・スキーマを使用して、以下のPL/SQLプロシージャを実行します。queue_nameはAQ JMSキューの名前です。

connect jmsuser / jmsuserpwd
dbms_aqadm.start_queue(queue_name=>'userQueue'

キューの開始の詳細は、Oracle Database PL/SQLパッケージ・プロシージャおよびタイプ・リファレンスのSTART_QUEUEプロシージャを参照してください。

AQ JMS用のWebLogic Serverの構成

以下の節では、AQ JMSと相互運用するようにWebLogic Serverを構成する方法を説明します。

- AQ JMS用のWebLogicデータ・ソースの構成

- JMSシステム・モジュールの構成

- JMS外部サーバーの構成

- JMS外部サーバーの接続ファクトリの構成

- AQ JMS外部サーバーの宛先の構成

AQ JMS用のWebLogicデータ・ソースの構成

AQ JMSを使用するWebLogic Serverアプリケーション(MDB、EJB、Webアプリケーションなど)には、AQ JMSサービスを提供するOracleデータベース用のデータ・ソースを構成します。このデータ・ソースは、JMSのユーザーおよびパスワードを使用して、データベース内のスキーマに接続するため、ほとんどの状況ではAQ JMS専用として使用されます。データベース接続で使用されるスキーマに作成した場合は、複数のキューおよびトピックがサポートされます。汎用データ・ソースまたはActive GridLink (AGL)データ・ソースを使用できます。

AQ JMS用の汎用データ・ソースの構成

データ・ソースを構成する場合は、以下の作業を実行します。

- 適切なOracle Thinドライバを選択します。

- AQ JMSで必要なトランザクションのタイプに基づいて、ドライバのタイプを選択します。

- ローカル・トランザクションでAQ JMSと併用するためには、非XAベースJDBCドライバを選択します。

- グローバル・トランザクションまたはローカル・トランザクションでAQ JMSと併用するためには、XAベースJDBCドライバを選択します。

- 非XAドライバのデータ・ソースを構成する場合、「グローバル・トランザクションのサポート」オプションは選択しません。このリリースでは、非XA JDBCドライバのデータ・ソースと、LLR、JTS、エミュレート2相コミットといったグローバル・トランザクション・オプションとの併用はサポートされていません。グローバル・トランザクション・オプションが選択されていると、サーバー・インスタンスでログに警告メッセージが記録されます。グローバル・トランザクションは、XAベースのJDBCドライバでサポートされています。

- データ・ソースの接続プールに、データベースのユーザー名とパスワードを構成します。IDベースの接続プールはサポートされていません。

詳細は、次を参照してください。

- Oracle WebLogic Server JDBCデータ・ソースの管理のJDBCデータ・ソースの構成。

- Oracle WebLogic Server管理コンソール・オンライン・ヘルプのJDBCデータ・ソースの作成。

AQ JMS用のAGLデータ・ソースの構成

データ・ソースを構成する場合は、以下の作業を実行します。

- 接続用のOracle Thin XAドライバを選択します。

- データ・ソースの接続プールに、データベースのユーザー名とパスワードを構成します。

詳細は、次を参照してください。

- Oracle WebLogic Server JDBCデータ・ソースの管理のActive GridLinkデータ・ソースの使用

- Oracle WebLogic Server管理コンソール・オンライン・ヘルプのJDBC GridLinkデータ・ソースの作成

AQ JMS用の汎用データ・ソースの構成

データ・ソースを構成する場合は、以下の作業を実行します。

- 適切なOracle Thinドライバを選択します。

- AQ JMSで必要なトランザクションのタイプに基づいて、ドライバのタイプを選択します。

- ローカル・トランザクションでAQ JMSと併用するためには、非XAベースJDBCドライバを選択します。

- グローバル・トランザクションまたはローカル・トランザクションでAQ JMSと併用するためには、XAベースJDBCドライバを選択します。

- 非XAドライバのデータ・ソースを構成する場合、「グローバル・トランザクションのサポート」オプションは選択しません。このリリースでは、非XA JDBCドライバのデータ・ソースと、LLR、JTS、エミュレート2相コミットといったグローバル・トランザクション・オプションとの併用はサポートされていません。グローバル・トランザクション・オプションが選択されていると、サーバー・インスタンスでログに警告メッセージが記録されます。グローバル・トランザクションは、XAベースのJDBCドライバでサポートされています。

- データ・ソースの接続プールに、データベースのユーザー名とパスワードを構成します。IDベースの接続プールはサポートされていません。

詳細は、次を参照してください。

- Oracle WebLogic Server JDBCデータ・ソースの管理のJDBCデータ・ソースの構成。

- Oracle WebLogic Server管理コンソール・オンライン・ヘルプのJDBCデータ・ソースの作成。

AQ JMS用のAGLデータ・ソースの構成

データ・ソースを構成する場合は、以下の作業を実行します。

- 接続用のOracle Thin XAドライバを選択します。

- データ・ソースの接続プールに、データベースのユーザー名とパスワードを構成します。

詳細は、次を参照してください。

- Oracle WebLogic Server JDBCデータ・ソースの管理のActive GridLinkデータ・ソースの使用

- Oracle WebLogic Server管理コンソール・オンライン・ヘルプのJDBC GridLinkデータ・ソースの作成

JMSシステム・モジュールの構成

AQリソース用のJMS外部サーバーをホストするために、専用のJMSシステム・モジュールを構成します。そのモジュールを、WebLogic Serverインスタンス、または外部JNDI名をホストする必要のあるクラスタでターゲット指定します。詳細は、次を参照してください。

- JMSモジュールの概要

- Oracle WebLogic Server管理コンソール・オンライン・ヘルプのシステム・モジュールでの外部サーバーの作成。

JMS外部サーバーの構成

JMS外部サーバーの構成で、次の内容を指定します。

- oracle.jms.AQjmsInitialContextFactoryをJNDI初期コンテキスト・ファクトリとして指定します。

- アプリケーション環境に必要なJDBCデータ・ソースを構成します。

詳細は、次を参照してください。

- 外部サーバー・リソースからサード・パーティJMSプロバイダへのアクセスの構成

- Oracle WebLogic Server管理コンソール・オンライン・ヘルプの外部サーバーの構成

データ・ソースの参照

datasourceというJNDIプロパティを指定します。これは、ローカルにバインドされたWLSデータ・ソースのJNDIの場所です。

例:

<foreign-server>
<initial-context-factory>oracle.jms.AQjmsInitialContextFactory</initial-context-factory>
<jndi-property>
<key>datasource</key>
<value>jdbc/aqjmsds</value>
</jndi-property>
</foreign-server>

datasource JNDIプロパティの値は、AQ JMS Oracleデータベースにアクセスするように構成されているデータ・ソースの名前です。セキュリティ・プリンシパルまたは資格証明など、その他の構成情報は必要ありません。ただし、データベースURLを指定する場合は、java.naming.security.principalとjava.naming.security.credentialsが必要です。

詳細は、「AQ JMS用のWebLogicデータ・ソースの構成」を参照してください。

JMS外部サーバーの接続ファクトリの構成

JMS外部サーバーの作成後は、WebLogic ServerのJNDIツリーにAQ JMS接続ファクトリのJNDIマッピングを作成できます。宛先とは異なり、AQ JMSの場合、Oracleデータベースで接続ファクトリを再定義する必要はありません。かわりに、接続ファクトリのリモートJNDI名の特定時に事前定義済みのJNDI名が指定されます。AQ JMS接続ファクトリのリモートJNDI名は、表8-1のいずれかになります。

表8-1 AQ JMS接続ファクトリのリモートJNDI名

<AQ JMSの接頭辞値>

JMSインタフェース

QueueConnectionFactory

javax.jms.QueueConnectionFactory

TopicConnectionFactory

javax.jms.TopicConnectionFactory

ConnectionFactory

javax.jms.ConnectionFactory

XAQueueConnectionFactory

javax.jms.XAQueueConnectionFactory

XATopicConnectionFactory

javax.jms.XATopicConnectionFactory

XAConnectionFactory

javax.jms.XAConnectionFactory

たとえば、AQ JMS外部サーバー用に構成された以下のような2つの接続ファクトリがあるとします。

表8-2 AQ JMS外部サーバーの接続ファクトリ例

ローカルJNDI名

リモートJNDI名

jms/aq/myCF

ConnectionFactory

aqjms/orderXaTopicFactory

XATopicConnectionFactory

WebLogicアプリケーションでjms/aq/myCFにあるJMSファクトリをルックアップした場合、アプリケーションはそのJMSのjavax.jms.ConnectionFactoryインタフェースを実装するAQ JMSオブジェクトを取得します。WebLogicアプリケーションでaq/orderXaTopicFactoryにあるJMSファクトリをルックアップした場合、アプリケーションはそのJMSのjavax.jms.XAToicConnectionFactoryインタフェースを実装するAQ JMSオブジェクトを取得します。

AQ JMS外部サーバーの接続ファクトリを構成するには、以下の作業を行う必要があります。

- ローカルおよびリモートのJNDI名を指定します。

- ローカルJNDI名は、接続ファクトリをWebLogic JNDIツリーにバインドするために使用される名前。ローカルJNDI名は、ローカルのWebLogic Serverで公開されている他のJNDI名と競合しないように、一意のものとする必要があります。

- リモートJNDI名は、AQ JMS接続ファクトリをルックアップするためにAQ JMSへ渡される名前。

AQ JMSをグローバル・トランザクションで使用するように構成する場合、XAベースの接続ファクトリを使用してください。そうしないと、非XAベースの接続ファクトリが構成されます。

- これ以外の構成パラメータは不要です。

次を参照:

- 外部接続ファクトリ・リソースを作成する

- Oracle WebLogic Server管理コンソール・オンライン・ヘルプの外部接続ファクトリの作成。

AQ JMS外部サーバーの宛先の構成

AQ JMSの外部宛先を構成する場合、以下の内容を構成する必要があります。

- ローカルJNDI名: WebLogic JNDIツリーに宛先をバインドするために使用される名前。ローカルJNDI名は、ローカルのWebLogic Serverインスタンスで公開されている他のJNDI名と競合しないように、一意のものとする必要があります。

- リモートJNDI名: ルックアップを行うためにAQ JMSに渡される名前。AQ JMSには、以下の構文に従ったリモートJNDI名が必要です。

- 宛先がキューの場合、リモートJNDI名はQueues/<queue name>にする必要があります。

- 宛先がキューの場合、リモートJNDI名はTopics/<topic name>にする必要があります

接続ファクトリと同様、AQ JMSの宛先にも、JMSオブジェクト・タイプを識別するために接頭辞の付いたリモートJNDI名が必要です。宛先用には以下の2つの値が用意されています。

表8-3 JMSインタフェースのAQ JMSの接頭辞値

AQ JMSの接頭辞値

JMSインタフェース

キュー

Javax.jms.Queue

トピック

javax.jms.Topic

AQ JMS接続ファクトリのJNDI名とは異なり、宛先名の値はデータベースに定義されているAQ JMS宛先を表しています。JMSキューまたはトピックの作成を参照してください。たとえば、AQ JMS外部サーバーに次の表に示すような2つの宛先が構成されているとします。

表8-4 AQ JMS外部サーバーの宛先例

ローカルJNDI名

リモートJNDI名

jms/myQueue

Queues/userQueue

AqTopic

Topics/myTopic

jms/myQueueという場所をルックアップするWebLogicアプリケーションは、userQueueで定義されているAQ JMSキューを参照します。AqTopicという場所をルックアップすると、myTopicで定義されているAQ JMSトピックが参照されます。

次を参照:

- 外部接続ファクトリ・リソースを作成する

- Oracle WebLogic Server管理コンソール・オンライン・ヘルプの外部宛先の作成。

Oracle 12cデータベースとの相互運用のための追加構成

次の項では、Oracle 12cデータベース上でAQ JMSを相互運用する場合に必要な追加構成について説明します。

- Oracle 12cデータベースの共有キューでのAQ非同期通知機能は、デフォルトで有効です。
AQ共有キューを使用する場合、メッセージ・リスナーまたはメッセージドリブンBean (MDB)からの非同期受信により、負荷に基づいて追加のJDBC接続が内部的に作成されます。JDBC接続の数がシステムで制限されている場合、クライアント・アプリケーションではシステム・プロパティの値oracle.jms.useJmsNotificationをfalseに設定して、非同期通知を無効にする必要があります。

転送可能MDBの場合、または-Dweblogic.mdb.message.MinimizeAQSessionsがtrueに設定されている場合、MDB接続は内部的に同期受信を使用し、非同期コンシューマは使用しません。

- 通知サービス(-Doracle.jms.useJmsNotification=true)を使用するには、JDBC URLのSIDのかわりにデータベース・サービス名を設定します。例:
jdbc:oracle:thin:@//DB_HOST:DB_PORT/Database ServiceName

- init.oraファイルにinitパラメータを設定することでローカル・リスナーを指定し、データベースを再起動します。例:
LOCAL_LISTENER="(ADDRESS=(PROTOCOL=tcp)(host=DB_HOST)(port=DB_PORT))

- WebLogic Serverプロパティを設定して、使用されるJMSセッションの数を最小限に抑え、MDBポーリング間隔を制御します。AQ JMSとの相互運用のためのメッセージ・ドリブンBeanの設定を参照してください

注意:
WebLogic Server 12.2.1.2では、WebLogic Server Javaシステムのプロパティweblogic.mdb.message.MimizeAQSessionsおよびweblogic.ejb.container.MDBDestinationPollIntervalMillisは廃止されています。かわりに、対応するactivation-config-propertyを使用してください。2つのactivation-config-propertyは、それぞれのJavaシステム・プロパティをオーバーライドします。

プログラミングの考慮事項

以下の節では、高度なWebLogic AQ JMSのトピックに関する情報を紹介します。

- AQ JMSとの相互運用のためのメッセージドリブンBeanの設定

- AQトピックをリスニングするクラスタ化されたWebLogic MDBのスケーラビリティ

- AQ JMS拡張

- リソース参照

- JDBC接続の利用

- Oracle RACサポート

- デバッグ

- パフォーマンスの考慮事項

AQ JMSとの相互運用のためのメッセージドリブンBeanの設定

メッセージドリブンBean (MDB)は、AQ JMSとの相互運用に、構成済の外部サーバーを使用します。「JMS外部サーバーの構成」を参照してください

次に、AQ JMSと相互運用する場合のMDBの考慮事項を示します。

- 次のWebLogic Serverプロパティを設定して、使用されるJMSセッションの数を最小限に抑え、MDBポーリング間隔を制御します。

- Dweblogic.mdb.message.MinimizeAQSessions=true
このプロパティを使用すると、MDBレイヤー内のAQ JMSセッションの数が減少するため、MDBにより保持されるJDBC接続の数が減少します。また、このプロパティの値trueは、weblogic.ejb.container.MDBDestinationPollIntervalMillisが5000ミリ秒より大きい数に設定された場合にのみ有効です。

-Dweblogic.ejb.container.MDBDestinationPollIntervalMillis=6000

- メッセージドリブン・パラメータinitial-context-factoryおよびprovider-urlは、JMS外部サーバーの構成の一部として提供されるため、サポートされません

- ejb-jar.xmlファイルで、MDBの宛先の宛先タイプをjavax.jms.Queueまたはjavax.jms.Topicに構成する必要があります

- コンテナ管理トランザクション、恒久トピック・サブスクリプションなどのMDB機能を有効にするには、他にもMDBの構成が必要です。

詳細は、Oracle WebLogic ServerメッセージドリブンBeanの開発で、メッセージドリブンBeanの理解を参照してください。

AQトピックをリスニングするクラスタ化されたWebLogic MDBのスケーラビリティ

クラスタ化されたMDBでAQトピックをリスニングする場合は、One-Copy-Per-Applicationのメッセージング戦略を実装するために、共有サブスクリプションを使用します。

サブスクリプションを共有するサブスクライバは、次の要件を満たしている必要があります。

- 異なるVM上に存在する。

- 同じデータ・ソース(または同じデータベース・ユーザー名とパスワードを使用するデータ・ソース)を使用します。

- 同じサブスクリプション名を使用します。

データベース・ユーザー名は、サブスクリプションのクライアントIDとして機能します。同じ名前のサブスクリプションに対するクライアントIDが同じ場合、そのサブスクリプションはAQで共有されます。共有サブスクリプションの詳細は、Oracle WebLogic Server JMSアプリケーションの開発の高可用性のための高度なメッセージング機能を参照してください。

AQ JMS拡張

AQ JMS拡張APIがAQ JMSの特定のクラスでサポートされています。AQ JMS拡張は、標準のJMSオブジェクト(接続ファクトリや宛先など)を独自仕様のAQ JMSクラスにキャストすると、呼び出せるようになります。例:

. . .
import oracle.jms.AQjmsFactory;
. . .
ConnectionFactory myCF = (ConnectionFactory) jndiCtx.lookup("aqjms/testCF");
AQjmsFactory myCF = (AQjmsFactory) myCF;
myCF.someProprietaryAQJMSmethod(..);
. . .

AQ JMS接続ファクトリのリソース参照を使用する場合、WebLogic Serverでは基底のAQ JMS接続ファクトリがラッパー・オブジェクトでラップされます。このラッパー・オブジェクトはJMSの標準APIを実装していますが、AQ JMS拡張APIを提供するAQ JMSクラスにはキャストできません。例:

. . .
// Implements wrapping and cannot cast to AQ JMS
<resource-ref>
<res-ref-name>aqjms/testCF</res-ref-name>
<res-type>javax.jms. ConnectionFactory</res-type>
<res-auth>Application</res-auth>
</resource-ref>
. . .

ラップ処理を回避するには、リソース参照のリソース・タイプとして、デプロイメント記述子のjavax.jms.XXXConnectionFactoryのかわりにjava.lang.Objectを指定します。この制限事項はAQ JMSに固有のものです。リソース参照はJavaインタフェースを使用して公開される拡張のみをサポートするためです。例:

. . .
// Use for AQ JMS extensions
<resource-ref>
<res-ref-name>aqjms/testCF</res-ref-name>
<res-type>java.lang.Object</res-type>
<res-auth>Application</res-auth>
</resource-ref>
. . .

AQ JMSでは、その拡張用のJavaインタフェースは定義されません。AQ JMSでは、ラップ処理を回避しても、自動JTAトランザクションの登録は無効にならず、プーリングも妨げられません。AQ JMSは、WebLogicデータ・ソースの組込みの使用を通して、これらの機能を暗黙的に取得するためです。

AdtMessageの使用

AdtMessageは抽象データ型(ADT)をサポートする、特殊なタイプのAQ JMS拡張機能です。ADTは、データ構造と、Oracleデータベースでデータを操作するサブプログラムで構成されます。

注意:

これは、メッセージ・ドリブンBean (MDB)ではサポートされません。

詳細は、次を参照してください。

- Oracle Streamsアドバンスト・キューイング・ユーザーズ・ガイドのOracle Java Message Service (OJMS)を使用したOracle Streamsアドバンスト・キューイングへのアクセスとオブジェクト・タイプのサポート

- Oracle Database PL/SQL言語リファレンスのデータ抽象化

リソース参照

リソース参照を使用し、リソース・タイプがjavax.jms.XXXConnectionFactoryの場合は、ユーザー・アプリケーションに渡されるAQ JMSオブジェクトがラップされます。AQ JMS拡張APIも使用する場合は、これらのAPIをラップしないようにする必要があります(「AQ JMS拡張」を参照)。

WebLogicリソース参照ラッパーでは、AQ JMS接続は自動的にはプールされません。かわりに、AQ JMSのサーバー側統合はデータ・ソースの接続プーリング機能に依存し、それによってJMS接続およびセッションのオープンとクローズに関わるオーバーヘッドが軽減されます。WebLogicリソース参照でプーリング機能が無効になるのは、AQ JMSプロバイダのJMS接続ファクトリが常にクライアントの識別子で事前に構成されているためです。逆に、このようになっているのでWebLogicリソース参照でプーリング機能が無効になると言うこともできます。

JDBC接続の利用

AQ JMSセッションでは、JMSセッションが閉じるまでJDBC接続が維持されます。これは、その接続でデータ・ソースやJDBC URLが使用されるかどうかとは関係なく行われます。セッションが長時間にわたってアイドル状態になった場合、AQ JMSセッションを閉じることをお薦めします。JMSセッションを閉じると、JDBC接続が開放されてWebLogicデータ・ソースのプールに戻るか、データベースおよびJDBC URLのネットワーク・リソースが開放されます。

Oracle RACサポート

次の項では、Oracle RAC環境での制限事項について説明します。

- Oracle RAC環境でAQ JMS RACのフェイルオーバーを実現するには、WebLogicマルチ・データ・ソースの構成が必要です。Oracle WebLogic Server JDBCデータ・ソースの管理のOracle RACでのWebLogic Serverの使用を参照してください。

- Oracle RACのフェイルオーバーは、このリリースではWebLogic AQ JMSスタンドアロン・クライアントの使用時にはサポートされません。

デバッグ

AQ JMSのトレースやデバッグの機能を使用するには、システム・プロパティoracle.jms.traceLevelを設定する必要があります。

このプロパティの値は1 - 6までの整数で、6に設定した場合に詳細度が最大になります。トレースの結果は実行中のJVMの標準出力に出力されます。

パフォーマンスの考慮事項

Oracle RDBMS 11.2.0.2以前のリリースでは、キュー表についての統計がデフォルトでロックされているため、各デキュー処理ごとに全表スキャンが行われます。この問題を解決するには、キュー表のロックを解除して統計を収集します。例:

exec DBMS_STATS.UNLOCK_TABLE_STATS ('<schema>','<queue table>');

exec DBMS_STATS.gather_table_stats('<schema>','<queue table>');

exec DBMS_STATS.LOCK_TABLE_STATS ('<schema>','<queue table>');

高度なトピック

以下の節では、WebLogic ServerアプリケーションとAQ JMSを相互運用する場合の高度な相互運用に関して説明します。

- セキュリティの考慮事項

- WebLogicメッセージング・ブリッジ

- スタンドアロンのWebLogic AQ JMSクライアント

セキュリティの考慮事項

スタンドアロンのクライアントとサーバー側のアプリケーションでは、セキュリティのセマンティクスや構成が異なります。セキュリティについて知りたい場合は、この項をよくお読みください。また、WebLogicのロックダウンに関するドキュメントでも、WebLogic Serverやクラスタを保護する方法について説明しています(『Oracle WebLogic Server本番環境の保護』を参照)。次の項では、このリリースでのセキュリティに関する考慮事項について説明します。

- AQ宛先のセキュリティの構成

- JNDIで公開された宛先および接続ファクトリへのアクセス

- JMS APIでルックアップされる宛先へのアクセスの制御

AQ宛先のセキュリティの構成

AQでは、宛先でのルックアップや、エンキューおよびデキューのため、データベース・ユーザーにENQUEUEまたはDEQUEUEあるいはその両方の許可を構成する必要があります。

以下のユーザー名に対し、ENQUEUEまたはDEQUEUEあるいはその両方の許可を必ず指定します。

- スタンドアロン・クライアントの場合:

- 構成済みのJMS外部サーバーのユーザー名(java.naming.security.principalプロパティを使用して指定されたとおり)。

- JMS ConnectionFactory APIのcreateConnection()メソッドを使用してusernameを渡すJavaコードの場合、このusernameに許可が必要です。

- サーバー側アプリケーションの場合:

- WebLogicデータ・ソースにデータベース・ユーザー名が構成されています。

- JMS ConnectionFactory APIのcreateConnection()メソッドでusernameを渡すJDBCデータ・ソース・クライアントに指定されているusernameには、許可を付与しません。このusernameはWebLogicのusernameであり、データベースのusernameではありません。

AQのルックアップ、エンキュー、およびデキューに使用されるJDBC接続の資格証明や許可については、Oracle Streamsアドバンスト・キューイング・ユーザーズ・ガイドのキューのセキュリティとアクセス制御を参照してください。

注意:

宛先のルックアップ時に許可が失敗すると、アプリケーションの呼出し側に(セキュリティ例外ではなく)「name not found」という例外として明示されます。

JNDIで公開された宛先および接続ファクトリへのアクセス

これまでに説明したように、JMS外部サーバーの構成タスクの一部として、接続ファクトリや宛先のローカルJNDI名を構成する必要があります。こうしたJNDI名には必要に応じてセキュリティ・ポリシーを構成することもできます。そのようにすると、JNDIルックアップ時に現在のWebLogic資格証明に基づいてアクセス・チェックが行われます。現在のWebLogic資格証明はクライアントのタイプによって決まります。

アプリケーションのWebLogic JNDIルックアップのセキュリティ・ポリシーの資格証明のチェックで宛先として合格すると、Oracle AQのその宛先リソースが、JMS外部サーバーの宛先で自動的にJDBC接続を使用してルックアップされます。

スタンドアロンのクライアントの場合、この宛先ルックアップの2番目のプロセスで使用される資格証明は、JMS外部サーバーに構成されているusernameおよびpasswordに基づくものです。

サーバー側アプリケーションのJDBCデータ・ソース・クライアントの場合、この2番目の宛先ルックアップで使用される資格証明は、そのデータ・ソースの一部として構成されているデータベースのusernameおよびpasswordに基づきます。このデータ・ソースへのアクセス権を得るために使用される資格証明は、現在のWebLogic資格証明であることに注意してください。このデータ・ソースにWebLogicセキュリティ・ポリシーを構成することも可能です。WebLogicデータ・ソースのIDベースの接続プーリング機能は、この目的のためにはサポートされていません。

前述したように、データベースの資格証明には、宛先の正常なルックアップのために、宛先に対するAQ JMSのエンキューまたはデキュー・パーミッションが必要です。「AQ宛先のセキュリティの構成」を参照してください

JMS APIでルックアップされる宛先へのアクセスの制御

JMSのQueueSession APIとTopicSession APIは、宛先のルックアップのために、createQueue()とcreateTopic()という名前のJNDIの代替物を提供します。Oracle WebLogic Server JMSアプリケーションの開発の宛先のルックアップ方法を参照してください。

createQueue()およびcreateTopic()の呼出しでは、JMS接続に関連付けられているデータベース資格証明が使用されます。以降の節では、この資格証明を設定する方法について説明します。

スタンドアロン・クライアント向けのその他のセキュリティ構成

以下の節では、スタンドアロン・クライアント向けのセキュリティ構成について説明します。

- JNDIの初期コンテキストの確立時や後続のJNDIルックアップの実行時には、クライアントからWebLogicへのネットワーク通信が発生します。確実にセキュアな通信を行い、プレーン・テキストが渡されないようにするには、SSL対応のプロトコル(t3sやhttpsなど)を使用します。データベース・ログイン用に構成されるJMS外部サーバーの資格証明はもちろん、WebLogicログインに使用される資格証明も、SSLが構成されていない場合にはプレーン・テキストで渡されます。

- ネットワーク通信は、AQとの通信時にクライアントからデータベースに対して行われます。この通信はJDBC URLの構成で制御され、JDBC URLがSSLを使用するように構成されていない限り、プレーン・テキストで渡されます。スタンドアロンのクライアントは、AQ JMS APIを使用してデータベース接続でデータベースと直接的に通信し、そのJMSリクエストはWebLogicサーバーを通りません。

- WebLogic Serverのユーザー名およびパスワード: クライアントからWebLogicへのネットワーク・ログインは、JNDIの初期コンテキスト確立の一部として実行されます。このコンテキストの作成時にオプションとして指定されるユーザー名およびパスワードのプロパティが、WebLogicのIDとなります(プロパティ名はそれぞれContext.SECURITY_PRINCIPAL = "java.naming.security.principal"、Context.SECURITY_CREDENTIALS = "java.naming.security.credentials")。これが、後続のJNDIルックアップでチェックされる資格証明となります。この資格証明は現在のスレッドとも暗黙的に関連付けられるため、同じスレッドでの後続のWebLogic処理にも使用される資格証明になります。ただし、これはAQ JMS処理に使用される資格証明ではありません。

- javax.jms.ConnectionFactory createConnection()メソッドには、オプションのユーザー名とパスワードがあります。スタンドアロン・クライアントの場合、これらが、JMS外部サーバー構成の一部として構成されているコンテキストの資格証明をオーバーライドします。AQ JMSでは、この指定されたユーザーIDでデータベース接続が作成されます。ユーザー名とパスワードを指定せずにcreateConnection()が呼び出された場合は、JMS外部サーバー構成の一部として構成されているユーザー名とパスワードを使用して、データベース接続が作成されます。

- ユーザー名やパスワードを直接、JDBC URLに含めてはなりません。かわりにJMS外部サーバーのユーザー名およびパスワードを使用します。

- JMS外部サーバーの接続ファクトリに、ユーザー名やパスワードを構成しないでください。このようにした場合の動作はサポートされません。

サーバー側アプリケーション向けのその他のセキュリティ構成

以下の節では、サーバー側アプリケーション向けのセキュリティ構成について説明します。

- スタンドアロン・クライアントのサポートにも使用されているJMS外部サーバーでないかぎり、そのJMS外部サーバーにjava.naming.security.principalや資格証明を構成しないでください。

- JMS外部サーバーの接続ファクトリに、ユーザー名やパスワードを構成しないでください。このようにした場合の動作はサポートされません。

- サーバーからデータベースへのネットワーク通信(サーバー側アプリケーション)は、データ・ソースの構成で制御され、そのデータ・ソースがSSLを使用するように構成されていない限り、プレーン・テキストで行われます。

- javax.jms.ConnectionFactory createConnection()メソッドには、オプションのユーザー名とパスワードがあります。サーバー側のJMS AQアプリケーションの場合、このメソッドはユーザー名をWebLogicユーザーのものと見なして、WebLogic serverに対する認証を行います。この動作は他の種類のJMS AQクライアントの動作とは異なります。他の種類のJMS AQクライアントでは、ユーザー名がデータベース・ユーザーとして扱われます。WebLogicデータ・ソースとともに構成されている場合、AQ JMSではそのWebLogicデータ・ソースに認証が委託され、AQ JMSでWebLogicユーザーのセマンティクスが継承されます。

- AQ JMS外部サーバーがWebLogicデータ・ソースとともに構成されている場合、そのデータ・ソースは汎用JDBC利用のために公開されます。データ・ソースは、Oracle WebLogic Server JDBCデータ・ソースの管理のJDBCデータ・ソースを保護するためのロールおよびポリシーの使用の説明に従って保護することをお薦めします。

- WebLogic Serverのユーザー名およびパスワードについて。WebLogicの資格証明は、JNDI内の保護されている名前にアクセスするときや、保護されているデータ・ソースにアクセスするときにチェックされます。サーバー側アプリケーションでは、その同じWebLogic資格証明を自動的にアプリケーションの呼出し側と見なします。あるいはMDBの場合には、この資格証明をMDB構成の一部として構成することも可能です。

- WebLogicデータ・ソースのIDベースの接続プーリング機能はサポートされていません。

- JNDIコンテキストの資格証明: 通常、サーバー側アプリケーション内でJNDIコンテキストの設定の一部として資格証明を指定する必要はありません。また、一般的に推奨されません。このようにすると新しい資格証明が作成され、アプリケーションの現在の資格証明がオーバーライドされます。つまり、コンテキストの作成時にオプションで指定されたユーザー名とパスワードのプロパティがWebLogicのIDになり、現在のIDと置き換えられます(プロパティ名はContext.SECURITY_PRINCIPAL = "java.naming.security.principal"とContext.SECURITY_CREDENTIALS = "java.naming.security.credentials")。このオプションの新しい資格証明は、暗黙的に現在のスレッドと関連付けられます。そのため、同じスレッドの後続のWebLogic処理(JNDIルックアップなど)でも、その資格証明が使用されます。この新しい資格証明は、AQ JMS処理に使用される資格証明ではありません。

WebLogicメッセージング・ブリッジ

WebLogicメッセージング・ブリッジは、構成済のソース・ブリッジ宛先およびターゲット・ブリッジ宛先と通信します。ソース宛先とターゲット宛先とのマッピングごとに、メッセージング・ブリッジのインスタンスを構成する必要があります。各メッセージング・ブリッジ・インスタンスは、マッピングするソース宛先とターゲット宛先、メッセージ・フィルタリング・セレクタ、サービスの品質(QOS)、トランザクション・セマンティクスおよび各種再接続パラメータを定義します。

AQ外部宛先が、メッセージを送受信するアプリケーションやMDBを実行するサーバーに対してローカルではない場合、AQ外部宛先に対してローカルなサーバーでメッセージング・ブリッジ・インスタンスを構成する必要があります。ローカル・データベース接続は、AQ宛先からのメッセージの送受信プロセスで使用されます。

WebLogicメッセージング・ブリッジの詳細は、Oracle WebLogic Server WebLogicメッセージング・ブリッジの管理のメッセージング・ブリッジの理解を参照してください。

メッセージング・ブリッジ・インスタンスを作成する

次に、あるドメインで外部宛先として構成されたAQ宛先と、別のドメインで実行するアプリケーションまたはMDBとの間にメッセージング・ブリッジを作成する主な手順について説明します。

1. AQ宛先が外部宛先として構成されるサーバーにブリッジ・インスタンスを作成します。

2. ソース・ブリッジ宛先とターゲット・ブリッジ宛先を作成します。

ソース宛先またはターゲット宛先に外部AQ JMS宛先が指定される場合、デフォルトの「メッセージング・プロバイダ」ドロップダウンで「その他のJMS」を選択します。

3. リソース・アダプタをデプロイします。

4. メッセージング・ブリッジ・インスタンスを作成します。

メッセージング・ブリッジのサービス品質をExactly-Onceにする場合は、データ・ソースをXAベースのJDBCドライバで構成し、XA JMS接続ファクトリ・インタフェースを実装するAQ JMS接続ファクトリを使用する必要があります。「AQ JMS用のWebLogicデータ・ソースの構成」および「JMS外部サーバー接続ファクトリの構成」を参照してください

5. メッセージング・ブリッジのターゲットを指定します。

WebLogic Server管理コンソールは、適切なリソース・アダプタをデプロイし、一部の属性値を設定して、メッセージング・ブリッジを作成するために役立ちます。使用する環境に合うように、メッセージング・ブリッジの設定変更が必要な場合もあります。Oracle WebLogic Server管理コンソール・オンライン・ヘルプのメッセージング・ブリッジ・インスタンスの作成を参照してください。

スタンドアロンのWebLogic AQ JMSクライアント

WebLogic AQ JMSスタンドアロン・クライアントを作成できます。これは、JDBC URLを使用してJMS外部サーバーが定義した、AQ JMS接続ファクトリと宛先をルックアップできます。クライアント側のクラスパスのjarとして$MW_HOME/oracle_common/modules/oracle.jdbc_12.1.0/aqapi.jarと$MW_HOME/oracle_common/modules/features/com.oracle.db.jdbc7-no-dms.jarが必要であり、wlthint3client.jar、wlclient.jar、wlfullclient.jarのいずれかのWebLogicクライアントjarも必要です。

注意:

クライアント側のクラスパスではWebLogic Server 12cのjarファイルのみを使用してください。11gのjarファイルの使用や12cと11gのjarファイルを組み合せた使用はサポートされていません。

WebLogic ServerのJVMの外部で実行されるアプリケーションについては、以下のような処理が行われます。

- 構成済のWebLogic JMS外部サーバーで、データベースのURLや、その他のJDBCドライバの構成が参照されます。「データベースのJDBC URLを使用した外部サーバーの構成」を参照してください

- WebLogic JMS外部サーバー構成の一部として、AQ JMSの接続ファクトリおよび宛先用にローカルJNDI名が定義されます。これらのJNDI名は、既存のAQ接続ファクトリや宛先にマップするように構成されます。

- スタンドアロンのクライアントではローカルJNDI名を参照します。WebLogic Serverで実行されるアプリケーションとは異なり、スタンドアロンのクライアントではドライバおよびAQクライアントが確実にclasspathに存在する必要があります。

データベースのJDBC URLを使用した外部サーバーの構成

jndi-properties-credentialsに、db_urlおよびjava.naming.security.principal JNDIプロパティと、パスワードを指定します。

例:

<foreign-server>

<initial-context-factory>oracle.jms.AQjmsInitialContextFactory</initial-context-factory>

<jndi-properties-credential-encrypted>{3DES}g8yFFu1AhP8=</jndi-properties-credential-encrypted>

<jndi-property>
<key>java.naming.security.principal</key>
<value>j2ee</value>
</jndi-property>

<jndi-property>
<key>db_url</key>
<value>jdbc:oracle:thin:@{hostname}:{port}:{sid}</value>
</jndi-property>

</foreign-server>

- db_url JNDIプロパティの値は、AQ JMS Oracleデータベースへの接続に使用されるJDBC URLです。

- java.naming.security.principalの値は、AQ JMSがデータベースへの接続に使用するデータベース・ユーザー名です。

- jndi-properties-credentialsはデータベースのパスワードを格納。

これ以外の構成プロパティは不要です。

スタンドアロンのWebLogic AQ JMSクライアント使用時の制限事項

スタンドアロンのWebLogic JMSクライアントの作成時および使用時に考慮する必要がある制限事項を次に示します。このリリースでは以下の内容はサポートされていません。

- WebLogic AQ JMSスタンドアロン・クライアントを使用した、WLSで管理されるグローバル・トランザクションへの自動参加。

- WebLogic AQ JMSスタンドアロン・クライアントの接続プーリング。

- データ・ソースを使用したAQ JMS外部サーバーで定義されているJMSオブジェクトのルックアップ。

関連ドキュメント

関連ドキュメントへのリンクを次に示します。

- Oracle Streamsアドバンスト・キューイング・ユーザーズ・ガイドのOracle Databaseアドバンスト・キューイングの概要を参照してください。

- Oracle WebLogic Server JMSアプリケーションの開発のリモートJMSプロバイダ統合のFAQを参照してください。

- 『Oracle WebLogic Serverのパフォーマンスのチューニング』

- 『Oracle WebLogic Serverスタンドアロン・クライアントの開発』

9 JMS統計のモニターとメッセージの管理

この章では、WebLogic Server 12.1.3でJMS統計をモニターおよび管理する方法について説明します。実行中のサーバーおよびそのコンテナ内にデプロイされているアプリケーションによって生成された診断データを作成、収集、分析、アーカイブし、それらの診断データにアクセスできます。

Weblogic JMSでは、高度な実行時統計機能でWebLogicドメイン内のJMSサーバーや宛先リソースをモニターして、問題がないかどうかを確認できます。問題があれば、プロファイリングによって、問題の原因となっているアプリケーションを判断できます。アプリケーションを絞り込んだら、JMSデバッグ機能を使用して、そのアプリケーション内の問題点を突き止めます。

JMS診断通知、デバッグ・オプション、メッセージ・ライフ・サイクルのロギング、およびJMS宛先でのメッセージ処理の制御を構成する方法については、「WebLogic JMSのトラブルシューティング」を参照してください。

このリリースに含まれるメッセージ管理ツールでは、WebLogic Server管理コンソールまたは新しいパブリック・ランタイムAPIを使用することで、すべてのメッセージを表示および参照したり、稼働中のJMSサーバーでほとんどのメッセージを操作したりする機能が強化されています。これらのメッセージ管理機能には、トランザクション管理、恒久サブスクライバの管理、JMSクライアント接続の管理に加えて、メッセージの表示(ソート用)、メッセージの操作(作成、移動、削除など)、メッセージのインポートとエクスポートなどがあります。

この章の内容は次のとおりです。

- JMS統計のモニター

- JMSメッセージの管理

WebLogic診断サービスの詳細は、『Oracle WebLogic Server診断フレームワークの構成と使用』を参照してください。

JMS統計のモニター

WebLogic JMSを構成すると、Oracle WebLogic Server JMSアプリケーションの開発の基本的なJMSアプリケーションの開発で説明されているように、アプリケーションではJMS APIを介してメッセージを送受信できるようになります。

JMSサーバー、接続、キューおよびトピック宛先、JMSサーバーのセッション・プール、プール済み接続、アクティブなセッション、メッセージ・プロデューサ、メッセージ・コンシューマ、JMSトピックの恒久サブスクライバといったJMSリソースに関する統計をモニターできます。

サーバーが実行されていれば、JMS統計は増え続けます。統計は、サーバーを再起動するときにのみリセットされます。

JMSサーバーのモニター

WebLogic Server管理コンソールまたはJMSServerRuntimeMBeanを通じて、ドメインに定義されているアクティブなJMSサーバーに関する統計をモニターできます。JMSサーバーは、JMSサーバーに限定的にターゲット指定されたJMSモジュール内のJMSキュー・リソースおよびJMSトピック・リソースの管理コンテナとして機能します。

WebLogic Server管理コンソールを使用したJMSサーバーのモニターの詳細は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのJMSサーバーのモニターを参照してください。

WebLogic Server管理コンソールでJMSサーバーをモニターする場合は、アクティブな宛先、トランザクション、接続、およびセッション・プールもモニターできます。

クラスタのターゲットとして指定されたJMSサーバーをモニターする

クラスタをターゲットとして指定されたJMSサービス(JMSサーバー、SAFエージェント、パス・サービスなど)と永続ストアには、動的クラスタ内の個々のインスタンスの統計をモニターするために関連付けられたRuntimeMbeansの複数のインスタンスがあります。JMSサーバーと永続ストアの実行時MBeanには、対応するサーバー・インスタンス名に従って、次のパターンを使用した名前が自動的に付けられます。

configured_JMS_service_Artifact_name@server-name

server-nameは構成済のサーバー名に動的サーバー・インスタンス番号を連結したものです。

アクティブなJMS宛先をモニターする

JMSサーバーにターゲット指定されているすべてのアクティブな宛先に関する統計をモニターできます。JMS宛先は、JMSサーバーに限定的にターゲット指定されたJMSモジュール内のキュー宛先またはトピック宛先のタイプを特定します。

詳細は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのJMSサーバー: モニター: アクティブな宛先を参照してください。

アクティブなJMSトランザクションをモニターする

JMSサーバーで実行しているすべてのアクティブなトランザクションに関する統計をモニターできます。

アクティブなJMSトランザクション用に提供される実行時統計の詳細は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのJMSサーバー: モニター: アクティブなトランザクションを参照してください。

アクティブなJMS接続、セッション、コンシューマ、プロデューサをモニターする

JMSサーバーへのアクティブなJMS接続に関する統計をモニターできます。JMS接続は、メッセージング・システムへの開かれた通信チャネルです。

アクティブなJMSサーバー接続用に提供される実行時統計の詳細は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのJMSサーバー: モニター: アクティブな接続を参照してください。

JMSサーバーのアクティブな接続のモニター用ページでも、サーバー上のアクティブなJMSセッション、コンシューマ、およびプロデューサの統計をすべてモニターできます。セッションでは、生成および消費されるメッセージの順序が定義されます。また、複数のメッセージ・プロデューサとメッセージ・コンシューマを作成できます。メッセージの生成と消費には同じスレッドを使用できます。

WebLogic Server管理コンソールを使用したセッション、コンシューマ、およびプロデューサのモニターの詳細は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプの次のトピックを参照してください。

- JMSサーバー: モニター: アクティブな接続: セッション

- JMSサーバー: 監視: アクティブな接続: セッション: コンシューマ

- JMSサーバー: 監視: アクティブな接続: セッション: プロデューサ

アクティブなJMSセッション・プールをモニターする

JMSサーバー用に定義されているすべてのアクティブなJMSセッション・プールに関する統計をモニターできます。セッション・プールを使用すると、アプリケーションでメッセージを並行して処理できます。

アクティブなJMSセッション・プール用に提供される実行時統計の詳細は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのJMSサーバー: モニター: アクティブなセッション・プールを参照してください。

キューのモニター

WebLogic Server管理コンソールまたはJMSDestinationRuntimeMBeanを通じて、JMSモジュール内のキュー・リソースに関する統計をモニターできます。JMSキューでは、JMSサーバーのポイント・ツー・ポイントの宛先タイプが定義されます。キューは、同期ピア通信に使用されます。キューに配信されたメッセージは、1つのコンシューマに配信されます。

WebLogic Server管理コンソールを使用したキュー・リソースのモニターの詳細は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのJMSシステム・モジュールのキューのモニターを参照してください。

WebLogic Server管理コンソールを使用して、キュー上のメッセージを管理することもできます。「JMSメッセージの管理」を参照してください

トピックのモニター

WebLogic Server管理コンソールまたはJMSDestinationRuntimeMBeanを使用して、JMSモジュール内のトピック・リソースに関する統計をモニターできます。JMSトピックでは、JMSサーバーのパブリッシュ/サブスクライブの宛先タイプが定義されます。トピックは、非同期のピア通信に使用されます。トピックに配信されたメッセージは、すべてのトピック・コンシューマに配信されます。

WebLogic Server管理コンソールを使用したトピック・リソースのモニターの詳細は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのJMSシステム・モジュールのトピックのモニターを参照してください。

トピックの恒久サブスクライバのモニター

WebLogic Server管理コンソールまたはJMSDurableSubscriberRuntimeMBeanを使用して、JMSトピックで実行中のすべての恒久サブスクライバに関する統計をモニターできます。恒久サブスクライバでは、トピック・サブスクライバに名前を割り当ててユーザーやアプリケーションと関連付けられます。恒久サブスクライバは、メッセージが配信された際にアクティブではない場合にも、メッセージが配信されるか期限切れになるまで、永続的なファイル・ベースのストアか、JDBCでアクセス可能なデータベースに格納されます。

WebLogic Server管理コンソールを使用して、トピックで実行中の恒久サブスクライバを管理することもできます。「JMSメッセージの管理」を参照してください

共通分散キューのモニター

WebLogic Server管理コンソールまたはJMSDestinationRuntimeMBeanを使用して、JMSモジュール内の共通分散キュー・リソースに関する統計をモニターできます。分散キュー・リソースは、単一の論理宛先としてクライアントからアクセス可能なキューのセットです(分散キューは独自のJNDI名を持ちます)。この単位のメンバーは通常、クラスタ内の複数のサーバーに分散されており、各メンバーは個々のJMSサーバーに属しています。

WebLogic Server管理コンソールを使用した共通分散キュー・リソースのモニターの詳細は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプの共通分散キューの統計のモニターを参照してください。

WebLogic Server管理コンソールを使用して、分散キュー上のメッセージを管理することもできます。「JMSメッセージの管理」を参照してください

共通分散トピックのモニター

WebLogic Server管理コンソールまたはJMSDestinationRuntimeMBeanを使用して、JMSモジュール内の共通分散トピック・リソースに関する統計をモニターできます。分散トピック・リソースは単一のトピックのセットであり、単一の論理宛先としてクライアントにアクセスできます(たとえば、分散トピックには独自のJNDI名があります)。この単位のメンバーは通常、クラスタ内の複数のサーバーに分散されており、各メンバーは個々のJMSサーバーに属しています。

WebLogic Server管理コンソールを使用した共通分散トピック・リソースのモニターの詳細は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプの共通分散キューの統計のモニターを参照してください。

プール済みJMS接続のモニター

サーバー上のすべてのアクティブなプール済みJMS接続に関する統計を表示できます。プール済みJMS接続は、EJBまたはサーブレットのデプロイメント記述子のresource-reference要素を使用してJMS接続ファクトリを定義するEJBとサーブレットによって使用される、セッション・プールです。

詳細は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのJMSサーバー: モニター: アクティブなプール接続を参照してください。

JMSメッセージの管理

Weblogic JMSメッセージのモニター機能と管理機能を使用すると、新しいメッセージの作成、選択したメッセージの削除、別のキューへのメッセージの移動、別のファイルへのメッセージ・コンテンツのエクスポート、別のファイルからのメッセージ・コンテンツのインポート、またはキューからのすべてのメッセージの削除を行うことができます。

Java APIを使用したJMSメッセージの管理

WebLogic Java Management Extensions (JMX)機能を使用すると、JMSDestinationRuntimeMBeanやJMSDurableSubscriberRuntimeMBeanにアクセスして、JMSキューやトピックの恒久サブスクライバ上にあるメッセージを管理できます。詳細は、Oracle WebLogic Server JMXによるカスタム管理ユーティリティの開発のJMXを使用したWebLogic Server MBeanへのアクセスを参照してください。

WebLogic JMSには、メッセージの様々な状態があります。後続の項で説明されているように、メッセージを管理するためにこれらの状態を利用できます。有効なメッセージ状態の詳細は、Oracle WebLogic Server Java APIリファレンスのweblogic.jms.extensions.JMSMessageInfoに関する項を参照してください。

管理コンソールを使用したJMSメッセージの管理

WebLogic Server管理コンソールの「JMSメッセージの管理」ページには、モニターしているスタンドアロンのキュー、分散キュー、または恒久トピック・サブスクライバで使用できるメッセージの概要が表示されます。ページ内でメッセージを探したり、指定したフィルタ条件を満たすメッセージのセットを検索することができます。メッセージの表示をカスタマイズして、必要な情報のみを表示することもできます。このページでは、コンテンツを表示するメッセージの選択、新しいメッセージの作成、1つまたは複数のメッセージの削除、メッセージの移動、メッセージのインポートとエクスポート、キューや恒久サブスクリプションからの全メッセージの削除を行うことができます。

WebLogic Server管理コンソールを使用してスタンドアロンのキュー、分散キュー、および恒久サブスクライバにあるメッセージを管理する場合の詳細は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプで次の手順を参照してください。

- キューのメッセージの管理

- 分散キュー・メッセージの管理

- トピックの恒久サブスクライバの管理

各メッセージ管理機能については、以降の節で詳しく説明します。

メッセージの実行時情報をモニターする

デフォルト設定の「JMSメッセージの管理」ページには、キューまたは恒久サブスクライバ上の各メッセージに関する情報が、以下の列で構成される表形式で表示されます。

- ID: メッセージの一意の識別子。

- タイプ: JMSメッセージの種類(BytesMessage、TextMessage、StreamMessage、ObjectMessage、MapMessage、XMLMessageなど)。

- 相関ID: メッセージのユーザー定義の識別子。通常は件名が同じメッセージの相関に使用されます

- 優先度: メッセージの重要度または緊急度のレベルを示す順位。0が最低、9が最高です。通常は、0 - 4が通常の優先度、5 - 9は緊急度の高い優先度を示します。優先度はデフォルトで4に設定されています。

- タイムスタンプ - メッセージがキューに到着した時刻。

表示する列の順序を変更したり、どの列を表示してどの列を非表示にするかを選択したりできます。ページに表示するメッセージの数を、デフォルトの10から20または30に増やすこともできます。

デフォルトでは、宛先に到着した順番でメッセージが表示されます。「ID」列のヘッダーをクリックすると、メッセージIDの昇順または降順でメッセージを表示することを選択できます。ただし、ソート順をいったん変更すると、当初のソート順に戻すことはできません。メッセージを到着順で表示するには、「JMSシステム・モジュール・リソース」ページに戻ってキューを選択しなおします。

メッセージを問い合せる

「JMSメッセージの管理」ページの上部にある「メッセージ・セレクタ」フィールドを使用すると、有効なJMSメッセージ・ヘッダーまたはプロパティ(JMSXDeliveryCountを除く)に基づいてキュー上のメッセージをフィルタ処理できます。メッセージ・セレクタはブール式です。これは、SQLのSELECT文のwhere句と類似した構文を含む文字列から構成されます。

以下に、セレクタ式の例を示します。

salary > 64000 and dept in ('eng','qa')
(product like 'WebLogic%' or product like '%T3')
and version > 3.0
hireyear between 1990 and 1992
or fireyear is not null
fireyear - hireyear > 4

メッセージ・セレクタ構文の詳細は、javax.jms.MessageのJavadoc(http://docs.oracle.com/javaee/6/api/javax/jms/Message.htmlで入手可能)を参照してください。

メッセージを移動する

以下の条件を満たせば、ソース宛先からターゲット宛先にメッセージを転送できます。

- ソース宛先が、消費の休止状態にあるキューまたはトピック恒久サブスクライバです。

注意:

消費の休止状態の詳細は、「消費の休止と消費の再開」を参照してください

- メッセージの状態が、「表示」、「遅延」、または「順序付け」です。

- ターゲット宛先が:

- ソース宛先と同じクラスタにあります

- キュー、トピック、またはトピック恒久サブスクライバです

- 生成の休止状態にありません

注意:

生成の休止状態の詳細は、「生成の休止と生成の再開」を参照してください

メッセージを移動しても、メッセージの識別子は変更されません。移動したメッセージがすでにターゲット宛先に存在する場合は、同じ識別子の重複メッセージが宛先に追加されます。

メッセージを削除する

以下の条件を満たす場合に、キューまたはトピックの恒久サブスクライバから特定のメッセージを削除したり、すべてのメッセージを削除することができます。

- 宛先が消費の休止状態にあります。

注意:

消費の休止状態の詳細は、「消費の休止と消費の再開」を参照してください

- メッセージの状態が、「表示」、「遅延」、または「順序付け」です。

削除処理の間は、宛先がロックされます。削除処理中に障害が発生すると、選択したメッセージの一部しか削除されない可能性があります。

新しいメッセージを作成する

宛先に送信する新しいメッセージを作成できます。新しいメッセージを作成するには、以下の情報を指定します。

- メッセージの種類: BytesMessage、TextMessage、StreamMessage、ObjectMessage、MapMessage、XMLMessageなど。

- 相関ID: メッセージのユーザー定義の識別子。通常は件名が同じメッセージの相関に使用されます。

- 有効期限: メッセージの有効期限(存続時間値)を指定します。

- 優先度: メッセージの重要度または緊急度のレベルを示す順位。0が最低、9が最高です。通常は、0 - 4が通常の優先度、5 - 9は緊急度の高い優先度を示します。優先度はデフォルトで4に設定されています。

- 配信モード: PERSISTENTまたはNON_PERSISTENTメッセージングを指定します。

- 配信時間: メッセージをコンシューマに配信できる最も早い絶対時間を定義します。

- 再配信の制限: メッセージがエラー宛先に移動するまでに試行できる再配信の回数。

- ヘッダー: 各JMSメッセージには、ヘッダー・フィールドの標準セットが含まれています。これはデフォルトで含まれ、メッセージ・コンシューマで利用できます。一部のフィールドは、メッセージ・プロデューサで設定できます。

- 本文: メッセージのコンテンツです。

JMSメッセージのプロパティの詳細は、Oracle WebLogic Server JMSアプリケーションの開発のWebLogic JMSの理解を参照してください。

メッセージをインポートする

XMLフォーマットのメッセージをインポートすると、指定した宛先にメッセージが作成されるか、既存のメッセージが置換されます。インポートするメッセージのターゲット宛先として指定できるのは、キューまたはトピック恒久サブスクライバです。宛先は、生成の休止状態である必要があります。

注意:

生成の休止状態の詳細は、「生成の休止と生成の再開」を参照してください

インポートしたファイルによって置換されたメッセージがJMSトランザクションに関連付けられていた場合は、インポートしたメッセージも引続きそのトランザクションに関連付けられます。

新しいメッセージを作成する場合や、インポートしたファイルによって既存のメッセージが置換される場合は、以下の規則が適用されます。

- 割当て制限は、新しいメッセージと置換したメッセージの両方に適用されます。

- インポートしたメッセージの配信回数はゼロに設定されます。

- 新しいメッセージIDは、インポートしたメッセージごとに生成されます。

- インポートしたメッセージの配信モードがPERSISTENTに設定されており、ターゲット宛先にストアが存在しない場合は、配信モードがNON-PERSISTENTに変更されます。

注意:

JMSメッセージのインポートは、結果だけを見ると新しいJMSメッセージの作成やパブリッシュに似ていますが、ExpirationTimeが定義されている(ゼロでない)メッセージのインポート時の動作が異なります。これは、メッセージ管理APIのExpirationTimeがインポートされたメッセージ専用であるためです。一方、メッセージ送信APIのExpirationTimeは送信されたメッセージの時間に関連するものです。

メッセージをエクスポートする

メッセージをエクスポートすると、JMSメッセージがXMLフォーマットまたはシリアライズされたフォーマットに変換されます。ソース宛先は、生成の休止状態である必要があります。

注意:

生成の休止状態の詳細は、「生成の休止と生成の再開」を参照してください

一時的な宛先を使用することで、サーバー定義の宛先の構成と作成に伴うシステム管理のオーバーヘッドを発生させずに、必要に応じてアプリケーションで宛先を作成できます。

注意:

通常、JMSアプリケーションでは、JMSReplyToヘッダー・フィールドを使用してリクエストにレスポンスを戻すことができます。しかし、JMSReplyToフィールドの情報は使用可能な宛先オブジェクトではなく、エクスポートまたはインポートの後は有効ではありません。

トランザクションの管理

グローバル・トランザクションの一部として生成または消費されるメッセージは、基本的にトランザクションによってロックされ、トランザクション・コーディネータがJMSブランチをコミットするか中止するまでロックされたままになります。障害が原因でコーディネータがトランザクションの結果をJMSサーバーに通信できない場合、トランザクションに関連付けられたメッセージは長時間保留されたままになります。

WebLogic Server管理コンソールから利用できるJMSサーバーのトランザクション管理機能を使用すると、次のことが行えます。

- JMSサーバーが参加する進行中のトランザクションを特定します。

- JMSトランザクション・ブランチに関連付けられたメッセージを特定します。

- 保留中のJMSトランザクション・ブランチをコミットするかロールバックすることでその結果を強制します。

- JMSクライアント接続を管理します。

特定のWebLogic ServerインスタンスのすべてのJMS接続を表示して、接続を保持する各プロセスのアドレスとポートの情報を取得できます。接続を終了させることもできます。WebLogic Server管理コンソールを使用したJMSサーバーのトランザクション管理の詳細は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのJMSサーバー: モニター: アクティブなトランザクションを参照してください。

JMSのトランザクションの詳細は、Oracle WebLogic Server JMSアプリケーションの開発のWebLogic JMSでのトランザクションの使用方法を参照してください。

恒久トピック・サブスクライバの管理

特定のトピックの恒久サブスクライバを一覧表示したり、サブスクライバに関連付けられたメッセージを参照することができます。また、サブスクライバの作成や削除、選択したメッセージの削除、サブスクリプションの全メッセージの削除を行うことができます。

詳細は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのトピックの恒久サブスクライバの管理を参照してください。

10 JMS初級ユーザーおよび上級ユーザーのベスト・プラクティス

この章では、JMS初級ユーザーと上級ユーザーのためのアドバイスおよびベスト・プラクティスを示します。WebLogic Server 12.1.3のターゲット設定、統合オプション、URLの概要、高可用性(HA)およびチューニングについて説明します。

この章の内容は次のとおりです。

- 構成のベスト・プラクティス

- ターゲット指定のベスト・プラクティス

- 統合およびマルチドメインのベスト・プラクティス

- WebLogic JMSクライアント・オプションの理解

- WebLogic URLの理解

- 厳密なメッセージの順序付けのベスト・プラクティス

- 高可用性のベスト・プラクティス

- JMSのパフォーマンスとチューニング

構成のベスト・プラクティス

次の項では、JMSアプリケーションの構成方法に関する基本手順の概要を示します。

1. JMSサーバーと永続ストアの構成

2. JMSモジュールの構成

3. JMSリソースの構成

4. SAFエージェント、ストア、インポート宛先の構成

JMSサーバーと永続ストアの構成

JMSサーバーと永続ストアを構成する前に、次の内容を検討します。

- 宛先、接続ファクトリ、およびその他のJMSリソースが、そのホストJMSサーバーおよび永続ストアとは別に構成されています。JMSリソースを構成するベスト・プラクティスの手順については後ほど説明します。

- WebLogic分散宛先を利用する場合、WebLogicクラスタを、そのクラスタの各WebLogicサーバーのJMSサーバーとカスタム永続ストアで構成する必要があります。WebLogic JMS分散宛先が機能するには、WebLogicクラスタが機能している必要があります。

- クラスタ化されたJMSサーバーは、すべてのWebLogic JMS機能(順序単位、シングルトン宛先、ストア・アンド・フォワード・エージェントなど)をサポートするわけではありませんが、簡略化された構成と、リソースの規模の動的変更を可能にします。「簡略化されたJMSクラスタと高可用性の構成」を参照してください

- 移行可能ターゲットのみがクラスタでサポートされます。クラスタを使用していない場合、サイズ1のクラスタを再検討して使用できます。これにより、移行可能ターゲットを使用できます。移行可能ターゲットを使用すると、次に示すように便利な再起動インプレース機能が有効になります。また、単一サーバーから複数サーバーへの拡張プロセスが容易になるため、アプリケーションの将来保証にも役立ちます。

注意:
高可用性については、移行可能なターゲットを使用するかわりに、適切な高可用性構成設定とともにJMSアーティファクトにクラスタをターゲットとして指定することをお薦めします。

構成済クラスタにJMSサーバーと永続ストアを構成するには、次の手順を実行します。

1. JMSサーバーをホストする各WebLogicサーバーでカスタム・ストアを作成します。WebLogicサーバーにすでにカスタム・ストアがある場合、サービスでストアを共有すると、通常は利便性とパフォーマンスが向上するため、この手順をスキップできます。(カスタム・ストアを使用する理由は何でしょうか。カスタム・ストアにより、チューニングと管理の柔軟性が高まります。また、デフォルト・ファイル・ストアは移行できません。

2. 各ストアをクラスタに割り当てます。クラスタを使用しない場合、各ストアをそのホスト・サーバーに直接ターゲット指定します。

移行可能なターゲットを使用するかわりに、クラスタをターゲットとして指定されたJMSアーティファクトを、高可用性設定で使用することをお薦めします。「簡略化されたJMSクラスタと高可用性の構成」を参照してください

3. 各WebLogicサーバーでJMSサーバーを構成します。ステップ1で作成されたストアを参照するようにJMSサーバーを構成します。ストアに使用されたターゲットにJMSサーバーをターゲット指定します。複数のJMSサーバーで同じストアを参照できます。

4. 各JMSサーバーでメッセージ数の割当てを構成します。デフォルトの割当てがないため、割当てを構成すると、メモリー不足状況の防止に役立ちます。経験則によれば、従来、各メッセージはページ・アウトする場合でも512バイトのメモリーを消費すると仮定されます。

5. JMSページングはデフォルトで有効ですが、デフォルトの動作が環境に対して有効であることを確認します。

JMSモジュールの構成

同種のJMSサーバーのセットは、分散ポリシーが「Distributed」に設定された、クラスタをターゲットとして指定された単一JMSサーバーか、それぞれが同じ分散宛先をホストするように同様に構成されたJMSサーバーのセットになります。同種のJMSサーバーごとに、JMSモジュールと単一の関連サブデプロイメントを構成します。

1. システム・モジュールを作成します。そのモジュールを、単一クラスタ(クラスタを使用する場合)または単一WebLogicサーバー・インスタンスにターゲット指定します。サブデプロイメントを利用する場合も常にモジュールをターゲット指定する必要があります。

注意:

- ほとんどの場合、デプロイ可能なアプリケーション・モジュールではなく、システム・モジュールを常に使用することをお薦めします。システム・モジュールは、WebLogic Server管理コンソール、JMX API (Java MBean)、またはWLSTを使用して作成できますが、デプロイ可能なモジュール用の同等のツールはありません。デプロイ可能なモジュールを変更するには、XMLを手動で編集して再デプロイするしかありません。

- JMSリソース定義でなくシステム・モジュール構成を常に使用することをお薦めします。システム・モジュールを使用した接続ファクトリおよび宛先の構成は、通常、アプリケーションにハード・コードされた構成よりずっと柔軟で保守性がよく、移植も容易です。

2. モジュールにつき厳密に1つのサブデプロイメントを作成します。サブデプロイメントは、WebLogic Server管理コンソールでは「高度なターゲット指定」と呼ばれる場合もあります。1つのサブデプロイメントにより、簡単になります。つまり、サード・パーティによるターゲット指定が理解しやすくなり、構成エラーが生じる可能性が少なくなります。1つのサブデプロイメントで十分でない場合は2つのモジュールを作成します。

3. サブデプロイメントはJMSサーバー(WebLogicサーバーではない)にのみ移入します。宛先をホストするJMSサーバーのみになります。これにより、JMSリソースを構成する際に、リソースが正しいJMSサーバーにターゲット指定されます。
.非分散宛先をサポートするモジュールの場合、サブデプロイメントは単一のJMSサーバーのみを参照する必要があります。分散宛先と非分散宛先が混在している場合は、2つのモジュール(それぞれに各自のサブデプロイメントが含まれる)を使用します

分散宛先を持つサブデプロイメントをサポートするモジュールの場合は、分散ポリシーが「Distributed」に設定されている、クラスタをターゲットとして指定された単一JMSサーバーを常に選択してください。

分散宛先と非分散宛先が混在している場合、2つのモジュール(それぞれに各自のサブデプロイメントが含まれる)を使用します。

JMSリソースの構成

JMSリソースを構成し、そのリソースを適切にターゲット指定します。

1. 宛先を作成し、その宛先を1つのサブデプロイメント(コンソールでは「高度なターゲット指定」と呼ばれる)にターゲット指定します。複数のJMSサーバーに解決するサブデプロイメント・ターゲットにターゲット指定できるのは分散宛先のみです。分散宛先、スタンドアロン宛先、インポート宛先が混在している場合は、2つのモジュール(それぞれに各自のサブデプロイメントが含まれる)を使用します。「ターゲット指定のベスト・プラクティス」を参照してください

2. カスタム接続ファクトリを作成し、デフォルト接続ファクトリのかわりに使用します。デフォルト接続ファクトリは調整できません。

ほとんどの場合、デフォルトのターゲット指定ではリソースがモジュールのターゲットを継承するため、デフォルトのターゲット指定と接続ファクトリを一緒に使用できます。リモート・クライアントでのみ使用される接続ファクトリの場合、モジュールのサブデプロイメント・ターゲットを使用します。

3. 接続ファクトリのマップされないリソース参照のモードを、デフォルト値「ReturnDefault」のままにしておくのではなく、「FailSafe」に設定します。値を「FailSafe」にすると、アプリケーションはマップされないリソース参照を確実に使用しません。詳細は、Oracle WebLogic Serverリリース・ノートのマップされない接続ファクトリ・リソースの動作変更を参照してください。
マップされないリソース参照モードの設定の詳細は、「接続ファクトリのマップされないリソース参照モードの指定」を参照してください。

SAFエージェント、ストア、インポート宛先の構成

SAFエージェントとそのストア、およびそのインポート宛先は、JMSサーバーとそのストア、およびJMS宛先と同じベスト・プラクティスに従う必要があります。SAFエージェントは移行可能ターゲットを使用できないため、クラスタでSAFエージェントをターゲット指定しないでください。

ターゲット指定のベスト・プラクティス

JMSリソースには次のターゲット指定のガイドラインをお薦めします。

- デフォルトのターゲット指定、WebLogicサーバーのターゲット指定、宛先を含むクラスタのターゲット指定は避けてください。宛先には高度なターゲット指定(サブデプロイメントのターゲット指定)を使用し、サブデプロイメントがJMSサーバーまたはSAFエージェントのみを参照するようにします。これは、非分散宛先、分散宛先、インポート宛先を含むすべての宛先タイプに適用されます。
ドメインの現在のJMSサーバーまたはSAFエージェントのみが特定のアプリケーションに使用される場合でも、次の理由によりこれがベスト・プラクティスとなります。

- 現在のアプリケーションに関連しない新しいJMSサーバーまたはSAFエージェントは、他のアプリケーション、Webサービス、またはサード・パーティ製品で導入できます。

- 今後、アプリケーションでは、スケーラビリティや管理上の目的で異なる宛先や異なるJMSサーバーまたはSAFエージェントが必要になります。

- Webサービス・デプロイメントおよびエラー・キューを構成する場合は常に高度なターゲット指定を使用します。これは、開発環境と本番環境のどちらも該当します。

- 分散キュー内でエラー宛先を使用するには、その親の宛先と同じサブデプロイメントにエラー宛先をターゲット指定する必要があります。

- ほとんどの場合、デフォルトのターゲット指定ではリソースがモジュールのターゲットを継承するため、デフォルトのターゲット指定と接続ファクトリを一緒に使用できます。リモート・クライアントでのみ使用される接続ファクトリの場合、モジュールのサブデプロイメント・ターゲットを使用します。

- クラスタ化されたJMSサーバーは、すべてのWebLogic JMS機能(順序単位、シングルトン宛先、ストア・アンド・フォワード・エージェントなど)をサポートするわけではありませんが、構成を簡略化し、WebLogicメッセージング・リソースの規模をアプリケーションで容易に変更できるようにするために、その使用を検討してください。「簡略化されたJMSクラスタ構成」を参照してください

統合およびマルチドメインのベスト・プラクティス

次の項では、WebLogic Serverを使用する統合環境とマルチドメイン環境のベスト・プラクティス情報を示します。

- リモートWebLogicクラスタまたはサーバーの宛先と通信するサーバー側アプリケーションの場合は、Oracle WebLogic Server JMSアプリケーションの開発のリモートJMSプロバイダの統合を参照してください。

- 相互運用WebLogic Serverドメインには次の制限事項があります。

- ドメイン名は一意にします。

- WebLogicサーバー名は、2つの異なるドメインにある場合でも一意にします。

- JMSサーバー名は、2つの異なるドメインにある場合でも一意にします。

- 相互運用ドメインには、セキュリティ上の特殊な注意事項があります。

- AQ JMSと相互運用するアプリケーションについては、「Oracle AQ JMSとの相互運用」を参照してください

- ドメインを構成してドメイン間トランザクションを有効にするには、Oracle WebLogic Server JTAアプリケーションの開発のドメイン間トランザクションに対する通信の構成を参照してください。

WebLogic JMSクライアント・オプションの理解

クライアント・アプリケーション(WebLogic Serverに依存しないランタイム環境のアプリケーション)の場合、Java、.NET、Cクライアントなどの複数のJMSクライアント・オプションがあります。Oracle WebLogic Serverスタンドアロン・クライアントの開発のJMSクライアントを参照してください。

注意:

WebLogic JMSクライアントは、外部トランザクション・マネージャを直接サポートしません。可能な場合、WebLogic TMを使用します。上級ユーザーの場合、トランザクション・サブシステムの割込みトランザクション・マネージャ機能をXAリソースとして使用できます。

WebLogic URLの理解

リモートWebLogic Serverインスタンスまたはクラスタと通信するアプリケーションは、サーバーやクラスタに接続する場合、JNDI InitialContextオブジェクトの作成時またはアプリケーション属性の設定時(あるいはその両方)にURLを指定する必要があります。

- JMSリソースと同じサーバーやクラスタで実行するアプリケーションのURLを指定しないでください。最初のコンテキストがURLを指定せずに作成されると、ローカル・サーバーまたはクラスタJNDIが自動的に参照されます。

- URLが複数のアドレスに解決する場合、WebLogic Serverクライアントはリスト内のアドレスをランダムに選択して開始し、成功するまで順番に各アドレスを自動で試行します。

- 本番システムでは、「URL構文」に示す複数のホスト/ポートURL表記を使用せず、最初のホスト名解決にDNSラウンド・ロビンやハードウェア・ロード・バランサを使用することを検討します

URL構文

WebLogic URL構文は次のようになります。

[t3|t3s|http|https|iiop|iiops]://address[,address]...

説明:

- address = hostlist : portlist

- hostlist = hostname [,hostname]...

- portlist = portrange [+portrange]...

- portrange = port [-port]

port-portを使用してポート範囲を示し、+で複数のポート範囲を分割します。たとえば、簡単なアドレスは、通常t3://hostA:7001のようになります。アドレスt3://hostA,hostB:7001-7002は、次のアドレスに相当します。

- t3://hostA,hostB:7001+7002

- t3://hostA:7001-7002,hostB:7001-7002

- t3://hostA:7001+7002,hostB:7001+7002

- t3://hostA:7001,hostA:7002,hostB:7001,hostB:7002

厳密なメッセージの順序付けのベスト・プラクティス

厳密に順序付けられたメッセージ処理が必要な場合、アプリケーションの設計と構成で、この要件を慎重に考慮する必要があります。

WebLogic JMS順序単位機能を利用する方法が最も簡単で効率的です。この方法では、通常、アプリケーションの変更は最小限(あるいは変更なし)で済みます。さらに、分散宛先、スケジュール済メッセージ、遅延メッセージ、トランザクション、ストア・アンド・フォワードとともに機能します。『Oracle WebLogic Server JMSアプリケーションの開発』のメッセージ順序単位の使用に関する項を参照してください。

高可用性のベスト・プラクティス

高可用性(HA)またはスケーラビリティが気になる場合、クラスタ化されたWebLogic機能を利用するようにアプリケーションを開発します。非クラスタ・アプリケーションからクラスタ・アプリケーションへの変更は一般的に困難なプロセスであるため、これは初期構成およびアプリケーションの設計段階で行われる最適な手段になります。

WebLogic JMSでは、メッセージは、宛先のホストJMSサーバーが実行している場合のみ利用できます。メッセージが中央の永続ストアにある場合、最初にメッセージを格納したサーバーがメッセージにアクセスできる唯一のJMSサーバーになります。WebLogicには、障害後にJMSサーバーを自動的に再起動または移行(あるいはその両方)する機能があります。また、同じクラスタ内の複数のJMSサーバー間で宛先をクラスタリング(分散)する機能もあります。

通常、HAは次の両方を使用することで実現します。

- 分散宛先

- HAサーバー/サービス。サーバーの全体移行または自動サービス移行のいずれかを使用して、JMSサーバーを自動的に再起動または移行(あるいはその両方)できます。

分散キューと分散トピック

分散キューは、通常、任意のクラスタ化されたキューイング使用例に対してかなり容易に適用できます。分散トピックは、次のような場合に最も適しています。

- サブスクライバが非恒久である場合。

- または、MDBを使用してサブスクライブする場合(直接的な非恒久サブスクライバには制限があり、最新の拡張要素を使用する必要があることがあります)。

Oracle WebLogic ServerメッセージドリブンBeanの開発のJMSトピックを使用したMDBの構成とデプロイメントと、Oracle WebLogic Server JMSアプリケーションの開発の分散宛先の使用を参照してください。

JMS外部サーバーの構成

JMS外部サーバーの構成で、次の内容を指定します。

- oracle.jms.AQjmsInitialContextFactoryをJNDI初期コンテキスト・ファクトリとして指定します。

- アプリケーション環境に必要なJDBCデータ・ソースを構成します。

詳細は、次を参照してください。

- 外部サーバー・リソースからサード・パーティJMSプロバイダへのアクセスの構成

- Oracle WebLogic Server管理コンソール・オンライン・ヘルプの外部サーバーの構成

JMSのパフォーマンスとチューニング

次のリンクには、WebLogic JMSのチューニング時に考慮する項目のチェックリストが記載されています。

- Oracle WebLogic ServerのパフォーマンスのチューニングのJMSのパフォーマンスとチューニングのチェックリストを参照してください。

11 WebLogic JMSのトラブルシューティング

この章では、WebLogic Server 12.1.3でのWebLogic JMSのメッセージおよび構成のトラブルシューティングの方法について説明します。

この章の内容は次のとおりです。

- JMSの通知の構成

- JMSのデバッグ

- メッセージ・ライフ・サイクルのロギング

- JMSメッセージ・ログの内容

- 宛先でのメッセージ処理の制御

JMS統計のモニターとJMSメッセージの管理の詳細は、「JMS統計のモニターとメッセージの管理」を参照してください。

JMSの通知の構成

「通知」は、監視ルールの評価がtrueとなった場合にトリガーされるアクションです。JMS通知は、関連する監視のトリガーに応じてJMSトピックまたはJMSキューにメッセージをポストするために使用します。システム・リソース構成ファイルの<destination-jndi-name>要素と<connection-factory-jndi-name>要素で、メッセージの配信方法を定義します。

詳細は、Oracle WebLogic Server診断フレームワークの構成と使用の通知の構成を参照してください。

JMSのデバッグ

特定のアプリケーションに問題があると突き止めたら、WebLogic Serverのデバッグ機能をアクティブ化して、アプリケーション内の特定の問題を探し当てることができます。

デバッグの有効化

デバッグは、適切なServerDebug構成属性をtrueに設定することで有効化できます。必要に応じて、サーバーのStdoutSeverityをDebugに設定することもできます。

構成属性は、以下のいずれかの方法で変更できます。

コマンド・ラインを使用してデバッグを有効化する

コマンド・ラインで適切なプロパティを設定します。例:

-Dweblogic.debug.DebugJMSBackEnd=true
-Dweblogic.log.StdoutSeverity="Debug"

この方法は静的なものであり、サーバーの起動時にのみ使用できます。

WebLogic Server管理コンソールを使用してデバッグを有効化する

WebLogic Server管理コンソールを使用して、デバッグ値を設定します。

1. WebLogic Server管理コンソールのチェンジ・センターで「ロックして編集」をクリックします(まだ行っていない場合) (Oracle WebLogic Serverの理解のチェンジ・センターの使用を参照してください)。

2. 管理コンソールの左ペインで、「環境」を展開して「サーバー」を選択します。

3. 「サーバーのサマリー」ページで、デバッグを有効化または無効化するサーバーをクリックして、そのサーバーの設定ページを開きます。

4. 「デバッグ」をクリックします。

5. 「デフォルト」を展開します。

6. 変更するデバッグ・スコープまたは属性のチェック・ボックスを選択します。

7. 「有効化」(または「無効化」)を選択して、選択したデバッグ・スコープまたは属性を有効化(または無効化)します。

8. WebLogic Server管理コンソールのチェンジ・センターで「変更のアクティブ化」をクリックしてこれらの変更をアクティブ化します。

すべての変更が即座に有効になるわけではありません。再起動が必要なものもあります(Oracle WebLogic Serverの理解のチェンジ・センターの使用を参照)。

この方法は動的なものであり、サーバーの実行中にデバッグを有効化するのに使用できます。

WebLogic Scripting Toolを使用してデバッグを有効化する

WebLogic Scripting Tool (WLST)を使用してデバッグ値を設定します。たとえば、次のコマンドでは、debug.pyというデバッグ値を設定するためのプログラムが実行されます。

java weblogic.WLST debug.py

メイン・スコープであるweblogicはグラフィックには表示されません。jmsはweblogic内のサブ・スコープです。DebugJMSBackEndの完全修飾されたDebugScopeは、weblogic.jms.backendです。

debug.pyプログラムには、以下のコードが含まれています。

user='user1'
password='password'
url='t3://localhost:7001'
connect(user, password, url)
edit()
cd('Servers/myserver/ServerDebug/myserver')
startEdit()
set('DebugJMSBackEnd','true')
save()
activate()

JavaからもWLSTを使用することができます。次の例では、デバッグ値の設定に使用されるJavaファイルを示します。

import weblogic.management.scripting.utils.WLSTInterpreter;
import java.io.*;
import weblogic.jndi.Environment;
import javax.naming.Context;
import javax.naming.InitialContext;
import javax.naming.NamingException;

public class test {
public static void main(String args[]) {
try {
WLSTInterpreter interpreter = null;
String user="user1";
String pass="pw12ab";
String url ="t3://localhost:7001";
Environment env = new Environment();
env.setProviderUrl(url);
env.setSecurityPrincipal(user);
env.setSecurityCredentials(pass);
Context ctx = env.getInitialContext();

interpreter = new WLSTInterpreter();
interpreter.exec
("connect('"+user+"','"+pass+"','"+url+"')");
interpreter.exec("edit()");
interpreter.exec("startEdit()");
interpreter.exec
("cd('Servers/myserver/ServerDebug/myserver')");
interpreter.exec("set('DebugJMSBackEnd','true')");
interpreter.exec("save()");
interpreter.exec("activate()");

} catch (Exception e) {
System.out.println("Exception "+e);
}
}
}

WLSTの使用は動的な手法で、サーバーの実行中にデバッグを有効化するために使用できます。

config.xmlファイルへの変更

コンソール、WLST、またはコマンド・ラインでデバッグ特性を変更すると、その内容がconfig.xmlファイルに反映されます。

以下のconfig.xmlのサンプル(抜粋)に、トランザクション・デバッグのスコープ(複数のデバッグ属性)および1つのJMS属性を示します。

コード・リスト11-1 JMSのデバッグに関するスタンザのサンプル

<server>
<name>myserver</name>
<server-debug>
<debug-scope>
<name>weblogic.transaction</name>
<enabled>true</enabled>
</debug-scope>
<debug-jms-back-end>true</debug-jms-back-end>
</server-debug>
</server>

JMSのデバッグ・スコープ

次は、JMSの登録されたデバッグ・スコープです。

- DebugJMSBackEnd (スコープはweblogic.jms.backend) - JMSバック・エンドのデバッグ情報(分散宛先やJMS SAF用に使用される情報を含む)を出力します。

- DebugJMSFrontEnd (スコープはweblogic.jms.frontend) - JMSフロント・エンドのデバッグ情報(マルチキャスト用に使用される情報を含む)を出力します。

- DebugJMSCommon (スコープはw blogic.jms.common) - JMS共通メソッドのデバッグ情報(クライアントJMSプロデューサからの情報を含む)を出力します。

- DebugJMSConfig (スコープはweblogic.jms.config) - JMSの構成(バックエンド、分散宛先、外部サーバー)に関する情報を出力します。

- DebugJMSBoot (スコープはweblogic.jms.boot) - JMSサーバーが使用しているストアと、構成されている宛先に関するメッセージを起動時に出力します。

- DebugJMSDispatcher (スコープはweblogic.jms.dispatcher) - PeerGone()の発生回数に関する情報を出力します。

- DebugJMSDistTopic (スコープはweblogic.jms.config) - 分散トピックの情報と、主要なバインドおよびアンバインドの情報を出力します。

- DebugJMSPauseResume (スコープはweblogic.jms.pauseresume) - 宛先における処理の休止と再開(バックエンド)に関する情報を出力します。

- DebugJMSModule (スコープはweblogic.jms.module) - JMSモジュールの処理とメッセージ・ライフ・サイクルに関する多くの情報を出力します。

- DebugJMSMessagePath (スコープはweblogic.jms.messagePath) - メッセージ・パス(クライアント、フロントエンド、バックエンド)を経由するメッセージの追跡情報(メッセージIDを含む)を出力します。

- DebugJMSSAF (スコープweblogic.jms.saf) - JMS SAF (ストア・アンド・フォワード)宛先に関する情報を出力します。

- DebugJMSCDS (スコープはweblogic.jms.CDS) - JMSの「構成ディレクトリ・サービス」に関する詳細な情報を出力します(このサービスは、サーバーに構成されているJMSリソースの構成の変更を知らせる通知を、クラスタ内だけでなく複数のクラスタやドメインに渡る範囲から取得するために、様々なサブ・システムで使用されます)。

- DebugJMSWrappers (スコープはweblogic.jms.wrappers) - JMS接続、セッション、および他のオブジェクトの、プーリングとラッピングに関する情報を出力します(この情報はデプロイメント記述子のresource-reference要素を利用してEJB内またはサーブレット内で使用されます)。

メッセージング・カーネルとパス・サービスのデバッグ・スコープ

次は、メッセージング・カーネルとパス・サービスの登録されたデバッグ・スコープです。

- DebugMessagingKernel (スコープはweblogic.messaging.kernel): メッセージング・カーネルに関する情報を出力します。

- DebugMessagingKernelBoot (スコープはweblogic.messaging.kernelboot): メッセージング・カーネルの起動に関する情報(処理メッセージ)を出力します。

- DebugPathSvc (スコープはweblogic.messaging.pathsvc): パス・サービスにおける一部の異常な状況に関する限定された情報を出力します。

- DebugPathSvcVerbose (スコープは weblogic.messaging.pathsvcverbose): パス・サービスにおける異常な状況に関する限定された情報を出力します。

リクエストの仕分け

これ以外のデバッグ方法としては、JMSサブシステムを介して個々の(通常は「仕分けされた」)アプリケーション・リクエストのフローを追跡する方法があります。詳細は、Oracle WebLogic Server診断フレームワークの構成と使用のDyeInjectionモニターによるDye Vectorの構成を参照してください。

メッセージ・ライフ・サイクルのロギング

JMSロギングは、JMSサーバーを作成するとデフォルトで有効になります。しかし、このJMSサーバーにターゲット指定するJMSモジュールのメッセージ宛先(または宛先で使用するJMSテンプレート)では、JMSロギングを明示的に有効にする必要があります。WebLogicロギング・サービスの詳細は、Oracle WebLogic Serverログ・ファイルの構成とログ・メッセージのフィルタ処理のWebLogicロギング・サービスの理解を参照してください。

メッセージのライフ・サイクルとは、JMSメッセージがJMSサーバーに届いた後、JMS APIまたはJMSメッセージ管理APIを通じて、そのメッセージに順に発生するイベントを外側から見た概念です。メッセージ・ライフ・サイクルのロギングを利用することで、JMSサーバーから見たJMSメッセージの存在やステータスに関する情報に容易にアクセスできます。各メッセージ・ログには、メッセージの生成、消費、削除などの基本的なライフ・サイクル・イベントについての情報が含まれます。

ロギングは、長期間にわたって継続的に発生します。また、JMSサーバーの実行中にリアルタイム・モードで使用したり、JMSサーバーの停止中にオフライン形式で使用したりすることも可能です。メッセージ・ロギングの構成の詳細は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプの次のトピックを参照してください。

- ログの表示と構成

- JMSサーバー・メッセージのログ・ローテーションの構成

- トピック・メッセージのロギングの構成

- キューのメッセージ・ロギングの構成

- JMSテンプレート・メッセージのロギングの構成

- 共通分散トピック - メッセージ・ロギングの構成

- 「共通分散キュー - メッセージ・ロギングの構成」

JMSメッセージ・ライフ・サイクルのイベント

JMS宛先のメッセージ・ライフ・サイクルのロギングを有効にすると、メッセージが基本的なメッセージ・ライフ・サイクル・イベントに対応する条件を満たすたびに、JMSサーバーのメッセージ・ログ・ファイルにレコードが追加されます。JMSメッセージのログ・エントリは、以下のライフ・サイクル・イベントによってトリガーされます。

- 生成: このイベントは、WebLogic Server JMS APIまたはJMS Management APIを使用してメッセージがJMSサーバーに受信されたときにログに記録されます。

- 消費: このイベントは、WebLogic Server JMS APIまたはJMS Management APIを使用してメッセージがJMSサーバーから送信されたときにログに記録されます。

- 削除: このイベントは、WebLogic Server JMS APIまたはJMS Management APIを使用してメッセージがJMSサーバーから手動で削除されたときにログに記録されます。

- 期限切れ: このイベントは、メッセージがJMSサーバーに格納された有効期限に達したときにログに記録されます。メッセージを受信したトピック・サブスクライバごとに別々に期限切れイベントが発生しても、イベントが複数回ログに記録されることはありません。

- 再試行超過: このイベントは、メッセージが再配信の再試行制限を超えたときにログに記録されます。トピック・サブスクライバごとに再配信回数が異なる場合は、このイベントが1つのメッセージについて複数回記録されることもあります。

- コンシューマ作成: このイベントは、キューのJMSコンシューマが作成されるか、トピックのJMS恒久サブスクライバが作成されたときにログに記録されます。

- コンシューマ破棄: このイベントは、JMSコンシューマがクローズされるか、トピックのJMS恒久サブスクライバがアンサブスクライブされたときにログに記録されます。

メッセージ・ログの場所

メッセージ・ログは、ドメイン・ディレクトリ内の次の場所に格納されます。

USER_DOMAIN\servers\servername\logs\jmsServers\jms_server_name\jms.messages.log

USER_DOMAINはドメインのルート・ディレクトリ(通常はc:\Oracle\Middleware\user_projects\domains\USER_DOMAIN)です。これは、WebLogic Serverプログラム・ファイルが格納されるディレクトリ(通常はc:\Oracle\Middleware\wlserver_10.3)に対応するディレクトリです。

JMSメッセージ・ロギングの有効化

キュー、トピック、JMSテンプレート、共通分散キュー、および共通分散トピックのJMSメッセージ・ロギングは、WebLogic Server管理コンソールを使用して有効にしたり無効にしたりできます。詳細は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプの次のトピックを参照してください。

- トピック・メッセージのロギングの構成

- キューのメッセージ・ロギングの構成

- JMSテンプレート・メッセージのロギングの構成

- 共通分散トピック - メッセージ・ロギングの構成

- 「共通分散キュー - メッセージ・ロギングの構成」

WebLogic Java Management Extensions (JMX)を使用すると、JMSメッセージ・ログを管理するためのJMSSystemResourceMBeanおよびJMSRuntimeMBeanのMBeanにアクセスできます。詳細は、Oracle WebLogic Server JMXによるカスタム管理ユーティリティの開発のWebLogic ServerサブシステムMBeanの概要を参照してください。

注意:

非恒久サブスクリプションのJMSメッセージ・ロギングは、デフォルト構成では有効化されていません。有効化するには、システム・プロパティweblogic.jms.message.logging.logNonDurableSubscriber=trueを設定します。

JMSサーバーおよびJMSシステム・リソースのJMSメッセージ・ロギングは、WebLogic Scripting Toolを使用して構成することもできます。詳細は、「WLSTを使用したJMSサーバーとJMSシステム・モジュール・リソースの管理」を参照してください。

メッセージ・ロギングを有効にする際は、メッセージ・ヘッダー・フィールド、システム定義のメッセージ・プロパティ、およびユーザー定義のプロパティのそれぞれについて、ログ・エントリにそのすべてを含めるか一部のみを含めるかを指定できます。また、メッセージの本文を含めることも、除外することもできます。メッセージのヘッダーとプロパティの詳細は、Oracle WebLogic Server JMSアプリケーションの開発の基本的なJMSアプリケーションの開発を参照してください。

JMSメッセージ・ログの内容

ログに追加される各レコードには、メッセージに関する基本的な情報(メッセージID、メッセージの件名の相関IDなど)が含まれます。JMSサーバーを構成して、メッセージの種類やユーザー・プロパティなどの追加情報を含めることもできます。

JMSメッセージ・ログ・レコードのフォーマット

特に注記のない限り、JMSメッセージ・ライフ・サイクル・ログに追加されるすべてのレコードには、以下の情報が以下に列挙した順序で記録されます。

- 日付: このメッセージのログ・レコードが生成された日時。

- トランザクション識別子: メッセージが関連付けられているトランザクションのトランザクション識別子

- WLS診断コンテキスト: システム内を流れるリクエストまたは作業単位の一意の識別子。この情報がJMSメッセージ・ログに含まれているのは、同じリクエストに属すイベント間の相関性を示すためです。

- 「日付」のミリ秒未加工値: メッセージ・ログ・レコードが生成された日時をミリ秒で表した値。トラフィック量の多いアプリケーションでのトラブルシューティングに使用します。

- 「日付」のナノ秒未加工値: メッセージ・ログ・レコードが生成された日時をナノ秒で表した値。トラフィック量の多いアプリケーションでのトラブルシューティングに使用します。

- JMSメッセージID: メッセージに割り当てられた一意の識別子。

- JMS相関ID: メッセージのユーザー定義の識別子。通常は件名が同じメッセージの相関に使用します。

- JMS宛先名: メッセージの宛先サーバーの完全修飾名。

- JMSメッセージ・ライフ・サイクル・イベント名: ログ・エントリをトリガーしたメッセージ・ライフ・サイクル・イベントの名前。

- JMSユーザー名: メッセージを生成、消費、または受信したユーザーの名前。

- JMSメッセージ・コンシューマ識別子 - この情報は、ログに記録されたメッセージ・ライフ・サイクル・イベントが、「消費」イベント、「コンシューマ作成」イベント、または「コンシューマ破棄」イベントである場合にのみログに含まれます。メッセージがキュー上で消費された場合は、コンシューマの起点と、JMSサーバーで識別されたコンシューマのOAM識別子に関する情報がログに含まれます。コンシューマが恒久サブスクライバである場合は、ログに接続のクライアントIDとサブスクリプション名も含まれます。
メッセージ・コンシューマ識別子の構文は次のとおりです。

MC:CA(…):OAMI(wls_server_name.jms.connection#.session#.consumer#)

説明:

- MCはメッセージ・コンシューマを表します。

- CAはクライアント・アドレスを表します。

- OAMIはOA&M識別子を表します。

- CCは接続コンシューマを表します(適用される場合のみ)。

コンシューマが恒久サブスクライバの場合は、追加情報が次の構文で表示されます。

DS:client_id.subscription_name[message consumer identifier]

DSは恒久サブスクライバを表します。

- JMSメッセージ・コンテンツ: 宛先ごとにカスタマイズ可能なフィールド。ただし、メッセージの本文は使用できません。

- JMSメッセージ・セレクタ: この情報は、ログに記録されたメッセージ・ライフ・サイクル・イベントが「コンシューマ作成」イベントである場合にのみログに含まれます。ログには、JMS APIからのselector引数が表示されます。

サンプル・ログ・ファイル・レコード

以下に示すサンプル・ログ・ファイル・レコードで、各メッセージ・ライフ・サイクル・イベントでログ・ファイルに記録される情報の種類を示します。各レコードは固定長ですが、イベントとの関連性やレコード内の各フィールドに有効な値が存在するかどうかに応じて含まれる情報が異なります。ログ・ファイル・レコードの構文は次のとおりです。

####<date_and_time_stamp> <transaction_id> <WLS_diagnostic_context>
<date_in_milliseconds> <date_in_nanoseconds> <JMS_message_id>
<JMS_correlation_id> <JMS_destination_name> <life_cycle_event_name>
<JMS_user_name> <consumer_identifier> <JMS_message_content>
<JMS_message_selector>

注意:

ログ・ファイルにJMSメッセージのコンテンツを含めることを選択する場合は、メッセージのコンテンツ内のすべての左向きの山カッコ(<)と右向きの山カッコ(>)がエスケープされる点に注意してください。ログ・ファイルでは、左向きの山カッコのかわりに"&lt;"、右向きの山カッコのかわりに"&gt;"が表示されます。

コンシューマ作成イベント

####<May 13, 2005 4:06:33 PM EDT> <> <> <1116014793818> <345063> <> <>
<jmsfunc!TestQueueLogging> <ConsumerCreate> <system> <MC:CA(/10.61.6.56):OAMI(myserver.jms.connection456.session460.consumer462)> <> <>

コンシューマ破棄イベント

####<May 13, 2005 4:06:33 PM EDT> <> <> <1116014793844> <40852> <> <>
<jmsfunc!TestQueueLogging> <ConsumerDestroy> <system> <MC:CA(/10.61.6.56):OAMI(myserver.jms.connection456.session460.consumer462)> <> <>

メッセージ生成イベント

####<May 13, 2005 4:06:43 PM EDT> <> <> <1116014803018> <693671> <ID:<327315.1116014803000.0>> <testSendRecord> <jmsfunc!TestQueueLoggingMarker>
<Produced> <system> <> <&lt;?xml version="1.0" encoding="UTF-8"?&gt;
&lt;mes:WLJMSMessage
xmlns:mes="http://www.bea.com/WLS/JMS/Message"&gt;&lt;mes:Header&gt;&lt;mes:JMSCor
relationID&gt;testSendRecord&lt;/mes:JMSCorrelationID&gt;&lt;mes:JMSDeliveryMode
&gt;NON_PERSISTENT&lt;/mes:JMSDeliveryMode&gt;&lt;mes:JMSExpiration&gt;0&lt;
/mes:JMSExpiration&gt;&lt;mes:JMSPriority&gt;4&lt;/mes:JMSPriority&gt;&lt;
mes:JMSRedelivered&gt;false&lt;/mes:JMSRedelivered&gt;&lt;mes:JMSTimestamp&gt;
1116014803000&lt;/mes:JMSTimestamp&gt;&lt;mes:Properties&gt;&lt;mes:property
name="JMSXDeliveryCount"&gt;&lt;mes:Int&gt;0&lt;/mes:Int&gt;&lt;/mes:property
&gt;&lt;/mes:Properties&gt;&lt;/mes:Header&gt;&lt;mes:Body&gt;&lt;mes:Text/&gt;
&lt;/mes:Body&gt;&lt;/mes:WLJMSMessage&gt;> <>

メッセージ消費イベント

####<May 13, 2005 4:06:45 PM EDT> <> <> <1116014805137> <268791> <ID:<327315.1116014804578.0>> <hello> <jmsfunc!TestQueueLogging> <Consumed> <system>
<MC:CA(/10.61.6.56):OAMI(myserver.jms.connection456.session475.consumer477)> <&lt;?xml version="1.0" encoding="UTF-8"?&gt;
&lt;mes:WLJMSMessage
xmlns:mes="http://www.bea.com/WLS/JMS/Message"&gt;&lt;mes:Header&gt;&lt;mes:
JMSCorrelationID&gt;hello&lt;/mes:JMSCorrelationID&gt;&lt;mes:JMSDeliveryMode
&gt;PERSISTENT&lt;/mes:JMSDeliveryMode&gt;&lt;mes:JMSExpiration&gt;0&lt;/mes:
JMSExpiration&gt;&lt;mes:JMSPriority&gt;4&lt;/mes:JMSPriority&gt;&lt;mes:
JMSRedelivered&gt;false&lt;/mes:JMSRedelivered&gt;&lt;mes:JMSTimestamp&gt;
1116014804578&lt;/mes:JMSTimestamp&gt;&lt;mes:JMSType&gt;SendRecord&lt;/mes:
JMSType&gt;&lt;mes:Properties&gt;&lt;mes:property name="JMS_BEA_RedeliveryLimit"&gt;&lt;mes:Int&gt;1&lt;/mes:Int&gt;&lt;/mes:property&gt;&lt;mes:
property name="JMSXDeliveryCount"&gt;&lt;mes:Int&gt;1&lt;/mes:Int&gt;&lt;/mes:property&gt;
&lt;/mes:Properties&gt;&lt;/mes:Header&gt;&lt;mes:Body&gt;&lt;mes:Text/&gt;&lt;/mes:Body&gt;&lt;/mes:WLJMSMessage&gt;> <>

メッセージ期限切れイベント

####<May 13, 2005 4:06:47 PM EDT> <> <> <1116014807258> <445317>
<ID:<327315.1116014807234.0>> <bar> <jmsfunc!TestQueueLogging> <Expired> <<WLS
Kernel>> <> <&lt;?xml version="1.0" encoding="UTF-8"?&gt;
&lt;mes:WLJMSMessage
xmlns:mes="http://www.bea.com/WLS/JMS/Message"&gt;&lt;mes:Header&gt;&lt;mes:
JMSCorrelationID&gt;bar&lt;/mes:JMSCorrelationID&gt;&lt;mes:JMSDeliveryMode&gt;
PERSISTENT&lt;/mes:JMSDeliveryMode&gt;&lt;mes:JMSExpiration&gt;1116014806234
&lt;/mes:JMSExpiration&gt;&lt;mes:JMSPriority&gt;4&lt;/mes:JMSPriority&gt;&lt;
mes:JMSRedelivered&gt;false&lt;/mes:JMSRedelivered&gt;&lt;mes:JMSTimestamp&gt;
1116014807234&lt;/mes:JMSTimestamp&gt;&lt;mes:JMSType&gt;ExpireRecord&lt;/mes:
JMSType&gt;&lt;mes:Properties&gt;&lt;mes:property name="JMS_BEA_RedeliveryLimit"&gt;&lt;mes:Int&gt;1&lt;/mes:Int&gt;&lt;/mes:property&gt;&lt;mes:
property name="JMSXDeliveryCount"&gt;&lt;mes:Int&gt;0&lt;/mes:Int&gt;&lt;/mes:property&gt;
&lt;/mes:Properties&gt;&lt;/mes:Header&gt;&lt;mes:Body&gt;&lt;mes:Text/&gt;&lt;/mes:Body&gt;&lt;/mes:WLJMSMessage&gt;> <>

再試行超過イベント

####<May 13, 2005 4:06:53 PM EDT> <> <> <1116014813491> <394206> <ID:<327315.1116014813453.0>> <bar> <jmsfunc!TestQueueLogging> <Retry exceeded>
<<WLS Kernel>> <> <&lt;?xml version="1.0" encoding="UTF-8"?&gt;
&lt;mes:WLJMSMessage xmlns:mes="http://www.bea.com/WLS/JMS/Message"&gt;&lt;mes:Header&gt;&lt;mes:
JMSCorrelationID&gt;bar&lt;/mes:JMSCorrelationID&gt;&lt;mes:JMSDeliveryMode&gt;
PERSISTENT&lt;/mes:JMSDeliveryMode&gt;&lt;mes:JMSExpiration&gt;0&lt;/mes:
JMSExpiration&gt;&lt;mes:JMSPriority&gt;4&lt;/mes:JMSPriority&gt;&lt;mes:
JMSRedelivered&gt;true&lt;/mes:JMSRedelivered&gt;&lt;mes:JMSTimestamp&gt;
1116014813453&lt;/mes:JMSTimestamp&gt;&lt;mes:JMSType&gt;RetryRecord&lt;/mes:
JMSType&gt;&lt;mes:Properties&gt;&lt;mes:property name="JMS_BEA_RedeliveryLimit"&gt;&lt;mes:Int&gt;1&lt;/mes:Int&gt;&lt;/mes:property&gt;&lt;mes:
property name="JMSXDeliveryCount"&gt;&lt;mes:Int&gt;2&lt;/mes:Int&gt;&lt;/mes:property
&gt;&lt;/mes:Properties&gt;&lt;/mes:Header&gt;&lt;mes:Body&gt;&lt;mes:Text/&gt;
&lt;/mes:Body&gt;&lt;/mes:WLJMSMessage&gt;> <>

メッセージ削除イベント

####<May 13, 2005 4:06:45 PM EDT> <> <> <1116014805071> <169809> <ID:<327315.1116014804859.0>> <hello> <jmsfunc!TestTopicLogging> <Removed>
<system> <DS:messagelogging_client.foo.SendRecordSubscriber> <&lt;?xml version="1.0" encoding="UTF-8"?&gt;
&lt;mes:WLJMSMessage xmlns:mes="http://www.bea.com/WLS/JMS/Message"&gt;&lt;mes:
Header&gt;&lt;mes:JMSCorrelationID&gt;hello&lt;/mes:JMSCorrelationID&gt;&lt;mes:
JMSDeliveryMode&gt;PERSISTENT&lt;/mes:JMSDeliveryMode&gt;&lt;mes:JMSExpiration
&gt;0&lt;/mes:JMSExpiration&gt;&lt;mes:JMSPriority&gt;4&lt;/mes:JMSPriority&gt;
&lt;mes:JMSRedelivered&gt;false&lt;/mes:JMSRedelivered&gt;&lt;mes:JMSTimestamp
&gt;1116014804859&lt;/mes:JMSTimestamp&gt;&lt;mes:JMSType&gt;
SendRecordSubscriber&lt;/mes:JMSType&gt;&lt;mes:Properties&gt;&lt;mes:property
name="JMSXDeliveryCount"&gt;&lt;mes:Int&gt;0&lt;/mes:Int&gt;&lt;/mes:property
&gt;&lt;/mes:Properties&gt;&lt;/mes:Header&gt;&lt;mes:Body&gt;&lt;mes:Text/&gt;&lt;/mes:Body&gt;&lt;/mes:WLJMSMessage&gt;> <>

JMSサーバー・ログ・ファイルの管理

JMSサーバーを作成したら、古いログ・メッセージを別のファイルに移動(ローテーション)するための条件を構成できます。また、ログ・ファイルのデフォルト名を変更することも可能です。

メッセージ・ログ・ファイルのローテーション

古いログ・メッセージは、特定のファイル・サイズや指定した時間間隔に基づいて、新しいファイルにローテーションできます。また、古いログ・メッセージのローテーションを実施しないことも選択できます。この場合は、すべてのメッセージが単一のファイルに蓄積され、ファイル・サイズが大きくなり過ぎたときにはその中身を削除する必要があります。

ログ・ファイルが特定のサイズに達したときに古いメッセージをローテーションする場合は、最小限のファイル・サイズを指定する必要があります。ログ・ファイルが指定の最小サイズに到達すると、サーバーが次回ファイル・サイズをチェックする際に、現在のログ・ファイルの名前が変更され、それ以降のメッセージを保存するための新規ログ・ファイルが作成されます。

定期的な間隔で古いメッセージをローテーションする場合は、最初の新しいログ・ファイルが作成された時間と、そのファイルの名前が変更されて置換されるまでの時間間隔を指定する必要があります。

JMSサーバーのログ・ファイルのローテーション設定については、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのJMSサーバー・メッセージのログ・ローテーションの構成を参照してください。

メッセージ・ログ・ファイル名の変更

ローテーションされたログ・ファイルは、作成順に番号付けされます。たとえば、7番目にローテーションされたファイルはmyserver.log00007という名前になります。トラブルシューティングを容易にするため、ログ・ファイルの名前を変更したり、ログ・ファイルがローテーションされた日時を含めたりできます。これを行うには、ファイル名にjava.text.SimpleDateFormat変数を追加します。それぞれの変数はパーセント記号(%)で囲みます。ログ・ファイルの名前の変更時に相対パス名を指定した場合、サーバーのルート・ディレクトリが基準と解釈されます。

JMSサーバーのメッセージ・ログ・ファイルの名前変更の詳細は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのJMSサーバー・メッセージのログ・ローテーションの構成を参照してください。

保存するメッセージ・ログ・ファイル数の制限

古いログ・ファイルをファイル・サイズまたは時間間隔に基づいてローテーションする場合は、古いメッセージの格納のためにJMSサーバーが作成するログ・ファイルの数を制限することもできます。この制限に達すると、最も古いログ・ファイルが削除され、最新の接尾辞の付いた新しいログ・ファイルが作成されます。このオプションを有効にしないと、新しいファイルがサーバーによって無限に作成されるため、必要に応じてこれらのファイルを手動で削除する必要があります。

JMSサーバーのメッセージ・ログ・ファイルの数の制限については、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのJMSサーバー・メッセージのログ・ローテーションの構成を参照してください。

宛先でのメッセージ処理の制御

WebLogic JMS構成および実行時APIを使用すると、メッセージの生成、挿入、および消費の処理を休止したり再開したりできます。休止および再開が可能なのは、JMS宛先または一時的な宛先、同じテンプレートを使用して構成された宛先のグループ、および単一のJMSサーバーによってホストされるすべての宛先において、プログラム的に(JMXや実行時MBean APIを使用して)または管理上の理由で(WebLogic Server管理コンソールを使用して)実行されるメッセージ処理です。外部リソースに障害が発生したとき、JMSサブシステムがメッセージの受け付けと配信(および再配信)を継続すると、システムに過度の負荷がかかることがあります。しかし、メッセージ処理を休止(および再開)することで、外部リソースの障害発生時のJMSサブシステムの動作を制御できます。

JMSサーバーおよび「休止」状態にあるその宛先を起動すると、それらの宛先でのメッセージの生成、挿入、または消費が起動後直ちに休止します。その後管理者が休止している宛先の状態を「再開」に変更すると、通常のメッセージ処理アクティビティ(生成、挿入、または消費)が再開します。また、新しい実行時オプションを使用すると、実行中の宛先の現在の状態を変更して、新しいメッセージの生成、挿入、または消費を許可または禁止できます。

- メッセージの生成_挿入_および消費の定義

- 生成の休止と生成の再開

- 挿入の休止と挿入の再開

- 消費の休止と消費の再開

- 処理中の作業とは

- 起動時のメッセージ処理の休止と再開の優先順位

- セキュリティ

メッセージの生成、挿入、および消費とは

宛先では、メッセージに対して様々な処理が実行されます。

- プロデューサが新しいメッセージを作成して宛先に送信すると、メッセージが生成されます。

- 処理中の作業が完了すると、メッセージが挿入されます。処理中の作業の完了とは、トランザクションのコミットにおいてメッセージが使用可能になったときや、宛先において遅延が使用可能になった後にメッセージが使用可能になるようにスケジューリングされたときです。

- メッセージが宛先から削除されると、そのメッセージが消費されます。

以下のセクションで説明するように、起動時または実行時にこれらの処理のいずれかまたはすべてを休止および再開できます。

休止と再開をロギングする

宛先でのメッセージの生成、挿入、または消費を、起動時または実行時に正常に「休止」または「再開」させると、そのことを示すメッセージがサーバー・ログに追加されます。宛先でのメッセージの生成、挿入、消費の休止または再開に失敗した場合は、適切なエラーまたは例外がログに記録されます。

生成の休止と生成の再開

JMS宛先での「生成が休止」されると、その宛先にアタッチされている新しいプロデューサと既存のプロデューサにおいて、その宛先に対する新しいメッセージを生成できなくなります。休止している宛先に対してプロデューサがメッセージを送信しようとすると、宛先が休止していることを示す例外が返されます。宛先で「休止していた生成が再開」されると、新しいメッセージの生成が再び許可されます。メッセージの生成の休止では、処理中の作業の結果であるメッセージの挿入は休止されません。

注意:

処理中の作業の構成要素については、「処理中の作業とは」を参照してください

起動時に生成を休止、再開する

起動時には、JMSサーバーのすべての宛先、同じJMSテンプレートを指す宛先のグループ、または個別の宛先での生成を休止または再開できます。production-paused-at-startupを構成した場合は、指定した宛先でのメッセージの生成アクティビティが次回のサーバー起動時に禁止され、その宛先の状態を明示的に「生成が有効化された」状態に変更するまで継続します。生成の再開を構成した場合は、指定した宛先でのメッセージの生成アクティビティが次回のサーバー起動時に許可され、その宛先の状態を明示的に「生成の休止」状態に変更するまで継続します。

WebLogic Server管理コンソールを使用して起動時のメッセージ生成を休止および再開する方法の詳細は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプの次のトピックを参照してください。

- 再起動時のJMSサーバー・メッセージ処理の休止

- サーバー再起動時のトピック・メッセージ処理の休止

- サーバー再起動時のキューのメッセージ処理の休止

- サーバー再起動時のJMSテンプレート・メッセージ処理の休止

- 共通分散トピック - サーバー再起動時のメッセージ処理の休止

- 共通分散キュー - サーバー再起動時のメッセージ処理の休止

注意:

この処理はレベル(JMSサーバー・レベル、JMSテンプレート・レベル、スタンドアロンの宛先レベル、共通分散宛先レベルなど)ごとに構成できるため、レベル間での優先順位が確立されています。詳細については、「起動時のメッセージ処理の休止と再開の優先順位」を参照してください

実行時に生成を休止、再開する

実行時には、JMSサーバーでターゲット指定されているすべての宛先、同じJMSテンプレートを指す宛先のグループ、または個別の宛先での生成を休止または再開できます。構成の変更がどのレベル(JMSサーバー・レベル、JMSテンプレート・レベル、または宛先レベル)で行われたかに関係なく、最も新しく変更された構成が常に優先されます。

実行時にメッセージ生成を休止および再開する方法については、Oracle WebLogic Server管理コンソール・オンライン・ヘルプの次に関する項を参照してください。

- 実行時のJMSサーバー・メッセージ処理の休止

- 実行時におけるトピック・メッセージ処理の休止

- 実行時におけるキュー・メッセージ処理の休止

生成の休止、再開と分散宛先

メンバー宛先での生成が休止されると、プロデューサによる生成において、そのメンバー宛先が考慮されなくなります。メッセージは、生成が可能な他のメンバー宛先に向けて送信されます。

生成の休止、再開とJMS接続の停止、開始

JMS接続を停止または開始しても、宛先の生成休止状態や生成再開状態には影響しません。

挿入の休止と挿入の再開

JMS宛先での「挿入」が休止されると、処理中の作業の結果として挿入されるメッセージと、プロデューサによって送信された新しいメッセージの両方が、宛先に現れなくなります。すべてのメッセージが宛先に現れないようにするには、挿入の休止を使用します。

処理中の作業が保留になっているかどうかを特定するには、WebLogic Server管理コンソールの統計を調べます。宛先でのメッセージの「挿入」を休止すると、処理中の作業完了に関係するメッセージが「配信不可」になり、新しいメッセージの生成処理が失敗します。コンシューマではこれらのメッセージがすべて「認識不可」になり、保留中でなくなったメッセージを反映するため統計が調整されます。

「挿入」の休止処理は、「生成」の休止処理よりも優先されます。つまり、宛先が現在「生成の休止」状態にある場合は、「挿入の休止」状態に変更できます。

処理中のメッセージが宛先に現れるようにするには、その宛先でのメッセージの挿入を明示的に「再開」する必要があります。挿入の「再開」処理が正常に完了すると、宛先が「挿入が有効化された」状態になり、「認識不可」だった処理中のメッセージがすべて認識可能になります。

起動時に挿入を休止、再開する

起動時には、JMSサーバーのすべての宛先、同じJMSテンプレートを指す宛先のグループ、または個別の宛先での挿入を休止または再開できます。insertion-paused-at-startupを構成した場合は、指定した宛先でのメッセージの挿入および生成アクティビティが次回のサーバー起動時に禁止され、その宛先の状態を明示的に「挿入が有効化された」状態に変更するまで継続します。挿入の再開を構成した場合は、指定した宛先でのメッセージの挿入アクティビティが次回のサーバー起動時に許可され、その宛先の状態を明示的に「挿入の休止」状態に変更するまで継続します。

起動時のメッセージ挿入の休止と再開の詳細は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプの次のトピックを参照してください。

- 再起動時のJMSサーバー・メッセージ処理の休止

- サーバー再起動時のトピック・メッセージ処理の休止

- サーバー再起動時のキューのメッセージ処理の休止

- サーバー再起動時のJMSテンプレート・メッセージ処理の休止

- 共通分散トピック - サーバー再起動時のメッセージ処理の休止

- 共通分散キュー - サーバー再起動時のメッセージ処理の休止

注意:

この処理はレベル(JMSサーバー・レベル、JMSテンプレート・レベル、宛先レベルなど)ごとに構成できるため、レベル間での優先順位が確立されています。詳細については、「起動時のメッセージ処理の休止と再開の優先順位」を参照してください

実行時に挿入を休止、再開する

実行時には、JMSサーバーのすべての宛先、同じJMSテンプレートを指す宛先のグループ、または個別の宛先での挿入を休止または再開できます。構成の変更がどのレベル(JMSサーバー・レベル、JMSテンプレート・レベル、または宛先レベル)で行われたかに関係なく、最も新しく変更された構成が常に優先されます。

実行時にメッセージ挿入を休止および再開する方法については、Oracle WebLogic Server管理コンソール・オンライン・ヘルプの次に関する項を参照してください。

- 実行時のJMSサーバー・メッセージ処理の休止

- 実行時におけるトピック・メッセージ処理の休止

- 実行時におけるキュー・メッセージ処理の休止

挿入の休止、再開と分散宛先

メンバー宛先での挿入が休止されると、メッセージの転送においてそのメンバー宛先が考慮されなくなります。メッセージは、挿入が可能な他のメンバー宛先に向けて送信されます。

挿入の休止、再開とJMS接続の停止、開始

JMS接続を停止または開始しても、宛先の挿入休止状態や挿入再開状態には影響しません。

消費の休止と消費の再開

JMS宛先での「消費が休止」されると、その宛先のメッセージが消費できなくなります。宛先が「消費の休止から再開」されると、その宛先にアタッチされている新しいコンシューマと既存のコンシューマが、その宛先のメッセージを再び消費できるようになります。

宛先での消費が休止されると、宛先の状態が「消費の休止」とマークされ、消費が再開されてメッセージが消費可能になるまで、すべての新しい同期受信処理がブロックされます。ブロッキング・タイムアウト処理を伴うすべての同期受信は、指定した時間の間ブロックされます。宛先での消費が休止している間は、その宛先にアタッチされている同期コンシューマへのメッセージは配信されません。

消費の「休止」処理が正常に行われた後、その宛先で消費処理を行えるようにするには、ユーザーが宛先を明示的に「再開」する必要があります。

起動時に消費を休止、再開する

起動時には、JMSサーバーのすべての宛先、同じJMSテンプレートを指す宛先のグループ、または個別の宛先での消費を休止または再開できます。consumption-paused-at-startupを構成した場合は、指定した宛先のメッセージの消費アクティビティが次回のサーバー起動時に禁止され、その宛先の状態を明示的に「消費が有効化された」状態に変更するまで継続します。消費の再開を構成した場合は、指定した宛先でのメッセージ消費アクティビティが次回のサーバー起動時に許可され、その宛先の状態を明示的に「消費の休止」状態に変更するまで継続します。

起動時の消費を休止および再開する方法については、Oracle WebLogic Server管理コンソール・オンライン・ヘルプの次のトピックを参照してください。

- 再起動時のJMSサーバー・メッセージ処理の休止

- サーバー再起動時のトピック・メッセージ処理の休止

- サーバー再起動時のキューのメッセージ処理の休止

- サーバー再起動時のJMSテンプレート・メッセージ処理の休止

- 共通分散トピック - サーバー再起動時のメッセージ処理の休止

- 共通分散キュー - サーバー再起動時のメッセージ処理の休止

実行時に消費を休止、再開する

実行時には、JMSサーバーのすべての宛先、同じJMSテンプレートを指す宛先のグループ、または個別の宛先での消費を休止または再開できます。構成の変更がどのレベル(JMSサーバー・レベル、JMSテンプレート・レベル、または宛先レベル)で行われたかに関係なく、最も新しく変更された構成が常に優先されます。

実行時に消費を休止および再開する方法については、Oracle WebLogic Server管理コンソール・オンライン・ヘルプの次に関する項を参照してください。

- 実行時のJMSサーバー・メッセージ処理の休止

- 実行時におけるトピック・メッセージ処理の休止

- 実行時におけるキュー・メッセージ処理の休止

消費の休止、再開とキュー・ブラウザ

キュー・ブラウザは、キュー宛先の「参照」のみが可能な特殊なタイプのコンシューマです。消費が休止されている宛先でも参照処理は禁止されません。

消費の休止、再開と分散宛先

消費が休止されているメンバー宛先は、コンシューマのロード・バランシング・アルゴリズムでは考慮されません。

消費の休止、再開とメッセージドリブンBean

宛先での消費を休止すると、メッセージドリブンBean (MDB)が関連する宛先からのメッセージを取得できなくなります。この機能を使用すると、接続の開始/停止を使用する場合と比較して、より柔軟に個別の宛先レベルからのMDBへのメッセージの配信を制御できます。つまり、消費の休止/再開機能を使用すると、JMS接続を複数のMDBで共有している場合でも、関連付けられた宛先での消費を休止することによって、特定のMDBへのメッセージの配信を禁止できるということです。

MDBの使用の詳細は、『Oracle WebLogic ServerメッセージドリブンBeanの開発』のJMSリソース停止中のメッセージ配信の中断の構成を参照してください。

消費の休止、再開とJMS接続の停止、開始

JMS接続の停止/開始機能では、コンシューマが受信APIを正常に呼び出したかどうかが判別されます。宛先での消費の休止/再開機能では、受信呼出しにおいて宛先からメッセージを取得したかどうかが判別されます。コンシューマの接続を停止または開始しても、宛先の消費の休止状態には影響しません。

宛先での消費が休止されている場合、コンシューマの接続が「停止」状態から「開始」に変更されると、同期受信処理がブロックされるかタイムアウトします。非同期コンシューマが関連付けられている宛先が「消費の休止」状態にあると、非同期コンシューマはメッセージを受信しません。

処理中の作業とは

- プロデューサに関連付けられる処理中の作業

- コンシューマに関連付けられる処理中の作業

プロデューサに関連付けられる処理中の作業

メッセージ・プロデューサに関連付けられた処理中の作業の結果として、宛先において次の種類のメッセージが挿入されます。

- 未生成のメッセージ: TimeToDeliverに設定された時間にプロデューサによって将来作成されることになっているメッセージ。未生成メッセージは、配信されるまでは宛先の統計で「保留中」のメッセージとしてカウントされ、消費することができません。

- 未コミット・メッセージ: ユーザー・トランザクションまたはトランザクション・セッションを使用してトランザクションの一環として生成されたメッセージのうち、まだコミットまたはロールバックされていないメッセージ。未コミット・メッセージは、トランザクションが完了するまでは宛先の統計で「保留中」のメッセージとしてカウントされ、消費することができません。

- 送信をブロックする割当て: 割当て制限のために初回には宛先に到達できなかった場合に、宛先が使用可能になるのを待機して一定時間ブロックするメッセージ。メッセージは宛先において、メッセージ割当て制限、バイト割当て制限、またはその両方を超える可能性があります。ブロック中にはこうしたメッセージはシステムから認識できないため、宛先の統計では一切カウントされません。

コンシューマに関連付けられる処理中の作業

メッセージ・コンシューマに関連付けられた処理中の作業の結果として、宛先において以下の種類のメッセージが挿入されます。

- 未応答(CLIENT ACK PENDING)メッセージ: クライアントによって受信されており、クライアントからの応答を待機しているメッセージ。この種のメッセージは「保留中のメッセージ」であり、確認応答を受信したときに宛先またはシステムから削除されます。

- 未コミット・メッセージ: クライアントによってトランザクション内で受信されているメッセージのうち、まだコミットまたはロールバックされていないメッセージ。この種のメッセージは、クライアントがそのトランザクションを正常にコミットしたときに、システムから削除されます。

- ロールバック・メッセージ: トランザクションが正常にロールバックされたために、宛先に戻されたメッセージ。
これらのメッセージは、関連する接続ファクトリ上で構成された再配信パラメータ(つまり、RedeliveryDelayおよび/またはRedeliveryDelayOverrideおよびRedeliveryLimit)や、ロールバック・リクエストが内部で非同期的に処理されるかに応じて、クライアントに対してただちに再配信できるかどうかが決まります。その結果、ロールバック・リクエスト後に呼出しがただちに実行される場合、ロールバック・リクエストへの消費操作件名に関連するメッセージは、コンシューマreceiveNoWait()呼出しに表示できなくなります。

再配信遅延が構成されている場合、メッセージはその遅延の期間は再配信不可となり、宛先の統計では「保留中」のメッセージとしてカウントされます。遅延期間の後、再配信制限を超えていなければ、メッセージが配信されて宛先の統計で「現在の」メッセージとしてカウントされます。再配信制限を超えている場合、エラー配信先が構成されていればメッセージがそこに移動し、エラー配信先が構成されていなければメッセージは削除されます。

ロールバックは、メッセージが処理される順序に影響を及ぼす可能性があります。ロールバックされたメッセージは、同一のキューまたはサブスクリプション内の後続のメッセージが処理された後で再配信されます。厳密なメッセージの順序付けが必要な場合は、『Oracle WebLogic Server JMSアプリケーションの開発』のメッセージ順序単位の使用に関する項を参照してください。

- 回復されたメッセージ: クライアントによるセッション「回復」の呼出しが明示的に行われたためにキューに現れるメッセージ。このメッセージは、前述のロールバックされたメッセージとほぼ同じです。

- 再配信されたメッセージ: クライアントへの配信に失敗したために宛先に再び現れるメッセージ。このメッセージは、前述のロールバックされたメッセージとほぼ同じです。

起動時のメッセージ処理の休止と再開の優先順位

起動時に、宛先の休止や再開を様々なレベルの属性で設定できます。

- JMSサーバーを使用して宛先のグループをホストしている場合は、宛先のグループ全体でのメッセージ処理を休止または再開できる

- JMSテンプレートを使用して宛先のグループの属性値を定義している場合は、グループ内のすべての宛先でのメッセージ処理を休止または再開できる

- 単一の宛先でのメッセージ処理を休止または再開できる

これらの各レベルの値が起動時に一致していない場合、指定した宛先でのメッセージ処理は以下の優先順位に基づいて決定されます。メッセージ処理の休止および再開を構成するための各属性において、

1. 宛先をホストするJMSサーバーの属性セットに有効な値が設定されている場合は、その値に基づいて起動時の宛先の状態が決定されます。サーバー・レベルの設定が最も優先されます。

2. 宛先をホストするJMSサーバーの属性セットに有効な値が設定されていない場合は、宛先レベルの属性の値が2番目に優先され、その値に基づいて起動時の宛先の状態が決定されます。

3. 宛先をホストするJMSサーバーおよび宛先の属性セットに有効な値が設定されていない場合は、JMSテンプレートの属性の値に基づいて起動時の宛先の状態が決定されます。

4. これら3つのレベルのすべてで属性が設定されていない場合は、値が「false」に設定されているものと見なされます。

セキュリティ

管理ユーザーやグループは、その時点で宛先の状態が他のユーザーによって制御されているかどうかに関係なく、宛先の現在の状態をオーバーライドできます。

2人の非管理ユーザーが宛先の状態を制御しようとした場合、以下の規則が適用されます。

1. 宛先の状態を「休止」に変更したユーザーと同じグループに属すユーザーのみが、その宛先を「再開」して通常の処理に戻すことができます。

2. 所属の異なる2ユーザーによって状態の変更が試行された場合

A JMSリソース定義要素リファレンス

この項では、次の各項で、Java EE JMSリソース定義要素およびプロパティについて説明します

- JMSコネクション・ファクトリの定義要素とプロパティ

- JMS宛先定義要素とプロパティ

JMSコネクション・ファクトリの定義要素とプロパティ

この項では、http://docs.oracle.com/javaee/7/api/javax/jms/JMSConnectionFactoryDefinition.htmlで説明するJMSリソース定義を使用してアプリケーション・モジュール内の接続ファクトリを構成する場合に指定する要素について説明します。

次の例では、@JMSConnectionFactoryDefinitionアノテーションを使用して、接続ファクトリを定義しています。

@JMSConnectionFactoryDefinition(
name="java:global/jms/demoConnectionFactory",
className= "javax.jms.ConnectionFactory",
description="Sample description for Connection Factory",
clientId="client_Id01",
transactional=true,
properties= {"UserName=myuser", "delivery-mode=Persistent", "load-balancing-enabled=true"}

JMSConnectionFactoryDefinitionアノテーションの詳細は、http://docs.oracle.com/javaee/7/api/javax/jms/JMSConnectionFactoryDefinition.htmlを参照してください。

JMSアプリケーション・モジュールの要素定義の詳細は、http://xmlns.oracle.com/weblogic/weblogic-jms/1.4/weblogic-jms.xsd にあるweblogic-jms.xsdスキーマを参照してください

表A-1 @JMSConnectionFactoryDefinition要素

@JMSConnectionFactoryDefinition要素にある要素

JMSアプリケーション・モジュールにある同等の要素

型

説明

name

jndi-name

String

定義されるJMS接続ファクトリのJNDI名。

注意: これは必須要素です。

description

notes

String

接続ファクトリの説明。

clientId

clientId

String

接続に使用されるクライアントID。

transactional

transaction-paramsxa-connection-factory-enabled

Boolean

接続がトランザクションに参加するかどうかを指定します。このプロパティの設定を、

false
にした場合、接続はトランザクションに参加しません。

デフォルトはTrueです。

resourceAdapter

なし

String

リソース・アダプタの名前。

className

なし

String

値は無視されます。

InterfaceName

なし

String

値は無視されます。

maxPoolSize

なし

integer

値は無視されます。

minPoolSize

なし

integer

値は無視されます。

user

なし

String

値は無視されます。

password

なし

String

値は無視されます。

JMS接続ファクトリ・プロパティ

注意:
この項で定義されるプロパティは、接続ファクトリ定義がアダプタを指定しない場合のみ適用されます。アダプタが指定されると、アダプタに対して一意であるプロパティが考慮されます。

表A-2 @JMSConnectionFactoryDefinitionプロパティ

@JMSConnectionFactoryDefinitionプロパティ

JMSアプリケーション・モジュールにある同等の要素

型

説明

name

name

Sting

接続ファクトリの名前。指定しない場合、名前は<module_name>_cfです。ここで、<module_name>は、リソースが定義されるJMSアプリケーション・モジュールの名前を表します。

jms-server-name

sub-deployment-name

Sting

リソースに対してターゲットとして指定されるJMSサーバー。アプリケーションで指定されたjms-server-nameがデプロイメントのスコープ中に存在しない場合、デプロイメントは失敗し、障害の理由を示す例外が発生します。

default-targeting-enabled

default-targeting-enabled

boolean

jms-server-nameが指定されていない場合は、このプロパティをtrueに設定します。jms-server-nameが指定されている場合、この値は無視されます。

表A-3 A-3 デフォルト・メッセージ配信のための@JMSConnectionFactoryDefinitionプロパティ

@JMSConnectionFactoryDefinitionプロパティ

JMSアプリケーション・モジュールにある同等のdefault-delivery-params要素

型

説明

default-delivery-mode

default-delivery-mode

String

定義される接続ファクトリを使用してプロデューサから送信されるすべてのメッセージに割り当てられる配信モード。受け入れられる値: PersistentまたはNon-persistent

default-time-to-deliver

default-time-to-deliver

String

メッセージが生成されてからその宛先で表示できるようになるまでの遅延時間(ミリ秒)

default-time-to-live

default-time-to-live

Long

メッセージの最大存在時間を示すミリ秒数。この値は、メッセージに優先度が明示的に定義されていない場合に使用されます。

default-priority

default-priority

integer

メッセージに優先度が明示的に定義されていない場合に使用するデフォルトの優先度。

default-redelivery-delay

default-redelivery-delay

Long

ロールバックまたは回復されたメッセージが再配信されるまでの遅延時間(ミリ秒)。

default-compression-threshold

default-compression-threshold

integer

シリアライズされたメッセージ本文のバイト数。任意のメッセージがこの制限を超過すると、そのメッセージがJMSメッセージ・プロデューサまたはコンシューマによって送信または受信されたときに、メッセージが圧縮されます

default-unit-of-order

default-unit-of-order

String

この接続ファクトリのデフォルトの順序単位プロデューサ。

オプション:「システム生成」および「ユーザー生成」

send-timeoutr

send-timeoutr

Long

宛先に、送信されようとしているメッセージ用に利用できる領域が十分にない(割当てがない)場合に、送信側が待機する最長時間(ミリ秒)。

これらのプロパティの詳細は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのJMS接続ファクトリ: 構成: デフォルト配信を参照してください。

表A-4 A-4 @JMSConnectionFactoryDefinitionクライアント・プロパティ

@JMSConnectionFactoryDefinitionプロパティ

JMSアプリケーション・モジュールにある同等のclient-params要素

型

説明

client-id-policy

client-id-policy

String

複数のJMS接続が同じクライアントIDを使用できるかどうか。有効なオプションは、「制限付き」と「制限なし」です。

subscription-sharing-policy

subscription-sharing-policy

String

接続上のサブスクリプション共有ポリシー。

有効なオプションは、「排他」と「共有可能」です。

acknowledge-policy

acknowledge-policy

String

CLIENT_ACKNOWLEDGEモードを使用し、トランザクションが未処理のセッションに対するクライアント承認ポリシー。有効なオプションは、AllとPreviousです。

allow-close-in-onMessage

allow-close-in-onMessage

Boolean

close()メソッドをonMessage()メソッド呼出し内で発行できるようにするメッセージ・コンシューマを、接続ファクトリで作成するかどうか。

注意: このプロパティのデフォルト値は、JMS接続ファクトリ定義を使用して作成された接続ファクトリでは、falseです。接続ファクトリがJMSシステム・モジュール内、またはアプリケーションをスコープとするモジュール内に作成された場合、allow-close-in-onMessageのデフォルト値はtrueです。

messages-maximum

messages-maximum

int

非同期セッション向けに存在でき、メッセージ・リスナーにまだ渡されていないメッセージの最大数

multicast-overrun-policy

multicast-overrun-policy

String

未処理のマルチキャスト・メッセージ数がmessages-maximumで指定された値に達し、一部のメッセージを削除する必要があるときに使用するポリシー。

有効なオプションは、KeepOldとKeepNewです。

synchronous-prefetch-mode

synchronous-prefetch-mode

String

同期コンシューマが1回のサーバー・アクセスでメッセージ(つまり、サーバーからクライアントに送られるメッセージ)をプリフェッチするかどうか。

有効なオプションは、enabled、disabledまたはtopicSubscriberOnlyです。

reconnect-policy

reconnect-policy

String

サーバーとのネットワーク接続が失われた後、またはサーバーの再起動時に、明示的および暗黙的にリフレッシュされるJMSクライアントのタイプ。

有効なオプションは、none、producerまたはallです。

reconnect-blocking-millis

reconnect-blocking-millis

Long

同期JMSコールが、JMSクライアント上で進行中の再接続を諦める前に、コール元スレッドをブロックする時間の最大長(単位はミリ秒)。

total-reconnect-period-millis

total-reconnect-period-millis

Long

最初のネットワーク切断、または最後の同期呼出しの試行のうち、いずれか最近に起こった方の後に、JMSクライアント(特に非同期コンシューマ)が、再試行を放棄せずサーバーに再接続しようとし続ける最長時間(ミリ秒)。

これらのプロパティの詳細は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのJMS接続ファクトリ: 構成:クライアントを参照してください。

表A-5 A-5 @JMSConnectionFactoryDefinitionトランザクション・プロパティ

@JMSConnectionFactoryDefinitionプロパティ

JMSアプリケーション・モジュールにある同等のtransaction-params要素

型

説明

transaction-timeout

transaction-timeout

Long

接続ファクトリで作成された接続上のすべてのトランザクションのタイムアウト値(秒)。

このプロパティは、transactional要素がtrueに設定された場合のみ設定します。

これらのプロパティの詳細は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのJMS接続ファクトリ: 構成: トランザクションを参照してください。

これらのプロパティの詳細は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのJMS接続ファクトリ: 構成: フロー制御を参照してください

表A-6 A-6 @JMSConnectionFactoryDefinitionフロー制御プロパティ

@JMSConnectionFactoryDefinitionプロパティ

JMSアプリケーション・モジュールにある同等のflow-control-params要素

型

説明

flow-minimum

flow-minimum

integer

しきい値の条件に達したプロデューサで許可される秒当たりの最大メッセージ数。プロデューサがフロー制御されている場合、秒当たりFlowMaximumに指定されたメッセージ数よりも処理を高速化できません。

flow-maximum

flow-maximum

integer

しきい値の条件に達したプロデューサで許可される秒当たりの最小メッセージ数。これはプロデューサのフロー制限の下限値。つまり、フロー制限がFlowMinimumに達したプロデューサの処理速度はWebLogic JMSによりそれ以上落とされません。

flow-interval

flow-interval

integer

プロデューサがフローをFlowMaximumのメッセージ数からFlowMinimumに、あるいはその反対に調節するときの調節期間の秒数。

flow-steps

flow-steps

integer

プロデューサが「最大フロー」のメッセージ数から「最小フロー」に、またはその反対にフローを調整するときに使用するステップ数。

flow-control-enabled

flow-control-enabled

Boolean

接続ファクトリを使用して作成されたプロデューサでフローを制御できるかどうか。

one-way-send-mode

one-way-send-mode

String

通常の非永続な非トランザクション・メッセージングのパフォーマンスを向上させるために、この接続ファクトリを使用して作成されたメッセージ・プロデューサに、一方向のメッセージ送信を許可するかどうか。

有効なオプションは、「有効」、「無効」またはtopicOnlyです。

one-way-send-window-size

one-way-send-window-size

integer

One-Way Send Modeが、キュー・センダーやトピック・パブリッシャによるone-way送信を許可するように設定されている場合に、ウィンドウごとの送信されるメッセージの最大数。ウィンドウ・サイズでは、さらなる一方向送信を続行できるようになる前に、プロデューサを規定するため双方向メッセージが必要な場合が決定されます。

これらのプロパティの詳細は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのJMS接続ファクトリ: 構成: フロー制御を参照してください

表A-7 A-7 @JMSConnectionFactoryDefinitionロード・バランシング・プロパティ

@JMSConnectionFactoryDefinitionプロパティ

JMSアプリケーション・モジュールにある同等のload-balancing-params要素

型

説明

load-balancing-enabled

load-balancing-enabled

Boolean

接続ファクトリを介して作成された非匿名プロデューサが、分散宛先内で呼出し単位でロード・バランシングされるようにするかどうか。

server-affinity-enabled

server-affinity-enabled

Boolean

サーバー・インスタンスで、分散宛先の複数のメンバー宛先にまたがってコンシューマまたはプロデューサのロード・バランシングを実行するときに、同じサーバー・インスタンス内で動作する他の物理宛先にまたがるロード・バランシングを最初に試行するかどうか。

これらのプロパティの詳細は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのJMS接続ファクトリの構成: ロード・バランシングを参照してください。

表A-8 A-8 @JMSConnectionFactoryDefinitionロード・バランシング・プロパティ

@JMSConnectionFactoryDefinitionプロパティ

JMSアプリケーション・モジュールにある同等のsecurity-params要素

型

説明

attach-jmsx-user-id

attach-jmsx-user-id

Boolean

接続ファクトリを介して作成された非匿名プロデューサが、分散宛先内で呼出し単位でロード・バランシングされるようにするかどうか。

これらのプロパティの詳細は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのJMS接続ファクトリ: 構成のセキュリティを参照してください

JMS宛先定義要素とプロパティ

この項では、JMSリソース定義を使用してアプリケーション・モジュール内のJMS宛先リソースを構成する場合に指定する要素について説明します(「Java EEリソース定義を使用したJMSリソースの定義」参照)。

次の例は、@JMSDestinationDefinitionアノテーションを使用して宛先を定義しています。

@JMSDestinationDefinition(
name="java:global/jms/demoDestination",
interfaceName="javax.jms.Queue",
className= "javax.jms.Queue",
description="Sample description for Queue",
destinationName="myQueue",
properties= {"default-unit-of-order=true", "time-to-deliver=Persistent", "attach-sender=always"}

JMSDestinationDefinitionアノテーションの詳細は、http://docs.oracle.com/javaee/7/api/javax/jms/JMSDestinationDefinition.htmlを参照してください

JMSアプリケーション・モジュールの要素定義の詳細は、http://xmlns.oracle.com/weblogic/weblogic-jms/1.4/weblogic-jms.xsdを参照してください

表A-9 A-9 @JMSDestinationDefinition要素

@JMSDestinationDefinition内の要素

JMSアプリケーション・モジュールにある同等の要素

型

説明

name

jndi-name

String

定義されるJMS宛先リソースのJNDI名。

注意: これは必須要素です。

interfaceName

uniform-distributed-queue or uniform-distributed-topic

String

JMS宛先インタフェースの完全修飾名。有効なオプションは、javax.jms.Queueまたはjavax.jms.Topicです。

JMS宛先定義は、interfaceNameに指定された値に基づいて、タイプがuniform-distributed-queueまたはuniform-distributed-topicのエンティティを使用してJMSモジュールに変換されます。

注意: これは必須要素です。

description

notes

String

定義されるJMS宛先の説明。

接続先名

name

String

キューまたはトピックのランタイムMBean名。指定しない場合、宛先名前は<module_name>_<queue/topic>です。ここで、<module_name>はリソースが定義されるJMSアプリケーション・モジュールの名前を表します。

className

なし

-

この値は無視されます。

resourceAdapter

なし

-

この値は無視されます。

表A-10 A-10 @JMSDestinationDefinitionプロパティ

@JMSDestinationDefinitionプロパティ

JMSアプリケーション・モジュールにある同等の要素

型

説明

jms-server-name

sub-deployment-name

String

リソースに対してターゲットとして指定されるJMSサーバー。アプリケーションで指定されたjms-server-nameがデプロイメントのスコープ中に存在しない場合、デプロイメントは失敗し、障害の理由を示す例外が発生します。

default-targeting-enabled

default-targeting-enabled

Boolean

jms-server-nameが指定されていない場合は、このプロパティをtrueに設定します。

jms-server-nameが指定されている場合、この値は無視されます。

表A-11 A-11 @JMSDestinationDefiitionしきい値プロパティ

@JMSDestinationDefinitionプロパティ

JMSアプリケーション・モジュールにある同等のthresholds要素

型

説明

bytes-high

bytes-high

Long

ロギングやフロー制御イベントを発生させる上限しきい値(この宛先内の合計バイト数)。

bytes-low

bytes-low

Long

ロギングやフロー制御イベントを発生させる下限しきい値(この宛先内の合計バイト数)。

messages-high

messages-high

Long

ロギングやフロー制御イベントを発生させる上限しきい値(この宛先内の合計メッセージ数)。

messages-low

messages-low

Long

ロギングやフロー制御イベントを発生させる下限しきい値(この宛先内の合計メッセージ数)。

これらのプロパティの詳細は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプの共通分散トピック: 構成: しきい値と割当て制限を参照してください。

表A-12 A-12 @JMSDestinationDefinitionメッセージ配信オーバーライド・プロパティ

@JMSDestinationDefinitionプロパティ

JMSアプリケーション・モジュールにある同等のdelivery-params-overrides 要素

型

説明

delivery-mode

delivery-mode

String

メッセージ・プロデューサによって指定された配信モードに関わりなく、宛先に届くすべてのメッセージに割り当てられる配信モード。

有効なオプションは、「永続」または「非永続」です。

time-to-deliver

time-to-deliver

String

メッセージが生成されてからそのターゲット分散宛先で表示できるようになるまでの配信遅延時間(ミリ秒単位またはスケジュールとして)。

time-to-live

time-to-live

Long

メッセージ・プロデューサによって指定されたTimeToLive値に関係なく、宛先に届くすべてのメッセージに割り当てられる存続時間。

priority

priority

Integer

メッセージ・プロデューサによって指定された優先度に関わりなく、宛先に届くすべてのメッセージに割り当てられる優先度。

redelivery-delay

redelivery-delay

Long

コンシューマや接続ファクトリによって指定された再配信遅延に関わりなく、ロールバックまたは回復されたメッセージが再配信されるまでの遅延(ミリ秒単位)。

詳細は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプの共通分散トピック: 構成: 再配信に関する項を参照してください。

これらのプロパティの詳細は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプの共通分散トピック: 構成: オーバーライドに関する項を参照してください。

表A-13 A-13 @JMSDestinationDefinitionメッセージ配信障害プロパティ

@JMSDestinationDefinitionプロパティ

JMSアプリケーション・モジュールにある同等のdelivery-failure params要素

型

説明

redelivery-limit

redelivery-limit

Integer

メッセージがエラー宛先に移動する前に再配信を試行できる回数。

expiration-policy

expiration-policy

String

宛先で期限切れメッセージに遭遇したときに使用するメッセージの有効期限ポリシー。

有効なオプションは、「破棄」または「ログ」または「リダイレクト」です。

expiration-logging-policy

expiration-logging-policy

String

有効期限ポリシーがLogに設定されている場合に、メッセージに関する情報が記録されます。

これらのプロパティの詳細は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプの共通分散トピック: 構成: 再配信を参照してください。

表A-14 A-14 @JMSDestinationDefinitionメッセージ・ロギング・プロパティ

@JMSDestinationDefinitionプロパティ

JMSアプリケーション・モジュールにある同等のmessage-logging-params要素

型

説明

message-logging-enabled

message-logging-enabled

Boolean

モジュールで、メッセージのライフサイクルに関する情報をロギングするかどうか。

message-logging-format

message-logging-format

String

メッセージに関する情報が記録されます。

このプロパティは、次の例に示すように定義されます。

このプロパティの有効値の詳細は、『Oracle WebLogic Server MBeanリファレンス』の、MessageLoggingParamsBeanのMessageLoggingFormat属性についての説明を参照してください。

これらのプロパティの詳細は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプの共通分散宛先: 構成: ロギングを参照してください。

表A-15 A-15 @JMSDestinationDefinition詳細構成プロパティ

@JMSDestinationDefinitionプロパティ

JMSアプリケーション・モジュールにある同等の要素

型

説明

load-balancing-policy

load-balancing-policy

String

この宛先のメンバーにメッセージが配信される方法

有効なオプションは、「ラウンドロビン」と「ランダム」です

production-paused-at-startup

production-paused-at-startup

Boolean

起動時に宛先で新しいメッセージの生成を休止するかどうか

insertion-paused-at-startup

insertion-paused-at-startup

Boolean

起動時に宛先で新しいメッセージの挿入を休止するかどうか。

consumption-paused-at-startup

consumption-paused-at-startup

Boolean

起動時に宛先で消費を休止するかどうか。

default-unit-of-order

default-unit-of-order

Boolean

ドメイン、JMSサーバー、宛先名に基づいて、システムで生成される順序単位名をWebLogic Serverが作成するかどうかを指定します。

unit-of-order-routing

unit-of-order-routing

String

順序単位の一部であるメッセージの宛先として分散宛先メンバーが選択される方法を指定します。

有効なオプションは、「ハッシュ」と「パス・サービス」です。

attach-sender

attach-sender

String

この宛先に届くメッセージに送信側ユーザーの資格証明が添付されている必要があるかどうか。有効なオプションは、「サポート」、「常時」および「なし」です。

jms-create-destination-identifier

jms-create-destination-identifier

String

宛先の参照名または分散宛先のメンバーの参照名。JNDIを利用せずにjavax.jms.Session createQueueまたはcreateTopicを使用して宛先を検索する方法を提供します。

saf-export-policy

saf-export-policy

String

ユーザーがストア・アンド・フォワードを使用する宛先にメッセージを送信できるかどうか。有効なオプションは、「すべて」と「なし」です。

messaging-performance-preferenc

messaging-performance-preferenc

Integer

宛先が、コンシューマに配信する消費可能なメッセージ(存在する場合)の完全なバッチを作成するまでに待機できる期間の長さ。

unit-of-work-handling-policy

unit-of-work-handling-policy

String

この宛先で作業単位(UOW)機能を有効化するかどうか。

有効なオプションは、PassThroughとSingleMessageDeliveryです。

incomplete-work-expiration-time

incomplete-work-expiration-time

Integer

未完了のUOW内の未配信メッセージが期限切れになるまでの最長時間(ミリ秒)。

これらのプロパティの詳細は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプの共通分散トピック: 構成: 一般にある、詳細構成オプションを参照してください。

注意:
これらのプロパティは、@JMSDestinationDefinitionのinterfaceName要素がjavax.jms.Queueに設定されている場合のみ適用できます。

これらのプロパティの詳細は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプの共通分散キュー: 構成: 全般を参照してください。

表A-16 A-16 @キュー宛先のための@JMSDestinationDefinitionプロパティ

@JMSDestinationDefinitionプロパティ

JMSアプリケーション・モジュールにある同等の要素

型

説明

forward-delay

forward-delay

Integer

コンシューマを持たない共通分散キュー・メンバーが、コンシューマを持つ他の共通分散キュー・メンバーにメッセージを転送するまでに待機する秒数。

reset-delivery-count-on-forward

reset-delivery-count-on-forward

Boolean

分散キュー・メンバー間でのメッセージ転送時に配信回数をリセットするかどうか。

注意:
これらのプロパティは、@JMSDestinationDefinitionのinterfaceName要素がjavax.jms.Topicに設定されている場合のみ適用できます。

これらのプロパティの詳細は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプの共通分散トピック: 構成: 全般と、共通分散トピック: マルチキャストを参照してください

表A-17 A-17 キュー宛先のための@JMSDestinationDefinitionプロパティ

@JMSDestinationDefinitionプロパティ

JMSアプリケーション・モジュールにある同等の要素

型

説明

forwarding-policy

forwarding-policy

String

送信されたメッセージをすべてのメンバーに転送するかどうかを指定する共通分散トピックのメッセージ転送ポリシー。

有効なオプションは、「パーティション化」と「レプリケート」です。

宛先がJMS宛先定義を使用して作成された場合、このプロパティのデフォルト値はPartitionedです。宛先が他の方法で作成された場合、デフォルト値は「レプリケート」です。

注意: 共通分散トピックがReplicatedに設定された転送ポリシーを持っている場合、リソース・グループまたはリソース・グループ・テンプレートにJMSモジュールをデプロイできません。このため、JMS宛先定義を含むアプリケーション・モジュールを、リソース・グループとリソース・グループ・テンプレートにデプロイする場合、デフォルトの転送ポリシー(Partitioned)を使用してください

multicast-address

multicast-address

String

トピックが、マルチキャスト・コンシューマにメッセージを送信するために使用できるアドレス。

multicast-time-to-live

multicast-time-to-live

Integer

マルチキャストの存続時間の値。メッセージがコンシューマに到達するまでに通過できるルーターの数を指定します。

multicast-port

multicast-port

Integer

トピックが、マルチキャスト・コンシューマにメッセージを送信するために使用されるポート。

Oracleの法律上の注意点

コピーライト

Copyright © 1994-2017, Oracle and/or its affiliates. All rights reserved.

ライセンス制約の保証と結果的に生じる損害の免責

このソフトウェアおよび関連ドキュメントの使用と開示は、ライセンス契約の制約条件に従うものとし、知的財産に関する法律により保護されています。ライセンス契約で明示的に許諾されている場合もしくは法律によって認められている場合を除き、形式、手段に関係なく、いかなる部分も使用、複写、複製、翻訳、放送、修正、ライセンス供与、送信、配布、発表、実行、公開または表示することはできません。このソフトウェアのリバース・エンジニアリング、逆アセンブル、逆コンパイルは互換性のために法律によって規定されている場合を除き、禁止されています。

保証免責

ここに記載された情報は予告なしに変更される場合があります。また、誤りが無いことの保証はいたしかねます。誤りを見つけた場合は、オラクルまでご連絡ください。

制限付権利について

このソフトウェアまたは関連ドキュメントを、米国政府機関もしくは米国政府機関に代わってこのソフトウェアまたは関連ドキュメントをライセンスされた者に提供する場合は、次の通知が適用されます。

U.S. GOVERNMENT END USERS: Oracle programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, delivered to U.S. Government end users are "commercial computer software" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations. As such, use, duplication, disclosure, modification, and adaptation of the programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, shall be subject to license terms and license restrictions applicable to the programs. No other rights are granted to the U.S. Government.

危険な用途への使用について

このソフトウェアまたはハードウェアは様々な情報管理アプリケーションでの一般的な使用のために開発されたものです。このソフトウェアまたはハードウェアは、危険が伴うアプリケーション(人的傷害を発生させる可能性があるアプリケーションを含む)への用途を目的として開発されていません。このソフトウェアまたはハードウェアを危険が伴うアプリケーションで使用する際、安全に使用するために、適切な安全装置、バックアップ、冗長性(redundancy)、その他の対策を講じることは使用者の責任となります。このソフトウェアまたはハードウェアを危険が伴うアプリケーションで使用したことに起因して損害が発生しても、Oracle Corporationおよびその関連会社は一切の責任を負いかねます。

商標と登録商標について

OracleおよびJavaはオラクルおよびその関連会社の登録商標です。その他の社名、商品名等は各社の商標または登録商標である場合があります。

Intel、Intel Xeonは、Intel Corporationの商標または登録商標です。すべてのSPARCの商標はライセンスをもとに使用し、SPARC International, Inc.の商標または登録商標です。AMD、Opteron、AMDロゴ、AMD Opteronロゴは、Advanced Micro Devices, Inc.の商標または登録商標です。UNIXは、The Open Groupの登録商標です。

第三者のコンテンツ、製品、サービスに対する免責事項

このソフトウェアまたはハードウェア、そしてドキュメントは、第三者のコンテンツ、製品、サービスへのアクセス、あるいはそれらに関する情報を提供することがあります。適用されるお客様とOracle Corporationとの間の契約に別段の定めがある場合を除いて、Oracle Corporationおよびその関連会社は、第三者のコンテンツ、製品、サービスに関して一切の責任を負わず、いかなる保証もいたしません。適用されるお客様とOracle Corporationとの間の契約に定めがある場合を除いて、Oracle Corporationおよびその関連会社は、第三者のコンテンツ、製品、サービスへのアクセスまたは使用によって損失、費用、あるいは損害が発生しても一切の責任を負いかねます。

Pre-General Availability (一般提供前)版のドキュメントについて

このドキュメントがPre-General Availability (一般提供前)版の場合:

このドキュメントはPre-General Availability (一般提供前)版であり、デモおよび暫定使用のみを目的としたものです。このソフトウェアを使用するハードウェアに限定するものではありません。Oracle Corporationおよびその関連会社は、このドキュメントに関して一切の責任を負わず、いかなる保証もいたしません。また、このドキュメントを使用したことによって損失、費用、あるいは損害が発生しても、一切の責任を負いかねます。

非公開のPre-General Availability (一般提供前)版のドキュメントについて

このドキュメントが非公開のPre-General Availability (一般提供前)版の場合:

このドキュメントに含まれる情報は、情報の共有のみを目的としたものであって、顧客諮問委員会(Customer Advisory Board)のメンバーとしてのお客様の立場でのみ、またはお客様のPre-General Availability Trial Agreement (Pre-GAトライアル契約)のみに従って検討されるべきものとします。マテリアル、コード、または機能の提供をお約束するものではなく、購入決定を行う際の判断材料とすべきではありません。このドキュメントに記載されている特徴または機能の開発、リリースおよび時期については、オラクルの裁量により決定されます。

このドキュメントには、ソフトウェアまたは印刷物などの形式を問わず、オラクルが独占的な権利を有する財産的情報が含まれています。この機密資料へのアクセスと使用は、お客様とオラクルとの間で締結され、お客様が遵守に同意した、Oracle Master Agreement、Oracle License and Oracle Services Agreement (オラクル・ライセンスおよびサービスに関する契約書)、Oracle Partner Network Agreement、Oracle Distribution Agreementまたはその他のライセンス契約の条件に従うものとします。このドキュメントとその内容の開示、コピー、複製および配布には、オラクルによる事前の承諾を必要とします。このドキュメントはライセンス契約の一部となるものではなく、オラクルおよびその子会社や関連会社との契約を構成するものではありません。

ドキュメントのアクセシビリティ

オラクルのアクセシビリティについての詳細情報は、Oracle Accessibility ProgramのWebサイト(http://www.oracle.com/pls/topic/lookup?ctx=acc&id=docacc)を参照してください。

Oracle Supportへのアクセス

サポートをご契約のお客様には、My Oracle Supportを通して電子支援サービスを提供しています。詳細情報は(http://www.oracle.com/pls/topic/lookup?ctx=acc&id=info)か、聴覚に障害のあるお客様は(http://www.oracle.com/pls/topic/lookup?ctx=acc&id=trs)を参照してください。