JP2010146261A - 提供元報知装置及び提供元報知方法 - Google Patents

Abstract

【課題】各サーバーの負荷を分散し、サーバー資源を有効に活用することが可能な提供元報知装置を提供する。
【解決手段】アプリケーションのサービスの提供元情報を取得する提供元情報取得部と、アプリケーションのサービスを端末に現在提供している提供状況の情報を取得する提供状況取得部と、アプリケーションと、アプリケーションのサービスを端末に提供することを予約された予約情報を取得する予約情報取得部と、提供元情報から求めた前記提供元に実際になった場合のサーバーの負荷状況、アプリケーションの提供状況の情報から求めた現在のサーバーの負荷状況、及び、予約情報から求めた所定期間のサーバーの負荷状況を基に、前記サーバー群の中で、予め定めた条件を満たしたサーバーを選定する判断処理部と、を有する。
【選択図】図１

Description

この発明は、複数のアプリケーションのサービスの提供元となり得るサーバー群と、複数のアプリケーションのサービスの提供先となり得る端末群とにネットワークを介して接続された提供元報知装置及び提供元報知方法に関する。ここで、アプリケーションとは、例えば、被検体の検出データである原画像を基に、原画像から派生する画像を含む画像データを生成するソフトウェアである。また、アプリケーションのサービスとは、端末からの要求を受けて、サーバーがアプリケーションの実行をすることにより、原画像から画像データを生成し、生成された画像データを端末に提供する役務をいう。

従来の技術（例えば、特許文献１）としては、ネットワークを介して接続された複数のクライアント端末に、アプリケーションサーバーに収蔵されたアプリケーションのサービスを提供するシステムがある。
また、従来の技術（例えば、特許文献２）としては、アプリケーション仲介サーバー同士が連携していて、いずれかのアプリケーション仲介サーバーがデータセットへの要求を受けると、他のアプリケーション仲介サーバーのデータベースに記憶されたデータセットを収集し、データセットを特定し、特定されたデータセットに要求を振り分ける技術が開示されている。そのため、利用者がデータセットの所在地を考慮せずに、データを収集することが可能となる利点がある。

特開２００８−１５６５８号公報 特開２００４−１０２９２２号公報

しかしながら、上記特許文献１に記載された技術では、アプリケーションサーバーの提供状況を動的に知る術が存在しない。そのため、例えば、アプリケーションのサービスの提供元（以下、単に提供元という。）であるサーバーに対し、端末から接続要求をする時に、接続要求時のサーバーの現在の負荷、提供元となることを予約された場合のサーバーの予約負荷、及び、仮に提供元になった場合のサーバーの予想負荷、等を考慮した上での接続要求を出すことは現実的に難しい。

加えて、アプリケーションサーバーが追加（増強）されても、追加されたアプリケーションサーバーが何のアプリケーションのサービスを提供しているのかを動的に知る術がない。そのため、基本的には、前回と同じアプリケーションサーバーに、前回と同じアプリケーションのサービスの提供を要求するのが一般的であった。

さらに、アプリケーションサーバーが、画像収集処理等の緊急処理を必要とした場合に、端末に対しアプリケーションのサービス提供中であっても、緊急処理を優先するため、端末とサーバー側との接続を強制的に切断することで、また、切断せずに、アプリケーションのサービスの提供が継続可能であっても、アプリケーションの処理に使われるＣＰＵ時間を限りなく０に近づけることで、端末にとって利用に耐えない状況をサーバーが作り出していた。

近年、モダリティの処理能力の向上や各種容量の向上によって、モダリティ自身がアプリケーションサーバーとなることも容易となったが、モダリティの主目的は医用画像の収集にあるため、医用アプリケーションのサービスの提供よりも医用画像の収集が最優先されるため、サービス提供中に医用画像の収集が必要となると、サービス提供中のアプリケーションサービスを緊急に中止しなければならない問題を抱えている。

また、前述のように、前回と同じアプリケーションサーバーに、前回と同じアプリケーションのサービスの提供を要求することが一般的となっている状況下では、アプリケーションサーバーの負荷分散が考慮されないため、提供元が一部のサーバーに偏ってしまい、提供元となったサーバーが過負荷になる。その結果、アプリケーションの処理性能低下を招き、また、端末からアプリケーションのサービスの提供要求をしても、要求が拒絶される場合があった。

昨今、技術革新により安価なアプリケーションサーバーを複数構築し、同一のアプリケーションのサービスの提供をするサーバーが複数存在している。このような状況においても、アプリケーションサーバーが何のアプリケーションのサービスを提供しているのかを動的に知る術がないため、提供元が一部のサーバーに偏ってしまっている。

また、上記特許文献２に記載された技術を利用すれば、いずれのアプリケーション仲介サーバーであっても、他のアプリケーション仲介サーバーが何のアプリケーションのサービスを提供しているのかを動的に知ることが可能である。

しかし、いずれのアプリケーション仲介サーバーであっても、他のアプリケーション仲介サーバーの負荷状況を考慮した上で、他のアプリケーション仲介サーバーに振り分けてはいないため、例えば、高負荷や過負荷の状況にある他のアプリケーション仲介サーバーに振り分けた場合、端末（利用者）にとって利用に耐えない状況となるという問題点があった。

この発明は、上記の問題を解決するものであり、アプリケーションのサービスの提供元となる各サーバーの負荷を分散し、各サーバーの資源を有効に活用することを可能とした提供元報知装置及び提供元報知方法を提供することを目的とする。

また、データを生成途中のサーバーから新たなサーバーに切り換える場合、生成途中のデータを、新たなサーバーが読み出すことにより、データを重複して生成せずに済み、処理効率の高い、使い易い提供元報知装置及び提供元報知方法を提供することを目的とする。

上記課題を解決するため、この発明は、端末とサーバーとの接続を仲介するプロバイダを使用し、プロバイダがサーバーの負荷を管理することで、各サーバーの負荷を分散することが可能となることに着目した。
具体的に、この発明の第１の形態は、複数のアプリケーションのサービスの提供元となり得るサーバー群と、複数のアプリケーションのサービスの提供先となり得る端末群とにネットワークを介して接続された提供元報知装置であって、アプリケーションと、該アプリケーションのサービスの提供元となり得るサーバー群とを対応付けた提供元情報を取得する提供元情報取得部と、アプリケーションと、該アプリケーションのサービスを端末に現在提供している提供元とを対応付けた提供状況の情報を前記サーバーから取得する提供状況取得部と、アプリケーションと、該アプリケーションのサービスを端末に提供することを予約された提供元と、該予約された時間とを対応付けた予約情報を取得する予約情報取得部と、前記各端末からアプリケーションのサービスの提供要求を受信する要求受信部と、前記サービスの提供要求をした前記各端末に該サービスの提供元を報知する接続管理部と、前記サービスの提供要求を受けて、前記提供元情報から求めた前記提供元に実際になった場合のサーバーの負荷状況、前記アプリケーションの提供状況の情報から求めた現在のサーバーの負荷状況、及び、前記予約情報から求めた所定期間のサーバーの負荷状況を基に、前記サーバー群の中で、予め定めた条件を満たしたサーバーを選定し、前記選定されたサーバーの情報を前記接続管理部に送る判断処理部と、を有することを特徴とする提供元報知装置である。
また、この発明の第７の形態は、複数のアプリケーションのサービスの提供元となり得るサーバー群と、複数のアプリケーションのサービスの提供先となり得る端末群とにネットワークを介して接続された提供元報知方法であって、アプリケーションと、該アプリケーションのサービスの提供元となり得るサーバー群とを対応付けた提供元情報を取得する提供元情報取得ステップと、アプリケーションと、該アプリケーションのサービスを端末に現在提供している提供元とを対応付けた提供状況の情報を前記サーバーから取得する提供状況管理ステップと、アプリケーションと、該アプリケーションのサービスを端末に提供することを予約された提供元と、該予約された時間とを対応付けた予約情報を取得する予約情報取得ステップと、前記各端末からアプリケーションのサービスの提供要求を要求受信部が受信する受信ステップと、前記サービスの提供要求を受けて、判断処理部が、前記提供元情報から提供元に実際になった場合のサーバーの予想負荷を求めるステップと、さらに、前記判断処理部が、前記提供状況の情報からサーバーの現在の負荷を求めるステップと、さらに、前記判断処理部が、前記予約情報から所定期間のサーバーの予約負荷を求めるステップと、さらに、前記判断処理部が、前記予想負荷、前記現在の負荷、及び、前記予約負荷を加算して総負荷を求めるステップと、さらに、前記判断処理部が、前記サーバー群の中で、前記総負荷が最小となるサーバーを選定する判断処理ステップと、前記接続管理部が、前記選定されたサーバーを前記端末に報知するステップと、を有することを特徴とする提供元報知方法である。

この発明の第１、及び第６の形態によると、アプリケーションのサービスの提供要求をした端末に対し、提供元の情報を報知するので、端末の利用者としては、接続先サーバー毎の負荷や提供されるサービス等を意識せずに済むため、容易に安定したサービスの提供を受けることが可能となる。また、サービスの提供元となり得るサーバー側にとっても、デフォルト接続先の固定による偏りが無くなることで、各サーバーへの負荷が分散され、有限であるコンピュータ資源が有効に活用されることが期待できる。

［第１の実施の形態］
（構成）
この発明の第１の実施形態に係る提供元報知装置の構成について図１から図５を参照して説明する。図１は、提供元報知装置の機能ブロック図である。図２は、各種管理情報の例を示す説明図、図３は、管理情報収集時のシーケンスチャートである。

複数のアプリケーションのサービスの提供元となり得るサーバー群と、複数のアプリケーションのサービスの提供先となり得る端末群と、提供元報知装置とがネットワークにそれぞれ接続されている。サーバー群、端末群、及び、提供元報知装置１０を含む医用アプリケーションプロバイダを図１に示す。

医用アプリケーション提供システムでは、端末からの医用アプリケーションのサービスの提供要求を受信した要求受信部１１が、接続管理部１２に接続管理を要求し、接続管理部１２は、処理判断部１３に対し提供元の選定を要求する。処理判断部１３は、提供元の選定要求を受付けたのち、管理情報管理手段１４が管理している管理情報を基に提供元となるサーバーを選定し、選定された提供元の情報を端末に返すことで、選定された提供元のサーバーと端末間の接続を仲介する。

サーバー選定の基準となる３つの管理情報を次に説明する。第１の管理情報は、アプリケーションと、アプリケーションのサービスの提供元となり得るサーバー群とを対応付けた提供元情報である。第２の管理情報は、アプリケーションと、アプリケーションのサービスを端末に現在提供している提供元とを対応付けた提供状況の情報である。第３の管理情報は、アプリケーションと、アプリケーションのサービスを端末に提供することを予約された提供元と、予約された時間とを対応付けた予約情報である。

次に、第１の管理情報である提供元情報を取得する提供アプリ等情報取得部１５、第２の管理情報である提供状況の情報を取得する提供状況取得部１６、及び、予約情報を取得する予約情報取得部１７について、図２及び図３を参照にして説明する。

先ず、提供アプリ等情報取得部１５について説明する。提供アプリ等情報取得部１５は、システム構築時やシステム起動時等に各サーバーから提供元情報を取得し、この提供元情報を基に、サーバーと、端末に提供可能なアプリケーションである提供アプリケーションと、アプリケーションのサービスを提供した場合のサーバーの平均負荷と、同時接続可能な端末の数である同時接続許可数とを対応付けた提供アプリ一覧（第１の管理情報）を作成する。提供アプリ等情報取得部１５は、提供アプリ一覧を管理情報管理手段１４に記憶させる。

提供アプリ一覧の一例を図２に示す。サーバー数の分だけ繰り返し、提供アプリ一覧を作成し、作成した情報を管理情報管理手段１４に記憶させる提供アプリ等情報取得部１５を図３に示す。

提供状況取得部１６は、サーバーからの接続処理完了通知や稼働中に一定時間間隔で提供状況の情報を取得し、提供状況の情報（動的情報）を基に、サーバーと、サーバーがサービスを提供しているアプリケーションと、アプリケーションのサービスの提供を受けている端末と、サービス提供中のサーバーの負荷状況とを対応付けた提供状況一覧（第２の管理情報）を作成する。提供状況取得部１６は、提供状況一覧を管理情報管理手段１４に記憶させる。

提供状況一覧の一例を図２に示す。サーバー数の分だけ繰り返し、提供状況一覧を作成し、作成した情報を管理情報管理手段１４に記憶させる提供状況取得部１６を図３に示す。

予約情報取得部１７は、システム起動時や稼働中の一定時間間隔で予約情報管理部１８から予約情報を取得し、この予約情報を基に、予約をした端末である使用端末と、予約されたアプリケーションである予約アプリと、予約時間と、アプリケーションのサービスの提供を受ける利用者と、予約されたサーバーである仮選定サーバーとを対応付けた予約情報一覧（第３の管理情報）を作成する。予約情報取得部１７は、予約情報一覧を管理情報管理手段１４に記憶させる。

予約情報一覧の一例を図２に示す。予約情報を取得し、予約情報一覧を作成し、管理情報管理手段１４に記憶させる予約情報取得部１７を図３に示す。なお、提供アプリ一覧、提供状況一覧、及び、予約情報一覧が記憶された管理情報管理手段１４を提供元報知装置１０にネットワークを介して接続させても良い。

（動作）
次に、端末がアプリケーションのサービスの提供を要求してから、サービスの提供元となるサーバーの情報を端末に通知するまでの処理の流れについて、図４を参照にして説明する。図４は、医用アプリケーションサービスの提供要求時のシーケンスチャートである。

先ず、端末Ｘが、アプリケーションのサービスの提供要求を要求受信部１１に送信する。次に、要求受信部１１が接続管理部１２に提供元要求を送る。次に、接続管理部１２は、処理判断部１３に提供元選定要求をする。

処理判断部１３は、管理情報管理手段１４に、第１から第３の管理情報である提供元情報、提供状況の情報、及び、予約情報の取得要求をし、第１から第３の管理情報を取得する。

処理判断部１３は、第１から第３の管理情報を基に、予め定められた条件を満たした提供元となるサーバーを選定し、選定された提供元の情報を接続管理部１２に送る。ここで、予め定められた条件とは、例えば、選定された場合のサーバーの負荷状態が所定範囲（例えば、７０％）内であることをいう。処理判断部１３は、サーバー群の中から予め定められた順番で、サーバーが予め定められた条件を満たしているか否かを判断し、その条件を最初に満たしたサーバーを選定しても良く、その条件を満たしたサーバーの全てを選定し、その全てのサーバーを提供元の情報として、端末に報知するようにしても良い。なお、旧サーバー名、新サーバー名、アプリケーション名、選定の状態、画像データ識別情報、その他の情報を含む提供元の情報の一例を図５に接続先情報として示す。

接続管理部１２は、提供元となるサーバーを端末Ｘに報知する。次に、端末Ｘは、報知されたサーバーに接続する。接続されたサーバーは、提供状況取得部１６に接続通知を送る。次に、提供状況取得部１６は、提供状況の情報を管理情報管理手段１４に記憶させる。

なお、接続管理部１２は、次の順番で受け付けた提供元選定要求がある場合に、処理判断部１３に次の順番で受け付けた提供元選定要求をする。次の順番で受け付けた提供元選定要求がない場合、端末からの提供元選定要求の処理を終了する。一つの提供元選定要求の処理を終了した後に、次の提供元選定要求の処理に移るので、予め定められた条件を満たすサーバーを確実に選定することが可能となる。

［第２の実施の形態］
次に、この発明の第２の実施形態に係る提供元報知装置の一連の動作について、図６を参照にして説明する。図６は、サーバーを選定するときのフローチャートである。

第２の実施形態に係る提供元報知装置は、端末からアプリケーションのサービスの提供要求を受けると、サーバー群の中から、負荷状態が最小であるサーバーを選定するようにしたものである。

例えば、端末Ｘからアプリケーションのサービスの提供要求を受けると、要求受信部１１が接続管理部１２に提供元の選択要求をし、処理判断部１３が、提供アプリ一覧、提供状況一覧、及び、予約情報一覧の３つの管理情報を管理情報管理手段１４から取得する（ステップＳ１０１）。

次に、負荷算出ループ（ステップＳ１０２）に移る。負荷算出ループでは、処理判断部１３がサーバーを順番に指定し、指定したサーバーの負荷を算出する。負荷の算出をしたサーバーの数が、所定台数（例えば、提供元報知装置１０の管理下にあるサーバー群の全台数）に達すると負荷算出ループを終了する。

負荷算出ループでは、先ず、処理判断部１３は、要求されたサービスをサーバーが提供しているか否かを判断する（ステップＳ１０３）。要求されたサービスをサーバーが提供していない場合（ステップＳ１０３；Ｎ）、ステップＳ１０２に戻る。

要求されたサービスの提供をしている場合（ステップＳ１０３；Ｙ）、処理判断部１３は、管理情報管理手段１４から取得した提供アプリ一覧より該当する医用アプリケーション サービスを提供するサーバーと予想負荷を求める（ステップＳ１０４）。

次に、処理判断部１３は、管理情報管理手段１４から取得した提供状況一覧から得られる現在の負荷を求める（ステップＳ１０５）。さらに、処理判断部１３は、管理情報管理手段１４から取得した予約情報一覧から得られる予約負荷を求める（ステップＳ１０６）。

次に、処理判断部１３は、予想負荷、現在の負荷、及び、予約負荷を加算してサーバー負荷（総負荷）を算出する（ステップＳ１０７）。サーバー負荷（総負荷）は、次の（１）式により求められる。
サーバー負荷（総負荷）＝予想負荷＋現在の負荷＋予約負荷 …（１）
ここで、予約負荷は、予約情報を基に、予約負荷の算出時から所定時間内にサーバーが受ける予定の負荷をいう。所定時間の初期値は、例えば、１時間に設定される。なお、図外の操作部の入力を受けて、所定時間の初期値を変更するようにしても良い。

次に、予約情報一覧から予約負荷を求めるステップＳ１０６の詳細について、図７を参照にして説明する。図７は、予約負荷を求めるときのフローチャートである。

第２の実施形態に係る提供元報知装置１０は、処理判断部１３が予約情報一覧から予約負荷を求める場合、予約負荷算出ループに移る（ステップＳ２０１）。予約負荷算出ループでは、処理判断部１３が、予約台数分のサーバー（端末からアプリケーションのサービスの提供を予約されたサーバー）の中から順番に指定し、指定したサーバーの予約負荷を算出する。予約負荷の算出をしたサーバーの数が所定の予約台数（予約されたサーバーの全台数）に達すると予約負荷算出ループを終了する。

予約負荷算出ループでは、先ず、処理判断部１３は、ステップＳ２０１で指定したサーバーについて、予約時間が現時点から所定時間（例えば、１時間）内であるか否かを判断する（ステップＳ２０２）。予約時間が所定時間内でない場合（ステップＳ２０２：Ｎ）、ステップＳ２０１に戻る。

予定時間が所定時間内である場合（ステップＳ２０２；Ｙ）、処理判断部１３は、ステップＳ２０１で指定したサーバーが、仮選定サーバー（上記するステップＳ１０４、Ｓ１０５で予測負荷及び現在の負荷を求めたサーバーで）であるか否かを判断する（ステップＳ２０３）。指定したサーバーが仮選定サーバーでない場合（ステップＳ２０３；Ｎ）、ステップＳ２０１に戻る。

ステップＳ２０１で指定したサーバーが仮選定サーバーである場合（ステップＳ２０３；Ｙ）、処理判断部１３は、予約情報を基に予約負荷を取得する（ステップＳ２０４）。
以上のようにして、処理判断部１３は、所定の予約台数分だけ予約負荷の算出を繰り返す（ステップＳ２０１〜Ｓ２０５）。それにより、処理判断部１３は、所定の予約台数分のサーバーの中で、仮選定サーバーの予約負荷を取得する。また、予約負荷算出ループを抜け、予約負荷を求める一連の動作を終了する。

次に、上記のステップＳ１０７で、サーバー負荷（予想負荷、現在の負荷、及び、予約負荷を加算した総負荷）を求めた後の動作について、図６を参照にして説明する。

次に、処理判断部１３は、負荷の算出をしたサーバーが１台目であるかを判断する（ステップＳ１０８）。サーバーが１台目の場合（ステップＳ１０８；Ｙ）、処理判断部１３は、１台目のサーバーの負荷（総負荷）を、例えば内部メモリに基準負荷として記憶させる（ステップＳ１１２）。その後、処理判断部１３が、順番に従って、次のサーバーを指定するステップＳ１０２に戻る。

負荷の算出をしたサーバーが１台目でない場合（ステップＳ１０８；Ｎ）、処理判断部１３は、２台目以降のサーバー負荷が、基準負荷に満たないか否かを判断する（ステップＳ１０９）。２台目以降のサーバー負荷が、基準負荷以上である場合（ステップＳ１０９；Ｎ）、処理判断部１３が、順番に従って、次のサーバーを指定するステップＳ１０２に戻る。

２台目以降のサーバー負荷が、基準負荷に満たない場合（ステップＳ１０９；Ｙ）、処理判断部１３は、２台目以降のサーバー負荷を、基準負荷として記憶させる（ステップＳ１１０）。

以上のようにして、処理判断部１３は、所定台数分だけサーバー負荷の算出を繰り返す（ステップＳ１０１〜Ｓ１１１）。それにより、処理判断部１３は、所定台数のサーバーの中で、最小となるサーバー負荷を基準負荷として取得する。また、負荷算出ループを抜け、終了する。

負荷算出ループを抜けると、処理判断部１３は、最小のサーバー負荷（基準負荷）である提供元の情報（接続先サーバー）を決定し、接続管理部１２に送る。接続管理部１２は、提供元の情報を、アプリケーションのサービスの提供要求をした端末に報知する。

以上の提供元報知装置１０を設けたことにより、提供元報知装置１０の管理下にあるサーバー群の中で、負荷状態が最小のサーバーから順番に負荷が割り当てられていくので、一部のサーバーに負荷を集中させずに、サーバー負荷の平均化を図ることが可能となる。

［第３の実施の形態］
次に、この発明の第３の実施形態に係る提供元報知装置について、図８から図１１を参照にして説明する。図８は、提供元報知装置の機能ブロック図、図９は、緊急処理時のシーケンスチャート、図１０は、接続先切替情報の一例を示す図である。

第３の実施形態において、提供元報知装置がネットワークを介して接続されるサーバー群は、医用画像の収集をし、医用画像から派生した画像（例えば、中間画像又は二次画像）を含む画像データの生成をするモダリティ（医用画像撮影診断装置）を有する。モダリティは、医用画像の収集と、アプリケーションのサービスの提供とを選択的に切り替え可能に構成されている。

第３の実施形態に係る提供元報知装置は、緊急処理時のサーバーを新たなサーバーに切り替えるべく、新たなサーバーの情報を端末に報知するものである。

緊急処理時とは、例えば、モダリティをアプリケーションサーバーとして利用している場合や、定期メンテナンス等で一時的にアプリケーションサーバーを停止しなければならない場合において、端末群が当該サーバーから医用アプリケーションサービスの提供を受けている場合をいう。

以上のような緊急処理時、アプリケーションサーバーであるモダリティからの通知により、端末上での処理を一時中断、別のアプリケーションサーバーにて同処理を再開させることで、処理を継続させることが可能となる。

医用アプリケーションサービスを提供しているモダリティ（アプリケーションサーバー）上で、収集処理等の緊急処理が必要になると、モダリティは、提供元報知装置１０の提供状況取得部１６に対して緊急対応通知（サービスの提供を中断するための対応要求）を行う。

緊急対応通知を受けた提供状況取得部１６は、接続管理部１２に対して当該サーバーの緊急処理を要求し、それを受けた接続管理部１２は、処理判断部１３に対して接続先の選定を要求する。処理判断部１３は、上記した３つの管理情報である提供アプリ一覧、提供状況一覧、及び、予約情報一覧を基に、当該サーバーで現在提供されている医用アプリケーションサービスと同じサービスを端末に対し提供することとなる新たなサーバーを選定する。

この第３実施形態でのサーバーの選定方法が前記第１実施形態での選定方法と異なるのは、緊急対応が必要なサーバーが存在することを鑑み、残りのサーバーから選定を行う点にある。

処理判断部１３は、新たなサーバーの選定が完了すると、端末毎の接続先切替情報と共に接続管理部１２に選定結果を返す。接続先切替情報を図１０に示す。応答を受けた接続管理部１２は、各端末へ切替えが必要な旨を通知し、端末の承諾を得る。

接続管理部１２は、端末から承諾通知を受け取ると当該サーバーに対して、処理の中断を要求する。この間、端末側では中断可能ポイントまで処理を進めておく。中断要求を受けたサーバーは、処理が中断可能ポイントまで進められるのを待ち、処理途中で生成された、中間画像又は二次画像を医用画像管理手段２１に記憶する。医用画像管理手段２１は、ネットワークに接続されていれば良く、各サーバーが有する記憶手段であっても良い。

中断処理が完了するとサーバーは、端末との接続を切断し、その旨を提供状況取得部１６に通知する。通知を受け取った、提供状況取得部１６は、管理情報を更新すると共に接続管理部１２へその旨を通知し、接続管理部１２は、予め選定された接続先切替情報を端末に通知する。端末は接続先切替情報と共にサーバーへ接続を要求する。要求を受け取ったサーバーは、接続先切替情報を基に中断時に記憶された、中間画像又は二次画像を読込み中断時の状態への再開処理を行う。

緊急処理を要求したサーバーＸ、及び、新たなサーバーＹを図９に示す。また、旧サーバー名、新サーバー名、アプリケーション名、選定の状態、画像データ識別情報、その他の情報を含む新旧両方の提供元の情報の一例を図１０に接続先情報として示す。

次に、この発明の第３の実施形態に係る提供元報知装置の一連の動作について、図１１を参照にして説明する。図１１は、緊急時に、サーバーを選定するときのフローチャートである。

第３の実施形態では、緊急処理を要求したサーバーが現在提供中のサービスの数分だけ、各サービスと同じサービスを提供することとなる新たなサーバーを選定する。従って、処理判断部１３は、各種管理情報を管理情報管理手段１４から取得すると（ステップＳ３０１）、処理判断部１３が、提供中のサービスの数分だけ、各サービスと同じサービスを提供することとなる新たなサーバーを選定する第１ループ（ステップＳ３０２）に入る。第１ループに入ると、さらに、処理判断部１３が、アプリケーションサーバーの数分の中から新たなサーバーを選定する第２ループ（ステップＳ３０３）に入る。そして、処理判断部１３が、提供中のサービスと同じサービスを提供することとなる新たなサーバーを選定すると、第２ループを一度は抜ける（ステップＳ３１２）。次に、第１ループに戻り、次のサービスと同じサービスを提供することとなる新たなサーバーを選定する第２ループに再び入る。

このようにして、提供中のサービスの数分だけ、各サービスと同じサービスを提供することとなる新たなサーバーの選定を次々に行う。

なお、第３実施形態では、上述したように、緊急対応が必要なサーバーが存在することを鑑み、残りのサーバーから選定を行う点に特徴がある。具体的には、緊急処理を要求したサーバーである場合（ステップＳ３０４；Ｙ）、ステップＳ３０３に戻り、次の順番のアプリケーションサーバーを指定する。また、第３実施形態では、負荷算出処理（ステップＳ３０６からＳ３１２、及び、Ｓ３１５）は、第２実施形態での負荷算出処理と同様である。

以上のようにして、提供中のサービスの数分だけ、各サービスと同じサービスを提供することとなる新たなサーバーの選定を全て終了すると、第１ループを抜け（ステップＳ３１４）、サーバーの選定が全て終了する。

第３の実施形態では、サービス提供中のサーバー上で緊急処理が必要になった場合でも、サービスの提供を中止させることなく、中断／再開と接続先の切替え手段を用いることで、同じサービスを提供している別のサーバーへスムーズに移行させることを可能にすることで、端末を利用しているユーザにも、サーバー上で緊急処理を行いたい（独占的に利用したい）ユーザに対しても気兼ねなく作業を行ってもらうことができるようになることで、限りある資源を効率よく有効に活用することが可能となる。

次に、前述した中断可能ポイントについて、図１２及び図１３を参照にして説明する。図１２は、原画像、中間画像、二次画像の一例を示す図、図１３は原画像、中間画像の例を示す図である。

中断可能ポイントの判断箇所については、まず大まかに医用アプリケーションの利用前、利用中、利用後に分けられる。サーバーに接続している状態ではあっても、利用前、利用後については、処理の途中ではないため、切替えにあたって特別な処理を必要としないので特に問題無く切替えが可能である。しかしながら、利用中の場合、何らかの処理中である可能性があるため、中断にあたっては、特別な処理が必要となる。

本発明での、医用アプリケーションサービスとは、主に画像処理を伴う臨床アプリケーション（脳機能解析アプリ、心機能解析アプリ、等）を想定しており、提供されるアプリケーションでは、原画像を元に画像処理を実施し、中間画像又は二次画像を生成して、記憶し、次のステップに移っている。原画像、中間画像、二次画像の例を図１２及び図１３に示す。

この中間画像又は二次画像を生成するタイミングにおいて、サービス提供中のサーバーが中間画像又は二次画像を記憶し、記憶した中間画像又は二次画像を、新たな提供元であるサーバーが読み出すことで処理の継続が可能であることから、このタイミングを中断ポイントして利用することで、処理の中断が可能となる。また、新たに、中間画像又は二次画像を生成し直さないで済み、アプリケーションのサービスをスムーズに移行することが可能となる。

［第４の実施の形態］
次に、この発明の第４の実施形態に係る提供元報知装置の一連の動作について、図１４及び図１５を参照にして説明する。図１４は、高負荷時のシーケンスチャート、図１５は、高負荷時に、サーバーを選定するときのフローチャートである。

第４の実施形態に係る提供元報知装置は、アプリケーションのサービスを提供中のサーバーが高負荷時になったとき、サービスの一部を新たな提供元（切替先）である他のサーバーに切り替えるべく、新たな提供元（切替先）の情報を端末に報知するものである。サービスの旧の提供元であるサーバーＸ、サービスの新たな提供元（切替先）であるサーバーＹを図１４に示す。

ここで、高負荷時とは、緊急時とは多少状況が異なるが、高負荷のアプリケーションの重複などによって、アプリケーションサーバーが高負荷状態に陥った場合をいう。高負荷時にも、緊急時と同様に提供サービスの切替処理を行うことで、当該サーバーの負荷を低減することが可能となる。但し、高負荷状態の負荷を低減する場合、緊急時のように全てのサービスを移行する必要はないので、サービスの一部を他のサーバーへ切り替えることで負荷の低減を図ることができる。

サーバーの高負荷状態が所定範囲を超えたことの情報（高負荷警告）を受けた提供状況取得部１６は、接続管理部１２に対して当該サーバーの負荷分散要求をし、それを受けた接続管理部１２は、処理判断部１３に対して、サービスの新たな提供元（切替先）の選定を要求する。処理判断部１３は、切り替えるべきサービス、並びに、上記した３つの管理情報である提供アプリ一覧、提供状況一覧、及び、予約情報一覧を基に、切り替えるべきサービスの新たな提供元（切替先）となるサーバーの選定をする。

この第４実施形態でのサーバーの選定方法が前記第１実施形態での選定方法と異なるのは、負荷分散が必要なサーバーを除いた、残りのサーバーから選定を行う点にある。

処理判断部１３は、新たな提供元（切替先）であるサーバーの選定が完了すると、端末毎の接続先切替情報と共に接続管理部１２に選定結果を返す。応答を受けた接続管理部１２は、各端末へ切替えが必要な旨を通知し、端末の承諾を得る。

接続管理部１２は、端末から承諾通知を受け取ると、サービス提供中のサーバーに対して、処理の中断を要求する。この間、端末側では中断可能ポイントまで処理を進めておく。サービス提供の中断要求を受けたサーバーは、処理が中断可能ポイントまで進められるのを待ち、サービス提供の処理途中で生成された、中間画像又は二次画像を医用画像管理手段２１に記憶する。ここでの中断可能ポイントは、第３の実施形態と同じ中断可能ポイントをいう。

サービス提供の中断処理が完了するとサーバーは、端末との接続を切断し、その旨を提供状況取得部１６に通知する。通知を受け取った、提供状況取得部１６は、管理情報を更新すると共に接続管理部１２へその旨を通知し、接続管理部１２は、予め選定された接続先切替情報を端末に通知する。端末は接続先切替情報と共にサーバーへ接続を要求する。要求を受け取ったサーバーは、接続先切替情報を基に医用画像管理手段２１に記憶された、中間画像又は二次画像を読込み、中断時の状態への再開処理を行う。

次に、この発明の第４の実施形態に係る提供元報知装置の一連の動作について、図１５を参照にして説明する。図１５は、高負荷時に、サーバーを選定するときのフローチャートである。

第４の実施形態では、負荷分散の要求をしたサーバーが、現在提供中のサービスの数分だけ、各サービスと同じサービスを提供することとなる新たなサーバーを選定する。従って、処理判断部１３は、各種管理情報を管理情報管理手段１４から取得すると（ステップＳ４０１）、高負荷状態にあるサーバーの負荷を記録し（ステップＳ４０２）、その後、処理判断部１３が、提供中のサービスの数分だけ、各サービスと同じサービスを提供することとなる新たなサーバーを選定する第１ループ（ステップＳ４０３）に入る。

第１ループに入ると、処理判断部１３は、負荷分散の要求をしたサーバーの負荷が分散処理によって、閾値（例えば、７０％）以下になったか否かを判断する（ステップＳ４０４）。そして、サーバーの負荷が閾値以下になった場合（ステップＳ４０４；Ｙ）、第１スープを抜け（ステップＳ４１７）、負荷分散処理を終了する。

サーバーの負荷が閾値を超えている場合（ステップＳ４０４；Ｎ）、処理判断部１３が、アプリケーションサーバーの数分の中から新たなサーバーを選定する第２ループ（ステップＳ４０５）に入る。そして、処理判断部１３が、提供中のサービスと同じサービスを提供することとなる新たなサーバーを選定すると、第２ループを抜ける（ステップＳ４１５）。次に、サーバーの負荷から、移行するサービスの予想負荷を減算する（ステップＳ４１６）。その後、第１ループに戻り、次のサービスと同じサービスを提供することとなる新たなサーバーを選定する（ステップＳ４０３）。

このようにして、サーバーの負荷が閾値以下になるまで、提供中のサービスの数分だけ、各サービスと同じサービスを提供することとなる新たなサーバーの選定を次々に行う。
なお、第４実施形態では、負荷分散が必要なサーバーが存在することを鑑み、残りのサーバーから選定を行う点に特徴がある。具体的には、負荷分散の要求をしたサーバーである場合（ステップＳ４０６；Ｙ）、ステップＳ４０５に戻り、次の順番のアプリケーションサーバーを指定する。また、要求されたサービスを提供していない場合（ステップＳ４０７；Ｙ）、負荷算出を行う。さらに、第４実施形態では、負荷算出処理（ステップＳ４０８からＳ４１４、及び、Ｓ４１８）は、第２実施形態での負荷算出処理と同様である。
以上のようにして、サーバーの負荷が閾値以下になると、新たなサーバーの選択を終了する。

緊急処理の手段を応用することで、サーバーが不意に高負荷に陥ってしまった時の負荷低減も図れることから、常に安定したサービス、パフォーマンスを提供するシンクライアントシステムを構築、提供することが可能となる。

この発明の第１実施形態に係る提供元報知装置の機能ブロック図である。 各種管理情報の例を示す説明図である。 管理情報収集時のシーケンスチャートである。 医用アプリケーションサービスの提供要求時のシーケンスチャートである。 接続先情報の一例を示す図である。 この発明の第２実施形態に係る提供元報知装置において、サーバーを選定するときのフローチャートである。 予約負荷を求めるときのフローチャートである。 この発明の第３実施形態に係る提供元報知装置の機能ブロック図である。 緊急処理時のシーケンスチャートである。 接続先切替情報の一例を示す図である。 緊急時に、サーバーを選定するときのフローチャートである。 原画像、中間画像、二次画像の一例を示す図である。 原画像、中間画像の例を示す図である。 この発明の第４実施形態に係る提供元報知装置において、高負荷時のシーケンスチャートである。 高負荷時に、サーバーを選定するときのフローチャートである。

符号の説明

１０ 提供元報知装置 １１ 要求受信部 １２ 接続管理部 １３ 処理判断部
１４ 管理情報管理手段 １５ 提供アプリ等情報取得部 １６ 提供状況取得部
１７ 予約情報取得部 １８ 予約情報管理部 ２１ 医用画像管理手段

Claims (7)

1. 複数のアプリケーションのサービスの提供元となり得るサーバー群と、複数のアプリケーションのサービスの提供先となり得る端末群とにネットワークを介して接続された提供元報知装置であって、
   アプリケーションと、該アプリケーションのサービスの提供元となり得るサーバー群とを対応付けた提供元情報を取得する提供元情報取得部と、
   アプリケーションと、該アプリケーションのサービスを端末に現在提供している提供元とを対応付けた提供状況の情報を前記サーバーから取得する提供状況取得部と、
   アプリケーションと、該アプリケーションのサービスを端末に提供することを予約された提供元と、該予約された時間とを対応付けた予約情報を取得する予約情報取得部と、
   前記各端末からアプリケーションのサービスの提供要求を受信する要求受信部と、
   前記サービスの提供要求をした前記各端末に該サービスの提供元を報知する接続管理部と、
   前記サービスの提供要求を受けて、前記提供元情報から求めた前記提供元に実際になった場合のサーバーの負荷状況、前記アプリケーションの提供状況の情報から求めた現在のサーバーの負荷状況、及び、前記予約情報から求めた所定期間のサーバーの負荷状況を基に、前記サーバー群の中で、予め定めた条件を満たしたサーバーを選定し、前記選定されたサーバーの情報を前記接続管理部に送る判断処理部と、
   を有する
   ことを特徴とする提供元報知装置。
2. 前記サーバー群は、医用画像の収集をし、該医用画像から派生した画像を含む画像データの生成をするモダリティを含み、
   前記モダリティは、前記医用画像の収集と、前記アプリケーションのサービスの提供とを選択的に切り替え可能に構成されていることを特徴とする請求項１に記載の提供元報知装置。
3. 前記接続管理部は、アプリケーションのサービスを提供中のサーバーから前記サービスの提供を中断するための対応要求を提供状況取得部が受けた場合、前記判断処理部に対し新たなサーバーの選定を要求し、
   さらに、前記接続管理部は、前記判断処理部による前記新たなサーバーの選定を受けて、前記提供中のサーバーに対し、前記サービスの提供の中断要求をし、
   さらに、前記接続管理部は、前記提供中のサーバーにより生成された前記画像データの読み出し要求を、前記新たなサーバーに対して行うことを特徴とする請求項１又は請求項２のいずれかに記載の提供元報知装置。
4. 前記接続管理部は、アプリケーションのサービスを提供中のサーバーの負荷状況が所定範囲を超えたことの情報を前記提供状況取得部が取得した場合、前記判断処理部に対し新たなサーバーの選定を要求し、
   さらに、前記接続管理部は、前記判断処理部による前記新たなサーバーの選定を受けて、前記提供中のサーバーに対し、前記サービスの提供の中断要求をし、
   さらに、前記接続管理部は、前記提供中のサーバーにより生成された前記画像データの読み出し要求を、前記新たなサーバーに対して行うことを特徴とする請求項１に記載の提供元報知装置。
5. 前記接続管理部は、前記提供中のサーバーにより生成された前記画像データが記憶された時点を中断ポイントとして、前記提供中のサーバーに対し、前記サービスの提供の中断要求をすることを特徴とする請求項３又は請求項４のいずれかに記載の提供元報知装置。
6. 前記判断処理部は、前記負荷状況が最小であるサーバーを選定することを特徴とする請求項１に記載の提供元報知装置。
7. 複数のアプリケーションのサービスの提供元となり得るサーバー群と、複数のアプリケーションのサービスの提供先となり得る端末群とにネットワークを介して接続された提供元報知方法であって、
   アプリケーションと、該アプリケーションのサービスの提供元となり得るサーバー群とを対応付けた提供元情報を取得する提供元情報取得ステップと、
   アプリケーションと、該アプリケーションのサービスを端末に現在提供している提供元とを対応付けた提供状況の情報を前記サーバーから取得する提供状況管理ステップと、
   アプリケーションと、該アプリケーションのサービスを端末に提供することを予約された提供元と、該予約された時間とを対応付けた予約情報を取得する予約情報取得ステップと、
   前記各端末からアプリケーションのサービスの提供要求を要求受信部が受信する受信ステップと、
   前記サービスの提供要求を受けて、判断処理部が、前記提供元情報から提供元に実際になった場合のサーバーの予想負荷を求めるステップと、
   さらに、前記判断処理部が、前記提供状況の情報からサーバーの現在の負荷を求めるステップと、
   さらに、前記判断処理部が、前記予約情報から所定期間のサーバーの予約負荷を求めるステップと、
   さらに、前記判断処理部が、前記予想負荷、前記現在の負荷、及び、前記予約負荷を加算して総負荷を求めるステップと、
   さらに、前記判断処理部が、前記サーバー群の中で、前記総負荷が最小となるサーバーを選定する判断処理ステップと、
   前記接続管理部が、前記選定されたサーバーを前記端末に報知するステップと、
   を有する
   ことを特徴とする提供元報知方法。