test

Sun GlassFish Message Queue 4.4 リリースノート

メッセージキュー 4.4 の新機能および最近のリリース

メッセージキュー 4.4 の新機能と、メッセージキュー 4.x ファミリのこれまでのリリースの新機能を、次の節に示します。

メッセージキュー 4.4 の新機能

メッセージキュー 4.4 は、多数の機能拡張とバグ修正を含むマイナーリリースです。この節では、このリリースに含まれる新しい機能を説明します。

JMS ブリッジサービス

JMS の仕様では、ブローカとクライアント間の通信に使用するワイヤープロトコルが定義されていないため、メッセージキュー を含む各 JMS プロバイダは、独自のプロトコルを定義して使用しています。この状況により、JMS プロバイダ間の相互運用性が失われてきました。

メッセージキュー 4.4 の JMS ブリッジサービスは、メッセージキュー ブローカが自身の送信先を外部 JMS プロバイダにある送信先にマッピングできるようにすることで、相互運用性の問題を解消します。実際にこのマッピングにより、メッセージキュー ブローカは外部 JMS プロバイダのクライアントと通信できるようになります。

JMS ブリッジサービスは、次のような外部 JMS プロバイダにある送信先のマッピングをサポートします。

オープンソースおよび商用の JMS プロバイダの多くは、これらの要件を満たしています。したがって JMS ブリッジサービスは、ほかの JMS プロバイダを使用している既存のメッセージング環境に メッセージキュー を統合するための効果的な方法となります。

JMS ブリッジサービスの詳細は、次の情報を参照してください。

STOMP ブリッジサービス

すでに説明したように、JMS 仕様にはブローカとクライアント間の通信に使用するワイヤープロトコルが定義されていません。STOMP (Streaming Text Oriented Messaging Protocol) オープンソースプロジェクト (http://stomp.codehaus.org) は、任意の言語で記述されたクライアントが STOMP プロトコルをサポートするメッセージングプロバイダとの通信に使用できる、単純なワイヤープロトコルを定義します。

メッセージキュー 4.4 は、STOMP ブリッジサービスを通して STOMP プロトコルのサポートを提供します。このサービスにより、メッセージキュー ブローカは STOMP クライアントと通信できます。

STOMP ブリッジサービスの詳細は、次の情報を参照してください。

その他の拡張機能

メッセージキュー 4.4 には、次の拡張機能も追加されています。

新しい Universal Message Service (UMS) の機能

UMS には、HTTP GET を使用して次のようなサービスを提供する機能が追加されました。

UMS の概要については、「Universal Message Service (UMS)」を参照してください。UMS API のドキュメントについては、https://mq.dev.java.net/4.3-content/ums/protocol.html を参照してください。各言語のプログラミング例については、https://mq.dev.java.net/4.3-content/ums/examples/README.html を参照してください。

IPS パッケージのサポート

現在の メッセージキュー は、オープンソースの Image Packaging System (IPS) を使用して配布用にパッケージされています。IPS は、pkg(5) システムとも呼ばれます。このパッケージ方法は、メッセージキュー を Sun GlassFish Enterprise Server 2.1.1 に統合するために追加されました。

メッセージキュー 4.3 の新機能

メッセージキュー 4.3 は、多数の機能拡張とバグ修正を含むマイナーリリースです。この節では、このリリースに含まれる新しい機能を説明します。

Universal Message Service (UMS)

メッセージキュー 4.3 では、HTTP 対応デバイスから Message Queue にアクセスするための、新しい UMS (Universal Message Service) とメッセージング API が導入されました。これにより、ほとんどのアプリケーションがほかのアプリケーションと通信できるようになり、JMS メッセージングの信頼性と保証された配信による利益を受けられるようになりました。また、UMS は JMS メッセージングのスケーラビリティーを拡張し、メッセージングクライアントの数がインターネットクラスの規模に達する場合でも対応できます。

アーキテクチャー

基本的な UMS のアーキテクチャーを次の図に示します。

図 1–1 UMS のアーキテクチャー

非 JMS クライアントと JMS プロバイダ間のゲートウェイとして機能する UMS を示す図

UMS は Web サーバーで動作し、言語的に中立でプラットフォームに依存しません。UMS は、非 JMS クライアントアプリケーションと JMS プロバイダ間のゲートウェイとして機能します。UMS API を使用して送信されたメッセージを受信し、受信したメッセージを JMS メッセージに変換して、JMS プロバイダのネイティブプロトコルを使用してプロバイダ内の送信先に送信します。同様に、JMS プロバイダの送信先からメッセージを受信してテキストまたは SOAP メッセージに変換し、UMS API を通してクライアントから要求されたとおりに、非 JMS クライアントにメッセージを送信します。

単純で言語に依存しないプロトコルベースの UMS API は、Web ベースのアプリケーションと非 Web ベースのアプリケーションの両方をサポートし、スクリプトおよびプログラミング言語の両方で使用できます。API は、REST (Representational State Transfer) 形式のプロトコルを使用する単純なメッセージング API と、SOAP メッセージヘッダーにプロトコルを埋め込む XML メッセージング API の、2 つの形式で提供されます。どちらの場合も、API は単一の http 要求だけを使用して、メッセージの送信または受信を行います。

UMS API の単純性と柔軟性により、AJAX、.NET、Python、C、Java、およびその他の多くのアプリケーションで、JMS 送信先にテキストメッセージや SOAP (添付ファイルを含む) メッセージを送信したり、JMS 送信先からメッセージを受信することができます。たとえば、Python アプリケーションは .NET アプリケーションと通信でき、iPhone は Java アプリケーションと通信することができます。

メッセージキュー 4.3 では、UMS は JMS プロバイダとして メッセージキュー のみをサポートします。

その他の機能

UMS は、先に述べた単純なゲートウェイとして機能するだけではありません。ステートレスクライアントセッションだけでなくステートフルセッションもサポートします。クライアントから要求された場合、UMS はクライアントアプリケーションのセッション状態を複数のサービス要求間で維持します。UMS でコンテナ管理による認証を使用したり、Message Queue ブローカとクライアントを認証するように設定することもできます。UMS はトランザクションもサポートするため、クライアントアプリケーションは複数のサービス要求を単一の不可分な単位としてコミットまたはロールバックすることができます。

UMS は Message Queue ブローカとの単一の接続上で多数のクライアントをサポートできるため、スケーラビリティーが最大となるように、ブローカの接続サービス上の負荷を軽減します。また、UMS の能力を水平方向に拡大することで、インターネットクラスの規模のメッセージング負荷に対応することもできます。

プロトコルベースの UMS API は単純であるため、クライアント側にクライアントライブラリは必要ありません。したがって、将来的に API を拡張して、クライアントアプリケーションをアップグレードすることなく、JMS の追加機能を実装することができます。

UMS の使用法

UMS を使用するには、Servlet 2.4 以降の仕様をサポートする Web コンテナに UMS を配備し、Message Queue ブローカを起動します。次に、適切な送信先を作成し、UMS API を使用してメッセージを送受信するメッセージングアプリケーションを作成します。

メッセージキュー 4.3 の配布に含まれる UMS の imqums.war ファイルは、プラットフォームごとに次の場所にインストールされます。

.war ファイルの名前は、必要に応じて変更できます。

表 1–5 imqums.war ファイルの場所

プラットフォーム 

imqums.war ファイルの場所

Solaris 

/usr/share/lib/imq

Linux 

/opt/sun/mq/share/lib

AIX 

IMQ_HOME/lib

Windows 

IMQ_HOME\lib

imqums.war を localhost:port で Web コンテナに配備した場合、UMS のドキュメントは次の場所で参照できます。

http://localhost:port/imqums

または、次の場所でも UMS のドキュメントを参照できます。

サポートされる Web コンテナ

現在、UMS は次の Web コンテナでサポートされます。

AIX プラットフォームのサポート

メッセージキュー 4.3 には、AIX プラットフォームのパッケージと、これらをインストールするためのインストーラが用意されています。

メッセージキュー の AIX 実装では、次のソフトウェアがサポートされます。

インストールの手順については、『Sun GlassFish Message Queue 4.4 Installation Guide』の第 4 章「AIX Installation」を参照してください。

AIX プラットフォームでは、メッセージキュー のファイルは メッセージキュー のホームディレクトリ (IMQ_HOME) 以下にだけインストールされます。IMQ_HOME は、mqInstallHome/mq ディレクトリを表します。mqInstallHome は、製品のインストール時に指定したインストールのホームディレクトリです (デフォルトでは、home-directory /MessageQueue)。

結果として メッセージキュー のディレクトリ構造は、Windows プラットフォームの場合と同じになります。『Sun GlassFish Message Queue 4.4 Administration Guide』の付録 A「Platform-Specific Locations of Message Queue Data」の Windows の節を参照してください。

メッセージキュー の AIX プラットフォームのサポートには、メッセージキュー C-API のサポートも含まれます。AIX プラットフォームで C アプリケーションをビルドおよびコンパイルする手順については、XREF を参照してください。

新しい ZIP ベースのインストーラ

メッセージキュー 4.3 では、ネイティブパッケージ配布ではなく、ZIP ベースの配布用に新しいインストーラが導入されました。インストーラは、メッセージキュー の新しい ZIP 形式の配布を AIX プラットフォームにインストールするために使用します。

新しいインストーラは、メッセージキュー の .ZIP ファイルをユーザーが書き込み可能な (root 特権を必要としない) 任意のディレクトリに展開し、メッセージキュー のインストールを Sun Connection に登録できるようにします。

ダウンロードバンドルのサイズを最小化するために、ZIP ベースの配布には Java ランタイムが含まれていません (ほとんどのサイトでは、すでにインストールされているはずです)。したがって、installer コマンドでは、JAVA_HOME 環境変数を使用するか、次のようにコマンド行に -j オプションを使用して、JDK または JRE を指定する必要があります。

$ installer -j JDK/JRE-path

JDK/JRE-path は、指定する JDK または JRE のパスです。

プラットフォームサポートの拡張

メッセージキュー では、次の更新されたプラットフォームサポートが保証されます。

その他の拡張機能

メッセージキュー には、次の拡張機能も追加されています。

Windows プラットフォームでの新しいディレクトリ構造

Windows プラットフォームでは、メッセージキュー のインストールディレクトリの構造が、AIX プラットフォームでのディレクトリ構造に一致するように以前のバージョンから変更されました。このディレクトリ構造は、今後 Solaris および Linux プラットフォームでも採用される予定で、単一のコンピュータへの複数のインストールや Sun Connection を利用した メッセージキュー の自動更新が容易になります。Sun Connection は、Sun のハードウェアとソフトウェアの追跡、構成、および維持を支援するために Sun が提供するサービスです。「インストーラでの Sun Connection 登録のサポート」を参照してください。

新しいブローカのプロパティー

ブローカの設定に、次の新しいプロパティーを使用できます。

表 1–6 ブローカのルーティングと配信のプロパティー

プロパティー 

タイプ 

デフォルト値 

説明 

imq.transaction.producer.maxNumMsgs

整数 

1000

プロデューサが単一のトランザクションで処理できるメッセージの最大数。リソースを使い果たさないように、この値は 5000 未満にすることを推奨します。 

imq.transaction.consumer.maxNumMsgs

整数 

100

コンシューマが単一のトランザクションで処理できるメッセージの最大数。リソースを使い果たさないように、この値は 1000 未満にすることを推奨します。 

imq.persist.jdbc.connection.limit

整数 

5

データベースに対して開くことができる接続の最大数。 

JMX 管理 API の機能強化

新しい属性と複合データキーが、次のように JMX API に追加されました。

詳細は、『Sun GlassFish Message Queue 4.4 Developer’s Guide for JMX Clients』の第 3 章「Message Queue MBean Reference」を参照してください。

ワイルドカードサブスクライバの永続サブスクリプションの一覧表示

永続サブスクリプションを一覧表示するコマンドは次のとおりです。

list dur [-d topicName]

このコマンドは、トピック名の指定を省略できるように拡張されています。トピックを指定しない場合、コマンドはすべてのトピック (ワイルドカード命名規則によるトピックを含む) について、すべての永続サブスクリプションを表示します。

メッセージキュー 4.2 の新機能

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

メッセージキュー 4.1 および 4.0 で導入された機能については、それぞれ、「メッセージキュー 4.1 の新機能」および「メッセージキュー 4.0 の新機能」を参照してください。

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

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

注 –

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

記号によるトピック送信先名の形式と使用例については、『Sun GlassFish Message Queue 4.4 Administration Guide』の「Supported Topic Destination Names」を参照してください。

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

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

この機能の使用法については、「XML ペイロードメッセージのスキーマ検証」を参照してください。

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

X/Open 分散トランザクションモデルに従って、分散トランザクションのサポートは、1 つ以上のリソースマネージャーで実行される操作の追跡と管理を行う分散トランザクションマネージャーに依存します。メッセージキュー 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 によって管理されます。

分散トランザクション機能の使用法については、『Sun GlassFish Message Queue 4.4 Developer’s Guide for C Clients』の「Working With Distributed Transactions」を参照してください。

メッセージキュー 4.2 には、Tuxedo トランザクションマネージャーに基づくプログラミング例が用意されています。これらのサンプルプログラムの使用法については、『Sun GlassFish Message Queue 4.4 Developer’s Guide for C Clients』の「Distributed Transaction Sample Programs」を参照してください。

注 –

分散トランザクション機能は、Solaris、Linux、および Windows プラットフォームでサポートされますが、現時点で保証されているのは Solaris プラットフォームのみです。

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

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

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

Sun Connection への メッセージキュー の登録については、『Sun GlassFish Message Queue 4.4 Installation Guide 』を参照してください。

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

メッセージキュー 4.2 では、JDBC ベースのデータストアとして MySQL データベースのサポートが導入されました。スタンドアロンブローカ用の JDBC データベースとして、MySQL Cluster Edition を使用できます。MySQL Cluster Edition は、拡張ブローカクラスタに必要な高可用性共有データストアとして使用することもできます。MySQL を使用するための メッセージキュー の設定については、『Sun GlassFish Message Queue 4.4 Administration Guide』の「Configuring a JDBC-Based Data Store」および『Sun GlassFish Message Queue 4.4 Administration Guide』の「Enhanced Broker Cluster Properties」を参照してください。

その他の拡張機能

先に述べた機能に加え、メッセージキュー 4.2 では次の拡張機能が導入されました。

メッセージキュー 4.1 の新機能

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

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

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

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

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

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

メッセージキュー 4.1 の拡張ブローカクラスタを設定するには、クラスタ内のブローカごとに、次のブローカプロパティーを指定します。

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

  1. 高可用性データベースをインストールします。

  2. JDBC ドライバの .jar ファイルをインストールします。

  3. 高可用性持続データストア用のデータベーススキーマを作成します。

  4. クラスタ内のブローカごとに、高可用性プロパティーを設定します。

  5. クラスタ内の各ブローカを起動します。

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

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

JAAS サポート

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

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

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

メッセージキュー 4.1 は、JDBC ベースのデータストアが拡張ブローカクラスタをサポートするように変更されました。このため、JDBC ベースのデータストアの形式がバージョン 410 に更新されました。バージョン 350、370、および 400 の形式は、バージョン 410 に自動的に移行されます。

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

ブローカの環境設定

メッセージキュー 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 のサポート

メッセージキュー 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 状態のトランザクションだけをロールバックすることができました。つまり、分散トランザクションの一部であるセッションが正常に終了しなかった場合、そのトランザクションは、管理者がクリーンアップできない状態のままになりました。メッセージキュー 4.1 では、コマンドユーティリティー (imqcmd) を使用して、STARTED、FAILED、INCOMPLETE、COMPLETE、および PREPARED の状態のトランザクションをクリーンアップ (ロールバック) することができます。

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

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

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

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

注 –

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

メッセージキュー 4.0 の新機能

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

注意 – 注意 –

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

JMX 管理 API のサポート

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

詳細は、『Sun GlassFish Message Queue 4.4 Developer’s Guide for JMX Clients 』を参照してください。

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

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

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

接続イベント通知 API

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

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

ブローカ管理の拡張機能

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

imqcmd コマンドの構文については、『Sun GlassFish Message Queue 4.4 Administration Guide』の第 16 章「Command Line Reference」を参照してください。

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

メッセージキュー 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 プロバイダのサポート

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

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

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

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

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

SSL サポート

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

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

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

java -DimqConnectionType=TLS 
      -DimqSSLIsHostTrusted=true ClientAppName

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

imqcmd list svc -secure -DimqSSLIsHostTrusted=true