JP7395908B2 - 情報処理システム - Google Patents

Description

本発明は、情報処理システムに関する。

ネットワーク上で提供されるサービス（クラウドサービス等）の利用形態の一つとして、ユーザが一つの中継装置を介して複数のサービスに接続可能とすることでユーザの利便性を高めるものがある。

特許文献１には、ユーザが複数のクラウドサーバのそれぞれについて保有するアカウントを示すアカウント情報を管理し、ユーザがログインしたときに、複数のクラウドサーバのそれぞれからユーザによる利用の状況を示す利用情報を取得し、利用情報によって示されるユーザによる複数のクラウドサーバのそれぞれの利用の状況を、当該ユーザがログインに際して操作した機器に備わるディスプレイに一覧表示させる情報システムが開示されている。

特許文献２には、クラウドサービスとその代替機能とサービス停止条件とを関連付けるクラウドサービス情報を記憶し、クラウドサービスの稼働状態を示す情報を取得し、この稼働状態を示す情報とサービス停止条件とを比較して特定のクラウドサービスの稼働状態を認識し、特定のクラウドサービスが停止中の場合、その代替機能を取得し、代替機能に基づく処理用の画面を表示する情報システムが開示されている。

また、障害発生時のユーザの利便性を高める従来技術として、特許文献３には、利用者の認証情報と利用者毎にクラウドサービスへのデータの格納が失敗した場合の対応情報とを記憶し、画像処理装置が読み込んだデータをクラウドに格納するにあたって、クラウドへのデータの格納に失敗した場合、利用者毎の情報に基づいた対応内容を、利用者に送信する中継装置が開示されている。

特開２０１４－２３８７８６号公報 特開２０１６－１７７４４７号公報 特開２０１７－４５０９９号公報

中継装置を介して接続されるサービス（外部サービス）が正常動作していない場合、外部サービスの状態をユーザに通知したいが、外部サービスの状態は実際に接続を試みなければわからない場合がある。

また、中継装置がユーザからのリクエストを受け付けた後に外部サービスが異常となった場合、受け付けたリクエストをエラーにしてしまうと、ユーザが改めて同じリクエストを行う必要が生じ、ユーザの手間を増大させることになる。

本発明は、ユーザによる複数の外部サービスへの接続を一元管理する中継装置において、自発的に外部サービスの状態を確認してユーザに通知し、ユーザの利便性の向上を図ることを目的とする。

請求項１に係る本発明は、外部装置からリクエストを受け付け、当該リクエストに必要な中間処理を行って外部のサーバへ転送する中継制御手段と、前記サーバに対してリクエストを送信し、当該サーバの応答に基づいて当該サーバに障害が発生しているか否かを検知する障害検知手段と、前記障害検知手段により検知された前記サーバの状態に基づき当該サーバによるサービスが利用可能か否かを判断する判断手段と、前記判断手段の判断結果に応じて、当該判断結果である前記サーバの状態を前記外部装置へ通知する状態通知手段と、を備え、前記中継制御手段が前記中間処理を行う際に一時的に前記リクエストを保持する保持手段と、前記保持手段に保持された前記リクエストに関して、当該リクエストの送信先の前記サーバが前記判断手段によりサービスを利用できないと判断された場合に、当該リクエストを前記中継制御手段による前記中間処理の対象から除外する制御を行うリクエスト制御手段と、をさらに備えることを特徴とする情報処理システムである。
請求項２に係る本発明は、前記障害検知手段は、前記中継制御手段が前記外部装置からリクエストを受け付けたか否かに関わらず、予め定められた送信条件にしたがって、前記サーバへリクエストを送信することを特徴とする、請求項１に記載の情報処理システムである。
請求項３に係る本発明は、前記障害検知手段は、定期的に前記サーバへリクエストを取得することを特徴とする、請求項２に記載の情報処理システムである。
請求項４に係る本発明は、前記障害検知手段は、前記サーバによるサービスで提供される機能を利用するダミーのリクエストを送信し、当該サーバの応答を取得することを特徴とする、請求項２に記載の情報処理システムである。
請求項５に係る本発明は、前記障害検知手段は、前記ダミーのリクエストとして、前記中継制御手段が前記外部装置からのリクエストを中継する際に前記サーバへ送信されるリクエストと同一のリクエストを送信することを特徴とする、請求項４に記載の情報処理システムである。
請求項６に係る本発明は、前記状態通知手段は、前記中継制御手段が前記外部装置からリクエストを受け付けた際、当該リクエストの送信先の前記サーバが前記判断手段によりサービスを利用できないと判断されている場合に、当該判断結果を当該外部装置へ通知することを特徴とする、請求項１に記載の情報処理システムである。
請求項７に係る本発明は、前記リクエスト制御手段により前記中継制御手段による前記中間処理の対象から除外された前記リクエストの発行元である前記外部装置に対し、当該リクエストの処理が未完了であることを通知するリクエスト状況通知手段をさらに備えることを特徴とする、請求項１に記載の情報処理システムである。
請求項８に係る本発明は、前記障害検知手段は、送信したリクエストに対する前記サーバの応答に基づいて当該サーバの障害が解消したか否かを検知し、前記判断手段は、前記障害検知手段により検知された前記サーバの状態に基づき当該サーバによるサービスが復旧したか否かを判断し、前記リクエスト制御手段は、前記判断手段により前記サーバによるサービスが復旧したと判断された場合に、前記保持手段に保持されて前記中継制御手段による前記中間処理の対象から除外されていた当該サーバを送信先とするリクエストを当該中間処理の対象に復帰させ、前記リクエスト状況通知手段は、前記リクエスト制御手段の制御により前記中間処理の対象に復帰した前記リクエストの発行元である前記外部装置に対し、当該リクエストの処理が再開されたことを通知することを特徴とする、請求項７に記載の情報処理システムである。

請求項１の発明によれば、ユーザによる複数の外部のサーバ（外部サービス）への接続を一元管理する中継装置において、単にリクエストを中継する構成と比較して、自発的に外部サービスの状態を確認してユーザに通知し、ユーザの利便性の向上を図ることができる。また、単に外部サービスの状態を確認する構成と比較して、障害が発生した外部サービスを対象とするリクエストについて中間処理を実行してしまうことを回避することができる。
請求項２の発明によれば、外部装置からリクエストを受け付けてから外部サービスの状態を確認する構成と比較して、外部装置からの問い合わせに対して即時に応答することができる。
請求項３の発明によれば、外部装置からリクエストを受け付けてから外部サービスの状態を確認する構成と比較して、定期的に外部サービスの状態を確認することにより、外部サービスの障害発生時期を特定することができる。
請求項４の発明によれば、単に外部サービスに対して状態の問い合わせをする構成と比較して、外部サービスの具体的な機能の状態を確認することができる。
請求項５の発明によれば、単に外部サービスに対して状態の問い合わせをする構成と比較して、外部装置からのリクエストと同じ通常のリクエストに対するサービスの応答を確認することができる。
請求項６の発明によれば、外部装置からリクエストを受け付けてから外部サービスの状態を確認する構成と比較して、外部装置からリクエストを受け付けた際に、即時に応答することができる。
請求項７の発明によれば、リクエストの対象である外部サービスに障害が発生した場合に、かかるリクエストをエラーとする構成と比較して、外部装置から重複してリクエストが行われる無駄を削減することができる。
請求項８の発明によれば、利用できない外部サービスを対象とするリクエストをエラーとする構成と比較して、外部サービスの復帰後に外部装置から重複してリクエストが行われる無駄を削減することができる。

本実施形態が適用される情報処理システムの全体構成を示す図である。 中継サーバの機能構成を示す図である。 端末装置の機能構成を示す図である。 障害検知部が外部サービスの障害を検知した際の動作を示すシーケンス図である。 外部サービスが利用できないことを報知する際の動作を示すシーケンス図である。 障害検知部が外部サービスの障害の復旧を検知した際の動作を示すシーケンス図である。 外部サービスが利用可能となったことを報知する際の動作を示すシーケンス図である。 端末装置から新規リクエストを受け付けた際の動作を示すシーケンス図である。 端末装置から新規リクエストを受け付け、対象の外部サービスに障害がある場合の動作を示すシーケンス図である。 既に受け付けたリクエストの対象の外部サービスに障害が発生した場合の動作を示すシーケンス図である。 既に受け付けたリクエストの対象の外部サービスが障害から復旧した場合の動作を示すシーケンス図である。

以下、添付図面を参照して、本発明の実施の形態について詳細に説明する。
＜システム構成＞
図１は、本実施形態が適用される情報処理システムの全体構成を示す図である。本実施形態の情報処理システムは、中継サーバ１００と、端末装置２００と、外部サービス３００とを備える。

端末装置２００は、ユーザの操作を受け付け、中継サーバ１００を経由して外部サービス３００にアクセスし、外部サービス３００が提供するサービスを受ける装置である。この端末装置２００は、外部サービス３００によるサービスを受けるためのリクエストを送信し、サービスである処理結果や処理結果の通知を受信する。本実施形態の端末装置２００は、中継サーバ１００を介して、外部サービス３００によるサービスの提供状態（外部サービス３００の稼働状態を含む）を確認する。

中継サーバ１００は、インターネット上に設けられたサーバであり、端末装置２００と外部サービス３００との間の通信を中継する。この中継サーバ１００は、端末装置２００から送信されたリクエストを受け付け、利用しようとする外部サービスに応じて前処理を行って、対象の外部サービス３００へ転送する。また、中継サーバ１００は、外部サービスの状態を確認し、得られた結果を端末装置２００へ通知する。

外部サービス３００は、インターネットを介してサービス（いわゆるクラウドサービス等）を提供するサーバである。この外部サービス３００は、中継サーバ１００を介して、端末装置２００から送信されたリクエストを受け付ける。そして、外部サービス３００は、リクエストに対する応答としてサービスを提供する。

図１には、一つの端末装置２００が中継サーバ１００に接続されているが、実際には、複数の端末装置２００が個別に中継サーバ１００に接続し、中継サーバ１００を介して外部サービス３００にアクセスしても良い。また、中継サーバ１００を介してアクセス可能な外部サービス３００の数も特に限定されない。中継サーバ１００および外部サービス３００は、単一のハードウェア（サーバマシン等）に限定されず、複数のハードウェアや仮想マシンに分散して構成しても良い。

＜中継サーバ１００の機能構成＞
図２は、中継サーバ１００の機能構成を示す図である。中継サーバ１００は、受け付け処理部１１０と、イベント処理部１２０と、リクエスト保持部１３０と、プラグイン実行部１４０とを備える。この受け付け処理部１１０、イベント処理部１２０、リクエスト保持部１３０およびプラグイン実行部１４０は、端末装置２００から受け付けたリクエストに対し、プラグインを用いて必要な中間処理を行い、外部サービス３００へ転送する中継制御手段の一例である。また、中継サーバ１００は、障害検知部１５０と、サービス利用可否判断部１６０と、リクエスト制御部１７０と、通知部１８０と、状態問い合わせ受け付け部１９０とを備える。

受け付け処理部１１０は、端末装置２００から送信されたリクエストを受け付ける。そして、受け付けたリクエストをイベント処理部１２０に渡す。また、受け付け処理部１１０は、障害が発生した外部サービスを利用するリクエストを受け付けた場合、そのリクエストを不可視状態（invisible）にする。これにより、そのリクエストに対するイベント処理部１２０の処理がスキップされる。リクエストの不可視化については後述する。

イベント処理部１２０は、受け付け処理部１１０からリクエストを受け取り、受け取ったリクエストに対する処理を行う。具体的には、イベント処理部１２０は、タスク定義を参照して、受け取ったリクエストの処理に必要なプラグインを特定する。タスク定義とは、プラグインを組み合わせて実行される一連の作業をタスクとして定義したものである。イベント処理部１２０は、タスク定義にしたがって、特定したプラグインを順次適用することにより、リクエストに対する処理を行う。

リクエスト保持部１３０は、プラグインごとに対応付けられたキューを有する。そして、イベント処理部１２０は、タスク定義に基づいて特定されるプラグインに対応する各キューに、該当するリクエストを保持させる。処理対象のリクエストは、一つのキューに保持され、そのキューに対応するプラグインによる処理が実行されると、タスク定義に基づいて特定される次のプラグインに対応するキューに保持される。このようにして、リクエストに対し、タスク定義にしたがって、プラグインによる処理が順次実行される。すなわち、リクエスト保持部１３０は、リクエストに対する中間処理を行うために、一時的にリクエストを保持する保持手段の一例である。

プラグイン実行部１４０は、リクエストを処理する各種のプラグインを実行する。例えば、処理対象の文書を外部サービス３００が受け付けられる書式に変換する等の文書処理を行うプラグイン、外部サービス３００においてまとめて扱うデータを一つのファイルにまとめるデータ処理を行うプラグイン等が、イベント処理部１２０の制御により、タスク定義に基づいて順次実行される。

障害検知部１５０は、接続可能な外部サービス３００に対してリクエストを送信し、外部サービス３００からの応答に基づいて、外部サービス３００の障害発生、復旧を検知する。障害検知部１５０は、障害検知手段の一例である。障害の検知は、種々の態様によって行われる。例えば、障害検知部１５０は、外部サービス３００から障害が発生していることを知らせる応答を受信することにより、この外部サービス３００に障害が発生したことを検知する。また、障害検知部１５０は、一定時間内に、外部サービス３００から正常な応答を受信しなかった場合に、この外部サービス３００に障害が発生したことを検知することとしても良い。その他、外部サービス３００が正常に動作していない場合に起こり得る種々の事象に基づいて障害を検知することとして良い。また、障害検知部１５０は、障害が発生したことが検知された外部サービス３００に対してリクエストを送信し、正常な応答を受信した場合は、この外部サービス３００が障害から復旧したことを検知する。

障害検知部１５０により送信されるリクエストは、外部サービス３００の機能を利用するために行われるリクエストのダミーである。例えば、端末装置２００からのリクエストに応じて中継サーバ１００から送信される、通常のサービスを受けるためのリクエストと同一のリクエストとしても良い。通常のサービスを受けるためのリクエストとは、必要に応じてイベント処理部１２０およびプラグイン実行部１４０による前処理が施されたリクエストである。また、外部サービス３００が対応している場合は、障害検知部１５０は、通常のサービスを受けるためのリクエストに代えて、外部サービス３００の状態を問い合わせるために特に設定されたリクエストを送信しても良い。

また、障害検知部１５０は、端末装置２００からのリクエストの有無に関わらず、予め定められた送信条件を満たすことにより、リクエストを送信する。例えば、障害検知部１５０は、予め定められた時間間隔で定期的にリクエストを送信する。また、障害検知部１５０は、ある外部サービス３００に対するリクエスト（端末装置２００からのリクエストに基づいて中継サーバ１００から送信されたリクエストを含む）から一定時間経過後にリクエストを送信しても良い。また、障害検知部１５０は、ある外部サービス３００において障害が復旧してから一定時間経過後にリクエストを送信しても良い。また、障害検知部１５０は、ある外部サービス３００において障害が発生した場合に、その外部サービス３００と同種のサービスを提供する他の外部サービス３００に対し、一定時間以内にリクエストを送信しても良い。その他、外部サービス３００の運用形態や仕様等に応じて、種々の送信条件を設定して良い。

また、障害検知部１５０は、ある外部サービス３００に障害が検知された場合、および、障害が検知された外部サービス３００が復旧した場合、その旨をリクエスト制御部１７０に通知する。

サービス利用可否判断部１６０は、障害検知部１５０の検知結果に基づいて、外部サービス３００の利用可否を判断する。具体的には、サービス利用可否判断部１６０は、障害検知部１５０により障害発生が検知される前は、外部サービスを利用可能（active）と判断する。また、サービス利用可否判断部１６０は、障害検知部１５０により障害発生が検知された外部サービス３００を利用不可（inactive）と判断する。また、サービス利用可否判断部１６０は、障害検知部１５０により障害復旧が検知された外部サービスを利用可能（active）と判断する。サービス利用可否判断部１６０は、判断手段の一例である。

リクエスト制御部１７０は、外部サービス３００の状態に応じて、リクエスト保持部１３０のキューに保持されているリクエストに対するプラグイン実行部１４０による処理の実行を制御する。具体的には、まず、リクエスト制御部１７０は、障害検知部１５０から、障害の発生または復旧の通知を受ける。次に、リクエスト制御部１７０は、受け付けた通知に応じて、障害が発生した外部サービスを利用するために適用されるプラグインを調べ、そのプラグインに対応するキューを特定する。次に、リクエスト制御部１７０は、特定したキューに保持されているリクエストのうち、障害が発生した外部サービス３００を利用するリクエストを不可視状態（invisible）にする。ここで、不可視状態にするのは、障害が発生した外部サービス３００を利用するリクエストのみである。したがって、同じキューに保持されている（同じプラグインが適用される）リクエストであっても、障害が発生した外部サービス３００を利用しない（すなわち、他の外部サービス３００を利用する）リクエストは不可視状態にしない。

また、リクエスト制御部１７０は、障害検知部１５０からの通知に応じて、障害が復旧した外部サービス３００を利用するために適用されるプラグインを調べ、そのプラグインに対応するキューを特定する。次に、リクエスト制御部１７０は、特定したキューに保持されているリクエストのうち、障害が復旧した外部サービス３００を利用するリクエストを可視状態（visible）にする。ここで、可視にするのは、障害が復旧した外部サービス３００を利用するリクエストのみである。したがって、同じキューに保持されている（同じプラグインが適用される）不可視状態のリクエストのうち、障害が復旧していない外部サービス３００を利用するリクエストは可視にしない。

以上のように、リクエスト制御部１７０は、リクエスト保持部１３０のキューに保持されているリクエストの状態を、可視状態から不可視状態へ、不可視状態から可視状態へと切り替えることにより、プラグイン実行部１４０による処理の実行を制御する。可視状態とは、リクエストがプラグイン実行部１４０から見える状態であり、プラグイン実行部１４０が対象のリクエストをキューから取り出して処理できる状態である。不可視状態とは、リクエストがプラグイン実行部１４０から見えない状態であり、プラグイン実行部１４０が対象のリクエストをキューから取り出して処理できない状態である。すなわち、不可視状態となったリクエストは、中継サーバ１００による中間処理の対象から除外される。そして、不可視状態から可視状態に変更されたリクエストは、中継サーバ１００による中間処理の対象に復帰する。リクエスト制御部１７０は、リクエスト制御手段の一例である。

可視状態と不可視状態との切り替えは、例えば、リクエストの属性情報を切り替えることにより行われる。具体的には、リクエスト制御部１７０が、対象のリクエストに対し、可視状態であること（または、不可視状態であること）を示すタグを付加して切り替えるようにしても良い。また、予め、受け付け処理部１１０やイベント処理部１２０が、受け付けたリクエストに対して可視・不可視を示すためのフラグを付加しておき、リクエスト制御部１７０が対象のリクエストのフラグ値を書き換えることにより切り替えるようにしても良い。

通知部１８０は、サービス利用可否判断部１６０により判断された外部サービス３００の利用可否の判断結果を、その外部サービス３００の状態を問い合わせた端末装置２００に通知する。また、通知部１８０は、リクエスト制御部１７０により不可視状態とされたためにリクエストの処理が実行されない場合に、実行されないリクエストの送信元である端末装置２００に対し、そのリクエストに対する処理が完了していない旨の通知を行う。また、通知部１８０は、不可視状態から可視状態に変更されたためにリクエストの処理が実行可能となった場合に、そのリクエストの送信元である端末装置２００に対し、そのリクエストに対する処理が再開した旨の通知を行う。

また、通知部１８０は、端末装置２００から受け付けたリクエストの対象である外部サービス３００が利用できない状態である場合に、そのリクエストに対する応答として、外部サービス３００が利用できないことを示す通知を行っても良い。さらに、利用できない外部サービス３００の代替となり得る機能を有する外部サービス３００（以下、代替サービス）が存在する場合、端末装置２００に代替サービスへのリクエストを提示する通知や、代替サービスの利用を促す通知を行うようにしても良い。リクエスト制御部１７０および通知部１８０は、状態通知手段の一例である。

状態問い合わせ受け付け部１９０は、端末装置２００から外部サービス３００の状態の問い合わせを受け付ける。そして、通知部１８０に、サービス利用可否判断部１６０の判断結果を通知するように指示する。この問い合わせは、端末装置２００による外部サービス３００を利用するためのリクエストとは別に行われる。

中継サーバ１００は、例えば、コンピュータにより実現される。上述したように、中継サーバ１００は、複数のハードウェアや仮想マシンに分散して構成しても良い。このような中継サーバ１００は、ハードウェアとして、演算手段であるＣＰＵ（Central Processing Unit）と、記憶手段である主記憶装置（メイン・メモリ）および外部記憶装置を備える。ＣＰＵは、外部記憶装置に格納されたプログラムを主記憶装置に読み込んで、実行する。主記憶装置としては、例えばＲＡＭ（Random Access Memory）が用いられる。外部記憶装置としては、例えば磁気ディスク装置やＳＳＤ（Solid State Drive）等が用いられる。図２を参照して説明した、受け付け処理部１１０、イベント処理部１２０、プラグイン実行部１４０、障害検知部１５０、サービス利用可否判断部１６０、リクエスト制御部１７０、通知部１８０および状態問い合わせ受け付け部１９０は、例えば、ＣＰＵがプログラムを実行することにより実現される。また、リクエスト保持部１３０は、例えば、プログラムを実行するＣＰＵと、記憶手段である主記憶装置や外部記憶装置により実現される。

＜端末装置２００の機能構成＞
図３は、端末装置２００の機能構成を示す図である。端末装置２００は、通信部２１０と、要求部２２０と、状態確認部２３０と、状態報知部２４０とを備える。端末装置２００は、例えば、パーソナルコンピュータ、スマートフォン等の携帯型情報端末等で実現される。

通信部２１０は、ネットワークを介して中継サーバ１００に接続し、外部サービス３００を利用するためのリクエストを送信する。また、通信部２１０は、リクエストに対する外部サービス３００からの応答を受信する。また、通信部２１０は、中継サーバ１００に対し、外部サービス３００の状態の問い合わせを送信し、中継サーバ１００からの応答を受信する。

要求部２２０は、ユーザの指示に基づく処理や、予め定められた条件に基づく自動処理により、外部サービス３００を利用するためのリクエストを生成する。そして、要求部２２０は、生成したリクエストを、通信部２１０により中継サーバ１００へ送信させる。

状態確認部２３０は、ユーザによる指示を受け付けて、外部サービス３００の状態の問い合わせを生成する。そして、状態確認部２３０は、生成した問い合わせを、通信部２１０により中継サーバ１００へ送信させる。

状態報知部２４０は、通信部２１０が外部サービス３００の状態の問い合わせに対する応答を中継サーバ１００から受信すると、受信した応答に基づき、外部サービス３００の利用の可否をユーザに報知する。ユーザに対する情報の報知は、例えば、図示しない表示手段（ディスプレイ装置等）にメッセージを表示することにより行っても良い。

端末装置２００は、例えば、パーソナルコンピュータ、スマートフォン等の携帯型情報端末等で実現される。かかる端末装置２００は、ハードウェアとして、演算手段であるＣＰＵと、記憶手段である主記憶装置および外部記憶装置を備える。また、端末装置２００は、ネットワークに接続するためのネットワークインターフェイスと、ユーザが入力操作を行うための入力装置と、各種の画面を表示する表示装置とを備える。図３を参照して説明した、要求部２２０および状態確認部２３０は、例えば、ＣＰＵがプログラムを実行することにより実現される。また、通信部２１０は、例えば、プログラムを実行するＣＰＵと、ネットワークインターフェイスとにより実現される。また、状態報知部２４０は、例えば、プログラムを実行するＣＰＵと、表示装置とにより実現される。

＜中継サーバ１００の動作＞
・障害検知時の動作
図４は、障害検知部１５０が外部サービス３００の障害を検知した際の動作を示すシーケンス図である。なお、以下の説明では、障害検知部１５０が外部サービス３００の障害を検知するために送信するリクエストをダミーリクエストと呼ぶ。

上述したように、障害検知部１５０は、予め定められた送信条件に基づいて外部サービス３００へダミーリクエストを送信する［Ａ］。外部サービス３００に障害が発生している場合、障害検知部１５０は、エラーの応答を受け取る［Ｂ］。図４に示す例では、外部サービス３００から中継サーバ１００（障害検知部１５０）へ応答が返されているが、上述したように、障害検知部１５０は、外部サービス３００から応答が返されない場合にも、かかる外部サービス３００に障害が発生したことを検知し得る。

外部サービス３００に障害が発生したことを検知した障害検知部１５０は、サービス利用可否判断部１６０に検知結果を通知する［Ｃ］。サービス利用可否判断部１６０は、受け取った検知結果に基づいて、この外部サービス３００が利用不可（inactive）の状態であると判断し、その情報を保持する［Ｄ］。

図５は、外部サービス３００が利用できないことを報知する際の動作を示すシーケンス図である。まず、端末装置２００から中継サーバ１００へ、外部サービス３００の状態の問い合わせが送信される［Ａ］。ここでは、例えば図４に示したように、障害の発生が検知されて利用不可とされた外部サービス３００の状態についての問い合わせが行われたものとする。中継サーバ１００の状態問い合わせ受け付け部１９０は、この問い合わせを受け付け、サービス利用可否判断部１６０に外部サービス３００の状態を問い合わせる［Ｂ］。

サービス利用可否判断部１６０は、自身が保持する情報により、問い合わせ対象の外部サービス３００の状態を確認する［Ｃ］。外部サービス３００は利用不可の状態なので、サービス利用可否判断部１６０から通知部１８０へ、外部サービス３００の状態（inactive）が通知される［Ｄ］。そして、通知部１８０から問い合わせを行った端末装置２００へ、問い合わせ対象の外部サービス３００の状態（利用不可）の通知が行われる［Ｅ］。端末装置２００は、この通知を受信すると、問い合わせ対象の外部サービス３００が利用できない状態であることを示す表示が行われ［Ｆ］、外部サービス３００の状態がユーザに報知される。

・障害復旧時の動作
図６は、障害検知部１５０が外部サービス３００の障害の復旧を検知した際の動作を示すシーケンス図である。図４の場合と同様に、障害検知部１５０は、予め定められた送信条件に基づいて外部サービス３００へダミーリクエストを送信する［Ａ］。ここでは、外部サービス３００が障害から復旧しているので、障害検知部１５０は、外部サービス３００から正常時の応答を受け取る［Ｂ］。

外部サービス３００が復旧したことを検知した障害検知部１５０は、サービス利用可否判断部１６０に検知結果を通知する［Ｃ］。サービス利用可否判断部１６０は、受け取った検知結果に基づいて、この外部サービス３００が利用可能（active）な状態であると判断し、その情報を保持する［Ｄ］。

図７は、外部サービス３００が利用可能となったことを報知する際の動作を示すシーケンス図である。図５に示した例と同様に、まず、端末装置２００から中継サーバ１００へ、外部サービス３００の状態の問い合わせが送信される［Ａ］。ここでは、例えば図６に示したように、障害から復旧したことが検知されて利用可能とされた外部サービス３００の状態についての問い合わせが行われたものとする。中継サーバ１００の状態問い合わせ受け付け部１９０は、この問い合わせを受け付け、サービス利用可否判断部１６０に外部サービス３００の状態を問い合わせる［Ｂ］。

サービス利用可否判断部１６０は、自身が保持する情報により、問い合わせ対象の外部サービス３００の状態を確認する［Ｃ］。外部サービス３００は利用可能な状態なので、サービス利用可否判断部１６０から通知部１８０へ、外部サービス３００の状態（active）が通知される［Ｄ］。そして、通知部１８０から問い合わせを行った端末装置２００へ、問い合わせ対象の外部サービス３００の状態（利用可能）の通知が行われる［Ｅ］。端末装置２００は、この通知を受信すると、問い合わせ対象の外部サービス３００が利用可能な状態であることを示す表示が行われ［Ｆ］、外部サービス３００の状態がユーザに報知される。

・新規リクエストの受け付け時の動作
図８は、端末装置２００から新規リクエストを受け付けた際の動作を示すシーケンス図である。まず、端末装置２００から中継サーバ１００へ、外部サービス３００を利用するためのリクエストが送られ、受け付け処理部１１０が受け付ける。受け付け処理部１１０は、受け付けたリクエストを解析して、リクエストの対象である（すなわち、利用しようとする）外部サービス３００を特定する［Ａ］。以下、このリクエストの対象である外部サービス３００を対象サービスと呼ぶ。

次に、受け付け処理部１１０は、受け付けたリクエストに対して設定する状態（可視状態または不可視状態）をリクエスト制御部１７０に問い合わせる［Ｂ］。リクエスト制御部１７０は、対象サービスが利用可能か否かをサービス利用可否判断部１６０に問い合わせ［Ｃ］、サービス利用可否判断部１６０は、自身が保持する情報により、対象サービスの状態を確認し、応答を返す。ここでは、対象サービスが正常に稼働中であり、サービス利用可否判断部１６０からリクエスト制御部１７０へ、対象サービスが利用可能であることを示す応答（active）が返されるものとする［Ｄ］。

リクエスト制御部１７０は、サービス利用可否判断部１６０からの応答に基づいて、リクエストの状態を可視状態（visible）とするように、受け付け処理部１１０に対して応答する［Ｅ］。受け付け処理部１１０は、リクエスト制御部１７０からの応答に基づいて、リクエストを可視状態でリクエスト保持部１３０の該当するキューに格納する［Ｆ］。該当するキューとは、リクエストに対して最初に実行されるプラグインに対応するキューである。リクエスト保持部１３０のキューにリクエストが格納されると、イベント処理部１２０の制御により、キューに対応するプラグイン実行部１４０が呼び出される［Ｇ］。そして、呼び出されたプラグイン実行部１４０によるプラグイン処理が実行される［Ｈ］。プラグイン実行部１４０による処理が完了すると、プラグイン実行部１４０からリクエスト制御部１７０へ、リクエストに対する処理が完了したことを示す完了通知が送られる［Ｉ］。

なお、図８には、リクエストに対し、一つのプラグイン実行部１４０による一つのプラグイン処理が実行される例が示されている。これに対し、複数のプラグイン処理が行われる場合は、一つのプラグイン処理が実行されるごとにリクエストが次のプラグインに対応するキューに移される。そして、イベント処理部１２０の制御により、各キューに対応する複数のプラグイン実行部１４０が順次呼び出されてプラグイン処理が実行される。

図９は、端末装置２００から新規リクエストを受け付け、対象の外部サービス３００に障害がある場合の動作を示すシーケンス図である。図８に示した例と同様に、まず、端末装置２００から中継サーバ１００へ、外部サービス３００（対象サービス）を利用するためのリクエストが送られ、受け付け処理部１１０が受け付ける。受け付け処理部１１０は、受け付けたリクエストを解析して、対象サービスを特定する［Ａ］。

次に、受け付け処理部１１０は、受け付けたリクエストに対して設定する状態（可視状態または不可視状態）をリクエスト制御部１７０に問い合わせる［Ｂ］。リクエスト制御部１７０は、対象サービスが利用可能か否かをサービス利用可否判断部１６０に問い合わせ［Ｃ］、サービス利用可否判断部１６０は、自身が保持する情報により、対象サービスの状態を確認し、応答を返す。ここでは、対象サービスの障害が発生しており、サービス利用可否判断部１６０からリクエスト制御部１７０へ、対象サービスが利用できないことを示す応答（inactive）が返されるものとする［Ｄ］。

リクエスト制御部１７０は、サービス利用可否判断部１６０からの応答に基づいて、リクエストの状態を不可視状態（invisible）とするように、受け付け処理部１１０に対して応答する［Ｅ］。受け付け処理部１１０は、リクエスト制御部１７０からの応答に基づいて、リクエストを不可視状態でリクエスト保持部１３０の該当するキューに格納する［Ｆ］。不可視状態のリクエストは、プラグイン実行部１４０からは見えず、プラグイン実行部１４０による処理は実行されない。このリクエストは、後に対象サービスが復旧して利用可能となるまで不可視状態のままリクエスト保持部１３０に保持される。そして、対象サービスが利用可能になると、プラグイン実行部１４０によるプラグイン処理が開始される。

図１０は、既に受け付けたリクエストの対象の外部サービス３００に障害が発生した場合の動作を示すシーケンス図である。図４を参照して説明したように、障害検知部１５０は、外部サービス３００に障害が発生したことを検知すると、サービス利用可否判断部１６０に検知結果（inactive）を通知する［Ａ］。サービス利用可否判断部１６０は、外部サービス３００を利用できなくなったことをリクエスト制御部１７０に通知する［Ｂ］。

リクエスト制御部１７０は、リクエスト保持部１３０に保持されているリクエストのうち、利用できなくなった外部サービス３００を対象サービスとするリクエストを検索する［Ｃ］。該当するリクエストがある場合、リクエスト制御部１７０は、リクエスト保持部１３０に対し、このリクエストの状態を不可視状態（invisible）に変更させる［Ｄ］。そして、リクエスト制御部１７０から通知部１８０へ、リクエストの状態（invisible）が通知され［Ｅ］、通知部１８０からこのリクエストを行った端末装置２００へ、リクエストに対する処理が未完了であることを示す通知が行われる［Ｆ］。したがって通知部１８０は、リクエスト状況通知手段の一例である。

図１１は、既に受け付けたリクエストの対象の外部サービス３００が障害から復旧した場合の動作を示すシーケンス図である。図６を参照して説明したように、障害検知部１５０は、外部サービス３００が障害から復旧したことを検知すると、サービス利用可否判断部１６０に検知結果（active）を通知する［Ａ］。サービス利用可否判断部１６０は、外部サービス３００が利用可能になったことをリクエスト制御部１７０に通知する［Ｂ］。

リクエスト制御部１７０は、リクエスト保持部１３０に保持されているリクエストのうち、利用可能になった外部サービス３００を対象サービスとするリクエストを検索する［Ｃ］。該当するリクエストがある場合、リクエスト制御部１７０は、リクエスト保持部１３０に対し、このリクエストの状態を可視状態（visible）に変更させる［Ｄ］。そして、リクエスト制御部１７０から通知部１８０へ、リクエストの状態（visible）が通知され［Ｅ］、通知部１８０からこのリクエストを行った端末装置２００へ、リクエストに対する処理が再開されたことを示す通知が行われる［Ｆ］。

以上、本発明の実施形態について説明したが、本発明の技術的範囲は上記実施形態には限定されない。例えば、上記の実施形態では、既に受け付けたリクエストの対象の外部サービス３００に障害が発生した場合に、そのリクエストを行った端末装置２００へ、リクエストに対する処理が未完了であることを示す通知を行うこととした。これに加えて、新規リクエストの対象サービスに障害がある場合にも、リクエストを不可視状態でリクエスト保持部１３０に保持させると共に、リクエストに対する処理が未完了であることを示す通知を行うようにしても良い。

また、上記の実施形態では、新規リクエストの対象サービスに障害がある場合、後に対象サービスが復旧して利用可能となるまで不可視状態のままリクエストがリクエスト保持部１３０に保持されることとした。これに対し、例えば、不可視状態でリクエスト保持部１３０に保持されたリクエストに関して、処理を再開されないまま一定時間が経過した場合に、受け付けたリクエストを取り消し、その旨をリクエストを行った端末装置２００へ通知するようにしても良い。その他、本発明の技術思想の範囲から逸脱しない様々な変更や構成の代替は、本発明に含まれる。

１００…中継サーバ、１１０…受け付け処理部、１２０…イベント処理部、１３０…リクエスト保持部、１４０…プラグイン実行部、１５０…障害検知部、１６０…サービス利用可否判断部、１７０…リクエスト制御部、１８０…通知部、１９０…状態問い合わせ受け付け部、２００…端末装置、２１０…通信部、２２０…要求部、２３０…状態確認部、２４０…状態報知部、３００…外部サービス

Claims (8)

1. 外部装置からリクエストを受け付け、当該リクエストに必要な中間処理を行って外部のサーバへ転送する中継制御手段と、
   前記サーバに対してリクエストを送信し、当該サーバの応答に基づいて当該サーバに障害が発生しているか否かを検知する障害検知手段と、
   前記障害検知手段により検知された前記サーバの状態に基づき当該サーバによるサービスが利用可能か否かを判断する判断手段と、
   前記判断手段の判断結果に応じて、当該判断結果である前記サーバの状態を前記外部装置へ通知する状態通知手段と、
   を備え、
   前記中継制御手段が前記中間処理を行う際に一時的に前記リクエストを保持する保持手段と、
   前記保持手段に保持された前記リクエストに関して、当該リクエストの送信先の前記サーバが前記判断手段によりサービスを利用できないと判断された場合に、当該リクエストを前記中継制御手段による前記中間処理の対象から除外する制御を行うリクエスト制御手段と、
   をさらに備えることを特徴とする情報処理システム。
2. 前記障害検知手段は、前記中継制御手段が前記外部装置からリクエストを受け付けたか否かに関わらず、予め定められた送信条件にしたがって、前記サーバへリクエストを送信することを特徴とする、請求項１に記載の情報処理システム。
3. 前記障害検知手段は、定期的に前記サーバへリクエストを取得することを特徴とする、請求項２に記載の情報処理システム。
4. 前記障害検知手段は、前記サーバによるサービスで提供される機能を利用するダミーのリクエストを送信し、当該サーバの応答を取得することを特徴とする、請求項２に記載の情報処理システム。
5. 前記障害検知手段は、前記ダミーのリクエストとして、前記中継制御手段が前記外部装置からのリクエストを中継する際に前記サーバへ送信されるリクエストと同一のリクエストを送信することを特徴とする、請求項４に記載の情報処理システム。
6. 前記状態通知手段は、前記中継制御手段が前記外部装置からリクエストを受け付けた際、当該リクエストの送信先の前記サーバが前記判断手段によりサービスを利用できないと判断されている場合に、当該判断結果を当該外部装置へ通知することを特徴とする、請求項１に記載の情報処理システム。
7. 前記リクエスト制御手段により前記中継制御手段による前記中間処理の対象から除外された前記リクエストの発行元である前記外部装置に対し、当該リクエストの処理が未完了であることを通知するリクエスト状況通知手段をさらに備えることを特徴とする、請求項１に記載の情報処理システム。
8. 前記障害検知手段は、送信したリクエストに対する前記サーバの応答に基づいて当該サーバの障害が解消したか否かを検知し、
   前記判断手段は、前記障害検知手段により検知された前記サーバの状態に基づき当該サーバによるサービスが復旧したか否かを判断し、
   前記リクエスト制御手段は、前記判断手段により前記サーバによるサービスが復旧したと判断された場合に、前記保持手段に保持されて前記中継制御手段による前記中間処理の対象から除外されていた当該サーバを送信先とするリクエストを当該中間処理の対象に復帰させ、
   前記リクエスト状況通知手段は、前記リクエスト制御手段の制御により前記中間処理の対象に復帰した前記リクエストの発行元である前記外部装置に対し、当該リクエストの処理が再開されたことを通知することを特徴とする、請求項７に記載の情報処理システム。