JMS メッセージングの実装に使用されるオブジェクトは、基本的にプログラミングドメイン全体で同じです。つまり、コネクションファクトリ、コネクション、セッション、プロデューサ、コンシューマ、メッセージ、および送信先が使用されます。図 2–5 に、この様子を示します。図の上から下に向かい、コネクションファクトリオブジェクトからどのようにオブジェクトが生成されるかを示しています。
これらのオブジェクトのうち、コネクションファクトリと送信先の 2 つは、1 つのオブジェクトストア内にあるように示されています。これは、これらのオブジェクトが通常、管理対象オブジェクトとして作成、設定、管理されるという点を強調するためです。この章を通じて、コネクションファクトリと送信先は、プログラムではなく管理操作によって作成されると想定しています。
表 2–2 は、メッセージの送受信に必要な手順をまとめています。手順 1 から 6 は、送信側と受信側で同じであることに注意してください。
表 2–2 メッセージのプロデュースとコンシューム
メッセージのプロデュース |
メッセージのコンシューム |
---|---|
1. 管理者がコネクションファクトリ管理対象オブジェクトを作成します。 |
|
2. 管理者が、物理的な送信先と、それを参照する管理対象オブジェクトを作成します。 |
|
3. クライアントが、JNDI 検索を使用して、コネクションファクトリオブジェクトを取得します。 |
|
4. クライアントが、JNDI 検索を使用して、送信先オブジェクトを取得します。 |
|
5. クライアントが、コネクションを作成し、このコネクションに固有の任意のプロパティーを設定します。 |
|
6. クライアントが、セッションを作成し、メッセージングの信頼性を決定するプロパティーを設定します。 |
|
7. クライアントがメッセージプロデューサを作成します。 |
クライアントがメッセージコンシューマを作成します。 |
8. クライアントがメッセージを作成します。 |
クライアントがコネクションを開始します。 |
9. クライアントがメッセージを送信します。 |
クライアントがメッセージを受信します。 |
以降の節では、プロデューサとコンシューマが使用するオブジェクト、つまりコネクション、セッション、メッセージ、および送信先について説明します。続いて、メッセージのプロデュースとコンシュームについて説明し、JMS オブジェクトの説明を締めくくります。
クライアントは、コネクションファクトリオブジェクト (ConnectionFactory) を使用して、コネクションを作成します。コネクションオブジェクト ( Connection)は、ブローカへのクライアントのアクティブなコネクションを表します。デフォルトで起動されるか、このクライアントの管理者が明示的に起動する基礎となるコネクションサービスを使用します。
通信リソースの割り当てとクライアントの認証は、コネクションが作成されるときに行われます。このオブジェクトは比較的重いため、ほとんどのクライアントはメッセージングのすべてを 1 つのコネクションだけで行います。コネクションは同時使用をサポートするため、複数のプロデューサとコンシューマが 1 つのコネクションを共有できます。
コネクションファクトリを作成するときに、そのプロパティーを設定しておくことによって、コネクションファクトリから生成されるすべてのコネクションの動作を設定できます。Message Queue の場合、次の情報を指定します。
ブローカが存在するホストの名前、必要なコネクションサービス、およびそのサービスへアクセスするためにクライアントが使用するポート。
コネクションに障害が生じた場合に、ブローカへの自動再接続を処理する方法。この機能は、コネクションが失われた場合に、クライアントを同じ (または別の) ブローカに接続し直します。データのフェイルオーバーは保証されません。別のブローカへ再接続した場合、持続メッセージとほかの状態情報が失われる可能性があります。
接続を試行するユーザーのデフォルト名とパスワード。接続時にパスワードが指定されない場合、この情報がユーザーの認証と操作の承認に使用されます。
ブローカとクライアントランタイムとの間で、コントロールメッセージおよびペイロードメッセージのフローを制御する方法。
クライアントアプリケーションの起動に使用するコマンド行から、コネクションファクトリのプロパティーをオーバーライドできます。また、どのコネクションのプロパティーも、そのコネクションのプロパティーを設定することによってオーバーライドできます。
コネクションオブジェクトを使用して、セッションオブジェクトの作成、例外リスナーの設定、または JMS バージョンおよびプロバイダ情報の取得を行えます。
コネクションがクライアントとブローカ間の通信チャネルである場合、セッションは、クライアントとブローカ間の単一のやり取りをマークします。セッションオブジェクトは、主にメッセージ、メッセージプロデューサ、およびメッセージコンシューマの作成に使用します。セッションを作成するときには、多数の通知オプションまたはトランザクションを使用して、信頼性の高い配信を設定します。詳細は、「信頼性の高いメッセージング」を参照してください。
JMS 仕様によれば、セッションは、シングルスレッドコンテキストで、メッセージのプロデュースとコンシュームを実行します。単一のセッションに対して複数のメッセージプロデューサとコンシューマを作成できますが、順番に使用するという制限があります。スレッド処理の実装は、Java クライアントと C クライアントでは少し異なります。スレッド処理の実装および制限の詳細は、該当する開発者ガイドを参照してください。
また、セッションオブジェクトを使用して、次の処理も行えます。
一時トピックおよびキューの作成および設定。これらは、要求 / 応答パターンの一部として使用されます。「要求 / 応答パターン」を参照してください。
トランザクション処理のサポート。
メッセージのプロデュースまたはコンシュームの順番の定義。
メッセージは、ヘッダー、プロパティー、および本体の 3 つの部分で構成されています。 メッセージを正しく作成し、特定のメッセージング動作を設定するために、この構造を理解する必要があります。
すべての JMS メッセージにはヘッダーが必要です。ヘッダーには、あらかじめ定義された 10 のフィールドがあります。これらについて、表 2–3 で説明します。
表 2–3 JMS 規定のメッセージヘッダー
この表からわかるように、メッセージヘッダーフィールドは、さまざまな目的に使用されます。たとえば、メッセージの識別、メッセージのルーティングの設定、メッセージ処理に関する情報の提供などです。
もっとも重要なフィールドの 1 つである JMSDeliveryMode によって、メッセージ配信の信頼性が決まります。このフィールドは、メッセージが持続かどうかを示します。
持続メッセージは、必ず 1 回だけ配信されてコンシュームされることが保証されています。持続メッセージは、メッセージサービスで障害が発生しても消失しません。
非持続メッセージは、1 回は配信されることが保証されています。非持続メッセージは、メッセージサービスで障害が発生した場合に消失する可能性があります。
メッセージヘッダーフィールドにはプロバイダ (ブローカまたはクライアントランタイム) が設定するものも、クライアントが設定するものもあります。メッセージプロデューサは、特定のメッセージング動作を得るために、ヘッダー値を設定する必要が生じる場合があります。メッセージコンシューマは、メッセージがどのようにルーティングされ、どのような追加処理が必要かを認識するために、ヘッダー値を読み込む必要が生じる場合があります。
ヘッダーフィールド (JMSDeliveryMode JMSExpiration および JMSPriority) は、次の 3 つの異なるレベルに設定できます。
コネクションファクトリから生成されたすべてのコネクションから出されるメッセージ用。
プロデュースされた各メッセージ用。
特定のメッセージプロデューサから出されるすべてのメッセージ用。
これらのフィールドを複数のレベルに設定した場合、コネクションファクトリに対して設定された値は、個々のメッセージに対して設定された値をオーバーライドします。特定のメッセージに対して設定された値は、メッセージのプロデューサに対して設定された値をオーバーライドします。
メッセージヘッダーフィールドに使用する定数名は、実装されている言語によって異なります。詳細は、『Sun Java System Message Queue 3.7 UR1 Developer’s Guide for Java Clients』または『Sun Java System Message Queue 3.7 UR1 Developer’s Guide for C Clients』を参照してください。
メッセージは、プロパティーと呼ばれるオプションのヘッダーフィールドも含めることができます。このフィールドは、プロパティー名とプロパティー値のペアとして指定されます。クライアントとプロバイダはプロパティーを使用して、メッセージヘッダーを拡張し、メッセージの識別と処理に役立つすべての情報を含めることができます。受信側クライアントは、メッセージプロパティーを使用して、指定された基準に適合したメッセージだけを配信するように要求できます。たとえば、コンシューミングクライアントは、ニュージャージーで働くパートタイム従業員の給与に関するメッセージが必要であることを示すことができます。プロバイダは、指定された基準に適合しないメッセージを配信しません。
JMS 仕様では、9 つの標準プロパティーが規定されています。クライアントが設定するプロパティーもあれば、プロバイダが設定するプロパティーもあります。その名前は予約文字「JMSX」で始まります。クライアントまたはプロバイダは、これらのプロパティーを使用して、メッセージの送信者、メッセージの状態、メッセージが配信された回数および時間を判断できます。これらのプロパティーは、プロバイダがメッセージをルーティングしたり、診断情報を提供したりする際に役立ちます。
Message Queue でもメッセージプロパティーが定義されています。これらのプロパティーは、圧縮されたメッセージを識別し、そのメッセージを配信できない場合の処理方法を識別するために使用されます。詳細は、『Sun Java System Message Queue 3.7 UR1 Developer’s Guide for Java Clients』の「Managing Message Size」を参照してください。
メッセージ本体には、クライアントが交換しようとするデータが含まれます。
表 2–4 に示すように、JMS メッセージのタイプによって、本体に含まれる内容と、コンシューマによる処理方法が決まります。セッションオブジェクトには、メッセージ本体の各タイプに応じた作成メソッドが含まれます。
表 2–4 メッセージ本体のタイプ
タイプ |
説明 |
---|---|
本体に Java プリミティブ値のストリームを含むメッセージです。順番に入力され、読み取られます。 |
|
本体に名前値のペアを含むメッセージです。エントリの順番は定義されていません。 |
|
本体に、XML メッセージなどの Java 文字列を含むメッセージです。 |
|
本体にシリアライズされた Java オブジェクトを含むメッセージです。 |
|
本体に未解釈バイトのストリームを含むメッセージです。 |
|
ヘッダーとプロパティーは含むが、本体は含まないメッセージです。 |
Java クライアントは、送信するメッセージの本体をクライアントランタイムで圧縮するように、プロパティーを設定することができます。コンシューマ側の Message Queue ランタイムは、メッセージを圧縮解除してから配信します。