BEA Tuxedo /Q の概要

ここでは、次の内容について説明します。

• はじめに

• キュー・システムのコンポーネントとタスク

• 管理者のタスク

• プログラマのタスク

 

---

はじめに

BEA Tuxedo/Q コンポーネントを使用すると、メッセージを永続的な記憶域 (ディスク) や一時的な記憶域 (メモリ) のキューに登録でき、後で取り出して処理できます。BEA Tuxedo アプリケーション・トランザクション・モニタ・インターフェイス (ATMI) を使用して、キューへのメッセージの登録、またはキューからのメッセージの取り出しを行う関数を実行できます。応答メッセージおよびエラー・メッセージは、キューに登録されて、後でクライアント・プログラムに返されます。管理コマンドのインタプリタを使用すると、キューの作成、表示、および変更を行うことができます。また、サーバを使用して、メッセージのキューへの登録、キューからの取り出し、キューからの転送、およびキューに関係するトランザクション管理の要求を受け取ることができます。

 

---

キュー・システムのコンポーネントとタスク

次の図は、キュー・システムのコンポーネントを示しています。

図 1-1 キュー・サービスの呼び出し

 

この図は、キュー・サービスの呼び出しで、キュー・システムの各コンポーネントがどのように動作するかを示しています。ここでは、この図を使用して、管理者とプログラマが BEA Tuxedo /Q コンポーネントを定義したり、メッセージをキューに入れて処理したり、応答を受け取る方法について説明します。図に示されているコンポーネントのサブセットを使用すると、単純なピア・ツー・ピア通信でキュー・サービスを使用できます。

キュー・スペースは、1 つのリソースです。このリソースには、X/Open の XA 準拠のリソース・マネージャ・インターフェイスからアクセスできます。このインターフェイスは、別の XA 準拠のリソース・マネージャと連携して、キューへの登録およびキューからの取り出しが 2 フェーズ・コミット・トランザクションの一部として行われるために必要です。

 

---

管理者のタスク

BEA Tuxedo の管理者は、サーバを定義し、キュー・サービスの呼び出しで縦の 2 本の破線の間に示されているキュー・スペースおよびキューを作成する必要があります。

キュー・サーバ・グループは、最低 1 つ定義します。その場合、TMS_QM をトランザクション・マネージャ・サーバにします。

このほかに、システムで提供される 2 つのサーバをコンフィギュレーション・ファイルに定義する必要があります。この 2 つのサーバは、次の処理を行います。

• メッセージ・キュー・サーバ TMQUEUE(5) は、メッセージをキューに登録したり、キューから取り出したりします。このサーバは、クライアントとサーバがキューに対してローカルであるかどうかにかかわらず、クライアントとサーバの代わりにメッセージに関する操作を行います。

• メッセージ転送サーバ TMQFORWARD(5) は、メッセージをキューから取り出して、アプリケーション・サーバに転送します。BEA Tuxedo システムでは、サーバ用の main() が用意されています。この関数は、サーバの初期化と終了、サービス・ルーチンへの着信要求の受信とディスパッチを行うためのバッファの割り当て、応答の正しい宛先へのルーティングを行います。このすべての処理は、アプリケーションに透過的です。既存のサーバは、自分のメッセージをキューから取り出したり、応答をキューに登録することは行いません。BEA Tuxedo /Q の目的の 1 つは、そのような既存のサーバを変更せずに、キューに登録されたメッセージに対して既存のサーバを利用できるようにすることです。TMQFORWARD サーバは、キュー・スペース内の 1 つ以上のキューからメッセージを取り出し、そのメッセージをキューと同じ名前のサービスを持つサーバに送信し、応答を待ちます。そして、発信元によって応答キューまたは異常終了キューが指定されている場合はメッセージの発信元の指定に従って 、対応する応答キューまたは異常終了キューに、正常終了応答または異常終了応答を登録します。

また、管理者は、キュー管理プログラム qmadmin(1) または APPQ_MIB(5) 管理情報ベース (MIB) を使用して、キュー・スペースを作成する必要があります。キュー・スペースには、キューが格納されます。たとえば、キュー・サービスの呼び出しでは、APP キュー・スペース内に 4 つのキューが存在しています。各キュー・スペースはリソース・マネージャ・インスタンスであり、1 つのグループに単一のリソース・マネージャ (RM) だけが存在できるため、キュー・スペースとキュー・サーバ・グループは 1 対 1 のマッピングです。

キュー・スペースの概念では、次に示す方法で、キュー間でオーバヘッドを共有することにより、キューに対応する管理オーバヘッドを減少させることができます。

• キュー・スペース内のキューは、メッセージ用の永続的な記憶域および非永続的な記憶域を共有します。

• キュー・サービスの呼び出しの単一のメッセージ・キュー・サーバ TMQUEUE は、単一のキュー・スペース内で、複数のキューに対してメッセージの登録と取り出しを行います。

• キュー・サービスの呼び出しの単一のメッセージ転送サーバ TMQFORWARD は、単一のキュー・スペース内で、複数のキューに対してメッセージの取り出しと転送を行います。

• キュー・サービスの呼び出しのトランザクション・マネージャ・サーバ TMS_QM の 2 つのインスタンスは、単一のキュー・スペース内で、複数のキューに対してトランザクションを実行します。トランザクション・マネージャ・サーバの 1 つのインスタンスは、非ブロッキング・トランザクション用に予約されています。そのため、高速で処理され、ブロッキング・トランザクションによって遅延されません。ブロッキング・トランザクションはトランザクション・マネージャ・サーバの 2 番目のインスタンスで処理されます。

管理者は、キュー・スペースに対して、アプリケーション・コンフィギュレーション内に単一のサーバ・グループを定義できます。その場合、UBBCONFIG にグループを指定するか、または tmconfig(1) を使用して (tmconfig、wtmconfig(1) を参照)、グループを動的に追加します。

• 最後に、管理者が 1 つのキュー・スペース内にあるキュー間でメッセージを移動させると、メッセージが異なる安定記憶領域にある場合よりもオーバヘッドが少なくなります。これは、1 フェーズ・コミットを行うことができるからです。

キューを定義する作業の 1 つに、キューのメッセージの順序を指定することがあります。キューの順序付けは、メッセージの可用期間、有効期限、優先順位、FIFO、LIFO のいずれか、またはこれらの組み合わせで決定します。

管理者は、この中から 1 つ以上の基準を指定します。その場合、最上位の基準から先に指定します。FIFO および LIFO の値は、最後に指定します。メッセージは、指定された順序付け基準に従ってキューに登録され、キューの先頭から取り出されます。管理者は、必要な数だけメッセージ・キュー・サーバを設定して、クライアントが安定キューに生成する要求に対応できるようにします。

データ依存型ルーティングは、同じサービスを提供するサーバが存在する複数のサーバ・グループ間でルーティングを行うために使用します。

管理上の目的から、定期的に取り出されないキューがしきい値に達したときに実行されるコマンドを設定できます。これは、キューに使用されるキュー・スペースのバイト数、ブロック数、または割合、あるいはキューのメッセージの数に基づいて設定します。このコマンドでは、TMQFORWARD サーバを起動してキューを取り出すか、または管理者にメールを送信して手動で処理します。

BEA Tuxedo システムでは、BEA Tuxedo インフラストラクチャのキューイング・サービス・コンポーネントを使用して、いくつかの操作が行われます。BEA Tuxedo インフラストラクチャは、セキュリティ、スケーラビリティ、キュー処理、トランザクションなどのサービスを提供します。たとえば、共用メモリの管理操作は、Queuing Services コンポーネントで提供されます。BEA Tuxedo アプリケーションで現在使用できない関数もあります。それらについては、その関数の説明で注記してあります。

キュー機能をクライアント間のピア・ツー・ピア通信で使用すると、クライアントは転送サーバを使用せずに、ほかのクライアントと通信できます。次の図は、ピア・ツー・ピア通信モデルを示しています。

図 1-2 ピア・ツー・ピア通信

 

 

---

プログラマのタスク

キュー・サービスの呼び出しのステップ 1 〜 3 で、tpenqueue(3c) を使用して、クライアントはアプリケーション・キュー・スペース内の SERVICE1 キューにメッセージを登録します。オプションとして、tpenqueue() の呼び出しに、応答キューおよび異常終了キューの名前を含めることができます。この例では、これらはキュー CLIENT_REPLY1 および FAILURE_Q になっています。クライアントは、メッセージに付ける相関識別子の値を指定することもできます。この値は、キュー間で同じです。そのため、キューのメッセージに対応付けられたどの応答メッセージまたは異常終了メッセージも、応答キューまたは異常終了キューから読み取られるときに識別できます。

クライアントは、デフォルトのキューの順序付け (たとえば、メッセージがキューから取り出せるようになるまでの時間) を使用するか、デフォルトのキューの順序付けを無効にすること (たとえば、メッセージをキューの先頭に置くこと、またはキュー上の別のメッセージの前に置くことを要求すること) ができます。tpenqueue() は、TMQUEUE サーバにメッセージを送信し、そのメッセージはキューに登録され、承認 (ステップ 3) がクライアントに送信されます。肯定応答は、クライアントが直接確認することはできません。ただし、クライアントが正常な戻り値を取得すると、肯定応答が送られたと見なすことができます。異常終了の戻り値には、異常終了の内容についての情報が含まれています。

キュー・マネージャによって割り当てられたメッセージ識別子は、アプリケーションに返されます。この識別子は、特定のメッセージをキューから取り出す場合に使用します。また、この識別子は、別の tpenqueue() 内で使用して、キューに次に登録されるメッセージの前にあるメッセージを識別することができます。

キューに登録されたメッセージをキューから取り出すには、そのメッセージをキューに登録したトランザクションが正常にコミットされている必要があります。

BEA Tuxedo /Q をキュー・サービスの呼び出しに使用している場合に、メッセージがキューの先頭に到達すると、TMQFORWARD サーバはそのメッセージをキューから取り出し、tpcall(3c) を介してキューと同じ名前を持つサービスに転送します。キュー・サービスの呼び出しでは、このキューとサービスは SERVICE1 という名前で、ステップ 4、5、および 6 がそれを示しています。クライアントの識別子、およびアプリケーションの認証キーは、メッセージをキューに登録したクライアントに設定されます。この 2 つは、キューから取り出されたメッセージがサービスに送信されるときに、そのメッセージに付加されます。

サービスが応答を返すと、TMQFORWARD はその応答 (オプションとしてユーザ戻りコードを伴う) を応答キューに登録します (キュー・サービスの呼び出しのステップ 7 を参照)。

その後 (キュー・サービスの呼び出しのステップ 8、9、および 10)、クライアントは tpdequeue(3c) を使用して、応答キュー CLIENT_REPLY1 から読み込んで応答メッセージを取得します。

tpdequeue() に TPQPEEK フラグを設定すると、メッセージをキューから削除せずに取り出すことができます。有効期限が過ぎたメッセージ、または管理者によって削除されたメッセージは、直ちにキューから削除されます。

トランザクション管理

トランザクション管理の目的の 1 つは、グローバル・トランザクション内でメッセージをキューに登録したりキューから取り出して、信頼性を確実にすることです。ただし、これとは相反する目的として、関与するトランザクションの数を最小限にして実行のオーバヘッドを減少させることがあります。

呼び出し元は、キュー処理を呼び出し元のトランザクションから分離して、自身が関与しているあらゆるトランザクションとは別のトランザクションで、メッセージをキューに登録することもできます。ただし、この場合のタイムアウトは、メッセージがキューに登録されているかどうかにかかわらず、認識されません。

より良い方法としては、次の図に示すように、呼び出し元のトランザクション内でメッセージをキューに登録します。

図 1-3 トランザクション境界の判定

 

この図では、クライアントがトランザクションを開始し、メッセージをキューに登録し、トランザクションをコミットしています。メッセージは、TMQFORWARD で開始される 2 番目のトランザクション内でキューから取り出されます。サービスは tpcall(3c) で呼び出されて実行され、応答が同じトランザクション内でキューに登録されます。クライアントは 3 番目のトランザクションを開始し、応答をキューから取り出します。また、別の要求メッセージをキューに登録する場合もあります。次の要求のキューへの登録は、前の要求からの応答をキューから取り出す処理と同じトランザクション内で行うことができます。そのため、実行中の処理では、3 番目と最初のトランザクションを 1 つにまとめることができます。

注記 システムでは、同じトランザクション内で、あるメッセージからの応答をキューから取り出し、次の要求をキューに入れることが可能です。ただし、同じトランザクション内で、要求をキューに入れ、応答をキューから取り出すことはできません。メッセージをキューから取り出すには、要求をキューに登録するトランザクションが正常にコミットされることが必要です。

応答メッセージの処理

応答メッセージは、tpenqueue() の呼び出し時に、アプリケーションによって指定することもしないことも可能です。その場合、それぞれ次のような結果になります。

• キュー・メッセージに応答キューが指定されていない場合、メッセージの処理以外の作業は要求されません。

• 応答キューを指定するメッセージがキューから取り出された場合、メッセージの発信者は、要求の実行が正常に終了したときに応答がキューに登録されることを要求しています。

  • アプリケーションが tpdequeue() を使用してメッセージを明示的にキューから取り出す場合、そのアプリケーションは tpenqueue() を呼び出して応答をキューに登録する必要があります。通常、これは要求メッセージがキューから取り出されて実行されるのと同じトランザクション内で行われます。そのため、この操作全体はアトミックに行われます。つまり、トランザクションが成功した場合にのみ、応答がキューに登録されます。

  • TMQFORWARD によってメッセージが自動的に処理される場合 (キューから取り出され、tpcall() を介してアプリケーションに渡される場合)、アプリケーション・サービスが正常に終了したとき、つまり TPSUCCESS が設定されて tpreturn(3c) が呼び出され、tpcall() が 1 を返さなかったときは、TMQFORWARD は応答をキューに登録します。tpcall() がデータを受け取ると、使用された型付きバッファは応答キューに登録されます。tpcall() でデータが受信されなかった場合、データなしのメッセージ (つまり、NULL メッセージ) が、キューに登録されます。メッセージがキューに登録されることは、それが NULL であっても、操作の完了を示すには十分です。

エラー処理

エラーを処理するには、アプリケーションに起こるエラーの特徴を理解することと、BEA Tuxedo 管理者とアプリケーション・プログラム開発者の注意深い計画と協力が必要です。BEA Tuxedo /Q では、メッセージがトランザクション内でキューから取り出され、そのトランザクションがロールバックされたときに、再試行パラメータが 0 より大きい場合は、メッセージがキューに戻されて、再度取り出しと実行が可能になります。

一時的な障害の場合は、少し時間をおいてから、メッセージの取り出しと実行を再試行します。たとえば、アプリケーション・データベースに対するアクティビティが多数ある場合は、別のトランザクションによってデータベースのロックが解除されるには、少しの時間さえあればよい場合があります。通常、再試行の回数に上限を設定することも、なんらかのアプリケーション不備によってリソースを著しく浪費することを防ぐには有用です。管理者がキューを設定するときに、再試行の回数と遅延時間 (秒単位) の両方を指定できます。再試行の回数 0 は、再試行が行われないことを示します。再試行の回数が上限に達すると、管理者がキュー・スペースに設定するエラー・キューにメッセージが移動されます。

障害が一時的なものではない場合もあります。たとえば、キュー・メッセージが存在しないアカウントに対して操作を要求する場合などです。その場合、再試行してリソースを浪費しないようにします。アプリケーション・プログラマまたは管理者が、特定の操作の失敗が一時的ではないと判断した場合、単に再試行の回数を 0 に設定します。同じサービスに対する障害が、一時的なものであったり、永続的なものであったりする場合がよくあります。管理者およびアプリケーション開発者は、いろいろな方法でエラーに対処できるようにしておきます。

アプリケーションは、直接メッセージをキューから取り出すことも、TMQFORWARD サーバを使用することもできます。また、トランザクションをコミットするようにロジックで指示されている場合に、トランザクションがロールバックされたり、メッセージがキューに再度登録されたりするエラーが発生することがあります。そのため、多様な問題が発生します。このような問題とその対処法については、BEA Tuxedo /Q の管理、BEA Tuxedo /Q の C 言語プログラミング、およびBEA Tuxedo/Q COBOL 言語プログラミングを参照してください。

まとめ

BEA Tuxedo /Q によって BEA Tuxedo アプリケーション・プログラマおよび管理者に提供される機能は、次のようにまとめることができます。

• アプリケーション・プログラミング・インターフェイスを使用して、要求をキューに登録して後で処理することができます。システムでは、要求が 1 回だけ正常に実行されることが保証されます。デフォルトでは、失敗した場合はメッセージがキューに戻されます。また、アプリケーション・プログラミング・インターフェイスを使用して、キューの先頭から、またはメッセージ識別子や相関識別子によって、メッセージを取り出すことができます。

• アプリケーション・プログラムや管理者は、キューのメッセージの順序付けを制御できます。その場合、基準を設定して順序付けします。基準としては、メッセージの可用期間、有効期限、優先順位、LIFO、FIFO のいずれか、またはこれらの組み合わせを使用できます。アプリケーションは、順序付けを無効化して、キューの先頭や、既にキューに登録されている特定のメッセージの前にメッセージを入れることができます。

• BEA Tuxedo サーバを使用して、クライアントおよびサーバ (リモート・クライアントやサーバの場合もあります) に代わって、メッセージをキューに登録したりキューから取り出すことができます。サーバのコピーをいくつ設定するかは、管理者が決定します。

• BEA Tuxedo サーバを使用して、キューからメッセージを取り出して、サービスに転送して実行できます。このサーバを使用すると、既存のサーバを変更せずにキューに登録された要求を処理できます。各転送サーバは、1 つ以上のキューを処理するように設定できます。トランザクションでは、1 回だけ処理が行われることが保証されます。管理者は、設定する転送サーバの数を決定します。

• 管理者は、処理のためにキューに格納されたメッセージを管理できます。たとえば、失敗時に要求を再試行する回数、再試行を行う間隔、キュー上のメッセージの再順序付け、キューの容量の管理などを行います。

キューに登録されたメッセージを使用するアプリケーション・パラダイムは多数あります。このようなパラダイムでは、マシン、サーバ、またはリソースが使用できない場合、または信頼性が低い場合 (広域ネットワークやワイヤレス・ネットワークの場合など) に、要求をキューに登録できます。また、ワーク・フローで、プロセスの次のステップを行うために各ステップでキュー要求を生成できます。さらに、処理に時間がかかるトランザクションのバッチ処理で、発信元が完了を待たなくても、最終的にはメッセージが処理されたことを保証できます。ピア・ツー・ピア関係で、関係がない 2 つのアプリケーション間で、データ・パイプを提供することもできます。