第 2 章 Message Queue メッセージングシステム

この章では、Sun Java^TM System Message Queue メッセージングシステムについて説明します。図 2-1 に示すシステムの主要部分に重点を置き、確実なメッセージ配信を実現するための連携作業について説明します。

図 2-1 に示す Message Queue メッセージングシステムの主要部分は次のとおりです。

Message Queue メッセージサーバ

この節では、図 2-1 に示す Message Queue メッセージサーバのさまざまな部分について説明します。次のものが含まれます。

ブローカ Message Queue ブローカには、Message Queue メッセージングシステムの配信サービスが用意されています。メッセージ配信は、コネクションサービス、メッセージのルーティングと配信、持続性、セキュリティ、およびログ記録を処理するさまざまなサポートコンポーネントに依存します (詳細は、「ブローカ」を参照)。メッセージサーバでは、1 つ以上のブローカインスタンスを使用できます (「マルチブローカクラスタ (Enterprise Edition)」を参照)。

物理的な送信先メッセージは 2 段階のプロセスで配信されます。まず、プロデューシングクライアントから、ブローカが管理する物理的な送信先に配信されます。次に、送信先から 1 つまたは複数のコンシューミングクライアントに配信されます。物理的な送信先は、ブローカの物理的なメモリーまたは持続ストレージ、あるいはその両方の場所を表します (詳細は、「物理的な送信先」を参照)。

ブローカ

プロデューシングクライアントから送信先へ、さらに送信先から 1 つ以上のコンシューミングクライアントへ配信される Message Queue メッセージングシステムのメッセージ配信は、ブローカ (または、並行して動作するブローカインスタンスのクラスタ) によって行われます。メッセージ配信を実行するには、ブローカはクライアントとの通信チャネルの設定、認証と承認、適切なメッセージルーティング、信頼性の高い配信の保証、およびシステムパフォーマンスを監視するためのデータの提供を行う必要があります。

この複合的なな機能の組み合わせを実行するために、ブローカはさまざまな内部コンポーネントを使用します。各コンポーネントには、配信プロセスにおける特定のロールが割り当てられています。図 2-2 にブローカのコンポーネントを示し、表 2-1 でそれらについて簡単に説明します。メッセージルーターコンポーネントがメッセージルーティングと配信サービスを主に実行し、それ以外のコンポーネントはメッセージルーターが依存する重要なサポートサービスを提供しています。

表 2-1 主要なブローカサービスコンポーネントと機能
コンポーネント	説明 / 機能
メッセージルーター	メッセージのルーティングおよび配信を管理する。JMS メッセージと、JMS メッセージの配信をサポートするために Message Queue メッセージングシステムが使用するコントロールメッセージを含む
コネクションサービス	ブローカとクライアント間の物理的な接続を管理し、送受信メッセージの転送を行う
持続マネージャ	システム障害が発生しても、JMS メッセージが配信されるように、持続ストレージへのデータの書き込みを管理する
セキュリティマネージャ	ブローカへのコネクションを要求するユーザーに認証サービスを提供し、認証されたユーザーに承認サービス (アクセス制御) を提供する
監視サービス	さまざまな出力チャネルに書き込み可能なメトリックスと診断情報を生成する。管理者はこれらをブローカの監視および管理に使用できる

負荷状態やアプリケーションの複雑さなどに応じて、これらの内部コンポーネントを設定してブローカのパフォーマンスを最適化することができます。次の節では、さまざまなコンポーネントが実行する機能と、コンポーネントの動作に影響を及ぼす設定可能なプロパティについて、詳しく説明します。

コネクションサービス

Message Queue ブローカは、Message Queue アプリケーションクライアントと Message Queue 管理クライアントの両方の通信をサポートしています (「Message Queue管理ツール」を参照)。各サービスは、サービスタイプとプロトコルタイプで指定されます。

サービスタイプ JMS メッセージ配信 (NORMAL) サービス、または Message Queue 管理 (ADMIN) サービスのどちらを提供するのかを指定します。

プロトコルタイプサービスをサポートする基礎となるトランスポートプロトコルレイヤーを指定します。

Message Queue ブローカで現在使用できるコネクションサービスを、表 2-2 に示します。

表 2-2 ブローカがサポートするコネクションサービス
サービス名	サービスタイプ	プロトコルタイプ
jms	NORMAL	tcp
ssljms (Enterprise Edition)	NORMAL	tls (SSL ベースセキュリティ)
httpjms (Enterprise Edition)	NORMAL	http
httpsjms (Enterprise Edition)	NORMAL	https (SSL ベースセキュリティ)
admin	ADMIN	tcp
ssladmin (Enterprise Edition)	ADMIN	tls (SSL ベースセキュリティ)

ブローカを設定して、これらのコネクションサービスの一部、またはすべてを実行することができます。各コネクションサービスは、ブローカのホスト名とポート番号で指定した特定のポートで使用できます。ポートを動的に割り当てることもできれば、コネクションサービスが使用可能なポートを指定することもできます。

図 2-3 に示すように、各サービスはスレッドプールマネージャを保持し、共通のポートマッパーサービスにサービス自体を登録します。

ポートマッパー

Message Queue には、ポートをさまざまなコネクションサービスにマップするポートマッパーが用意されています。ポートマッパー自体は、標準のポート番号 7676 に常駐します。クライアントがブローカとコネクションをする場合、最初に、必要なコネクションサービスのポート番号を要求するポートマッパーに接続します。

jms、ssljms、admin、および ssladmin のコネクションサービスを設定する場合、これらのコネクションサービスに、静的なポート番号を割り当てることも可能ですが、これは、たとえばファイアウォール経由のコネクションのような特殊な状況でだけ実行され、一般にはお勧めしません。httpjms サービスと httpsjms サービスは、それぞれ付録 C 「HTTP/HTTPS サポート (Enterprise Edition)」の表 C-1 と表 C-3 に示すプロパティを使用して設定します。

スレッドプールマネージャ

各コネクションサービスは、複数のコネクションをサポートするマルチスレッドです。これらのコネクションに必要なスレッドは、スレッドプールマネージャのコンポーネントが管理するスレッドプールに保存されます。スレッドプールマネージャを設定して、スレッドプールに保持されるスレッドの最小数と最大数を指定することができます。コネクションでスレッドが必要になると、スレッドプールにスレッドが追加されます。スレッドの最小数より少なくなると、システムは最小数のしきい値になるまで、スレッドをシャットダウンして、スレッドを解放します。これによってメモリーのリソースが節約されます。新しいスレッドを頻繁に作成する必要がないように、最小数に十分な数を指定します。コネクションの負荷が重い場合、スレッドの数を最大数まで増やすことができます。それでも足らない場合、スレッドが利用できるようになるまで、コネクションは待機します。

スレッドプール内のスレッドは、1 つのコネクションだけに割り当てる (専用モデル) か、必要に応じて、複数のコネクションに割り当てる (共有モデル) ことができます。

専用モデルブローカへのコネクションごとに、コネクションの受信メッセージの処理用と、コネクションの送信メッセージの処理用の 2 つの専用スレッドが必要です。このため、コネクションの数は、スレッドプール内の最大スレッド数の半分に制限されますが、高いパフォーマンスを得られます。

共有モデル (Enterprise Edition) コネクションは、メッセージが送信されるか受信されると必ず、共有スレッドによって処理されます。このモデルでは、コネクションごとの専用スレッドは必要ないため、コネクションサービス、さらにブローカがサポートできるコネクション数が多くなります。ただし、スレッドの共有にはある程度のパフォーマンスオーバーヘッドが伴います。スレッドプールマネージャは、一連のディストリビュータスレッドを使用してコネクションのアクティビティを監視し、必要に応じてスレッドにコネクションを割り当てます。このアクティビティに伴うパフォーマンスオーバーヘッドは、各ディストリビュータスレッドが監視するコネクション数を制限することで最小限に抑えることができます。

セキュリティ

各コネクションサービスは、特定の認証および承認 (アクセス制御) 機能をサポートします (「セキュリティマネージャ」を参照)。

コネクションサービスのプロパティ

コネクションサービスに関する設定可能なプロパティを表 2-3 に示します。各プロパティの説明については、第 5 章「ブローカの起動と設定」を参照してください。

表 2-3 コネクションサービスのプロパティ
プロパティ名	説明
imq.service.activelist	ブローカの起動時にアクティブになる、コンマで区切られた、名前別のコネクションサービスのリスト。サポートされているサービスは、 jms、ssljms、httpjms、httpsjms、admin、ssladmin デフォルト値 : jms、admin
imq.ping.interval	ブローカがコネクションを介して Message Queue クライアントランタイムへ継続的に ping を試行する間隔デフォルト値 : 120 秒
imq.hostname	1 台のコンピュータに、複数のネットワークインタフェースカードがある場合など、複数のホストを使用できる場合には、すべてのコネクションサービスがバインドするホストを、ホスト名、または IP アドレスで指定するデフォルト値 : すべての使用可能な IP アドレス
imq.portmapper.port	ブローカのプライマリポートを指定する。ポートマッパーが常駐するポート。ホストで複数のブローカインスタンスを実行する場合、各ブローカインスタンスに、固有のポートマッパーポートを割り当てる必要があるデフォルト値 : 7676
imq.portmapper.hostname	1 台のコンピュータに、複数のネットワークインタフェースカードがある場合など、複数のホストを使用できる場合には、ポートマッパーがバインドするホストを、ホスト名、または IP アドレスで指定するデフォルト値 : imq.hostname の値を継承する
imq.portmapper.backlog	ポートマッパーが、要求を拒否せずに、同時に処理可能な要求の最大数を指定する。オペレーティングシステムのバックログに格納可能な、ポートマッパーによる処理を待機中の要求の数を、プロパティで設定するデフォルト値 : 50.
imq.service_name. protocol_type¹.port	jms、ssljms、admin、および ssladmin のサービスの場合のみ、指定したコネクションサービスのポート番号を指定するデフォルト値 : 0 (ポートは、ポートマッパーによって動的に割り当てられる) httpjms と httpsjms コネクションサービスを設定する場合、付録 C 「HTTP/HTTPS サポート (Enterprise Edition)」を参照
imq.service_name. protocol_type¹.hostname	jms、ssljms、admin、および ssladmin のサービスの場合のみ、複数のホストを使用できる際 (1 台のコンピュータに、複数のネットワークインタフェースカードがある場合など) に、指定したコネクションサービスが接続するホスト (ホスト名、または IP アドレス) を指定するデフォルト値 : imq.hostname の値を継承する
imq.service_name. min_threads	指定したコネクションサービスが使用するスレッドプールに初めに保持されるスレッドの数を指定するデフォルト値 : コネクションサービスによって異なる (表 5-1 を参照)
imq.service_name. max_threads	指定したコネクションサービスが使用するスレッドプールに保持されるスレッドの最大数を指定する。新しいスレッドは、それ以上追加されなくなる。この数は、0 より大きく、min_threads の値よりも大きくする必要があるデフォルト値 : コネクションサービスによって異なる (表 5-1 を参照)
imq.service_name. threadpool_model	指定したコネクションサービスに対して、スレッドをコネクション専用 (dedicated) にするのか、あるいは必要に応じてコネクションで共有 (shared) するのかどちらかを指定する。共有モデル (スレッドプール管理) の場合、ブローカがサポートするコネクションの数が増えるが、jms コネクションサービスと admin コネクションサービスでしか実装されないデフォルト値 : コネクションサービスによって異なる (表 5-1 を参照)
imq.shared. connectionMonitor_limit	共有スレッドプールモデルの場合のみ、ディストリビュータスレッドで監視できるコネクションの最大数を指定する。(すべてのコネクションを監視するのに十分なディストリビュータスレッドをシステムが割り当てる) この値が小さいほど、システムはより早くスレッドにアクティブコネクションを割り当てることができる。値を -1 に設定した場合、無制限になるデフォルト値 : オペレーティングシステムによって異なる (表 5-1 を参照)

1protocol_type は表 2-2 に記載されています。

メッセージルーター

サポートされているコネクションサービスを使用して、クライアントとブローカ間でコネクションが確立されると、メッセージのルーティングおよび配信が処理できます。

基本的な配信メカニズム

通常、ブローカで処理されるメッセージは、2 つのカテゴリに分類されます。1 つ目は、プロデューサクライアントによって送信されるコンシューマクライアント向けの JMS メッセージ、すなわちペイロードメッセージです。2 つ目は、JMS メッセージの配信をサポートするために、クライアント間で送受信される多数のコントロールメッセージです。

受信メッセージが JMS メッセージの場合、送信先のタイプ (キュー、またはトピック) に基づいて、ブローカはメッセージをコンシューマクライアントにルートします。

メッセージルーターは、意図したすべてのコンシューマにメッセージを配信すると、メモリーからそのメッセージを消去します。また、メッセージが持続的 (「信頼性のあるメッセージング」を参照) である場合、ブローカの持続データストアから、そのメッセージを削除します。

信頼性の高い配信 : 通知およびトランザクション

信頼性の高い配信 (「信頼性のあるメッセージング」を参照) の要件を追加すると、前述した配信メカニズムはさらに複雑になります。信頼性の高い配信には、ブローカとのメッセージの配信が正常に終了することと、メッセージが実際に配信される前に、ブローカがメッセージや配信情報を失うことがないようにする 2 つの要素があります。

ブローカとのメッセージの配信を正常に行うために、Message Queue は通知と呼ばれる多数のコントロールメッセージを使用します。

たとえば、プロデューサが送信先に JMS メッセージ (ペイロードメッセージ) を送信した場合、ブローカは JMS メッセージを受信したことを示すコントロールメッセージ (ブローカの通知) を送り返します。デフォルトでは、プロデューサが JMS メッセージを持続的として指定している場合に限り、Message Queue はこれを実行します。プロデューシングクライアントは、送信先への配信を保証するために、ブローカの通知を使用します (「メッセージのプロデュース」を参照)。

同様に、ブローカが JMS メッセージをコンシューマに配信した場合、コンシューミングクライアントは、メッセージを受信および処理したことを示す通知を送り返します。クライアントは、セッションオブジェクトの作成時に、これらの通知を自動的に、またはどのくらいの頻度で送信するのかを指定します。原則として、メッセージルーターは、メッセージを配信した各メッセージコンシューマ (トピックの複数のサブスクライバなど) から通知を受信していない場合、メモリーから JMS メッセージを削除しません。

トピックのサブスクリプションが永続的な場合、メッセージルーターは、各 JMS メッセージをその送信先で保持し、各永続サブスクライバがアクティブなコンシューマになると、そのメッセージを配信します。メッセージルーターは、クライアントの通知を受信するたびにそれを記録し、すべての通知を受信すると、初めて JMS メッセージを削除します (ただし、この時点で JMS メッセージの有効期限が切れている場合は除く)。

さらに、メッセージルーターは、ブローカの通知をクライアントに送り返して、クライアントの通知を受信したことを確認します。コンシューミングクライアントは、ブローカの通知を使用して、ブローカが JMS メッセージを何度も配信しないようにします (「メッセージのコンシューム」を参照)。何らかの理由で、ブローカがクライアントの通知を受信し損なうと、JMS メッセージが繰り返し配信される可能性があります。

ブローカがクライアントの通知を受信しないで、JMS メッセージを再び配信する場合、メッセージに再配信フラグが付けられます。一般的に、ブローカがクライアントの通知を受信する前にクライアントのコネクションが閉じられて、新しいコネクションが開かれると、ブローカは JMS メッセージを再配信します。たとえば、メッセージが通知される前に、キューのメッセージコンシューマがオフラインになって、別のコンシューマがキューに登録された場合、ブローカは通知されていないメッセージを新しいコンシューマに再配信します。

前述のクライアントとブローカの通知プロセスは、トランザクションに分類される JMS メッセージの配信にも適用されます。この場合、クライアントとブローカの通知は、各 JMS メッセージレベルだけでなく、トランザクションレベルでも動作します。トランザクションがコミットされると、ブローカの通知が自動的に送信されます。

ブローカはトランザクションを追跡し、トランザクションがコミットされるか、あるいは障害が発生した場合にロールバックされるようにします。このトランザクション管理は、大規模な分散トランザクションの一部であるローカルトランザクションもサポートします (「分散トランザクション」を参照)。ブローカは、これらのトランザクションがコミットされるまで、トランザクションの状態を追跡します。デフォルトでは、ブローカは起動時に、コミットされていないすべてのトランザクションを調べて、PREPARED 状態以外のトランザクションをすべてロールバックします。

信頼性の高い配信 : 持続

信頼性の高い配信のもう 1 つの局面は、メッセージが実際に配信されるまで、ブローカがメッセージ、または配信情報を保持することです。通常、メッセージは配信されたり、有効期限が切れたりするまで、メモリー内に保持されます。ただし、ブローカで障害が発生すると、これらのメッセージは失われる可能性があります。

プロデューサクライアントは、メッセージを持続に指定することができます。そのように指定すると、メッセージルーターは持続マネージャ (「持続マネージャ」を参照) にメッセージを渡します。持続マネージャはそのメッセージをデータベースまたはファイルシステムに格納するので、ブローカで障害が発生しても、メッセージを復元することができます。

メモリーリソースとメッセージフローの管理

ブローカのパフォーマンスと安定性は、使用できるシステムリソースとメモリーなどのリソースの使用効率によって異なります。特に、メッセージルーターでは、メッセージのプロデュース量がコンシューム量をかなり上回る場合には、過負荷となりメモリーリソースを使い果たしてしまうことがあります。この問題の発生を避けるために、メッセージルーターは、リソースが不十分なときでもシステムの動作を維持できるように 3 レベルのメモリー保護を使用しています。

個々の送信先のメッセージ制限物理的な送信先の属性を設定して、メッセージ数とメッセージが使用する総メモリー量の上限を指定できます (表 6-10 を参照)。また、この上限に達したときに、メッセージルーターが 4 種類の対応のうちどれを実行するかを指定できます。4 種類の制限の動作は次のとおりです。

システム全体のメッセージ制限システム全体のメッセージ制限は、二次的な保護を提供します。システム全体の制限を指定すると、システム上のすべての送信先に対して一括して適用され、メッセージの総数とすべてのメッセージによって使用される総メモリー量が制限されます (表 2-4 を参照)。どちらかのシステム全体のメッセージ制限に達した場合、メッセージルーターは新しいメッセージを拒否します。

システムメモリーのしきい値システムメモリーのしきい値は、三次的な保護を提供します。ブローカがさらに深刻な状況に陥ったときに、メモリーの過負荷を避けるためのアクションを実行できるように、使用可能なシステムメモリーのしきい値を指定できます。実行するアクションは、 green (使用可能なメモリーが十分にある)、yellow (ブローカのメモリーが減っている)、orange (ブローカのメモリーが不十分である)、red (ブローカのメモリーが不足している) といったメモリーリソースの状態によって異なります。ブローカのメモリーの状態が green から yellow、orange、red へと進むにつれ、ブローカは次のタイプの本格的なアクションを段階的に実行します。

これらのアクションはどちらもパフォーマンスを低下させます。

システムメモリーのしきい値に達する場合は、送信先ごとのメッセージ制限とシステム全体のメッセージ制限が適切に設定されていないことが原因と考えられます。場合によっては、潜在するメモリーの過負荷をしきい値がタイミングよく指摘できないことがあります。したがって、この機能に依存してメモリーリソースを制御するのではなく、メモリーリソースが最適化されるように個々の送信先とシステム全体を設定する必要があります。

メッセージルーターのプロパティ

メモリーリソースを管理するためのシステム全体の制限とシステムメモリーのしきい値の詳細は、表 2-4 を参照してください。これらのプロパティの設定については、第 5 章「ブローカの起動と設定」を参照してください。

表 2-4 メッセージルーターのプロパティ
プロパティ名	説明
imq.message.expiration. interval	有効期限が切れたメッセージを再利用させる頻度を秒単位で指定するデフォルト値 : 60
imq.system.max_count	ブローカが保持するメッセージの最大数を指定する。この値を超えるメッセージは拒否される。値を -1 に設定した場合、無制限になるデフォルト値 : -1
imq.system.max_size	ブローカが保持するメッセージの最大のサイズ (バイト、K バイト、または M バイト単位) を指定する。この値を超えるメッセージは拒否される。値を -1 に設定した場合、無制限になるデフォルト値 : -1
imq.message.max_size	メッセージの本体の最大許容サイズ (バイト、K バイト、または M バイト単位) を指定する。このサイズを超えるメッセージは拒否される。値を -1 に設定した場合、無制限になるデフォルト値 : 70m (M バイト)
imq.resource_state. threshold	指定したメモリーリソースの状態で、そのメモリーリソースがトリガーされるメモリーの利用率を指定する。リソースの状態を表す値は、green、yellow、orange、および red デフォルト値 : それぞれ、0、80、90、98
imq.resource_state.count	メモリーリソースの各状態がトリガーされたときに、一度に入力可能なメッセージの最大数を指定する。この制限は、システムメモリーがさらに不十分になると、メッセージプロデューサの処理速度を低下させるデフォルト値 : それぞれ、5000、500、50、0
imq.transaction. autorollback	PREPARED 状態の分散トランザクションをブローカの起動時に自動的にロールバックするかどうかを指定する (true/false)。false の場合は、imqcmd を使用して、手動でトランザクションをコミット、またはロールバックする必要がある (「トランザクションの管理」を参照) デフォルト値 : false

持続マネージャ

障害が発生したブローカを復元するには、メッセージの配信処理の状態を作成し直す必要があります。この場合、ブローカは、すべての持続メッセージを重要な転送情報および配信情報とともにデータストアに保存する必要があります。持続マネージャのコンポーネントは、この情報の書き込みおよび検索を管理します。

障害が発生したブローカを復元する場合、配信されていないメッセージを復元するだけでは不十分です。ブローカは、次のタスクも実行する必要があります。

持続マネージャは、このすべての状態情報の格納および検索を管理します。

ブローカが再起動すると、送信先と永続サブスクリプションの再作成、持続メッセージの復元、すべてのトランザクションの状態の復元、および配信されていないメッセージのルーティングテーブルの再作成が行われます。この後に、メッセージの配信を再開します。

Message Queue は、組み込み持続モジュールとプラグイン持続モジュールの両方をサポートしています (図 2-4 を参照)。組み込み持続は、ファイルベースのデータストアです。プラグイン持続は、JDBC^TM (Java Database Connectivity) インタフェースを使用し、JDBC 互換のデータストアを必要とします。通常、組み込み持続の方が、プラグイン持続より処理速度が速くなりますが、JDBC 互換のデータベースシステムを使用する冗長性および管理機能を好むユーザーもいます。

組み込み持続

デフォルトの Message Queue 持続ストレージソリューションは、ファイルベースのデータストアです。この方法では、メッセージ、送信先、永続サブスクリプション、トランザクションなどの持続データを保存するために、個別のファイルを使用します。

ファイルベースのデータストアは、そのデータストアが関連付けられているブローカインスタンスの名前 (instanceName) によって識別されるディレクトリに配置されます (付録 A 「Message Queue データの場所」を参照)。

ファイルベースのデータストアは、常駐先の送信先に応じてメッセージがディレクトリに格納されるように構成されています。大半のメッセージは、可変長レコードから構成されるシングルファイルに格納されます。

メッセージが追加および削除されたときの断片化を減らすために、可変長レコードファイルを圧縮できます (「送信先の圧縮」を参照)。さらに、設定可能なしきい値 (imq.persist.file.message.max_record_size) より大きいメッセージは、可変長レコードファイルではなく、メッセージに該当するファイルへ組み込み持続マネージャが格納します。これらの個々のファイルでは、ファイルが再利用できるようにファイルプールが維持されます。メッセージファイルは不要となった場合でも、削除されず、送信先ディレクトリの空きファイルのプールに追加され、新しいメッセージを格納するために使用されます。

送信先ファイルプールのファイルの最大数 (imq.persist.file.destination.message.filepool.limit) を設定できます。また、ファイルプールにおける空きファイルの割合 (imq.persist.file.message.filepool.cleanratio) を指定できます。再利用のために単にタグをつける場合と異なり、空きファイルは削除されてサイズが 0 になります。削除するファイルの割合が大きいほど、ディスク容量は小さくなりますが、ファイルプールを保持するためのオーバーヘッドが増えます。シャットダウン時に、タグの付いたファイルを削除するかどうか (imq.persist.file.message.cleanup) を指定することもできます。ファイルが削除されると、ファイルが使用するディスク容量が小さくなりますが、ブローカはシャットダウンに時間がかかるようになります。

そのほかの持続データはすべて (送信先、永続サブスクリプション、トランザクション) は、それぞれ個別のファイルに格納されます。つまり、送信先はすべて 1 つのファイルに、永続サブスクリプションはすべて別の 1 つのファイルに、といった具合になります。

信頼性を最大にするため、持続操作によりメモリー内の状態と物理的なストレージとを同期するように指定できます (imq.persist.file.sync.enabled)。この同期化は、システムクラッシュによるデータの損失をなくす上で役立ちますが、パフォーマンスが犠牲になります。

データストアには機密事項を扱うメッセージや財産的価値のあるメッセージが含まれることがあるため、...instances/instanceName/fs350/ ディレクトリは承認されていないアクセスから保護することをお勧めします。保護する方法については、「持続データの保護」を参照してください。

プラグイン持続

JDBC ドライバを介してアクセスが可能な任意のデータストアにアクセスするように、ブローカを設定することができます。この作業には、さまざまな JDBC 関連のブローカ設定プロパティの設定、適切なスキーマでデータストアを作成する Database Manager ユーティリティ (imqdbmgr) の使用が含まれます。手順および関連する設定プロパティについては、付録 B 「プラグイン持続の設定」で説明します。

持続マネージャのプロパティ

最初のプロパティを除き、表 2-5 に示されたプロパティはすべて、組み込み持続に関係しています。プラグイン持続に関係するプロパティは、表 B-1 に示されています。

表 2-5 持続マネージャのプロパティ
プロパティ名	説明
imq.persist.store	組み込みのファイルベース (file) の持続、またはプラグインの JDBC 互換 (jdbc) の持続のどちらをブローカが使用するのかを指定するデフォルト値 : file
imq.persist.file.sync. enabled	持続操作でメモリー内の状態を物理的なストレージと同期させるかどうかを指定する。true の場合、システムクラッシュによるデータ損失は回避されるが、持続操作のパフォーマンスに負荷がかかるデフォルト値 : false
imq.persist.file.message. max_record_size	組み込みのファイルベースの持続では、個別のファイルに格納されるメッセージではなく、メッセージストレージファイルに追加されるメッセージの最大サイズを指定するデフォルト値 : 1m (M バイト)
imq.persist.file. destination.message. filepool.limit	組み込みのファイルベースの持続では、送信先のファイルプールで再利用できる空きファイルの最大数を指定する。この値が大きいほど、ブローカが持続データを処理する速度が速くなる。この値を超える空きファイルは削除される。この制限を越えると、ブローカは必要に応じて追加ファイルを作成および削除するデフォルト値 : 100
imq.persist.file.message. filepool.cleanratio	組み込みのファイルベースの持続では、クリーン状態 (サイズを 0 にする) で保持される送信先のファイルプールの空きファイルの割合を指定する。この値が大きいほど、作業中にファイルを削除するのに必要なオーバーヘッドが増えるが、ファイルプールに必要なディスク容量は小さくなるデフォルト値 : 0
imq.persist.file.message. cleanup	組み込みのファイルベースの持続では、ブローカのシャットダウン時に、送信先のファイルプール内の空きファイルを削除するかどうかを指定する。値を false に設定すると、ブローカのシャットダウンが速まるが、ファイルを格納するためのディスク容量がさらに必要になるデフォルト値 : false

セキュリティマネージャ

Message Queue では、認証および承認 (アクセス制御) 機能が用意されており、暗号化機能もサポートされています。

認証機能と承認機能はユーザーリポジトリによって異なります (図 2-5 を参照)。ユーザーリポジトリには、ファイル、ディレクトリ、または名前、パスワード、グループメンバーシップなどのメッセージングシステムのユーザーに関する情報を含むデータベースがあります。ユーザー名とパスワードはブローカへのコネクションが要求されたときに、ユーザーを認証するために使用されます。ユーザー名とグループのメンバーシップは、送信先のプロデューシングメッセージ、またはコンシューミングメッセージなどの操作を承認するために、アクセス制御ファイルと一緒に使用されます。

Message Queue の管理者は、Message Queue で提供されるユーザーリポジトリ (「単層型ファイルユーザーリポジトリを使用する」を参照) を生成するか、あるいは既存の LDAP ユーザーリポジトリをセキュリティマネージャのコンポーネントに組み込みます (「ユーザーリポジトリに LDAP サーバを使用する」を参照)。単層型ファイルのユーザーリポジトリは簡単に使用できますが、セキュリティ攻撃に対して脆弱なため、評価や開発を目的とする場合にだけ使用してください。一方、LDAPユーザーリポジトリは安全なため、実稼働を目的とする場合に適しています。

認証

Message Queue のセキュリティは、パスワードベースの認証がサポートしています。クライアントがブローカへのコネクションを要求する場合、ユーザー名とパスワードを提示する必要があります。セキュリティマネージャは、クライアントから提示されたユーザー名とパスワードをユーザーリポジトリ内に格納されているものと比較します。クライアントからブローカにパスワードが送信される場合、パスワードは、Base-64 か、メッセージダイジェスト (MD) のどちらかを使用して暗号化されます。セキュリティ保護された送信については、「暗号化 (Enterprise Edition)」を参照してください。各コネクションサービスで使用する暗号化のタイプを 1 つずつ設定するか、あるいはブローカ単位で暗号化を設定することができます。

承認

クライアントアプリケーションのユーザーが認証されると、ユーザーはさまざまな Message Queue 関連のアクティビティを実行することを承認されます。セキュリティマネージャは、ユーザーベースとグループベースの両方のアクセス制御をサポートしています。ユーザー名、またはユーザーリポジトリでユーザーに割り当てられているグループに応じて、ユーザーは特定の Message Queue 操作を実行するためのアクセス権を付与されます。これらのアクセス制御は、アクセス制御プロパティファイルで指定します (図 2-5 を参照)。

ユーザーがある操作を実行しようとすると、セキュリティマネージャが、ユーザーリポジトリ内のユーザー名とグループのメンバーシップを、アクセス制御プロパティファイル内のユーザー名とグループのメンバーシップと照らし合わせます。アクセス制御プロパティには、操作に対するユーザーのアクセス権が指定されています。アクセス制御プロパティファイルでは、次の操作に対するアクセス権を指定します。

デフォルトのアクセス制御プロパティファイルは、 admin という 1 つのグループだけを明示的に参照します (「グループ」を参照)。admin グループのユーザーには、admin サービスコネクションのアクセス権が付与されます。admin サービスは、送信先の作成、ブローカの監視と制御などの管理機能を実行できます。その他のグループに定義されたユーザーは、デフォルトでは admin サービスコネクションにアクセスできません。

Message Queue の管理者は、グループを定義し、ユーザーリポジトリ内のそれらのグループとユーザーを関連付けることができます。ただし、グループは単層型ファイルのユーザーリポジトリで完全にはサポートされません。そうすると、アクセス制御プロパティファイルを編集してユーザー別およびグループ別に目的 (メッセージのプロデュースとコンシューム、またはキューの送信先のメッセージの参照) に応じて、送信先へのアクセスを指定できます。特定のユーザー、またはグループだけがアクセスできる個別の送信先、またはすべての送信先を作成できます。

さらに、ブローカを設定して、送信先の自動作成 (「自動作成 (および管理者によって作成) された送信先」を参照) を許可する場合、ブローカが送信先を自動作成するユーザーを、アクセス制御プロパティファイルを編集して管理することができます。

暗号化 (Enterprise Edition)

クライアントとブローカ間で送信されるメッセージを暗号化するには、SSL (Secure Socket Layer) 標準に基づいたコネクションサービスを使用する必要があります。SSL は、SSL 対応のブローカとクライアント間で暗号化されたコネクションを確立して、コネクションレベルのセキュリティを提供します。

Message Queue の SSL ベースのコネクションサービスを使用するには、キーツールユーティリティ (imqkeytool) を使用して、非公開キーと公開キーのペアを生成します。このユーティリティは、自己署名型証明書に公開キーを組み込んで、それを Message Queue のキーストアに配置します。Message Queueのキーストア自体は、パスワードによって保護されているため、起動時にキーストアのパスワードを入力して、ロックを解除する必要があります。「暗号化 : SSL ベースのサービスとの連動 (Enterprise Edition)」を参照

キーストアのロックが解除されると、ブローカは、コネクションを要求しているクライアントに証明書を渡すことができます。証明書を受け取ると、クライアントはその証明書を使用して暗号化されたブローカへのコネクションを設定します。

認証、承認、暗号化、およびその他のセキュリティ保護された通信に関する設定可能なプロパティを表 2-6 に示します。各プロパティの説明については、第 5 章「ブローカの起動と設定」を参照してください。

表 2-6 セキュリティマネージャのプロパティ
プロパティ名	説明
imq.authentication.type	パスワードを Base-64 コーディング (basic)、または MD5 ダイジェスト (digest) のどちらで送信するのかを指定する。ブローカでサポートされるすべてのコネクションサービスに対して、符号化を設定するデフォルト値 : digest
imq.service_name. authentication.type	パスワードを Base-64 コーディング (basic)、または MD5 ダイジェスト (digest) のどちらで送信するのかを指定する。指定したコネクションサービスの符号化を設定して、ブローカ全体の設定をオーバーライドするデフォルト値 : imq.authentication.type の値を継承する
imq.authentication. basic.user_repository	認証に使用される (Base-64 コーディング用の) ユーザーリポジトリのタイプとして、ファイルベース (file)、または LDAP (ldap) のどちらかを指定する。その他の LDAP のプロパティについては、表 8-5 を参照デフォルト値 : file
imq.authentication. client.response.timeout	ブローカからの認証要求に対するクライアントの応答をシステムが待機する時間を秒単位で指定するデフォルト値 : 180 (秒)
imq.accesscontrol. enabled	ブローカでサポートされるすべてのコネクションサービスに対して、アクセス制御を設定する (true/false)。アクセス制御プロパティファイルに指定されているように、認証されたユーザーが、コネクションサービスを使用するためのアクセス権、あるいは特定の送信先に対して特定の Message Queue 操作を実行するためのアクセス権を保持していることをシステムでチェックするかどうかを指定するデフォルト値 : true
imq.service_name. accesscontrol.enabled	指定したコネクションサービスに対して、アクセス制御を設定し (true/false)、ブローカ全体の設定をオーバーライドする。アクセス制御プロパティファイルに指定されているように、認証されたユーザーが、指定したコネクションサービスを使用するためのアクセス権、あるいは特定の送信先に対して特定の Message Queue 操作を実行するためのアクセス権を保持していることをシステムでチェックするかどうかを指定するデフォルト値 : imq.accesscontrol.enabled の値を継承
imq.accesscontrol.file. filename	ブローカインスタンスでサポートされるすべてのコネクションサービスに対して、アクセス制御プロパティファイルの名前を指定する。ファイル名には、アクセス制御ディレクトリへの相対ファイルパスを指定する (付録 A 「Message Queue データの場所」を参照) デフォルト値 : accesscontrol.properties
imq.service_name. accesscontrol.file. filename	ブローカインスタンスの指定したコネクションサービスに対して、アクセス制御プロパティファイルの名前を指定する。ファイル名には、アクセス制御ディレクトリへの相対ファイルパスを指定する (付録 A 「Message Queue データの場所」を参照) デフォルト値: imq.accesscontrol.file.filename の値を継承
imq.passfile.enabled	セキュリティ保護される通信用の (SSL、LDAP、JDBC^TM の) ユーザーパスワードをパスファイルで指定するどうか (true/false) を指定するデフォルト値 : false
imq.passfile.dirpath	パスファイルが配置されているディレクトリへのパスを指定する。これは、オペレーティングシステムによって異なるデフォルト値 : 付録 A 「Message Queue データの場所」を参照
imq.passfile.name	パスファイル名を指定するデフォルト値 : passfile
imq.keystore.property_name	SSL ベースのサービスの場合は、 SSL キーストアに関係するセキュリティプロパティを指定する。表 8-8 を参照

監視サービス

ブローカには、ブローカの動作を監視および診断するためのさまざまなコンポーネントが用意されています。たとえば、次のようなコンポーネントが含まれています。

メトリックスジェネレータ

メトリックスジェネレータは、ブローカとの間で入出力されるメッセージフロー、ブローカメモリー内のメッセージ数とそれらが消費するメモリー量、開かれているコネクションの数、使用中のスレッドの数など、ブローカの動作に関する情報を提供します。

メトリックスデータの生成をオン、またはオフにすることも、メトリックスレポートを生成する頻度を指定することもできます。

ロガー

Message Queue のロガーは、ブローカコードとメトリックスジェネレータによって生成された情報を取得し、標準出力 (コンソール)、ログファイル、Solaris^TM プラットフォーム、syslog デーモンプロセスなどの多数の出力チャネルに書き込みます。

ロガーが収集する情報のタイプと、各出力チャネルに書き込む情報のタイプを指定できます。

たとえば、ロガーが収集する情報のタイプとして、もっとも深刻で重要な情報 (エラー) からあまり重要でない情報 (メトリックスデータ) までロガーのレベルを指定できます。情報のカテゴリを重要度の高い順に、表 2-7 に示します。

表 2-7 ロギングのカテゴリ
カテゴリ	説明
ERROR	システム障害が生じる可能性のある問題点を示すメッセージ
WARNING	システム障害が生じる可能性はないが、留意すべき警告
INFO	メトリックスおよびその他の情報メッセージの報告

ロガーのレベルを設定するには、これらのカテゴリのどれかを指定します。ロガーは、指定されたカテゴリとそれより上のレベルのカテゴリのデータをすべて出力します。たとえば、ロギングに WARNING レベルを指定すると、ロガーは、警告情報とエラー情報の両方を出力します。

各出力チャネルに対して、ロガーに書き込むカテゴリを設定できます。たとえば、ロガーのレベルが INFO の場合、エラーと警告だけをコンソールに出力し、情報 (メトリックスデータ) だけをログファイルに書き込むように指定することができます。Solaris syslog の設定および使用方法については、syslog(1M)、syslog.conf(4)、および syslog(3C) のマニュアルページを参照してください。

ログファイルに出力する場合、ログファイルを閉じて新しいファイルに出力がロールオーバーされる時点を指定できます。ログファイルが指定したサイズや有効期間に達すると、そのファイルは保存されて、新しいログファイルが作成されます。ログファイルは、そのログファイルが関連付けられているブローカインスタンスの名前 (instanceName) によって識別されたディレクトリに書き込まれます (付録 A 「Message Queue データの場所」を参照)。

新しいロールオーバーログファイルが作成されると、もっとも新しい 9 個のログファイルのアーカイブが保持されます。

メトリックスメッセージプロデューサ (Enterprise Edition)

メッセージプロデューサのコンポーネントは、定期的にメトリックスジェネレータのコンポーネントから情報を受け取り、その情報をメッセージに書き込みます。その後、そのメッセージは、メッセージに含まれるメトリックス情報のタイプに応じて、多数あるメトリックストピック送信先の 1 つに送信されます。

5 つのメトリックストピック送信先があります。それらの名前と、各送信先へ配信されるメトリックスメッセージのタイプを表 2-8 に示します。

表 2-8 メトリックスのトピック送信先
トピック送信先名	メトリックスメッセージのタイプ
mq.metrics.broker	ブローカのメトリックス
mq.metrics.jvm	Java 仮想マシンのメトリックス
mq.metrics.destination_list	送信先とそれらのタイプのリスト
mq.metrics.destination.queue. monitoredDestinationName	指定した名前のキューの送信先メトリックス
mq.metrics.destination.topic. monitoredDestinationName	指定した名前のトピックの送信先メトリックス

これらのメトリックストピック送信先にサブスクライブした Message Queue クライアントは、送信先内でメッセージをコンシュームし、メッセージに含まれるメトリックス情報を処理します。とたえば、クライアントは、mq.metrics.broker 送信先にサブスクライブし、ブローカ内のメッセージの合計数といった情報を受け取り処理することができます。

メトリックスメッセージプロデューサは、メトリックスデータに相当する、名前と値のペアを含むメッセージを作成する内部 Message Queue クライアントです。メッセージのタイプは MapMessage です。これらのメッセージは、該当するメトリックストピック送信先へのサブスクライバが複数存在する場合にだけ生成されます。

メトリックスメッセージプロデューサによって生成されるメッセージのタイプは、MapMessage です。このメッセージは、含まれるメトリックスのタイプに応じて、多数の名前と値のペアから構成されます。各名前と値のペアは、メトリックスの数とその値に相当します。たとえば、ブローカメトリックスメッセージは、ブローカとの間で送受信されたメッセージの数、これらのメッセージのサイズ、現在メモリー内にあるメッセージの数とサイズなど、多数のメトリックスに関する値を含んでいます。各タイプのメトリックスメッセージで報告されるメトリックスの数に関する詳細は、メトリックスメッセージをコンシュームさせる Message Queue クライアントのプログラミング方法が説明されている『Message Queue Java Client Developer's Guide』を参照してください。

メトリックスメッセージの本体に含まれるメトリックス情報以外に、各メッセージのヘッダーには 2 つのプロパティがあります。1 つはメトリックスメッセージのタイプを指定し、もう 1 つはタイムスタンプを記録します。Message Queue クライアントアプリケーションは、これらのヘッダープロパティを使用して、メトリックスメッセージからデータを抽出し該当するタイムスタンプを記録できます。

監視サービスのプロパティ

ブローカによる情報の生成、ロギング、およびメトリックスメッセージの生成を設定する設定可能なプロパティを表 2-9 に示します。各プロパティの設定に関する説明は、第 5 章「ブローカの起動と設定」を参照してください。

表 2-9 監視サービスのプロパティ
プロパティ名	説明
imq.metrics.enabled	メトリックス情報をロガーへ書き込むかどうかを指定する (true/false)。メトリックスメッセージの生成への影響はない (imq.metrics.topic.enabled を参照) デフォルト値 : true
imq.metrics.interval	メトリックスのロギングが有効な場合 (imq.metrics.enabled=true) は、メトリックス情報がロガーへ書き込まれる時間間隔を秒単位で指定する。値を -1 に設定した場合は、情報が報告されない。メトリックスメッセージの生成の時間間隔には影響しない (imq.metrics.topic.interval を参照) デフォルト値 : -1
imq.log.level	ロガーレベル、つまり、出力チャネルへ書き込み可能な出力のカテゴリを指定する。指定したカテゴリとそれより上のレベルのカテゴリが含まれる。指定できる値は、高いものから降順に、 ERROR、WARNING、INFO であるデフォルト値 : INFO
imq.log.file.output	ログファイルに書き込むロギング情報のカテゴリを指定する。指定できる値は、縦線 (\|) で区切ったロギングのカテゴリのセット、ALL または NONE デフォルト値 : ALL
imq.log.file.dirpath	ログファイルが格納されているディレクトリへのパスを指定する。これは、オペレーティングシステムによって異なるデフォルト値 : 付録 A 「Message Queue データの場所」を参照
imq.log.file.filename	ログファイル名を指定するデフォルト値 : log.txt
imq.log.file.rolloverbytes	新しいログファイルに出力がロールオーバーされるログファイルのサイズをバイト単位で指定する。値を -1 に設定した場合、ファイルのサイズに基づいたロールオーバーは行われないデフォルト値 : -1
imq.log.file.rolloversecs	新しいログファイルに出力がロールオーバーされるログファイルの有効期間を秒単位で指定する。値を -1 に設定した場合、ファイルの有効期間に基づいたロールオーバーは行われないデフォルト値 : 604800 (1 週間)
imq.log.console.output	コンソールへ書き込むロギング情報のカテゴリを指定する。指定できる値は、縦線 (\|) で区切ったロギングのカテゴリのセット、ALL または NONE デフォルト値 : ERROR\| WARNING
imq.log.console.stream	コンソールの出力を標準出力 (OUT)、または標準エラー出力 (ERR) のどちらに書き込むかを指定するデフォルト値 : ERR
imq.log.syslog.facility	(Solaris のみ) Message Queue ブローカが記録する syslog 機能を指定する。値は、syslog(3C) のマニュアルページに示される値をミラー化する。Message Queue で使用できる値は、 LOG_USER、LOG_DAEMON、および LOG_LOCAL0 ～ LOG_LOCAL7 デフォルト値 : LOG_DAEMON
imq.log.syslog.logpid	(Solaris のみ) メッセージとともにブローカのプロセス ID を記録するかどうかを指定する (true/false) デフォルト値 : true
imq.log.syslog.logconsole	(Solaris のみ) メッセージを syslog に送信できない場合に、システムコンソールにメッセージを出力するかどうかを指定する (true/false) デフォルト値 : false
imq.log.syslog.identity	(Solaris のみ) syslog に記録される各メッセージの先頭に付加する識別情報文字列を指定するデフォルト値 : imqbrokerd_ の後にブローカインスタンス名
imq.log.syslog.output	(Solaris のみ) syslogd(1M) に書き込むロギング情報のカテゴリを指定する。指定できる値は、縦線 (\|) で区切ったロギングのカテゴリのセット、ALL または NONE デフォルト値 : ERROR
imq.log.timezone	ログのタイムスタンプのタイムゾーンを指定する。識別子は、java.util.TimeZone.getTimeZone() が使用しているものと同じである次に例を示す。GMT、America/LosAngeles、Europe/Rome、Asia/Tokyo デフォルト値 : 該当地域のタイムゾーン
imq.metrics.topic.enabled	メトリックスメッセージの生成を有効にするかどうかを指定する (true/false)。false の場合、メトリックストピック送信先へサブスクライブしようとすると、クライアント側の例外がスローされるデフォルト値 : true
imq.metrics.topic.interval	メトリックトピック送信先へ送信するメトリックメッセージを生成する時間間隔を秒単位で指定するデフォルト値 : 60
imq.metrics.topic.persist	メトリックスメッセージが持続メッセージかどうかを指定する (true/false) デフォルト値 : false
imq.metrics.topic.timetolive	メトリックストピック送信先へ送信されるメトリックスメッセージの有効期間を秒単位で指定する。デフォルト値 : 300

物理的な送信先

Message Queue のメッセージングは、メッセージの 2 段階配信を前提としています。メッセージは最初にプロデューサクライアントから、ブローカの送信先に配信され、次にブローカの送信先から 1 つまたは複数のコンシューマクライアントに配信されます。2 つのタイプの送信先があります (「プログラミングドメイン」を参照)。それらのタイプは、キュー (ポイントツーポイント配信モデル) とトピック (パブリッシュ / サブスクライブ配信モデル) です。これらの送信先は、受信メッセージがコンシューマクライアントにルーティングされる前に整列化するブローカの物理的なメモリーの場所を表しています。

この節では、キューとトピックという 2 つのタイプの物理的な送信先のプロパティと動作について説明します。

キューの送信先

キューの送信先は、ポイントツーポイントメッセージングで使用されます。メッセージは、送信先に配信対象を登録している多数のコンシューマのうちの 1 つだけに最終的に配信されるようになっています。メッセージはメッセージプロデューサから到着すると、キューに入って、単一のメッセージコンシューマに配信されます。

複数のコンシューマへのキュー配信

1 つのキュー送信先内のメッセージはシングルコンシューマにだけ配信されますが、Message Queue は、複数のコンシューマをキューに登録できます。ブローカは受信メッセージを異なる複数のコンシューマにルートし、それらの間で負荷を分散できます。

複数のコンシューマへのキュー配信を実装するには、次の、キュー送信先属性に基づくロードバランスの方法を使用します。

コンシューマの数がこの 2 つの属性値の合計を超えた場合、新しいコンシューマは拒否されます。(Message Queue Platform Edition はキューあたり最大 3 つのコンシューマ (2 つはアクティブ、1 つはバックアップ) をサポートします。Message Queue Enterprise Edition がサポートするコンシューマの数は無制限です。

ロードバランスメカニズムでは、さまざまなコンシューマがメッセージをコンシュームする度合いを考慮します。このメカニズムは、次のように動作します。

キュー送信先内のメッセージは、設定可能なサイズ (キュー送信先の consumerFlowLimit 属性) にまとめられ、新たに使用可能になったアクティブコンシューマにキューに登録された順序でルートされます。これらのメッセージが配信された後、キューに到着した追加メッセージは、コンシューマが使用可能になったとき、つまり設定可能なパーセンテージ分だけ、以前に配信されたメッセージをコンシューマがコンシュームしたときに、一括してそのコンシューマにルートされます。各コンシューマへのディスパッチ速度は、コンシューマの現在の容量とメッセージの処理速度によって異なります。

メッセージの生成速度が遅い場合は、ブローカがアクティブコンシューマ間で不均等にメッセージをディスパッチしている可能性があります。必要な数以上のアクティブコンシューマが存在する場合、一部のコンシューマはメッセージを受信しないことがあります。

アクティブコンシューマに障害が生じると、1 番目のバックアップコンシューマがアクティブになり、障害の生じたコンシューマの動作を引き継ぎます。キュー送信先に複数のアクティブコンシューマがある場合は、メッセージがコンシュームされる順序は保証されません。

ブローカクラスタ環境における複数のコンシューマへの配信では、ローカルコンシューマに高いプライオリティを設定できます。キュー送信先属性である localDeliveryPreferred を使用すると、プロデューサのホームブローカ、つまりプロデューサのメッセージ送信先となるブローカ (ローカルブローカ) にコンシューマが存在しない場合にだけ、メッセージをリモートコンシューマへ配信するように指定できます。このように指定すると、リモートコンシューマへのルーティング (それらのホームブローカを経由) がスループットの低下を招く可能性のある状況で、パフォーマンスを向上させることができます。この属性を使用する場合は、送信先の範囲をローカルだけの配信に制限しないようにしてください (表 6-10 を参照)。

メモリーの考慮事項

メッセージは、長期間キューに存在することができるため、メモリーリソースが問題になる可能性があります。キューに割り当てるメモリーが多すぎると、メモリーが十分に利用されず、少なすぎると、メッセージが拒否されます。柔軟性を考慮し、各キューの負荷需要に基づいて、キューの作成時に物理的なプロパティを設定できます。このようなプロパティには、キュー内のメッセージの最大数、キュー内のメッセージに割り当てる最大メモリー、キュー内のメッセージの最大サイズがあります (表 6-10 を参照)。

トピックの送信先

トピックの送信先は、パブリッシュ / サブスクライバメッセージングで使用されます。メッセージは、送信先に配信対象を登録しているすべてのコンシューマに最終的に配信されるようになっています。メッセージはプロデューサから送信されてくると、トピックをサブスクライブするすべてのコンシューマにルートされます。コンシューマがトピックの永続サブスクリプションを登録している場合、コンシューマは、トピックにメッセージが配信されるときに、アクティブになっている必要はありません。コンシューマが再びアクティブになるまで、ブローカがメッセージを保存し、配信するからです。

通常、メッセージはトピックの送信先に長期間保存されることがないため、メモリーリソースは大きな問題にはなりません。しかし、送信先で受信されるメッセージの最大許容サイズを設定することは可能です (表 6-10 を参照)。

自動作成 (および管理者によって作成) された送信先

Message Queue メッセージサーバは、メッセージングシステムの中心的なハブであるため、そのパフォーマンスと信頼性が、エンタープライズアプリケーションの成功に向けての重要な鍵となります。送信先は、送信先が処理するメッセージの数とサイズ、および登録するメッセージコンシューマの数と永続性によっては、リソースを著しくコンシュームする可能性があるので、メッセージサーバのパフォーマンスと信頼性を確保するために、送信先を綿密に管理する必要があります。したがって、アプリケーションのための送信先の作成、送信先の監視、必要に応じたリソース要件の再構成が、管理者の基本的な業務になります。

しかし、送信先を動的に作成するのが望ましい場合もあります。たとえば、開発およびテストサイクル中に、管理者の介入なしで、必要に応じてブローカに送信先を自動的に作成させる必要がでてくる場合があります。

Message Queue は、この自動作成機能をサポートしています。自動作成を有効にすると、実在しない送信先に、MessageConsumer や MessageProducer がアクセスしようとしたときに、ブローカが送信先を自動的に作成します。ただし、クライアントアプリケーションのユーザーは、自動作成の権限を保持する必要があります (「送信先自動作成アクセス制御」を参照)

送信先が明示的ではなく自動的に作成される場合、同じ送信先名を使用する異なるクライアントアプリケーション間でクラッシュが発生したり、送信先をサポートするのに必要なリソースによって、システムのパフォーマンスが低下したりする可能性があります。このため、自動作成された送信先は、それ以降使用されない状態、つまり、それ以降メッセージコンシューマクライアントを保持せず、メッセージを一切含まない状態になると、ブローカによって自動的に破棄されます。ブローカが再起動すると、持続メッセージが含まれている場合にだけ、自動作成された送信先が再び作成されます。

Message Queue メッセージサーバでは、表 2-10 に示すプロパティを使用して、自動作成機能を有効または無効に設定できます。各プロパティの説明については、第 5 章「ブローカの起動と設定」を参照してください。

表 2-10 自動作成の設定プロパティ
プロパティ名	説明
imq.autocreate.topic	ブローカでトピックの送信先の自動作成を許可するかどうかを指定する (true/false) デフォルト値 : true
imq.autocreate.queue	ブローカでキューの送信先の自動作成を許可するかどうかを指定する (true/false) デフォルト値 : true
imq.autocreate.destination. maxNumMsgs	自動作成された送信先で許容されるコンシュームされないメッセージの最大数を指定するデフォルト値 : 100,000
imq.autocreate.destination. maxTotalMsgBytes	送信先でコンシュームされないメッセージ用として許容されるメモリーの最大量 (バイト単位) を指定するデフォルト値 : 10m (M バイト)
imq.autocreate.destination. limitBehavior	メモリー制限のしきい値に達したときのブローカの応答方法を指定する。値は、次のどれかになる FLOW_CONTROL - プロデューサの低速化 REMOVE_OLDEST - もっとも古いメッセージの廃棄 REMOVE_LOW_PRIORITY - メッセージの有効期限に従い優先度が最低のメッセージを破棄する REJECT_NEWEST - 最新のメッセージを拒否するデフォルト値 : REJECT_NEWEST
imq.autocreate.destination. maxBytesPerMsg	自動作成された送信先で許容されるシングルメッセージの最大サイズをバイト単位で指定するデフォルト値 : 10k (10,240)
imq.autocreate.destination. maxNumProducers	送信先で許容されるプロデューサの最大数を指定する。この制限に達すると、新しいプロデューサを作成できないデフォルト値 : 100
imq.autocreate.destination. isLocalOnly	ブローカクラスタに対してのみ適用。送信先がそのほかのブローカに複製されないように指定する。つまり、メッセージの配信をローカルコンシューマ (送信先の作成元にあるブローカに接続されたコンシューマ) だけに制限する。いったん送信先が作成されると、この属性は更新できないデフォルト値 : false
imq.autocreate.queue maxNumActiveConsumers	自動作成されたキュー送信先からのロードバランスされた配信でアクティブにできるコンシューマの最大数を指定する。値を -1 に設定した場合、無制限になるデフォルト値 : 1
imq.autocreate.queue. maxNumBackupConsumers	自動作成されたキュー送信先からのロードバランスされた配信で障害が生じた場合に、アクティブコンシューマに取って代わることができるバックアップコンシューマの最大数を指定する。値を -1 に設定した場合、無制限になるデフォルト値 : 0
imq.autocreate.queue. consumerFlowLimit	1 つのバッチでコンシューマに配信されるメッセージの最大数を指定する。ロードバランスされたキュー配信では、ロードバランスされる前に、最初にキューに入っていてアクティブコンシューマにルートされるメッセージの数となる (「複数のコンシューマへのキュー配信」を参照)。この制限は、各コネクションの送信先のコンシューマに対して小さい値を設定することでオーバーライドできる (『Message Queue Java Client Developer's Guide』のコネクションファクトリ属性の説明を参照)。値を -1 に設定した場合、無制限になるデフォルト値 : 1000
imq.autocreate.topic. consumerFlowLimit	1 つのバッチでコンシューマに配信されるメッセージの最大数を指定する。値を -1 に設定した場合、無制限になる。デフォルト値 : 1,000
imq.autocreate.queue. localDeliveryPreferred	ブローカクラスタ内のロードバランスされたキュー配信にだけ適用される。ローカルブローカ上にコンシューマが存在しない場合にだけ、メッセージがリモートコンシューマに配信されるように指定する。自動作成された送信先をローカルだけの配信に制限してはならない (isLocalOnly = false) デフォルト値 : false

一時送信先

一時送信先は、ほかのクライアントに送信したメッセージに対する応答を受信するために送信先が必要な場合に、クライアントが JMS API を使用して明示的に作成および破棄します。これらの送信先は、送信先が作成されたコネクションの存続期間中にだけ、ブローカによって保持されます。管理者が一時送信先を破棄することはできません。また、一時送信先が使用されている間は、クライアントアプリケーションが一時送信先を破棄することもできません。管理者が作成した送信先や自動作成された送信先 (持続メッセージを保持する) と違って、一時送信先は、継続的には格納されず、ブローカの再起動時に作成し直されることもありません。ただし、Message Queue 管理ツールからは認識できます (表 6-9 を参照)。

マルチブローカクラスタ (Enterprise Edition)

Message Queue Enterprise Edition は、複数の連結したブローカインスタンス、すなわち、ブローカのクラスタを使用したメッセージサーバの実装をサポートしています。クラスタのサポートによって、メッセージサーバのスケーラビリティが提供されます。

ブローカに接続するクライアントの数や配信されるメッセージの数が増えると、ブローカは最終的に、ファイル記述子やメモリーの制限などのリソースの限界を超えてしまいます。増え続ける負荷に対処するための 1 つの方法は、Message Queue メッセージサーバにブローカ、つまり、ブローカインスタンスを追加して、クライアントのコネクションとメッセージの配信を複数のブローカに分散することです。

また、複数のブローカを使用してネットワークの帯域幅を最適化することもできます。たとえば、一連のリモートブローカ間で、速度の遅い、長距離のネットワークリンクを使用する一方で、個々のブローカインスタンスへのクライアントの接続に、速度の速いリンクを使用することができます。

異なるユーザーリポジトリを保持するワークグループに対応したり、ファイアウォールの制限に対処したりする場合など、ブローカのクラスタを使用する理由はほかにも存在しますが、フェイルオーバーはこれに含まれません。Message Queue は、障害の生じたコネクションを、クラスタ内の別のブローカを使用して再確立できますが、状態情報は失われてしまいます。そのため、クラスタ内の 1 つのブローカを、障害が発生した別のブローカの自動バックアップとして使用することはできません。

つまり、現時点では、Message Queue は高可用性メッセージサーバをサポートしていません。ただし、Sun クラスタソフトウェアと高可用性データベースを使用して、ブローカのフェイルオーバーを提供できます。また、複数のブローカを使用して、カスタマイズされたフェイルオーバーソリューションを実装するように、メッセージングアプリケーションを設計することもできます。

次の節では、Message Queue のブローカのクラスタのアーキテクチャと内部機能について説明します。

マルチブローカのアーキテクチャ

図 2-7 に示すように、マルチブローカのメッセージサーバを使用すると、クライアントのコネクションを多数のブローカインスタンスに分散することができます。クライアント側から見た場合、各クライアントは個々のブローカ (クライアントのホームブローカ) に接続し、ホームブローカがクラスタ内の唯一のブローカであるかのように、メッセージを送受信します。しかし、サーバ側から見た場合、ホームブローカは、クラスタ内のほかのブローカと並行して動作し、直接接続しているメッセージプロデューサとコンシューマに配信サービスを提供します。

理論的には、クラスタ内のブローカに、任意のトポロジで接続することは可能です。ただし、図 2-7 に示すように、Message Queue は、完全に接続されたクラスタ、すなわち、各ブローカがクラスタ内のほかのブローカすべてに直接接続するトポロジだけをサポートしています。

メッセージ配信

マルチブローカの設定では、各送信先がクラスタ内のすべてのブローカで複製されます。一部の例外を除き、クラスタ環境内の送信先属性は一括して送信先のすべてのインスタンス、つまり、個々の送信先インスタンスではなくクラスタ全体に適用されます。また、isLocalOnly 属性が true に設定された送信先は、クラスタ内で複製されません。詳細は、表 6-10 の送信先属性の説明を参照してください。

各ブローカは、ほかのすべてのブローカの送信先に対して登録されたメッセージコンシューマを認識しています。このため、各ブローカは、ブローカに直接接続しているメッセージプロデューサから、リモートのメッセージコンシューマにメッセージをルートし、リモートのプロデューサから、ブローカに直接接続しているコンシューマにメッセージを配信することができます。

クラスタ設定では、各メッセージプロデューサが直接接続しているブローカが、そのプロデューサによって送信されたメッセージのルートを行います。したがって、持続メッセージの格納とルートは、両方ともメッセージのホームブローカによって行われます。

クラスタ内のブローカ間のトラフィックを最小限に抑えるため、送信先からクライアントランタイムへのメッセージの配信は、コンシューマコネクションのフロー制御メカニズムによって制限されています。この方法で、メッセージは、ターゲットブローカに接続されたコンシューマに配信される場合にだけブローカ間で送信されるため、ブローカ間での不要なメッセージの受け渡しをなくすことができます。また、複数のコンシューマへのキュー配信など、場合によっては、ローカルコンシューマへの配信にリモートコンシューマへの配信より高いプライオリティを指定することで、ブローカ間のトラフィックを最小限にすることもできます (表 6-10 の localDeliveryPreferred キュー送信先属性を参照)。

クライアントとメッセージサーバ間に安全で暗号化されたメッセージ配信が必要となる場合は、クラスタ内のブローカ間のメッセージ配信も保護するようにクラスタを設定できます (「ブローカ間の安全なコネクション」を参照)。

クラスタの同期化

管理者がブローカの送信先を作成、または破棄すると、この情報がクラスタ内のほかのすべてのブローカに自動的に伝えられます。同様に、メッセージコンシューマがホームブローカに登録された場合や、明示的、またはクライアントやネットワークの障害やホームブローカのダウンが原因で、コンシューマがホームブローカから接続を解除された場合に、コンシューマについての関連情報がクラスタ全体に伝えられます。永続サブスクリプションに関する情報も同じように、クラスタ内のすべてのブローカに伝えられます。

通常、送信先やメッセージコンシューマに関する情報を特定のブローカに伝える場合、共有リソースで変更が行われたときに、ブローカがオンラインになっている必要があります。ブローカがクラッシュして再起動していたり、新しいブローカをクラスタに動的に追加していたりして、ブローカがオフラインになっているときにこのような変更が行われると、どうなるかについて、次に説明します。

オフラインになったブローカや新たに追加されたブローカを収容するため、Message Queue は、クラスタ内のすべての持続エンティティに加えられた変更の記録を維持します。この記録は、作成または破棄されたすべての送信先とすべての永続サブスクリプションに関する記録です。ブローカはクラスタに動的に追加されると、最初に、この設定変更記録から送信先および永続サブスクライバの情報を読み取ります。ブローカはオンラインになったときに、現在のアクティブコンシューマに関する情報をほかのブローカと交換します。この情報を使用して、新しいブローカはクラスタに完全に統合化されます。

設定変更記録は、クラスタ内の 1 つのブローカ、すなわち、マスターブローカとして設定されているブローカに管理されます。クラスタにブローカを動的に追加する場合、マスターブローカがキーポイントになるため、常にこのブローカを最初に起動しておく必要があります。マスターブローカがオンラインになっていないと、クラスタ内のほかのブローカが初期化を実行できません。

マスターブローカがオフラインになると、ほかのブローカが設定変更記録にアクセスできなくなり、Message Queue は送信先と永続サブスクリプションをクラスタ全体に伝えられません。このような状況では、送信先または永続サブスクリプションを作成または破棄しようとすると (あるいは、永続サブスクリプションの再有効化のようなさまざまな関連操作を実行しようとすると)、例外が生じます。


注	負荷の高いネットワークトラフィックやサイズの大きいメッセージは、クラスタ内のコネクションを妨げることがあります。遅延が多くなると、ロックプロトコルがタイムアウトになることがあります。その結果、クライアントは、永続サブスクライバまたはキューメッセージコンシューマを作成しようとしたときに、例外を受け取ることがあります。通常、これらの問題は、高速のコネクションを使用することによって回避できます。

基幹アプリケーション環境の場合、設定変更記録の偶発的な破損や、マスターブローカの障害に対応するために、設定変更記録を定期的にバックアップすることをお勧めします。これは imqbrokerd コマンドの -backup オプション (表 5-2 を参照) を使用すると実行できます。このオプションでは、設定変更記録を含んだバックアップファイルを作成する方法が提供されます。その後で、-restore オプションを使用して、設定変更記録を復元することができます。

必要に応じて、マスターブローカの役割を果たすブローカを変更することができます。これを実行するには、設定変更記録をバックアップし、適切なクラスタ設定プロパティ (表 5-3 を参照) を変更して新しいマスターブローカを指定した後、-restore オプションを使用して新しいマスターブローカを再起動します。

開発環境でのクラスタの使用

クラスタをテストに使用し、スケーラビリティやブローカの復元が重視されない開発環境では、マスターブローカはさほど必要ありません。マスターブローカなしで設定した環境の場合、Message Queue はほかのブローカを起動するために、マスターブローカを実行する要件を緩和し、送信先や永続サブスクリプションの変更を行って、この変更をクラスタ内で実行中のすべてのブローカに伝えることを許可します。ただし、ブローカがオフラインになって、その後で復元された場合、オフライン中に行われた変更は同期化されません。

通常、テスト環境の場合、送信先は自動作成 (「自動作成 (および管理者によって作成) された送信先」を参照) され、これらの送信先の永続サブスクリプションは、テストしているアプリケーションによって作成および破棄されます。送信先と永続サブスクリプションにおけるこれらの変更は、クラスタ全体に伝えられます。ただし、マスターブローカを使用する環境を再設定すると、Message Queue は送信先および永続サブスクリプションを変更し、クラスタ全体にこれらの変更を伝えるために、マスターブローカを起動しておく要件を再び強要するようになります。

クラスタ設定プロパティ

クラスタ内の各ブローカは、起動時に、クラスタ内のほかのブローカに関する情報 (ホスト名とポート番号) を受け取る必要があります。この情報は、クラスタ内のブローカ間で、コネクションを確立する際に使用されます。各ブローカは、マスターブローカ (使用している場合) のホスト名とポート番号についても把握する必要があります。

クラスタ内のすべてのブローカは、共通のクラスタ設定プロパティを使用する必要があります。この共通化は、各ブローカが起動時に参照する中央の 1 つのクラスタ設定ファイルに、クラスタ設定プロパティを配置することで実現できます。

また、クラスタ設定プロパティを複製して、個別のブローカに提供することもできます。ただし、これを行うとクラスタ設定に矛盾を引き起こすことがあるため、お勧めしません。クラスタ設定プロパティを 1 つのファイルだけにすることで、すべてのブローカが同じ情報を読み取るようになります。

クラスタ設定ファイルは、一連のブローカに共通するすべてのブローカ設定プロパティを格納できます。本来、クラスタ設定ファイルは、クラスタを設定するためのものですが、クラスタ内のすべてのブローカに共通するほかのブローカのプロパティを格納するのにも使用できます。

Message Queue クライアントランタイム

Message Queue クライアントランタイムは、クライアントアプリケーションに Message Queue メッセージサービスへのインタフェースを提供します。つまり、クライアントランタイムによって、「JMS プログラミングモデル」に記載されるすべての JMS プログラミングオブジェクトが Java クライアントアプリケーションに提供され、該当する C インタフェースが C クライアントアプリケーションに提供されます。Message Queue クライアントランタイムは、クライアントが送信先にメッセージを送信し、送信先からメッセージを受信するために必要なすべての操作をサポートします。

この節では、Message Queue クライアントランタイムの動作方法について詳しく説明します。クライアントアプリケーションの設計と、Java クライアントランタイムおよび C クライアントランタイムのパフォーマンスに影響を及ぼす要因については、それぞれ『Message Queue Java Client Developer's Guide』と『Message Queue C Client Developer's Guide』で説明されています。

図 2-8 に、クライアントアプリケーションと Message Queue クライアントランタイム間の対話におけるメッセージのプロデュースとコンシューム、および Message Queue クライアントランタイムと Message Queue メッセージサーバ間の対話におけるメッセージの配信について示します。

メッセージのプロデュース

メッセージのプロデュースでは、クライアントによってメッセージが作成され、ブローカ上の送信先へのコネクションを介して送信されます。MessageProducer オブジェクトのメッセージ配信モードが、持続的 (配信を 1 回だけ保証する) に設定されている場合、メッセージが送信先に配信されて、ブローカの持続データストアに保存されたことをブローカが通知するまで、クライアントスレッドがブロックされます。メッセージが持続的でない場合、ブローカの通知メッセージ (「Ack」というプロパティ名で呼ばれる) は返されず、クライアントスレッドはブロックされません。

メッセージのコンシューム

メッセージのコンシュームは、プロデュースより複雑です。ブローカの送信先に到着したメッセージは、次の条件に基づいて Message Queue クライアントランタイムへのコネクションで配信されます。

図 2-9 に示されるように、コネクションで配信されるメッセージは、適切な Message Queue セッションに分散されます。ここで、メッセージは適切な MessageConsumer オブジェクトによってコンシュームされるために、キューに入れられます。メッセージは、1 つずつ各セッションキューからフェッチされ (セッションはシングルスレッドになる)、receive メソッドを呼び出すクライアントスレッドによって同期的、または MessageListener オブジェクトの onMessage メソッドを呼び出すセッションスレッドによって非同期的にコンシュームされます。

図 2-9 Message Queue クライアントランタイムへのメッセージの配信

ブローカがクライアントランタイムにメッセージを配信する場合、ブローカはそれに応じてメッセージをマークしますが、メッセージが受信、またはコンシュームされたかどうかは、実際には把握していません。このため、ブローカは、ブローカの送信先からメッセージを削除する前に、クライアントがメッセージの受信を通知するのを待ちます。

Message Queue管理対象オブジェクト

管理対象オブジェクトを使用すると、クライアントアプリケーションコードがプロバイダに依存しなくなります。これはクライアントアプリケーションが使用するオブジェクトに、プロバイダに依存しない方法で、プロバイダ固有の実装と設定情報をカプセル化することによって実現できます。管理対象オブジェクトは、管理者が作成および設定し、ネームサービスに格納されます。クライアントアプリケーションは、標準 JNDI 検索コードを介して管理対象オブジェクトにアクセスします。

Message Queue は、 ConnectionFactory と Destination の 2 つのタイプの管理対象オブジェクトを提供します。どちらもプロバイダの固有情報をカプセル化し、クライアントアプリケーション内でいろいろな方法で使われます。ConnectionFactory オブジェクトは、メッセージサーバへのコネクションを作成する際に使用され、Destination オブジェクトは、物理的な送信先を識別する際に使用されます。

管理対象オブジェクトで、Message Queue メッセージサーバの制御および管理を非常に簡単に行うことができます。

この仕組みによって、Message Queue の管理者はメッセージサーバの設定詳細を管理することが可能となり、同時に、クライアントアプリケーションがプロバイダに依存しなくなります。このため、クライアントアプリケーションは、プロバイダ固有の構文およびオブジェクトの命名規則 (「JMS プロバイダへの非依存性」を参照)、またはプロバイダ固有の設定プロパティを把握する必要がありません。

管理対象オブジェクトは、第 7 章「管理対象オブジェクトの管理」に記載された Message Queue 管理ツールを使用して作成します。管理対象オブジェクトを作成する場合、オブジェクトを作成するときに設定した Message Queue 固有の設定値が、クライアントアプリケーションによって変更されないように、オブジェクトを読み取り専用に設定することができます。つまり、クライアントコードが読み取り専用の管理対象オブジェクトに、属性値を設定することはできません。また、「クライアントの起動時の属性値のオーバーライド」に示すように、管理者がクライアントアプリケーションの起動オプションを使用して、これらの値をオーバーライドすることもできません。

クライアントアプリケーションは、ConnectionFactory と Destination の両方の管理対象オブジェクトをインスタンス化することができますが、管理対象オブジェクトの基本目的 (Message Queue の管理者が、アプリケーションに必要なブローカリソースの制御とそのパフォーマンスの調整を行えるようにする) が徐々に失われます。また、管理対象オブジェクトを直接インスタンス化すると、クライアントアプリケーションは、プロバイダに依存しないものではなく、プロバイダに依存したものになります。

コネクションファクトリ管理対象オブジェクト

ConnectionFactory オブジェクトは、クライアントアプリケーションと Message Queue メッセージサーバ間の物理的なコネクションを確立する場合に使用します。また、コネクションの動作や、ブローカにアクセスするためにコネクションを使用するクライアントランタイムの動作を指定する場合にも使用します。

分散トランザクション (「ローカルトランザクション」を参照) をサポートする場合は、分散トランザクションをサポートする特殊な XAConnectionFactory オブジェクトを使用する必要があります。

ConnectionFactory 管理対象オブジェクトを構成することによって、オブジェクトがプロデュースするすべてのコネクションに共通する属性値 (プロパティ) を指定します。ConnectionFactory オブジェクトと XAConnectionFactory オブジェクトは、一連の同じ属性値を共有します。これらの属性値は、影響を及ぼす動作に基づいて、いくつかのカテゴリに分類されます。

各カテゴリと対応する属性については、『Message Queue Java Client Developer's Guide』で詳しく説明します。Message Queue の管理者は、これらの属性値の調整を行わなければならない場合もありますが、クライアントアプリケーションのパフォーマンスをチューニングするために、調整が必要な属性を判断するのは、通常、アプリケーション開発者です。表 7-3 に、属性の概要をアルファベット順に示します。

送信先管理対象オブジェクト

Destination 管理対象オブジェクトは、公に名前の付けられた Destination オブジェクトに対応するブローカの物理的な送信先 (キュー、またはトピック) を表しています。この 2 つの属性を表 2-11 に示します。Destination オブジェクトを作成すると、クライアントアプリケーションの MessageConsumer オブジェクトまたは MessageProducer オブジェクト、あるいはその両方が、対応する物理的な送信先にアクセスできるようになります。

クライアントの起動時の属性値のオーバーライド

Java アプリケーションだけでなく、メッセージングアプリケーションの起動時にも、コマンド行からシステムプロパティを指定できます。この方法は、クライアントアプリケーションコードで使用されている管理対象オブジェクトの属性値をオーバーライドすることもできます。たとえば、JNDI 検索を介してアクセスするクライアントアプリケーションコードの管理対象オブジェクトの設定をオーバーライドすることが可能です。

クライアントアプリケーションの起動時に、管理対象オブジェクトの設定をオーバーライドするには、次のようなコマンド行の構文を使用します。

表 2-11 送信先の属性
属性/プロパティ名	説明
imqDestinationName	物理的な送信先のプロバイダ固有名を指定する。物理的な送信先を作成したときに、この名前を指定する。送信先名には、英数字 (空白文字は含まない) だけを使用する必要がある。送信先名は、英字や "_" および "$" で開始できる。文字列「mq.」で開始することはできないデフォルトは Untitled_Destination_Object
imqDestinationDescription	オブジェクトの管理に役立つ情報を指定する。デフォルト値 : 送信先オブジェクトの説明

たとえば、クライアントアプリケーションをクライアントコードでアクセスされる ConnectionFactory 管理対象オブジェクトに指定されたブローカとは異なるブローカに接続する場合、別のブローカの imqBrokerHostName と imqBrokerHostPort を設定するために、オーバーライドのコマンド行を使用して、クライアントアプリケーションを起動することができます。

ただし、管理対象オブジェクトが読み取り専用に設定されている場合、オーバーライドのコマンド行を使用して、その属性値を変更することはできません。オーバーライドの指定は無視されます。

前へ目次索引次へ
Sun Java System Message Queue 3.5 SP1 管理ガイド