|
| |
| Sun Java System Message Queue 3 2005Q4 管理ガイド | |
第 8 章
管理対象オブジェクトの管理管理対象オブジェクトでは、プロバイダ固有の設定およびネーミング情報をカプセル化することにより、JMS プロバイダ間で移植可能なクライアントアプリケーションを開発できます。Message Queue の管理者は、通常、クライアントアプリケーションがメッセージの送受信のためのブローカ接続を取得する際に使用する管理対象オブジェクトを作成します。
この章では、オブジェクトマネージャーユーティリティー (imqobjmgr) を使用して、管理対象オブジェクトを作成および管理する方法について説明します。この章は、次の節から構成されています。
オブジェクトストア管理対象オブジェクトは、即時に使用可能なオブジェクトストアに配置されます。クライアントアプリケーションは、JNDI (Java Naming and Directory Interface) を介して、このオブジェクトストアに配置された管理対象オブジェクトにアクセスします。使用できるオブジェクトストアには、標準 LDAP (Lightweight Directory Access Protocol) ディレクトリサーバーとローカルファイルシステムのディレクトリの 2 種類があります。
LDAP サーバーオブジェクトストア
LDAP サーバーは、運用メッセージングシステム用のオブジェクトストアとしてお勧めします。LDAP サーバーは、分散システムでの使用を考慮した設計になっており、本稼働環境で役立つセキュリティー機能を備えています。
LDAP 実装は、多数のベンダーによってサポートされています。Message Queue の管理ツールで LDAP サーバー上のオブジェクトストアを管理するには、最初に、Java オブジェクトを格納して JNDI 検索を実行するようにサーバーを設定する必要がある場合があります。詳細については、使用する LDAP 実装に付属のマニュアルを参照してください。
LDAP サーバーをオブジェクトストアとして使用するには、表 8-1 に示す属性を指定する必要があります。これらの属性は、次のように分類されます。
- 初期コンテキスト: java.naming.factory.initial 属性は、サーバーでの JNDI 検索の初期コンテキストを指定します。LDAP オブジェクトストアの場合、この属性の値は固定です。
- ロケーション: java.naming.provider.url 属性は、LDAP サーバーの URL とディレクトリパスを指定します。指定したパスが存在することを確認する必要があります。
- セキュリティー: java.naming.security.principal、java.naming.security.credentials、および java.naming.security.authentication 属性は、オブジェクトストアにアクセスを試みる呼び出し元の認証を制御します。これらの属性の正確な形式と値は、LDAP サービスプロバイダによって異なります。詳細について、およびセキュリティー情報がすべての操作に対して必要か、または格納されたデータを変更する操作に対してのみ必要かについては、使用する LDAP 実装に付属のマニュアルを参照してください。
ファイルシステムオブジェクトストア
Message Queue では、管理対象オブジェクトのオブジェクトストアとしてローカルファイルシステムのディレクトリを使用することもサポートされています。この方法は、本稼動システムにはお勧めしませんが、開発環境で非常に簡単に扱えるという利点があります。ただし、複数のコンピュータノードに配備されているクライアントに対して、一元化されたオブジェクトストアとしてディレクトリを使用する場合は、それらすべてのクライアントがディレクトリへのアクセス権を持っている必要があります。また、ディレクトリへのアクセス権を持つユーザーはすべて、Message Queue の管理ツールを使用して管理対象オブジェクトを作成および管理できます。
ファイルシステムのディレクトリをオブジェクトストアとして使用するには、表 8-2 に示す属性を指定する必要があります。これらの属性の意味は、前述の LDAP オブジェクトストアの場合とほとんど同じですが、java.naming.provider.url 属性では、オブジェクトストアを格納するディレクトリのディレクトリパスを指定します。このディレクトリが存在していて、Message Queue の管理ツールのユーザーと、ストアにアクセスするクライアントアプリケーションのユーザーが、適切なアクセス権を持っている必要があります。
表 8-2 ファイルシステムオブジェクトストアの属性
属性
説明
java.naming.factory.initial
JNDI 検索の初期コンテキスト
例:
com.sun.jndi.fscontext.RefFSContextFactory
java.naming.provider.url
ディレクトリパス
例:
file:///C:/myapp/mqobjs
管理対象オブジェクトの属性Message Queue の管理対象オブジェクトには 2 つの基本的な種類があります。
これらの種類の管理対象オブジェクトはそれぞれ、オブジェクトのプロパティーと動作を決める特定の属性を持ちます。この節では、コマンド行ユーティリティーであるオブジェクトマネージャー (imqobjmgr) を使用してこれらの属性を設定する方法について説明します。また、第 2 章で説明したように、GUI 管理コンソールで属性を設定することもできます (「管理対象オブジェクトの操作」を参照)。
接続ファクトリの属性
クライアントアプリケーションは、接続ファクトリ管理対象オブジェクトを使用して、ブローカとメッセージを交換するための接続を作成します。接続ファクトリの属性は、その接続ファクトリが作成するすべての接続のプロパティーを定義します。接続が作成されたあとは、そのプロパティーを変更できません。つまり、接続のプロパティーを設定するには、その作成に使用される接続ファクトリの属性を設定する必要があります。
Message Queue では、2 つのクラスの接続ファクトリオブジェクトが定義されています。
どちらのクラスも同じ設定属性を持ち、それらを使用して、リソース、パフォーマンス、およびメッセージスループットを最適化できます。これらの属性のリストと詳細な説明については、第 16 章「管理対象オブジェクト属性のリファレンス」を参照してください。次の節では、これらの属性について取り上げます。
接続の処理
接続処理の属性では、接続先のメッセージサーバーのアドレス、および必要に応じて、接続障害の検出方法と再接続の試行方法を指定します。これらの要約については、表 16-1 を参照してください。
メッセージサーバーのアドレスリスト
もっとも重要な接続処理の属性は、接続の確立先となる 1 つ以上のブローカを指定する imqAddressList です。この属性の値は、メッセージサーバーのアドレスを 1 つ含む文字列、またはブローカクラスタの場合はコンマ区切りで複数含む文字列です。サーバーのアドレスには、使用する接続サービス (「接続サービス」を参照) と接続の確立方法に応じて、さまざまなアドレススキーマを使用できます。
- mq。jms または ssljms 接続サービスで、ブローカのポートマッパーを使用してポートを動的に割り当てます。
- mqtcp。jms 接続サービスを使用し、ポートマッパーをバイパスして、指定されたポートに直接接続します。
- mqssl。ssljms 接続サービスを使用し、指定されたポートへの SSL (Secure Socket Layer) 接続を作成します。
- http。httpjms 接続サービスを使用し、指定された URL の Message Queue トンネルサーブレットへの HTTP (Hypertext Transport Protocol) 接続を作成します。
- https。httpsjms 接続サービスを使用し、指定された URL の Message Queue トンネルサーブレットへの HTTPS (Secure Hypertext Transport Protocol) 接続を作成します。
これらのアドレススキーマの要約については、表 16-2 を参照してください。
各メッセージサーバーアドレスの一般的な形式は、次のようになります。
scheme は、前述のアドレススキーマのいずれかで、address は、サーバーのアドレス自体を示します。アドレスを指定するための正確な構文は、表 16-2 の最後の列に示すように、アドレススキーマによって異なります。さまざまなアドレス形式の例については、表 16-3 を参照してください。
複数のブローカによるクラスタ環境では、アドレスリストに複数のサーバーアドレスを含めることができます。最初の接続試行に失敗すると、Message Queue クライアントランタイムは、リスト内の別のアドレスに接続を試行し、成功するまでリスト内のすべてのアドレスに順に接続を試みます。2 つの追加の接続ファクトリ属性によって、この方法を制御します。
- imqAddressListBehavior。指定したアドレスへの試行順序を指定します。この属性を文字列 PRIORITY に設定すると、アドレスリストに表示されている順序でアドレスが試行されます。属性値を RANDOM にすると、ランダムな順序でアドレスが試行されます。これは、たとえば、多数の Message Queue クライアントが同じ接続ファクトリオブジェクトを共有しているときに、すべてのクライアントが同じサーバーアドレスに接続を試行するのを避けるためなどに便利です。
- imqAddressListIterations。試行を中止して失敗を報告するまでの、リストの繰り返し回数を指定します。値 -1 は、無限に繰り返すことを示します。つまり、クライアントランタイムは、接続の確立に成功するか時間切れになるまで試行を続けます。
自動再接続
接続ファクトリの imqReconnectEnabled 属性を true に設定することで、接続に障害が発生した場合にクライアントがブローカに自動的に再接続するように設定できます。imqReconnectAttempts 属性では、特定のサーバーアドレスに再接続を試行する回数を制御します。imqReconnectInterval 属性では、試行の間隔をミリ秒単位で指定します。
メッセージサーバーのアドレスリスト (imqAddressList) で複数のアドレスを指定するブローカクラスタでは、障害の発生した接続を、元のブローカだけでなく、クラスタ内の別のブローカでも復元できます。元のブローカへの再接続に失敗すると、クライアントランタイムは、リスト内のほかのアドレスを試行します。前述のとおり、imqAddressListBehavior および imqAddressListIterations 属性で、アドレスの試行順序とリストの繰り返し回数を制御します。各アドレスは、imqReconnectInterval ミリ秒の間隔で、imqReconnectAttempts を最大回数として、繰り返し試行されます。
自動再接続では、メッセージの消費に関するすべてのクライアント通知モードがサポートされます。接続が再確立されると、ブローカは、以前に配信した未通知メッセージをすべて再配信し、それらに Redeliver フラグを付けます。アプリケーションコードでは、このフラグを使用して、特定のメッセージが消費されたが未通知であるかどうかを判断できます。ただし、永続的でないサブスクライバの場合、メッセージサーバーは、接続が閉じられたあとはメッセージを保持しません。そのため、接続がダウンしている間にそれらのサブスクライバに対して生成されたメッセージは、再接続後に配信できず、失われることになります。自動再接続中は、メッセージ生成がブロックされます。メッセージプロデューサは、接続の再確立が完了するまで、サーバーにメッセージを送信できません。自動再接続は、接続のフェイルオーバーを提供しますが、データのフェイルオーバーは実行しません。障害の発生したブローカまたは切断されたブローカが保持する持続メッセージ、その他の状態情報は、クライアントが別のブローカインスタンスに再接続すると失われることがあります。接続の再確立の試行中、Message Queue によって、クライアントランタイムが提供したオブジェクト (セッション、メッセージコンシューマ、メッセージプロデューサなど) は維持されます。一時的送信先も、接続に障害が発生したときは、クライアントがそれらの送信先に再接続して再度アクセスする可能性があるため、当面は維持されます。再接続してそれらの送信先を使用するための時間をクライアントに与えたあとで、ブローカはそれらを削除します。再接続時にブローカでクライアント側の状態を完全に復元できない場合 (たとえば、接続の間のみ存在する処理済セッションを使用している場合など) は、自動再接続は行われず、代わりに接続の例外ハンドラが呼び出されます。その後の例外のキャッチ、再接続、および状態の復元は、アプリケーションコードに任されます。
接続の定期的なテスト (ping)
Message Queue クライアントランタイムは、接続を定期的にテストする、つまり「ping」を実行するように設定できます。これにより、メッセージ転送に失敗する前に、予防的に接続の障害を検出できます。メッセージを消費するだけで生成しないクライアントアプリケーションでは、接続の障害を検出する手段がほかにないため、このようなテストが特に重要です。メッセージをたまに生成するだけのクライアントでも、この機能が役立ちます。
接続ファクトリ属性 imqPingInterval では、接続で ping を実行する頻度を秒単位で指定します。デフォルトでは、この間隔は 30 秒に設定されます。値 -1 を指定すると、ping の実行が無効になります。
失敗した ping への対応は、オペレーションシステムのプラットフォームによって異なります。一部のオペレーティングシステムでは、ただちに、クライアントアプリケーションの例外リスナーに例外がスローされます。クライアントに例外リスナーがない場合は、その接続を使用するための次回の試行に失敗します。また、オペレーティングシステムによっては、ブローカへの接続の確立を試行し続け、ping が成功するかバッファーがオーバーフローするまで、一連の ping をバッファリングするものもあります。
クライアントの識別
表 16-4 に示されている接続ファクトリ属性は、クライアント認証と、永続サブスクライバのクライアント識別子の設定をサポートしています。
クライアント認証
ブローカへのすべての接続試行は、ユーザー名とパスワードによって、メッセージサーバーが管理するユーザーリポジトリに対して認証される必要があります。接続ファクトリ属性 imqDefaultUsername および imqDefaultPassword では、クライアントが接続の作成時にユーザー名とパスワードを明示的に提供しなかった場合に使用するデフォルトのユーザー名とパスワードを指定します。
開発者がアプリケーションの開発およびテストの際にユーザーリポジトリを設定する手間を省くことができるように、Message Queue には、ユーザー名とパスワードがどちらも guest に設定されたゲストユーザーアカウントが用意されています。これは、imqDefaultUsername および imqDefaultPassword 属性のデフォルト値でもあるため、これらが明示的に指定されていない場合、クライアントは常にゲストアカウントで接続を取得できます。本稼働環境では、ブローカ接続へのアクセスは、ユーザーリポジトリに明示的に登録されているユーザーのみに制限するべきです。
クライアント識別子
『Java Message Service 仕様書』では、メッセージサーバーがクライアントに代わって持続状態を維持する必要があるときは常に、接続で一意のクライアント識別子を提供することが要求されています。Message Queue は、このクライアント識別子を使用して、トピック送信先への永続サブスクライバを追跡します。永続サブスクライバが非アクティブになると、ブローカは、そのトピックのすべての受信メッセージを保持し、サブスクライバが再度アクティブになったときにそれらを配信します。ブローカは、クライアント識別子によってサブスクライバを識別します。
クライアントアプリケーションが接続オブジェクトの setClientID メソッドを使用してプログラムによって独自のクライアント識別子を設定することは可能ですが、この場合、クライアント識別子が互いに一意になるように調整するのが難しくなります。一般的には、Message Queue が、クライアントに代わって接続を作成するときに一意の識別子を自動的に割り当てるようにすることをお勧めします。このためには、接続ファクトリの imqConfiguredClientID 属性を、次の形式の値に設定します。
この属性値の先頭の 4 文字は必ず、${u} になります。括弧内に u 以外の文字があると、接続の作成時に例外がスローされます。先頭以外の位置では、これらの文字は特別な意味を持たず、プレーンテキストとして扱われます。factoryID の値は、この接続ファクトリオブジェクトに一意に関連付ける文字列です。
特定のクライアントの接続を作成するときに、Message Queue は、文字列 ${u} を u:userName に置き換えることによってクライアント識別子を生成します。userName は、接続で認証されたユーザー名です。これにより、特定の接続ファクトリによって作成された接続がそれぞれ、ほかのすべての面で同一であっても、一意のクライアント識別子を持つことが保証されます。たとえば、ユーザー名が Calvin で、接続ファクトリの imqConfiguredClientID 属性に指定された文字列が ${u}Hobbes である場合、割り当てられるクライアント識別子は u:CalvinHobbes になります。
imqConfiguredClientID を使用してクライアント識別子を指定する場合でも、クライアントアプリケーションは、接続メソッド setClientID を使用してこの設定をオーバーライドできます。接続ファクトリの imqDisableSetClientID 属性を true に設定することで、これを避けることができます。永続サブスクライバを使用するアプリケーションでは、管理のために imqConfiguredClientID を使用するか、プログラムによって setClientID を使用して、クライアント識別子を必ず設定する必要があります。
信頼性およびフロー制御
クライアントが送受信する「ペイロード」メッセージと Message Queue 自体が使用する制御メッセージ (ブローカ通知など) は、クライアントとブローカ間の同じ接続でやり取りされるため、ペイロードのトラフィックが過剰になると、制御メッセージの配信が妨げられる可能性があります。この問題を軽減するために、表 16-5 に示されている接続ファクトリ属性を使用して、2 種類のメッセージの相対的なフローを管理できます。これらの属性は、4 つのカテゴリに分類されます。
- 通知タイムアウト: 例外をスローするまでのブローカ通知の最大待ち時間 (imqAckTimeout) を指定します。
- 接続フロー測定: ペイロードメッセージの転送を、指定したサイズ (imqConnectionFlowCount) のバッチに制限します。これにより、累積された制御メッセージを配信する機会が定期的に得られます。
- 接続フロー制御: 特定の接続で、消費を待って保留状態になるペイロードメッセージの数 (imqConnectionFlowLimit) を制限します。制限に達すると、消費待ちのメッセージの数が制限を下回るまで、その接続へのペイロードメッセージの配信が一時停止されます。この機能の使用は、ブール型のフラグ (imqConnectionFlowLimitEnabled) によって制御します。
- コンシューマフロー制御: 単一のコンシューマに対して、消費を待って保留状態になるペイロードメッセージの数 (imqConsumerFlowLimit) を制限します。この制限は、特定のキュー送信先のプロパティー (consumerFlowLimit) として指定することもできます。制限に達すると、消費待ちのメッセージの数が、imqConsumerFlowLimit に対する割合として imqConsumerFlowThreshold 属性で指定した制限を下回るまで、そのコンシューマへのペイロードメッセージの配信が一時停止されます。同じ接続上で 1 つのコンシューマがほかのコンシューマの通信を妨げるのを回避することによって、複数のコンシューマ間のロードバランスを向上させるのに役立ちます。
これらのフロー制御技術のいずれを使用する場合でも、信頼性とスループットの兼ね合いを考慮する必要があります。詳細は、「クライアントランタイムのメッセージフローの調整」を参照してください。
キューブラウザとサーバーセッション
表 16-6 に、クライアントのキュー検索とサーバーセッションに関する接続ファクトリ属性が示されています。imqQueueBrowserMaxMessagesPerRetrieve 属性では、キュー送信先の内容の検索時に一度に取得するメッセージの最大数を指定します。imqQueueBrowserRetrieveTimeout 属性では、メッセージ取得の最大待ち時間を指定します。ブール型の imqLoadMaxToServerSession 属性では、アプリケーションサーバーセッションでの接続コンシューマの動作を制御します。この属性の値が true の場合、クライアントは、サーバーセッションに対して最大数までのメッセージを読み込みます。false の場合は、一度に 1 つのメッセージだけを読み込みます。
標準メッセージプロパティー
『Java Message Service 仕様書』では、Message Queue などの JMS プロバイダが任意でサポートできる、いくつかの標準メッセージプロパティーを定義しています。規定によって、これらの標準プロパティーの名前はすべて、JMSX という文字列で始まります。表 16-7 に示されている接続ファクトリ属性では、Message Queue クライアントランタイムがこれらいずれかの標準プロパティーを設定するかどうかを制御します。生成されたメッセージについては、次のプロパティーがあります。
消費されたメッセージについては、次のものがあります。
メッセージヘッダーのオーバーライド
表 16-8 に示されている接続ファクトリ属性を使用して、クライアントが特定の JMS メッセージヘッダーフィールドに設定した値をオーバーライドできます。指定した設定は、その接続ファクトリから取得された接続が生成するすべてのメッセージに使用されます。この方法でオーバーライドできるヘッダーフィールドには次のものがあります。
これらのフィールドにはそれぞれ、フィールドがオーバーライド可能であるかどうかを制御するブールの属性と、フィールドの値を指定する属性の 2 つがあります。たとえば、優先度のレベルを設定するための属性は、imqOverrideJMSPriority と imqJMSPriority です。さらに、オーバーライドの値を一時的送信先に適用するかどうかを制御する imqOverrideJMSHeadersToTemporaryDestinations 属性もあります。
注
メッセージヘッダーをオーバーライドすると、特定のアプリケーションの要件に支障を及ぼす可能性があるため、これらの属性は、必ずアプリケーションの設計者またはユーザーに相談した上で使用することをお勧めします。
送信先の属性
物理的なキューまたはトピック送信先を識別する送信先管理対象オブジェクトには、表 16-9 に示されている 2 つの属性だけがあります。重要な属性である imqDestinationName では、この管理対象オブジェクトが表す物理的送信先の名前を指定します。これは、その物理的送信先を作成した imqcmd create dst コマンドの -n オプションで指定された名前です。オプションの説明文字列である imqDestinationDescription もあります。これを使用して、送信先オブジェクトを識別しやすくしたり、作成済みのほかの送信先オブジェクトと区別しやすくしたりできます。
オブジェクトマネージャーユーティリティーの使用Message Queue のオブジェクトマネージャーユーティリティー (imqobjmgr) を使用して、管理対象オブジェクトを作成および管理できます。imqobjmgr コマンドには、管理対象オブジェクトに対してさまざまな操作を実行するための、次のサブコマンドが用意されています。
imqobjmgr コマンドの構文、サブコマンド、およびオプションに関する参照情報については、「オブジェクトマネージャーユーティリティー」を参照してください。
オブジェクトマネージャーのほとんどの操作で、imqobjmgr コマンドのオプションとして次の情報を指定する必要があります。
使用可能な属性とそれらの値については、「オブジェクトストア」を参照してください。
- 管理対象オブジェクトの属性 (-o オプション)
使用可能な属性とそれらの値については、「管理対象オブジェクトの属性」を参照してください。
管理対象オブジェクトの追加
imqobjmgr コマンドの add サブコマンドでは、接続ファクトリおよびトピックまたはキュー送信先管理対象オブジェクトをオブジェクトストアに追加します。LDAP オブジェクトストアに格納する管理対象オブジェクトには、接頭辞 cn= で始まる検索名を割り当てる必要があります。ファイルシステムオブジェクトストアでは、検索名を特定の接頭辞で始める必要はありませんが、スラッシュ文字 (/) を含めてはいけません。
注
オブジェクトマネージャーは、Message Queue 管理対象オブジェクトだけを一覧表示します。オブジェクトストアに、追加したい管理対象オブジェクトと同じ検索名の Message Queue 以外のオブジェクトが含まれている場合は、追加操作を実行するとエラーが表示されます。
接続ファクトリの追加
クライアントアプリケーションがブローカ接続を作成できるようにするには、作成される接続のタイプに応じた接続ファクトリ管理対象オブジェクト、つまりキュー接続ファクトリまたはトピック接続ファクトリを追加します。コード例 8-1 に、キュー接続ファクトリ (管理対象オブジェクトのタイプ qf) を LDAP オブジェクトストアに追加するコマンドを示します。このオブジェクトは、検索名が cn=myQCF で、ホスト myHost のポート番号 7272 で実行するブローカに、jms 接続サービスを使用して接続します。
送信先の追加
送信先を表す管理対象オブジェクトを作成するときは、最初に物理的送信先を作成してから、管理対象オブジェクトをオブジェクトストアに追加することをお勧めします。物理的送信先を作成するには、「物理的送信先の作成」で説明しているように、コマンドユーティリティー (imqcmd) を使用します。
コード例 8-2 に示すコマンドでは、トピック送信先を表す管理対象オブジェクトを LDAP オブジェクトストアに追加しています。検索名は myTopic で、物理的送信先の名前は physTopic です。キュー送信先を追加するためのコマンドも同様になりますが、管理対象オブジェクトのタイプ (-t オプション) を、トピック (topic) 送信先を示す t の代わりに、キュー (queue) 送信先を示す q にします。
コード例 8-2 LDAP オブジェクトストアへの送信先の追加
imqobjmgr add
-l "cn=myTopic"
-j "java.naming.factory.initial=com.sun.jndi.ldap.LdapCtxFactory"
-j "java.naming.provider.url=ldap://mydomain.com:389/o=imq"
-j "java.naming.security.principal=uid=homerSimpson,ou=People,o=imq"
-j "java.naming.security.credentials=doh"
-j "java.naming.security.authentication=simple"
-t t
-o "imqDestinationName=physTopic"
コード例 8-3 に、同じコマンドで、LDAP サーバーではなく Solaris ファイルシステムに管理対象オブジェクトを格納する場合の例を示します。
コード例 8-3 ファイルシステムオブジェクトストアへの送信先の追加
imqobjmgr add
-l "cn=myTopic"
-j "java.naming.factory.initial=
com.sun.jndi.fscontext.RefFSContextFactory"
-j "java.naming.provider.url=file:///home/foo/imq_admin_objects"
-t t
-o "imqDestinationName=physTopic"
管理対象オブジェクトの削除
管理対象オブジェクトをオブジェクトストアから削除するには、imqobjmgr コマンドの delete サブコマンドを使用して、削除するオブジェクトの検索名、タイプ、および場所を指定します。コード例 8-4 に示すコマンドでは、前述のコード例 8-2 で追加したオブジェクトを削除しています。
コード例 8-4 管理対象オブジェクトの削除
imqobjmgr delete
-l "cn=myTopic"
-j "java.naming.factory.initial=com.sun.jndi.ldap.LdapCtxFactory"
-j "java.naming.provider.url=ldap://mydomain.com:389/o=imq"
-j "java.naming.security.principal=uid=homerSimpson,ou=People,o=imq"
-j "java.naming.security.credentials=doh"
-j "java.naming.security.authentication=simple"
-t t
管理対象オブジェクトの一覧表示
オブジェクトマネージャーの list サブコマンドを使用して、オブジェクトストア内のすべての管理対象オブジェクトまたは特定のタイプの管理対象オブジェクトを一覧表示できます。コード例 8-5 に、LDAP サーバー上のすべての管理対象オブジェクトを一覧表示する例を示します。
コード例 8-5 すべての管理対象オブジェクトの一覧表示
imqobjmgr list
-j "java.naming.factory.initial=com.sun.jndi.ldap.LdapCtxFactory"
-j "java.naming.provider.url=ldap://mydomain.com:389/o=imq"
-j "java.naming.security.principal=uid=homerSimpson,ou=People,o=imq"
-j "java.naming.security.credentials=doh"
-j "java.naming.security.authentication=simple"
コード例 8-6 では、すべてのキュー送信先 (タイプ q) を一覧表示しています。
コード例 8-6 特定のタイプの管理対象オブジェクトの一覧表示
imqobjmgr list
-j "java.naming.factory.initial=com.sun.jndi.ldap.LdapCtxFactory"
-j "java.naming.provider.url=ldap://mydomain.com:389/o=imq"
-j "java.naming.security.principal=uid=homerSimpson,ou=People,o=imq"
-j "java.naming.security.credentials=doh"
-j "java.naming.security.authentication=simple"
-t q
管理対象オブジェクトの情報の表示
query サブコマンドでは、検索名および格納先のオブジェクトストアの属性によって指定した管理対象オブジェクトに関する情報が表示されます。コード例 8-7 では、検索名が cn=myTopic であるオブジェクトの情報を表示しています。
コード例 8-7 管理対象オブジェクトの情報の表示
imqobjmgr query
-l "cn=myTopic"
-j "java.naming.factory.initial=com.sun.jndi.ldap.LdapCtxFactory"
-j "java.naming.provider.url=ldap://mydomain.com:389/o=imq"
-j "java.naming.security.principal=uid=homerSimpson,ou=People,o=imq"
-j "java.naming.security.credentials=doh"
-j "java.naming.security.authentication=simple"
管理対象オブジェクトの属性の変更
管理対象オブジェクトの属性を変更するには、imqobjmgr update サブコマンドを使用します。オブジェクトの検索名と場所を指定し、-o オプションを使用して新しい属性値を指定します。
コード例 8-8 では、コード例 8-1 でオブジェクトストアに追加したキュー接続ファクトリの imqReconnectAttempts 属性の値を変更しています。
コード例 8-8 管理対象オブジェクトの属性の変更
imqobjmgr update
-l "cn=myQCF"
-j "java.naming.factory.initial=com.sun.jndi.ldap.LdapCtxFactory"
-j "java.naming.provider.url=ldap://mydomain.com:389/o=imq"
-j "java.naming.security.principal=uid=homerSimpson,ou=People,o=imq"
-j "java.naming.security.credentials=doh"
-j "java.naming.security.authentication=simple"
-t qf
-o "imqReconnectAttempts=3"
コマンドファイルの使用
imqobjmgr コマンドの -i オプションでは、Java プロパティーファイルの構文を使用してサブコマンド節の全部または一部を示したコマンドファイルの名前を指定できます。この機能は特に、通常は多くの入力が必要で、imqobjmgr を何度も呼び出す場合はたいてい同じになる、オブジェクトストアの属性を指定するときに便利です。また、コマンドファイルを使用すると、コマンド行で許可されている最大文字数を超えてしまうのを避けることもできます。
コード例 8-9 に、オブジェクトマネージャーコマンドファイルの一般的な構文を示します。version プロパティーはコマンド行オプションではありません。これは、コマンドファイル自体のバージョン (Message Queue 製品のバージョンではない) を示し、値を 2.0 に設定する必要があります。
コード例 8-9 オブジェクトマネージャーコマンドファイルの構文
version=2.0
cmdtype=[ add | delete | list | query | update ]
obj.lookupName=lookup name
objstore.attrs.objStoreAttrName1=value1
objstore.attrs.objStoreAttrName2=value2
. . .
objstore.attrs.objStoreAttrNameN=valueN
obj.type=[ q | t | cf | qf | tf | xcf | xqf | xtf | e ]
obj.attrs.objAttrName1=value1
obj.attrs.objAttrName2=value2
. . .
obj.attrs.objAttrNameN=valueN
前述のコード例 8-1 で示した、LDAP オブジェクトストアにキュー接続ファクトリを追加するオブジェクトマネージャーコマンドを例として考えてみます。このコマンドは、コード例 8-10 に示すようにコマンドファイルでカプセル化できます。コマンドファイルの名前を MyCmdFile とした場合、次のコマンド行でコマンドを実行できます。
imqobjmgr -i MyCmdFile
コード例 8-10 コマンドファイルの例
version=2.0
cmdtype=add
obj.lookupName=cn=myQCF
objstore.attrs.java.naming.factory.initial=com.sun.jndi.ldap.LdapCtxFactory
objstore.attrs.java.naming.provider.url=ldap://mydomain.com:389/o=imq
objstore.attrs.java.naming.security.principal=¥
uid=homerSimpson,ou=People,o=imq
objstore.attrs.java.naming.security.credentials=doh
objstore.attrs.java.naming.security.authentication=simple
obj.type=qf
obj.attrs.imqAddressList=mq://myHost:7272/jms
コマンドファイルを使用して、imqobjmgr サブコマンド節の一部だけを指定し、残りの部分はコマンド行で明示的に指定することもできます。たとえば、コード例 8-12 に示すコマンドファイルでは、LDAP オブジェクトストアの属性値だけを指定しています。
コード例 8-11 部分的なコマンドファイル
version=2.0
objstore.attrs.java.naming.factory.initial=com.sun.jndi.ldap.LdapCtxFactory
objstore.attrs.java.naming.provider.url=ldap://mydomain.com:389/o=imq
objstore.attrs.java.naming.security.principal=¥
uid=homerSimpson,ou=People,o=imq
objstore.attrs.java.naming.security.credentials=doh
objstore.attrs.java.naming.security.authentication=simple
次に、コード例 8-12 に示すように、このコマンドファイルを使用して imqobjmgr コマンドでオブジェクトストアを指定し、残りのオプションを明示的に指定できます。
コード例 8-12 部分的なコマンドファイルの使用
imqobjmgr add
-l "cn=myQCF"
-i MyCmdFile
-t qf
-o "imqAddressList=mq://myHost:7272/jms"
コマンドファイルのその他の例は、プラットフォームに応じて次の場所で参照できます。