Javaアプリは、WeblogicJMSメッセージブリッジを介してMQシリーズキューに書き込みます。実際のMQシリーズ接続/キューの詳細は、アプリサーバーのMQシリーズ.bindingsファイルに保存されます。バインディングファイルとすべてのエントリの意味について頭を悩ませたことはありません。誰かがこのファイルを理解するためのガイダンスを提供できますか?
1 に答える
.bindingsファイルをアドレス指定する前に、少し前に戻って、JNDI(Java Naming and Directory Interface)と、JMSでのJNDIの使用方法を確認する必要があります。キュー、トピック、およびさまざまなタイプの接続ファクトリはすべて、メソッドと属性を持つランタイムJMSオブジェクトです。ただし、それらを事前定義してレジストリに格納し、JMSアプリケーションがJNDIルックアップを使用してそれらを取得できるようにすることができます。
オブジェクトはJMS側とプロバイダー固有の側を持っているという点でコインに似ているため、これは便利です。JMS側では、管理対象オブジェクトはほぼ同じように見えます。基盤となるトランスポートプロバイダーに関係なく、ConnectionFactoryには同じメソッドと属性があります。ただし、プロバイダー固有の側面では、管理対象オブジェクトは、トランスポートプロバイダーごとに大きく異なります。たとえば、WebSphere MQトランスポートで使用されるConnectionFactoryには、キュー・マネージャーの属性があります。他のトランスポートプロバイダーには「キューマネージャー」がないため、この属性はWMQコンテキストでのみ有効です。
管理対象オブジェクトの2つの側面は、JMSがトランスポートプロバイダーから独立して機能できるようにする「接着剤」です。コードでは、ConnectionFactoryを検索するだけで、メソッド呼び出しを実行するのに適したオブジェクトを取得できます。裏では、プロバイダーのJMSクラスは、プロバイダー固有のオブジェクト属性を使用してコンテキストを提供し、汎用JMSAPI呼び出しをプロバイダー固有の呼び出しに変換します。したがって、インスタンス化する接続オブジェクトは、QMgr名、ホスト、ポート、チャネル、およびその他のさまざまなパラメーターを指定するWMQCONNECT呼び出しになります。
OK、.bindingsファイルにアクセスすることを約束しました。JNDIルックアップは「レジストリ」に対するものであり、通常はLDAPなどを意味します。ただし、Sunは、プログラムが使用するAPIと、レジストリで使用されるSPIまたはサービスプロバイダーインターフェイスがあるという点で、JMSのようにJNDIを設計しました。したがって、JNDIはLDAPに実装できますが、それが必要であると言うものは何もありません。LDAPで実装されます。Sunが箱から出してすぐに提供した基本的な実装の1つは、ローカルファイルシステムをレジストリとして使用することでした。この実装では、ルートコンテキストはファイルフォルダーです。各コンテキストは、別のサブコンテキスト(別のファイルフォルダー)またはオブジェクト定義のいずれかを格納できます。通常、ルートコンテキスト用のフォルダが1つあり、すべてのオブジェクトがそのレベルで定義されます。オブジェクト定義を保持するファイルは...ご想像のとおり....bindingsファイルです。
.bindingsファイル内のオブジェクトは、名前/タイプ/値のトリプレットで表されます。したがって、各.bindingsファイルには通常多くのオブジェクトがあります。各オブジェクトには多くの属性があります。各属性には、名前、値、および値を保持する変数のタイプがあります。.bindingsファイルのハンドルを取得する最良の方法は、すべてのオブジェクトとその属性をまとめて人間が読める形式にするファイルを並べ替えることです。可能なプロパティのリストについては、マニュアルを参照してください。
もちろん、.bindingsファイルはコンパイルされたアーティファクトであると想定されており、人間が読める形式ではありません。IBMは、.bindingsファイルを生成して読み取るためのJMSAdminツールを提供しています。WMQエクスプローラーを使用して、.bindingsファイル内の管理対象オブジェクトを管理することもできます。これらについては、上記のリンク先のマニュアルでも説明されています。ここにdeveloperWorksの(言う人もいる)良いチュートリアルもあります。