3 JMSメッセージに対するSAFの構成
-
ノート:
WebLogic SAFクライアントが提供するメカニズムにより、ネットワークに接続できない(一時的なエラー、ネットワーク障害など)ためにSAFクライアントがJMS宛先にアクセスできない場合でも、スタンドアロン・クライアントはサーバー側のJMS宛先にJMSメッセージを確実に送信できます。SAFクライアントの接続が切断されている間、そのクライアントによって送信されたメッセージはクライアント上でローカルに格納され、クライアントが再接続されたときにサーバー側のJMS宛先に転送されます。Oracle WebLogic Serverスタンドアロン・クライアントの開発のJMS SAFクライアントによる確実なメッセージ送信を参照してください。
JMSモジュールのSAFリソース
weblogic-jmsmd.xsd
スキーマに準拠するXMLドキュメントによって定義されます。JMSモジュールには、WebLogic ServerでのJMSメッセージの格納と転送を可能にする、SAFリソースの構成も含まれます。『Oracle WebLogic Server JMSリソースの管理』のJMSリソースの構成の理解に関する項を参照してください。
次のトピックでは、JMSモジュールのSAFリソースを構成する方法について説明します。
JMS SAFリソースが構成されると、構成されたSAF送信エージェントによって、受信側へのメッセージの転送、確認応答が時間内に戻らなかった場合のメッセージの再送信、およびメッセージの永続性が必要になる場合の永続ストレージへのメッセージの一時的な格納が行われます。「ストア・アンド・フォワード・サービスの理解」を参照してください。
JMS SAFはJMSアプリケーションからは透過的です。既存のJMSアプリケーションは、コードを変更することなく、この機能を利用できます。実際には、JMSモジュールでインポート済みJMS宛先を構成し、その後、リモートのJMS宛先をローカルのJNDI名に関連付ける必要があるだけです。JMSクライアント・コードは既存のJMS APIを使用して、インポート済み宛先にアクセスします。メッセージの生産のみがJMSストア・アンド・フォワードの対象となるので、JMSクライアントは引き続き、インポート済み宛先から直接メッセージを消費する必要があります。
SAFインポート済み宛先
SAF宛先(キューまたはトピック)は、リモートのサーバー・インスタンスやクラスタに関連付けられたJMSモジュール内のJMS宛先(キューまたはトピック)をローカルに表現したものです。このようなリモート宛先は、ローカルのクラスタやサーバー・インスタンスに「インポート」されます。これにより、ローカルのサーバー・インスタンスやクラスタから、リモートのサーバー・インスタンスやクラスタにメッセージを送信することが可能になります。宛先に対する「SAFエクスポート・ポリシー」パラメータが明示的に無効化されていない限り、デフォルトではすべてのJMS宛先が自動的にエクスポートされます。
インポートされたSAF宛先の集合は、SAFインポート済み宛先と呼ばれます。インポート済み宛先の各集合は、SAFリモート・コンテキストと関連付けられます。また、それらは同じJNDI接頭辞、存続時間のデフォルト(メッセージの有効期限)、およびSAFエラー処理オブジェクトを共有します。
JMSプロデューサがSAF宛先にメッセージを送信すると、これらのメッセージは後の配信に備えてSAF宛先に格納されます。SAFエージェントは、(インポート済み宛先が表す)リモートJMS宛先へ、その宛先がアクセス可能であればSAFリモート・コンテキストを使用してメッセージを転送します。
SAFリモート・コンテキスト
SAFリモート・コンテキストでは、JMS宛先のエクスポート元である、リモートのサーバー・インスタンスまたはクラスタのURLが定義されます。また、リモート・クラスタまたはサーバーで認証および認可されるセキュリティ資格証明も含まれます。インポート済み宛先を使用する場合は、SAFリモート・コンテキストの構成が必須です。SAFリモート・コンテキストは、複数のSAFインポート済み宛先の構成で再利用できます。
次に示すURLは、SAFリモート・コンテキストで、スタンドアロンJMS宛先をインポートするリモート管理対象サーバーを1つ定義した場合の例です。
<URL> t3://123.0.0.1:7001 </URL>
リモート・クラスタから分散宛先をインポートする場合は、DNSサーバー名またはIPアドレスをカンマで区切って指定します。次に示すURLは、SAFリモート・コンテキストで、分散宛先のメンバーをインポートするリモート・クラスタを定義した場合の例です。
<URL> t3://123.0.0.1:7001,123.0.0.1:7002,123.0.0.1:7003 </URL>
WebLogicクラスタとの最初の接続ポイントを指定する方法は、Oracle WebLogic Server JNDIアプリケーションの開発のクラスタ環境でのWebLogic JNDIの使用を参照してください。
SAFエラー処理
SAFエラー処理リソースでは、SAFサービスがリモート宛先へのメッセージ転送に失敗した場合に行うアクションを定義します。SAFエラー処理リソースは、SAFインポート済み宛先を使用する場合でも必須ではありませんが、ベスト・プラクティスとしてお薦めします。
構成オプションには、以下のパラメータが含まれます。
-
エラー処理ポリシー:
-
「破棄」 - デフォルトでは、期限切れのメッセージは単にシステムから削除されます。削除はログに記録されず、メッセージは別の場所にリダイレクトされません。
-
「ログ」 - 期限切れのメッセージを削除し、メッセージがシステムから削除されたことを示すエントリをサーバー・ログ・ファイルに書き込みます。実際にログに記録される情報は、「ログ・フォーマット」フィールドで定義します。
-
「リダイレクト」 - 期限切れのメッセージを現在の位置から、インポート済みのSAF宛先に定義されているエラー宛先へ移動します。
-
「常に転送」 - インポート済みの宛先に対して設定されたSAFデフォルト存続時間と、メッセージに対して設定された存続時間を無視するので、期限が切れた後でもメッセージをリモート宛先へ転送します。このオプションは、アプリケーションでリモート宛先に有効期限ポリシーが設定されていても、それらのメッセージをリモート宛先の有効期限プロセスで処理したい場合に便利です。
-
-
「ログ・フォーマット」 - 「ログ」ポリシーを選択した場合は、このフィールドを使用して、メッセージのどの情報をログに記録するかを定義します。
-
「エラー宛先」 - 「リダイレクト」ポリシーを選択した場合は、このフィールドを使用して、期限切れメッセージをリダイレクトするローカルのSAF宛先を選択します。
SAF JMSの仕組み
図3-1に、Domain1のDomain1Module-jms.xmlモジュール内のQueueSend
キューに生成されたJMSメッセージが、SAFエージェントによってDomain2のDomain2Module-jms.xmlモジュール内のQueueReceive
キューに転送される仕組みを示します。
JMS SAFリソースの作成
-
WebLogic Server管理コンソールを使用します。これにより、使用している環境のJMSシステム・モジュールおよびJMSシステム・リソースを構成、変更、ターゲット指定、モニター、および削除できます。JMS SAFリソースの構成タスクのロード・マップについては、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのJMS SAFの構成を参照してください
-
WebLogic Scripting Tool (WLST)を使用します。これにより、JMSサーバーとJMSシステム・リソースを作成および管理できます。『Oracle WebLogic Server JMSリソースの管理』のWLSTを使用したJMSサーバーとJMSシステム・モジュール・リソースの管理に関する項を参照してください。
-
WebLogic Java Management Extensions (JMX)を使用します。これにより、
SAFImportedDestinationsBean
、SAFRemoteContextBean
、およびSAFErrorHandlingBean
管理MBeanにアクセスして、JMSモジュールのSAFリソースを作成および管理できます。『Oracle WebLogic Server JMXによるカスタム管理ユーティリティの開発』のWebLogic ServerサブシステムMBeanの概要に関する項を参照してください。 -
JMSモジュール・ヘルパー拡張APIを使用します。これにより、JMS実行時MBeanの検索と、特定のモジュール内のJMSシステム・モジュール構成リソースの管理(検索、作成、削除)を行うことができます。『Oracle WebLogic Server JMSアプリケーションの開発』のJMSモジュール・ヘルパーを使用したアプリケーションの管理に関する項またはOracle WebLogic Server Java APIリファレンスの
JMSModuleHelper
に関する項を参照してください。
JMS宛先に対するストア・アンド・フォワード・エージェントの構成 - 主なステップ
ストア・アンド・フォワード(SAF)エージェントは、ローカル送信エンドポイントとリモート受信エンドポイントの間で格納と転送を行います。JMS SAF機能は、WebLogic SAFサービス上に構築され、高可用性を備えたJMSメッセージを生成します。JMS SAFでは、送信機能を持つように構成されたSAFエージェントのみが必要です。
WebLogic Server管理コンソールを使用して、リモート宛先にJMSメッセージを転送するためにSAFリソースを構成する主なステップは次のとおりです。
JMSメッセージに対するSAFの設計
JMSメッセージの格納と転送のためにWebLogic SAFを設計および構成する際には、運用環境に適したサービスの質、メッセージ配信モード、メッセージ順序単位、トランザクション・ロールバック、ロード・バランシングなどの特定の設定について慎重に考慮する必要があります。
次のトピックでは、JMSメッセージを格納および転送するためにWebLogic SAFを設計および構成する方法について説明します。
サービスの品質(QOS)レベルの選択
永続JMSメッセージは、SAFサービスによって常に「必ず1回」のQOSで転送されます。非永続メッセージでは、SAFインポート済みキューとトピックに対して以下の3種類のQOSレベルを定義できます。
-
「必ず1回」 - もっとも高レベルのQOS。メッセージがリモート・エンドポイントに1回だけ送信されます。「必ず1回」を指定すると、サーバーのクラッシュ時やネットワークのダウン時にもメッセージは存続し、各メッセージがエンドポイントに1つだけ存在する状態にできます。
-
「1回以上」 - メッセージはリモート・エンドポイントに少なくとも1回は転送されますが、重複する可能性があります。「1回以上」を指定すると、メッセージの転送中に発生したネットワーク障害やサーバーのクラッシュにより、そのメッセージの複数のコピーがリモートのエンドポイントに現れることがあります。
-
「最大1回」 - もっとも低レベルのQOS。各メッセージがリモート・エンドポイントに(送信できた場合には) 1回だけ送信されます。メッセージが重複してエンドポイントに届くことはありません。「最大1回」を指定していると、ネットワーク障害やサーバーのクラッシュによってメッセージが失われることがあります。メッセージが重複してエンドポイントに届くことはありません。
SAFによる配信モードの処理方法
SAFアプリケーションでは、メッセージごとに配信モードを指定することもできます。
-
永続メッセージは、受信側に正常に転送され、確認応答されるまで送信側の永続ストアに保存されます。
-
非永続メッセージは、受信側がそれらを確認応答するまで送信側のメモリー内に存在し続けます(つまり、非永続メッセージは送信側がクラッシュすると失われるおそれがあります)。
メッセージ順序単位の使用
クラスタ内では、JMSプロデューサをメッセージ順序単位に関連付けることができます。これにより、スタンドアロンのメッセージ・プロデューサまたは1つのプロデューサとして機能するプロデューサのグループは、処理順序に関して複数のメッセージを1つの単位にグループ化できるようになります。『Oracle WebLogic Server JMSアプリケーションの開発』のメッセージ順序単位の使用に関する項を参照してください。
SAFインポート済宛先ではハッシュ・マップまたはパス・サービスのいずれかを使用して、クラスタ内の順序付けされたメッセージをグループ化できます。ただし、パス・サービスを構成するのがベスト・プラクティスです。パス・サービスは、メッセージのグループとメッセージング・リソース(SAFエージェントなど)との間のマッピングを格納できる永続マップです。『Oracle WebLogic Server JMSリソースの管理』のWebLogicパス・サービスの使用に関する項を参照してください。
トランザクション・メッセージ
アプリケーションのメッセージがトランザクション内にある場合、「必ず1回」のセマンティクスを維持するために、永続ストレージへのメッセージの保存はそのユーザー・トランザクションの一環として行われます。
特に、メッセージの永続ストレージからの削除は、アプリケーションでトランザクションのロールバックが決定された場合にトランザクション・ロールバックの一環として行われます。一方、転送はアプリケーション・トランザクションの一環としては行われません。トランザクションがコミットされるまで、トランザクション・メッセージは送信エージェントによって転送されません。トランザクション内では、メッセージの順序はメッセージが送信された時間に基づいて保持されます。
SAF境界を越えるメッセージの圧縮
JMSストア・アンド・フォワードでは、別々のクラスタ間でメッセージが転送される場合、メッセージを圧縮できます。メッセージ圧縮のしきい値は、WLMessageProducer
インタフェースのJMS API拡張機能を使用することによってプログラム的に設定するか、接続ファクトリまたはJMS SAFリモート・コンテキストで「デフォルト圧縮しきい値」を指定することによって管理的に設定できます。
JMSメッセージ圧縮の使用の詳細は、Oracle WebLogic Serverのパフォーマンスのチューニングのメッセージの圧縮を参照してください。
SAFリモート・コンテキストの圧縮しきい値を超える非圧縮メッセージは、SAF境界を越えて転送されるときに圧縮されます。メッセージは、リモート・エンドポイントで受信されるまで、圧縮されたままです。接続ファクトリで圧縮が有効になっているためにSAF境界を越えるときにメッセージがすでに圧縮されている場合は、SAF圧縮がトリガーされるかどうかに関係なく、メッセージは圧縮されたままSAF境界を越えて転送されます。
分散宛先に対するSAF
リモート・エンドポイントは分散宛先であってもかまいません。一般的に、リモート分散宛先へのメッセージは、スタンドアロンのリモート宛先に転送されるメッセージと同様に格納および転送されます。しかし、ロード・バランシングは他の分散宛先と別に処理されます。詳細は、「SAFロード・バランシング」を参照してください
『Oracle WebLogic Server JMSリソースの管理』の分散宛先の構成に関する項を参照してください。
SAFロード・バランシング
ロード・バランシングでは、メッセージがインポート済のSAF宛先に送信される場合、またはリモート宛先に転送される場合のメッセージ経路が決定されます。SAFメッセージのメッセージ経路を決定するようWebLogic Serverを構成する際には、次の2つの状況を考慮してください。
インポート済宛先へのメッセージの送信
JMSクライアントによって送信されたメッセージは、次のいずれかのメッセージ経路を使用して、インポート済宛先にロード・バランシングされます。
-
単一のSAFエージェントの場合、ロード・バランシングは通常のJMS宛先への送信と同様に処理されます。
-
複数のSAFエージェントの場合、インポート済宛先は分散宛先と同様に機能します。接続ファクトリのロード・バランシング設定に従って、メッセージが複数のSAFエージェントにロード・バランシングされます。「接続と接続ファクトリ」を参照してください
- メッセージを実行中のすべてのメンバーに分散する(
「メンバー単位」
-デフォルト)、または必ず1回のロード・バランシング
・ポリシーを使用してJVMごとに単一のメンバーにのみ分散する(「JVM単位」
)を選択できます。『JMSリソースの管理』のロード・バランシングのヒューリスティックに関する項を参照してください。
SAFエージェントによるリモート宛先へのメッセージの転送
メッセージの転送は、各SAFエージェントが個別に行います。この場合、メッセージを転送するSAFエージェントはロード・バランシングの対象とならず、メッセージ経路は宛先タイプによって決まります。
-
宛先が分散されていない通常の宛先の場合、ロード・バランシングやフェイルオーバーは行われません。
-
ターゲットとなる宛先が分散宛先の場合、メッセージ経路とフェイルオーバーの動作は、順序単位が設定されていない
Exactly-once
メッセージ(persistent
またはnon-persistent
で、QoSがExactlyOnce
のメッセージ)に対するSAFエージェントの構成によって決まります。メッセージ経路は、使用可能な分散宛先メンバーのリストの中から、ラウンドロビン方式のロード・バランシング・メッセージによって決定されます。使用できなくなったメンバーは、リストから動的に削除されます。使用可能になったメンバーは、リストに動的に追加されます。単一メッセージの観点から、フェイルオーバーは行われません。SAFエージェントが宛先メンバーへのメッセージの配信に失敗した場合、別のメンバーに再配信するのではなく、元のメンバーへの配信を定期的に再試行します。
ExactlyOnce
QoSを維持するため、メッセージのターゲット・メンバーは変更されません。複数のJVMにまたがるメッセージの均一なロード・バランシングでは、順序単位が設定されていない
「必ず1回」
のQoS転送メッセージの候補メンバーは、各リモートJVMにある分散宛先の単一メンバーに制限できます。この動作は、Imported Destination ExactlyOnceLoadBalancingPolicy
属性またはコマンドライン・システム・プロパティを使用して構成できます。詳細は、『JMSリソースの管理』のロード・バランシングのヒューリスティックに関する項を参照してください。 -
その他すべてのメッセージ・タイプについては、デフォルト接続ファクトリ(
loadBalancingEnabled=true
およびserverAffinityEnabled=true
)によってメッセージ経路が決まります。ノート:
JMS接続ファクトリのデフォルト設定は変更もオーバーライドもできません。
SAFでのJMSReplyToフィールドの使用
一般的に、JMSアプリケーションはJMSReplyTo
ヘッダー・フィールドを使用して、一時的な宛先の名前を他のアプリケーションに対して公開できます。ただし、JMSReplyTo
フィールドを使用した一時的な宛先の使用は、SAFインポート済み宛先ではサポートされていません。
『Oracle WebLogic Server JMSアプリケーションの開発』の一時的な宛先の使用に関する項を参照してください。
SAF宛先の保護
SAFインポート済み宛先では、以下のセキュリティ対策が適用されています。
-
SAFインポート済キューとトピックに対してセキュアなロールとポリシーを設定できます。ロールとポリシーの構成の詳細は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプの次の項を参照してください。
-
SAFサービスでは、メッセージの
JMSXUserID
がSAF境界を越えて保持されることはありません。JMSXUserID
とは、メッセージの送信者であるユーザーを識別するシステム生成のプロパティです。JMSXUserID
は、公開しているJMS仕様(http://www.oracle.com/technetwork/java/jms/index.html
)で定義されています。
接続と接続ファクトリ
JMSメッセージは、クライアントから接続ホストを通じて、WebLogic JMSサーバーまたはSAFエージェントがホストするJMS宛先インスタンスへと転送されます。クライアントは、JNDIを使用して接続ファクトリを取得し、それを使用してWebLogicへのJMS接続を作成します。各接続インスタンスは、特定のWebLogicサーバー(接続ホスト)に関連付けられています。
接続ファクトリとは、クライアント接続の構成パラメータを定義するもので、クライアントの宛先と同じサーバーまたはクラスタでホストされる必要があります。WebLogic JMSは、デフォルト接続ファクトリとカスタム接続ファクトリを提供します。デフォルト接続ファクトリは構成できません。一方、カスタム接続ファクトリは構成可能ですが、デフォルト接続ファクトリと同じJNDI名では構成できません。接続ファクトリは、WebLogicクラスタ内の1つ以上のサーバーでホストできます。
-
デフォルト接続ファクトリは、常にクラスタ内のすべてのサーバーでホストされます。
-
カスタム接続ファクトリのホストは、ターゲット構成に基づいて設定されます。
クライアントの接続ファクトリ・インスタンスは、実際にはWebLogic RMIのレプリカ対応スタブであり、接続ファクトリをホストするすべてのアクティブ・サーバーを暗黙的に追跡します。サーバーがクラスタ内で利用可能および利用不可になると、接続ファクトリ・インスタンスはこの情報で自動的に更新されます。クライアントが、接続ファクトリ・インスタンスを使用して接続を作成すると、いずれかのサーバーがクライアントの接続ホストとなります。接続ホストは接続の存続期間中ずっと変わりません。
分散宛先およびインポート済宛先に対するプロデューサのロード・バランシング動作をチューニングする接続ファクトリ設定が3つあります。
-
Server Affinity
: 接続ホストが存在する場合に、送信リクエストを分散宛先またはインポート済宛先のすべてのメンバーではなく、接続ホストのローカル・メンバーの間でのみロード・バランシングするかどうかを指定します。デフォルトでは有効になっています。 -
Load Balancing
: 非匿名のプロデューサを呼出しごとにメンバー間でロード・バランシングするかどうかを指定します。有効にすると、メッセージはsend()
またはpublish()
ごとにすべてのメンバーの間でロード・バランシングされます。無効にすると、最初のsend()
またはpublish()
でロード・バランシングの決定が行われ、その後のメッセージはすべて同じ宛先に送信されます。デフォルトでは有効になっています。 -
プロデューサのロード・バランシング・ポリシー
: メッセージを実行中のすべてのメンバーに分散する「メンバー単位」
(デフォルト)、またはJVMごとに単一のメンバーにのみ分散する「JVM単位」
のいずれかを指定します。『JMSリソースの管理』のロード・バランシングのヒューリスティックに関する項を参照してください。
ノート:
サーバー・アフィニティ
、ロード・バランス
および「プロデューサのロード・バランシング・ポリシー」
は、次の場合に無視されます。
-
通常の宛先への生成の場合。
-
順序単位および作業単位のメッセージに対して使用し、順序に関するサービス品質を厳密に維持する場合。