WebSphere Message Broker バージョン 8.0.0.5 オペレーティング・システム: AIX、HP-Itanium、Linux、Solaris、Windows、z/OS

製品の最新バージョンについては、IBM Integration Bus バージョン 9.0 をご覧ください。

プロキシー・サーブレット構成例のシナリオ

プロキシー・サーブレットの構成は、そのデプロイ先の構成に応じて異なります。

プロキシー・サーブレットの構成は、そのプロキシー・サーブレットが使用されるデプロイメントに応じて異なります。 以下のセクションでは、いくつかの共通シナリオと、必須のプロキシー・サーブレット構成パラメーターについて説明します。

シナリオ 1: Web サーブレット・コンテナーは WebSphere® Message Broker と同じサーバー上にあります。

この構成例では、以下のプロキシー・サーブレット構成パラメーターを構成する必要があります。

  • useClientModefalse に設定します。
  • useQueueManagerDataInsteadOfConfigFile を "" に設定します。
  • configFile を構成ファイルのロケーションに設定します。

サーブレットは、構成ファイルからキュー・マネージャー名を読み取ってから、そのキュー・マネージャーへの接続を試行します。

シナリオ 2: Web サーブレット・コンテナーが WebSphere Message Broker とは異なるサーバー上にあり、ブローカー・キュー・マネージャーへの WebSphere MQ クライアント・リンクがあります。

この構成例では、以下のプロキシー・サーブレット・パラメーターを構成する必要があります。

  • useClientModetrue に設定します。
  • useQueueManagerDataInsteadOfConfigFile* またはブローカー・キュー・マネージャー名に設定します。
  • clientModeHostnameclientModeChannelName、および clientModePortNumber を正しい値 (プロキシー・サーブレット構成パラメーターで詳述) に設定します。

ブローカーに代わってサーブレットは リモート・キュー・マネージャーに接続しようと試み、ブローカーから WebSphere MQ クライアント接続を経由して、必要なノード構成データを読み取ります。正常に接続するには、リモート・キュー・マネージャーで SYSTEM.DEFAULT.LISTENER.TCP リスナーを開始する必要があります。

注: ブローカー・サーバーから Web サーブレット・コンテナー・サーバーへ構成ファイルをコピーしてから、以下のプロキシー・サーブレット構成パラメーターを設定します。
  • configFile を、ブローカー・サーバーからコピーした構成ファイルのロケーションに設定します。
  • useQueueManagerDataInsteadOfConfigFile を "" に設定して、サーブレットに強制的に構成ファイルを読み取らせます。

ただし、構成ファイルは、以後ブローカーによって変更される際に毎回コピーする必要があります。

シナリオ 3: Web コンテナーが WebSphere Message Broker とは異なるサーバー上にあり、独自のキュー・マネージャーと、ブローカー・キュー・マネージャーへの WebSphere MQ チャネル・リンクがあります。

この構成例は、クライアント・モードが使用されないのでシナリオ 1 に似ていますが、以下のプロキシー・サーブレット構成パラメーターを設定する必要があります。

  • useClusterModetrue に設定します。
  • clusterModeQueueManagerName を Web サーブレット・コンテナーのキュー・マネージャーに設定します。
  • clusterModeReplyToQ をそのキュー・マネージャー上に存在するキューに設定します。

サーブレットは、構成ファイルのキュー・マネージャー名を使用して、指定のキュー・マネージャー上でキュー SYSTEM.BROKER.WS.INPUT を開くことを試行します。そのため、チャネルおよび送信キューを事前にセットアップして、メッセージがブローカー・キュー・マネージャーに確実に到達するようにする必要があります。

構成ファイルはブローカー・サーバーからこのシナリオでコピーする必要があります。

シナリオ 4: Web サーブレット・コンテナーが WebSphere Message Broker とは異なるサーバー上にあり、ブローカー・キュー・マネージャーへの WebSphere MQ クライアント・リンクがありますが、いくつかのブローカーに作業を分散するためにネットワーク・ロード・バランサーを使用します。

構成はシナリオ 2 と同じですが、ネットワーク・ロード・バランサー IP がブローカー・サーバーの代わりになります。 一般的には構成ファイルが使用されることはできません。なぜなら、1 つの仮想 IP アドレスの背後に複数のブローカーがあり、 ブローカーごとに異なる構成ファイルがあるからです。 サーブレット はパー・コネクション・ベースの情報を読み込み、各ブローカーに対して 訂正構成情報を使用します。

この構成例では、以下のプロキシー・サーブレット構成パラメーターを構成する必要があります。

  • useClientModetrue に設定します。
  • useQueueManagerDataInsteadOfConfigFile* またはブローカー・キュー・マネージャー名に設定します。
  • clientModeHostnameclientModeChannelName、および clientModePortNumber を正しい値 (プロキシー・サーブレット構成パラメーターで詳述) に設定します。

この構成をデプロイする理由の 1 つがフェイルオーバーである場合、以下の追加のプロキシー・サーブレット構成パラメーターを構成することを推奨します。

  • clientModeConnectRetryCount を、ブローカー数以上の数値に設定します。 この設定により、ロード・バランサーが単純な周期的スケジューリングを行う場合でも、単一のサーバーで障害が発生した場合に偶発的なエラーが発生することはありません。 サーブレットは、使用可能な最初のブローカーを使用します。
  • reconnectActiveLinksAge をファイアウォール・タイムアウトより小さい値に設定します。 このように設定すると、サーブレットとロード・バランサーの間 (またはロード・バランサーとブローカーの間) のファイアウォールによって破棄された可能性のある古い接続が再利用されなくなります。

代わりの方法として、testConnectionBeforeReusetrue に設定して、 Web サーブレット・コンテナーとブローカー・キュー・マネージャーの間のドロップされた WebSphere MQ リンクを処理する方法もあります。 ただし、このオプションを指定すると、ブローカーへのデータの送信を試行する前に MQINQ が実行されてしまいます。 MQINQ が失敗した場合、新しい接続が確立され、 データが新しい接続を経由して送信されます。 構成は MQPUT と MQGET に他の命令を追加するので、結果としてすべてのメッセージにかなりのオーバーヘッドが生じます。このオプションは、他に代わりの選択可能なオプションがない場合にのみ使用してください。

プロキシー・サーブレット構成の完了を終了するには、プロキシー・サーブレットの構成を参照してください。

すべてのプロキシー・サーブレット構成パラメーターについては、プロキシー・サーブレット構成パラメーターを参照してください。

特記事項 | 商標 | ダウンロード | ライブラリー | サポート | フィードバック

Copyright IBM Corporation 1999, 2014Copyright IBM Corporation 1999, 2014.

        
        最終更新:
        
        最終更新: 2015-02-28 17:46:23


参照トピック参照トピック | バージョン 8.0.0.5 | ac69431_