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 管理ツールでは、トピック送信先のパブリッシャー (プロデューサ) とサブスクライバ (コンシューマ) の合計数のほかに、一致する送信先記号名を含むワイルドカードパブリッシャーの数と、送信先記号名を含むワイルドカードサブスクライバの数も報告されます (存在する場合)。
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 を使用した検証に失敗すると、クライアントランタイムは例外をスローします。
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 によって管理されます。
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 クライアントです。 |
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 がすでにインストールされている必要があります。登録専用モードでは、登録に関連するインストーラ画面のみが表示されます。
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」を参照してください。