JP2005502122A - ソフトウェア・キューイング・アプリケーションを監視するためのシステムおよび方法 - Google Patents

Abstract

【課題】メッセージ・キューイング送信システムにおいて、上流および下流のソフトウェア・アプリケーションを監視するためのコンピュータ実施方法を提供すること。
【解決手段】この送信システムは、少なくとも１つの入力キューからの複数の入力メッセージを読み出し、複数の出力メッセージを少なくとも１つの出力キューに書き込むことができる少なくとも１つの処理タスクを含む。この方法では、各入力キューのメッセージ数、および各出力キューのメッセージ数を判断し、処理タスクのアクティブ化状況を判断し、これらの結果を集めてタスク・モニタ画面上に表示することができる。長さと状況の情報は、定期的にリフレッシュされる。
【選択図】図１

Description

【技術分野】
【０００１】
本発明は、一般には、コンピュータ・ネットワークにおけるデータ伝送に関し、より詳細には、ソフトウェア・キューイング・アプリケーションを監視するためのシステムおよび方法に関する。
【背景技術】
【０００２】
ＦＤＤＩ、ＢＩＳＤＮ、ＳＯＮＥＴなどのネットワーク通信標準の出現により、現在はギガバイト・コンピュータ通信の時代になり、またテラバイト通信の時代が急速に近づいている。こうした高速ネットワーク環境には、ネットワークからの情報に依存して、ネットワーク設計、ネットワーク管理、ネットワーク制御機能およびネットワーク・サービスの助けとなる、新しい強力なツールが必要である。こうした高速環境に伴う問題は、１つまたは複数の高速通信チャネルからの生データを監視し、このデータを、必要時にはいつでも、アルゴリズムへの入力として、ユーザ、サービスにとって有用な「情報」に変換することなどである。
【０００３】
今日まで、こうした問題は、「リアルタイム」のネットワーク監視およびパフォーマンス評価であると見られてきた。ネットワーク監視は一般に、システムの運用に関する動的情報を抽出、処理、収集および提示することと定義される。その後、監視情報は、リアルタイムでネットワーク・リソースの状態を評価するために、ネットワーク・パフォーマンス管理のアナリスト、通常はコンピュータ表示装置上で監視情報を分析する個人によって使用される。
【０００４】
大規模なネットワーキング構造を管理する要件の１つは、異なるプラットフォームを含み得るコンピュータ・ネットワーク全体にわたって情報を伝送する役割を担う、多数の様々なアプリケーションを監視することである。
【０００５】
こうしたアプリケーションの一部は、バックグランド・タスクであり、一般にユーザ・インターフェイスを提供しないことから、通常このように呼ばれる。様々なシステム間で情報を伝送する役割を担うバックグランド・タスクに関する行動情報が必要とされている。実際に、アプリケーション・オペレータは、伝送が成功したか否か、またその伝送に問題またはボトルネックが生じているか否かを知る必要がある。残念ながら、バックグランド・タスクは、状況情報を提供せず、したがって、アプリケーション・オペレータは、アプリケーションが正しく動作しているか否かを判断する術がない。
【０００６】
異機種アプリケーション伝送に対して広く使用される手法に、メッセージ・キューイングがある。メッセージ・キューイングによって、分散されたアプリケーションが、ハードウェアおよびソフトウェアのリソースに関係なく、メッセージを交換することができる。メッセージ・キューイング・システムでは、アプリケーションを送信するのに、送達ルートまたは受信側アプリケーションがいつメッセージを取り出すかのタイミングを気に掛ける必要はない。受信側アプリケーションは、送信側アプリケーションとの直接のリンクを必ずしも維持せずに、適宜新しいメッセージを取り出すことができる。また受信側アプリケーションは、必要に応じて受信確認を行うことができる。
【０００７】
メッセージは、アプリケーション間を、同期をとっても、また非同期でも流れることができる。同期モードでは、送信側アプリケーションは、受信側アプリケーションからの返信を受け取ってから続行することができる。またメッセージは、一対一モード、一対多モード、多対一モードまたその任意の組合せのモードでアプリケーション間を流れることができる。
【０００８】
一般に、メッセージ・アプリケーションは２つの部分、すなわちアプリケーション・データとメッセージ識別データを含む。メッセージは、複数のパラメータ、たとえばメッセージ・タイプ、アプリケーション・データの長さ、メッセージの優先順位によって識別することができる。
【０００９】
メッセージ・アプリケーションおよびそのリソースを監視するためのいくつかの方法が知られている。Tivoli SystemのTivoliや、IBMコーポレーションのOmegamonなどの商品によって、キューを監視し、アプリケーションの状況を判断することができる。こうした商品を用いる際には、アプリケーション・オペレータは、必要な措置を講じるのに必要なパラメータを見つけるために、連続して複数のパネル間をナビゲートしなければならない。そうしている間に、アプリケーション上で発生する重要な問題を見落とすというリスクがある。
【００１０】
IBMコーポレーションのMQSeriesやＣＩＣＳなどの他の商品では、キューの長さおよびアプリケーションの状況を判断する方法が提供される。
【００１１】
Bonnell他に発行された米国特許５，６５５，０８１号では、自律型の知的エージェント・アーキテクチュア（intelligentautonomous agent architecture）を使用して、分散コンピューティング環境全体にわたってコンピュータのリソースおよびアプリケーションを監視し管理するためのシステムを開示している。前記の商品と同様に、このシステムでは、キューが、所定の数のアプリケーション識別のないメッセージを含むとき、アラート・メッセージを起動することができる。
【００１２】
しかし、監視対象の特定のアプリケーションに関連する、タスク状況およびキューの長さを収集する唯一のインターフェイスをオペレータに提供するツールは現在存在せず、既知のシステムでは、システム全体のすべてのアプリケーションに関する情報が提供される。
【発明の開示】
【発明が解決しようとする課題】
【００１３】
したがって、使用中のあるアプリケーションおよびそのリソースに関連する全ての情報を収集する単一のシステムを、アプリケーション・オペレータに提供することが求められている。
【課題を解決するための手段】
【００１４】
本発明の一目的は、エラー検出に有用な情報を自動的に唯一のビューに集める、アプリケーション監視システムを提供することである。
【００１５】
本発明の別の目的は、ユーザとの対話（user interaction）なしに動作するこうしたシステムを提供することである。
【００１６】
本発明は、前記その他の目的を、メッセージ・キューイング送信システム（messagequeuing transmission system）において、上流および下流のソフトウェア・アプリケーションを監視するコンピュータ実施方法を提供することによって実現する。この送信システムは、少なくとも１つの入力キューから複数の入力メッセージを読み出し、複数の出力メッセージを少なくとも１つの出力キューに書き込むことができる、少なくとも１つの処理タスクを含む。この方法は、以下のステップを含む。
ａ．入力キューおよび出力キューにそれぞれ入力および出力キュー・グループ識別子を割り当てるステップ
ｂ．各キュー・グループごとに、各入力キューおよび各出力キューにキュー識別子を割り当てるステップ
ｃ．処理タスクにタスク識別子を割り当てるステップ
ｄ．所定のリフレッシュ時間間隔のリフレッシュ・カウンタを初期設定するステップ
ｅ．各キュー・グループごとに、各入力キューに格納されたメッセージの数および各出力キューに格納されたメッセージの数を判断するステップ
ｆ．識別された処理タスクのアクティブ化状況（activation status）を判断するステップ
ｇ．タスク・モニタの記憶域に、上記両方の判断ステップの結果を集めるステップ
ｈ．時間間隔ごとに、（ｅ）から（ｇ）のステップを繰り返すステップ
【００１７】
好ましい一実施形態では、集められた結果が、オペレータが制御する表示画面に表示される。
【００１８】
別の実施形態では、上流のアプリケーションが入力メッセージを送り、下流のアプリケーションが出力メッセージを受信する。この送信システムは、少なくとも１つの出力メッセージに応答した、下流アプリケーションからの少なくとも１つの応答メッセージを受信するための少なくとも１つの応答キューをさらに含み、また応答メッセージを処理するための少なくとも１つの応答タスクをさらに含む。
【００１９】
別の実施形態では、この方法は、出力メッセージが出力キューに書き込まれる時点と、それに対応する応答メッセージが応答メッセージ・キューに書き込まれる時点との時間間隔を計算するステップをさらに含む。時間間隔の値に従って、警告メッセージをオペレータに表示することができる。
【発明を実施するための最良の形態】
【００２０】
まず図１を参照して、本発明の方法を実施することができる、簡略化したメッセージ・キューイング送信システム１００をこれから説明する。一般に、バックグランド・タスクに関する入力情報（incoming information）は、上流の外部ソフトウェア・アプリケーション１０２から送られ、送信システム１００内で、いくつかのキュー・レイヤを通って処理されてから、下流の外部ソフトウェア・アプリケーション１０８に出力される。
【００２１】
本発明は、ハードウェア、オペレーティング・システム、また接続に関係なく、ネットワーク化されたどんなコンピューティング環境においても動作させることができる。したがって、こうした側面については言及しない。
【００２２】
具体的には、入力情報が、上流アプリケーション１０２から届き、このアプリケーションは、複数のメッセージを入力キュー「Ｇ１」に入れる。次いで、メッセージは、入力タスク１０４によって捕捉され、何らかのアプリケーション論理プロセスの後で、中間キュー「Ｇ２」に提供される。次いで、中間メッセージ・キュー「Ｇ２」が出力タスク１０６によって処理され、次いでこのタスクが、出力メッセージを出力キュー「Ｇ３」に引き渡す。次いで、出力情報が下流アプリケーション１０８によって取り出される。
【００２３】
下流アプリケーション１０８は、出力メッセージの受信確認を行うことができ、送信システムに応答メッセージをフィードバックし、応答キュー「Ｇ４」に応答メッセージを残す。次いで、このメッセージが１つまたは複数の応答タスク１１０によって処理される。
【００２４】
この送信システムのタスクは、エラー情報をエラー・ログ・キュー１１６に送ることができる。
【００２５】
それぞれのキューおよびそれぞれのタスクは、タスク・モニタ１１２によって監視される。図２から５を参照して以下で詳述するように、このタスク・モニタは、情報送信システムの状況の唯一の全体像をいつでも提供することができる。タスク・モニタ１１２は、システムの効率を判断するのにアプリケーション・オペレータが必要とする状況データを、送信システムに沿って収集し、こうしたデータをタスク・モニタの記憶域１１３に書き込む。好ましい一実施形態では、収集されるデータは、キューの長さ、タスクのアクティブ化／非アクティブ化状況、出力キューと応答キューのタイム・スタンプの差、およびエラー・ログ・キューの内容である。
【００２６】
次いで、収集された送信システムの状況は、タスク・モニタ記憶域１１３から読み出され、モニタ画面１１４上に表示される。
【００２７】
本発明は、メッセージ・キューイング送信システムの様々な構成に適用できることが当業者には理解されよう。表現「タスク」、「アプリケーション」、「常駐トランザクション」は、送信システムの内部プロセッサ（１０４、１０６、１１０）を指すために使用できることも理解されよう。さらに、メッセージを格納するキューは、標準のメッセージ・キューイング製品、たとえば前述のIBMコーポレーションのMQSeriesなどの形態のものでよい。
【００２８】
図２に、タスク・モニタ１１２によるモニタ画面１１４上の表示２００を示す。図５を参照して以下に述べるように、この表示は、オペレータが指定する間隔に従ってリフレッシュされる。タスク・モニタ１１２は、数個のタスク・グループ（ＴＳＫ１からＴＳＫ５）を制御しているとき、図１のメッセージ・キューイング送信システムの状況を表示する。表示２００は、数個の情報領域（２０２〜２０６）を含む。第１の情報領域２０２は、「キューの長さ」状況に関する情報を提供する。第２の情報領域２０４は、「ログ・メッセージ」状況に関する情報を提供し、最後の情報領域２０６は、「時間制御」パラメータ状況および「バックグランド・タスク」のアクティブ化／非アクティブ化状況に関する情報を提供する。
【００２９】
「キューの長さ」領域２０２は、図１の送信システムのそれぞれのキュー内に、所与の時点で存在しているメッセージの数を示す。
【００３０】
図３を参照して以下で詳述するように、「キューの長さ」領域には、「キュー・グループ」と同数の行がある。それぞれの行には、そのキュー・グループ内のキューと同数の列がある。
【００３１】
キューの長さの値が０であると、関連するアプリケーションにバックログがなく、そのアプリケーションが適切に動作した可能性が高いことを示す。キューの長さが０以外の値であると、バックログがあることを示し、それによって、特に、表示２００のリフレッシュの後でそのバックログが消えない場合は、措置が必要であることをオペレータに示す。何らかの理由で、キューの長さを判断することができない場合は、タスク・モニタ画面１１４上に、特別な警告が表示される。
【００３２】
この警告は、対応する行を特別な色で表示すること、および警告メッセージを「ログ・メッセージ」領域２０４に出すことを含むことができる。「ログ・メッセージ」領域２０４は、タスクからログ・キュー１１６に送られた連続するエラー・メッセージを含む。
【００３３】
図２の「バックグランド・タスク」と称される別の情報領域２０６は、監視対象のそれぞれ異なるバックグランド・タスクのリストを含む。バックグランド・タスク領域はさらに、時間制御機能の（「イネーブル」または「ディセーブル」することができる）状況の表示を含むことができる。時間制御機能については、図４を参照して以下で説明するが、タスク・モニタ１１２は、時間制御機能があってもなくても動作することができることにここで留意されたい。さらに、ここで示す画面表示２００の例示的な編成は、本発明を限定するためのものではなく、当業者なら、本発明の教示があれば、関連するパラメータの他の表示を容易に考案することができよう。
【００３４】
次に図３を参照すると、タスク・モニタ１１２を操作するためのキュー構成をサポートする好ましい実装が、タスク・テーブル３０２およびキュー・テーブル３０４、３０６の形で示されている。テーブルは、以下のようにキューおよびタスクを識別する識別子を含む。さらに説明するように、テーブルの内容は、タスク・モニタ１１２の開始時に読み込まれる。
【００３５】
バックグランド・タスクは、各バックグランド・タスクのタスク名を示す第１の識別子、およびアクティビティを監視しようとする各タスクのタスク番号を示す第２の識別子に従って分類してタスク・テーブル３０２に入れる。
【００３６】
キューは、キュー・グループ・テーブル３０４で参照されるキュー・グループに分類される。キュー・グループ・テーブル３０４は、グループ名を示す第１の識別子、およびグループ番号（Ｇ１〜Ｇｎ）を示す第２の識別子を含む。キューのグループ化は、メッセージ・キューイング送信システムの特定の構成によって決まり得る。図１の例では、キューは４つのグループ、すなわち入力グループ「Ｇ１」、中間グループ「Ｇ２」、出力グループ「Ｇ３」、応答グループ「Ｇ４」に分けられる。応答グループに関連するグループ・テーブルは、応答グループが関連付けられるグループ番号を示す別の識別子を含む。この例では、応答グループ「Ｇ４」は、出力グループ「Ｇ３」と関連付けられる。
【００３７】
それぞれのキュー・グループは、そのキュー・グループに属する複数のキューを詳述するキュー・テーブル３０６にリンクされる。それぞれのキュー・テーブルは、それが関連付けられるキュー・グループ番号を示す第１の識別子、そのキュー・グループ番号のキュー番号を示す第２の識別子、およびキュー・タイプを定義する第３の識別子を含む。キューがアクティブかどうかを示す別の識別子を追加することができる。
【００３８】
応答グループでは、別の識別子が、応答キュー番号が関連付けられるキュー番号を示す。この例では、キュー番号「Ｇ４−１」は、出力キュー「Ｇ３−３」と関連付けられる。こうした例は、本発明を限定するためのものではなく、説明をわかりやすくするため提示するものにすぎない。当業者なら、本発明の教示があれば、データ・テーブルの他の構成を考案することができよう。
【００３９】
以下で詳述するように、応答キュー・グループと出力キュー・グループの対応付けにより、時間制御機能で使用される形の複数のキュー対（出力キュー、応答キュー）を構成することができる。
【００４０】
時間制御機能は、メッセージが出力キューに書き込まれる時点と、応答が応答キューに書き込まれる時点の時間間隔を計算する。したがって、出力グループに応答する応答グループについては、それぞれの応答キューを、出力グループに属する出力キューの１つにリンクされているものとして定義することができる。
【００４１】
キュー・タイプ情報は、参照されるアプリケーションについて、プログラムがどのようにキューにアクセスするか、たとえば、ＣＩＳＣコマンドを使用してＣＩＳＣキューにアクセスするのか、あるいはＭＱステートメントを使用してMQ Seriesタイプのキューにアクセスするのかを示す。
【００４２】
図４は、例示的な実施形態における、本発明の時間制御機能の操作を示すフローチャートである。しかし、時間制御機能は任意選択であり、本発明は、この機能なしで実施することができる。タスク・モニタ１１２は、時間制御機能がイネーブルされていでも、ディセーブルされていても開始することができる。時間制御機能の目的は、下流アプリケーション（１０８）の機能を監視することである。下流アプリケーションは、出力キュー（Ｇ３）から読み出し、関連する応答キュー（Ｇ４）に「受信確認」応答メッセージを書き込む。時間制御機能は、出力キュー（Ｇ３）へのメッセージの書込みと、応答キュー（Ｇ４）への対応する応答メッセージの書込みの間の経過時間を判断することができる。これによって、下流アプリケーション（１０８）が適切に動作しているかどうかに関する情報を、アプリケーション・オペレータに提供する。
【００４３】
時間制御機能は、それぞれの対（出力キュー、応答キュー）ごとに、アクティブ化することができる。
【００４４】
ステップ４００で、時間制御機能がイネーブルされて、処理が開始する。時間制御の間隔が決定される（ステップ４０２）。図５を参照して以下で説明するように、時間制御間隔は、オペレータによって指定される。オペレータがそれぞれのキュー対ごとに同じ値に固定することが好ましい。時間制御間隔は、下流アプリケーション（１０８）によって取り出される前に、メッセージが出力キュー（Ｇ３）内にあることが許容される時間を指定する。
【００４５】
次いで、時間制御カウンタが、最初の時間制御間隔についてカウントし始める（ステップ４０４）。
【００４６】
それぞれのキュー対ごとに、出力タスク（１０６）が最後のメッセージを出力キュー（Ｇ３）のうちの１つに入れた（本明細書では、最終書込み（put）と称する）時点を、応答タスク（１１０）が最終応答メッセージを受信した時点と比較する（ステップ４０６）。
【００４７】
最終書込みが、最終応答よりも前に行われている場合（イエス分岐）は、下流アプリケーションが速やかにメッセージを処理していることを示す。前の状況確認で警告メッセージがイネーブルされている場合（ステップ４１２）には、下流アプリケーションのメッセージ読出しが追いついた可能性があるので、その警告がディセーブルされ（ステップ４０８）、時間制御カウンタが再度開始する（ステップ４０４）。
【００４８】
最終書込みが最終応答よりも後に行われている場合（ノー分岐）は、下流アプリケーション（１０８）が出力キュー（Ｇ３）内のメッセージを速やかに処理していないことを示す。この非アクティブな時間が、時間制御間隔によって指定された時間の範囲内かどうかを判断する（ステップ４１０）。
【００４９】
この時間が時間制御間隔によって指定された時間の範囲内である場合（分岐ＮＯ）は、警告を出すには早すぎ、処理がループ・バックする（ステップ４０６）。
【００５０】
この時間が時間制御間隔によって指定された時間よりも長い場合（分岐ＮＯ）は、現在のキュー対について警告メッセージがイネーブルされ（ステップ４１２）、それが表示される（ステップ４１４）。上記で説明したように、警告メッセージは、ログ・メッセージ領域２０４に送信され、ある長さのキュー内の対応する行を強調表示することができる。
【００５１】
図５は、本発明のタスク・モニタ・システムの操作を示すフローチャートである。
【００５２】
タスク・モニタ１１２が開始され、処理が開始する（ステップ５００）。モニタ画面上に、完成すべき入力フォームがオペレータに提示される。このフォームで、以下のものを要求することができる。
・リフレッシュ間隔値
・時間制御状況（イネーブル／ディセーブル）
・それぞれのキュー対の時間制御間隔値
【００５３】
リフレッシュ間隔によって、収集された関連するデータの状況をリフレッシュするタイミングを制御する。情報領域は、リフレッシュ間隔値によって指定される一定の間隔でリフレッシュされ、更新されたデータが表示される。好ましい実装では、リフレッシュ間隔は数秒に設定される。
【００５４】
タスク・モニタ１１２によってテーブルが読み出され（ステップ５０４）、監視対象の構成が決定される。したがって、キュー・テーブル３０４、３０６およびタスク・テーブル３０２に格納された情報を（それぞれのアクセス方法に従って）取り出し、関連するデータを収集する。こうしたテーブルは、リレーショナル・データベース・システムに格納しても、フラット・ファイルとして格納してもよく、本発明の一般的方法に影響は及ぼさない。特に、タスク・モニタ１１２は、タスク・テーブル３０２では、タスク番号およびタスク名の値を指し、そのアクティビティが制御対象になる。タスク・モニタ１１２は、テーブル３０４および３０６では、グループ番号の値を指し、そのグループに属するキューのキュー長がリフレッシュ間隔の終了ごとに表示される。さらに、タスク・モニタ１１２は、応答キューのキュー番号の値を指す。
【００５５】
次いで（ステップ５０６で）、キュー対（出力キュー、応答キュー）が生成される。キュー対は、それぞれのキュー対ごとに以下の表で示す情報を含む、出力−応答アレイの形で構成される。
【００５６】
【表１】

【００５７】
出力−応答アレイは、出力キューにメッセージを入れるタスク、および応答キューからメッセージを取り出すタスクの両方からアクセスできるように、メモリ域に格納することができる。
【００５８】
出力キューにメッセージを入れるタスクは、「最終書込み」フィールドに、タイム・スタンプ（書込みが行われた時点）を書き込み、応答キューからメッセージを取り出すタスクは、「最終応答」フィールドに、タイム・スタンプ（取出しが行われた時点）を書き込む。
【００５９】
応答キューが実装されない一実施形態では、処理は直接、図５のステップ５０４からステップ５０８に進む。出力−応答アレイが生成された後、そのリフレッシュ間隔のリフレッシュ・カウンタが開始する（ステップ５０８）。それぞれのリフレッシュ間隔の間、操作のシーケンス・ループが実行される。
・ステップ５１０で、タスク・モニタ１１２にタスク状況を尋ねることによって、アクティブなバックグランド・タスクのリストが決定される。その結果を監視対象のタスクのリストと比較する。タスクが実行されていない場合は、オペレータに警告する（ステップ５１８）。タスク情報領域２０６内の対応するタスク名を強調表示することができ、ログ・メッセージ領域２０４の次のログ・ライン上に警告メッセージを表示することができる。
・ステップ５１２で、それぞれのアクティブなキュー内に存在するレコード数を判断し、レコード数を判断することができない場合は、ログ・メッセージをログ・メッセージ領域２０４に生成し、そのキュー列の対応する値を、キューの長さ領域２０２で強調表示する（ステップ５１８）。
・ステップ５１４で、ログ・キューを読み出し、実装、たとえばＳＱＬテーブル、ファイル、データのレビューが可能な他の任意の永続的レポジトリに応じて、情報を記憶手段に格納する。ログ・キューを読み出している間に問題が発生した場合は、ログ・メッセージ領域２０４にエラー・メッセージを出す。好ましくは、ログ・メッセージ領域（２０４）の上部分（upper region）に情報を表示し、オペレータが常に最終ログ・メッセージを見るように、古いコンテンツ領域を自動的にスクロール・ダウンする（ステップ５１８）。
・ステップ５０２で時間制御機能がイネーブルされている場合には、図４を参照して説明したように、ステップ５１６で、それぞれのキュー対（出力キュー、応答キュー）ごとに、時間制御プロセスを動作させる。時間制御機能がイネーブルされていない場合には、処理は直接、ステップ５１４から５１８に進む。
・ステップ５１８で、ステップ５１０、５１２、５１４および５１６で収集されたデータを集め、タスク・モニタ記憶域１１３に書き込み、モニタ画面上に表示する。
・ステップ５２０で、終了のメッセージを入力するオプションをオペレータに提供し、ステップ５２２で、タスク・モニタ１１２によって終了コマンドが受信された場合は、処理を終了する（ステップ５２４）。そうでない場合は、オペレータが終了メッセージを入力するまで、処理はステップ５０８にループする。
【００６０】
本発明を、その特定の実施形態を参照して示し説明したが、本発明の精神および範囲から逸脱せずに、形態および詳細についての様々な変更が行われ得ることが当業者には理解されよう。
【図面の簡単な説明】
【００６１】
【図１】本発明の方法が実施されるメッセージ・キューイング送信システムの簡略図である。
【図２】図１のシステムのメッセージ・キューイング情報を表示する本発明のタスク・モニタ画面を示す図である。
【図３】本発明のキューおよびタスク構成を扱うためのテーブル構造を示す図である。
【図４】本発明の時間制御操作を示すフローチャートである。
【図５】本発明のタスク・モニタ・システムの操作を示すフローチャートである。

Claims (12)

1. 少なくとも１つの処理タスクが実行中であるメッセージ・キューイング送信システムにおいて、上流および下流のソフトウェア・アプリケーションを監視するためのコンピュータ実施方法であって、
   メッセージ・キューイング送信システム内で、第１入力キューおよび第２入力キューに入力キュー・グループ識別子を割り当てることによって第１キュー・グループを形成するステップと、
   前記メッセージ・キューイング送信システム内で、第１出力キューおよび第２出力キューに出力キュー・グループ識別子を割り当てることによって第２キュー・グループを形成するステップと、
   前記第１入力キューに第１キュー識別子を、前記第２入力キューに第２キュー識別子を、前記第１出力キューに第３キュー識別子を、および前記第２出力キューに第４キュー識別子を割り当てるステップと、
   前記メッセージ・キューイング送信システム内で、処理タスクにタスク識別子を割り当てるステップと、
   前記第１入力キューに格納された第１のメッセージ数と、前記第２入力キューに格納された第２のメッセージ数と、前記第１出力キューに格納された第３のメッセージ数と、および前記第２出力キューに格納された第４のメッセージ数とを判断するステップと、
   前記処理タスクのアクティブ化状況を判断するステップと、
   タスク・モニタ記憶域に、前記第１入力キューに格納された前記第１メッセージ数と、前記第２入力キューに格納された前記第２メッセージ数と、前記第１出力キューに格納された前記第３メッセージ数と、前記第２出力キューに格納された前記第４メッセージ数と、および前記処理タスクの前記アクティブ化状況とを集めるステップとを含む方法。
2. リフレッシュ・カウンタのリフレッシュ時間間隔に従って、前記両判断ステップおよび前記集めるステップを繰り返す、請求項１に記載の方法。
3. 前記タスク・モニタ記憶域の内容を、表示画面上に提示するステップをさらに含む、請求項１に記載の方法。
4. 前記処理タスクからのエラー・メッセージを、エラー・ログ・キューに書き込むステップをさらに含む、請求項１に記載の方法。
5. 前記エラー・メッセージを表示画面上に提示するステップをさらに含む、請求項４に記載の方法。
6. 前記第１キュー識別子と、前記第２キュー識別子と、前記第３キュー識別子と、および前記第４キュー識別子とがそれぞれ異なる、請求項１に記載の方法。
7. 前記処理タスクがバックグランド・タスクである、請求項１に記載の方法。
8. 前記タスク識別子をタスク識別子テーブルに格納するステップと、
   前記第１キュー・グループ識別子と前記第２キュー・グループ識別子とを、キュー・グループ・テーブルに格納するステップと、
   前記第１キュー識別子と、前記第２キュー識別子と、前記第３キュー識別子と、および前記第４キュー識別子とを、キュー・テーブルに格納するステップとをさらに含む、請求項１に記載の方法。
9. 出力メッセージに応答して生成される応答メッセージを受信するための応答キューに、応答先グループ識別子を割り当てるステップをさらに含み、前記応答メッセージが、前記出力メッセージを受信する下流のソフトウェア・アプリケーションによって生成される、請求項１に記載の方法。
10. 前記応答メッセージが前記応答キューから取り出され、応答タスクによって処理される、請求項９に記載の方法。
11. 前記メッセージ・キューイング送信システムの出力キューへの出力メッセージ書込みと、前記応答キューへの前記応答メッセージ書込みとの時間間隔を計算するステップをさらに含む、請求項９に記載の方法。
12. 前記時間間隔を、所定の時間制御間隔と比較するステップをさらに含む、請求項１１に記載の方法。

Images