付録 C HTTP/HTTPS のサポート

Message Queue の Enterprise Edition では、Java クライアントが、TCP 接続を直接使用するのではなく、HTTP またはセキュリティー保護された HTTP (HTTPS) 転送を使用してブローカと通信するようにサポートされています。C クライアントでは、HTTP/HTTPS がサポートされません。

この付録では、このようなサポートを有効にするために使用されるアーキテクチャーについて説明し、クライアントが Message Queue メッセージングに HTTP ベースの接続を使用するために必要となる設定の手順を示します。この付録は、次の節から構成されています。

HTTP/HTTPS サポートのアーキテクチャー

Message Queue メッセージングは、HTTP/HTTPS 接続で実行できます。HTTP/HTTPS 接続は、通常ファイアウォールの通過が許可されるため、ファイアウォールによってブローカからクライアントアプリケーションを分離できます。

図 C-1 に、HTTP/HTTPS サポートの提供に関連する主なコンポーネントを示します。

クライアント側では、HTTP または HTTPS トランスポートドライバが、Message Queue メッセージを HTTP 要求にカプセル化し、これらの要求が正しい手順で Web サーバーまたはアプリケーションサーバーに送信されるようにします。

クライアントは、必要に応じて、HTTP プロキシサーバーを使用してブローカと通信できます。プロキシのアドレスは、クライアントの起動時に、コマンド行オプションを使用して指定します。詳細は、「HTTP プロキシを使用する」を参照してください。

HTTP または HTTPS トンネルサーブレット (どちらも Message Queue にバンドルされている) が、Web サーバーまたはアプリケーションサーバーに読み込まれます。サーブレットは、ペイロードメッセージをクライアント HTTP 要求から取り出してから、ブローカに転送します。また HTTP/HTTPS トンネルサーブレットは、クライアントが作成した HTTP 要求に応じて、ブローカのメッセージをクライアントに返送します。1 つの HTTP/HTTPS トンネルサーブレットで複数のブローカにアクセスできます。

図 C-1 HTTP/HTTPS サポートのアーキテクチャー
図は、HTTP プロキシおよび HTTP トンネルサーブレットにより、メッセージがどのようにファイウォールを通過するかを示します。図は文字で説明されます。

ブローカ側では、httpjms または httpsjms 接続サービスが、対応するトンネルサーブレットから送られてくるメッセージを開いて逆多重化します。

Web サーバーまたはアプリケーションサーバーに障害が生じ再起動された場合は、すべての接続が復元されるため、クライアントへの影響はありません。ブローカに障害が生じ再起動された場合は、例外がスローされ、クライアントはそれぞれの接続を再確立する必要があります。発生するのはまれですが、Web サーバーまたはアプリケーションサーバーとブローカの両方に障害が生じ、ブローカが再起動しなかった場合、Web サーバーまたはアプリケーションサーバーはクライアント接続を復元し、引き続きブローカ接続を待機しますが、クライアントには通知しません。この状況を避けるために、常に、ブローカを再起動してください。

図 C-1 からわかるとおり、HTTP と HTTPS サポートのアーキテクチャーは非常に良く似ています。主な相違点は、HTTPS (httpsjms 接続サービス) の場合、トンネルサーブレットにクライアントアプリケーションとブローカの両方への安全な接続があることです。

ブローカへの安全な接続は、SSL に対応したトンネルサーブレット、つまり Message Queue の HTTPS トンネルサーブレットを通して提供されます。このトンネルサーブレットが、接続の要求時にブローカに自己署名型証明書を渡します。ブローカは証明書を使用して、HTTPS トンネルサーブレットへの暗号化された接続を設定します。この接続が確立されると、クライアントアプリケーションと Web サーバーまたはアプリケーションサーバーは、クライアントアプリケーションとトンネルサーブレット間の安全な接続のネゴシエーションを行うことができます。

HTTP サポートの有効化

次に、HTTP サポートを有効化するのに必要な手順を説明します。

HTTP サポートを有効にする

手順 1: HTTP トンネルサーブレットを配置する

HTTP トンネルサーブレットは、Sun Java System Web Server または Sun Java System Application Server に、Web アーカイブ (.war) ファイルとして配置できます。

HTTP トンネルサーブレットを .war ファイルとして配置するときは、Web サーバーまたはアプリケーションサーバーで提供される配置メカニズムを使用します。HTTP トンネルサーブレットの .war ファイル (imqhttp.war) は、.jar、.war、および .rar ファイルを含むディレクトリに配置します。これはオペレーティングシステムによって異なります (付録 A 「プラットフォームごとの Message Queue データの場所」を参照)。

.war ファイルには、Web サーバーまたはアプリケーションサーバーがサーブレットを読み込んで実行するときに必要となる基本的な設定情報が示された配置記述子が含まれています。Web サーバーまたはアプリケーションサーバーによっては、サーブレットの URL のコンテキストルート部分を指定しなければならない場合もあります。

HTTP トンネルサーブレットを Sun Java System Web Server に配置する

ここでは、Sun Java System Web Server への配置手順について説明します。Web ブラウザを使用してサーブレットの URL にアクセスすると、HTTP トンネルサーブレットが問題なく配置されたことが確認できます。ステータス情報も表示されます。

HTTP トンネルサーブレットを .war ファイルとして配置する

ブラウザベースの管理 GUI で、「Virtual Server Class」タブを選択してから、「Manage Classes」を選択します。

適切な仮想サーバークラス名 (defaultClass など) を選択して、「Manage」ボタンをクリックします。

「Manage Virtual Servers」を選択します。

適切な仮想サーバー名を選択し、「Manage」ボタンをクリックします。

「Web Applications」タブを選択します。

「Deploy Web Application」をクリックします。

「WAR File On and WAR File Path」フィールドで、imqhttp.war ファイルを指す適切な値を選択します。このファイルはオペレーティングシステムによって異なるディレクトリに格納されています (付録 A 「プラットフォームごとの Message Queue データの場所」を参照)。

「Application URI」フィールドにパスを入力します。

「Application URI」フィールドの値は、トンネルサーブレット URL の /contextRoot 部分です。

http://hostName:portNumber/contextRoot/tunnel

たとえば、contextRoot を imq に設定した場合、「Application URI」フィールドは次のようになります。

/imq

サーブレットを配置するインストールディレクトリのパス (通常は、Sun Java System Web Server インストールルートの内の場所) を入力します。

「OK」をクリックします。

Web サーバーインスタンスを再起動します。

クライアントはこの URL を使用することで、HTTP 接続を使ってメッセージサービスに接続できます。

サーバーのアクセスログを無効にする

必ずしもサーバーのアクセスログを無効にする必要はありませんが、無効にしたほうがより良いパフォーマンスを得ることができます。

サーバーのアクセスログを無効にする

Log クライアントアクセス制御を使用して、ロギングを無効にします。

HTTP トンネルサーブレットを Sun Java System Application Server に配置する

この節では、HTTP トンネルサーブレットを Sun Java System Application Server に .war ファイルとして配置し、Message Queue ブローカからの接続を受け付けるようにトンネルサーブレットを設定する方法について説明します。

配置ツールを使用する

HTTP トンネルサーブレットを Application Server 環境に配置する

Web ベースの管理 GUI で、次を選択します。

「App Server」 > 「Instances」 > 「server1」 > 「Applications」 > 「Web Applications」

「Deploy」ボタンをクリックします。

「File Path:」テキストフィールドに、HTTP トンネルサーブレットの .war ファイル (imqhttp.war) の場所を入力し、「OK」をクリックします。

imqhttp.war ファイルの場所は、オペレーティングシステムによって異なります (付録 A 「プラットフォームごとの Message Queue データの場所」を参照)。

「Context Root」テキストフィールドの値を設定し、「OK」をクリックします。

「Context Root」フィールドの値は、トンネルサーブレット URL の /contextRoot 部分です。

http://hostName:portNumber/contextRoot/tunnel

たとえば、「Context Root」フィールドは /imq に設定できます。

表示される確認画面で、トンネルサーブレットが正常に配置され、デフォルトで有効になっており、この場合は次の場所に格納されていることが確認されます。

/var/opt/SUNWappserver8/domains/domain1/server1/applications/
j2ee-modules/imqhttp_1

クライアントはこの URL を使用することで、HTTP 接続を使ってメッセージサービスに接続できます。

server.policy ファイルを変更する

Application Server は、セキュリティーポリシーが変更されていないかぎり、強制的にデフォルトのセキュリティーポリシーセットを適用し、HTTP トンネルサーブレットが Message Queue ブローカからの接続を受け入れるのを阻止します。

各アプリケーションサーバーインスタンスには、セキュリティーポリシーまたはルールを含むファイルがあります。たとえば、Solaris 上の server1 インスタンスのこのファイルは次の場所にあります。

トンネルサーブレットに Message Queue ブローカからの接続を受け入れさせるように設定するには、このファイルにエントリを追加する必要があります。

アプリケーションサーバーの server.policy ファイルを変更する

server.policy ファイルを開きます。

次のエントリを追加します。


grant codeBase
"file:/var/opt/SUNWappserver8/domains/domain1/server1/ applications/j2ee-modules/imqhttp_1/-"
{
permission java.net.SocketPermission "*", "connect,accept,resolve";
};

手順 2: httpjms 接続サービスを設定する

デフォルトでは、HTTP サポートはブローカに対してアクティブになっていないため、httpjms 接続サービスをアクティブにするようブローカを再設定する必要があります。再設定したあとは、「ブローカの起動」で説明されているようにブローカを起動できます。

httpjms 接続サービスをアクティブにする

ブローカのインスタンス設定ファイルを開きます。

インスタンス設定ファイルは、その設定ファイルが関連付けられているブローカインスタンスの名前 (instanceName) によって識別されるディレクトリに格納されています (付録 A 「プラットフォームごとの Message Queue データの場所」を参照)。

.../instances/instanceName/props/config.properties

httpjms の値を imq.service.activelist プロパティーに追加します。

imq.service.activelist=jms,admin,httpjms

ブローカは、起動時に、Web サーバーまたはアプリケーションサーバーとそのホストマシン上で実行している HTTP トンネルサーブレットを探します。リモートトンネルサーブレットにアクセスするには、接続サービスの servletHost および servletPort プロパティーを設定し直します。

pullPeriod プロパティーを設定し直して、パフォーマンスを向上させることもできます。表 C-1 では、httpjms 接続サービスの設定プロパティーについて説明します。

表 C-1 httpjms 接続サービスのプロパティー
プロパティー	説明
imq.httpjms.http. servletHost	必要に応じてこの値を変更し、HTTP トンネルサーブレットを実行するホストの名前 (ホスト名または IP アドレス) を指定します。リモートホストか、またはローカルホストの特定のホスト名のどちらかになります。デフォルト値は、localhost です。
imq.httpjms.http. servletPort	この値を変更して、ブローカが HTTP トンネルサーブレットにアクセスするために使用するポート番号を指定します。Web サーバー上でデフォルトのポート番号が変更されている場合は、それに合わせてこのプロパティーを変更します。デフォルト値は、7675 です。
imq.httpjms.http. pullPeriod	メッセージをブローカから取り出すために各クライアントランタイムが出す HTTP 要求の間隔を秒単位で指定します。このプロパティーはブローカで設定され、クライアントランタイムに伝達される点に注意してください。値がゼロまたは負の場合、クライアントは常に HTTP 要求の 1 つを保留にして、可能なかぎり迅速なメッセージの取り出しに備えます。クライアント数が多いと、この動作によって Web サーバーまたはアプリケーションサーバーのリソースが消耗し、サーバーの応答が遅くなる場合があります。そのような場合には、pullPeriod プロパティーを正の秒数に設定する必要があります。これにより、後続の取り出し要求が出される前の、クライアントの HTTP トランスポートドライバの待機時間が設定されます。値を正の数に設定すると、クライアントにより監視される応答時間を犠牲にして、Web サーバーまたはアプリケーションサーバーのリソースが維持されます。デフォルト値は、-1 です。
imq.httpjms.http. connectionTimeout	クライアントランタイムが例外をスローする前に HTTP トンネルサーブレットからの応答を待機する時間を秒単位で指定します。このプロパティーはブローカで設定され、クライアントランタイムに伝達される点に注意してください。このプロパティーは、ブローカが HTTP トンネルサーブレットと通信したあと、接続を解放するまでの時間も指定します。ブローカとトンネルサーブレットは、HTTP サーブレットへアクセス中のクライアントが異常終了したかどうかを確認する手段を持っていないため、この場合はタイムアウトが必須となります。デフォルト値は、60 です。

手順 3: HTTP 接続を設定する

クライアントアプリケーションは、設定済みの接続ファクトリ管理対象オブジェクトを適切に使用して、ブローカへの HTTP 接続を確立する必要があります。この節では、HTTP 接続設定について説明します。

接続ファクトリを設定する

HTTP サポートを有効にするには、接続ファクトリの imqAddressList 属性を HTTP トンネルサーブレット URL に設定する必要があります。HTTP トンネルサーブレット URL の一般的な構文は次のとおりです。

hostName:portNumber は、HTTP トンネルサーブレットをホストする Web サーバーまたはアプリケーションサーバーの名前とポートです。contextRoot は、Web サーバーまたはアプリケーションサーバーにトンネルサーブレットを配置したときに設定したパスです。

接続ファクトリ属性の全般と imqAddressList 属性の詳細については、『Message Queue Developer's Guide for Java Clients』を参照してください。

接続ファクトリ属性の設定は、次のいずれかの方法で行います。

接続ファクトリ管理対象オブジェクトを作成する imqobjmgr コマンドで -o オプションを使用するか (「接続ファクトリの追加」を参照)、管理コンソール (imqadmin) を使用して接続ファクトリ管理対象オブジェクトを作成するときに属性を設定します。

クライアントを起動するコマンドで -D オプションを使用します (『Message Queue Developer's Guide for Java Clients』を参照)。

クライアントのプログラムで接続ファクトリを作成してから、API 呼び出しを使用して接続ファクトリの属性を設定します (『Message Queue Developer's Guide for Java Clients』を参照)。

1 つのサーブレットを使用して複数のブローカにアクセスする

複数のブローカを実行している場合、複数の Web サーバーまたはアプリケーションサーバーとサーブレットインスタンスを設定する必要はありません。現在実行中のブローカ間で、1 つの Web サーバーまたはアプリケーションサーバーと HTTP トンネルサーブレットのインスタンスを共有できます。複数のブローカインスタンスが 1 つのトンネルサーブレットを共有している場合は、次に示すとおり、imqAddressList 接続ファクトリ属性を設定する必要があります。

bkrHostName はブローカインスタンスのホスト名で、instanceName はクライアントにアクセスさせる特定のブローカインスタンスの名前です。

bkrHostName と instanceName に正しい文字列を入力したことを確認するには、ブラウザからサーブレット URL にアクセスして、HTTP トンネルサーブレットの状態レポートを生成します。レポートでは、サーブレットがアクセスしているすべてのブローカが次のように一覧表示されます。

HTTP プロキシを使用する

HTTP プロキシを使用して HTTP トンネルサーブレットにアクセスする場合、次の設定を行います。

クライアントアプリケーションを起動するコマンドに -D オプションを使用して、これらのプロパティーを設定できます。

HTTPS サポートの有効化

以降の節では、HTTPS サポートを有効化する手順について説明します。この手順は、「HTTP サポートの有効化」の手順とほとんど同じですが、さらに SSL 証明書の生成とアクセスに必要となる手順も追加されています。

HTTPS サポートを有効にする

手順 1: HTTPS トンネルサーブレットの自己署名型証明書を生成する

Message Queue の SSL Support は、クライアントが既知の信頼されたサーバーと通信することを前提に、ネットワーク上のデータを保護することを目的としています。したがって、自己署名型のサーバー証明書だけを使用して SSL が実装されます。httpsjms 接続サービスのアーキテクチャーでは、HTTPS トンネルサーブレットが、ブローカに対してもアプリケーションクライアントに対してもサーバーの役割をします。

keytool ユーティリティーを実行し、トンネルサーブレットの自己署名型証明書を生成します。コマンドプロンプトで次のとおり入力します。

ユーティリティーが、必要な情報を要求します。UNIX システムでは、キーストアを作成するアクセス権を取得するためにスーパーユーザー (root) として keytool を実行する必要があります。

keytool は、まず、キーストアに対するパスワードの入力を要求します。次に一部の組織情報の入力、続いて確認を要求します。確認が取れると、キーの組み合わせを生成している間、このコマンドは停止します。その後、特定のキーの組み合わせをロックするためのパスワード (キーパスワード) の入力を要求してくるので、Return キーを押します。これで、キーパスワードに、キーストアと同じパスワードが設定されます。


注	設定したパスワードを忘れないでください。あとでトンネルサーブレットがキーストアを開くことができるように、そのパスワードを入力する必要があります。

JDK keytool ユーティリティーは、自己署名型証明書を生成し、keyStoreLocation 引数で指定された Message Queue のキーストアファイル内に証明書を配置します。

手順 2: HTTP トンネルサーブレットの .war ファイルの記述子ファイルを変更する


注	HTTPS トンネルサーブレットは、キーストアを参照する必要があります。必ず、keyStoreLocation にある生成されたキーストアを、HTTPS トンネルサーブレットがアクセスできる場所に移動またはコピーしてください (「手順 3: HTTPS トンネルサーブレットを配置する」を参照)。

HTTP トンネルサーブレットの .war ファイルには、Web サーバーまたはアプリケーションサーバーがサーブレットを読み込んで実行するときに必要となる基本的な設定情報が示された配置記述子が含まれています。

imqhttps.war ファイルの配置記述子は、トンネルサーブレットが必要とするキーストアファイルが配置された場所を認識できません。そのため、imqhttps.war ファイルを配置する前に、トンネルサーブレットの配置記述子 (XML ファイル) を編集し、キーストアの場所とパスワードを指定する必要があります。

HTTPS トンネルサーブレット .war ファイルを変更する

.war ファイルを一時ディレクトリにコピーします。

cp /usr/share/lib/imq/imqhttps.war /tmp (Solaris)

cp /opt/sun/mq/share/lib/imqhttps.war /tmp (Linux)

cp IMQ_HOME/lib/imqhttps.war /tmp (Windows)

一時ディレクトリを現在のディレクトリにします。

$ cd /tmp

.war ファイルの内容を抽出します。

$ jar xvf imqhttps.war

.war ファイルの配置記述子を一覧表示します。

$ ls -l WEB-INF/web.xml

web.xml ファイルを編集して、keystoreLocation と keystorePassword という引数に正しい値を設定します。必要に応じて serverPort と serverHost の引数も設定します。

.war ファイルの内容を設定し直します。

$ jar uvf imqhttps.war WEB-INF/web.xml

これで修正済みの imqhttps.war ファイルを使用して、HTTPS トンネルサーブレットを配置できるようになりました。キーストアパスワードの漏洩が心配な場合は、ファイルシステムアクセス権を使用して、imqhttps.war ファイルへのアクセスを制限できます。

手順 3: HTTPS トンネルサーブレットを配置する

HTTP トンネルサーブレットは、Sun Java System Web Server または Sun Java System Application Server に、Web アーカイブ (WAR) ファイルとして配置できます。

HTTPS トンネルサーブレットを .war ファイルとして配置するときは、Web サーバーまたはアプリケーションサーバーで提供される配置メカニズムを使用します。HTTPS トンネルサーブレットの .war ファイル (imqhttps.war) は、オペレーティングシステムによって異なるディレクトリに格納されています (付録 A 「プラットフォームごとの Message Queue データの場所」を参照)。

Web サーバーで暗号化がアクティブであり、クライアントとブローカの間で終端間の安全な通信が有効であることを確認してください。

Web アーカイブファイルとして配置する

HTTPS トンネルサーブレットを Sun Java System Web Server に配置する

この節では、HTTPS トンネルサーブレットを Sun Java System Web Server に .war ファイルとして配置する方法について説明します。Web ブラウザを使用してサーブレットの URL にアクセスすると、HTTPS トンネルサーブレットが問題なく配置されたことが確認できます。ステータス情報も表示されます。

HTTPS トンネルサーブレットを配置する前に、JSSE .jar ファイルが Web サーバーのクラスパスに含まれていることを確認します。これを確実にするもっとも簡単な方法は、jsse.jar、jnet.jar、および jcert.jar を WebServer_TOPDIR/bin/https/jre/lib/ext にコピーすることです。

HTTPS トンネルサーブレットを .war ファイルとして配置する

ブラウザベースの管理 GUI で、「Virtual Server Class」タブを選択します。「Manage Classes」をクリックします。

適切な仮想サーバークラス名 (defaultClass など) を選択して、「Manage」ボタンをクリックします。

「Manage Virtual Servers」を選択します。

適切な仮想サーバー名を選択し、「Manage」ボタンをクリックします。

「Web Applications」タブを選択します。

「Deploy Web Application」をクリックします。

「WAR File On and WAR File Path」フィールドで、修正済みの imqhttps.war ファイルを指す適切な値を選択します (「HTTPS トンネルサーブレット .war ファイルを変更する」を参照)。

「Application URI」フィールドにパスを入力します。

「Application URI」フィールドの値は、トンネルサーブレット URL の /contextRoot 部分です。

https://hostName:portNumber/contextRoot/tunnel

たとえば、contextRoot を imq に設定した場合、「Application URI」フィールドは次のようになります。

/imq

サーブレットを配置するインストールディレクトリのパス (通常は、Sun Java System Web Server インストールルートの内の場所) を入力します。

「OK」をクリックします。

Web サーバーインスタンスを再起動します。

クライアントはこの URL を使用することで、安全な HTTPS 接続を使ってメッセージサービスに接続できます。

サーバーのアクセスログを無効にする

必ずしもサーバーのアクセスログを無効にする必要はありませんが、無効にしたほうがより良いパフォーマンスを得ることができます。

サーバーのアクセスログを無効にする

Log クライアントアクセス制御を使用して、ロギングを無効にします。

HTTPS トンネルサーブレットを Sun Java System Application Server に配置する

この節では、HTTPS トンネルサーブレットを Sun Java System Application Server に .war ファイルとして配置する方法について説明します。

配置ツールを使用する

HTTPS トンネルサーブレットを Application Server 環境に配置する

Web ベースの管理 GUI で、次を選択します。

「App Server」 > 「Instances」 > 「server1」 > 「Applications」 > 「Web Applications」

「Deploy」ボタンをクリックします。

「File Path:」テキストフィールドに、HTTPS トンネルサーブレットの .war ファイル (imqhttps.war) の場所を入力し、「OK」をクリックします。

imqhttps.war ファイルの場所は、オペレーティングシステムによって異なります (付録 A 「プラットフォームごとの Message Queue データの場所」を参照)。

「Context Root」テキストフィールドの値を設定し、「OK」をクリックします。

「Context Root」フィールドの値は、トンネルサーブレット URL の /contextRoot 部分です。

https://hostName:portNumber/contextRoot/tunnel

たとえば、「Context Root」フィールドは次のように設定できます。

/imq

次の画面で、トンネルサーブレットが正常に配置され、デフォルトで有効になっており、この場合は次の場所に格納されていることが表示されます。

/var/opt/SUNWappserver8/domains/domain1/server1/applications/
j2ee-modules/imqhttps_1

クライアントはこの URL を使用することで、HTTPS 接続を使ってメッセージサービスに接続できます。

server.policy ファイルを変更する

Application Server は、セキュリティーポリシーが変更されていないかぎり、強制的にデフォルトのセキュリティーポリシーセットを適用し、HTTPS トンネルサーブレットが Message Queue ブローカからの接続を受け入れるのを阻止します。

トンネルサーブレットに Message Queue ブローカからの接続を受け入れさせるには、このファイルにエントリを追加する必要があります。

アプリケーションサーバーの server.policy ファイルを変更する

server.policy ファイルを開きます。

次のエントリを追加します。


grant codeBase
"file:/var/opt/SUNWappserver8/domains/domain1/server1/ applications/j2ee-modules/imqhttps_1/-"
{
permission java.net.SocketPermission "*", "connect,accept,resolve";
};

手順 4: httpsjms 接続サービスを設定する

デフォルトでは、HTTPS サポートはブローカに対してアクティブになっていないため、httpsjms 接続サービスをアクティブにするようブローカを再設定する必要があります。再設定したあとは、「ブローカの起動」で説明されているようにブローカを起動できます。

httpsjms 接続サービスをアクティブにする

ブローカのインスタンス設定ファイルを開きます。

.../instances/instanceName/props/config.properties

httpsjms の値を imq.service.activelist プロパティーに追加します。

imq.service.activelist=jms,admin,httpsjms

ブローカは、起動時に Web サーバーとそのホストマシン上で実行している HTTPS トンネルサーブレットを探します。リモートトンネルサーブレットにアクセスするには、接続サービスの servletHost および servletPort プロパティーを設定し直します。

pullPeriod プロパティーを設定し直して、パフォーマンスを向上させることもできます。表 C-2 では、httpsjms 接続サービスの設定プロパティーについて説明します。

表 C-2 httpsjms 接続サービスのプロパティー
プロパティー	説明
imq.httpsjms.https. servletHost	必要に応じて、この値を変更し、HTTPS トンネルサーブレットを実行するホストの名前 (ホスト名または IP アドレス) を指定します。リモートホストか、またはローカルホストの特定のホスト名のどちらかになります。デフォルト値は、localhost です。
imq.httpsjms.https. servletPort	この値を変更して、ブローカが HTTPS トンネルサーブレットにアクセスするために使用するポート番号を指定します。Web サーバー上でデフォルトのポート番号が変更されている場合は、それに合わせてこのプロパティーを変更します。デフォルト値は、7674 です。
imq.httpsjms.https. pullPeriod	メッセージをブローカから取り出すために各クライアントが出す HTTP 要求の間隔を秒単位で指定します。このプロパティーはブローカで設定され、クライアントランタイムに伝達される点に注意してください。値がゼロまたは負の場合、クライアントは常に HTTP 要求の 1 つを保留にして、可能なかぎり迅速なメッセージの取り出しに備えます。クライアント数が多いと、この動作によって Web サーバーのリソースが消耗し、サーバーの応答が遅くなる場合があります。そのような場合には、pullPeriod プロパティーを正の秒数に設定する必要があります。これにより、後続の取り出し要求が出される前の、クライアントの HTTP トランスポートドライバの待機時間が設定されます。値を正の数に設定すると、クライアントにより監視される応答時間を犠牲にして、Web サーバーのリソースが維持されます。デフォルト値は、-1 です。
imq.httpsjms.https. connectionTimeout	クライアントランタイムが例外をスローする前に HTTPS トンネルサーブレットからの応答を待機する時間を秒単位で指定します。このプロパティーはブローカで設定され、クライアントランタイムに伝達される点に注意してください。このプロパティーは、ブローカが HTTPS トンネルサーブレットと通信したあと、接続を解放するまでの時間も指定します。ブローカとトンネルサーブレットは、HTTPS サーブレットへアクセス中のクライアントが異常終了したかどうかを確認する手段を持っていないため、この場合はタイムアウトが必要となります。デフォルト値は、60 です。

手順 5: HTTPS 接続を設定する

クライアントアプリケーションは、適切に設定された接続ファクトリ管理対象オブジェクトを使用して、ブローカへの HTTPS 接続を確立する必要があります。

ただし、クライアントは Java Secure Socket Extension (JSSE) で提供される SSL ライブラリへもアクセスし、root 証明書を持つ必要もあります。SSL ライブラリは、JDK 1.4 に付属しています。それ以前の JDK バージョンを使用している場合は、「JSSE を設定する」を参照してください。それ以外の場合は、「root 証明書をインポートする」に進んでください。

これらの点を解決したあとで、HTTPS 接続の設定に進むことができます。

JSSE を設定する

JSSE .jar ファイルを JRE_HOME/lib/ext ディレクトリにコピーします。

jsse.jar、jnet.jar、jcert.jar

JSSE セキュリティープロバイダを静的に追加します。

security.provider.n=com.sun.net.ssl.internal.ssl.Provider

これを JRE_HOME/lib/security/java.security ファイルに追加します。n は、セキュリティープロバイダパッケージに対して次に利用可能な優先順位です。

JDK 1.4 を使用していない場合は、-D オプションをクライアントアプリケーションを起動するコマンドに使用して、次の JSSE プロパティーを設定します。

java.protocol.handler.pkgs=com.sun.net.ssl.internal.www.protocol

root 証明書をインポートする

Web サーバーの証明書に署名した認証局 (CA) の root 証明書が、デフォルトで信頼されるデータベースにない場合、または Web サーバーまたはアプリケーションサーバーの専用の証明書を使用している場合、信頼されるデータベースに証明書を追加する必要があります。これに該当する場合は、次の手順に従ってください。それ以外の場合は、「接続ファクトリを設定する」に進んでください。

証明書が certFile に保存され、trustStoreFile がキーストアであると仮定して、次のコマンドを実行します。

クライアントアプリケーションを起動するコマンドに -D オプションを使用して、次の JSSE プロパティーを指定する必要もあります。

接続ファクトリを設定する

HTTPS サポートを有効にするには、接続ファクトリの imqAddressList 属性を HTTPS トンネルサーブレット URL に設定する必要があります。HTTPS トンネルサーブレット URL の一般的な構文は次のとおりです。

hostName:portNumber は、HTTPS トンネルサーブレットをホストする Web サーバーの名前とポートです。contextRoot は、Web サーバーにトンネルサーブレットを配置したときに設定したパスです。

接続ファクトリ属性の全般と imqAddressList 属性の詳細については、『Message Queue Developer's Guide for Java Clients』を参照してください。

接続ファクトリ属性の設定は、次のいずれかの方法で行います。

クライアントアプリケーションを起動するコマンドに -D オプションを使用します (『Message Queue Developer's Guide for Java Clients』を参照)。

クライアントアプリケーションのプログラムで接続ファクトリを作成してから、API 呼び出しを使用して接続ファクトリの属性を設定します (『Message Queue Developer's Guide for Java Clients』を参照)。

1 つのサーブレットを使用して複数のブローカにアクセスする

複数のブローカを実行している場合、複数の Web サーバーとサーブレットインスタンスを設定する必要はありません。現在実行中のブローカ間で、1 つの Web サーバーと HTTPS トンネルサーブレットのインスタンスを共有できます。複数のブローカインスタンスが 1 つのトンネルサーブレットを共有している場合は、次に示すとおり、imqAddressList 接続ファクトリ属性を設定する必要があります。

https://hostName:portNumber/contextRoot/tunnel?ServerName=bkrHostName:instanceName

bkrHostName はブローカインスタンスのホスト名で、instanceName はクライアントにアクセスさせる特定のブローカインスタンスの名前です。

bkrHostName と instanceName に正しい文字列を入力したことを確認するには、ブラウザからサーブレット URL にアクセスして、HTTPS トンネルサーブレットの状態レポートを生成します。レポートでは、サーブレットがアクセスしているすべてのブローカが次のように一覧表示されます。

HTTP プロキシを使用する

HTTP プロキシを使用して HTTPS トンネルサーブレットにアクセスする場合、次の設定を行います。

クライアントアプリケーションを起動するコマンドに -D オプションを使用して、これらのプロパティーを設定できます。

トラブルシューティング

この節では、HTTP や HTTPS 接続で発生する可能性がある問題、およびその問題の解決方法について説明します。

サーバーかブローカの障害

Web サーバーで障害が生じても再起動すれば、すべての接続が復元され、クライアントへの影響はありません。しかしブローカに障害が生じて再起動された場合は、例外がスローされ、クライアントはそれぞれの接続を再確立する必要があります。

Web サーバーとブローカの両方に障害が生じ、ブローカが再起動されない場合、Web サーバーはクライアント接続を復元し、ブローカ接続を待機しますが、クライアントには通知しません。この状況を避けるため、ブローカの再起動を必ず確認してください。

クライアントのトンネルサーブレットによる接続障害

HTTPS クライアントがトンネルサーブレットでブローカに接続できない場合は、次のように操作します。

サービスが再開する場合、HTTPS クライアントはトンネルサーブレットでブローカに接続できます。

前へ目次索引次へ
Sun Java System Message Queue 3 2005Q4 管理ガイド