Sun Java System Message Queue 4.2 リリースノート

Message Queue 4.2 の新機能および最近のリリース

次の各節では、Message Queue 4.2、4.1、および 4.0 の新機能について説明します。

Message Queue 4.2 の新機能

Sun Java System Message Queue は、多くの機能を備えるメッセージサービスで、Java Messaging Specification (JMS) 1.1 に準拠する信頼性の高い非同期メッセージングを提供します。Message Queue では、JMS 仕様を超える機能も用意され大規模企業のシステム配備のニーズにも対応できるようになっています。

Message Queue 4.2 は、いくつかの機能拡張とバグ修正が施されたマイナーリリースです。この節では、Message Queue 4.2 のインストールまたは Message Queue 4.2 へのアップグレードの方法、およびこのリリースに含まれる新機能について説明します。

Message Queue 4.0 および 4.1 で導入された機能については、それぞれ、「Message Queue 4.0 の新機能」および「Message Queue 4.1 の新機能」を参照してください。

パブリッシャーまたはサブスクライバの複数の送信先

Message Queue 4.2 では、パブリッシャーは複数のトピック送信先にメッセージを発行でき、サブスクライバは複数のトピック送信先からメッセージを消費できます。この機能は、トピック送信先の名前にワイルドカード文字を使用して、複数の送信先を表すことにより実現されます。そのような記号名を使用することにより、管理者は、必要な場合に、ワイルドカードのネーミングスキームに整合する追加のトピック送信先を作成できます。送信先が追加されると自動的に、パブリッシャーはその送信先に発行し、サブスクライバはその送信先から消費するようになります。ワイルドカードトピックのサブスクライバの方が、パブリッシャーよりも一般的です。

注 –

この機能は、キュー送信先には適用されません。

トピック送信先の記号名の形式は複数の部分で構成されており、ワイルドカード文字 (*、**、>) で名前の 1 部分または複数の部分を表すことができます。たとえば、次のようなトピック送信先のネーミングスキームがあるとします。

size.color.shape

このトピック名の各部には、次のような値を指定できます。

size: large、medium、small など
color: red、 green、blue など
shape: circle、 triangle、square など

Message Queue では、次のワイルドカード文字がサポートされます。

*: 単一部分と一致
**: 1 つ以上の部分と一致
>: 任意の数の後続部分と一致

従って、複数のトピック送信先を次のように示すことができます。

large.*.circle は、次のトピック送信先を表します。

large.red.circle
large.green.circle
...

**.square は、次のような、.square で終わるすべてのトピック送信先を表します。

small.green.square
medium.blue.square
...

small.> は、次のような、small. で始まるすべてのトピック送信先を表します。

small.blue.circle
small.red.square
...

この複数送信先機能を使用するには、前述のようなネーミングスキームを使用してトピック送信先を作成します。クライアントアプリケーションは、それらの送信先記号名を使用してパブリッシャーまたはコンシューマを作成できます。次に例を示します。

...
String DEST_LOOKUP_NAME = "large.*.circle";
Topic t = (Destination) ctx.lookup(DEST_LOOKUP_NAME);
TopicPublisher myPublisher = mySession.createPublisher(t)
myPublisher.send(myMessage);

...
String DEST_LOOKUP_NAME = "**.square";
Topic t = (Destination) ctx.lookup(DEST_LOOKUP_NAME);
TopicSubscriber mySubscriber = mySession.createSubscriber(t);
Message m = mySubscriber.receive();

最初の例では、ブローカが、記号名 large.*.circle に一致するすべての送信先にメッセージのコピーを配置します。2 番目の例では、記号名 **.square に一致する送信先が 1 つ以上ある場合にサブスクライバが作成され、サブスクライバはその記号名に一致するすべての送信先からメッセージを受信します。記号名に一致する送信先がない場合は、一致する送信先が追加されるまで、サブスクライバは作成されません。

記号名に一致する追加の送信先を管理者が作成すると、その後、その記号名を使用して作成されたワイルドカードパブリッシャーがその送信先にメッセージを発行し、次に、その記号名を使用して作成されたワイルドカードサブスクライバがその送信先からメッセージを受信します。

また、Message Queue 管理ツールでは、トピック送信先のパブリッシャー (プロデューサ) とサブスクライバ (コンシューマ) の合計数のほかに、一致する送信先記号名を含むワイルドカードパブリッシャーの数と、送信先記号名を含むワイルドカードサブスクライバの数も報告されます (存在する場合)。

XML ペイロードメッセージのスキーマ検証

Message Queue 4.2 のこの新機能では、メッセージがブローカに送信された時点で、テキスト (オブジェクトではない) の XML メッセージの XML スキーマを検証できます。XML スキーマ (XSD) の場所は、Message Queue 送信先のプロパティーとして指定されます。XSD の場所が指定されていない場合は、XML ドキュメント内の DTD 宣言を使用して DTD 検証が実行されます。データ型および値の範囲の検証を含む XSD 検証は、DTD 検証よりも厳格です。

クライアントアプリケーションでこの新機能を使用する場合は、Java SE のバージョンを JRE 1.5 以上にアップグレードしてください。

XML スキーマ検証を有効にするには、次の物理送信先プロパティーを設定します。

表 1–5 XML スキーマ検証の物理送信先プロパティー


プロパティー	型	デフォルト値	説明
`validateXMLSchemaEnabled`	ブール型	`false`	XML スキーマ検証が有効になっているかどうか `false` に設定されているか、または何も設定されていない場合、送信先の XML スキーマ検証は有効になっていません。
`XMLSchemaURIList`	文字列	null	XML スキーマドキュメント (XSD) URI 文字列のスペース区切りリスト URI は、XML スキーマ検証が有効になっている場合に使用する 1 つ以上の XSD の場所を示します。複数の URI を指定する場合は、この値を二重引用符で囲みます。例: “`http://foo/flap.xsd http://test.com/test.xsd`” このプロパティーが設定されていないか、または null の場合に XML 検証が有効になっていると、XML ドキュメント内で指定された DTD を使用して XML 検証が実行されます。
`reloadXMLSchemaOnFailure`	ブール型	`false`	障害発生時に XML スキーマを再読み込みするかどうか false に設定されているか、または何も設定されていない場合は、検証で障害が発生したときにスキーマの再読み込みは行われません。

XML 検証が有効になっている場合、Message Queue クライアントランタイムは、XML メッセージをブローカに送信する前に、指定された XSD (XSD が指定されていない場合は DTD) に照らしたメッセージの検証を試みます。指定されたスキーマが見つからないか、またはメッセージを検証できない場合は、メッセージは送信されずに、例外がスローされます。

送信先の作成時または更新時に、imqcmd create dst または imqcmd update dst コマンドを使用して、XML 検証プロパティーを設定できます。XML 検証プロパティーは、送信先がアクティブでないときに設定してください。つまり、送信先のコンシューマとプロデューサがないとき、および送信先にメッセージが存在しないときです。

注 –

実行時に XSD にアクセスできない場合は、送信先がアクティブなときに XMLSchemaURIList を変更しなければならないことがあります。

たとえばプロデューサが送信先に接続されている場合など、送信先がアクティブなときに XML 検証プロパティーのいずれかが設定されると、その変更は、プロデューサがブローカに再接続されるまで有効になりません。同様に、アプリケーションの要件が変更されたために XSD が変更された場合は、変更後の XSD に基づいて XML メッセージを生成するすべてのクライアントアプリケーションをブローカに再接続してください。

reloadXMLSchemaOnFailure プロパティーが true に設定されているときに XML 検証に失敗すると、Message Queue クライアントランタイムは、メッセージを再度検証する前に XSD の再読み込みを試みます。再読み込みした XSD を使用した検証に失敗すると、クライアントランタイムは例外をスローします。

分散トランザクションの C-API サポート

X/Open 分散トランザクションモデルに従って、分散トランザクションのサポートは、1 つ以上のリソースマネージャーで実行される操作の追跡と管理を行う分散トランザクションマネージャーに依存します。Message Queue 4.2 では、Message Queue C-API で XA インタフェース (分散トランザクションマネージャーと、XA 準拠のリソースマネージャーとしての Message Queue の間のインタフェース) がサポートされるようになりました。それにより、BEA Tuxedo などの分散トランザクション処理環境で実行される Message Queue C-API クライアントが、分散トランザクションに参加できるようになりました。

この分散トランザクションのサポートは、次に示す、XA インタフェース仕様を実装するための新しい C-API 関数 (および新しいパラメータとエラーコード) から成ります。

MQGetXAConnection()
MQCreateXASession()

C クライアントアプリケーションを分散トランザクションのコンテキストで使用する場合は、MQGetXAConnection() を使用して接続を取得し、MQCreateXASession() を使用して、メッセージを生成および消費するためのセッションを作成します。すべての分散トランザクションの開始、コミット、およびロールバックは、分散トランザクションマネージャーが提供する API によって管理されます。

public 情報

X/Open XA インタフェース仕様では、Message Queue の XA 準拠リソースマネージャーに関する次の public 情報が必要です。

xa_switch_t 構造体の名前: sun_my_xa_switch
リソースマネージャーの名前: SUN_RM
リンクする MQ C-API ライブラリ: mqcrt
xa_close 文字列と形式: なし
xa_open 文字列と形式: 「;」で区切られた名前と値のペア (「名前=値」形式)

次の名前と値の組み合わせがサポートされます。

表 1–6 Message Queue リソースマネージャーの名前と値の組み合わせ


名前	値	説明	デフォルト
address	`host`:`port`	ブローカのPortmapper サービスのホストとポート	`localhost:7676`
username	文字列	ブローカへの接続に使用するユーザー名	`guest`
password	文字列	ユーザー名のパスワード	`guest`
conntype	TCP または SSL	ブローカへの接続のプロトコルの種類	`TCP`
trustedhost	true/false	ブローカのホストが信頼できるかどうか (conntype が SSL の場合にのみ使用)	`true`
certdbpath	文字列	NSS 証明書およびキーデータベースファイルが格納されたディレクトリへのフルパス	なし
clientid	文字列	JMS 永続サブスクリプションでのみ必要	なし
reconnects	整数	ブローカへの再接続の試行回数 (0 は再接続しないことを意味する)	`0`

プログラミング例

分散トランザクションを使用するアプリケーションのプログラミングでは、トランザクションマネージャー環境で動作するサーバー側のサービスと、トランザクションマネージャー API を呼び出すクライアント側のコードを作成します。Message Queue 4.2 には、Tuxedo トランザクションマネージャーに基づくプログラミング例が用意されています。それらの例は、各プラットフォームの ./C/tuxedo ディレクトリ内の sample programs ディレクトリにあります。

このディレクトリに含まれている README ファイルに、Message Queue リソースマネージャーを使用するための Tuxedo のセットアップ方法、および Tuxedo 環境で次のプログラミング例を構築する方法が記載されています。

プログラミング例	説明
`jmsserver.c`	Message Queue を使用してメッセージを送受信する Tuxedo サービスを実装します。
`jmsclient_sender.c`	`jmsserver.c` プログラムのメッセージ生成サービスを使用する Tuxedo クライアントです。
`jmsclient_receiver.c`	`jmsserver.c` プログラムのメッセージ受信サービスを使用する Tuxedo クライアントです。
`async_jmsserver.c`	Message Queue を使用してメッセージを非同期に消費する Tuxedo サービスを実装します。
`jmsclient_async_receiver.c`	`async_jmsserver.c` プログラムの非同期メッセージ消費サービスを使用する Tuxed クライアントです。

インストーラでの Sun Connection 登録のサポート

Message Queue インストーラが、Message Queue を Sun Connection に登録できるように拡張されました。Sun Connection は、Sun のハードウェアとソフトウェアの追跡、構成、および維持を支援するために Sun が提供するサービスです。

Message Queue のインストール時に、Message Queue を Sun Connection に登録できます。インストールした Message Queue に関する情報、たとえば、リリースバージョン、ホスト名、オペレーティングシステム、インストール日などの基本情報は、Sun Connection のデータベースに安全に転送されます。Sun Connection のインベントリサービスは、Sun のハードウェアとソフトウェアの構成に役立ちます。また、更新サービスでは、最新のセキュリティー修正、推奨される更新、および機能拡張に関する情報を得ることができます。

Message Queue 4.2 では、Sun Connection 登録用に、次のインストーラ画面が追加されています。

登録するには、Sun Online アカウントを持っているか、または作成する必要があります。アカウントをまだ持っていない場合は、Sun Online アカウントを作成するための、次の画面が表示されます。

インストール時にこれらの画面を使用して Message Queue を登録できますが、インストールが完了した後で登録することもできます。その場合は、次のように登録専用モードでインストーラを実行します。

# installer -r

登録専用モードを使用するには、Message Queue 4.2 がすでにインストールされている必要があります。登録専用モードでは、登録に関連するインストーラ画面のみが表示されます。

MySQL データベースのサポート

Message Queue 4.2 では、JDBC ベースのデータストアとして MySQL データベースがサポートされます。スタンドアロンブローカ用の JDBC データベースとしては、MySQL Cluster Edition を使用できます。MySQL Cluster Edition は、高可用性ブローカクラスタに必要な高可用性共有データストアとして使用することもできます。MySQL を使用するための Message Queue の構成については、『Sun Java System Message Queue 4.2 Administration Guide』の「Configuring a JDBC-Based Data Store」および『Sun Java System Message Queue 4.2 Administration Guide』の「High-Availability Cluster Properties」を参照してください。

Message Queue 4.1 の新機能

Message Queue 4.1 は、いくつかの新機能、機能拡張、およびバグ修正を実装したマイナーリリースです。ここでは 4.1 リリースの新機能について説明するとともに、詳細な情報の参照先を示します。

Message Queue 4.0 で導入された機能については、「Message Queue 4.0 の新機能」を参照してください。

高可用性ブローカクラスタ

Message Queue 4.1 では、高可用性ブローカクラスタが導入されました。従来のブローカクラスタでは、ブローカで障害が発生した場合に別のブローカがメッセージングサービスを提供する「メッセージングサービス」の可用性のみが提供されていました。高可用性ブローカクラスタでは、ブローカで障害が発生した場合に持続メッセージと状態データを使用して別のブローカがメッセージ配信を継承できる、「データ」の可用性も提供されます。

Message Queue 4.1 で導入された高可用性の実装では、JDBC ベースの共有データストアが使用されます。ブローカクラスタ内の各ブローカがそれぞれの持続データストアを持つのではなく、クラスタ内のすべてのブローカが同じ JDBC 準拠データベースを共有します。特定のブローカで障害が発生すると、そのブローカのメッセージルーティングおよび配信を、メッセージクラスタ内の別のブローカが継承します。そのときに、継承ブローカは、共有データストアのデータおよび状態情報を使用します。障害が発生したブローカのメッセージングクライアントは継承ブローカに再接続するため、メッセージングサービスは中断されません。

Message Queue 4.1 の高可用性実装に使用される JDBC ベースの共有ストアは、それ自体も高可用性ストアでなければなりません。高可用性データベースを持っていない場合、またはメッセージ配信が中断されないことを重要視しない場合は、データの可用性がなくサービスの可用性のみを提供する従来のクラスタを引き続き使用できます。

Message Queue 4.1 の高可用性ブローカクラスタを設定するには、クラスタ内のブローカごとに、次のブローカプロパティーを指定します。

クラスタメンバーシッププロパティー。ブローカが高可用性ブローカクラスタ内にあることと、クラスタの ID およびクラスタ内のブローカの ID を指定します。
高可用性データベースプロパティー。持続データモデル (JDBC)、データベースベンダーの名前、およびベンダー固有の設定プロパティーを指定します。
障害検出および継承プロパティー。ブローカ障害の検出および継承ブローカによる処理の方法を指定します。

高可用性ブローカクラスタ実装を使用するには、次の操作を実行します。

高可用性データベースをインストールします。
JDBC ドライバの .jar ファイルをインストールします。
高可用性持続データストア用のデータベーススキーマを作成します。
クラスタ内のブローカごとに、高可用性プロパティーを設定します。
クラスタ内の各ブローカを起動します。

高可用性ブローカクラスタの概念に関する説明、および従来のクラスタとの比較については、『Sun Java System Message Queue 4.2 Technical Overview』の第 4 章「Broker Clusters」を参照してください。高可用性ブローカクラスタの手続きおよび参照に関する情報については、『Sun Java System Message Queue 4.2 Administration Guide』の第 10 章「Configuring and Managing Broker Clusters」および『Sun Java System Message Queue 4.2 Administration Guide』の「Cluster Configuration Properties」を参照してください。

Message Queue 4.0 で高可用性データベースを使用していた場合、高可用性ブローカクラスタに切り替えるには、データベースマネージャーユーティリティー (imqdbmgr) を使用して共有持続データストアに変換できます。「ブローカクラスタ」で、既知の問題および制限事項についても参照してください。

JAAS サポート

Message Queue 4.1 では、ファイルベースおよび LDAP ベースの組み込み認証機構に加えて、JAAS (Java Authentication and Authorization Service) サポートも導入されています。JAAS を使用すると、外部の認証機構をブローカに接続して Message Queue クライアントを認証できます。

ブローカによって JAAS 準拠の認証サービスで利用可能になる情報についての説明、およびそれらのサービスを使用するようにブローカを設定する方法については、『Sun Java System Message Queue 4.2 Administration Guide』の「Using JAAS-Based Authentication」を参照してください。

持続データストアの形式の変更

Message Queue 4.1 は、JDBC ベースのデータストアが高可用性ブローカクラスタをサポートするように変更されました。このため、JDBC ベースのデータストアの形式が Version 410 になりました。Version 350、370、および 400 の形式は、自動的に Version 410 に移行されます。

ファイルベースの持続データストアの形式は、何も変更されていないので、Version 370 のままです。

ブローカの環境設定

Message Queue 4.1 の環境設定ファイル imqenv.conf に、プロパティー IMQ_DEFAULT_EXT_JARS が追加されました。このプロパティーを設定して、ブローカが起動するときに CLASSPATH に含まれる外部 .jar ファイルのパス名を指定できます。このプロパティーを使用して外部 .jar ファイルの場所を指定した場合は、これらのファイルを lib/ext ディレクトリにコピーする必要はなくなります。外部 .jar ファイルは、JDBC ドライバまたは JAAS ログインモジュールを参照できます。次のサンプルプロパティーは、JDBC ドライバの場所を指定します。

IMQ_DEFAULT_EXT_JARS=/opt/SUNWhadb4/lib/hadbjdbc4.jar:/opt/SUNWjavadb/derby.jar

Java ES Monitoring Framework のサポート

Message Queue 4.1 では、Sun Java Enterprise System (Java ES) Monitoring Framework のサポートが導入されました。Monitoring Framework は、一般的なグラフィカルインタフェースを使用して Java ES コンポーネントを監視できるようにします。このインタフェースは、Sun Java System Monitoring Console と呼ばれる Web ベースのコンソールによって実装されます。管理者はこのコンソールを使用して、パフォーマンス統計の表示、自動監視のためのルールの作成、アラームの確認などを行えます。ほかの Java ES コンポーネントと一緒に Message Queue を実行している場合は、1 つのインタフェースを使用してすべてのコンポーネントを管理するほうが便利なことがあります。

Java ES Monitoring Framework による Message Queue の監視については、XREF を参照してください。

拡張されたトランザクション管理

以前は、管理上、PREPARED 状態のトランザクションだけをロールバックすることができました。つまり、分散トランザクションの一部であるセッションが正常に終了しなかった場合、そのトランザクションは、管理者がクリーンアップできない状態のままになりました。Message Queue 4.1 では、コマンドユーティリティー (imqcmd) を使用して、STARTED、FAILED、INCOMPLETE、COMPLETE、PREPARED の状態にあるトランザクションをクリーンアップ (ロールバック) できます。

特定のトランザクションがロールバックできるかどうか (特に、PREPARED 状態でない場合) の判別に役立つように、このコマンドユーティリティーは、追加のデータを imqcmd query txn 出力の一部として提供します。このデータは、そのトランザクションを開始した接続のコネクション ID を提供し、トランザクションが作成された時間を示します。管理者は、この情報を使用して、トランザクションをロールバックする必要があるかどうかを決定できます。一般に、管理者は早計にトランザクションをロールバックすることを避けるとよいでしょう。

C クライアント接続の固定ポート

Message Queue 4.1 では、C クライアントは、Java クライアントと同様に、ブローカのポートマッパーサービスで動的に割り当てられるポートではなく、固定ブローカポートに接続できるようになりました。固定ポート接続は、ファイアウォールを経由する場合、または他の何らかの理由でポートマッパーサービスをバイパスする必要がある場合に役立ちます。

固定ポート接続を設定するには、ブローカと C クライアントランタイムの両方 (接続の両端) を設定する必要があります。たとえば、ssljms を介してクライアントをポート 1756 に接続する場合は、次のように操作します。

クライアント側で、次のプロパティーを設定します。

MQ_SERVICE_PORT_PROPERTY=1756

MQ_CONNECTION_TYPE_PROPERTY=SSL
ブローカ側で、imq.serviceName.protocolType.port プロパティーを次のように設定します。
```
imq.ssljms.tls.port=1756
```

注 –

MQ_SERVICE_PORT_PROPERTY 接続プロパティーは、Message Queue 3.7 Update 2 にバックポートされています。

Message Queue 4.0 の新機能

Message Queue 4.0 は、Application Server 9 PE のサポートに限定されたマイナーリリースです。このリリースでは、いくつかの新機能、機能拡張、およびバグ修正が実装されています。この節では、このリリースの新機能について説明します。

注意 –

version 4.0 には、軽度とはいえ、状況によって十分な対応が必要になる変更が導入されました。その 1 つとして、パスワードを指定するコマンド行オプションが使用されなくなったことが挙げられます。今後は、「使用されなくなったパスワードオプション」で説明するように、すべてのパスワードをファイルに保存するか、または要求されたときに入力します。

JMX 管理 API のサポート

Message Queue 4.0 には、Java Management Extensions (JMX) 仕様に準拠して、Message Queue ブローカを設定および監視するための新しい API が追加されました。この API を使用すると、Java アプリケーション内部からプログラムによってブローカ関数を設定および監視することができます。以前のバージョンの Message Queue では、これらの関数にはコマンド行管理ユーティリティーまたは管理コンソールからしかアクセスできませんでした。

詳細については、『Sun Java System Message Queue 4.2 Developer’s Guide for JMX Clients』を参照してください。

クライアントランタイムログ

Message Queue 4.0 では、接続およびセッション関連のイベントに関するクライアントランタイムログのサポートが導入されました。

クライアントランタイムログおよびその設定方法については、『Java Dev Guide』の 137 ページを参照してください。

接続イベント通知 API

Message Queue 4.0 にはイベント通知 API が導入され、クライアントランタイムが接続状態の変更をアプリケーションに通知できるようになりました。接続イベント通知を使用すると、Message Queue クライアントは接続のクローズおよび再接続イベントを待機して、通知タイプと接続状態に基づいて適切なアクションを起こすことができます。たとえば、フェイルオーバーが発生してクライアントが別のブローカに再接続された場合、アプリケーションはそのトランザクションの状態をクリーンアップしてから新しいトランザクションに進む必要があるかもしれません。

接続イベント、およびイベントリスナの作成方法については、『Java Dev Guide』の 96 ページを参照してください。

ブローカ管理の拡張機能

Message Queue 4.0 では、コマンドユーティリティー (imqcmd) に、サブコマンドといくつかのコマンドオプションが追加されました。管理者はこれらを使用して、ブローカを休止したり、指定した間隔の後でブローカをシャットダウンしたり、接続を破棄したり、Java システムプロパティー (たとえば、コネクション関連のプロパティー) を設定したりできます。

ブローカを休止すると休止状態になり、ブローカをシャットダウンまたは再起動する前に、メッセージを排出してしまうことができます。休止状態にあるブローカに新しく接続が作成されることはありません。ブローカを休止するには、次のようなコマンドを入力します。

imqcmd quiesce bkr -b Wolfgang:1756
指定した間隔の後でブローカをシャットダウンするには、次のようなコマンドを入力します。(時間間隔は、ブローカをシャットダウンするまでの待機を秒数で指定します。)

imqcmd shutdown bkr -b Hastings:1066 -time 90

時間間隔を指定した場合、ブローカはシャットダウンが発生するタイミングを示すメッセージを記録します。次にその例を示します。

Shutting down the broker in 29 seconds (29996 milliseconds)

ブローカがシャットダウンを待っている間、ブローカの動作は次のような影響を受けます。
- 管理 JMS 接続は引き続き受け付けられます。
- 新しい JMS 接続は受け付けられません。
- 既存の JMS 接続は引き続き機能します。
- ブローカが高可用性ブローカクラスタ内のほかのブローカを継承することはできません。
- imqcmd ユーティリティーはブロックはせず、シャットダウンの要求をブローカに送信してすぐに返します。
接続を破棄するには、次のようなコマンドを入力します。

imqcmd destroy cxn -n 2691475382197166336

コマンド imqcmd list cxn または imqcmd query cxn を使用してコネクション ID を取得します。
imqcmd を使用してシステムプロパティーを設定するには、新しい –D オプションを使用します。これは、JMS コネクションファクトリのプロパティー、またはコネクション関連の Java システムのプロパティーの設定または上書きに便利です。次に例を示します。
```
imqcmd list svc -secure -DimqSSLIsHostTrusted=true
imqcmd list svc -secure -Djavax.net.ssl.trustStore=/tmp/mytruststore 
            -Djavax.net.ssl.trustStorePassword=mytrustword
```

imqcmd コマンドの構文の詳細は、『Sun Java System Message Queue 4.2 Administration Guide』の第 15 章「Command Line Reference」を参照してください。

JDBC ベースのデータストアに関する情報の表示

Message Queue 4.0 では、データベースマネージャーユーティリティー imqdbmgr に、新しい query サブコマンドが追加されました。このサブコマンドは、JDBC ベースのデータストアに関する情報 (データベースバージョン、データベースユーザー、データベーステーブルが作成されたかどうかなど) を表示するために使用します。

次に、このコマンドによって表示される情報の例を示します。

imqdbmgr query

[04/Oct/2005:15:30:20 PDT] Using plugged-in persistent store:
        version=400
        brokerid=Mozart1756
        database connection url=jdbc:oracle:thin:@Xhome:1521:mqdb
        database user=scott
Running in standalone mode.
Database tables have already been created.

JDBC プロバイダのサポート

Message Queue 4.0 では、Apache Derby Version 10.1.1 が、JDBC ベースのデータストアプロバイダとしてサポートされるようになりました。

持続データストアの形式の変更

Message Queue 4.0 では、最適化のため、および今後の拡張機能をサポートするために、JDBC ベースのデータストアに変更が加えられました。このため、JDBC ベースのデータストアの形式が Version 400 になりました。Message Queue 4.0 では、ファイルベースのデータストアのバージョンは、何も変更されていないので、370 のままです。

追加のメッセージプロパティー

Message Queue 4.0 では、デッドメッセージキューに配置されたすべてのメッセージで設定される 2 つの新しいプロパティーが追加されました。

JMS_SUN_DMQ_PRODUCING_BROKER は、メッセージが生成されたブローカを指定します。
JMS_SUN_DMQ_DEAD_BROKER は、メッセージをデッドとして指定したブローカを指定します。

SSL サポート

Message Queue 4.0 から、クライアントコネクションファクトリのプロパティー imqSSLIsHostTrusted のデフォルト値が false になりました。使用しているアプリケーションが以前のデフォルト値の true に依存している場合は、再設定を行い、プロパティーを明示的に true に設定する必要があります。

ブローカが自己署名付き証明書を使用するように設定されているときは、ホストを信頼することもできます。この場合、接続で SSL ベースの接続サービスを使用するように指定する (imqConnectionType プロパティーを使用する) ことに加えて、imqSSLIsHostTrusted プロパティーを true に設定することをお勧めします。

たとえば、ブローカが自己署名付き証明書を使用するときに安全にクライアントアプリケーションを実行するには、次のようなコマンドを使用します。

java -DimqConnectionType=TLS 
      -DimqSSLIsHostTrusted=true ClientAppName

ブローカが自己署名付き証明書を使用するときにコマンドユーティリティー (imqcmd) を安全に使用するには、次のようなコマンドを使用します (コネクタサービスのリストを表示する場合)。

imqcmd list svc -secure -DimqSSLIsHostTrusted=true