【０００１】
【発明の属する技術分野】
本発明はプログラム間におけるメッセージ通信技術に関する。
【０００２】
【従来の技術】
情報処理の形態は、かつては専らメインフレームと端末による集中型処理であったが現在ではクライアントサーバ方式が主流となりつつあり、その基盤は分散処理方式である。この分散処理方式における通信方式として柔軟で拡張性に富んだシステムを構築するためメッセージキューを介し、クライアントとサーバシステム間の通信を非同期に通信する非同期メッセージ通信を活用したシステム構築の事例が急速に広まっている。非同期メッセージ通信ではクライアントアプリケーションはサーバシステムへの処理要求メッセージを送信キューに格納したところで要求処理を手放すことができ、さらにクライアントアプリケーションはサーバシステムから応答された処理結果メッセージをキューから取り出すことで参照できる。
【０００３】
つまり非同期メッセージ通信はサーバシステムへの処理要求メッセージの送信やサーバからの処理結果メッセージの受信がクライアントアプリケーションから離れ、バックグラウンドで実行できるといった特徴がある。処理要求メッセージを実行できる業務アプリケーションを持ったサーバシステムが複数存在する場合もクライアントアプリケーションは処理要求メッセージがどのサーバシステムに送信されて実行されるかは検知する必要がない。しかし、業務アプリケーションの実行待ちによる停滞がより少ないサーバシステムを送信先として選択することが望まれる。
【０００４】
従来の処理要求メッセージの送信先サーバシステムの選択方法としては特許文献１に開示されているようなサーバシステムからクライアントに通知される可用性データに基づいて送信可能なサーバシステムを選択し、選択可能なサーバシステムが複数存在する場合は例えばラウンドロビン方式などの任意の負荷分散ロジックに基づいたアルゴリズムにより解決される。
【０００５】
【特許文献１】
特開平１１−３２８１３２号
【０００６】
【発明が解決しようとする課題】
上記従来技術はクライアントがサーバシステムから受信する受信可／否データをもとに送信先が決定されるが、受信可能となっているサーバシステムが複数存在するときクライアント内の負荷分散ロジックに依存される。例えばクライアントがラウンドロビン方式を採用している場合、特定のサーバシステムが業務アプリケーションの実行遅延などの理由から既に多数の処理要求メッセージを抱えている場合でもクライアントはそのサーバシステムを送信先として選択し、処理要求メッセージを送信してしまうため、サーバシステム間での処理要求メッセージの仕掛かりが均等化できなくなり、特定のサーバシステムで多数の処理要求メッセージをもつ傍ら他のサーバシステムで処理要求メッセージの到着待ちとなるなどシステム全体のスループットが低下する場合があるといった問題があった。
【０００７】
本発明は、サーバシステム間の負荷のアンバランスの改善や、サーバシステムのリソースをより効率的に利用することを目的とする。
【０００８】
【課題を解決するための手段】
上記の目的を達成するために以下の方法を用いるものである。クライアントの送信要求アプリケーションで発行されるサーバシステムの業務アプリケーションに対する処理要求メッセージは処理要求メッセージのサーバシステム送信時に送信先判定テーブルを参照することで、同一業務アプリケーションをもったサーバシステムの集まりであるサーバグループの中から処理要求メッセージの送信先サーバシステムを選択する。ここでいうメッセージ通信は、端末と計算機もしくは計算機間の通信、もしくはプログラム間やオブジェクト間、プログラムとオブジェクト間の通信でも良い。
【０００９】
クライアントで保持する送信先判定テーブルは後述のサーバグループ内負荷管理装置により受け取るテーブルであり、サーバグループ内の全てのサーバシステム内の受信キューに格納されているメッセージ数とそれぞれの「起動中」または「停止中」の業務アプリケーションの実行状況を保持している。
【００１０】
クライアントにおける送信先サーバシステムの判定基準は送信先判定テーブルのレコード内で最もメッセージ数が少ない業務アプリケーションが「起動中」のサーバシステムを選択する。ここでもし、前記の条件を満たすサーバシステムが複数存在した場合はそのうちどのサーバシステムを選択しても良い。クライアントは選択したサーバシステムへ処理要求メッセージを送信する。送信が成功すると送信時にサーバシステムから受け取った最新の受信キューのメッセージ数と業務アプリケーションの実行状況を送信先判定テーブルの送信先サーバシステムのレコードに対して更新する。
【００１１】
ここでもし、サーバシステムへの処理要求メッセージの送信に失敗した場合は、サーバシステムに障害が発生しているものと判断し、送信先判定テーブル内の該当するサーバシステムの業務アプリケーションの実行状況を「停止中」に変更することで当該サーバシステムへの処理要求メッセージの送信を抑止する。なお、クライアントが処理要求メッセージの送信時に参照する送信先判定テーブルには有効期限を設けてサーバグループ内負荷管理装置より更新した送信先判定テーブルがクライアント定義による間隔を経過した場合は使用せず、再びサーバグループ内負荷管理装置から最新データを取得する。
【００１２】
サーバグループ内負荷管理装置では定期的およびサーバシステムの業務アプリケーションの状態が「起動中」から「停止中」、または「停止中」から「起動中」に変わる度に各サーバシステムが通知する更新データをもとにサーバグループ内の全てのサーバシステムの受信キューに格納されているメッセージ数と業務アプリケーションの実行状況を管理する。サーバグループ内負荷管理装置ではシステムで定義された一定の間隔内に更新データを送付しなかったサーバシステムについてサーバシステムに障害が発生しているものと判断し、送信先判定テーブル内の該当サーバシステムの業務アプリケーションの実行状況を「停止中」に変更することで当該サーバシステムへの処理要求メッセージの送信を抑止する。
【００１３】
サーバシステム内では受信キューの処理要求メッセージがシステムで定義された一定の間隔取り出しが行われていないと業務アプリケーションが異常停止していると判断し、サーバシステムの業務アプリケーションの実行状況を「停止中」としてサーバグループ内負荷監視装置に通知し、処理要求メッセージの送信を抑止する。さらに当該サーバシステムはサーバグループ内負荷監視装置から受信キュー管理テーブルの状態を取得し、クライアントのサーバシステム選択手順と同様な手順で転送先のサーバシステムを選択し、転送先サーバに向けてメッセージを送信する。
【００１４】
サーバシステムでの業務アプリケーションの実行状況は業務アプリケーションが開始または実行契機で「開始中」に設定され終了時に「停止中」に設定される。つまりサーバグループ内負荷管理装置での更新データの通知のよる監視やーバシステム内での受信キューの処理要求メッセージの取り出しの監視によって抑止されたクライアントからの処理要求メッセージの送信やサーバシステムの転送処理は業務アプリケーションの開始時または実行時に解除する。
【００１５】
【発明の実施の形態】
以下、本発明の実施例を図面より説明する。図１は本発明の一実施例の概略構成図である。
図１において１０１はクライアントを示す。２０１はサーバグループ４０１に属するサーバシステムを示す。また３０１はサーバグループ４０１に設置されたサーバ内負荷管理装置を示す。
【００１６】
クライアント１０１はサーバグループ４０１のサーバシステムの業務アプリケーション２１に対する処理要求をするクライアント処理要求アプリケーション１０と処理要求メッセージを生成する処理要求メッセージ生成部１１と処理要求メッセージを蓄積するクライアント送信キュー１２とサーバグループ４０１の中から送信先のサーバシステム２０１を選択するクライアントメッセージ送信先判定部１３と送信先サーバシステムを選択するため判定情報となる送信先サーバ判定テーブル１４を有する。ここでいうアプリケーションは、プログラム、業務プログラム、オブジェクトでも良い。
【００１７】
さらにクライアント１０１はサーバシステム２０１より送付される処理結果メッセージを格納するためのクライアント受信キュー１５とクライアント受信キュー１５から処理結果メッセージを取り出すクライアント処理結果メッセージ応答部１６および処理結果をクライアント１０１のユーザに向けて結果を表示するクライアント結果表示アプリケーション１７を有する。さらにクライアント１０１からサーバシステム２０１へ処理要求メッセージを送信するクライアントメッセージ送信部１８とサーバシステム２０１からの処理結果メッセージ受信し、クライアント受信キュー１５へ格納するクライアントメッセージ受信部１９を有する。
【００１８】
サーバシステム２０１はクライアント１０１から受信した処理要求メッセージを蓄積できるサーバ受信キュー２０と処理要求メッセージに応じた業務データベース２２に検索や更新などのアクセスをし、サーバ送信キュー２３へ処理結果メッセージを格納する業務アプリケーション２１と処理結果メッセージを蓄積するサーバ送信キュー２３とサーバ受信キュー２０の処理要求メッセージの格納を監視するサーバ送信キュー監視部２４とクライアント１０１から処理要求メッセージを受信してサーバ受信キュー２０へ格納するサーバメッセージ受信部２８とクライアント１０１への処理結果メッセージの送信を行うサーバメッセージ送信部２９を有する。
【００１９】
さらにサーバシステム２０１はサーバ受信キュー２０の処理要求メッセージの格納数を管理するサーバ受信キュー状態管理部２５と業務アプリケーション２１の起動と停止状態を監視し、停止状態になるとサーバ受信キュー２０の処理要求メッセージを他のサーバシステム２０１へ転送する業務アプリケーション状態監視部２６とその転送先となるサーバシステムを選択するため判定情報となる転送先サーバ判定テーブル２７を有する。
【００２０】
サーバグループ内負荷管理装置３０１はサーバグループ４０１内の全てのサーバシステム２０１のサーバ受信キュー２０のメッセージ数と業務アプリケーションの状態を管理する受信キュー管理テーブル３２とサーバシステム２０１から通知される情報を受信キュー管理テーブル３２に更新する受信キュー負荷状態更新部３１とクライアント１０１またはサーバシステム２０１からのサーバ受信キュー管理テーブル３２の参照に応答する受信キュー負荷状態応答部３０を有する。
【００２１】
なお、システム内のクライアント１０１およびサーバシステム２０１にはそれぞれシステム全体でユニークとなるクライアントＩＤまたはサーバシステムＩＤを付与するものとする。
【００２２】
クライアント１０１においてクライアント処理要求アプリケーション１０は図２に示したフローチャート１０２０１に従って実行する。クライアント処理要求アプリケーション１０は例えばグラフィカルユーザインタフェースなど任意のユーザアプリケーションを介して、サーバシステムにおける例えば業務データベース更新や検索要求など任意の処理要求を受け付け、処理要求をクライアント処理要求メッセージ生成部に通知する。
【００２３】
クライアント処理要求メッセージ生成部１１は図３に示したフローチャート１０３０１に従って実行する。クライアント処理要求メッセージ生成部１１は図１９に示す処理要求メッセージ形式１９０１に従った処理要求メッセージを作成する。処理要求メッセージのメッセージ種別フィールドには本メッセージが処理要求メッセージであることを示すシステム共通で定めた識別子を更新する。メッセージＩＤフィールドにはシステム全体でユニークとなる任意のメッセージＩＤを更新する。メッセージＩＤをシステム全体でユニークにする方法については規定しない。例えば「クライアントＩＤ＋メッセージ生成時刻＋同一時刻内の生成通番」などが考えられる。メッセージ生成時刻フィールドには現在時刻を更新する。要求元クライアントＩＤフィールドには自クライアントＩＤを更新する。処理要求内容フィールドにはクライアント処理要求アプリケーション１１から受け付けた処理要求を更新する。次にクライアント処理要求メッセージ生成部１１は作成した処理要求メッセージをクライアント送信キュー１２に格納する。
【００２４】
クライアント送信キュー１２はクライアントメッセージ送信先判定部１３によって監視される。クライアントメッセージ送信先判定部１３は図４に示したフローチャート１０４０１に従って実行する。クライアントメッセージ送信先判定部１３はクライアント送信キュー１２に処理要求メッセージが到着すると、まずはクライアント１０１内で管理される送信先サーバ判定テーブル１４のデータ更新時刻を参照する。現在時刻がデータ更新時刻からクライアント１０１内であらかじめ定義された更新間隔を経過している場合は以下の手順により送信先判定テーブル１４を最新情報に更新する。クライアントメッセージ送信先判定部１３は図２２に示したサーバ負荷情報送信依頼電文形式２２０１に従ったサーバ負荷情報送信依頼電文を作成する。
【００２５】
サーバ負荷情報送信依頼電文の電文種別フィールドには本電文がサーバ負荷情報送信依頼電文であることを示すシステム共通で定めた識別子を更新する。依頼元システムＩＤフィールドには自クライアントＩＤを更新する。
【００２６】
作成したサーバ負荷情報送信依頼電文はサーバグループ内負荷管理装置３０１のサーバ受信キュー負荷情報応答部３０へ送信する。
サーバ受信キュー負荷情報応答部３０からは図２３に示したサーバ負荷情報応答電文形式２３０１に従ったサーバ負荷情報応答電文が返却される。
【００２７】
サーバ負荷情報応答電文にはサーバグループ４０１に属したサーバシステム毎のサーバ受信キューのメッセージ数と業務アプリケーションのステータス情報が埋め込まれている。クライアントメッセージ送信先判定部１３はこのサーバ負荷情報応答電文を受け取るとサーバ負荷情報応答電文の先頭サーバシステムＩＤフィールドのシステムＩＤから最終サーバシステムＩＤフィールドのシステムＩＤまで順番に図２７に示した送信先判定テーブル形式２７０１の形式をもった送信先判定テーブル１４にサーバ負荷情報応答電文のサーバ受信キューメッセージ数フィールドと業務アプリケーションステータスフィールドの内容を更新する。なお、送信先判定テーブル１４のクライアント１０１内での保持方法は規定しない。ただし、クライアント１０１のシステム軽度を保つためにはメモリ上で保持することが望ましい。送信先判定テーブル１４の更新が完了するとクライアント１０１のシステム内固有に管理される送信先サーバ判定テーブル１４のデータ更新時刻を現在時刻に更新する。
【００２８】
クライアントメッセージ送信先判定部１３は次に送信先サーバ判定テーブル１４を使用して処理要求メッセージの送信先サーバシステムを選択する。処理要求メッセージの送信先サーバシステムの選択処理の手順については後述する。
【００２９】
クライアントメッセージ送信先判定部１３は処理要求メッセージの送信先サーバシステムの選択処理により送信先サーバシステムが選択できなかった場合は送信先サーバ判定テーブル１４のデータ更新時刻から更新間隔が経過するまで待ち、再びサーバ負荷情報送信依頼電文の作成処理に戻る。送信先サーバシステムが選択できた場合、クライアント送信キュー１２から処理要求メッセージを取得し、取得した処理要求メッセージの送信先サーバシステムＩＤフィールドに送信先サーバシステムの選択処理で選択した送信先サーバシステムのサーバシステムＩＤを更新する。そしてクライアントメッセージ送信部１８へ処理要求メッセージを通知し、送信指示する。クライアントメッセージ送信部１８による処理要求メッセージの送信処理が終わるとクライアントメッセージ送信部１８からの戻り値を判定し、送信成功が返却された場合は戻り値に付与されたメッセージ数と業務アプリケーションステータスを送信先サーバ判定テーブル１４の送信先サーバシステムのレコードに対して更新する。
【００３０】
またクライアントメッセージ送信部１８から送信失敗が返却された場合は該当サーバシステムが送信先サーバシステムとして選択されないように送信先サーバ判定テーブル内の業務アプリケーションステータスフィールドを「停止中」に変更する。その後、クライアントメッセージ送信先判定部１３はクライアント受信キュー１２のメッセージ監視処理に戻り、これら一連の処理を繰り返す。
クライアントメッセージ送信先判定部１３の送信先サーバシステムの選択処理は図５に示すフローチャート１０５０１に従って実行する。まず送信先サーバ判定テーブル１４の全てのレコードを参照し、業務アプリケーションステータスフィールドが「起動中」のサーバシステムＩＤを抽出する。ここでもし、「起動中」のサーバシステム２０１が一つも存在しない場合は選択可能なサーバシステム２０１がないものと判断し、「選択可能なサーバシステムなし」を返却する。
【００３１】
起動中のサーバシステム２０１が１つしかないときはそのサーバシステムが送信先サーバシステムとして選択されることになり、そのサーバシステムのサーバシステムＩＤを返却する。また、起動中のサーバシステム２０１が複数あるときはサーバ受信キューメッセージ数が最も少ないサーバシステム２０１を選択し、そのサーバシステム２０１のサーバシステムＩＤを返却する。また、サーバ受信キューメッセージ数については、他に比べて少ないものでもある程度の効果は期待できる。
【００３２】
ここでもし、サーバ受信キューメッセージ数が同一のサーバシステム２０１が複数存在した場合は、そのうちでどのサーバシステム２０１を選択しても良いものとする。例えばシステムＩＤの小さい方を優先的に選択することで一つのサーバシステム２０１を特定できる。
【００３３】
クライアントメッセージ送信部１８はクライアントメッセージ送信先判定部１３が選択したサーバシステム２０１へ処理要求メッセージを送信する。クライアントメッセージ送信部１８は図６に示したフローチャート１０６０１に従って実行される。
【００３４】
クライアントメッセージ送信部１８は送信指示を受け付けると図２４に示したメッセージ送信電文形式２４０１に従うメッセージ送信電文を作成する。メッセージ送信電文の電文種別フィールドには本電文がメッセージ送信電文であることを示すシステム共通で定めた識別子を更新する。依頼元システムＩＤフィールドには自クライアントＩＤを格納する。メッセージフィールドにはクライアントメッセージ送信先判定部１３より受け取った処理要求メッセージを更新する。そして処理要求メッセージの送信先サーバシステムＩＤフィールドを参照し、そのサーバシステム２０１のサーバメッセージ受信部２８に向けてメッセージ送信電文を送信する。
【００３５】
その後送信先のサーバシステムから図２５に示したメッセージ送信応答電文形式２５０１に従うメッセージ送信応答電文が返るのを待つ。ここでもし、システムで定義した応答タイムアウト間隔内にメッセージ送信応答電文が返らないとき、送信先サーバシステムは停止しているものと判断し、クライアント送信キューに処理要求メッセージを戻し、送信失敗を返却する。送信先のサーバシステム２０１からメッセージ送信応答電文が返るとメッセージ送信応答電文の応答結果フィールドを参照し、応答結果が送信成功のときサーバ受信キューメッセージ数フィールドと業務アプリケーションステータスフィールドの値を戻り値に付与し、送信成功を返却する。応答結果が送信失敗の場合はクライアント送信キュー１５に処理要求メッセージを戻し、送信失敗を返却する。
【００３６】
クライアントメッセージ送信部１８が送信するメッセージ送信電文はサーバメッセージ受信部２８が受信する。サーバメッセージ受信部２８は図１１に示したフローチャート１１１０１に従って実行する。サーバメッセージ受信部２８はメッセージ送信電文を受け取るとまず、サーバシステム内で保持している業務アプリケーションステータスを参照する。この業務アプリケーションステータスはサーバシステム内の業務アプリケーションが「起動中」か「停止中」かを表わす情報で例えば共用メモリ領域などで管理されたサーバシステム２０１内の機能間で参照および更新ができる共通情報である。
【００３７】
業務アプリケーションステータスが「起動中」のときメッセージ送信電文から処理要求メッセージを取り出し、サーバ受信キュー２０に格納する。そしてサーバ受信キュー２０の現在のメッセージ数を参照する。その後、メッセージ送信応答電文を作成する。メッセージ送信応答電文の電文種別フィールドには本電文がメッセージ送信応答電文であることを示すシステム共通で定めた識別子を更新する。サーバ受信キューメッセージ数フィールドには参照したサーバ受信キュー２０の現在のメッセージ数を更新する。業務アプリケーションフィールドには現在の業務アプリケーションステータスを更新する。応答結果フィールドは送信成功に更新する。 そして作成したメッセージ送信応答電文をメッセージ送信電文の依頼元システムＩＤフィールドに格納されている依頼元システムに向けて送信する。業務アプリケーションステータスが「停止中」のときは同様にメッセージ送信応答電文を作成するが、電文種別フィールドを更新した後、応答結果フィールドには送信失敗を更新する。サーバ受信キューメッセージ数フィールドと業務アプリケーションステータスフィールドは更新する必要はない。作成したメッセージ送信応答電文は同様の手順で依頼元システムに送信する。
【００３８】
サーバシステム２０１の受信キュー２０はサーバ受信キュー状態管理部２５により監視される。サーバ受信キュー状態管理部２５は図１２に示したフローチャート１１２０１に従って実行する。サーバ受信キュー状態管理部２５はサーバシステム内であらかじめ定義したサーバ受信キュー監視間隔毎または業務アプリケーション状態監視部からの受信キューの状態報告指示により、図２１に示したサーバ受信キュー状態報告電文形式２１０１に従うサーバ受信キュー状態報告電文を作成する。サーバ受信キュー状態報告電文の電文種別フィールドには本電文がサーバ受信キュー状態報告電文であることを示すシステム共通で定めた識別子を更新する。サーバシステムＩＤフィールドには自サーバシステムＩＤを更新する。サーバ受信キューメッセージ数フィールドにはサーバ受信キュー２０から現在の処理要求メッセージ数を取得し、更新する。
【００３９】
さらに業務アプリケーションステータスフィールドにサーバシステム内で管理する業務アプリケーションステータスを更新する。作成したサーバ受信キュー状態報告電文はサーバグループ内負荷管理装置３０１のサーバ受信キュー負荷状態更新部３１に通知する。
【００４０】
サーバ受信キュー負荷状態更新部３１は図１８のフローチャート１１８０１に従って実行する。サーバ受信キュー負荷管理状態更新部３１はサーバ受信キュー状態報告電文を受け取るとサーバ受信キュー管理テーブル３２を更新する。サーバ受信キュー管理テーブル３２は図２６に示したサーバ受信キュー管理テーブル形式２６０１の形式をもつ。サーバ受信キュー管理テーブル３２はサーバグループ４０１内のサーバシステム２０１それぞれのサーバ受信キュー２０に格納されたメッセージ数と業務アプリケーション２１が「起動中」であるか「停止中」であるかを示すステータス各レコードの更新時刻を管理情報として保持する。なおサーバグループ内負荷管理装置３０１でのサーバ受信キュー管理テーブル３２の保持方法は規定しない。しかし、本テーブルの各サーバシステムのレコード情報は最新の管理情報が逐次更新されるのでデータベース管理システムを使用することが望ましい。
【００４１】
サーバ受信キュー負荷状態更新部３１はサーバ受信キュー状態報告電文よりサーバシステムＩＤフィールドとサーバ受信キューメッセージ数フィールドおよび業務アプリケーションステータスフィールドを参照し、サーバ受信キュー管理テーブル３２のサーバシステムＩＤが合致するレコードに対してサーバ受信キューメッセージ数フィールドと業務アプリケーションステータスフィールドに更新する。さらに同レコードの更新時刻フィールドは現在時刻で更新する。
【００４２】
また、サーバ受信キュー負荷管理状態更新部３１では、各サーバシステム２０１からサーバ受信キュー状態報告電文が定期的に送られているかを監視している。サーバグループ内負荷管理装置３０１であらかじめ定義されたサーバ受信キュー管理テーブル更新監視間隔毎にサーバ受信キュー管理テーブル３２の全レコードの更新時刻フィールドをチェックし、サーバ受信キュー管理テーブル更新監視間隔内に更新されていないレコードに該当するサーバシステム２０１は停止していると判断し、該当レコードの業務アプリケーションステータスフィールドを「停止中」に更新する。
【００４３】
クライアント１０１やサーバシステム２０１からのサーバ受信キュー管理テーブル３２への参照はサーバグループ内負荷管理装置３０１のサーバ受信キュー負荷状態応答部３０が応答する。サーバ受信キュー負荷状態応答部３０は図１７に示したフローチャート１１７０１に従って実行される。サーバ受信キュー負荷状態応答部３０ではクライアント１０１またはサーバシステム２０１から送られるサーバ負荷情報送信依頼電文を受け取るとサーバ受信キュー管理テーブル３２より全サーバシステム２０１のレコードを参照し、サーバ負荷情報応答電文を作成する。
【００４４】
サーバ負荷情報応答電文の電文種別フィールドには本電文がサーバ負荷情報応答電文であることを示すシステム共通で定めた識別子を格納し、先頭サーバシステムＩＤフィールドにはサーバ受信キュー管理テーブル３２の先頭レコードのシステムＩＤ、最終サーバシステムＩＤフィールドに最終レコードのシステムＩＤを格納する。そしてサーバシステムＩＤフィールド、サーバ受信キューメッセージ数フィールドおよび業務アプリケーションステータスフィールドにはサーバ受信キュー管理テーブルの先頭レコードから最終レコードまでレコード順にフィールドに対応して格納する。作成したサーバ負荷情報応答電文はサーバ負荷情報送信依頼電文の依頼元システムＩＤフィールドを参照し、依頼元システムに向けて送信する。
【００４５】
一方、サーバシステム２０１の受信キュー２０に格納された処理要求メッセージは業務アプリケーション２１によって監視される。業務アプリケーション２１は図１５に示したフローチャート１１５０１に従って実行する。業務アプリケーション２１は起動時に業務アプリケーションステータスを「起動中」に更新する。起動後はユーザからの停止要求があるまで常時、サーバ受信キュー２０を参照し、処理要求メッセージの到着を監視する。サーバ受信キュー２０に処理要求メッセージがあったとき業務アプリケーション２１はサーバ受信キュー２０から処理要求メッセージを取得する。
【００４６】
ただし、サーバ受信キュー内の処理要求メッセージは他サーバシステム２０１から転送されてくる場合があるため、サーバ受信キュー２０に格納された順序が必ずしも処理要求メッセージの生成時刻が古いものから順番になっているとは限らない。このため、メッセージの取得手順はメッセージ先入れ先出し方式ではなく処理要求メッセージのメッセージ生成時刻フィールドが最も古いものを優先して取得する。
【００４７】
業務アプリケーション２１は取得した処理要求メッセージの処理要求内容フィールドを参照し、業務データベース２２などを利用し、処理要求内容に応じたユーザアプリケーションを実行することで要求元のクライアント１０１への処理結果を得る。業務アプリケーション２１は次に図２０に示した処理結果メッセージ形式２００１に従う処理結果メッセージを作成する。処理結果メッセージのメッセージ種別フィールドには本メッセージが処理結果メッセージであることを示すシステム共通で定めた識別子を更新する。要求元クライアントＩＤフィールドには処理要求メッセージに格納されていた要求元クライアントＩＤを更新する。
【００４８】
さらに処理結果フィールドにはユーザアプリケーションによって得た処理結果を格納する。作成した処理結果メッセージはサーバ送信キュー２３に格納する。業務アプリケーション２１はユーザアプリケーションを実行する度に業務アプリケーションステータスを「起動中」に更新する。これはユーザアプリケーションがその処理内容によって、特異的に処理が遅延した場合を考慮しており、もし業務アプリケーション状態監視部２６が後述のアプリケーション実行監視処理により業務アプリケーションステータスを「停止中」に更新しても業務アプリケーション２１が処理を継続している場合には業務アプリケーションステータスを「起動中」に戻すことができるためである。
【００４９】
業務アプリケーション２１は停止時に業務アプリケーションステータスを「停止中」に変更する。
【００５０】
業務アプリケーション２１が変更する業務アプリケーションステータスは業務アプリケーション状態監視部２６が監視する。業務アプリケーション状態監視部２６は図１３のフローチャート１１３０１に従って実行する。業務アプリケーション状態監視部２６は業務アプリケーションステータスが「停止中」から「起動中」に状態が変わるとサーバ受信キュー状態管理部２５へサーバ受信キューの状態報告を指示する。業務アプリケーション状態監視部２６は業務アプリケーションステータスが「起動中」になると今度は「停止中」に変更されていないかを随時チェックする。また起動中の間はサーバ受信キュー２０に格納された処理要求メッセージが正常に処理されているか業務アプリケーション２１の状態監視処理をする。業務アプリケーション状態監視手順は以下通りである。
【００５１】
まず、サーバ受信キュー２０に処理要求メッセージが格納されているかどうかチェックし、処理要求メッセージが格納されている時、業務アプリケーション２１が次に処理する先頭の処理要求メッセージを参照し、そのメッセージＩＤを記憶する。その後、サーバシステム２０１内であらかじめ定義したアプリケーション実行監視間隔の時間待つ。ただし、この間も業務アプリケーションステータスが「停止中」に変更されないかは繰り返しチェックする。アプリケーション実行監視間隔が経過すると再度サーバ受信キューに処理要求メッセージをチェックする。もしサーバ受信キューにメッセージがない場合、または業務アプリケーション２１が次に処理する先頭の処理要求メッセージのメッセージＩＤが前記で記憶中したメッセージＩＤと異なる場合は処理要求メッセージが正常に動作していると判断し、監視処理を継続する。
【００５２】
しかし、前記のメッセージＩＤが記憶中のメッセージＩＤと異なる場合は業務アプリケーションが障害などの理由で業務アプリケーションステータスを変更せずにダウンしていると判断し、システム内の業務アプリケーションステータスを「停止中」に変更する。業務アプリケーション２１からのステータス変更または業務アプリケーション状態監視部２６によるステータス変更により、業務アプリケーションステータスが「停止中」になるとサーバ受信キュー状態管理部２５にサーバ受信キューの状態報告を指示する。さらにサーバ受信キュー２０に処理要求メッセージが存在するときこれらの処理要求メッセージを他のサーバシステム２０１へ転送する。
【００５３】
業務アプリケーション状態監視部２６の転送処理は図１４に示したフローチャート１１４０１に従って実行する。業務アプリケーション状態監視部２６はサーバ負荷情報送信依頼電文を作成し、サーバグループ内負荷管理装置３０１のサーバ受信キュー負荷情報応答部３０へを送信する。このときサーバ負荷情報送信依頼電文の要求元システムＩＤフィールドには自サーバシステムＩＤを格納する。サーバ受信キュー負荷情報応答部３０からサーバ負荷情報応答電文を受け取るとサーバ負荷情報応答電文の先頭サーバシステムＩＤから最終サーバシステムＩＤまで順にサーバ受信キューメッセージ数と業務アプリケーションステータスの情報をもとに図２８に示した転送先判定テーブル形式２８０１に従う転送先判定テーブル２７を作成する。
【００５４】
転送先判定テーブル２７はクライアント１０１で保持する送信先判定テーブル１４と同形式であり、サーバ負荷情報応答電文からの更新もクライアント１０１の送信先判定テーブル１４と同様の手順で行うことができる。
【００５５】
ただし、転送先判定テーブル２７は転送先として自サーバシステムが選択されることがないようにあらかじめ自サーバシステムのレコードは作成しないようにする。なお、転送先判定テーブル２７の保持方法は規定しない。しかし、転送先判定テーブル２７は処理要求メッセージ転送時の一時的な情報を管理するためのテーブルであるためメモリ上することが望ましい。転送先判定テーブル２７の更新が完了すると、ここで業務アプリケーション２１が再起動されているかチェックする。業務アプリケーションステータスが「起動中」に変更されているとき、つまり再起動された場合には転送の必要がないため転送処理は中止する。
【００５６】
業務アプリケーションステータスが「停止中」のときクライアントでの送信先サーバシステムの選択手順と同様にフローチャート１０５０１に従って業務アプリケーションが起動中で最もサーバ受信キューのメッセージ数が少ない転送先サーバシステムを選択する。転送先サーバシステムが選択できなかった場合はサーバ負荷情報送信依頼電文の送信から繰り返す。また転送先サーバシステムが選択できた場合はサーバ受信キューから処理要求メッセージを取得し、送信先サーバシステムＩＤフィールドに選択した転送先サーバシステムＩＤを更新し、サーバメッセージ送信部２９に処理要求メッセージを通知し、送信指示する。
【００５７】
サーバメッセージ送信部２９の戻り値が送信成功のとき、戻り値に付与されたサーバ受信キューメッセージ数と業務アプリケーションステータスを転送先判定テーブル２７の転送先サーバシステムＩＤのレコードに更新する。また処理要求メッセージの送信失敗が返却されると同レコードの業務アプリケーションステータスを「停止中」に変更する。次に再度自サーバシステム内の処理要求メッセージを参照し、メッセージが存在する場合は業務アプリケーションステータスチェック処理に戻り、自サーバ受信キューのメッセージがなくなるか、業務アプリケーションのステータスが「起動中」になるまでこれを繰り返す。
【００５８】
サーバ送信キュー２３に格納された処理結果メッセージはサーバ送信キュー監視部２４により監視される。サーバ送信キュー監視部２４は図１６のフローチャート１１６０１に従って実行される。サーバ送信キュー２３に処理結果メッセージが格納されるとサーバ送信キュー監視部２４がこれを取り出し、取り出した処理結果メッセージをサーバメッセージ送信部２９に通知する。
【００５９】
サーバメッセージ送信部２９はサーバ送信キュー監視部２９からの処理結果メッセージのクライアント１０１への送信と業務アプリケーション状態監視部２６からの処理要求メッセージの他サーバシステム２０１への転送を行う。サーバメッセージ送信部２９は図１０に示したフローチャート１１００１に従って実行される。
【００６０】
サーバメッセージ送信部２９は送信指示を受け付けると通知されたメッセージのメッセージ種別フィールドを参照する。メッセージ種別が処理結果メッセージの場合、まずメッセージ送信電文を作成する。電文種別フィールドにはメッセージ送信電文を示す識別子を更新する。依頼元システムＩＤフィールドは自サーバシステムＩＤを更新する。メッセージフィールドにはサーバ送信キュー監視部２９から受け取った処理結果メッセージを更新する。次に処理結果メッセージの要求元クライアントＩＤフィールドを参照し、要求元のクライアント１０１のメッセージ受信部にメッセージ送信電文を送信する。その後送信先のクライアント１０１からのメッセージ送信応答電文が返るのを待つ。
【００６１】
ここでもし、システムで定義した応答タイムアウト間隔内にメッセージ送信応答電文が返らないとき、サーバ送信キュー２４に処理要求メッセージを戻し、送信失敗を返却する。
【００６２】
送信先のクライアント１０１からメッセージ送信応答電文が返るとメッセージ送信応答電文の応答結果フィールドを参照し、応答結果が送信成功のとき、送信成功を返却する。応答結果が送信失敗の場合はサーバ送信キュー２３に処理要求メッセージを戻し、送信失敗を返却する。
【００６３】
メッセージ種別が処理要求メッセージの場合、まずメッセージ送信電文を作成する。電文種別フィールドにはメッセージ送信電文を示す識別子を更新する。依頼元システムＩＤフィールドは自サーバシステムＩＤを更新する。メッセージフィールドには業務アプリケーション状態監視部２６から受け取った処理要求メッセージを更新する。次に処理要求メッセージの送信先サーバシステムＩＤフィールドを参照し、転送先のサーバシステム２０１のメッセージ受信部２８にメッセージ送信電文を送信する。その後転送先のサーバシステム２０１からのメッセージ送信応答電文が返るのを待つ。
【００６４】
ここでもし、システムで定義した応答タイムアウト間隔内にメッセージ送信応答電文が返らないとき、転送先サーバシステム２０１は停止しているものと判断し、サーバ受信キュー２０に処理要求メッセージを戻し、送信失敗を返却する。
【００６５】
転送先のサーバシステム２０１からメッセージ送信応答電文が返るとメッセージ送信応答電文の応答結果フィールドを参照し、応答結果が送信成功のときメッセージ送信応答電文のサーバ受信キューメッセージ数フィールドと業務アプリケーションステータスフィールドの値を戻り値に付与し、送信成功を返却する。応答結果が送信失敗の場合はサーバ受信キュー２０に処理要求メッセージを戻し、送信失敗を返却する。
【００６６】
クライアント１０１ではサーバシステム２０１が送信するメッセージ送信電文をクライアントメッセージ受信部１９が受信する。クライアントメッセージ受信部１９は図７に示したフローチャート１０７０１に従って実行する。クライアントメッセージ受信部１９ではサーバシステム２０１からのメッセージ送信電文を受け取るとメッセージ送信電文のメッセージフィールドから処理結果メッセージを取得し、クライアント受信キュー１５に格納する。その後、メッセージ送信応答電文を作成し、電文種別フィールドにメッセージ送信電文の識別子を更新し、さらに応答結果フィールドには送信成功を更新する。そしてメッセージ送信電文の依頼元システムＩＤフィールドに格納されたサーバシステム２０１にメッセージ送信応答電文を送信する。
【００６７】
クライアント１０１のクライアント受信キュー１５はクライアント処理結果メッセージ応答部１６により監視される。クライアント処理結果メッセージ応答部１６は図８に示したフローチャート１０８０１に従って実行する。クライアント処理結果メッセージ応答部１６はクライアント受信キュー１５に処理結果メッセージが格納されると処理結果メッセージを取得し、処理結果メッセージの処理結果フィールドの内容をクライアント結果表示アプリケーション１７に通知する。
【００６８】
クライアント結果表示アプリケーション１７は図９に示したフローチャート１０９０１に従って実行する。クライアント結果表示アプリケーション１７では例えばグラフィカルユーザインタフェースなど任意のユーザアプリケーションを介して処理結果をユーザに通知する。
【００６９】
サーバグループ内のサーバシステム間での業務アプリケーションの負荷を均等化することでサーバグループ内のシステムリソースを効率的に利用することができ、業務アプリケーションの実行待ちが少ないサーバを選択できる。さらに業務アプリケーションが異常停止した場合でも他のサーバシステムに転送することでサーバ処理要求メッセージの滞留を防ぐことができる。
【００７０】
【発明の効果】
本発明によれば、サーバシステム間の負荷のアンバランスの改善が可能となる
【図面の簡単な説明】
【図１】本システムの一実施例の概略構成図である。
【図２】実施例のクライアント処理要求アプリケーションの処理を示すフローチャートである。
【図３】実施例の実施例のクライアント処理要求メッセージ生成部の処理を示すフローチャートである。
【図４】実施例の実施例のクライアントメッセージ送信先判定部
の処理を示すフローチャートである。
【図５】実施例の実施例のクライアントメッセージ送信先判定部の送信先サーバシステム選択処理と業務アプリケーション状態監視部の転送先サーバシステム選択処理を示すフローチャートである。
【図６】実施例の実施例のクライアントメッセージ送信部の処理を示すフローチャートである。
【図７】実施例の実施例のクライアントメッセージ受信部の処理を示すフローチャートである。
【図８】実施例の実施例のクライアント処理結果メッセージ応答部の処理を示すフローチャートである。
【図９】実施例の実施例のクライアント結果表示アプリケーションの処理を示すフローチャートである。
【図１０】実施例の実施例のサーバメッセージ受信部の処理を示すフローチャートである。
【図１１】実施例の実施例のサーバメッセージ受信部の処理を示すフローチャートである。
【図１２】実施例の実施例のサーバ受信キュー状態管理部の処理を示すフローチャートである。
【図１３】実施例の実施例の業務アプリケーション状態監視部の監視処理を示すフローチャートである。
【図１４】実施例の実施例の業務アプリケーション状態監視部の転送処理を示すフローチャートである。
【図１５】実施例の実施例の業務アプリケーションの処理を示すフローチャートである。
【図１６】実施例の実施例のサーバ送信キュー監視部の処理を示すフローチャートである。
【図１７】実施例の実施例のサーバ受信キュー負荷状態応答部の処理を示すフローチャートである。
【図１８】実施例の実施例のサーバ受信キュー負荷状態更新部の処理を示すフローチャートである。
【図１９】実施例の処理要求メッセージの形式である。
【図２０】実施例の処理結果メッセージの形式である。
【図２１】実施例のサーバ受信キュー状態報告電文の形式である。
【図２２】実施例のサーバ負荷情報送信依頼電文の形式である。
【図２３】実施例のサーバ負荷情報応答電文の形式である。
【図２４】実施例のメッセージ送信電文の形式である。
【図２５】実施例のメッセージ送信応答電文の形式である。
【図２６】実施例のサーバ受信キュー管理テーブルの形式である。
【図２７】実施例の送信先サーバ判定テーブルの形式である。
【図２８】実施例の転送先サーバ判定テーブルの形式である。
【符号の説明】
１０１ クライアント
２０１ サーバシステム
３０１ サーバグループ内負荷管理装置
４０１ サーバグループ
１０ クライアント処理要求アプリケーション
１１ クライアント処理要求メッセージ生成部
１２ クライアント受信キュー
１３ クライアントメッセージ送信先判定部
１４ 送信先サーバ判定テーブル
１５ クライアント受信キュー
１６ クライアント処理結果メッセージ応答部
１７ クライアント結果表示アプリケーション
１８ クライアントメッセージ送信部
１９ クライアントメッセージ受信部
２０ サーバ受信キュー
２１ 業務アプリケーション
２２ 業務データベース
２３ サーバ送信キュー
２５ サーバ送信キュー監視部
２５ サーバ受信キュー状態管理部
２６ 業務アプリケーション状態監視部
２７ 転送先サーバ判定テーブル
２８ サーバメッセージ受信部
２９ サーバメッセージ送信部
３０ サーバ受信キュー負荷状態応答部
３１ 業務アプリケーション負荷状態更新部
３２ サーバ受信キュー管理テーブル[0001]
BACKGROUND OF THE INVENTION
The present invention relates to a message communication technique between programs.
[0002]
[Prior art]
The form of information processing used to be centralized processing using only mainframes and terminals, but at present, the client-server system is becoming mainstream, and the foundation is a distributed processing system. In order to build a flexible and extensible system as a communication method in this distributed processing method, examples of system construction using asynchronous message communication that asynchronously communicates communication between client and server systems via message queues are rapidly It is widespread. In asynchronous message communication, the client application can release the request processing when the processing request message to the server system is stored in the transmission queue, and the client application can refer to the processing result message returned from the server system by retrieving it from the queue. .
[0003]
In other words, asynchronous message communication has a feature that transmission of a processing request message to the server system and reception of a processing result message from the server can be executed in the background away from the client application. Even when there are a plurality of server systems having business applications that can execute the processing request message, the client application does not need to detect which server system the processing request message is transmitted to be executed. However, it is desirable to select a server system with less stagnation due to waiting for execution of business applications as a transmission destination.
[0004]
As a conventional method for selecting a destination server system for processing request messages, a server system that can be sent based on availability data notified to a client from the server system as disclosed in Patent Document 1 can be selected and selected. When there are a plurality of server systems, the problem is solved by an algorithm based on an arbitrary load balancing logic such as a round robin method.
[0005]
[Patent Document 1]
JP-A-11-328132
[0006]
[Problems to be solved by the invention]
In the above prior art, the transmission destination is determined based on the receivability data that the client receives from the server system. However, when there are multiple server systems that can be received, it depends on the load balancing logic in the client. The For example, when a client adopts the round robin method, even when a specific server system already has a large number of processing request messages due to delays in execution of business applications, the client selects that server system as a destination. Since the processing request message is transmitted, the processing request messages between the server systems cannot be equalized, and there are many processing request messages in a specific server system. There was a problem that the throughput of the entire system might be reduced, such as waiting for arrival.
[0007]
It is an object of the present invention to improve load imbalance between server systems and more efficiently use server system resources.
[0008]
[Means for Solving the Problems]
In order to achieve the above object, the following method is used. A processing request message for a business application in a server system issued by a client transmission request application refers to a server system group having the same business application by referring to the destination determination table when the processing request message is sent to the server system. Select a destination server system for processing request messages from the group. The message communication here may be communication between a terminal and a computer or a computer, communication between programs or objects, or communication between programs and objects.
[0009]
The destination determination table held by the client is a table received by the load management device in the server group, which will be described later, and the number of messages stored in the reception queues in all server systems in the server group and the respective “active” or Holds the execution status of business applications that are "stopped".
[0010]
As a determination criterion of the destination server system in the client, a server system in which the business application having the smallest number of messages in the record of the destination determination table is “active” is selected. Here, when there are a plurality of server systems satisfying the above conditions, any one of them may be selected. The client sends a processing request message to the selected server system. If the transmission is successful, the latest number of messages in the reception queue received from the server system at the time of transmission and the execution status of the business application are updated to the record of the transmission destination server system in the transmission destination determination table.
[0011]
If the processing request message fails to be sent to the server system, it is determined that a failure has occurred in the server system, and the execution status of the business application of the corresponding server system in the destination determination table is displayed. By changing to “stopped”, transmission of the processing request message to the server system is suppressed. The destination determination table that the client refers to when sending the processing request message is not used when the destination determination table updated by the load management device in the server group with an expiration date has passed an interval defined by the client, The latest data is acquired again from the load management device in the server group.
[0012]
Update data notified by each server system on the server group load management device periodically and whenever the status of a business application in the server system changes from "Starting" to "Stopping" or "Stopping" to "Starting" Based on the above, it manages the number of messages stored in the reception queue of all server systems in the server group and the execution status of business applications. The load management device in the server group determines that a failure has occurred in the server system for a server system that has not sent update data within a certain interval defined by the system, and the corresponding server system in the destination determination table By changing the execution status of the current business application to “Stopped”, transmission of the processing request message to the server system is suppressed.
[0013]
In the server system, if the processing request message in the receive queue is not fetched at a fixed interval defined in the system, it is determined that the business application has stopped abnormally, and the execution status of the business application in the server system is set to “Stopped”. ”To the server group load monitoring apparatus, and the transmission of the processing request message is suppressed. Furthermore, the server system obtains the status of the reception queue management table from the load monitoring device in the server group, selects the transfer destination server system in the same manner as the client server system selection procedure, and sends a message to the transfer destination server. Send.
[0014]
The execution status of the business application in the server system is set to “Starting” when the business application starts or is triggered, and is set to “Stopped” when the business application ends. In other words, the transmission of processing request messages from the client and the transfer processing of the server system that are suppressed by the monitoring by the update data notification in the load management device in the server group and the monitoring of the processing request messages in the reception queue in the server system Cancel when starting or executing a business application.
[0015]
DETAILED DESCRIPTION OF THE INVENTION
Embodiments of the present invention will be described below with reference to the drawings. FIG. 1 is a schematic configuration diagram of an embodiment of the present invention.
In FIG. 1, reference numeral 101 denotes a client. Reference numeral 201 denotes a server system belonging to the server group 401. Reference numeral 301 denotes an in-server load management apparatus installed in the server group 401.
[0016]
The client 101 includes a client processing request application 10 that makes a processing request to the business application 21 of the server system in the server group 401, a processing request message generator 11 that generates a processing request message, a client transmission queue 12 that stores the processing request message, and a server group. A client message transmission destination determination unit 13 that selects a transmission destination server system 201 from 401 and a transmission destination server determination table 14 that is determination information for selecting a transmission destination server system. The application here may be a program, a business program, or an object.
[0017]
Furthermore, the client 101 stores the processing result message sent from the server system 201, the client reception queue 15 for storing the processing result message, the client processing result message response unit 16 for retrieving the processing result message from the client reception queue 15, and the processing result to the user of the client 101. A client result display application 17 for displaying the results. Further, a client message transmitting unit 18 that transmits a processing request message from the client 101 to the server system 201 and a client message receiving unit 19 that receives a processing result message from the server system 201 and stores it in the client reception queue 15.
[0018]
The server system 201 accesses the server reception queue 20 that can store the processing request message received from the client 101 and the business database 22 according to the processing request message, and stores the processing result message in the server transmission queue 23. The processing request message is received from the client 101 and the server transmission queue monitoring unit 24 for monitoring the storage of the processing request message in the server transmission queue 23 and the server reception queue 20 for accumulating the business application 21 and the processing result message. A server message receiving unit 28 for storing and a server message transmitting unit 29 for transmitting a processing result message to the client 101 are included.
[0019]
Further, the server system 201 monitors the start and stop states of the server reception queue state management unit 25 and the business application 21 that manage the number of stored processing request messages in the server reception queue 20. A business application status monitoring unit 26 that transfers a message to another server system 201 and a transfer destination server determination table 27 that is determination information for selecting a server system that is the transfer destination are included.
[0020]
The intra-server group load management apparatus 301 receives the information received from the server system 201 and the reception queue management table 32 for managing the number of messages in the server reception queue 20 of all the server systems 201 in the server group 401 and the state of the business application. A reception queue load state update unit 31 that updates the queue management table 32 and a reception queue load state response unit 30 that responds to reference to the server reception queue management table 32 from the client 101 or the server system 201 are provided.
[0021]
It is assumed that a client ID or server system ID that is unique for the entire system is assigned to each of the client 101 and the server system 201 in the system.
[0022]
In the client 101, the client processing request application 10 executes in accordance with the flowchart 10201 shown in FIG. The client processing request application 10 receives an arbitrary processing request such as a business database update or a search request in the server system via an arbitrary user application such as a graphical user interface, and notifies the processing request to the client processing request message generator.
[0023]
The client processing request message generating unit 11 executes the processing according to the flowchart 10301 shown in FIG. The client process request message generation unit 11 creates a process request message according to the process request message format 1901 shown in FIG. In the message type field of the processing request message, an identifier common to the system indicating that this message is a processing request message is updated. An arbitrary message ID that is unique in the entire system is updated in the message ID field. The method for making the message ID unique throughout the system is not specified. For example, “client ID + message generation time + generation serial number within the same time” can be considered. The current time is updated in the message generation time field. The own client ID is updated in the request source client ID field. The processing request received from the client processing request application 11 is updated in the processing request content field. Next, the client process request message generator 11 stores the created process request message in the client transmission queue 12.
[0024]
The client transmission queue 12 is monitored by the client message transmission destination determination unit 13. The client message transmission destination determination unit 13 executes in accordance with the flowchart 10401 shown in FIG. When a processing request message arrives at the client transmission queue 12, the client message transmission destination determination unit 13 first refers to the data update time of the transmission destination server determination table 14 managed in the client 101. When the current time has passed the update interval defined in advance in the client 101 from the data update time, the transmission destination determination table 14 is updated to the latest information by the following procedure. The client message transmission destination determination unit 13 creates a server load information transmission request message according to the server load information transmission request message format 2201 shown in FIG.
[0025]
In the message type field of the server load information transmission request message, an identifier defined in common in the system indicating that this message is a server load information transmission request message is updated. The own client ID is updated in the request source system ID field.
[0026]
The created server load information transmission request message is transmitted to the server reception queue load information response unit 30 of the intra-server group load management apparatus 301.
The server reception queue load information response unit 30 returns a server load information response message in accordance with the server load information response message format 2301 shown in FIG.
[0027]
In the server load information response message, the number of messages in the server reception queue for each server system belonging to the server group 401 and the status information of the business application are embedded. When the client message transmission destination determination unit 13 receives this server load information response message, the transmission destination shown in FIG. 27 in order from the system ID in the first server system ID field to the system ID in the last server system ID field of the server load information response message. The contents of the server reception queue message number field and the business application status field of the server load information response message are updated in the transmission destination determination table 14 having the determination table format 2701 format. Note that the method of holding the transmission destination determination table 14 in the client 101 is not defined. However, in order to keep the system lightness of the client 101, it is desirable to hold it on the memory. When the update of the transmission destination determination table 14 is completed, the data update time of the transmission destination server determination table 14 managed uniquely in the system of the client 101 is updated to the current time.
[0028]
Next, the client message transmission destination determination unit 13 uses the transmission destination server determination table 14 to select a transmission destination server system for the processing request message. The procedure for selecting the processing destination message transmission destination server system will be described later.
[0029]
The client message transmission destination determination unit 13 waits until the update interval elapses from the data update time of the transmission destination server determination table 14 when the transmission destination server system cannot be selected by the selection processing of the transmission destination server system of the processing request message. The process returns to the server load information transmission request message creation process again. When the transmission destination server system can be selected, the processing request message is acquired from the client transmission queue 12, and the transmission destination server system selected in the transmission destination server system selection process is selected in the transmission destination server system ID field of the acquired processing request message. Update the server system ID. Then, the client message transmitting unit 18 is notified of the processing request message and instructed to transmit. When the transmission processing of the processing request message by the client message transmission unit 18 is completed, the return value from the client message transmission unit 18 is determined, and when the transmission success is returned, the number of messages attached to the return value and the business application status are transmitted. Update the record of the destination server system in the destination server determination table 14.
[0030]
When the transmission failure is returned from the client message transmission unit 18, the business application status field in the transmission destination server determination table is changed to “stopped” so that the corresponding server system is not selected as the transmission destination server system. Thereafter, the client message destination determination unit 13 returns to the message monitoring process of the client reception queue 12 and repeats the series of processes.
The selection processing of the destination server system of the client message destination determination unit 13 is executed according to the flowchart 10501 shown in FIG. First, all records in the destination server determination table 14 are referred to, and a server system ID whose business application status field is “Active” is extracted. If there is no “active” server system 201, it is determined that there is no selectable server system 201, and “no selectable server system” is returned.
[0031]
When there is only one active server system 201, the server system is selected as the destination server system, and the server system ID of the server system is returned. When there are a plurality of active server systems 201, the server system 201 having the smallest number of server reception queue messages is selected, and the server system ID of the server system 201 is returned. Further, even if the number of server reception queue messages is smaller than the others, a certain degree of effect can be expected.
[0032]
If there are a plurality of server systems 201 having the same number of server reception queue messages, any server system 201 may be selected. For example, one server system 201 can be specified by preferentially selecting the smaller system ID.
[0033]
The client message transmission unit 18 transmits a processing request message to the server system 201 selected by the client message transmission destination determination unit 13. The client message transmission unit 18 is executed according to the flowchart 10601 shown in FIG.
[0034]
Upon receipt of the transmission instruction, the client message transmission unit 18 creates a message transmission message in accordance with the message transmission message format 2401 shown in FIG. In the message type field of the message transmission message, an identifier defined in common in the system indicating that the message is a message transmission message is updated. The client ID is stored in the request source system ID field. In the message field, the processing request message received from the client message destination determination unit 13 is updated. Then, referring to the transmission destination server system ID field of the processing request message, a message transmission message is transmitted to the server message reception unit 28 of the server system 201.
[0035]
Thereafter, it waits for a message transmission response message conforming to the message transmission response message format 2501 shown in FIG. If the message transmission response message is not returned within the response timeout interval defined by the system, it is determined that the destination server system is stopped, the processing request message is returned to the client transmission queue, and the transmission failure is returned. To do. When a message transmission response message is returned from the destination server system 201, the response result field of the message transmission response message is referred to. When the response result is successful, the values of the server reception queue message number field and the business application status field are set as return values. Grant and return successful transmission. If the response result is a transmission failure, a processing request message is returned to the client transmission queue 15 and a transmission failure is returned.
[0036]
The server message receiver 28 receives the message transmission message transmitted by the client message transmitter 18. The server message receiving unit 28 executes in accordance with the flowchart 11101 shown in FIG. When the server message receiving unit 28 receives the message transmission message, it first refers to the business application status held in the server system. The business application status is information indicating whether the business application in the server system is “starting” or “stopping”, and is common information that can be referred to and updated between functions in the server system 201 managed in, for example, the shared memory area. It is.
[0037]
When the business application status is “active”, the processing request message is extracted from the message transmission message and stored in the server reception queue 20. Then, the current number of messages in the server reception queue 20 is referred to. Then, a message transmission response message is created. In the message type field of the message transmission response message, an identifier defined in common in the system indicating that this message is a message transmission response message is updated. In the server reception queue message number field, the current number of messages in the referenced server reception queue 20 is updated. The current business application status is updated in the business application field. The response result field is updated with successful transmission. Then, the created message transmission response message is transmitted to the request source system stored in the request source system ID field of the message transmission message. When the business application status is “stopped”, a message transmission response message is created in the same manner, but after updating the message type field, the transmission failure is updated in the response result field. The server reception queue message count field and the business application status field do not need to be updated. The created message transmission response message is transmitted to the request source system in the same procedure.
[0038]
The reception queue 20 of the server system 201 is monitored by the server reception queue state management unit 25. The server reception queue state management unit 25 executes in accordance with the flowchart 11201 shown in FIG. The server reception queue status management unit 25 receives the server reception queue status report message format 2101 shown in FIG. 21 at every server reception queue monitoring interval defined in the server system or according to a reception queue status report instruction from the business application status monitoring unit. Create a server reception queue status report message conforming to. In the message type field of the server reception queue status report message, an identifier defined in common in the system indicating that this message is a server reception queue status report message is updated. The own server system ID is updated in the server system ID field. In the server reception queue message number field, the current processing request message number is acquired from the server reception queue 20 and updated.
[0039]
Further, the business application status managed in the server system is updated in the business application status field. The created server reception queue status report message is notified to the server reception queue load status update unit 31 of the intra-server group load management device 301.
[0040]
The server reception queue load state update unit 31 executes in accordance with the flowchart 11801 of FIG. When the server reception queue load management state update unit 31 receives the server reception queue state report message, it updates the server reception queue management table 32. The server reception queue management table 32 has a server reception queue management table format 2601 shown in FIG. The server reception queue management table 32 shows the number of messages stored in the server reception queue 20 of each server system 201 in the server group 401 and statuses indicating whether the business application 21 is “starting” or “stopping”. Holds record update time as management information. Note that the method for holding the server reception queue management table 32 in the server group load management apparatus 301 is not defined. However, it is desirable to use a database management system because the latest management information is sequentially updated in the record information of each server system in this table.
[0041]
The server reception queue load state update unit 31 refers to the server system ID field, the server reception queue message number field, and the business application status field from the server reception queue state report message, and records that match the server system ID in the server reception queue management table 32 Update to the server reception queue message count field and business application status field. Furthermore, the update time field of the record is updated with the current time.
[0042]
In addition, the server reception queue load management state updating unit 31 monitors whether or not a server reception queue state report message is periodically sent from each server system 201. The update time field of all records in the server reception queue management table 32 is checked at every server reception queue management table update monitoring interval defined in advance in the server group load management device 301, and updated within the server reception queue management table update monitoring interval. It is determined that the server system 201 corresponding to the record that is not yet stopped, and the business application status field of the record is updated to “stopped”.
[0043]
The reference to the server reception queue management table 32 from the client 101 or the server system 201 is responded by the server reception queue load state response unit 30 of the intra-server group load management apparatus 301. The server reception queue load state response unit 30 is executed according to the flowchart 11701 shown in FIG. When the server reception queue load state response unit 30 receives a server load information transmission request message sent from the client 101 or the server system 201, the server reception queue management table 32 refers to the records of all the server systems 201 and sends a server load information response message. create.
[0044]
In the message type field of the server load information response message, an identifier defined in common in the system indicating that this message is a server load information response message is stored. In the first server system ID field, the first record of the server reception queue management table 32 is stored. The system ID of the final record is stored in the system ID and final server system ID fields. In the server system ID field, the server reception queue message number field, and the business application status field, the first record to the last record in the server reception queue management table are stored in the order of records. The created server load information response message refers to the request source system ID field of the server load information transmission request message and transmits it to the request source system.
[0045]
On the other hand, the processing request message stored in the reception queue 20 of the server system 201 is monitored by the business application 21. The business application 21 is executed according to the flowchart 11501 shown in FIG. The business application 21 updates the business application status to “active” at the time of startup. After startup, the server reception queue 20 is always referred to until a stop request is received from the user, and the arrival of the processing request message is monitored. When there is a processing request message in the server reception queue 20, the business application 21 acquires the processing request message from the server reception queue 20.
[0046]
However, since the processing request messages in the server reception queue may be transferred from the other server system 201, the order stored in the server reception queue 20 is not necessarily from the generation time of the processing request message. Not necessarily. For this reason, the message acquisition procedure preferentially acquires the oldest message generation time field of the processing request message instead of the message first-in first-out method.
[0047]
The business application 21 refers to the processing request content field of the acquired processing request message, uses the business database 22 or the like, and executes a user application corresponding to the processing request content to obtain a processing result for the requesting client 101. . Next, the business application 21 creates a processing result message in accordance with the processing result message format 2001 shown in FIG. In the message type field of the processing result message, an identifier defined in common in the system indicating that this message is a processing result message is updated. The request source client ID field is updated with the request source client ID stored in the processing request message.
[0048]
Further, the processing result obtained by the user application is stored in the processing result field. The created processing result message is stored in the server transmission queue 23. The business application 21 updates the business application status to “Active” every time the user application is executed. This takes into account the case where the user application specifically delays processing depending on the processing contents, and if the business application status monitoring unit 26 updates the business application status to “stopped” by the application execution monitoring processing described later. However, if the business application 21 continues processing, the business application status can be returned to “Active”.
[0049]
The business application 21 changes the business application status to “stopped” when stopped.
[0050]
The business application status monitoring unit 26 monitors the business application status changed by the business application 21. The business application state monitoring unit 26 executes according to the flowchart 11301 of FIG. The business application status monitoring unit 26 instructs the server reception queue status management unit 25 to report the status of the server reception queue when the status of the business application status changes from “stopped” to “active”. When the business application status becomes “active”, the business application status monitoring unit 26 checks from time to time whether the status is changed to “stopped”. During the activation, the status monitoring process of the business application 21 is performed to check whether the processing request message stored in the server reception queue 20 is normally processed. The business application status monitoring procedure is as follows.
[0051]
First, it is checked whether or not a processing request message is stored in the server reception queue 20, and when the processing request message is stored, the business processing application 21 refers to the first processing request message to be processed next, and determines the message ID. Remember. Thereafter, the server system 201 waits for an application execution monitoring interval defined in advance in the server system 201. However, during this time, it is repeatedly checked whether the business application status is changed to “stopped”. When the application execution monitoring interval elapses, the processing request message is checked again in the server reception queue. If there is no message in the server reception queue, or if the message ID of the first processing request message to be processed next by the business application 21 is different from the message ID stored above, the processing request message is operating normally. Judge and continue the monitoring process.
[0052]
However, if the message ID is different from the stored message ID, it is determined that the business application is down without changing the business application status due to a failure or the like, and the business application status in the system is changed to “stopped”. Change to When the business application status becomes “stopped” due to the status change from the business application 21 or the status change by the business application status monitoring unit 26, the server reception queue status management unit 25 is instructed to report the status of the server reception queue. Further, when there are processing request messages in the server reception queue 20, these processing request messages are transferred to another server system 201.
[0053]
The transfer process of the business application state monitoring unit 26 is executed according to the flowchart 11401 shown in FIG. The business application state monitoring unit 26 creates a server load information transmission request message and transmits it to the server reception queue load information response unit 30 of the intra-server group load management device 301. At this time, the own server system ID is stored in the request source system ID field of the server load information transmission request message. When a server load information response message is received from the server reception queue load information response unit 30, the server load information response message is sequentially displayed from the first server system ID to the last server system ID in the server reception queue message number and business application status information. A transfer destination determination table 27 according to the transfer destination determination table format 2801 shown in FIG.
[0054]
The transfer destination determination table 27 has the same format as the transmission destination determination table 14 held by the client 101, and the update from the server load information response message can be performed in the same procedure as the transmission destination determination table 14 of the client 101.
[0055]
However, the transfer destination determination table 27 does not create a record of the own server system in advance so that the own server system is not selected as the transfer destination. Note that the method for holding the transfer destination determination table 27 is not defined. However, since the transfer destination determination table 27 is a table for managing temporary information at the time of processing request message transfer, it is preferably stored in a memory. When the update of the transfer destination determination table 27 is completed, it is checked here whether the business application 21 has been restarted. When the business application status is changed to “Starting”, that is, when it is restarted, the transfer processing is stopped because there is no need for transfer.
[0056]
When the business application status is “stopped”, the transfer destination server system having the smallest number of messages in the server reception queue is selected according to the flowchart 10501 in the same manner as the selection procedure of the transmission destination server system at the client. When the transfer destination server system cannot be selected, the process is repeated from the transmission of the server load information transmission request message. If the transfer destination server system can be selected, the processing request message is acquired from the server reception queue, the selected transfer destination server system ID is updated in the transmission destination server system ID field, and the processing request message is sent to the server message transmission unit 29. Notify and send instructions.
[0057]
When the return value of the server message sending unit 29 is successful, the number of server reception queue messages and the business application status assigned to the return value are updated to the record of the transfer destination server system ID in the transfer destination determination table 27. If the processing request message transmission failure is returned, the business application status of the record is changed to “Stopped”. Next, refer to the processing request message in the local server system again, and if there is a message, return to the business application status check process and the message in the local server reception queue disappears, or the status of the business application becomes “Starting” Repeat this until.
[0058]
The processing result message stored in the server transmission queue 23 is monitored by the server transmission queue monitoring unit 24. The server transmission queue monitoring unit 24 is executed according to the flowchart 11601 in FIG. When the processing result message is stored in the server transmission queue 23, the server transmission queue monitoring unit 24 takes it out and notifies the server message transmission unit 29 of the extracted processing result message.
[0059]
The server message transmission unit 29 transmits the processing result message from the server transmission queue monitoring unit 29 to the client 101 and transfers the processing request message from the business application state monitoring unit 26 to the server system 201. The server message transmission unit 29 is executed according to the flowchart 11001 shown in FIG.
[0060]
When the server message transmission unit 29 accepts the transmission instruction, the server message transmission unit 29 refers to the message type field of the notified message. If the message type is a processing result message, a message transmission message is first created. The identifier indicating the message transmission message is updated in the message type field. The request source system ID field updates its own server system ID. In the message field, the processing result message received from the server transmission queue monitoring unit 29 is updated. Next, referring to the request source client ID field of the processing result message, a message transmission message is transmitted to the message reception unit of the request source client 101. After that, it waits for a message transmission response message from the destination client 101 to return.
[0061]
Here, when the message transmission response message is not returned within the response timeout interval defined by the system, the processing request message is returned to the server transmission queue 24 and the transmission failure is returned.
[0062]
When a message transmission response message is returned from the destination client 101, the response result field of the message transmission response message is referred to. When the response result is successful, the transmission success is returned. If the response result is a transmission failure, a processing request message is returned to the server transmission queue 23, and the transmission failure is returned.
[0063]
If the message type is a processing request message, a message transmission message is first created. The identifier indicating the message transmission message is updated in the message type field. The request source system ID field updates its own server system ID. In the message field, the processing request message received from the business application state monitoring unit 26 is updated. Next, referring to the transmission destination server system ID field of the processing request message, a message transmission message is transmitted to the message receiving unit 28 of the transfer destination server system 201. Thereafter, it waits for a message transmission response message from the destination server system 201 to be returned.
[0064]
Here, if the message transmission response message is not returned within the response timeout interval defined by the system, it is determined that the transfer destination server system 201 is stopped, the processing request message is returned to the server reception queue 20, and the transmission fails. To return.
[0065]
When a message transmission response message is returned from the transfer destination server system 201, the response result field of the message transmission response message is referred to. When the response result is successful, the server reception queue message number field and the business application status field of the message transmission response message Assign a value to the return value and return successful transmission. If the response result is a transmission failure, a processing request message is returned to the server reception queue 20 and a transmission failure is returned.
[0066]
In the client 101, the client message receiving unit 19 receives a message transmission message transmitted from the server system 201. The client message receiving unit 19 executes in accordance with the flowchart 10701 shown in FIG. When the client message reception unit 19 receives a message transmission message from the server system 201, the client message reception unit 19 acquires a processing result message from the message field of the message transmission message and stores it in the client reception queue 15. Thereafter, a message transmission response message is created, the identifier of the message transmission message is updated in the message type field, and the transmission success is updated in the response result field. Then, a message transmission response message is transmitted to the server system 201 stored in the request source system ID field of the message transmission message.
[0067]
The client reception queue 15 of the client 101 is monitored by the client processing result message response unit 16. The client processing result message response unit 16 executes in accordance with the flowchart 10801 shown in FIG. When the processing result message is stored in the client reception queue 15, the client processing result message response unit 16 acquires the processing result message and notifies the client result display application 17 of the contents of the processing result field of the processing result message.
[0068]
The client result display application 17 is executed according to the flowchart 10901 shown in FIG. The client result display application 17 notifies the user of the processing result via an arbitrary user application such as a graphical user interface.
[0069]
By equalizing the business application load among the server systems in the server group, the system resources in the server group can be used efficiently, and a server with less business application execution waiting can be selected. Furthermore, even if a business application is abnormally stopped, the server processing request message can be prevented from staying by transferring it to another server system.
[0070]
【The invention's effect】
According to the present invention, it is possible to improve load imbalance between server systems.
[Brief description of the drawings]
FIG. 1 is a schematic configuration diagram of an embodiment of the present system.
FIG. 2 is a flowchart illustrating processing of a client processing request application according to the embodiment.
FIG. 3 is a flowchart illustrating processing of a client processing request message generation unit according to the embodiment.
FIG. 4 illustrates a client message transmission destination determination unit according to the embodiment.
It is a flowchart which shows the process of.
FIG. 5 is a flowchart illustrating a destination server system selection process of a client message destination determination unit and a transfer destination server system selection process of a business application status monitoring unit according to an embodiment of the present invention.
FIG. 6 is a flowchart illustrating processing of a client message transmission unit according to an embodiment of the present invention.
FIG. 7 is a flowchart illustrating processing of a client message receiving unit according to an embodiment of the present invention.
FIG. 8 is a flowchart illustrating processing of a client processing result message response unit according to the embodiment.
FIG. 9 is a flowchart illustrating processing of a client result display application according to the embodiment.
FIG. 10 is a flowchart illustrating processing of a server message receiving unit according to the embodiment of the present invention.
FIG. 11 is a flowchart illustrating processing of a server message receiving unit according to an embodiment of the present invention.
FIG. 12 is a flowchart illustrating processing of a server reception queue state management unit according to the embodiment of the present invention.
FIG. 13 is a flowchart illustrating monitoring processing of a business application state monitoring unit according to the embodiment.
FIG. 14 is a flowchart illustrating a transfer process of the business application state monitoring unit according to the embodiment.
FIG. 15 is a flowchart illustrating processing of the business application according to the embodiment.
FIG. 16 is a flowchart illustrating processing of a server transmission queue monitoring unit according to an embodiment of the present invention.
FIG. 17 is a flowchart illustrating processing of a server reception queue load state response unit according to the embodiment of the present invention.
FIG. 18 is a flowchart illustrating processing of a server reception queue load state update unit according to an embodiment of the present invention.
FIG. 19 is a format of a processing request message according to the embodiment.
FIG. 20 is a format of a processing result message according to the embodiment.
FIG. 21 is a format of a server reception queue status report message according to the embodiment.
FIG. 22 is a format of a server load information transmission request message according to the embodiment.
FIG. 23 is a format of a server load information response message according to the embodiment.
FIG. 24 is a format of a message transmission message according to the embodiment.
FIG. 25 is a format of a message transmission response message according to the embodiment.
FIG. 26 is a format of a server reception queue management table according to the embodiment.
FIG. 27 is a format of a transmission destination server determination table of the embodiment.
FIG. 28 is a format of a transfer destination server determination table of the embodiment.
[Explanation of symbols]
101 clients
201 server system
301 Server Group Load Management Device
401 Server group
10 Client processing request application
11 Client processing request message generator
12 Client receive queue
13 Client message destination determination unit
14 Destination server determination table
15 Client receive queue
16 Client processing result message response part
17 Client result display application
18 Client message transmitter
19 Client message receiver
20 Server receive queue
21 Business applications
22 Business database
23 Server transmission queue
25 Server transmission queue monitoring unit
25 Server reception queue status management section
26 Business Application Status Monitor
27 Transfer destination server determination table
28 Server message receiver
29 Server message transmitter
30 Server reception queue load status response section
31 Business application load status update section
32 Server reception queue management table