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

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

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

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

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

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 情報が必要です。

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

表 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 Connection 登録用の画面

登録するには、Sun Online アカウントを持っているか、または作成する必要があります。アカウントをまだ持っていない場合は、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」を参照してください。