JP2005025481A - メッセージ通信方法およびその実施計算機システム - Google Patents
メッセージ通信方法およびその実施計算機システム Download PDFInfo
- Publication number
- JP2005025481A JP2005025481A JP2003189952A JP2003189952A JP2005025481A JP 2005025481 A JP2005025481 A JP 2005025481A JP 2003189952 A JP2003189952 A JP 2003189952A JP 2003189952 A JP2003189952 A JP 2003189952A JP 2005025481 A JP2005025481 A JP 2005025481A
- Authority
- JP
- Japan
- Prior art keywords
- server
- message
- client
- processing request
- transmission
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Images
Abstract
【課題】非同期メッセージ通信使用したシステムでクライアント１０１が発行する処理要求メッセージが送信先のサーバシステム２０１で業務アプリケーション２１に対しての実行待ちや業務アプリケーション２１の障害により応答遅延することを抑制する通信方法を提供する。
【解決手段】クライアントが発行する処理要求メッセージの送信先はサーバシステムの業務アプリケーションが起動中の状態であり、なおかつサーバ受信キューに格納されているメッセージ数が最も少ないサーバシステムを選択する。サーバシステムではサーバ受信キューの処理要求メッセージ取り出しを監視し、一定時間以上取り出しされないときは他のサーバシステムへメッセージを転送する。
【選択図】 図１
【解決手段】クライアントが発行する処理要求メッセージの送信先はサーバシステムの業務アプリケーションが起動中の状態であり、なおかつサーバ受信キューに格納されているメッセージ数が最も少ないサーバシステムを選択する。サーバシステムではサーバ受信キューの処理要求メッセージ取り出しを監視し、一定時間以上取り出しされないときは他のサーバシステムへメッセージを転送する。
【選択図】 図１
Description
【０００１】
【発明の属する技術分野】
本発明はプログラム間におけるメッセージ通信技術に関する。
【０００２】
【従来の技術】
情報処理の形態は、かつては専らメインフレームと端末による集中型処理であったが現在ではクライアントサーバ方式が主流となりつつあり、その基盤は分散処理方式である。この分散処理方式における通信方式として柔軟で拡張性に富んだシステムを構築するためメッセージキューを介し、クライアントとサーバシステム間の通信を非同期に通信する非同期メッセージ通信を活用したシステム構築の事例が急速に広まっている。非同期メッセージ通信ではクライアントアプリケーションはサーバシステムへの処理要求メッセージを送信キューに格納したところで要求処理を手放すことができ、さらにクライアントアプリケーションはサーバシステムから応答された処理結果メッセージをキューから取り出すことで参照できる。
【０００３】
つまり非同期メッセージ通信はサーバシステムへの処理要求メッセージの送信やサーバからの処理結果メッセージの受信がクライアントアプリケーションから離れ、バックグラウンドで実行できるといった特徴がある。処理要求メッセージを実行できる業務アプリケーションを持ったサーバシステムが複数存在する場合もクライアントアプリケーションは処理要求メッセージがどのサーバシステムに送信されて実行されるかは検知する必要がない。しかし、業務アプリケーションの実行待ちによる停滞がより少ないサーバシステムを送信先として選択することが望まれる。
【０００４】
従来の処理要求メッセージの送信先サーバシステムの選択方法としては特許文献１に開示されているようなサーバシステムからクライアントに通知される可用性データに基づいて送信可能なサーバシステムを選択し、選択可能なサーバシステムが複数存在する場合は例えばラウンドロビン方式などの任意の負荷分散ロジックに基づいたアルゴリズムにより解決される。
【０００５】
【特許文献１】
特開平１１−３２８１３２号
【０００６】
【発明が解決しようとする課題】
上記従来技術はクライアントがサーバシステムから受信する受信可／否データをもとに送信先が決定されるが、受信可能となっているサーバシステムが複数存在するときクライアント内の負荷分散ロジックに依存される。例えばクライアントがラウンドロビン方式を採用している場合、特定のサーバシステムが業務アプリケーションの実行遅延などの理由から既に多数の処理要求メッセージを抱えている場合でもクライアントはそのサーバシステムを送信先として選択し、処理要求メッセージを送信してしまうため、サーバシステム間での処理要求メッセージの仕掛かりが均等化できなくなり、特定のサーバシステムで多数の処理要求メッセージをもつ傍ら他のサーバシステムで処理要求メッセージの到着待ちとなるなどシステム全体のスループットが低下する場合があるといった問題があった。
【０００７】
本発明は、サーバシステム間の負荷のアンバランスの改善や、サーバシステムのリソースをより効率的に利用することを目的とする。
【０００８】
【課題を解決するための手段】
上記の目的を達成するために以下の方法を用いるものである。クライアントの送信要求アプリケーションで発行されるサーバシステムの業務アプリケーションに対する処理要求メッセージは処理要求メッセージのサーバシステム送信時に送信先判定テーブルを参照することで、同一業務アプリケーションをもったサーバシステムの集まりであるサーバグループの中から処理要求メッセージの送信先サーバシステムを選択する。ここでいうメッセージ通信は、端末と計算機もしくは計算機間の通信、もしくはプログラム間やオブジェクト間、プログラムとオブジェクト間の通信でも良い。
【０００９】
クライアントで保持する送信先判定テーブルは後述のサーバグループ内負荷管理装置により受け取るテーブルであり、サーバグループ内の全てのサーバシステム内の受信キューに格納されているメッセージ数とそれぞれの「起動中」または「停止中」の業務アプリケーションの実行状況を保持している。
【００１０】
クライアントにおける送信先サーバシステムの判定基準は送信先判定テーブルのレコード内で最もメッセージ数が少ない業務アプリケーションが「起動中」のサーバシステムを選択する。ここでもし、前記の条件を満たすサーバシステムが複数存在した場合はそのうちどのサーバシステムを選択しても良い。クライアントは選択したサーバシステムへ処理要求メッセージを送信する。送信が成功すると送信時にサーバシステムから受け取った最新の受信キューのメッセージ数と業務アプリケーションの実行状況を送信先判定テーブルの送信先サーバシステムのレコードに対して更新する。
【００１１】
ここでもし、サーバシステムへの処理要求メッセージの送信に失敗した場合は、サーバシステムに障害が発生しているものと判断し、送信先判定テーブル内の該当するサーバシステムの業務アプリケーションの実行状況を「停止中」に変更することで当該サーバシステムへの処理要求メッセージの送信を抑止する。なお、クライアントが処理要求メッセージの送信時に参照する送信先判定テーブルには有効期限を設けてサーバグループ内負荷管理装置より更新した送信先判定テーブルがクライアント定義による間隔を経過した場合は使用せず、再びサーバグループ内負荷管理装置から最新データを取得する。
【００１２】
サーバグループ内負荷管理装置では定期的およびサーバシステムの業務アプリケーションの状態が「起動中」から「停止中」、または「停止中」から「起動中」に変わる度に各サーバシステムが通知する更新データをもとにサーバグループ内の全てのサーバシステムの受信キューに格納されているメッセージ数と業務アプリケーションの実行状況を管理する。サーバグループ内負荷管理装置ではシステムで定義された一定の間隔内に更新データを送付しなかったサーバシステムについてサーバシステムに障害が発生しているものと判断し、送信先判定テーブル内の該当サーバシステムの業務アプリケーションの実行状況を「停止中」に変更することで当該サーバシステムへの処理要求メッセージの送信を抑止する。
【００１３】
サーバシステム内では受信キューの処理要求メッセージがシステムで定義された一定の間隔取り出しが行われていないと業務アプリケーションが異常停止していると判断し、サーバシステムの業務アプリケーションの実行状況を「停止中」としてサーバグループ内負荷監視装置に通知し、処理要求メッセージの送信を抑止する。さらに当該サーバシステムはサーバグループ内負荷監視装置から受信キュー管理テーブルの状態を取得し、クライアントのサーバシステム選択手順と同様な手順で転送先のサーバシステムを選択し、転送先サーバに向けてメッセージを送信する。
【００１４】
サーバシステムでの業務アプリケーションの実行状況は業務アプリケーションが開始または実行契機で「開始中」に設定され終了時に「停止中」に設定される。つまりサーバグループ内負荷管理装置での更新データの通知のよる監視やーバシステム内での受信キューの処理要求メッセージの取り出しの監視によって抑止されたクライアントからの処理要求メッセージの送信やサーバシステムの転送処理は業務アプリケーションの開始時または実行時に解除する。
【００１５】
【発明の実施の形態】
以下、本発明の実施例を図面より説明する。図１は本発明の一実施例の概略構成図である。
図１において１０１はクライアントを示す。２０１はサーバグループ４０１に属するサーバシステムを示す。また３０１はサーバグループ４０１に設置されたサーバ内負荷管理装置を示す。
【００１６】
クライアント１０１はサーバグループ４０１のサーバシステムの業務アプリケーション２１に対する処理要求をするクライアント処理要求アプリケーション１０と処理要求メッセージを生成する処理要求メッセージ生成部１１と処理要求メッセージを蓄積するクライアント送信キュー１２とサーバグループ４０１の中から送信先のサーバシステム２０１を選択するクライアントメッセージ送信先判定部１３と送信先サーバシステムを選択するため判定情報となる送信先サーバ判定テーブル１４を有する。ここでいうアプリケーションは、プログラム、業務プログラム、オブジェクトでも良い。
【００１７】
さらにクライアント１０１はサーバシステム２０１より送付される処理結果メッセージを格納するためのクライアント受信キュー１５とクライアント受信キュー１５から処理結果メッセージを取り出すクライアント処理結果メッセージ応答部１６および処理結果をクライアント１０１のユーザに向けて結果を表示するクライアント結果表示アプリケーション１７を有する。さらにクライアント１０１からサーバシステム２０１へ処理要求メッセージを送信するクライアントメッセージ送信部１８とサーバシステム２０１からの処理結果メッセージ受信し、クライアント受信キュー１５へ格納するクライアントメッセージ受信部１９を有する。
【００１８】
サーバシステム２０１はクライアント１０１から受信した処理要求メッセージを蓄積できるサーバ受信キュー２０と処理要求メッセージに応じた業務データベース２２に検索や更新などのアクセスをし、サーバ送信キュー２３へ処理結果メッセージを格納する業務アプリケーション２１と処理結果メッセージを蓄積するサーバ送信キュー２３とサーバ受信キュー２０の処理要求メッセージの格納を監視するサーバ送信キュー監視部２４とクライアント１０１から処理要求メッセージを受信してサーバ受信キュー２０へ格納するサーバメッセージ受信部２８とクライアント１０１への処理結果メッセージの送信を行うサーバメッセージ送信部２９を有する。
【００１９】
さらにサーバシステム２０１はサーバ受信キュー２０の処理要求メッセージの格納数を管理するサーバ受信キュー状態管理部２５と業務アプリケーション２１の起動と停止状態を監視し、停止状態になるとサーバ受信キュー２０の処理要求メッセージを他のサーバシステム２０１へ転送する業務アプリケーション状態監視部２６とその転送先となるサーバシステムを選択するため判定情報となる転送先サーバ判定テーブル２７を有する。
【００２０】
サーバグループ内負荷管理装置３０１はサーバグループ４０１内の全てのサーバシステム２０１のサーバ受信キュー２０のメッセージ数と業務アプリケーションの状態を管理する受信キュー管理テーブル３２とサーバシステム２０１から通知される情報を受信キュー管理テーブル３２に更新する受信キュー負荷状態更新部３１とクライアント１０１またはサーバシステム２０１からのサーバ受信キュー管理テーブル３２の参照に応答する受信キュー負荷状態応答部３０を有する。
【００２１】
なお、システム内のクライアント１０１およびサーバシステム２０１にはそれぞれシステム全体でユニークとなるクライアントＩＤまたはサーバシステムＩＤを付与するものとする。
【００２２】
クライアント１０１においてクライアント処理要求アプリケーション１０は図２に示したフローチャート１０２０１に従って実行する。クライアント処理要求アプリケーション１０は例えばグラフィカルユーザインタフェースなど任意のユーザアプリケーションを介して、サーバシステムにおける例えば業務データベース更新や検索要求など任意の処理要求を受け付け、処理要求をクライアント処理要求メッセージ生成部に通知する。
【００２３】
クライアント処理要求メッセージ生成部１１は図３に示したフローチャート１０３０１に従って実行する。クライアント処理要求メッセージ生成部１１は図１９に示す処理要求メッセージ形式１９０１に従った処理要求メッセージを作成する。処理要求メッセージのメッセージ種別フィールドには本メッセージが処理要求メッセージであることを示すシステム共通で定めた識別子を更新する。メッセージＩＤフィールドにはシステム全体でユニークとなる任意のメッセージＩＤを更新する。メッセージＩＤをシステム全体でユニークにする方法については規定しない。例えば「クライアントＩＤ＋メッセージ生成時刻＋同一時刻内の生成通番」などが考えられる。メッセージ生成時刻フィールドには現在時刻を更新する。要求元クライアントＩＤフィールドには自クライアントＩＤを更新する。処理要求内容フィールドにはクライアント処理要求アプリケーション１１から受け付けた処理要求を更新する。次にクライアント処理要求メッセージ生成部１１は作成した処理要求メッセージをクライアント送信キュー１２に格納する。
【００２４】
クライアント送信キュー１２はクライアントメッセージ送信先判定部１３によって監視される。クライアントメッセージ送信先判定部１３は図４に示したフローチャート１０４０１に従って実行する。クライアントメッセージ送信先判定部１３はクライアント送信キュー１２に処理要求メッセージが到着すると、まずはクライアント１０１内で管理される送信先サーバ判定テーブル１４のデータ更新時刻を参照する。現在時刻がデータ更新時刻からクライアント１０１内であらかじめ定義された更新間隔を経過している場合は以下の手順により送信先判定テーブル１４を最新情報に更新する。クライアントメッセージ送信先判定部１３は図２２に示したサーバ負荷情報送信依頼電文形式２２０１に従ったサーバ負荷情報送信依頼電文を作成する。
【００２５】
サーバ負荷情報送信依頼電文の電文種別フィールドには本電文がサーバ負荷情報送信依頼電文であることを示すシステム共通で定めた識別子を更新する。依頼元システムＩＤフィールドには自クライアントＩＤを更新する。
【００２６】
作成したサーバ負荷情報送信依頼電文はサーバグループ内負荷管理装置３０１のサーバ受信キュー負荷情報応答部３０へ送信する。
サーバ受信キュー負荷情報応答部３０からは図２３に示したサーバ負荷情報応答電文形式２３０１に従ったサーバ負荷情報応答電文が返却される。
【００２７】
サーバ負荷情報応答電文にはサーバグループ４０１に属したサーバシステム毎のサーバ受信キューのメッセージ数と業務アプリケーションのステータス情報が埋め込まれている。クライアントメッセージ送信先判定部１３はこのサーバ負荷情報応答電文を受け取るとサーバ負荷情報応答電文の先頭サーバシステムＩＤフィールドのシステムＩＤから最終サーバシステムＩＤフィールドのシステムＩＤまで順番に図２７に示した送信先判定テーブル形式２７０１の形式をもった送信先判定テーブル１４にサーバ負荷情報応答電文のサーバ受信キューメッセージ数フィールドと業務アプリケーションステータスフィールドの内容を更新する。なお、送信先判定テーブル１４のクライアント１０１内での保持方法は規定しない。ただし、クライアント１０１のシステム軽度を保つためにはメモリ上で保持することが望ましい。送信先判定テーブル１４の更新が完了するとクライアント１０１のシステム内固有に管理される送信先サーバ判定テーブル１４のデータ更新時刻を現在時刻に更新する。
【００２８】
クライアントメッセージ送信先判定部１３は次に送信先サーバ判定テーブル１４を使用して処理要求メッセージの送信先サーバシステムを選択する。処理要求メッセージの送信先サーバシステムの選択処理の手順については後述する。
【００２９】
クライアントメッセージ送信先判定部１３は処理要求メッセージの送信先サーバシステムの選択処理により送信先サーバシステムが選択できなかった場合は送信先サーバ判定テーブル１４のデータ更新時刻から更新間隔が経過するまで待ち、再びサーバ負荷情報送信依頼電文の作成処理に戻る。送信先サーバシステムが選択できた場合、クライアント送信キュー１２から処理要求メッセージを取得し、取得した処理要求メッセージの送信先サーバシステムＩＤフィールドに送信先サーバシステムの選択処理で選択した送信先サーバシステムのサーバシステムＩＤを更新する。そしてクライアントメッセージ送信部１８へ処理要求メッセージを通知し、送信指示する。クライアントメッセージ送信部１８による処理要求メッセージの送信処理が終わるとクライアントメッセージ送信部１８からの戻り値を判定し、送信成功が返却された場合は戻り値に付与されたメッセージ数と業務アプリケーションステータスを送信先サーバ判定テーブル１４の送信先サーバシステムのレコードに対して更新する。
【００３０】
またクライアントメッセージ送信部１８から送信失敗が返却された場合は該当サーバシステムが送信先サーバシステムとして選択されないように送信先サーバ判定テーブル内の業務アプリケーションステータスフィールドを「停止中」に変更する。その後、クライアントメッセージ送信先判定部１３はクライアント受信キュー１２のメッセージ監視処理に戻り、これら一連の処理を繰り返す。
クライアントメッセージ送信先判定部１３の送信先サーバシステムの選択処理は図５に示すフローチャート１０５０１に従って実行する。まず送信先サーバ判定テーブル１４の全てのレコードを参照し、業務アプリケーションステータスフィールドが「起動中」のサーバシステムＩＤを抽出する。ここでもし、「起動中」のサーバシステム２０１が一つも存在しない場合は選択可能なサーバシステム２０１がないものと判断し、「選択可能なサーバシステムなし」を返却する。
【００３１】
起動中のサーバシステム２０１が１つしかないときはそのサーバシステムが送信先サーバシステムとして選択されることになり、そのサーバシステムのサーバシステムＩＤを返却する。また、起動中のサーバシステム２０１が複数あるときはサーバ受信キューメッセージ数が最も少ないサーバシステム２０１を選択し、そのサーバシステム２０１のサーバシステムＩＤを返却する。また、サーバ受信キューメッセージ数については、他に比べて少ないものでもある程度の効果は期待できる。
【００３２】
ここでもし、サーバ受信キューメッセージ数が同一のサーバシステム２０１が複数存在した場合は、そのうちでどのサーバシステム２０１を選択しても良いものとする。例えばシステムＩＤの小さい方を優先的に選択することで一つのサーバシステム２０１を特定できる。
【００３３】
クライアントメッセージ送信部１８はクライアントメッセージ送信先判定部１３が選択したサーバシステム２０１へ処理要求メッセージを送信する。クライアントメッセージ送信部１８は図６に示したフローチャート１０６０１に従って実行される。
【００３４】
クライアントメッセージ送信部１８は送信指示を受け付けると図２４に示したメッセージ送信電文形式２４０１に従うメッセージ送信電文を作成する。メッセージ送信電文の電文種別フィールドには本電文がメッセージ送信電文であることを示すシステム共通で定めた識別子を更新する。依頼元システムＩＤフィールドには自クライアントＩＤを格納する。メッセージフィールドにはクライアントメッセージ送信先判定部１３より受け取った処理要求メッセージを更新する。そして処理要求メッセージの送信先サーバシステムＩＤフィールドを参照し、そのサーバシステム２０１のサーバメッセージ受信部２８に向けてメッセージ送信電文を送信する。
【００３５】
その後送信先のサーバシステムから図２５に示したメッセージ送信応答電文形式２５０１に従うメッセージ送信応答電文が返るのを待つ。ここでもし、システムで定義した応答タイムアウト間隔内にメッセージ送信応答電文が返らないとき、送信先サーバシステムは停止しているものと判断し、クライアント送信キューに処理要求メッセージを戻し、送信失敗を返却する。送信先のサーバシステム２０１からメッセージ送信応答電文が返るとメッセージ送信応答電文の応答結果フィールドを参照し、応答結果が送信成功のときサーバ受信キューメッセージ数フィールドと業務アプリケーションステータスフィールドの値を戻り値に付与し、送信成功を返却する。応答結果が送信失敗の場合はクライアント送信キュー１５に処理要求メッセージを戻し、送信失敗を返却する。
【００３６】
クライアントメッセージ送信部１８が送信するメッセージ送信電文はサーバメッセージ受信部２８が受信する。サーバメッセージ受信部２８は図１１に示したフローチャート１１１０１に従って実行する。サーバメッセージ受信部２８はメッセージ送信電文を受け取るとまず、サーバシステム内で保持している業務アプリケーションステータスを参照する。この業務アプリケーションステータスはサーバシステム内の業務アプリケーションが「起動中」か「停止中」かを表わす情報で例えば共用メモリ領域などで管理されたサーバシステム２０１内の機能間で参照および更新ができる共通情報である。
【００３７】
業務アプリケーションステータスが「起動中」のときメッセージ送信電文から処理要求メッセージを取り出し、サーバ受信キュー２０に格納する。そしてサーバ受信キュー２０の現在のメッセージ数を参照する。その後、メッセージ送信応答電文を作成する。メッセージ送信応答電文の電文種別フィールドには本電文がメッセージ送信応答電文であることを示すシステム共通で定めた識別子を更新する。サーバ受信キューメッセージ数フィールドには参照したサーバ受信キュー２０の現在のメッセージ数を更新する。業務アプリケーションフィールドには現在の業務アプリケーションステータスを更新する。応答結果フィールドは送信成功に更新する。 そして作成したメッセージ送信応答電文をメッセージ送信電文の依頼元システムＩＤフィールドに格納されている依頼元システムに向けて送信する。業務アプリケーションステータスが「停止中」のときは同様にメッセージ送信応答電文を作成するが、電文種別フィールドを更新した後、応答結果フィールドには送信失敗を更新する。サーバ受信キューメッセージ数フィールドと業務アプリケーションステータスフィールドは更新する必要はない。作成したメッセージ送信応答電文は同様の手順で依頼元システムに送信する。
【００３８】
サーバシステム２０１の受信キュー２０はサーバ受信キュー状態管理部２５により監視される。サーバ受信キュー状態管理部２５は図１２に示したフローチャート１１２０１に従って実行する。サーバ受信キュー状態管理部２５はサーバシステム内であらかじめ定義したサーバ受信キュー監視間隔毎または業務アプリケーション状態監視部からの受信キューの状態報告指示により、図２１に示したサーバ受信キュー状態報告電文形式２１０１に従うサーバ受信キュー状態報告電文を作成する。サーバ受信キュー状態報告電文の電文種別フィールドには本電文がサーバ受信キュー状態報告電文であることを示すシステム共通で定めた識別子を更新する。サーバシステムＩＤフィールドには自サーバシステムＩＤを更新する。サーバ受信キューメッセージ数フィールドにはサーバ受信キュー２０から現在の処理要求メッセージ数を取得し、更新する。
【００３９】
さらに業務アプリケーションステータスフィールドにサーバシステム内で管理する業務アプリケーションステータスを更新する。作成したサーバ受信キュー状態報告電文はサーバグループ内負荷管理装置３０１のサーバ受信キュー負荷状態更新部３１に通知する。
【００４０】
サーバ受信キュー負荷状態更新部３１は図１８のフローチャート１１８０１に従って実行する。サーバ受信キュー負荷管理状態更新部３１はサーバ受信キュー状態報告電文を受け取るとサーバ受信キュー管理テーブル３２を更新する。サーバ受信キュー管理テーブル３２は図２６に示したサーバ受信キュー管理テーブル形式２６０１の形式をもつ。サーバ受信キュー管理テーブル３２はサーバグループ４０１内のサーバシステム２０１それぞれのサーバ受信キュー２０に格納されたメッセージ数と業務アプリケーション２１が「起動中」であるか「停止中」であるかを示すステータス各レコードの更新時刻を管理情報として保持する。なおサーバグループ内負荷管理装置３０１でのサーバ受信キュー管理テーブル３２の保持方法は規定しない。しかし、本テーブルの各サーバシステムのレコード情報は最新の管理情報が逐次更新されるのでデータベース管理システムを使用することが望ましい。
【００４１】
サーバ受信キュー負荷状態更新部３１はサーバ受信キュー状態報告電文よりサーバシステムＩＤフィールドとサーバ受信キューメッセージ数フィールドおよび業務アプリケーションステータスフィールドを参照し、サーバ受信キュー管理テーブル３２のサーバシステムＩＤが合致するレコードに対してサーバ受信キューメッセージ数フィールドと業務アプリケーションステータスフィールドに更新する。さらに同レコードの更新時刻フィールドは現在時刻で更新する。
【００４２】
また、サーバ受信キュー負荷管理状態更新部３１では、各サーバシステム２０１からサーバ受信キュー状態報告電文が定期的に送られているかを監視している。サーバグループ内負荷管理装置３０１であらかじめ定義されたサーバ受信キュー管理テーブル更新監視間隔毎にサーバ受信キュー管理テーブル３２の全レコードの更新時刻フィールドをチェックし、サーバ受信キュー管理テーブル更新監視間隔内に更新されていないレコードに該当するサーバシステム２０１は停止していると判断し、該当レコードの業務アプリケーションステータスフィールドを「停止中」に更新する。
【００４３】
クライアント１０１やサーバシステム２０１からのサーバ受信キュー管理テーブル３２への参照はサーバグループ内負荷管理装置３０１のサーバ受信キュー負荷状態応答部３０が応答する。サーバ受信キュー負荷状態応答部３０は図１７に示したフローチャート１１７０１に従って実行される。サーバ受信キュー負荷状態応答部３０ではクライアント１０１またはサーバシステム２０１から送られるサーバ負荷情報送信依頼電文を受け取るとサーバ受信キュー管理テーブル３２より全サーバシステム２０１のレコードを参照し、サーバ負荷情報応答電文を作成する。
【００４４】
サーバ負荷情報応答電文の電文種別フィールドには本電文がサーバ負荷情報応答電文であることを示すシステム共通で定めた識別子を格納し、先頭サーバシステムＩＤフィールドにはサーバ受信キュー管理テーブル３２の先頭レコードのシステムＩＤ、最終サーバシステムＩＤフィールドに最終レコードのシステムＩＤを格納する。そしてサーバシステムＩＤフィールド、サーバ受信キューメッセージ数フィールドおよび業務アプリケーションステータスフィールドにはサーバ受信キュー管理テーブルの先頭レコードから最終レコードまでレコード順にフィールドに対応して格納する。作成したサーバ負荷情報応答電文はサーバ負荷情報送信依頼電文の依頼元システムＩＤフィールドを参照し、依頼元システムに向けて送信する。
【００４５】
一方、サーバシステム２０１の受信キュー２０に格納された処理要求メッセージは業務アプリケーション２１によって監視される。業務アプリケーション２１は図１５に示したフローチャート１１５０１に従って実行する。業務アプリケーション２１は起動時に業務アプリケーションステータスを「起動中」に更新する。起動後はユーザからの停止要求があるまで常時、サーバ受信キュー２０を参照し、処理要求メッセージの到着を監視する。サーバ受信キュー２０に処理要求メッセージがあったとき業務アプリケーション２１はサーバ受信キュー２０から処理要求メッセージを取得する。
【００４６】
ただし、サーバ受信キュー内の処理要求メッセージは他サーバシステム２０１から転送されてくる場合があるため、サーバ受信キュー２０に格納された順序が必ずしも処理要求メッセージの生成時刻が古いものから順番になっているとは限らない。このため、メッセージの取得手順はメッセージ先入れ先出し方式ではなく処理要求メッセージのメッセージ生成時刻フィールドが最も古いものを優先して取得する。
【００４７】
業務アプリケーション２１は取得した処理要求メッセージの処理要求内容フィールドを参照し、業務データベース２２などを利用し、処理要求内容に応じたユーザアプリケーションを実行することで要求元のクライアント１０１への処理結果を得る。業務アプリケーション２１は次に図２０に示した処理結果メッセージ形式２００１に従う処理結果メッセージを作成する。処理結果メッセージのメッセージ種別フィールドには本メッセージが処理結果メッセージであることを示すシステム共通で定めた識別子を更新する。要求元クライアントＩＤフィールドには処理要求メッセージに格納されていた要求元クライアントＩＤを更新する。
【００４８】
さらに処理結果フィールドにはユーザアプリケーションによって得た処理結果を格納する。作成した処理結果メッセージはサーバ送信キュー２３に格納する。業務アプリケーション２１はユーザアプリケーションを実行する度に業務アプリケーションステータスを「起動中」に更新する。これはユーザアプリケーションがその処理内容によって、特異的に処理が遅延した場合を考慮しており、もし業務アプリケーション状態監視部２６が後述のアプリケーション実行監視処理により業務アプリケーションステータスを「停止中」に更新しても業務アプリケーション２１が処理を継続している場合には業務アプリケーションステータスを「起動中」に戻すことができるためである。
【００４９】
業務アプリケーション２１は停止時に業務アプリケーションステータスを「停止中」に変更する。
【００５０】
業務アプリケーション２１が変更する業務アプリケーションステータスは業務アプリケーション状態監視部２６が監視する。業務アプリケーション状態監視部２６は図１３のフローチャート１１３０１に従って実行する。業務アプリケーション状態監視部２６は業務アプリケーションステータスが「停止中」から「起動中」に状態が変わるとサーバ受信キュー状態管理部２５へサーバ受信キューの状態報告を指示する。業務アプリケーション状態監視部２６は業務アプリケーションステータスが「起動中」になると今度は「停止中」に変更されていないかを随時チェックする。また起動中の間はサーバ受信キュー２０に格納された処理要求メッセージが正常に処理されているか業務アプリケーション２１の状態監視処理をする。業務アプリケーション状態監視手順は以下通りである。
【００５１】
まず、サーバ受信キュー２０に処理要求メッセージが格納されているかどうかチェックし、処理要求メッセージが格納されている時、業務アプリケーション２１が次に処理する先頭の処理要求メッセージを参照し、そのメッセージＩＤを記憶する。その後、サーバシステム２０１内であらかじめ定義したアプリケーション実行監視間隔の時間待つ。ただし、この間も業務アプリケーションステータスが「停止中」に変更されないかは繰り返しチェックする。アプリケーション実行監視間隔が経過すると再度サーバ受信キューに処理要求メッセージをチェックする。もしサーバ受信キューにメッセージがない場合、または業務アプリケーション２１が次に処理する先頭の処理要求メッセージのメッセージＩＤが前記で記憶中したメッセージＩＤと異なる場合は処理要求メッセージが正常に動作していると判断し、監視処理を継続する。
【００５２】
しかし、前記のメッセージＩＤが記憶中のメッセージＩＤと異なる場合は業務アプリケーションが障害などの理由で業務アプリケーションステータスを変更せずにダウンしていると判断し、システム内の業務アプリケーションステータスを「停止中」に変更する。業務アプリケーション２１からのステータス変更または業務アプリケーション状態監視部２６によるステータス変更により、業務アプリケーションステータスが「停止中」になるとサーバ受信キュー状態管理部２５にサーバ受信キューの状態報告を指示する。さらにサーバ受信キュー２０に処理要求メッセージが存在するときこれらの処理要求メッセージを他のサーバシステム２０１へ転送する。
【００５３】
業務アプリケーション状態監視部２６の転送処理は図１４に示したフローチャート１１４０１に従って実行する。業務アプリケーション状態監視部２６はサーバ負荷情報送信依頼電文を作成し、サーバグループ内負荷管理装置３０１のサーバ受信キュー負荷情報応答部３０へを送信する。このときサーバ負荷情報送信依頼電文の要求元システムＩＤフィールドには自サーバシステムＩＤを格納する。サーバ受信キュー負荷情報応答部３０からサーバ負荷情報応答電文を受け取るとサーバ負荷情報応答電文の先頭サーバシステムＩＤから最終サーバシステムＩＤまで順にサーバ受信キューメッセージ数と業務アプリケーションステータスの情報をもとに図２８に示した転送先判定テーブル形式２８０１に従う転送先判定テーブル２７を作成する。
【００５４】
転送先判定テーブル２７はクライアント１０１で保持する送信先判定テーブル１４と同形式であり、サーバ負荷情報応答電文からの更新もクライアント１０１の送信先判定テーブル１４と同様の手順で行うことができる。
【００５５】
ただし、転送先判定テーブル２７は転送先として自サーバシステムが選択されることがないようにあらかじめ自サーバシステムのレコードは作成しないようにする。なお、転送先判定テーブル２７の保持方法は規定しない。しかし、転送先判定テーブル２７は処理要求メッセージ転送時の一時的な情報を管理するためのテーブルであるためメモリ上することが望ましい。転送先判定テーブル２７の更新が完了すると、ここで業務アプリケーション２１が再起動されているかチェックする。業務アプリケーションステータスが「起動中」に変更されているとき、つまり再起動された場合には転送の必要がないため転送処理は中止する。
【００５６】
業務アプリケーションステータスが「停止中」のときクライアントでの送信先サーバシステムの選択手順と同様にフローチャート１０５０１に従って業務アプリケーションが起動中で最もサーバ受信キューのメッセージ数が少ない転送先サーバシステムを選択する。転送先サーバシステムが選択できなかった場合はサーバ負荷情報送信依頼電文の送信から繰り返す。また転送先サーバシステムが選択できた場合はサーバ受信キューから処理要求メッセージを取得し、送信先サーバシステムＩＤフィールドに選択した転送先サーバシステムＩＤを更新し、サーバメッセージ送信部２９に処理要求メッセージを通知し、送信指示する。
【００５７】
サーバメッセージ送信部２９の戻り値が送信成功のとき、戻り値に付与されたサーバ受信キューメッセージ数と業務アプリケーションステータスを転送先判定テーブル２７の転送先サーバシステムＩＤのレコードに更新する。また処理要求メッセージの送信失敗が返却されると同レコードの業務アプリケーションステータスを「停止中」に変更する。次に再度自サーバシステム内の処理要求メッセージを参照し、メッセージが存在する場合は業務アプリケーションステータスチェック処理に戻り、自サーバ受信キューのメッセージがなくなるか、業務アプリケーションのステータスが「起動中」になるまでこれを繰り返す。
【００５８】
サーバ送信キュー２３に格納された処理結果メッセージはサーバ送信キュー監視部２４により監視される。サーバ送信キュー監視部２４は図１６のフローチャート１１６０１に従って実行される。サーバ送信キュー２３に処理結果メッセージが格納されるとサーバ送信キュー監視部２４がこれを取り出し、取り出した処理結果メッセージをサーバメッセージ送信部２９に通知する。
【００５９】
サーバメッセージ送信部２９はサーバ送信キュー監視部２９からの処理結果メッセージのクライアント１０１への送信と業務アプリケーション状態監視部２６からの処理要求メッセージの他サーバシステム２０１への転送を行う。サーバメッセージ送信部２９は図１０に示したフローチャート１１００１に従って実行される。
【００６０】
サーバメッセージ送信部２９は送信指示を受け付けると通知されたメッセージのメッセージ種別フィールドを参照する。メッセージ種別が処理結果メッセージの場合、まずメッセージ送信電文を作成する。電文種別フィールドにはメッセージ送信電文を示す識別子を更新する。依頼元システムＩＤフィールドは自サーバシステムＩＤを更新する。メッセージフィールドにはサーバ送信キュー監視部２９から受け取った処理結果メッセージを更新する。次に処理結果メッセージの要求元クライアントＩＤフィールドを参照し、要求元のクライアント１０１のメッセージ受信部にメッセージ送信電文を送信する。その後送信先のクライアント１０１からのメッセージ送信応答電文が返るのを待つ。
【００６１】
ここでもし、システムで定義した応答タイムアウト間隔内にメッセージ送信応答電文が返らないとき、サーバ送信キュー２４に処理要求メッセージを戻し、送信失敗を返却する。
【００６２】
送信先のクライアント１０１からメッセージ送信応答電文が返るとメッセージ送信応答電文の応答結果フィールドを参照し、応答結果が送信成功のとき、送信成功を返却する。応答結果が送信失敗の場合はサーバ送信キュー２３に処理要求メッセージを戻し、送信失敗を返却する。
【００６３】
メッセージ種別が処理要求メッセージの場合、まずメッセージ送信電文を作成する。電文種別フィールドにはメッセージ送信電文を示す識別子を更新する。依頼元システムＩＤフィールドは自サーバシステムＩＤを更新する。メッセージフィールドには業務アプリケーション状態監視部２６から受け取った処理要求メッセージを更新する。次に処理要求メッセージの送信先サーバシステムＩＤフィールドを参照し、転送先のサーバシステム２０１のメッセージ受信部２８にメッセージ送信電文を送信する。その後転送先のサーバシステム２０１からのメッセージ送信応答電文が返るのを待つ。
【００６４】
ここでもし、システムで定義した応答タイムアウト間隔内にメッセージ送信応答電文が返らないとき、転送先サーバシステム２０１は停止しているものと判断し、サーバ受信キュー２０に処理要求メッセージを戻し、送信失敗を返却する。
【００６５】
転送先のサーバシステム２０１からメッセージ送信応答電文が返るとメッセージ送信応答電文の応答結果フィールドを参照し、応答結果が送信成功のときメッセージ送信応答電文のサーバ受信キューメッセージ数フィールドと業務アプリケーションステータスフィールドの値を戻り値に付与し、送信成功を返却する。応答結果が送信失敗の場合はサーバ受信キュー２０に処理要求メッセージを戻し、送信失敗を返却する。
【００６６】
クライアント１０１ではサーバシステム２０１が送信するメッセージ送信電文をクライアントメッセージ受信部１９が受信する。クライアントメッセージ受信部１９は図７に示したフローチャート１０７０１に従って実行する。クライアントメッセージ受信部１９ではサーバシステム２０１からのメッセージ送信電文を受け取るとメッセージ送信電文のメッセージフィールドから処理結果メッセージを取得し、クライアント受信キュー１５に格納する。その後、メッセージ送信応答電文を作成し、電文種別フィールドにメッセージ送信電文の識別子を更新し、さらに応答結果フィールドには送信成功を更新する。そしてメッセージ送信電文の依頼元システムＩＤフィールドに格納されたサーバシステム２０１にメッセージ送信応答電文を送信する。
【００６７】
クライアント１０１のクライアント受信キュー１５はクライアント処理結果メッセージ応答部１６により監視される。クライアント処理結果メッセージ応答部１６は図８に示したフローチャート１０８０１に従って実行する。クライアント処理結果メッセージ応答部１６はクライアント受信キュー１５に処理結果メッセージが格納されると処理結果メッセージを取得し、処理結果メッセージの処理結果フィールドの内容をクライアント結果表示アプリケーション１７に通知する。
【００６８】
クライアント結果表示アプリケーション１７は図９に示したフローチャート１０９０１に従って実行する。クライアント結果表示アプリケーション１７では例えばグラフィカルユーザインタフェースなど任意のユーザアプリケーションを介して処理結果をユーザに通知する。
【００６９】
サーバグループ内のサーバシステム間での業務アプリケーションの負荷を均等化することでサーバグループ内のシステムリソースを効率的に利用することができ、業務アプリケーションの実行待ちが少ないサーバを選択できる。さらに業務アプリケーションが異常停止した場合でも他のサーバシステムに転送することでサーバ処理要求メッセージの滞留を防ぐことができる。
【００７０】
【発明の効果】
本発明によれば、サーバシステム間の負荷のアンバランスの改善が可能となる
【図面の簡単な説明】
【図１】本システムの一実施例の概略構成図である。
【図２】実施例のクライアント処理要求アプリケーションの処理を示すフローチャートである。
【図３】実施例の実施例のクライアント処理要求メッセージ生成部の処理を示すフローチャートである。
【図４】実施例の実施例のクライアントメッセージ送信先判定部
の処理を示すフローチャートである。
【図５】実施例の実施例のクライアントメッセージ送信先判定部の送信先サーバシステム選択処理と業務アプリケーション状態監視部の転送先サーバシステム選択処理を示すフローチャートである。
【図６】実施例の実施例のクライアントメッセージ送信部の処理を示すフローチャートである。
【図７】実施例の実施例のクライアントメッセージ受信部の処理を示すフローチャートである。
【図８】実施例の実施例のクライアント処理結果メッセージ応答部の処理を示すフローチャートである。
【図９】実施例の実施例のクライアント結果表示アプリケーションの処理を示すフローチャートである。
【図１０】実施例の実施例のサーバメッセージ受信部の処理を示すフローチャートである。
【図１１】実施例の実施例のサーバメッセージ受信部の処理を示すフローチャートである。
【図１２】実施例の実施例のサーバ受信キュー状態管理部の処理を示すフローチャートである。
【図１３】実施例の実施例の業務アプリケーション状態監視部の監視処理を示すフローチャートである。
【図１４】実施例の実施例の業務アプリケーション状態監視部の転送処理を示すフローチャートである。
【図１５】実施例の実施例の業務アプリケーションの処理を示すフローチャートである。
【図１６】実施例の実施例のサーバ送信キュー監視部の処理を示すフローチャートである。
【図１７】実施例の実施例のサーバ受信キュー負荷状態応答部の処理を示すフローチャートである。
【図１８】実施例の実施例のサーバ受信キュー負荷状態更新部の処理を示すフローチャートである。
【図１９】実施例の処理要求メッセージの形式である。
【図２０】実施例の処理結果メッセージの形式である。
【図２１】実施例のサーバ受信キュー状態報告電文の形式である。
【図２２】実施例のサーバ負荷情報送信依頼電文の形式である。
【図２３】実施例のサーバ負荷情報応答電文の形式である。
【図２４】実施例のメッセージ送信電文の形式である。
【図２５】実施例のメッセージ送信応答電文の形式である。
【図２６】実施例のサーバ受信キュー管理テーブルの形式である。
【図２７】実施例の送信先サーバ判定テーブルの形式である。
【図２８】実施例の転送先サーバ判定テーブルの形式である。
【符号の説明】
１０１ クライアント
２０１ サーバシステム
３０１ サーバグループ内負荷管理装置
４０１ サーバグループ
１０ クライアント処理要求アプリケーション
１１ クライアント処理要求メッセージ生成部
１２ クライアント受信キュー
１３ クライアントメッセージ送信先判定部
１４ 送信先サーバ判定テーブル
１５ クライアント受信キュー
１６ クライアント処理結果メッセージ応答部
１７ クライアント結果表示アプリケーション
１８ クライアントメッセージ送信部
１９ クライアントメッセージ受信部
２０ サーバ受信キュー
２１ 業務アプリケーション
２２ 業務データベース
２３ サーバ送信キュー
２５ サーバ送信キュー監視部
２５ サーバ受信キュー状態管理部
２６ 業務アプリケーション状態監視部
２７ 転送先サーバ判定テーブル
２８ サーバメッセージ受信部
２９ サーバメッセージ送信部
３０ サーバ受信キュー負荷状態応答部
３１ 業務アプリケーション負荷状態更新部
３２ サーバ受信キュー管理テーブル
【発明の属する技術分野】
本発明はプログラム間におけるメッセージ通信技術に関する。
【０００２】
【従来の技術】
情報処理の形態は、かつては専らメインフレームと端末による集中型処理であったが現在ではクライアントサーバ方式が主流となりつつあり、その基盤は分散処理方式である。この分散処理方式における通信方式として柔軟で拡張性に富んだシステムを構築するためメッセージキューを介し、クライアントとサーバシステム間の通信を非同期に通信する非同期メッセージ通信を活用したシステム構築の事例が急速に広まっている。非同期メッセージ通信ではクライアントアプリケーションはサーバシステムへの処理要求メッセージを送信キューに格納したところで要求処理を手放すことができ、さらにクライアントアプリケーションはサーバシステムから応答された処理結果メッセージをキューから取り出すことで参照できる。
【０００３】
つまり非同期メッセージ通信はサーバシステムへの処理要求メッセージの送信やサーバからの処理結果メッセージの受信がクライアントアプリケーションから離れ、バックグラウンドで実行できるといった特徴がある。処理要求メッセージを実行できる業務アプリケーションを持ったサーバシステムが複数存在する場合もクライアントアプリケーションは処理要求メッセージがどのサーバシステムに送信されて実行されるかは検知する必要がない。しかし、業務アプリケーションの実行待ちによる停滞がより少ないサーバシステムを送信先として選択することが望まれる。
【０００４】
従来の処理要求メッセージの送信先サーバシステムの選択方法としては特許文献１に開示されているようなサーバシステムからクライアントに通知される可用性データに基づいて送信可能なサーバシステムを選択し、選択可能なサーバシステムが複数存在する場合は例えばラウンドロビン方式などの任意の負荷分散ロジックに基づいたアルゴリズムにより解決される。
【０００５】
【特許文献１】
特開平１１−３２８１３２号
【０００６】
【発明が解決しようとする課題】
上記従来技術はクライアントがサーバシステムから受信する受信可／否データをもとに送信先が決定されるが、受信可能となっているサーバシステムが複数存在するときクライアント内の負荷分散ロジックに依存される。例えばクライアントがラウンドロビン方式を採用している場合、特定のサーバシステムが業務アプリケーションの実行遅延などの理由から既に多数の処理要求メッセージを抱えている場合でもクライアントはそのサーバシステムを送信先として選択し、処理要求メッセージを送信してしまうため、サーバシステム間での処理要求メッセージの仕掛かりが均等化できなくなり、特定のサーバシステムで多数の処理要求メッセージをもつ傍ら他のサーバシステムで処理要求メッセージの到着待ちとなるなどシステム全体のスループットが低下する場合があるといった問題があった。
【０００７】
本発明は、サーバシステム間の負荷のアンバランスの改善や、サーバシステムのリソースをより効率的に利用することを目的とする。
【０００８】
【課題を解決するための手段】
上記の目的を達成するために以下の方法を用いるものである。クライアントの送信要求アプリケーションで発行されるサーバシステムの業務アプリケーションに対する処理要求メッセージは処理要求メッセージのサーバシステム送信時に送信先判定テーブルを参照することで、同一業務アプリケーションをもったサーバシステムの集まりであるサーバグループの中から処理要求メッセージの送信先サーバシステムを選択する。ここでいうメッセージ通信は、端末と計算機もしくは計算機間の通信、もしくはプログラム間やオブジェクト間、プログラムとオブジェクト間の通信でも良い。
【０００９】
クライアントで保持する送信先判定テーブルは後述のサーバグループ内負荷管理装置により受け取るテーブルであり、サーバグループ内の全てのサーバシステム内の受信キューに格納されているメッセージ数とそれぞれの「起動中」または「停止中」の業務アプリケーションの実行状況を保持している。
【００１０】
クライアントにおける送信先サーバシステムの判定基準は送信先判定テーブルのレコード内で最もメッセージ数が少ない業務アプリケーションが「起動中」のサーバシステムを選択する。ここでもし、前記の条件を満たすサーバシステムが複数存在した場合はそのうちどのサーバシステムを選択しても良い。クライアントは選択したサーバシステムへ処理要求メッセージを送信する。送信が成功すると送信時にサーバシステムから受け取った最新の受信キューのメッセージ数と業務アプリケーションの実行状況を送信先判定テーブルの送信先サーバシステムのレコードに対して更新する。
【００１１】
ここでもし、サーバシステムへの処理要求メッセージの送信に失敗した場合は、サーバシステムに障害が発生しているものと判断し、送信先判定テーブル内の該当するサーバシステムの業務アプリケーションの実行状況を「停止中」に変更することで当該サーバシステムへの処理要求メッセージの送信を抑止する。なお、クライアントが処理要求メッセージの送信時に参照する送信先判定テーブルには有効期限を設けてサーバグループ内負荷管理装置より更新した送信先判定テーブルがクライアント定義による間隔を経過した場合は使用せず、再びサーバグループ内負荷管理装置から最新データを取得する。
【００１２】
サーバグループ内負荷管理装置では定期的およびサーバシステムの業務アプリケーションの状態が「起動中」から「停止中」、または「停止中」から「起動中」に変わる度に各サーバシステムが通知する更新データをもとにサーバグループ内の全てのサーバシステムの受信キューに格納されているメッセージ数と業務アプリケーションの実行状況を管理する。サーバグループ内負荷管理装置ではシステムで定義された一定の間隔内に更新データを送付しなかったサーバシステムについてサーバシステムに障害が発生しているものと判断し、送信先判定テーブル内の該当サーバシステムの業務アプリケーションの実行状況を「停止中」に変更することで当該サーバシステムへの処理要求メッセージの送信を抑止する。
【００１３】
サーバシステム内では受信キューの処理要求メッセージがシステムで定義された一定の間隔取り出しが行われていないと業務アプリケーションが異常停止していると判断し、サーバシステムの業務アプリケーションの実行状況を「停止中」としてサーバグループ内負荷監視装置に通知し、処理要求メッセージの送信を抑止する。さらに当該サーバシステムはサーバグループ内負荷監視装置から受信キュー管理テーブルの状態を取得し、クライアントのサーバシステム選択手順と同様な手順で転送先のサーバシステムを選択し、転送先サーバに向けてメッセージを送信する。
【００１４】
サーバシステムでの業務アプリケーションの実行状況は業務アプリケーションが開始または実行契機で「開始中」に設定され終了時に「停止中」に設定される。つまりサーバグループ内負荷管理装置での更新データの通知のよる監視やーバシステム内での受信キューの処理要求メッセージの取り出しの監視によって抑止されたクライアントからの処理要求メッセージの送信やサーバシステムの転送処理は業務アプリケーションの開始時または実行時に解除する。
【００１５】
【発明の実施の形態】
以下、本発明の実施例を図面より説明する。図１は本発明の一実施例の概略構成図である。
図１において１０１はクライアントを示す。２０１はサーバグループ４０１に属するサーバシステムを示す。また３０１はサーバグループ４０１に設置されたサーバ内負荷管理装置を示す。
【００１６】
クライアント１０１はサーバグループ４０１のサーバシステムの業務アプリケーション２１に対する処理要求をするクライアント処理要求アプリケーション１０と処理要求メッセージを生成する処理要求メッセージ生成部１１と処理要求メッセージを蓄積するクライアント送信キュー１２とサーバグループ４０１の中から送信先のサーバシステム２０１を選択するクライアントメッセージ送信先判定部１３と送信先サーバシステムを選択するため判定情報となる送信先サーバ判定テーブル１４を有する。ここでいうアプリケーションは、プログラム、業務プログラム、オブジェクトでも良い。
【００１７】
さらにクライアント１０１はサーバシステム２０１より送付される処理結果メッセージを格納するためのクライアント受信キュー１５とクライアント受信キュー１５から処理結果メッセージを取り出すクライアント処理結果メッセージ応答部１６および処理結果をクライアント１０１のユーザに向けて結果を表示するクライアント結果表示アプリケーション１７を有する。さらにクライアント１０１からサーバシステム２０１へ処理要求メッセージを送信するクライアントメッセージ送信部１８とサーバシステム２０１からの処理結果メッセージ受信し、クライアント受信キュー１５へ格納するクライアントメッセージ受信部１９を有する。
【００１８】
サーバシステム２０１はクライアント１０１から受信した処理要求メッセージを蓄積できるサーバ受信キュー２０と処理要求メッセージに応じた業務データベース２２に検索や更新などのアクセスをし、サーバ送信キュー２３へ処理結果メッセージを格納する業務アプリケーション２１と処理結果メッセージを蓄積するサーバ送信キュー２３とサーバ受信キュー２０の処理要求メッセージの格納を監視するサーバ送信キュー監視部２４とクライアント１０１から処理要求メッセージを受信してサーバ受信キュー２０へ格納するサーバメッセージ受信部２８とクライアント１０１への処理結果メッセージの送信を行うサーバメッセージ送信部２９を有する。
【００１９】
さらにサーバシステム２０１はサーバ受信キュー２０の処理要求メッセージの格納数を管理するサーバ受信キュー状態管理部２５と業務アプリケーション２１の起動と停止状態を監視し、停止状態になるとサーバ受信キュー２０の処理要求メッセージを他のサーバシステム２０１へ転送する業務アプリケーション状態監視部２６とその転送先となるサーバシステムを選択するため判定情報となる転送先サーバ判定テーブル２７を有する。
【００２０】
サーバグループ内負荷管理装置３０１はサーバグループ４０１内の全てのサーバシステム２０１のサーバ受信キュー２０のメッセージ数と業務アプリケーションの状態を管理する受信キュー管理テーブル３２とサーバシステム２０１から通知される情報を受信キュー管理テーブル３２に更新する受信キュー負荷状態更新部３１とクライアント１０１またはサーバシステム２０１からのサーバ受信キュー管理テーブル３２の参照に応答する受信キュー負荷状態応答部３０を有する。
【００２１】
なお、システム内のクライアント１０１およびサーバシステム２０１にはそれぞれシステム全体でユニークとなるクライアントＩＤまたはサーバシステムＩＤを付与するものとする。
【００２２】
クライアント１０１においてクライアント処理要求アプリケーション１０は図２に示したフローチャート１０２０１に従って実行する。クライアント処理要求アプリケーション１０は例えばグラフィカルユーザインタフェースなど任意のユーザアプリケーションを介して、サーバシステムにおける例えば業務データベース更新や検索要求など任意の処理要求を受け付け、処理要求をクライアント処理要求メッセージ生成部に通知する。
【００２３】
クライアント処理要求メッセージ生成部１１は図３に示したフローチャート１０３０１に従って実行する。クライアント処理要求メッセージ生成部１１は図１９に示す処理要求メッセージ形式１９０１に従った処理要求メッセージを作成する。処理要求メッセージのメッセージ種別フィールドには本メッセージが処理要求メッセージであることを示すシステム共通で定めた識別子を更新する。メッセージＩＤフィールドにはシステム全体でユニークとなる任意のメッセージＩＤを更新する。メッセージＩＤをシステム全体でユニークにする方法については規定しない。例えば「クライアントＩＤ＋メッセージ生成時刻＋同一時刻内の生成通番」などが考えられる。メッセージ生成時刻フィールドには現在時刻を更新する。要求元クライアントＩＤフィールドには自クライアントＩＤを更新する。処理要求内容フィールドにはクライアント処理要求アプリケーション１１から受け付けた処理要求を更新する。次にクライアント処理要求メッセージ生成部１１は作成した処理要求メッセージをクライアント送信キュー１２に格納する。
【００２４】
クライアント送信キュー１２はクライアントメッセージ送信先判定部１３によって監視される。クライアントメッセージ送信先判定部１３は図４に示したフローチャート１０４０１に従って実行する。クライアントメッセージ送信先判定部１３はクライアント送信キュー１２に処理要求メッセージが到着すると、まずはクライアント１０１内で管理される送信先サーバ判定テーブル１４のデータ更新時刻を参照する。現在時刻がデータ更新時刻からクライアント１０１内であらかじめ定義された更新間隔を経過している場合は以下の手順により送信先判定テーブル１４を最新情報に更新する。クライアントメッセージ送信先判定部１３は図２２に示したサーバ負荷情報送信依頼電文形式２２０１に従ったサーバ負荷情報送信依頼電文を作成する。
【００２５】
サーバ負荷情報送信依頼電文の電文種別フィールドには本電文がサーバ負荷情報送信依頼電文であることを示すシステム共通で定めた識別子を更新する。依頼元システムＩＤフィールドには自クライアントＩＤを更新する。
【００２６】
作成したサーバ負荷情報送信依頼電文はサーバグループ内負荷管理装置３０１のサーバ受信キュー負荷情報応答部３０へ送信する。
サーバ受信キュー負荷情報応答部３０からは図２３に示したサーバ負荷情報応答電文形式２３０１に従ったサーバ負荷情報応答電文が返却される。
【００２７】
サーバ負荷情報応答電文にはサーバグループ４０１に属したサーバシステム毎のサーバ受信キューのメッセージ数と業務アプリケーションのステータス情報が埋め込まれている。クライアントメッセージ送信先判定部１３はこのサーバ負荷情報応答電文を受け取るとサーバ負荷情報応答電文の先頭サーバシステムＩＤフィールドのシステムＩＤから最終サーバシステムＩＤフィールドのシステムＩＤまで順番に図２７に示した送信先判定テーブル形式２７０１の形式をもった送信先判定テーブル１４にサーバ負荷情報応答電文のサーバ受信キューメッセージ数フィールドと業務アプリケーションステータスフィールドの内容を更新する。なお、送信先判定テーブル１４のクライアント１０１内での保持方法は規定しない。ただし、クライアント１０１のシステム軽度を保つためにはメモリ上で保持することが望ましい。送信先判定テーブル１４の更新が完了するとクライアント１０１のシステム内固有に管理される送信先サーバ判定テーブル１４のデータ更新時刻を現在時刻に更新する。
【００２８】
クライアントメッセージ送信先判定部１３は次に送信先サーバ判定テーブル１４を使用して処理要求メッセージの送信先サーバシステムを選択する。処理要求メッセージの送信先サーバシステムの選択処理の手順については後述する。
【００２９】
クライアントメッセージ送信先判定部１３は処理要求メッセージの送信先サーバシステムの選択処理により送信先サーバシステムが選択できなかった場合は送信先サーバ判定テーブル１４のデータ更新時刻から更新間隔が経過するまで待ち、再びサーバ負荷情報送信依頼電文の作成処理に戻る。送信先サーバシステムが選択できた場合、クライアント送信キュー１２から処理要求メッセージを取得し、取得した処理要求メッセージの送信先サーバシステムＩＤフィールドに送信先サーバシステムの選択処理で選択した送信先サーバシステムのサーバシステムＩＤを更新する。そしてクライアントメッセージ送信部１８へ処理要求メッセージを通知し、送信指示する。クライアントメッセージ送信部１８による処理要求メッセージの送信処理が終わるとクライアントメッセージ送信部１８からの戻り値を判定し、送信成功が返却された場合は戻り値に付与されたメッセージ数と業務アプリケーションステータスを送信先サーバ判定テーブル１４の送信先サーバシステムのレコードに対して更新する。
【００３０】
またクライアントメッセージ送信部１８から送信失敗が返却された場合は該当サーバシステムが送信先サーバシステムとして選択されないように送信先サーバ判定テーブル内の業務アプリケーションステータスフィールドを「停止中」に変更する。その後、クライアントメッセージ送信先判定部１３はクライアント受信キュー１２のメッセージ監視処理に戻り、これら一連の処理を繰り返す。
クライアントメッセージ送信先判定部１３の送信先サーバシステムの選択処理は図５に示すフローチャート１０５０１に従って実行する。まず送信先サーバ判定テーブル１４の全てのレコードを参照し、業務アプリケーションステータスフィールドが「起動中」のサーバシステムＩＤを抽出する。ここでもし、「起動中」のサーバシステム２０１が一つも存在しない場合は選択可能なサーバシステム２０１がないものと判断し、「選択可能なサーバシステムなし」を返却する。
【００３１】
起動中のサーバシステム２０１が１つしかないときはそのサーバシステムが送信先サーバシステムとして選択されることになり、そのサーバシステムのサーバシステムＩＤを返却する。また、起動中のサーバシステム２０１が複数あるときはサーバ受信キューメッセージ数が最も少ないサーバシステム２０１を選択し、そのサーバシステム２０１のサーバシステムＩＤを返却する。また、サーバ受信キューメッセージ数については、他に比べて少ないものでもある程度の効果は期待できる。
【００３２】
ここでもし、サーバ受信キューメッセージ数が同一のサーバシステム２０１が複数存在した場合は、そのうちでどのサーバシステム２０１を選択しても良いものとする。例えばシステムＩＤの小さい方を優先的に選択することで一つのサーバシステム２０１を特定できる。
【００３３】
クライアントメッセージ送信部１８はクライアントメッセージ送信先判定部１３が選択したサーバシステム２０１へ処理要求メッセージを送信する。クライアントメッセージ送信部１８は図６に示したフローチャート１０６０１に従って実行される。
【００３４】
クライアントメッセージ送信部１８は送信指示を受け付けると図２４に示したメッセージ送信電文形式２４０１に従うメッセージ送信電文を作成する。メッセージ送信電文の電文種別フィールドには本電文がメッセージ送信電文であることを示すシステム共通で定めた識別子を更新する。依頼元システムＩＤフィールドには自クライアントＩＤを格納する。メッセージフィールドにはクライアントメッセージ送信先判定部１３より受け取った処理要求メッセージを更新する。そして処理要求メッセージの送信先サーバシステムＩＤフィールドを参照し、そのサーバシステム２０１のサーバメッセージ受信部２８に向けてメッセージ送信電文を送信する。
【００３５】
その後送信先のサーバシステムから図２５に示したメッセージ送信応答電文形式２５０１に従うメッセージ送信応答電文が返るのを待つ。ここでもし、システムで定義した応答タイムアウト間隔内にメッセージ送信応答電文が返らないとき、送信先サーバシステムは停止しているものと判断し、クライアント送信キューに処理要求メッセージを戻し、送信失敗を返却する。送信先のサーバシステム２０１からメッセージ送信応答電文が返るとメッセージ送信応答電文の応答結果フィールドを参照し、応答結果が送信成功のときサーバ受信キューメッセージ数フィールドと業務アプリケーションステータスフィールドの値を戻り値に付与し、送信成功を返却する。応答結果が送信失敗の場合はクライアント送信キュー１５に処理要求メッセージを戻し、送信失敗を返却する。
【００３６】
クライアントメッセージ送信部１８が送信するメッセージ送信電文はサーバメッセージ受信部２８が受信する。サーバメッセージ受信部２８は図１１に示したフローチャート１１１０１に従って実行する。サーバメッセージ受信部２８はメッセージ送信電文を受け取るとまず、サーバシステム内で保持している業務アプリケーションステータスを参照する。この業務アプリケーションステータスはサーバシステム内の業務アプリケーションが「起動中」か「停止中」かを表わす情報で例えば共用メモリ領域などで管理されたサーバシステム２０１内の機能間で参照および更新ができる共通情報である。
【００３７】
業務アプリケーションステータスが「起動中」のときメッセージ送信電文から処理要求メッセージを取り出し、サーバ受信キュー２０に格納する。そしてサーバ受信キュー２０の現在のメッセージ数を参照する。その後、メッセージ送信応答電文を作成する。メッセージ送信応答電文の電文種別フィールドには本電文がメッセージ送信応答電文であることを示すシステム共通で定めた識別子を更新する。サーバ受信キューメッセージ数フィールドには参照したサーバ受信キュー２０の現在のメッセージ数を更新する。業務アプリケーションフィールドには現在の業務アプリケーションステータスを更新する。応答結果フィールドは送信成功に更新する。 そして作成したメッセージ送信応答電文をメッセージ送信電文の依頼元システムＩＤフィールドに格納されている依頼元システムに向けて送信する。業務アプリケーションステータスが「停止中」のときは同様にメッセージ送信応答電文を作成するが、電文種別フィールドを更新した後、応答結果フィールドには送信失敗を更新する。サーバ受信キューメッセージ数フィールドと業務アプリケーションステータスフィールドは更新する必要はない。作成したメッセージ送信応答電文は同様の手順で依頼元システムに送信する。
【００３８】
サーバシステム２０１の受信キュー２０はサーバ受信キュー状態管理部２５により監視される。サーバ受信キュー状態管理部２５は図１２に示したフローチャート１１２０１に従って実行する。サーバ受信キュー状態管理部２５はサーバシステム内であらかじめ定義したサーバ受信キュー監視間隔毎または業務アプリケーション状態監視部からの受信キューの状態報告指示により、図２１に示したサーバ受信キュー状態報告電文形式２１０１に従うサーバ受信キュー状態報告電文を作成する。サーバ受信キュー状態報告電文の電文種別フィールドには本電文がサーバ受信キュー状態報告電文であることを示すシステム共通で定めた識別子を更新する。サーバシステムＩＤフィールドには自サーバシステムＩＤを更新する。サーバ受信キューメッセージ数フィールドにはサーバ受信キュー２０から現在の処理要求メッセージ数を取得し、更新する。
【００３９】
さらに業務アプリケーションステータスフィールドにサーバシステム内で管理する業務アプリケーションステータスを更新する。作成したサーバ受信キュー状態報告電文はサーバグループ内負荷管理装置３０１のサーバ受信キュー負荷状態更新部３１に通知する。
【００４０】
サーバ受信キュー負荷状態更新部３１は図１８のフローチャート１１８０１に従って実行する。サーバ受信キュー負荷管理状態更新部３１はサーバ受信キュー状態報告電文を受け取るとサーバ受信キュー管理テーブル３２を更新する。サーバ受信キュー管理テーブル３２は図２６に示したサーバ受信キュー管理テーブル形式２６０１の形式をもつ。サーバ受信キュー管理テーブル３２はサーバグループ４０１内のサーバシステム２０１それぞれのサーバ受信キュー２０に格納されたメッセージ数と業務アプリケーション２１が「起動中」であるか「停止中」であるかを示すステータス各レコードの更新時刻を管理情報として保持する。なおサーバグループ内負荷管理装置３０１でのサーバ受信キュー管理テーブル３２の保持方法は規定しない。しかし、本テーブルの各サーバシステムのレコード情報は最新の管理情報が逐次更新されるのでデータベース管理システムを使用することが望ましい。
【００４１】
サーバ受信キュー負荷状態更新部３１はサーバ受信キュー状態報告電文よりサーバシステムＩＤフィールドとサーバ受信キューメッセージ数フィールドおよび業務アプリケーションステータスフィールドを参照し、サーバ受信キュー管理テーブル３２のサーバシステムＩＤが合致するレコードに対してサーバ受信キューメッセージ数フィールドと業務アプリケーションステータスフィールドに更新する。さらに同レコードの更新時刻フィールドは現在時刻で更新する。
【００４２】
また、サーバ受信キュー負荷管理状態更新部３１では、各サーバシステム２０１からサーバ受信キュー状態報告電文が定期的に送られているかを監視している。サーバグループ内負荷管理装置３０１であらかじめ定義されたサーバ受信キュー管理テーブル更新監視間隔毎にサーバ受信キュー管理テーブル３２の全レコードの更新時刻フィールドをチェックし、サーバ受信キュー管理テーブル更新監視間隔内に更新されていないレコードに該当するサーバシステム２０１は停止していると判断し、該当レコードの業務アプリケーションステータスフィールドを「停止中」に更新する。
【００４３】
クライアント１０１やサーバシステム２０１からのサーバ受信キュー管理テーブル３２への参照はサーバグループ内負荷管理装置３０１のサーバ受信キュー負荷状態応答部３０が応答する。サーバ受信キュー負荷状態応答部３０は図１７に示したフローチャート１１７０１に従って実行される。サーバ受信キュー負荷状態応答部３０ではクライアント１０１またはサーバシステム２０１から送られるサーバ負荷情報送信依頼電文を受け取るとサーバ受信キュー管理テーブル３２より全サーバシステム２０１のレコードを参照し、サーバ負荷情報応答電文を作成する。
【００４４】
サーバ負荷情報応答電文の電文種別フィールドには本電文がサーバ負荷情報応答電文であることを示すシステム共通で定めた識別子を格納し、先頭サーバシステムＩＤフィールドにはサーバ受信キュー管理テーブル３２の先頭レコードのシステムＩＤ、最終サーバシステムＩＤフィールドに最終レコードのシステムＩＤを格納する。そしてサーバシステムＩＤフィールド、サーバ受信キューメッセージ数フィールドおよび業務アプリケーションステータスフィールドにはサーバ受信キュー管理テーブルの先頭レコードから最終レコードまでレコード順にフィールドに対応して格納する。作成したサーバ負荷情報応答電文はサーバ負荷情報送信依頼電文の依頼元システムＩＤフィールドを参照し、依頼元システムに向けて送信する。
【００４５】
一方、サーバシステム２０１の受信キュー２０に格納された処理要求メッセージは業務アプリケーション２１によって監視される。業務アプリケーション２１は図１５に示したフローチャート１１５０１に従って実行する。業務アプリケーション２１は起動時に業務アプリケーションステータスを「起動中」に更新する。起動後はユーザからの停止要求があるまで常時、サーバ受信キュー２０を参照し、処理要求メッセージの到着を監視する。サーバ受信キュー２０に処理要求メッセージがあったとき業務アプリケーション２１はサーバ受信キュー２０から処理要求メッセージを取得する。
【００４６】
ただし、サーバ受信キュー内の処理要求メッセージは他サーバシステム２０１から転送されてくる場合があるため、サーバ受信キュー２０に格納された順序が必ずしも処理要求メッセージの生成時刻が古いものから順番になっているとは限らない。このため、メッセージの取得手順はメッセージ先入れ先出し方式ではなく処理要求メッセージのメッセージ生成時刻フィールドが最も古いものを優先して取得する。
【００４７】
業務アプリケーション２１は取得した処理要求メッセージの処理要求内容フィールドを参照し、業務データベース２２などを利用し、処理要求内容に応じたユーザアプリケーションを実行することで要求元のクライアント１０１への処理結果を得る。業務アプリケーション２１は次に図２０に示した処理結果メッセージ形式２００１に従う処理結果メッセージを作成する。処理結果メッセージのメッセージ種別フィールドには本メッセージが処理結果メッセージであることを示すシステム共通で定めた識別子を更新する。要求元クライアントＩＤフィールドには処理要求メッセージに格納されていた要求元クライアントＩＤを更新する。
【００４８】
さらに処理結果フィールドにはユーザアプリケーションによって得た処理結果を格納する。作成した処理結果メッセージはサーバ送信キュー２３に格納する。業務アプリケーション２１はユーザアプリケーションを実行する度に業務アプリケーションステータスを「起動中」に更新する。これはユーザアプリケーションがその処理内容によって、特異的に処理が遅延した場合を考慮しており、もし業務アプリケーション状態監視部２６が後述のアプリケーション実行監視処理により業務アプリケーションステータスを「停止中」に更新しても業務アプリケーション２１が処理を継続している場合には業務アプリケーションステータスを「起動中」に戻すことができるためである。
【００４９】
業務アプリケーション２１は停止時に業務アプリケーションステータスを「停止中」に変更する。
【００５０】
業務アプリケーション２１が変更する業務アプリケーションステータスは業務アプリケーション状態監視部２６が監視する。業務アプリケーション状態監視部２６は図１３のフローチャート１１３０１に従って実行する。業務アプリケーション状態監視部２６は業務アプリケーションステータスが「停止中」から「起動中」に状態が変わるとサーバ受信キュー状態管理部２５へサーバ受信キューの状態報告を指示する。業務アプリケーション状態監視部２６は業務アプリケーションステータスが「起動中」になると今度は「停止中」に変更されていないかを随時チェックする。また起動中の間はサーバ受信キュー２０に格納された処理要求メッセージが正常に処理されているか業務アプリケーション２１の状態監視処理をする。業務アプリケーション状態監視手順は以下通りである。
【００５１】
まず、サーバ受信キュー２０に処理要求メッセージが格納されているかどうかチェックし、処理要求メッセージが格納されている時、業務アプリケーション２１が次に処理する先頭の処理要求メッセージを参照し、そのメッセージＩＤを記憶する。その後、サーバシステム２０１内であらかじめ定義したアプリケーション実行監視間隔の時間待つ。ただし、この間も業務アプリケーションステータスが「停止中」に変更されないかは繰り返しチェックする。アプリケーション実行監視間隔が経過すると再度サーバ受信キューに処理要求メッセージをチェックする。もしサーバ受信キューにメッセージがない場合、または業務アプリケーション２１が次に処理する先頭の処理要求メッセージのメッセージＩＤが前記で記憶中したメッセージＩＤと異なる場合は処理要求メッセージが正常に動作していると判断し、監視処理を継続する。
【００５２】
しかし、前記のメッセージＩＤが記憶中のメッセージＩＤと異なる場合は業務アプリケーションが障害などの理由で業務アプリケーションステータスを変更せずにダウンしていると判断し、システム内の業務アプリケーションステータスを「停止中」に変更する。業務アプリケーション２１からのステータス変更または業務アプリケーション状態監視部２６によるステータス変更により、業務アプリケーションステータスが「停止中」になるとサーバ受信キュー状態管理部２５にサーバ受信キューの状態報告を指示する。さらにサーバ受信キュー２０に処理要求メッセージが存在するときこれらの処理要求メッセージを他のサーバシステム２０１へ転送する。
【００５３】
業務アプリケーション状態監視部２６の転送処理は図１４に示したフローチャート１１４０１に従って実行する。業務アプリケーション状態監視部２６はサーバ負荷情報送信依頼電文を作成し、サーバグループ内負荷管理装置３０１のサーバ受信キュー負荷情報応答部３０へを送信する。このときサーバ負荷情報送信依頼電文の要求元システムＩＤフィールドには自サーバシステムＩＤを格納する。サーバ受信キュー負荷情報応答部３０からサーバ負荷情報応答電文を受け取るとサーバ負荷情報応答電文の先頭サーバシステムＩＤから最終サーバシステムＩＤまで順にサーバ受信キューメッセージ数と業務アプリケーションステータスの情報をもとに図２８に示した転送先判定テーブル形式２８０１に従う転送先判定テーブル２７を作成する。
【００５４】
転送先判定テーブル２７はクライアント１０１で保持する送信先判定テーブル１４と同形式であり、サーバ負荷情報応答電文からの更新もクライアント１０１の送信先判定テーブル１４と同様の手順で行うことができる。
【００５５】
ただし、転送先判定テーブル２７は転送先として自サーバシステムが選択されることがないようにあらかじめ自サーバシステムのレコードは作成しないようにする。なお、転送先判定テーブル２７の保持方法は規定しない。しかし、転送先判定テーブル２７は処理要求メッセージ転送時の一時的な情報を管理するためのテーブルであるためメモリ上することが望ましい。転送先判定テーブル２７の更新が完了すると、ここで業務アプリケーション２１が再起動されているかチェックする。業務アプリケーションステータスが「起動中」に変更されているとき、つまり再起動された場合には転送の必要がないため転送処理は中止する。
【００５６】
業務アプリケーションステータスが「停止中」のときクライアントでの送信先サーバシステムの選択手順と同様にフローチャート１０５０１に従って業務アプリケーションが起動中で最もサーバ受信キューのメッセージ数が少ない転送先サーバシステムを選択する。転送先サーバシステムが選択できなかった場合はサーバ負荷情報送信依頼電文の送信から繰り返す。また転送先サーバシステムが選択できた場合はサーバ受信キューから処理要求メッセージを取得し、送信先サーバシステムＩＤフィールドに選択した転送先サーバシステムＩＤを更新し、サーバメッセージ送信部２９に処理要求メッセージを通知し、送信指示する。
【００５７】
サーバメッセージ送信部２９の戻り値が送信成功のとき、戻り値に付与されたサーバ受信キューメッセージ数と業務アプリケーションステータスを転送先判定テーブル２７の転送先サーバシステムＩＤのレコードに更新する。また処理要求メッセージの送信失敗が返却されると同レコードの業務アプリケーションステータスを「停止中」に変更する。次に再度自サーバシステム内の処理要求メッセージを参照し、メッセージが存在する場合は業務アプリケーションステータスチェック処理に戻り、自サーバ受信キューのメッセージがなくなるか、業務アプリケーションのステータスが「起動中」になるまでこれを繰り返す。
【００５８】
サーバ送信キュー２３に格納された処理結果メッセージはサーバ送信キュー監視部２４により監視される。サーバ送信キュー監視部２４は図１６のフローチャート１１６０１に従って実行される。サーバ送信キュー２３に処理結果メッセージが格納されるとサーバ送信キュー監視部２４がこれを取り出し、取り出した処理結果メッセージをサーバメッセージ送信部２９に通知する。
【００５９】
サーバメッセージ送信部２９はサーバ送信キュー監視部２９からの処理結果メッセージのクライアント１０１への送信と業務アプリケーション状態監視部２６からの処理要求メッセージの他サーバシステム２０１への転送を行う。サーバメッセージ送信部２９は図１０に示したフローチャート１１００１に従って実行される。
【００６０】
サーバメッセージ送信部２９は送信指示を受け付けると通知されたメッセージのメッセージ種別フィールドを参照する。メッセージ種別が処理結果メッセージの場合、まずメッセージ送信電文を作成する。電文種別フィールドにはメッセージ送信電文を示す識別子を更新する。依頼元システムＩＤフィールドは自サーバシステムＩＤを更新する。メッセージフィールドにはサーバ送信キュー監視部２９から受け取った処理結果メッセージを更新する。次に処理結果メッセージの要求元クライアントＩＤフィールドを参照し、要求元のクライアント１０１のメッセージ受信部にメッセージ送信電文を送信する。その後送信先のクライアント１０１からのメッセージ送信応答電文が返るのを待つ。
【００６１】
ここでもし、システムで定義した応答タイムアウト間隔内にメッセージ送信応答電文が返らないとき、サーバ送信キュー２４に処理要求メッセージを戻し、送信失敗を返却する。
【００６２】
送信先のクライアント１０１からメッセージ送信応答電文が返るとメッセージ送信応答電文の応答結果フィールドを参照し、応答結果が送信成功のとき、送信成功を返却する。応答結果が送信失敗の場合はサーバ送信キュー２３に処理要求メッセージを戻し、送信失敗を返却する。
【００６３】
メッセージ種別が処理要求メッセージの場合、まずメッセージ送信電文を作成する。電文種別フィールドにはメッセージ送信電文を示す識別子を更新する。依頼元システムＩＤフィールドは自サーバシステムＩＤを更新する。メッセージフィールドには業務アプリケーション状態監視部２６から受け取った処理要求メッセージを更新する。次に処理要求メッセージの送信先サーバシステムＩＤフィールドを参照し、転送先のサーバシステム２０１のメッセージ受信部２８にメッセージ送信電文を送信する。その後転送先のサーバシステム２０１からのメッセージ送信応答電文が返るのを待つ。
【００６４】
ここでもし、システムで定義した応答タイムアウト間隔内にメッセージ送信応答電文が返らないとき、転送先サーバシステム２０１は停止しているものと判断し、サーバ受信キュー２０に処理要求メッセージを戻し、送信失敗を返却する。
【００６５】
転送先のサーバシステム２０１からメッセージ送信応答電文が返るとメッセージ送信応答電文の応答結果フィールドを参照し、応答結果が送信成功のときメッセージ送信応答電文のサーバ受信キューメッセージ数フィールドと業務アプリケーションステータスフィールドの値を戻り値に付与し、送信成功を返却する。応答結果が送信失敗の場合はサーバ受信キュー２０に処理要求メッセージを戻し、送信失敗を返却する。
【００６６】
クライアント１０１ではサーバシステム２０１が送信するメッセージ送信電文をクライアントメッセージ受信部１９が受信する。クライアントメッセージ受信部１９は図７に示したフローチャート１０７０１に従って実行する。クライアントメッセージ受信部１９ではサーバシステム２０１からのメッセージ送信電文を受け取るとメッセージ送信電文のメッセージフィールドから処理結果メッセージを取得し、クライアント受信キュー１５に格納する。その後、メッセージ送信応答電文を作成し、電文種別フィールドにメッセージ送信電文の識別子を更新し、さらに応答結果フィールドには送信成功を更新する。そしてメッセージ送信電文の依頼元システムＩＤフィールドに格納されたサーバシステム２０１にメッセージ送信応答電文を送信する。
【００６７】
クライアント１０１のクライアント受信キュー１５はクライアント処理結果メッセージ応答部１６により監視される。クライアント処理結果メッセージ応答部１６は図８に示したフローチャート１０８０１に従って実行する。クライアント処理結果メッセージ応答部１６はクライアント受信キュー１５に処理結果メッセージが格納されると処理結果メッセージを取得し、処理結果メッセージの処理結果フィールドの内容をクライアント結果表示アプリケーション１７に通知する。
【００６８】
クライアント結果表示アプリケーション１７は図９に示したフローチャート１０９０１に従って実行する。クライアント結果表示アプリケーション１７では例えばグラフィカルユーザインタフェースなど任意のユーザアプリケーションを介して処理結果をユーザに通知する。
【００６９】
サーバグループ内のサーバシステム間での業務アプリケーションの負荷を均等化することでサーバグループ内のシステムリソースを効率的に利用することができ、業務アプリケーションの実行待ちが少ないサーバを選択できる。さらに業務アプリケーションが異常停止した場合でも他のサーバシステムに転送することでサーバ処理要求メッセージの滞留を防ぐことができる。
【００７０】
【発明の効果】
本発明によれば、サーバシステム間の負荷のアンバランスの改善が可能となる
【図面の簡単な説明】
【図１】本システムの一実施例の概略構成図である。
【図２】実施例のクライアント処理要求アプリケーションの処理を示すフローチャートである。
【図３】実施例の実施例のクライアント処理要求メッセージ生成部の処理を示すフローチャートである。
【図４】実施例の実施例のクライアントメッセージ送信先判定部
の処理を示すフローチャートである。
【図５】実施例の実施例のクライアントメッセージ送信先判定部の送信先サーバシステム選択処理と業務アプリケーション状態監視部の転送先サーバシステム選択処理を示すフローチャートである。
【図６】実施例の実施例のクライアントメッセージ送信部の処理を示すフローチャートである。
【図７】実施例の実施例のクライアントメッセージ受信部の処理を示すフローチャートである。
【図８】実施例の実施例のクライアント処理結果メッセージ応答部の処理を示すフローチャートである。
【図９】実施例の実施例のクライアント結果表示アプリケーションの処理を示すフローチャートである。
【図１０】実施例の実施例のサーバメッセージ受信部の処理を示すフローチャートである。
【図１１】実施例の実施例のサーバメッセージ受信部の処理を示すフローチャートである。
【図１２】実施例の実施例のサーバ受信キュー状態管理部の処理を示すフローチャートである。
【図１３】実施例の実施例の業務アプリケーション状態監視部の監視処理を示すフローチャートである。
【図１４】実施例の実施例の業務アプリケーション状態監視部の転送処理を示すフローチャートである。
【図１５】実施例の実施例の業務アプリケーションの処理を示すフローチャートである。
【図１６】実施例の実施例のサーバ送信キュー監視部の処理を示すフローチャートである。
【図１７】実施例の実施例のサーバ受信キュー負荷状態応答部の処理を示すフローチャートである。
【図１８】実施例の実施例のサーバ受信キュー負荷状態更新部の処理を示すフローチャートである。
【図１９】実施例の処理要求メッセージの形式である。
【図２０】実施例の処理結果メッセージの形式である。
【図２１】実施例のサーバ受信キュー状態報告電文の形式である。
【図２２】実施例のサーバ負荷情報送信依頼電文の形式である。
【図２３】実施例のサーバ負荷情報応答電文の形式である。
【図２４】実施例のメッセージ送信電文の形式である。
【図２５】実施例のメッセージ送信応答電文の形式である。
【図２６】実施例のサーバ受信キュー管理テーブルの形式である。
【図２７】実施例の送信先サーバ判定テーブルの形式である。
【図２８】実施例の転送先サーバ判定テーブルの形式である。
【符号の説明】
１０１ クライアント
２０１ サーバシステム
３０１ サーバグループ内負荷管理装置
４０１ サーバグループ
１０ クライアント処理要求アプリケーション
１１ クライアント処理要求メッセージ生成部
１２ クライアント受信キュー
１３ クライアントメッセージ送信先判定部
１４ 送信先サーバ判定テーブル
１５ クライアント受信キュー
１６ クライアント処理結果メッセージ応答部
１７ クライアント結果表示アプリケーション
１８ クライアントメッセージ送信部
１９ クライアントメッセージ受信部
２０ サーバ受信キュー
２１ 業務アプリケーション
２２ 業務データベース
２３ サーバ送信キュー
２５ サーバ送信キュー監視部
２５ サーバ受信キュー状態管理部
２６ 業務アプリケーション状態監視部
２７ 転送先サーバ判定テーブル
２８ サーバメッセージ受信部
２９ サーバメッセージ送信部
３０ サーバ受信キュー負荷状態応答部
３１ 業務アプリケーション負荷状態更新部
３２ サーバ受信キュー管理テーブル
Claims (5)
- プログラムを実行できる複数のサーバで構成されるサーバグループと該サーバで実行するプログラムに対して非同期に処理要求を発行するプログラムを実行する複数のクライアントで構成される計算機システムにおけるメッセージ通信方法において、
前記サーバシステム内のプログラムが起動中で受信キューで待っている処理要求メッセージが最も少ないサーバを判定し、前記クライアントからの処理要求メッセージの送信先となる前記サーバを選択することを特徴とするメッセージ通信方法。 - 前記のサーバの前記の受信キューの処理要求メッセージが一定時間の取り出しがされないときやプログラムが停止したときに処理要求メッセージをサーバグループ内の他のサーバのうちでプログラムが起動中で受信キューで待っている処理要求メッセージが最も少ないサーバへ転送することを特徴とする請求項１記載のメッセージ通信方法。
- プログラムを実行できる複数の計算機を有する計算機システムと該計算機システムに対して処理要求を発行する端末とを有する計算機システムにおけるメッセージ通信方法において、 前記端末からの処理要求メッセージの送信先となる前記計算機を、各前記計算機の受信キューの状態で選択することを特徴とするメッセージ通信方法。
- プログラムを実行できる複数のサーバで構成されるサーバグループとサーバのプログラムに対して非同期に処理要求を発行するプログラムを実行する複数のクライアントとを備え、
前記クライアントからの処理要求メッセージの送信先となる前記サーバをサーバグループ内のプログラムが起動中で受信キューで待っている処理要求メッセージが最も少ないサーバを選択する手段とを備えたことを特徴とする計算機システム。 - 前記サーバの前記受信キューの処理要求メッセージが一定時間の取り出しがされないときやプログラムが停止したときに処理要求メッセージをサーバグループ内の他のサーバのうちでプログラムが起動中で受信キューで待っている処理要求メッセージが最も少ないサーバへ転送する手段とを備えたことを特徴とする請求項４記載の計算機システム。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2003189952A JP2005025481A (ja) | 2003-07-02 | 2003-07-02 | メッセージ通信方法およびその実施計算機システム |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2003189952A JP2005025481A (ja) | 2003-07-02 | 2003-07-02 | メッセージ通信方法およびその実施計算機システム |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| JP2005025481A true JP2005025481A (ja) | 2005-01-27 |
Family
ID=34187970
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2003189952A Pending JP2005025481A (ja) | 2003-07-02 | 2003-07-02 | メッセージ通信方法およびその実施計算機システム |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP2005025481A (ja) |
Cited By (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2008140120A (ja) * | 2006-12-01 | 2008-06-19 | Fujitsu Ltd | 計算資源管理プログラム、計算資源管理装置および分散処理システム |
| JP2010244500A (ja) * | 2009-03-16 | 2010-10-28 | Nec Corp | 分散処理システムおよび分散処理方法 |
| JP2011512586A (ja) * | 2008-02-14 | 2011-04-21 | インターナショナル・ビジネス・マシーンズ・コーポレーション | 入出力動作を監視するための装置、方法、およびコンピュータ・プログラム |
| CN114531721A (zh) * | 2022-01-28 | 2022-05-24 | 新华三技术有限公司 | 一种建立隧道、报文的处理的方法和ac |
-
2003
- 2003-07-02 JP JP2003189952A patent/JP2005025481A/ja active Pending
Cited By (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2008140120A (ja) * | 2006-12-01 | 2008-06-19 | Fujitsu Ltd | 計算資源管理プログラム、計算資源管理装置および分散処理システム |
| JP4606404B2 (ja) * | 2006-12-01 | 2011-01-05 | 富士通株式会社 | 計算資源管理プログラムおよび計算資源管理装置 |
| JP2011512586A (ja) * | 2008-02-14 | 2011-04-21 | インターナショナル・ビジネス・マシーンズ・コーポレーション | 入出力動作を監視するための装置、方法、およびコンピュータ・プログラム |
| JP2010244500A (ja) * | 2009-03-16 | 2010-10-28 | Nec Corp | 分散処理システムおよび分散処理方法 |
| CN114531721A (zh) * | 2022-01-28 | 2022-05-24 | 新华三技术有限公司 | 一种建立隧道、报文的处理的方法和ac |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| EP3490224B1 (en) | Data synchronization method and system | |
| CN107947960B (zh) | 配置信息的推送方法及系统、配置信息的接收方法及系统 | |
| CN103581276B (zh) | 集群管理装置、系统、业务客户端及相应方法 | |
| US7870425B2 (en) | De-centralized nodal failover handling | |
| CN105338086A (zh) | 一种分布式的消息转发方法 | |
| CN109783151B (zh) | 规则变更的方法和装置 | |
| CN106462593B (zh) | 大规模并行处理数据库的系统和方法 | |
| CN112333249B (zh) | 一种业务服务系统及方法 | |
| US20130204926A1 (en) | Information processing system, information processing device, client terminal, and computer readable medium | |
| US9736235B2 (en) | Computer system, computer, and load balancing method | |
| US8606908B2 (en) | Wake-up server | |
| WO2006131440A1 (en) | Apparatus, system, and method for facilitating communication between an enterprise information system and a client | |
| US20050210152A1 (en) | Providing availability information using a distributed cache arrangement and updating the caches using peer-to-peer synchronization strategies | |
| US7424712B1 (en) | System and method for controlling co-scheduling of processes of parallel program | |
| JP5408620B2 (ja) | データ分散管理システム及びデータ分散管理方法 | |
| US8201017B2 (en) | Method for queuing message and program recording medium thereof | |
| JP2005025481A (ja) | メッセージ通信方法およびその実施計算機システム | |
| CN108984290A (zh) | 任务调度方法和系统 | |
| US8863149B2 (en) | Message processing apparatus and message processing method | |
| JP2009515474A (ja) | 独立したメッセージストアおよびメッセージトランスポートエージェント | |
| EP3687133B1 (en) | System and method for synchronization of media objects between devices operating in a multiroom system | |
| CN110933150A (zh) | 数据同步方法、系统、装置、电子设备及计算机存储介质 | |
| CN114924861A (zh) | 一种分布式任务处理方法及系统 | |
| CN114500416A (zh) | 用于最多一次消息投递的投递方法和投递系统 | |
| CN116662040B (zh) | 一种消息的分发方法、装置、电子设备及存储介质 |