(57)【要約】【課題】冗長化しないでコンピュータによるサービスの中断を抑制する。【解決手段】本情報処理装置は、サービスを提供するサーバとサーバからサービスの提供を受ける端末との間の通信を中継する。本情報処理装置は、サーバによるサービス提供の中断および再開の通知をサービスの稼働状況を監視する装置から受ける管理部と、サーバによるサービスの提供の中断の通知を管理部が受けると、通信において端末からサーバへ送信されるデータを保留する保留部と、サーバによるサービス提供の再開の通知を管理部が受けると、保留部によって保留されたデータをサーバに送信する送信部と、を備える。【選択図】図１０
2015197759.tif 000002
【特許請求の範囲】
【請求項１】
サービスを提供するサーバと前記サーバから前記サービスの提供を受ける端末との間の通信を中継する情報処理装置であって、
前記サーバによる前記サービス提供の中断および再開の通知を前記サービスの稼働状況を監視する装置から受ける管理部と、
前記管理部によって前記サーバによる前記サービスの提供の中断の通知を受けると、前記端末から前記サーバへ送信されるデータを保留する保留部と、
前記管理部によって前記サーバによる前記サービス提供の再開の通知を受けると、前記保留部によって保留された前記データを前記サーバに送信する送信部と、を備える、
情報処理装置。
【請求項２】
前記サーバから前記端末へ提供される前記サービスに伴うデータに前記サーバと前記端末との間の接続に関するパラメータを含むセッション情報が含まれている場合、前記サービス提供の中断前におけるセッション情報と前記サービス提供の再開後におけるセッション情報の対応を記憶するセッション情報記憶部、をさらに備える、
請求項１に記載の情報処理装置。
【請求項３】
前記セッションを終了させる手順を記憶するセッション終了手順記憶部と、
前記管理部によって前記サーバによる前記サービス提供の中断の通知を受けると、前記セッション終了記憶部と前記セッション情報記憶部を参照し、前記端末と前記サーバとの間のセッションを終了するセッション終了部と、をさらに備える、
請求項２に記載の情報処理装置。
【請求項４】
前記サーバと前記端末との間の通信の履歴を保存する履歴保存部と、
前記管理部によって前記サーバによる前記サービス提供の再開の通知を受けると、前記履歴保存部に保存された通信の履歴と前記セッション情報記憶部に記憶された情報に基づいて、前記サーバによって提供される前記サービスの状態を前記サービス提供の中断時点の状態に復元する復元部と、をさらに備える、
請求項２または請求項３に記載の情報処理装置。
【請求項５】
前記履歴保存部に保存する対象となる通信を特定する情報を保存する特定部をさらに備える、
請求項４に記載の情報処理装置。
【請求項６】
前記セッション情報記憶部を参照して前記端末から送信された中断前の前記サーバに対するデータを再開後の前記サーバに対するデータに変換する変換部、をさらに備える、
請求項２から請求項５のいずれか一項に記載の情報処理装置。
【請求項７】
前記サーバへの接続方式が前記サービスの中断および再開によって変更される場合に、中断前の前記サービスへの接続方式と再開後の前記サービスへの接続方式の対応を記憶する対応記憶部と、
前記対応記憶部を参照して、中断前の前記サービスへ送信されるデータを再開後の前記サービスへ送信されるデータに変換する接続方式変換部と、をさらに備える、
請求項１から請求項６のいずれか一項に記載の情報処理装置。
【請求項８】
サービスを提供するサーバと前記サーバから前記サービスの提供を受ける端末との間の通信を中継する情報処理装置が、
前記サーバによる前記サービス提供の中断および再開の通知を前記サービスの稼働状況を監視する装置から受ける管理ステップと、
前記管理ステップによって前記サーバによる前記サービスの提供の中断の通知を受けると、前記端末から前記サーバへ送信されるデータを保留する保留ステップと、
前記管理ステップによって前記サーバによる前記サービス提供の再開の通知を受けると、前記保留ステップによって保留された前記データを前記サーバに送信する送信ステップと、を実行する、
情報処理方法。
【請求項９】
サービスを提供するサーバと前記サーバから前記サービスの提供を受ける端末との間の通信を中継する情報処理装置に、
前記サーバによる前記サービス提供の中断および再開の通知を前記サービスの稼働状況を監視する装置から受ける管理ステップと、
前記管理ステップによって前記サーバによる前記サービスの提供の中断の通知を受けると、前記端末から前記サーバへ送信されるデータを保留する保留ステップと、
前記管理ステップによって前記サーバによる前記サービス提供の再開の通知を受けると、前記保留ステップによって保留された前記データを前記サーバに送信する送信ステップと、を実行させる、
プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、情報処理装置、情報処理方法およびプログラムに関する。
【背景技術】
【０００２】
コンピュータを利用した様々なサービスがネットワークを通じて提供されている。このようなサービスとして、例えば、オンラインショッピングあるいは動画公開サイト等を例示できる。このようなサービスでは、サービスが利用できなくなるサービス中断期間は可能な限り少ないほうが望ましい。しかしながら、コンピュータの運用においては、オペレーティングシステム（ＯＳ）や各種アプリケーションへの修正パッチの適用に例示されるメンテナンス作業あるいはハードウェア障害等によりサービスの提供が中断される場合がある。そこで、サービスの中断を抑制するためにサービスを提供するコンピュータを冗長化する対策が取られている。コンピュータを冗長化することにより、１台をメンテナンスで停止しても他のコンピュータでサービスの提供を継続できる。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開２００６−３３０９７３号公報
【特許文献２】国際公開第２００６／０５７０４０号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
しかしながら、実際に運用されているコンピュータには冗長化されていないものも少なくない。したがって、冗長化されていないコンピュータあるいは冗長化を前提としていないコンピュータでのサービス提供において、冗長化技術によってサービスの中断を抑制するには困難を伴う。そこで、開示の技術の１つの側面は、冗長化しないでコンピュータによるサービスの中断を抑制する技術である。
【課題を解決するための手段】
【０００５】
開示の技術の１つの側面は、次のような情報処理装置によって例示される。
本情報処理装置は、サービスを提供するサーバとサーバからサービスの提供を受ける端末との間の通信を中継する情報処理装置である。本情報処理装置は、サーバによるサービス提供の中断および再開の通知をサービスの稼働状況を監視する装置から受ける管理部と、サーバによるサービスの提供の中断の通知を管理部が受けると、通信において端末からサーバへ送信されるデータを保留する保留部と、サーバによるサービス提供の再開の通知を管理部が受けると、保留部によって保留されたデータをサーバに送信する送信部と、を備える。
【発明の効果】
【０００６】
本情報処理装置は、冗長化しないでコンピュータによるサービスの中断を抑制する。
【図面の簡単な説明】
【０００７】
【図１】第１比較例のシステムを例示する図である。
【図２】第１比較例のシステムのメンテナンス時の状態を例示する図である。
【図３】第２比較例のシステムを例示する図である。
【図４】旧ロジックでサービスを提供しているシステムを例示する図である
【図５】新ロジックに切り替えてサービスを提供しているシステムを例示する図である。
【図６】第３比較例のシステムを例示する図である。
【図７】第３比較例のシステムのメンテナンス時の状態を例示する図である。
【図８】第１実施形態のシステム構成を例示する図である。
【図９】情報処理装置のハードウェア構成を例示する図である。
【図１０】プロキシサーバの機能ブロックを例示する図である。
【図１１】アクセス変換情報部に記憶される情報を例示する図である。
【図１２】保留アクセス部に記憶される情報を例示する図である。
【図１３】アクセス管理情報部に記憶される情報を例示する図である。
【図１４】アクセス履歴部に記憶される情報を例示する図である。
【図１５】セッション情報部に記憶される情報を例示する図である。
【図１６】終了シーケンス部に記憶される情報を例示する図である。
【図１７】アクセスプロキシ部の処理の流れを例示する図である。
【図１８】モード管理部の処理の流れを例示する図である。
【図１９】アクセス依頼部の処理の流れを例示する図である。
【図２０】変換情報保存部の処理の流れを例示する図である。
【図２１】アクセス管理部の処理の流れを例示する図である。
【図２２】サービスアクセス部の処理の流れを例示する図である。
【図２３】モード処理振分部の処理の流れを例示する図である。
【図２４Ａ】終了処理部の処理の流れを例示する図である。
【図２４Ｂ】終了処理部が生成するデータの内容を例示する図である。
【図２５Ａ】ステート復元部の処理の流れを例示する図である。
【図２５Ｂ】ステート復元部が生成するデータの内容および当該データに対するサービスからの応答データの内容を例示する図である。
【図２５Ｃ】ステート復元後のアクセス変換情報部を例示する図である。
【図２６】サービスのアップデート時の処理の流れを例示する図である。
【図２７】変形例におけるプロキシクライアントのアップデート前の状態を例示する図である。
【図２８】変形例におけるプロキシクライアントのアップデート中の状態を例示する図である。
【図２９】変形例におけるプロキシクライアントのアップデート後の状態を例示する図である。
【図３０Ａ】変形例におけるアップデート後のプロキシサーバの機能ブロックを例示する図である。
【図３０Ｂ】インターフェース対応情報部に記憶される情報を例示する図である。
【図３０Ｃ】サービスアクセス部による接続方式の変換の処理の流れを例示する図である。
【図３１】第２実施形態の機能ブロックを例示する図である。
【図３２】第２実施形態のリカバリ処理の流れを例示する図である。
【図３３】第２実施形態のバックアップ処理の流れを例示する図である。
【発明を実施するための形態】
【０００８】
以下、図面を参照して、一実施形態に係る情報処理装置について説明する。以下に示す実施形態の構成は例示であり、本装置は実施形態の構成に限定されない。
【０００９】
＜第１比較例＞
図１は、第１比較例のシステムを例示する図である。図１では、負荷分散サーバ１、サービス２、データベース３が例示されている。サービス２は冗長化されたサーバ２ａ〜２ｃによって提供される。負荷分散サーバ１は、ユーザからのサービス２へのアクセスをサーバ２ａ〜２ｃに分散させる。ＤＢ３はサーバ２ａ〜２ｃによって共有されるデータベースである。第１比較例では、冗長化されたサーバ２ａ〜２ｃを提供するサーバを順番にメ
ンテナンスする、いわゆるローリングメンテナンスが例示される。
【００１０】
図２は、第１比較例のシステムのメンテナンス時の状態を例示する図である。図２では、例えば、メンテナンス等の理由によって、サーバ２ａがサービスの提供を中断している。そのため、負荷分散サーバ１は、ユーザからのアクセスをサーバ２ｂあるいはサーバ２ｃに分散させる。サーバ２ａのメンテナンスが終了され、サーバ２ａがサービス提供を再開する。その後、サーバ２ｂのメンテナンスが開始される。以後、サーバ２ｂおよびサーバ２ｃのメンテナンス時にも、負荷分散サーバ１は、メンテナンス中ではないサーバにユーザからのアクセスを分散させる。つまり、冗長化されたサーバは順番にメンテナンスされる。負荷分散サーバ１は、メンテナンスが実施されていないサーバにユーザからのアクセスを分散する。
【００１１】
第１比較例では、負荷分散サーバ１がメンテナンスされていないサーバにユーザからのアクセスを分散した。その結果、第１比較例はユーザへのサービスの中断を抑制する。しかし、第１比較例ではサービスの状態を示すステートを共有する仕組みを持たない。そのため、例えばログイン処理等のステートを管理するサービス（以下、本明細書においてステートフルなサービスと称する）に対して第１比較例のローリングメンテナンスを適用することは難しい。
【００１２】
＜第２比較例＞
第２比較例では、サービス内部でサービスのロジックを切り替えるシステムを例示する。第２比較例のシステムは、サービス内でロジックを入れ替え可能である。サービスのロジックとは、例えば、サービスを提供するプログラムモジュールである。第２比較例では、アップデートされたロジックがサービスに追加され、ロジックを切り替えることでアップデートされるシステムについて説明する。以下、図３〜図５を参照して、第２比較例のシステムについて説明する。
【００１３】
図３は、第２比較例のシステムを例示する図である。図３では、サーバ４、サービス２および旧ロジック２ｄが例示されている。旧ロジック２ｄはサービス２を提供するプログラムである。
【００１４】
図４は、旧ロジック２ｄでサービス２を提供しているシステムを例示する図である。図４では、サーバ４に新ロジック２ｅが追加されている。新ロジック２ｅは、旧ロジック２ｄの機能を改善したプログラムである。
【００１５】
図５は、新ロジック２ｅに切り替えてサービス２を提供しているシステムを例示する図である。図５では、サービス２を提供するプログラムを旧ロジック２ｄから新ロジック２ｅに切り替えている。第２比較例では、ロジック切り替えの前にあらかじめ新ロジック２ｅをサーバ４に組み込んでいる。その結果、第２比較例のシステムは、ロジックの切り替えが発生しても、ユーザへのサービス中断を抑制できる。しかし、第２比較例のシステムは、新旧ロジック間でステートを共有する仕組みを持たない。そのため、ステートフルなサービスに対してロジック切り替え機能を実装したシステムを適用することは難しい。
【００１６】
＜第３比較例＞
第３比較例では、サービス内部でステートを共有するシステムについて説明する。第３比較例のシステムでは、第１比較例のシステムにステートを共有する仕組みが追加される。第１比較例のシステムと共通の構成要素については同一の符号を付し、その説明は省略される。以下、図６と図７を参照して、第３比較例について説明する。
【００１７】
図６は、第３比較例のシステムを例示する図である。図６では、負荷分散サーバ１、サ
ービス２が例示されている。第３比較例では、サーバ２ａ〜２ｃにおいて、それぞれステート２ｆ〜ステート２ｈが共有されている。ステートの共有は、例えば、サーバ２ａ〜２ｃによって共有される記憶装置にステートの情報を保存すればよい。
【００１８】
図７は、第３比較例のシステムのメンテナンス時の状態を例示する図である。図７は、サーバ２ａがメンテナンスによりサービスの提供を中断している。しかしながら、サービスのステートを共有しているため、サーバ２ａのステートをサーバ２ｂ〜２ｃが引き継ぐ事が可能である。
【００１９】
第３比較例では、サーバ２ａ〜２ｃ間でステートを共有している。そのため、メンテナンス中に他のサーバにユーザからのアクセスを振り分けてもログイン処理等のステートを利用する処理を継続できる。そのため、第３比較例のシステムは、ステートフルなサービスにも適用できる。
【００２０】
以上で説明した各比較例は、サービスを提供するサーバあるいはロジックの冗長化を前提としている。そのため、冗長化されずにサービスが提供されているシステムに対して、各比較例のシステムを適用することは難しい。
【００２１】
＜第１実施形態＞
図８から図２６を参照して第１実施形態について説明する。第１実施形態では、クライアント端末とサービスを提供するサーバとの間にプロキシサーバが設けられる。プロキシサーバは、「サービスを提供するサーバと前記サーバからサービスの提供を受ける端末との間の通信を中継する情報処理装置」の一例である。サービスの提供が中断されている間は、プロキシサーバがクライアント端末から送信されるデータを保留する。サービスの提供が再開されると、プロキシサーバは保留したデータをサーバに送信する。第１実施形態では、サービス中断の一例として、サービスのアップデート作業を取り上げる。
【００２２】
図８は、第１実施形態のシステム構成を例示する図である。図８では、プロキシサーバ１０、サービス１１、クライアント１２およびネットワーク環境５が例示されている。プロキシサーバ１０、サービス１１を提供するサーバおよびクライアント１２はネットワーク環境５によって相互に接続されている。プロキシサーバ１０は、クライアント１２とサービス１１との通信経路上に設置される。プロキシサーバ１０は、サービス１１のメンテナンス時において、クライアント１２からサービス１１へ送信されるデータを保留する。サービス１１はクライアント１２に対して各種サービスを提供する。クライアント１２は、サービス１１からサービスの提供を受ける。プロキシサーバ１０、サービス１１を提供するサーバおよびクライアント１２は情報処理装置である。ネットワーク環境５は、各種の情報処理装置を相互に接続する通信経路である。ネットワーク環境５は、例えば、インターネットである。
【００２３】
クライアント１２は情報処理装置である。クライアント１２は、プロキシサーバ１０を経由してサービス１１にアクセスする。
【００２４】
サービス１１はサーバによって提供される。サーバは情報処理装置である。サービス１１は、クライアント１２に対してサービスを提供する。サービス１１は、例えば、ウェブサーバによって提供されるウェブサービスである。
【００２５】
プロキシサーバ１０は情報処理装置である。プロキシサーバ１０は、クライアント１２とサービス１１を提供するサーバとの通信経路上に設置される。プロキシサーバ１０は、アップデート等によるサービス１１の中断をクライアント１２から隠蔽する。
【００２６】
ネットワーク環境５は、プロキシサーバ１０、サービス１１を提供するサーバおよびクライアント１２を相互に接続する。ネットワーク環境５は、有線のネットワークでも無線のネットワークでもよい。ネットワーク環境５は、例えば、インターネット、Ｌｏｃａｌ
Ａｒｅａ  Ｎｅｔｗｏｒｋ（ＬＡＮ）、Ｖｉｒｔｕａｌ  Ｐｒｉｖａｔｅ  Ｎｅｔｗｏｒｋ（ＶＰＮ）、無線ＬＡＮ、携帯電話の電話回線等である。
【００２７】
図９は、情報処理装置１００のハードウェア構成を例示する図である。情報処理装置１００は、プロセッサ１０１、主記憶部１０２、補助記憶部１０３、通信部１０４および接続バスＢ１を含む。プロセッサ１０１、主記憶部１０２、補助記憶部１０３および通信部１０４は、接続バスＢ１によって相互に接続されている。情報処理装置１００は、プロキシサーバ１０、サービス１１を提供するサーバあるいはクライアント１２として利用できる。
【００２８】
情報処理装置１００は、プロセッサ１０１が補助記憶部１０３に記憶されたプログラムを主記憶部１０２の作業領域に実行可能に展開し、プログラムの実行を通じて周辺装置の制御を行う。これにより、情報処理装置１００は、所定の目的に合致した機能手段を実現することができる。主記憶部１０２及び補助記憶部１０３は、情報処理装置１００が読み取り可能な記憶媒体である。
【００２９】
主記憶部１０２は、プロセッサ１０１から直接アクセスされる記憶部として例示される。主記憶部１０２は、Ｒａｎｄｏｍ  Ａｃｃｅｓｓ  Ｍｅｍｏｒｙ（ＲＡＭ）およびＲｅａｄ  Ｏｎｌｙ  Ｍｅｍｏｒｙ（ＲＯＭ）を含む。
【００３０】
補助記憶部１０３は、各種のプログラム及び各種のデータを読み書き自在に記録媒体に格納する。補助記憶部１０３は外部記憶装置とも呼ばれる。補助記憶部１０３には、オペレーティングシステム（Ｏｐｅｒａｔｉｎｇ  Ｓｙｓｔｅｍ、ＯＳ）、各種プログラム、各種テーブル等が格納される。ＯＳは、通信部１０４を介して接続される外部装置等とのデータの受け渡しを行う通信インターフェースプログラムを含む。外部装置等には、例えば、ネットワーク等で接続された、他の映像処理装置および外部記憶装置が含まれる。なお、補助記憶部１０３は、例えば、ネットワーク上のコンピュータ群であるクラウドシステムの一部であってもよい。
【００３１】
補助記憶部１０３は、例えば、Ｅｒａｓａｂｌｅ  Ｐｒｏｇｒａｍｍａｂｌｅ  ＲＯＭ（ＥＰＲＯＭ）、ソリッドステートディスク（Ｓｏｌｉｄ  Ｓｔａｔｅ  Ｄｉｓｋ、ＳＳＤ）、ハードディスクドライブ（Ｈａｒｄ  Ｄｉｓｋ  Ｄｒｉｖｅ、ＨＤＤ）等である。また、補助記憶部１０３は、例えば、Ｃｏｍｐａｃｔ  Ｄｉｓｃ（ＣＤ）ドライブ装置、Ｄｉｇｉｔａｌ  Ｖｅｒｓａｔｉｌｅ  Ｄｉｓｃ（ＤＶＤ）ドライブ装置、Ｂｌｕ−ｒａｙ（登録商標）  Ｄｉｓｃ（ＢＤ）ドライブ装置等である。また、補助記憶部１０３は、Ｎｅｔｗｏｒｋ  Ａｔｔａｃｈｅｄ  Ｓｔｏｒａｇｅ（ＮＡＳ）あるいはＳｔｏｒａｇｅ
Ａｒｅａ  Ｎｅｔｗｏｒｋ（ＳＡＮ）によって提供されてもよい。記録媒体としては、例えば、不揮発性半導体メモリ（フラッシュメモリ）を含むシリコンディスク、ハードディスク、ＣＤ、ＤＶＤ、ＢＤ、Ｕｎｉｖｅｒｓａｌ  Ｓｅｒｉａｌ  Ｂｕｓ（ＵＳＢ）メモリ等である。
【００３２】
通信部１０４は、例えば、ネットワーク環境５とのインターフェースである。通信部１０４は、ネットワーク環境５を介して外部の装置と通信を行う。
【００３３】
情報処理装置１００は、例えば、ユーザ等からの操作指示等を受け付ける入力部をさらに備えてもよい。このような入力部として、キーボード、ポインティングデバイス、タッチパネル、加速度センサーあるいは音声入力装置といった入力デバイスを例示できる。
【００３４】
情報処理装置１００は、例えば、プロセッサ１０１で処理されるデータや主記憶部１０２に記憶されるデータを出力する出力部を備えるものとしてもよい。このような、出力部として、Ｃａｔｈｏｄｅ  Ｒａｙ  Ｔｕｂｅ（ＣＲＴ）ディスプレイ、Ｌｉｑｕｉｄ  Ｃｒｙｓｔａｌ  Ｄｉｓｐｌａｙ（ＬＣＤ）、Ｐｌａｓｍａ  Ｄｉｓｐｌａｙ  Ｐａｎｅｌ（ＰＤＰ）、Ｅｌｅｃｔｒｏｌｕｍｉｎｅｓｃｅｎｃｅ（ＥＬ）パネル、有機ＥＬパネルあるいはプリンタといった出力デバイスを例示できる。
【００３５】
＜第１実施形態の機能ブロック＞
図１０は、プロキシサーバ１０の機能ブロックを例示する図である。図１０では、プロキシサービス１０ａ、プロキシクライアント１０ｂ、運用管理部２２０、クライアント１２およびサービス１１の各ブロックが例示されている。例えば、図９のプロセッサ１０１が図１０の各ブロックとして主記憶部１０２に実行可能に展開されたコンピュータプログラムを実行する。ただし、図１０のいずれかのブロックの少なくとも一部はハードウェア回路を含んでもよい。プロキシサーバ１０、サービス１１を提供するサーバ、クライアント１２および運用管理部２２０はネットワーク環境５によって相互に接続されている。以下、図１０を参照して、プロキシサーバ１０の各機能ブロックについて説明する。
【００３６】
プロキシサーバ１０は情報処理装置である。プロキシサーバ１０は、クライアント１２とサービス１１を提供するサーバとの通信経路上に設置される。プロキシサーバ１０は、プロキシサービス１０ａおよびプロキシクライアント１０ｂを含む。プロキシサーバ１０は、アップデート等によるサービス１１の中断をクライアント１２から隠蔽する。
【００３７】
サービス１１がアップデートされている間、サービス１１によってクライアント１２へ提供されるサービスは中断される虞がある。そこで、プロキシサーバ１０は、運用管理部２２０からサービス１１のアップデートを通知されると、クライアント１２とサービス１１との間のセッションを終了する処理を行う。セッションは、サービス１１とクライアント１２との接続関係である。セッションを示すセッション情報は、少なくとも１つの引数を含む。引数は、クライアント１２からサービス１１に渡されるパラメータということができる。また、プロキシサーバ１０は、サービス１１のアップデート中、クライアント１２からサービス１１へ送信されるデータを保留する。
【００３８】
プロキシサーバ１０は、アップデート後のサービス１１の起動を運用管理部２２０から通知されると、サービス１１のステートを復元する処理を行う。ステートの復元処理は、セッションの開始およびサービス１１のステートの復元を含む。ステートの復元では、プロキシサーバ１０は、クライアント１２からサービス１１へ送信されるデータを再現する。そのため、プロキシサーバ１０は、クライアント１２とサービス１１との通信の履歴を保存している。
【００３９】
ステートの復元を行うと、セッションは新たに開始される。そのため、サービス１１の中断前におけるセッション情報と再開後におけるセッション情報は異なることが多い。ここで、保留されたデータにはサービス１１の中断前におけるセッション情報が付与されている。そのため、プロキシサーバ１０が保留されたデータを送信しても、サービス１１はそのデータを受信しない虞がある。
【００４０】
そこで、プロキシサーバ１０は、あらかじめクライアント１２とサービス１１とのセッション情報を保存する。プロキシサーバ１０は、保存したセッション情報を参照することで、保留されたデータに含まれるセッション情報を再開後のサービス１１のセッション情報に変換する。その後、プロキシサーバ１０はサービス１１に保留されたデータを送信すればよい。
【００４１】
クライアント１２は、セッション情報がサービス１１の再開後に変更されていることを通知されていない。そのため、クライアント１２は、サービス１１の再開後もサービス１１の中断前のセッション情報を付与してデータを送信する。プロキシサーバ１０は、クライアント１２から受信したデータに付与されているセッション情報を再開後のサービス１１のセッション情報に変換する。その後、プロキシサーバ１０は、クライアント１２から受信したデータをサービス１１に送信すればよい。
【００４２】
以上の処理を行うことで、プロキシサーバ１０は、クライアント１２に対してサービス１１の中断を隠蔽する事が出来る。
【００４３】
プロキシサービス１０ａは、クライアント１２とプロキシクライアント１０ｂとの間の通信を中継する。プロキシサービス１０ａは、クライアント１２、運用管理部２２０およびプロキシクライアント１０ｂからの通信を受け付ける。プロキシサービス１０ａは、アクセスプロキシ部２０１、アクセス依頼部２０２、モード管理部２０３、アクセス変換情報部２０４、変換情報保存部２０５および保留アクセス部２０６を含む。
【００４４】
アクセスプロキシ部２０１は、クライアント１２から送信されるデータを受け付ける。アクセスプロキシ部２０１は、設定されるモードによって処理を切り替える。アクセスプロキシ部２０１のモードは、通常モードおよびアップデートモードを含む。アクセスプロキシ部２０１のモードは、モード管理部２０３からのモードを変更する指示によって変更される。以下、本明細書においてモード管理部２０３からアクセスプロキシ部２０１へのモードを変更する指示をモード変更通知と称する。モードが通常モードに設定されている場合、アクセスプロキシ部２０１は、クライアント１２から送信されたデータをアクセス依頼部２０２へと送信する。モードがアップデートモードに設定されている場合、アクセスプロキシ部２０１は、クライアント１２から送信されたデータを保留する。保留されたデータは、例えば主記憶部１０２に設けられた保留アクセス部２０６に蓄積される。保留されたデータは、アクセスプロキシ部２０１のモードがアップデートモードから通常モードに切り替わったときにアクセス依頼部２０２へ送信される。アクセスプロキシ部２０１は、「送信部」の一例である。
【００４５】
アクセス依頼部２０２は、アクセスプロキシ部２０１からのデータを受け付ける。少なくとも１つの引数を含みサービス１１とクライアント１２との間の接続関係を示すセッション情報は、サービス１１の再開後、後述するステートを復元する処理によって変更される場合がある。クライアント１２は、セッション情報が変更された場合でも、中断前のサービス１１のセッション情報を使用して再開後のサービス１１に対してデータを送信する。そこで、アクセス依頼部２０２は、サービス１１の中断前のセッション情報と再開後のセッション情報を記憶するアクセス変換情報部２０４を参照して、クライアント１２から受け付けたデータを変換するか否かを決定する。アクセス依頼部２０２は、例えば、クライアント１２から受け取ったデータに含まれる宛先ＵＲＬ情報およびサービス１１に渡す引数とアクセス変換情報部２０４に記憶された情報が一致した場合、受け付けたデータを変換対象とする。受け付けたデータを変換しない場合、アクセス依頼部２０２は受け付けたデータをそのままプロキシクライアント１０ｂに送信する。受け付けたデータを変換する場合、アクセス依頼部２０２はアクセス変換情報部２０４を参照してデータを変換し、変換後のデータをプロキシクライアント１０ｂに送信する。アクセス依頼部２０２は、「変換部」の一例である。
【００４６】
モード管理部２０３は、運用管理部２２０からの通知に基づいてアクセスプロキシ部２０１にモード変更通知を行う。モード管理部２０３は、運用管理部２２０からの通知をモード処理振分部２１４に通知する。モード管理部２０３は、「管理部」の一例である。
【００４７】
アクセス変換情報部２０４は、変換対象となるデータを特定するＵｎｉｆｏｒｍ  Ｒｅｓｏｕｒｃｅ  Ｌｏｃａｔｏｒ（ＵＲＬ）情報を記憶する。また、サービス中断前のサービス１１とクライアント１２との間のセッション情報およびサービス再開後のサービス１１とクライアント１２との間のセッション情報を記憶する。アクセス依頼部２０２は、アクセス変換情報部２０４の情報を基に、アクセスプロキシ部２０１から受け付けたデータが変換対象であるか決定する。アクセス変換情報部２０４は、図９の主記憶部１０２あるいは補助記憶部１０３に設けられれば良い。なお、アクセス変換情報部２０４に記憶される情報は、後述するプロキシクライアント１０ｂのセッション情報部２１２に記憶される情報と同一である。そのため、アクセス依頼部２０２がプロキシクライアント１０ｂのセッション情報部２１２を利用できるのであれば、アクセス変換情報部２０４を設けなくともよい。アクセス変換情報部２０４は、「セッション情報記憶部」の一例である。
【００４８】
変換情報保存部２０５は、プロキシクライアント１０ｂのアクセス管理部２１０の要求に基づいてアクセス変換情報部２０４に記憶されている情報を更新する。
【００４９】
保留アクセス部２０６には、アクセスプロキシ部２０１によって保留されたデータが保存される。保留アクセス部２０６は、図９の主記憶部１０２あるいは補助記憶部１０３に設けられれば良い。保留アクセス部２０６は、「保留部」の一例である。
【００５０】
プロキシクライアント１０ｂは、プロキシサービス１０ａとサービス１１との間の通信を中継する。プロキシクライアント１０ｂは、アクセス管理部２１０、アクセス履歴部２１１、セッション情報部２１２、ステート復元部２１３、モード処理振分部２１４、終了処理部２１５、終了シーケンス部２１６、サービスアクセス部２１７およびアクセス管理情報部２１８を含む。
【００５１】
アクセス管理部２１０は、アクセス依頼部２０２またはステート復元部２１３からのデータを受け付ける。アクセス管理部２１０は、受け付けたデータをサービスアクセス部２１７に送信する。また、アクセス管理部２１０は、サービス１１からの応答をサービスアクセス部２１７から受信する。アクセス管理部２１０は、アクセス依頼部２０２からデータを受け付けるとアクセス管理情報部２１８を参照し、そのデータが通信履歴を保存する対象（以下、本明細書において管理対象と称する）であるか否か判定する。管理対象のデータである場合、アクセス管理部２１０は、クライアント１２とサービス１１の間の通信の履歴をアクセス履歴部２１１に保存する。ここでは、例えば、アクセス依頼部２０２から受信したデータおよびサービス１１からの応答等の情報がクライアント１２毎にアクセス履歴部２１１に保存される。さらに、アクセス管理部２１０は、サービス１１とクライアント１２との間のセッション情報をセッション情報部２１２に記憶する。
【００５２】
アクセス履歴部２１１は、クライアント１２とサービス１１の間の通信の履歴をクライアント１２毎に記憶する。アクセス履歴部２１１は、通信の履歴をセッション毎にグループ分けして記憶してもよい。アクセス履歴部２１１は、図９の主記憶部１０２あるいは補助記憶部１０３に設けられれば良い。アクセス履歴部２１１は、「履歴保存部」の一例である。
【００５３】
セッション情報部２１２は、ＵＲＬ情報、サービス中断前のサービス１１とクライアント１２との間のセッション情報およびサービス再開後のサービス１１とクライアント１２との間のセッション情報を記憶する。セッション情報部２１２は、図９の主記憶部１０２あるいは補助記憶部１０３に設けられれば良い。なお、セッション情報部２１２に記憶されている情報は、プロキシサービス１０ａのアクセス変換情報部２０４と同一である。そのため、アクセス管理部２１０、ステート復元部２１３および終了処理部２１５がプロキ
シサービス１０ａのアクセス変換情報部２０４を利用できるのであれば、セッション情報部２１２を設けなくともよい。セッション情報部２１２は、「セッション情報記憶部」の一例である。
【００５４】
ステート復元部２１３は、サービス１１のアップデート後にセッションの復元をアクセス管理部２１０に要求する。ステート復元部２１３は、アクセス管理部２１０に対し、アクセス履歴部２１１に基づくサービス１１へのアクセスを要求してステートを復元する。なお、ステート復元部２１３による通信は、アクセス履歴部２１１に保存されなくてよい。ステート復元部２１３およびアクセス管理部２１０は、「復元部」の一例である。
【００５５】
モード処理振分部２１４は、モード管理部２０３からサービス１１のアップデート開始およびアップデート終了の指示を受信する。モード管理部２０３からアップデート開始を通知された場合、モード処理振分部２１４は、アップデートの開始を終了処理部２１５に通知する。終了処理部２１５による処理が完了すると、モード処理振分部２１４は、モード管理部２０３に終了処理部２１５による処理の完了を通知する。モード管理部２０３からアップデート終了を通知された場合、モード処理振分部２１４は、ステート復元部２１３にステートを復元する処理を要求する。ステート復元部２１３によるステートを復元する処理が完了すると、モード処理振分部２１４は、モード管理部２０３にステートの復元処理の完了を通知する。
【００５６】
終了処理部２１５は、サービス１１がアップデートされる前にセッションを終了する処理を行う。終了処理部２１５は、セッション情報部２１２および終了シーケンス部２１６に基づいてサービス１１へのアクセス要求を生成する。生成されたアクセス要求は、サービスアクセス部２１７によってサービス１１に送信される。終了処理部２１５は、「セッション終了部」の一例である。
【００５７】
終了シーケンス部２１６は、サービス１１とのセッションを終了させる処理の流れを記憶する。終了シーケンス部２１６に記憶される情報は、例えば、プロキシサーバ１０の初期設定時に登録されればよい。プロキシサーバ１０の運用開始後にサービス１１が追加された場合、追加されたサービス１１を終了させる処理の流れを終了シーケンス部２１６に追加登録すればよい。終了シーケンス部２１６は、図９の主記憶部１０２あるいは補助記憶部１０３に設けられれば良い。終了シーケンス部２１６は、「終了手順記憶部」の一例である。
【００５８】
サービスアクセス部２１７は、アクセス管理部２１０または終了処理部２１５からのデータをサービス１１へ送信する。また、サービスアクセス部２１７は、サービス１１からの応答を受信する。受信した応答は、アクセス管理部２１０または終了処理部２１５に送信される。
【００５９】
アクセス管理情報部２１８は、管理対象となるデータを特定する情報を保存する。アクセス管理情報部２１８は、サービス１１のＵＲＬ情報およびアクセス時のメソッドを含む。アクセス管理情報部２１８は、セッション情報をさらに含んでもよい。アクセス管理情報部２１８は、アクセス管理部２１０から参照される。アクセス管理情報部２１８に記憶される情報は、例えば、プロキシサーバ１０の初期設定時に登録されればよい。プロキシサーバ１０の運用開始後にサービス１１が追加された場合、追加されたサービス１１において管理対象となるデータを特定する情報をアクセス管理情報部２１８に追加登録すればよい。アクセス管理情報部２１８は、図９の主記憶部１０２あるいは補助記憶部１０３に設けられれば良い。アクセス管理情報部２１８は、「特定部」の一例である。
【００６０】
運用管理部２２０は、サービス１１の稼働状況を監視する。また、運用管理部２２０は
、サービス１１のアップデートを実施する。運用管理部２２０は、サービス１１のアップデートの開始および完了をモード管理部２０３に通知する。運用管理はサービス１１をアップデートする場合、アップデートの開始をモード管理部２０３に通知する。モード管理部２０３からアップデート開始の準備が完了した通知を受けると、運用管理部２２０はサービス１１のアップデートを開始する。サービス１１のアップデートが完了すると、運用管理部２２０は、モード管理部２０３にアップデート完了を通知する。運用管理部２２０は、「前記サーバによるサービス提供の中断および再開の通知を前記サービスの稼働状況を監視する装置」の一例である。
【００６１】
図１１は、アクセス変換情報部２０４に記憶される情報を例示する図である。例えば、サービス１１の中断前後でセッション情報が変更された場合、アクセス変換情報部２０４に記憶される情報を参照することで、アクセス依頼部２０２はクライアント１２からのデータを変換する。以下、図１１を参照してアクセス変換情報部２０４に記憶される情報を説明する。
【００６２】
アクセス変換情報部２０４には、変換対象ＵＲＬ２０４ａ、変換対象引数２０４ｂ、クライアント２０４ｃ、変換前の値２０４ｄおよび変換後の値２０４ｅが記憶される。
【００６３】
変換対象ＵＲＬ２０４ａには、アクセス依頼部２０２による変換の対象となるデータを特定するＵＲＬが記憶される。変換対象引数２０４ｂには、アクセス依頼部２０２による変換の対象となる引数が記憶される。クライアント２０４ｃは、クライアント１２を識別する情報が記憶される。図１１では、クライアント２０４ｃとしてＩＰアドレスが記憶されている。しかしながら、クライアント２０４ｃはＩＰアドレスに限定されない。クライアント２０４ｃは、例えば、ＭＡＣアドレスあるいはホスト名等であってもよい。クライアント２０４ｃは、クライアント１２を識別可能な情報であればよい。変換前の値２０４ｄは、変換対象引数２０４ｂに設定される変換前の値を記憶する。変換前の値は、例えば、アップデート前のサービス１１とクライアント１２との間の通信で使用される引数の値である。変換後の値２０４ｅは、変換対象引数２０４ｂに設定される変換後の値を記憶する。変換後の値は、例えば、アップデート後のサービス１１とクライアント１２との間の通信で使用される引数の値である。
【００６４】
図１２は、保留アクセス部２０６に記憶される情報を例示する図である。サービスが中断している間、アクセスプロキシ部２０１はクライアントから受信したデータを保留アクセス部２０６に記憶する。保留アクセス部２０６には、クライアント２０６ａ、ＵＲＬ２０６ｂ、メソッド２０６ｃおよび要求２０６ｄが記憶される。以下、図１２を参照して保留アクセス部２０６に記憶される情報について説明する。
【００６５】
クライアント２０６ａには、クライアント１２を識別する情報が記憶される。図１２では、クライアント２０６ａとしてＩＰアドレスが記憶されている。しかしながら、クライアント２０６ａはＩＰアドレスに限定されない。クライアント２０６ａは、例えば、ＭＡＣアドレスあるいはホスト名等であってもよい。クライアント２０６ａは、クライアント１２を識別可能な情報であればよい。ＵＲＬ２０６ｂには、クライアント１２がアクセスするＵＲＬが記憶される。メソッド２０６ｃには、サービスにアクセスする際に用いられるメソッドが記憶される。メソッド２０６ｃに記憶されるメソッドは、例えば、ＨＴＴＰのメソッドである。要求２０６ｄには、クライアント１２からサービス１１に送信された要求が記憶される。
【００６６】
図１３は、アクセス管理情報部２１８に記憶される情報を例示する図である。アクセス管理情報部２１８には、管理対象となるデータを特定する情報が記憶される。アクセス管理部２１０は、アクセス管理情報部２１８に記憶された情報を参照することで、管理対象
のデータを特定する。アクセス管理情報部２１８には、管理対象ＵＲＬ２１８ａ、メソッド２１８ｂ、変換対象ＵＲＬ２１８ｃ、変換対象引数２１８ｄおよびセッションフラグ２１８ｅが記憶される。以下、図１３を参照してアクセス管理情報部２１８に記憶される情報について説明する。
【００６７】
管理対象ＵＲＬ２１８ａには、管理対象となるサービスのＵＲＬが記憶される。管理対象となるサービスのＵＲＬとは、例えば、クライアント１２からサービス１１への通信およびサービス１１からクライアント１２への通信において、通信履歴を保存する通信を特定するＵＲＬである。メソッド２１８ｂには、クライアント１２からサービス１１へのアクセスで用いられるメソッドが記憶される。
【００６８】
さらに、アクセス管理情報２１８は、セッション情報記憶部２１２に記憶する対象を特定する情報も記憶される。セッション情報部２１２に記憶する対象は、サービス１１からクライアント１２へ応答するデータにセッション情報が含まれるデータである。変換対象ＵＲＬ２１８ｃには、セッション情報部２１２に記憶する対象となる通信を特定するＵＲＬが記憶される。変換対象引数２１８ｄには、セッション情報部２１２に記憶する対象となる引数が記憶される。セッションフラグ２１８ｅには、アクセス履歴部２１１にアクセスの履歴を記録する際にセッションのグループを作成するか否かを示すフラグ情報が記憶される。セッションフラグ２１８ｅがオンに設定（ｔｒｕｅに設定）されると、当該通信の履歴はセッション情報とともにアクセス履歴部２１１に保存される。
【００６９】
図１４は、アクセス履歴部２１１に記憶される情報を例示する図である。アクセス履歴部２１１には、アクセス管理部２１０によってクライアント１２とサービス１１との間の通信履歴が記憶される。アクセス履歴部２１１に記憶された情報は、ステート復元部２１３によるセッションの復元処理に用いられる。アクセス履歴部２１１はクライアント１２毎に情報を記憶する。アクセス履歴部２１１には、セッション２１１ａ、ＵＲＬ２１１ｂ、引数２１１ｃ、メソッド２１１ｄ、要求２１１ｅおよび返答２１１ｆが記憶される。以下、図１４を参照して、アクセス履歴部２１１に記憶される情報について説明する。
【００７０】
セッション２１１ａは、セッションを示すセッション情報が記憶される。ＵＲＬ２１１ｂは、サービス１１のＵＲＬが記憶される。引数２１１ｃは、クライアント１２がサービス１１へアクセスする際に引数として渡される値を記憶する。メソッド２１１ｄは、クライアント１２からサービス１１へデータを送信する際に用いられるメソッドを記憶する。要求２１１ｅは、クライアント１２からサービス１１へ送信される要求を記憶する。返答２１１ｆは、サービス１１からクライアント１２への応答が記憶される。
【００７１】
図１５は、セッション情報部２１２に記憶される情報を例示する図である。セッション情報部２１２に記憶される情報は、例えば、終了処理部２１５によるクライアント１２とサービス１１との間のセッションを終了する処理に用いられる。また、セッション情報部２１２に記憶される情報は、例えば、ステート復元部２１３によるステートを復元する処理に使用される。セッション情報部２１２には、変換対象ＵＲＬ２０４ａ、変換対象引数２０４ｂ、クライアント２０４ｃ、変換前の値２０４ｄおよび復元後の値２１２ｅが記憶される。セッション情報部２１２に記憶される情報は、アクセス変換情報部２０４と同一である。そのため、セッション情報部２１２に記憶される情報についての説明は省略される。なお、アクセス変換情報部２０４の変換後の値２０４ｅは、セッション情報部２１２においては復元後の値２１２ｅと称する。
【００７２】
図１６は、終了シーケンス部２１６に記憶される情報を例示する図である。終了シーケンス部２１６には、クライアント１２とサービス１１との間のセッションを終了する際に用いられる情報が記憶される。クライアント１２とサービス１１との間のセッションを終
了する際、終了処理部２１５は終了シーケンス２１６に記憶されている情報を参照する。終了シーケンス部２１６には、ＵＲＬ２１６ａ、引数２１６ｂ、メソッド２１６ｃおよび要求２１６ｄが記憶される。以下、図１６を参照して終了シーケンス部２１６に記憶される情報について説明する。
【００７３】
ＵＲＬ２１６ａは、セッションを終了する対象となるサービス１１のＵＲＬ情報を記憶する。引数２１６ｂは、ＵＲＬ２１６ａと併せてサービス１１に通知される引数を記憶する。メソッド２１６ｃは、ＵＲＬ２１６ａに記憶されたＵＲＬにデータを送信する際に用いられるメソッドを記憶する。要求２１６ｄは、セッションを終了する際にサービス１１に送信される要求を記憶する。図１６では、さらに説明の便宜上（１）〜（４）の数字を図１６の表の左側に付している。終了処理部２１５は、終了シーケンス部２１６に記憶されている各行の処理を（１）〜（４）の順に処理することで、セッションを終了する処理を行う。
【００７４】
＜各機能ブロックの処理の流れ＞
図１７から図２５Ｃは各機能ブロックの処理の流れを例示している。以下、図１７から図２５Ｃを参照して、各機能ブロックの処理の流れを説明する。
【００７５】
＜アクセスプロキシ部２０１の処理の流れ＞
図１７は、アクセスプロキシ部２０１の処理の流れを例示する図である。アクセスプロキシ部２０１は、モード管理部２０３からモード変更通知を受信する。また、アクセスプロキシ部２０１は、クライアント１２からのデータをアクセス依頼部２０２へと中継する。以下、図１７を参照してアクセスプロキシ部２０１の処理について説明する。
【００７６】
図１７のＳ２０１からＳ２０５を参照して、モード管理部２０３からモード変更通知を受信した場合のアクセスプロキシ部２０１の処理が説明される。
【００７７】
アクセスプロキシ部２０１は、受け付けたデータがモード管理部２０３からのモード変更通知であるか確認する（Ｓ２０１）。受け付けたデータがモード変更通知である場合、アクセスプロキシ部２０１は、指定されたモードに変更される（Ｓ２０２）。アクセスプロキシ部２０１は、設定されているモードが通常モードであるか確認する。通常モードでない場合（Ｓ２０３でＮＯ）、アクセスプロキシ部２０１は処理を終了する（Ｓ２０３）。通常モードである場合（Ｓ２０３でＹＥＳ）、アクセスプロキシ部２０１は保留しているデータがあるか保留アクセス部２０６を確認する。保留されているデータが無い場合（Ｓ２０４でＮＯ）、アクセスプロキシは処理を終了する（Ｓ２０４）。保留されているデータがある場合（Ｓ２０４でＹＥＳ）、アクセスプロキシ部２０１は保留アクセス部２０６に保存されているデータを読み込む。アクセスプロキシ部２０１は、読み込んだデータをアクセス依頼部２０２へ送信する。アクセスプロキシ部２０１は、アクセス依頼部２０２へ送信したデータを保留アクセス部２０６から消去する。Ｓ２０５の保留されているデータを送信する処理は、「送信ステップ」の一例である（Ｓ２０５）。
【００７８】
次に、図１７のＳ２０６からＳ２０８を参照して、クライアント１２からのデータを受信した場合のアクセスプロキシ部２０１の処理が説明される。
【００７９】
アクセスプロキシ部２０１は、設定されているモードが通常モードであるか確認する（Ｓ２０６）。通常モードである場合（Ｓ２０６でＹＥＳ）、アクセスプロキシ部２０１は、受信したデータをアクセス依頼部２０２へ送信する（Ｓ２０７）。通常モードではない場合（Ｓ２０６でＮＯ）、アクセスプロキシ部２０１は、受信したデータを保留アクセス部２０６に保存する。Ｓ２０８の処理は、「保留ステップ」の一例である（Ｓ２０８）。
【００８０】
以上の処理により、アクセスプロキシ部２０１は、クライアント１２から受信したデータをアクセス依頼部２０２に送信できる。また、アクセスプロキシ部２０１は、サービス１１の中断中にクライアント１２から受信したデータを保留できる。アクセスプロキシ部２０１は、保留したデータを保留アクセス部２０６に記憶すればよい。さらに、アクセスプロキシ部２０１は、保留アクセス部２０６に記憶されたデータをサービス１１に送信できる。
【００８１】
＜モード管理部２０３の処理の流れ＞
図１８は、モード管理部２０３の処理の流れを例示する図である。モード管理部２０３は、運用管理部２２０からの通知を受けて、アクセスプロキシ部２０１にモードの変更を指示する。また、モード処理振分部２１４にアップデート開始および終了を通知する。以下、図１８を参照してモード管理部２０３の処理について説明する。
【００８２】
まず、図１８のＳ３０１からＳ３０３を参照して、運用管理部２２０からアップデート開始の通知を受けた場合のモード管理部２０３の処理について説明する。
【００８３】
モード管理部２０３は、運用管理部２２０からの通知を受信する。Ｓ３０１の処理は、「管理ステップ」の一例である（Ｓ３０１）。運用管理部２２０から受信した通知がアップデートの開始であった場合（Ｓ３０１でＹＥＳ）、モード管理部２０３はアクセスプロキシ部２０１に対しアップデートモードへの変更を指示する（Ｓ３０２）。モード管理部２０３は、アップデートの開始をモード処理振分部２１４に通知する（Ｓ３０３）。モード管理部２０３は、モード処理振分部２１４からの処理終了を受け、運用管理部２２０へアップデート開始処理完了を返す。
【００８４】
次に、図１８のＳ３０４からＳ３０６を参照して、運用管理部２２０からの通知がアップデート開始以外である場合のモード管理部２０３の処理について説明する。
【００８５】
運用管理部２２０からの通知がアップデートの終了の通知であるか判定する。Ｓ３０４の処理は、「管理ステップ」の一例である（Ｓ３０４）。運用管理部２２０からの通知がアップデートの終了の通知である場合（Ｓ３０４でＹＥＳ）、モード管理部２０３はアップデートの終了をモード処理振分部２１４に通知する（Ｓ３０５）。モード管理部２０３は、モード処理振分部２１４からの処理終了を受け、アクセスプロキシ部２０１に対し通常モードへの変更を指示する（Ｓ３０６）。運用管理部２２０からの通知がアップデートの終了の通知ではない場合（Ｓ３０４でＮＯ）、モード管理部２０３は処理を終了する。
【００８６】
以上の処理により、モード管理部２０３は、運用管理部２２０からの通知に基づいてアクセスプロキシ部２０１およびモード処理振分部２１４に処理を指示できる。
【００８７】
＜アクセス依頼部２０２の処理の流れ＞
図１９は、アクセス依頼部２０２の処理の流れを例示する図である。アクセス依頼部２０２はアクセスプロキシ部２０１からのデータをアクセス管理部２１０に中継する。アクセス依頼部２０２は、アクセスプロキシ部２０１からのデータが変換対象である場合、当該データを変換してからアクセス管理部２１０に中継する。以下、図１９を参照して、アクセス依頼部２０２の処理について説明する。
【００８８】
アクセス依頼部２０２は、アクセスプロキシ部２０１からのデータを受信する。アクセス依頼部２０２は、アクセス変換情報部２０４を参照して受信したデータが変換対象であるか判定する。この判定は、例えば、受信したデータの宛先ＵＲＬ、引数および送信元ＩＰアドレスがアクセス変換情報部２０４に記憶された変換対象ＵＲＬ２０４ａ、変換対象引数２０４ｂおよびクライアント２０４ｃが一致するか否かで判定される（Ｓ４０１）。
受信したデータが変換対象である場合（Ｓ４０２でＹＥＳ）、アクセス依頼部２０２は、アクセス変換情報部２０４に記憶された情報を基にデータを変換する。Ｓ４０３の処理は、「変換ステップ」の一例である（Ｓ４０３）。
【００８９】
例えば、Ｓ４０３の処理は、図１１に例示されている情報がアクセス変換情報部２０４に保存されている場合、以下のように例示される。ＩＰアドレスが「192.168.1.22」であるクライアントから「http://192.168.1.10/service1?id=1240」というデータが送信される。送信されたデータはアクセスプロキシ部２０１を経由してアクセス依頼部２０２が受信する。アクセス依頼部２０２は、受信したデータとアクセス変換情報部２０４を比較する。アクセス依頼部は、受信したデータのＵＲＬ、引数およびクライアントがアクセス変換情報部２０４に保存されている情報と一致すると判断する。その結果、アクセス依頼部２０２はそのデータを「http://192.168.1.10/service1?id=1251」に変換する。また、別のケースとして、ＩＰアドレスが「192.168.1.22」であるクライアントから「http://192.168.1.10/service1/sub?id=1240&subid=1」という通信がされた場合を考える。この場合、アクセス依頼部２０２は、アクセス変換情報部２０４を参照して、受信したデータを「http://192.168.1.10/service1/sub?id=1251&subid=2」に変換する。また、さらに別のケースとして、例えば、ＩＰアドレス192.168.1.20であるクライアントから「http://192.168.1.10/service1/sub?id=1234&subid=1」というデータが送信された場合を考える。この場合、アクセス変換情報部２０４を参照すると変換対象引数である「id」および「subid
」の値が変換の前後で同じである。そのため、アクセス依頼部２０２はこのデータを変換しなくともよい。
【００９０】
図１１を参照した上記の例では、変換対象ＵＲＬ２０４ａに記憶されたＵＲＬ情報がクライアント１２から送信されたデータの宛先ＵＲＬに含まれる場合、当該データが変換の対象とされた。しかしながら、アクセス依頼部２０２による処理は、このような構成に限定されない。アクセス依頼部２０２は、例えば、変換対象ＵＲＬ２０４ａに記憶されたＵＲＬ情報とクライアント１２から送信されたデータの宛先ＵＲＬが完全に一致する場合に、当該データを変換対象であるとしてもよい。
【００９１】
図１１を参照した上記の例では、変換対象引数２０４ｂは、ＨＴＴＰの引数となっている。しかしながら、変換対象引数２０４ｂは、ＨＴＴＰの引数に限定されない。変換対象引数２０４ｂは、例えば、ＵＲＬ情報の一部に含まれていてもよい。ＵＲＬ情報の一部に引数を含む例として、例えば、「http:/ http://192.168.1.10/service1/1234/1」を例示できる。この例の場合、引数の値として「1234」および「1」がＵＲＬ情報に含まれてい
る。この例の場合、ＵＲＬ情報における引数の位置を特定する情報がアクセス変換情報部２０４に記憶されればよい。
【００９２】
図１９に戻って、アクセス依頼部２０２の処理の流れについて説明が続けられる。受信したデータが変換対象ではない場合、アクセス依頼部２０２は受信したデータを変換しない（Ｓ４０２でＮＯ）。アクセス依頼部２０２は、データをアクセス管理部２１０へ中継する（Ｓ４０４）。
【００９３】
以上の処理により、アクセス依頼部２０２は、アクセスプロキシ部２０１から受信したデータをアクセス管理部２１０に送信できる。また、アクセス依頼部２０２は、アクセス変換情報部２０４を参照することで、アクセスプロキシ部２０１から受信したデータを変換できる。その結果、セッション情報がサービス１１の中断前後で異なっている場合でも、サービス１１は、クライアント１２から送信されたデータを受信できる。
【００９４】
＜変換情報保存部２０５の処理の流れ＞
図２０は、変換情報保存部２０５の処理の流れを例示する図である。変換情報保存部２
０５は、アクセス管理部２１０からの指示によって変換されたデータを保存する。以下、図２０を参照して、変換情報保存部２０５の処理の流れについて説明する。
【００９５】
変換情報保存部２０５は、アクセス管理部２１０から変換対象ＵＲＬ２０４ａ、変換対象引数２０４ｂ、クライアントＩＰアドレス２０４ｃ、変換前の値２０４ｄおよび変換後の値２０４ｅを受信する。変換対象ＵＲＬ２０４ａ、変換対象引数２０４ｂ、クライアントＩＰアドレス２０４ｃおよび変換前の値２０４ｄの値が受信した情報と一致する情報が既にアクセス変換情報部２０４に記憶されている場合、変換情報保存部２０５は変換後の値２０４ｅを更新する。変換対象ＵＲＬ２０４ａ、変換対象引数２０４ｂ、クライアントＩＰアドレス２０４ｃおよび変換前の値２０４ｄの値が受信した情報と一致する情報がアクセス変換情報部２０４に記憶されていない場合、変換情報保存部２０５はアクセス管理部２１０から受信した情報をアクセス変換情報部２０４に新規の情報として保存する（Ｓ５０１）。
【００９６】
以上の処理により、変換情報部２０５は、アクセス管理部２１０からの依頼に基づいて、アクセス変換情報部２０４に記憶される情報を更新できる。
【００９７】
＜アクセス管理部２１０の処理の流れ＞
図２１は、アクセス管理部２１０の処理の流れを例示する図である。アクセス管理部２１０は、アクセス依頼部２０２からのデータをサービスアクセス部２１７に中継する。以下、図２１を参照して、アクセス管理部２１０の処理の流れについて説明する。
【００９８】
アクセス管理部２１０は、アクセス依頼部２０２からのデータを受信する。アクセス管理部２１０は、受信したデータをサービスアクセス部２１７に送信する（Ｓ６０１）。アクセス管理部２１０は、サービス１１からの応答をサービスアクセス部２１７経由で受信する（Ｓ６０２）。アクセス管理部２１０は、アクセス依頼部２０２から受信したデータが管理対象であるか確認する。アクセス管理部２１０は、例えば、アクセス依頼部２０２から受信したデータの宛先ＵＲＬおよびメソッドがアクセス管理情報部２１８に記憶されている管理対象ＵＲＬ２１８ａおよびメソッド２１８ｂに一致するか確認すればよい。一致した場合、アクセス管理部２１０は、アクセス依頼部２０２から受信したデータを管理対象であると判定する。Ｓ６０３の処理は、「特定ステップ」の一例である（Ｓ６０３）。管理対象でない場合（Ｓ６０４でＮＯ）、アクセス管理部２１０は処理を終了する。管理対象である場合（Ｓ６０４でＹＥＳ）、アクセス管理部２１０はセッション情報部２１２に当該データのセッション情報が保存されているか確認する（Ｓ６０５）。セッション情報が保存されていない場合（Ｓ６０５でＮＯ）、アクセス管理部２１０は処理をＳ６０９に進める。セッション情報が保存されている場合（Ｓ６０５でＹＥＳ）、アクセス管理部２１０は、アクセス管理情報部２１８を参照し、セッションフラグ２１８ｅがオン（ｔｒｕｅ）に設定されているか確認する（Ｓ６０６）。セッションフラグ２１８ｅがオン（ｔｒｕｅ）に設定されていない場合（Ｓ６０６でＮＯ）、アクセス管理部２１０は処理をＳ６０８に進める。セッションフラグ２１８ｅがオン（ｔｒｕｅ）に設定されている場合（Ｓ６０６でＹＥＳ）、アクセス管理部２１０はアクセス履歴部２１１にセッション用のグループ（以下、本明細書においてセッショングループと称する）を作成する。セッショングループは、セッションフラグ２１８ｅがオンに設定されている変換対象引数２１８ｄの値をキーとして作成されればよい（Ｓ６０７）。アクセス管理部２１０は、アクセス依頼部２０２から受信したデータとサービスアクセス部２１７から受信したサービス１１の応答をアクセス履歴部２１１に保存する。Ｓ６０７〜Ｓ６０８の処理は、「履歴保存ステップ」の一例である（Ｓ６０８）。
【００９９】
例えば、以下の具体例に基づいてＳ６０８の処理が例示される。ＩＰアドレス192.168.1.20のクライアント１２から「http://192.168.1.10/service1」へ「{“name”:”user1
”,”pass”:”xxx”}」という要求がＰＯＳＴメソッドで送信され、サービス１１から「{“id”:”1234”}」という応答があった場合を考える。また、アクセス管理情報部２１
８には図１３に例示した値が保存されているものとする。この場合、クライアント１２から送信されたデータは図１３に例示するアクセス管理情報部２１８の管理対象ＵＲＬ２１８ａおよびメソッド２１８ｂに一致する。そのため、アクセス管理部２１０は、この通信のデータを管理対象のデータであると判定する。さらに、変換対象引数「id」はセッションフラグとしてtrueが設定されている。そのため、アクセス管理部２１０は、「id」が「1234」に設定されているセッショングループをアクセス履歴部２１１に作成する。アクセス管理部２１０は、作成されたグループに対し、ＵＲＬ２１１ｂとして「http://192.168.1.10/service1」、引数２１１ｃとして「なし」、メソッド２１１ｄとして「POST」、要求２１１ｅとして「{“name”:”user1”,”pass”:”xxx”}」、返答２１１ｆとして「{“id”:”1234”}」を保存する。その結果、アクセス履歴部２１１は、図１４の１行目（セッション２１１ａの値がid=1234となっている行）のようになる。
【０１００】
図２１に戻って、アクセス管理部２１０の処理の流れについて説明が続けられる。アクセス管理部２１０はアクセス管理情報部２１８に保存されている変換対象ＵＲＬ２１８ｃおよび変換対象引数２１８ｄを取得する（Ｓ６０９）。アクセス管理部２１０は、取得された変換対象ＵＲＬ２１８ｃおよび変換対象引数２１８ｄのうち、アクセス依頼部２０２から受信したデータの宛先ＵＲＬおよび引数と一致するものがあるか確認する。一致するものがある場合、アクセス管理部２１０は当該データを変換対象と判定する。一致するものが無い場合、アクセス管理部２１０は当該データを変換対象ではないと判定する（Ｓ６１０）。変換対象でない場合（Ｓ６１０でＮＯ）、アクセス管理部２１０は処理をＳ６１５に進める。変換対象である場合（Ｓ６１０でＹＥＳ）、アクセス管理部２１０は当該データの情報がセッション情報部２１２に保存されているか確認する（Ｓ６１１）。セッション情報部２１２に保存されている場合（Ｓ６１１でＹＥＳ）、アクセス管理部２１０は当該データの内容とサービス１１の応答からセッション情報を取得する。セッション情報は、例えば、アクセス管理情報部２１８のセッションフラグ２１８ｅがｔｒｕｅに設定されている引数の値である。前述のとおり、アクセス管理情報部２１８に記憶される情報は、プロキシサーバ１０の初期設定時に登録されている。アクセス管理部２１０は、取得したセッション情報をセッション情報部２１２の復元後の値２１２ｅに保存する。保存されたセッション情報は、終了処理部２１５による終了処理あるいはステート復元部２１３によるステートの復元処理に用いられる。Ｓ６１２の処理は、「セッション情報記憶ステップ」の一例である（Ｓ６１２）。セッション情報が保存されていない場合（Ｓ６１１でＮＯ）、アクセス管理部２１０は、クライアント１２からのデータとサービス１１からの応答からセッション情報を生成し、セッション情報部２１２に保存する。セッション情報は、例えば、クライアント１２からのデータの宛先ＵＲＬ、クライアント１２のＩＰアドレス、引数および引数に設定される値である。Ｓ６１３の処理は、「セッション情報記憶ステップ」の一例である（Ｓ６１３）。アクセス管理部２１０は、セッション情報をプロキシサービス１０ａの変換情報保存部２０５に通知する。変換情報保存部２０５は、通知された情報に基づいてアクセス変換情報部２０４を更新する（Ｓ６１４）。アクセス管理部２１０は、サービス１１から受信した応答をプロキシサービス１０ａのアクセス依頼部２０２に送信する（Ｓ６１５）。
【０１０１】
以上の処理により、アクセス管理部２１０は、アクセス依頼部２０２から受信したデータをサービスアクセス部２１７へ送信できる。また、アクセス管理部２１０は、管理対象のデータをアクセス履歴部２１１へ記憶できる。さらに、アクセス管理部２１０は、変換対象となるデータのセッション情報をセッション情報部２１２に記憶できる。ここでは、アクセス依頼部２０２からのアクセスについて述べたが、ステート復元部２１３からのアクセスも、アクセス管理部２１０は扱う。その際は、アクセス履歴部２１１への保存を行わないという違いがあるが、それ以外は上記の処理を行う。
【０１０２】
＜サービスアクセス部２１７の処理の流れ＞
図２２は、サービスアクセス部２１７の処理の流れを例示する図である。サービスアクセス部２１７は、アクセス管理部２１０から受信したデータをサービス１１へ送信する。サービスアクセス部２１７は、サービス１１から受信した応答をアクセス管理部２１０へ送信する。以下、図２２を参照して、サービスアクセス部２１７の処理の流れについて説明する。
【０１０３】
サービスアクセス部２１７は、アクセス管理部２１０から受信したデータをサービス１１へ送信する（Ｓ７０１）。サービスアクセス部２１７はサービス１１から応答を受信する。サービスアクセス部２１７は、受信した応答をアクセス管理部２１０へ送信する（Ｓ７０２）。
【０１０４】
以上の処理により、サービスアクセス部２１７は、アクセス管理部２１０から受信したデータをサービス１１に送信できる。また、サービスアクセス部２１７は、サービス１１からクライアント１２への応答のデータをアクセス管理部２１０へ送信できる。サービスアクセス部２１７は、終了処理部２１５から受信したデータをサービス１１へと中継する役割ももつ。上記処理のアクセス管理部２１０を終了処理部２１５と読み替えることで、終了処理部２１５からのサービス１１へのアクセスをサービスアクセス部２１７にて中継する処理となる。
【０１０５】
＜モード処理振分部２１４の処理の流れ＞
図２３は、モード処理振分部２１４の処理の流れを例示する図である。モード処理振分部２１４は、モード管理部２０３からアップデートの開始あるいはアップデートの終了の通知を受ける。以下、図２３を参照して、モード処理振分部２１４の処理の流れについて説明する。
【０１０６】
図２３のＳ８０１からＳ８０３を参照して、モード管理部２０３からアップデート開始の通知を受けた場合の、モード処理振分部２１４の処理について説明する。
【０１０７】
モード処理振分部２１４は、モード管理部２０３から受信した通知がアップデート開始の通知であるか判定する（Ｓ８０１）。アップデート開始の通知である場合（Ｓ８０１でＹＥＳ）、モード処理振分部２１４は、終了処理部２１５に終了処理の指示をする（Ｓ８０２）。モード処理振分部２１４は、終了処理部２１５から終了処理の完了報告を受ける。モード処理振分部２１４は、処理の完了をモード管理部２０３に通知する（Ｓ８０３）。
【０１０８】
次に、図２３のＳ８０４以降を参照して、モード管理部２０３から受信した通知がアップデート開始の通知ではない場合の、モード処理振分部２１４の処理について説明する。
【０１０９】
モード処理振分部２１４は、モード管理部２０３から受信した通知がアップデート終了の通知であるか判定する（Ｓ８０４）。アップデート終了の通知である場合（Ｓ８０４でＹＥＳ）、モード処理振分部２１４は、ステート復元部２１３に処理を指示する（Ｓ８０５）。モード処理振分部２１４は、ステート復元部２１３からステート復元処理の完了報告を受ける。モード処理振分部２１４は、処理の完了をモード管理部２０３に通知する（Ｓ８０３）。アップデート終了の通知ではない場合、モード処理振分部２１４は処理を終了する（Ｓ８０４でＮＯ）。
【０１１０】
以上の処理により、モード処理振分部２１４は、モード管理部２０３からの通知に応じて終了処理部２１５あるいはステート復元部２１３に処理を指示できる。
【０１１１】
＜終了処理部２１５の処理の流れ＞
図２４Ａは、終了処理部２１５の処理の流れを例示する図である。終了処理部２１５は、サービスアクセス部２１７を通じてサービス１１とのセッションの終了処理を行う。以下、図２４Ａを参照して、終了処理部２１５の処理の流れについて説明する。
【０１１２】
終了処理部２１５は、セッション情報部２１２を参照し、サービス１１とセッションを確立しているクライアント１２のリストを作成する（Ｓ９０１）。終了処理部２１５は、Ｓ９０１でリストアップしたクライアント１２毎に終了シーケンス部２１６およびセッション情報部２１２を参照してサービス１１とのセッションを終了するデータを生成する（Ｓ９０２）。終了処理部２１５は、生成されたデータをサービスアクセス部２１７経由でサービス１１に送信する。Ｓ９０３の処理は、「セッション終了ステップ」の一例である（Ｓ９０３）。終了処理部２１５は、Ｓ９０１でリストアップしたすべてのクライアント１２に対するＳ９０２からＳ９０３の処理が完了したか確認する。完了していない場合、終了処理部２１５はＳ９０２以降の処理を繰り返す（Ｓ９０４でＮＯ）。完了している場合、終了処理部２１５は処理を終了する（Ｓ９０４でＹＥＳ）。
【０１１３】
図２４Ｂは、終了処理部２１５が生成するデータの内容を例示する図である。終了処理部２１５が生成するデータはクライアント１２毎に生成される。図２４Ｂでは、２台のクライアント（ＩＰアドレス１９２．１６８．１．２０のクライアントとＩＰアドレス１９２．１６８．１．２２のクライアント）の終了処理に用いられるデータの内容が例示されている。図２４Ｂでは、ＵＲＬ２１５ａ、引数２１５ｂ、メソッド２１５ｃおよび要求２１５ｄが例示されている。以下、図２４Ｂを参照して、終了処理部２１５が行うセッションの終了処理について説明する。
【０１１４】
ＵＲＬ２１５ａは、セッションの終了処理の対象となるサービス１１のＵＲＬ情報を例示している。引数２１５ｂは、終了処理部２１５がＵＲＬ２１５ａにアクセスする際にサービス１１に渡す引数とその値を例示している。メソッド２１５ｃは、終了処理部２１５がＵＲＬ２１５ａにアクセスする際に使用するメソッドを例示している。要求２１５ｄは、終了処理部２１５がＵＲＬ２１５ａにアクセスする際に送信する要求を例示している。図２４Ｂでは、横１列で１まとまりのデータが例示されている。終了処理部２１５は、図２４Ｂの各行に例示する内容のデータをサービス１１に送信することで、セッションの終了処理を行う。
【０１１５】
図２４Ｂを参照して、終了処理部２１５がＩＰアドレス192.168.1.20のクライアントとサービス「http://192.168.1.10/service1」との間に確立されているセッションを終了する処理を説明する。まず、終了処理部２１５は、ＵＲＬ「http://192.168.1.10/service1/sub/lock」、引数として「id=1234」および「subid=1」、メソッドとして「DELETE」を
指定したデータを送信する。続いて、終了処理部２１５は、ＵＲＬ「http://192.168.1.10/service1/sub/func」、引数として「id=1234」および「subid=1」、メソッドとして「POST」、要求として「{“data”:”null”}」を指定したデータを送信する。続いて、終了処理部２１５は、ＵＲＬ「http://192.168.1.10/service1/sub」、引数として「id=1234
」および「subid=1」、メソッドとして「DELETE」を指定したデータを送信する。最後に
、終了処理部２１５は、ＵＲＬ「http://192.168.1.10/service1」、引数として「id=1234」、メソッドとして「DELETE」を指定したデータを送信する。以上の処理により、終了
処理部２１５は、ＩＰアドレス192.168.1.20のクライアントとサービス「http://192.168.1.10/service1」との間に確立されているセッションを終了する。
【０１１６】
以上の処理により、終了処理部２１５は、サービス１１の中断前にセッションを正常に終了できる。
【０１１７】
＜ステート復元部２１３の処理の流れ＞
図２５Ａは、ステート復元部２１３の処理の流れを例示する図である。ステート復元部２１３は、サービス１１のアップデート後に、ステートを復元する処理を行う。ステート復元部によるステートを復元する処理は、アクセス履歴部２１１およびセッション情報部２１２を参照して行われる。以下、図２５Ａを参照して、ステート復元部２１３の処理について説明する。
【０１１８】
ステート復元部２１３は、アクセス履歴部２１１からクライアント１２毎の通信履歴を取得する（Ｓ１００１）。ステート復元部２１３は、クライアント１２毎の通信履歴からセッション毎の通信履歴を取得する（Ｓ１００２）。ステート復元部２１３は、取得したセッション毎の通信履歴に引数が含まれるか確認する。引数がない場合（Ｓ１００３でＮＯ）、ステート復元部２１３は処理をＳ１００５に進める（Ｓ１００３）。引数がある場合（Ｓ１００３でＹＥＳ）、ステート復元部２１３は、セッション情報部２１２の復元後の値２１２ｅを取得する（Ｓ１００４）。ステート復元部２１３は、Ｓ１００１からＳ１００４で取得した情報を基にステートの復元を行うデータを生成する。ステート復元部２１３は、生成したデータにセッション情報部２１２から取得した復元後の値２１２ｅをセッション情報として付与する。ステート復元部２１３は、セッション情報を付与したデータのサービス１１への送信をアクセス管理部２１０に依頼する。アクセス管理部２１０は、依頼されたデータをサービスアクセス部２１７を介してサービス１１に送信する。Ｓ１００５の処理は、「復元ステップ」の一例である（Ｓ１００５）。ステート復元部２１３は、セッション毎の履歴をすべて処理したか確認する。未処理のセッション毎の履歴がある場合（Ｓ１００６でＮＯ）、ステート復元部２１３は、処理をＳ１００２に戻す（Ｓ１００６）。セッション毎の履歴をすべて処理した場合（Ｓ１００６でＹＥＳ）、ステート復元部２１３は、アクセス履歴部２１１を参照してクライアント毎の履歴をすべて処理したか確認する。未処理のクライアント毎の履歴がある場合、ステート復元部２１３は処理をＳ１００１に戻す。クライアント毎の履歴をすべて処理した場合、ステート復元部２１３は処理を終了する（Ｓ１００７）。
【０１１９】
図２５Ｂは、ステート復元部２１３が生成するデータの内容および当該データに対するサービス１１からの応答データの内容を例示する図である。図２５Ｂは、図１４に例示するアクセス履歴があった場合のステート復元部２１３によって生成されるデータの内容および当該データに対するサービス１１からの応答データの内容を例示する。ステート復元部２１３のデータはクライアント１２毎に生成される。図２５Ｂでは、２台のクライアント（ＩＰアドレス１９２．１６８．１．２０のクライアントとＩＰアドレス１９２．１６８．１．２２のクライアント）のステートを復元するデータの内容が例示されている。図２５Ｂでは、ＵＲＬ２１３ａ、引数２１３ｂ、メソッド２１３ｃ、要求２１３ｄおよび応答２１３ｅが例示されている。以下、図２５Ｂを参照して、ステート復元部２１３が行う処理について説明する。
【０１２０】
ＵＲＬ２１３ａは、ステート復元の対象となるサービス１１のＵＲＬ情報を例示している。引数２１３ｂは、ステート復元部２１３がＵＲＬ２１５ａで提供されるサービス１１にアクセスする際に、サービス１１に渡す引数とその値を例示している。メソッド２１３ｃは、ステート復元部２１３がＵＲＬ２１３ａで提供されるサービス１１にアクセスする際に使用するメソッドを例示している。要求２１３ｄは、ステート復元部２１３がＵＲＬ２１３ａで提供されるサービス１１にアクセスする際に送信する要求を例示している。応答２１３ｅは、ステート復元部２１３がサービス１１から受け取る応答を例示している。応答２１３ｅに例示されるサービス１１からの応答は、アクセス管理部２１０によってセッション情報部２１２の復元後の値２１２ｅに記憶される。図２５Ｂでは、横１列のＵＲＬ２１３ａ、引数２１３ｂ、メソッド２１３ｃおよび要求２１３ｄで１まとまりのデータ
が例示される。ステート復元部２１３は、図２５Ｂの各行に例示する内容のデータを生成する。ステート復元部２１３は、生成したデータの送信をアクセス管理部２１０に依頼することで、ステートの復元処理を行う。
【０１２１】
図２５Ｂを参照して、ステート復元部２１３がＩＰアドレス192.168.1.20のクライアントとサービス「http://192.168.1.10/service1」との間のステートを復元する処理を説明する処理を例示する。まず、図２５Ｂの第２行の１つ目の例を説明する。この例では、ステート復元部２１３は、ＵＲＬ「http://192.168.1.10/service1」、メソッドとして「POST」、要求として「{”name”:”user1”,”pass”:”xxx”}」としたデータを生成する
。ステート復元部２１３は、生成したデータの送信をアクセス管理部２１０に依頼する。アクセス管理部２１０は、依頼されたデータをサービスアクセス部２１７を介して送信する。アクセス管理部２１０は、送信したデータの応答として「{”id”:”1252”}」をサ
ービスアクセス部２１７を介して受信する。アクセス管理部２１０は、セッション情報部２１２の復元後の値２１２ｅに応答「{”id”:”1252”}」の値「1252」を保存する。ま
た、アクセス管理部２１０は、変換情報保存部２０５に対しアクセス変換情報部２０４の変換後の値２０４ｅへの「{”id”:”1252”}」の値「1252」の保存を依頼する。変換情
報保存部２０５は、アクセス変換情報部２０４の変換後の値２０４ｅに「{”id”:”1252”}」の値「1252」を保存する。
【０１２２】
次に、図２５Ｂの第３行にある２つ目の例を説明する。この例では、ステート復元部２１３は、ＵＲＬ「http://192.168.1.10/service1/sub」、引数として「id=1252」、メソ
ッドとして「POST」、要求として「{”device”:”device1”}」としたデータを生成する。ステート復元部２１３は、生成したデータの送信をアクセス管理部２１０に依頼する。アクセス管理部２１０は、依頼されたデータを送信する。アクセス管理部２１０は、送信したデータの応答として「{”subid”:”2”}」をサービスアクセス部２１７を介して受
信する。アクセス管理部２１０は、セッション情報部２１２の復元後の値２１２ｅに応答「{”subid”:”2”}」の値「2」を保存する。また、アクセス管理部２１０は、変換情報保存部２０５に対しアクセス変換情報部２０４の変換後の値２０４ｅへの「{”subid”:
”2”}」の値「2」の保存を依頼する。変換情報保存部２０５は、アクセス変換情報部２
０４の変換後の値２０４ｅに「{”subid”:”2”}」の値「2」を保存する。
【０１２３】
次に、図２５Ｂの第４行にある３つ目の例を説明する。この例では、ステート復元部２１３は、ＵＲＬ「http://192.168.1.10/service1/func」、引数として「id=1252」および「subid=2」、メソッドとして「POST」、要求として「{”data”:”test”}」としたデータを生成する。ステート復元部２１３は、生成したデータの送信をアクセス管理部２１０に依頼する。アクセス管理部２１０は、依頼されたデータを送信する。アクセス管理部２１０は、送信したデータの応答として「{”result”:”success”}」をサービスアクセス部２１７介して受信する。
【０１２４】
次に、図２５Ｂの第５行にある４つ目の例を説明する。この例では、ステート復元部２１３は、ＵＲＬ「http://192.168.1.10/service1/lock」、引数として「id=1252」および「subid=2」、メソッドとして「GET」としたデータを生成する。ステート復元部２１３は、生成したデータの送信をアクセス管理部２１０に依頼する。アクセス管理部２１０は、依頼されたデータを送信する。アクセス管理部２１０は、送信したデータの応答として「{”result”:”success”}」をサービスアクセス部２１７を介して受信する。以上の処理により、ステート復元部２１３は、ステートをアップデート前の状態に復元する。
【０１２５】
図２５Ｃは、ステート復元後のアクセス変換情報部２０４を例示する図である。図２５Ｃは、図２５Ｂに例示されるステート復元処理が行われた場合のアクセス変換情報部２０４を例示する。図２５Ｃでは、復元後の値２１２ｅにステート復元部２１３による復元処
理で取得された応答２１３ｅの値が記憶されている。クライアント１２はアップデート前のセッション情報（変換前の値に相当）を使用してサービス１１にデータを送信する。このような場合でも、アクセス依頼部２０２がアクセス変換情報部２０４を参照することでセッション情報を復元後の値に変換することができる。その結果、クライアント１２は、サービス１１のアップデート前後でセッション情報が変更されたことを意識せずにサービス１１へデータを送信できる。
【０１２６】
以上の処理により、ステート復元部２１３は、サービス１１のステートを復元できる。
【０１２７】
＜サービス１１からクライアント１２への応答データ＞
以上の説明では、主にクライアント１２からサービス１１へ送信される場合の処理が説明された。サービス１１からクライアント１２へ応答するデータは、以上で説明された経路を逆向きにたどることで、サービス１１からクライアント１２へ送信される。つまり、サービス１１からクライアント１２へ応答するデータは、サービスアクセス部２１７、アクセス管理部２１０、アクセス依頼部２０２およびアクセスプロキシ部２０１を経由してサービス１１からクライアント１２へ送信される。
【０１２８】
ここで、セッション情報がステートの復元処理によって変更されている場合を考える。この場合、クラアント１２はセッション情報の変更を通知されない。そのため、アクセス依頼部２０２は、アクセス変換情報部２０４を参照して、サービス１１から受信したデータに含まれるセッション情報を変更される前のセッション情報に変換する。その後、アクセス依頼部２０２は、セッション情報を変換したデータをアクセスプロキシ２０１を介してクライアント１２へ送信する。
【０１２９】
以上の処理により、クライアント１２は、サービス１１のセッション情報が変更されたことを意識せずにサービス１１からのデータを受信できる。
【０１３０】
＜サービス１１のアップデート時の処理の流れ＞
図２６は、サービス１１のアップデート時の処理の流れを例示する図である。図２６では、クライアント１２、プロキシサービス１０ａ、プロキシクライアント１０ｂ、旧サービス１１ａ、新サービス１１ｂおよび運用管理部２２０が例示されている。旧サービス１１ａは、アップデートされる前のサービス１１である。新サービス１１ｂは、アップデートされた後のサービス１１である。図２６に記載されている矢印は、矢印の根本から先の方向にデータが送信されていることを例示している。図２６では、図の上方から下方に向けて時間が流れている。以下、図２６を参照してアップデート時の処理の流れについて説明する。
【０１３１】
まず、Ｓ１０１からＳ１０７を参照して、旧サービス１１ａが停止されるまでの処理が説明される。
【０１３２】
運用管理部２２０は、プロキシサービス１０ａのモード管理部２０３に旧サービス１１ａのアップデート開始を通知する（Ｓ１０１）。モード管理部２０３は、アクセスプロキシ部２０１のモードをアップデートモードに変更する。モード管理部２０３は、旧サービス１１ａのアップデート開始をプロキシクライアント１０ｂのモード処理振分部２１４に通知する（Ｓ１０２）。モード処理振分部２１４は、終了処理部２１５に旧サービス１１ａとクライアント１２の間のセッションの終了処理を指示する。終了処理部２１５は、旧サービス１１ａとクライアント１２の間で確立されているセッションがある場合、終了シーケンス部２１６を参照して、そのセッションの終了処理を行う（Ｓ１０３、Ｓ１０４）。終了処理部２１５は、セッション終了処理の完了をモード処理振分部２１４に通知する。モード処理振分部２１４は、セッション終了処理の完了をモード管理部２０３に通知す
る（Ｓ１０５）。モード管理部２０３は、セッション終了処理の完了を運用管理部２２０に通知する（Ｓ１０６）。運用管理部２２０は、旧サービス１１ａのサービス停止処理を実行する（Ｓ１０７）。
【０１３３】
続いて、Ｓ１０８からＳ１１４を参照して、新サービス１１ｂへのアップデートから新サービス１１ｂのステート復元までの処理が説明される。
【０１３４】
サービス１１は、旧サービス１１ａから新サービス１１ｂへのアップデート中である。そのため、サービス１１は、クライアント１２からのデータを受信しない。そのため、プロキシサービス１０ａのアクセスプロキシ部２０１は、旧サービス１１ａから新サービス１１ｂへのサービスアップデートが実施されている間、クライアント１２から受け付けたデータを保留アクセス部２０６に保存する（Ｓ１０８）。運用管理部２２０は、旧サービス１１ａを終了すると、新サービス１１ｂを起動する（Ｓ１０９）。運用管理部２２０は、旧サービス１１ａから新サービス１１ｂへのアップデート完了をモード管理部２０３に通知する（Ｓ１１０）。モード管理部２０３は、旧サービス１１ａから新サービス１１ｂへのアップデート完了をモード処理振分部２１４に通知する（Ｓ１１１）。モード処理振分部２１４は、ステート復元部２１３にステートの復元を指示する。ステート復元部２１３は、アクセス履歴部２１１およびセッション情報部２１２を参照してステートを復元するデータを生成する。ステート復元部２１３は、生成したデータのサービス１１への送信をアクセス管理部２１０に依頼する。アクセス管理部２１０は、ステート復元部２１３から受信したデータをサービスアクセス部２１７を介してサービス１１へ送信する（Ｓ１１２）。アクセス管理部２１０は、サービス１１からの応答データをサービスアクセス部２１７を介して受信する。アクセス管理部２１０は、受信したデータに含まれるセッション情報をセッション情報部２１２に記憶する。さらに、アクセス管理部２１０は、このセッション情報の保存を変換情報保存部２０５に依頼する。変換情報保存部２０５は、アクセス管理部２１０から依頼されたセッション情報をアクセス変換情報部２０４に記憶する（Ｓ１１３）。ステートの復元処理を完了すると、ステート復元部２１３は、モード処理振分部２１４にステート復元処理の完了を通知する。モード処理振分部２１４は、ステートの復元処理の完了をモード管理部２０３に通知する（Ｓ１１４）。
【０１３５】
続いて、Ｓ１１５以降を参照して、ステート復元後の処理が説明される。
【０１３６】
モード管理部２０３は、ステートの復元処理完了を運用管理部２２０に通知する。モード管理部２０３は、アクセスプロキシ部２０１のモードを通常モードに変更する（Ｓ１１５）。通常モードに変更されたアクセスプロキシ部２０１は、Ｓ１０８で保留したクライアント１２からのデータをアクセス依頼部２０２に送信する。アクセス依頼部２０２は、アクセス変換情報部２０４を参照して、受信したデータに付与されているセッション情報を旧サービス１１ａのセッション情報から新サービス１１ｂのセッション情報に変換する。アクセス依頼部２０２は、セッション情報を変換したデータをプロキシクライアント１０ｂのアクセス管理部２１０に送信する（Ｓ１１６）。アクセス管理部２１０は、アクセス依頼部２０２から受信したデータをサービスアクセス部２１７に送信する。サービスアクセス部２１７は受信したデータを新サービス１１ｂに送信する（Ｓ１１７）。新サービス１１ｂは、サービスアクセス部２１７から受信したデータに対する応答をサービスアクセス部２１７に送信する（Ｓ１１８）。サービスアクセス部２１７は、新サービス１１ｂから受信したデータをアクセス管理部２１０に送信する。アクセス管理部２１０は受信したデータをアクセス依頼部２０２へ送信する（Ｓ１１９）。アクセス依頼部２０２は、アクセス変換情報部２０４を参照して、受信したデータに付与されているセッション情報を新サービス１１ｂのセッション情報から旧サービス１１ａのセッション情報に変換する。アクセス依頼部２０２は、変換したデータをアクセスプロキシ部２０１を介してクライアント１２に送信する（Ｓ１２０）。
【０１３７】
第１実施形態では、サービス１１とクライアント１２の間にプロキシサーバ１０を設ける構成が採用された。そのため、サービス１１に冗長化等の仕組みを導入することなくサービス１１のサービス中断をクライアント１２から隠蔽できる。
【０１３８】
プロキシサーバ１０は、透過プロキシサーバであってもよい。透過プロキシサーバとは、情報処理装置にプロキシサーバの設定を行わなくとも当該情報処理装置から利用できるプロキシサーバである。プロキシサーバ１０として透過プロキシサーバが採用された場合、サービス１１の設定を変更せずにプロキシサーバ１０が適用される。
【０１３９】
プロキシサーバ１０は、Ｓｅｃｕｒｅ  Ｓｏｃｋｅｔｓ  Ｌａｙｅｒ（ＳＳＬ）復号化機能を有するプロキシサーバであってもよい。ＳＳＬ復号化機能を有することで、ＳＳＬで暗号化された通信に対してもプロキシサーバ１０が適用される。
【０１４０】
プロキシサーバ１０では、サービス１１がサービスの提供を中断している間クライアント１２からサービス１１へのデータを保留する。プロキシサーバ１０は、サービス１１のサービス再開を契機に、保留したデータをサービス１１へ送信する。その結果、サービス１１のクライアント１２へのサービス中断が抑制される。
【０１４１】
プロキシサーバ１０では、サービス１１からの応答にセッション情報が含まれている場合、アクセス変換情報部２０４およびセッション情報部２１２にセッション情報が記憶された。その結果、アクセス依頼部２０２によるデータの変換およびステート復元部２１３によるセッションの復元ができる。
【０１４２】
プロキシサーバ１０では、アクセス履歴部２１１およびセッション情報部２１２に記憶された情報を基にステート復元部２１３がステートの復元処理を行う。その結果、セッション情報等がサービス１１の中断前後で変化していても、プロキシサーバ１０はステートを復元できる。
【０１４３】
プロキシサーバ１０では、サービス中断前後のセッション情報の対応をアクセス変換情報部２０４に記憶する。サービス再開後のクライアント１２からサービス１１へのデータは、アクセス依頼部２０２がアクセス変換情報部２０４を基にセッション情報等の変換を行う。その結果、クライアント１２は、サービス１１のセッション情報が変更されたことを意識することなくサービス１１と通信できる。
【０１４４】
プロキシサーバ１０は、管理対象となるデータを特定する情報をアクセス管理情報部２１８に登録する。その結果、プロキシサーバ１０の適用対象となるサービス１１が追加された場合でも、追加されたサービス１１の情報をアクセス管理情報部２１８に追加登録することで対応できる。また、プロキシサーバ１０では、アクセス管理情報部２１８に登録されていないデータを管理対象としない。そのため、プロキシサーバ１０を通過するすべてのデータを管理対象とする場合と比較して、プロキシサーバ１０の処理負荷を低減できる。
【０１４５】
プロキシサーバ１０は、サービス１１の中断を通知されるとクライアント１２とサービス１１との間で確立しているセッションを終了する。そのため、プロキシサーバ１０は、サービス１１のアップデート前にセッションを正常に終了できる。
【０１４６】
＜変形例＞
第１実施形態では、アップデートの前後でクライアント１２からサービス１１へアクセスする際のＵＲＬ、引数、メソッド等（以下、本明細書においてインターフェースと称す
る）が変更されない場合を例示した。変形例では、アップデートの前後でサービス１１のインターフェースが変更される場合を例示する。インターフェースは「接続方式」の一例である。なお、第１実施形態と同一の構成要素については、同一の符号を付し、その説明は省略される。
【０１４７】
図２７は、変形例におけるプロキシサーバ１０のアップデート前の状態を例示する図である。図２７では、サービス１１ｃ、新サービス１１ｄ、プロキシサーバ１０およびクライアント１２が例示されている。サービス１１ｃを提供するサーバ、プロキシサーバ１０およびクライアント１２はネットワーク環境５で相互に接続されている。プロキシサーバ１０は、プロキシサービス１０ａおよびプロキシクライアント１０ｂを含む。サービス１１ｃと新サービス１１ｄとはクライアント１２からアクセスされる際のインターフェースが異なる。図２７の状態では、クライアント１２はプロキシサービス１０ａおよびプロキシクライアント１０ｂを経由してサービス１１ｃに接続している。
【０１４８】
図２８は、変形例におけるプロキシクライアント１０ｂのアップデート中の状態を例示する図である。図２８では、図２７に加えて新プロキシクライアント１０ｃが例示されている。サービス１１ｃを提供するサーバ、プロキシサーバ１０およびクライアント１２はネットワーク環境５で相互に接続されている。新プロキシクライアント１０ｃは、アップデート後の新サービス１１ｄに対応するプロキシクライアントである。新プロキシクライアント１０ｃは、クライアント１２からサービス１１ｃへのアクセスを新サービス１１ｄへのアクセスに変換する機能を有する。このアクセス変換機能は、例えば、サービス１１ｃと新サービス１１ｄのＵＲＬ、引数あるいはメソッド等の対応表を基に変換すればよい。
【０１４９】
図２９は、変形例におけるプロキシクライアント１０ｂのアップデート後の状態を例示する図である。新サービス１１ｄを提供するサーバ、プロキシサーバ１０およびクライアント１２はネットワーク環境５で相互に接続されている。図２９の状態では、クライアント１２は、プロキシサービス１０ａおよび新プロキシクライアント１０ｃを経由して新サービス１１ｄに接続されている。新プロキシクライアント１０ｃは、クライアント１２からサービス１１ｃに送信されるデータを新サービス１１ｄへのデータに変換して新サービス１１ｄへ送信する。
【０１５０】
図３０Ａは、変形例におけるアップデート後のプロキシサーバ１０の機能ブロックを例示する図である。図３０Ａでは、プロキシサービス１０ａ、プロキシクライアント１０ｃ、運用管理部２２０、クライアント１２およびサービス１１の各ブロックが例示されている。例えば、図９のプロセッサ１０１が図３０Ａの各ブロックとして主記憶部１０２に実行可能に展開されたコンピュータプログラムを実行する。ただし、図３０Ａのいずれかのブロックの少なくとも一部はハードウェア回路を含んでもよい。プロキシサーバ１０は、プロキシサービス１０ａおよびプロキシクライアント１０ｃを有する。プロキシクライアント１０ｃは、アップデート後の新サービス１１ｄに対応するプロキシクライアントである。プロキシサーバ１０、サービス１１を提供するサーバ、クライアント１２および運用管理部２２０はネットワーク環境５によって相互に接続されている。以下、図３０Ａを参照して、プロキシサーバ１０の各機能ブロックについて説明する。なお、第１実施形態と共通の構成要素については同一の符号を付し、その説明は省略される。
【０１５１】
サービスアクセス部２１７ａは、インターフェース対応情報部２１９に記憶される情報を参照して、受信したデータをアップデート後のサービスへのデータに変換する。サービスアクセス２１７ａは、「接続方式変換部」の一例である。
【０１５２】
インターフェース対応情報部２１９は、アップデート前のサービスのインターフェース
情報とアップデート後のサービスのインターフェース情報との対応情報を記憶する。インターフェース対応情報部２１９は、図９の主記憶部１０２あるいは補助記憶部１０３に設けられれば良い。インターフェース対応情報部２１９は、「対応記憶部」の一例である。
【０１５３】
図３０Ｂは、インターフェース対応情報部２１９に記憶される情報を例示する図である。図３０Ｂでは、アップデートによってサービス１１のＵＲＬが変更された場合にインターフェース対応情報部２１９に記憶される情報を例示する。アップデート前ＵＲＬ２１９ａには、アップデート実施前のサービス１１（つまり、図２７〜図２９のサービス１１ｃ）のＵＲＬ情報が記憶される。アップデート後ＵＲＬ２１９ｂには、アップデート実施後のサービス１１（つまり、図２７〜図２９の新サービス１１ｄ）のＵＲＬ情報が記憶される。サービスアクセス部２１７ａは、インターフェース対応情報部２１９に記憶された情報を基に、受信した情報を変換すればよい。なお、図３０Ｂでは、アップデートの前後でサービス１１のＵＲＬが変更される場合を例示した。しかし、インターフェース対応情報部２１９に記憶される情報はＵＲＬ情報に限定されない。インターフェース対応情報部２１９に記憶される情報は、アップデート前のサービス１１の情報とアップデート後のサービス１１のインターフェース情報の対応が記憶されればよい。サービスアクセス部２１７ａは、インターフェース対応情報部２１９に記憶された情報を基に、アクセス管理部２１０および終了処理部２１５から受信するデータをアップデート後のサービス１１に対するデータに変換すればよい。
【０１５４】
なお、アップデートによりサービス１１とのセッションを終了させる処理の流れが変更される場合も考えられる。このような場合、アップデート後のサービス１１とのセッションを終了させる処理の流れを終了シーケンス部２１６に登録すればよい。
【０１５５】
図３０Ｃは、サービスアクセス部２１７ａによる接続方式の変換の処理の流れを例示する図である。以下、図３０Ｃを参照してサービスアクセス部２１７ａによる接続方式の変換処理の流れについて説明する。
【０１５６】
サービスアクセス部２１７ａは、アクセス管理部２１０あるいは終了処理部２１５からのデータを受信する。サービスアクセス部２１７ａは、インターフェース対応情報部２１９を参照して受信したデータが変換対象であるか判定する。この判定は、例えば、受信したデータの宛先ＵＲＬがインターフェース対応情報部２１９に記憶されたアップデート前ＵＲＬ２１９ａと一致するか否かで判定される（Ｓ１３０１）。受信したデータが変換対象である場合（Ｓ１３０２でＹＥＳ）、サービスアクセス部２１７ａは、インターフェース対応情報部２１９に記憶された情報を基にデータを変換する。Ｓ１３０３の処理は、「接続方式変換ステップ」の一例である（Ｓ１３０３）。受信したデータが変換対象ではない場合、サービスアクセス部２１７ａは受信したデータを変換しない（Ｓ１３０２でＮＯ）。サービスアクセス部２１７ａは、データをサービス１１へ中継する（Ｓ１３０４）。
【０１５７】
変形例では、サービス１１ｃへ送信されたデータを新サービス１１ｄへ送信されるデータに変換した。その結果、アップデートの前後でインターフェースが変更になる場合でも、サービス１１の中断がクライアント１２から隠蔽される。
【０１５８】
以上で説明した実施形態および変形例ではサービス１１が１つの場合を例示した。しかしながら、プロキシサーバ１０の適用範囲はサービス１１が１つの場合に限定されない。例えば、保留アクセス部２０６、セッション情報部２１２等に保存される情報をサービス１１毎に保存するようにすることで、サービス１１が複数の場合にもプロキシサーバ１０を適用可能である。
【０１５９】
＜第２実施形態＞
第１実施形態では、サービス１１がアップデートされる場合を例にサービス１１の中断をクライアント１２に対して隠蔽する技術を説明した。第２実施形態では、サービス１１がバックアップデータからリカバリされる場合について説明する。
【０１６０】
バックアップからリカバリされた場合、サービス１１はバックアップを取得した時点の状態になる。そのため、第１実施形態のようにサービスが中断される直前の状態にステートを戻すことは難しい。そこで、第２実施形態では、バックアップを取得した時点からの全アクセス履歴を保存する。サービス１１をリカバリした場合、保存された全アクセス履歴を基に、バックアップを取得した時点以降のステートを復元する。
【０１６１】
図３１は、第２実施形態の機能ブロックを例示する図である。図３１では、プロキシサーバ５１０、サービス１１、クライアント１２および運用管理部２２０ａが例示されている。例えば、図９のプロセッサ１０１が図３１の各ブロックとして主記憶部１０２に実行可能に展開されたコンピュータプログラムを実行する。ただし、図３１のいずれかのブロックの少なくとも一部はハードウェア回路を含んでもよい。プロキシサーバ５１０、サービス１１を提供するサーバ、クライアント１２および運用管理部２２０ａはネットワーク環境５で相互に接続されている。プロキシサーバ５１０は、プロキシサービス５１０ａおよびプロキシクライアント５１０ｂを含む。プロキシサービス５１０ａは、アクセスプロキシ部２０１ａ、アクセス依頼部２０２、モード管理部２０３ａおよび保留アクセス部２０６を含む。プロキシクライアント５１０ｂは、アクセス管理部２１０、モード処理振分部２１４ａ、サービスアクセス部２１７、全アクセス履歴部２５０、リカバリ処理部２５１および履歴クリア部２５２を含む。なお、第１実施形態と同一の構成要素については、同一の符号を付し、その説明は省略される。
【０１６２】
アクセスプロキシ部２０１ａは、クライアント１２からのデータを受け付ける。アクセスプロキシ部２０１ａは設定されるモードによって処理を切り替える。アクセスプロキシ部２０１ａのモードは、例えば、通常モード、リカバリモードおよびバックアップモードである。モードが通常モードに設定されている場合、アクセスプロキシ部２０１ａは、クライアント１２からのデータをアクセス依頼部２０２へと送信する。モードがリカバリモードあるいはバックアップモードに設定されている場合、アクセスプロキシ部２０１ａは、クライアント１２からのデータを保留する。保留されたデータは保留アクセス部２０６に保存される。保留アクセス部２０６に保存されたデータは、アクセスプロキシ部２０１ａのモードが通常モードに切り替わったときにアクセス依頼部２０２へ送信される。
【０１６３】
モード管理部２０３ａは、運用管理部２２０ａからの通知に応じてアクセスプロキシ部２０１ａのモードを変更する。運用管理部２２０ａからリカバリ開始の通知を受けた場合、モード管理部２０３ａはアクセスプロキシ部２０１ａに対してリカバリモードへの移行を指示する。運用管理部２２０ａからバックアップ開始の通知を受けた場合、モード管理部２０３ａはアクセスプロキシ部２０１ａに対してバックアップモードへの移行を指示する。運用管理部２２０ａからリカバリ終了の通知を受けた場合、モード管理部２０３ａはアクセスプロキシ部２０１ａに対して通常モードへの移行を指示する。運用管理部２２０ａからバックアップ終了の通知を受けた場合、モード管理部２０３ａはアクセスプロキシ部２０１ａに対して通常モードへの移行を指示する。また、運用管理部２２０ａからリカバリ開始の通知を受けた場合、モード管理部２０３ａはモード処理振分部２１４ａにリカバリ開始を通知する。さらに、運用管理部２２０ａからバックアップ終了の通知を受けた場合、モード管理部２０３ａはモード処理振分部２１４ａにバックアップ終了を通知する。
【０１６４】
全アクセス履歴部２５０には、バックアップデータ取得時以降のクライアント１２とサービス１１間の通信履歴がアクセス管理部２１０によって保存される。運用管理部２２０
ａによるサービス１１のバックアップデータ取得を契機にして、運用管理部２２０ａがモード管理部２０３ａにバックアップ終了を通知し、モード管理部２０３ａがバックアップ終了をモード処理振分部２１４ａに通知する。モード処理振分部２１４ａは、バックアップ終了を履歴クリア部２５２に通知する。履歴クリア部２５２は、全アクセス履歴部２５０に保存されている情報を消去する。その後、次回のサービス１１のバックアップデータ取得時まで、全アクセス履歴部２５０には、クライアント１２とサービス１１との間の通信履歴が保存される。全アクセス履歴部２５０は、図９の主記憶部１０２あるいは補助記憶部１０３に設けられれば良い。
【０１６５】
リカバリ処理部２５１は、リカバリ終了の通知をモード処理振分部２１４ａから受ける。バックアップあるいはリカバリが終了されると、リカバリ処理部２５１はアクセス管理部２１０にリカバリ完了に対する処理を依頼する。リカバリ完了に対する処理は、例えば、全アクセス履歴部２５０に基づきクライアント１２とサービス１１間のステートを復元する処理である。
【０１６６】
モード処理振分部２１４ａは、サービス１１のバックアップ終了、リカバリ終了の通知をモード管理部２０３ａから受信する。モード処理振分部２１４ａは、バックアップあるいはリカバリの終了の通知を受けると、リカバリ処理部２５１にリカバリ終了に対する処理の開始を指示する。
【０１６７】
履歴クリア部２５２は、モード処理振分部２１４ａからバックアップ終了を通知されると、全アクセス履歴部２５０に保存されている情報を消去する。全アクセス履歴部２５０に保存されている情報の消去を完了すると、履歴クリア部２５２はモード処理振分部２１４ａに完了報告をする。
【０１６８】
運用管理部２２０ａは、サービス１１のバックアップおよびリカバリを実行する。運用管理部２２０ａは、サービス１１のバックアップおよびリカバリの開始および終了をモード管理部２０３ａに通知する。
【０１６９】
図３２は、第２実施形態のリカバリ処理の流れを例示する図である。以下、図３２を参照して、第２実施形態のリカバリ処理の流れについて説明する。
【０１７０】
運用管理部２２０ａは、モード管理部２０３ａにリカバリ開始を通知する（Ｓ１１０１）。モード管理部２０３ａは、アクセスプロキシ部２０１ａのモードをリカバリモードに移行する（Ｓ１１０２）。アクセスプロキシ部２０１ａは、クライアント１２からのデータを保留する。保留されたデータは保留アクセス部２０６に保存される（Ｓ１１０３）。運用管理部２２０ａは、サービス１１のリカバリを開始する。サービス１１のリカバリが完了すると、運用管理部２２０ａはリカバリ終了をモード管理部２０３ａに通知する（Ｓ１１０４）。モード管理部２０３ａは、モード処理振分部２１４ａにリカバリ終了を通知する（Ｓ１１０５）。モード処理振分部２１４ａは、リカバリ処理２１５にステートの復元を指示する。リカバリ処理２１５は、全アクセス履歴部２５０を基にステートを復元するデータを生成する。リカバリ処理２５１は、生成したデータの送信をアクセス管理部２１０に依頼する。アクセス管理部２１０は依頼されたデータをサービスアクセス部２１７を介してサービス１１へ送信することで、クライアント１２とサービス１１との間のステートを復元する（Ｓ１１０６）。モード処理振分部２１４ａは、モード管理部２０３ａにステートの復元処理の完了を通知する（Ｓ１１０７）。モード管理部２０３ａは、アクセスプロキシ部２０１ａのモードを通常モードに設定する（Ｓ１１０８）。通常モードに設定されたアクセスプロキシ部２０１ａは、保留アクセス部２０６に保存されたデータを読み出し、サービス１１へ送信する（Ｓ１１０９）。モード管理部２０３ａは、運用管理部２２０ａに処理の完了を通知する（Ｓ１１１０）。
【０１７１】
図３３は、第２実施形態のバックアップ処理の流れを例示する図である。以下、図３３を参照して、第２実施形態のバックアップ処理の流れを説明する。
【０１７２】
Ｓ１２０１からＳ１２０５までの処理は、リカバリ処理がバックアップ処理に変更されていることを除いて、Ｓ１１０１からＳ１１０５と同様である。そのため、説明は省略される。モード処理振分部２１４ａは、履歴クリア部２５２に対して全アクセス履歴部２５０に保存されている通信履歴の消去を指示する。履歴クリア部２５２は、モード処理振分部２１４ａからの指示に応じて、全アクセス履歴部２５０に保存されている通信履歴を消去する（Ｓ１２０６）。履歴クリア部２５２は、全アクセス履歴部２５０に保存されている通信履歴の消去完了をモード処理振分部２１４ａに通知する（Ｓ１２０７）。モード処理振分部２１４ａは、モード管理部２０３ａに処理の完了を通知する（Ｓ１２０８）。Ｓ１２０９からＳ１２１１までの処理は、Ｓ１１０８からＳ１１１０と同様である。そのため、説明は省略される。
【０１７３】
第２実施形態では、バックアップ取得時からのクライアント１２とサービス１１の通信履歴を全アクセス履歴部２５０に保存した。第２実施形態は、サービス１１をリカバリした場合、全アクセス履歴部２５０に記憶された情報を基づき、クライアント１２とサービス１１のバックアップ取得時以降のステートを復元する。そのため、第２実施形態のシステムは、クライアント１２とサービス１１との間のステートを復元できる。全アクセス履歴部２５２に保存される情報の項目は、例えば、アクセス履歴部２１１と同様である。
【０１７４】
以上で開示した実施形態や変形例はそれぞれ組み合わせる事ができる。例えば、第１実施形態および第２実施形態を組み合わせることで、サービス１１のアップデートおよびバックアップからのリカバリの双方に対応可能なシステムが実現される。
【０１７５】
＜その他＞
以上の変形例を含む第１実施形態および第２実施形態に関し、更に以下の付記を開示する。
（付記１）
サービスを提供するサーバと前記サーバから前記サービスの提供を受ける端末との間の通信を中継する情報処理装置であって、
前記サーバによる前記サービス提供の中断および再開の通知を前記サービスの稼働状況を監視する装置から受ける管理部と、
前記管理部によって前記サーバによる前記サービスの提供の中断の通知を受けると、前記端末から前記サーバへ送信されるデータを保留する保留部と、
前記管理部によって前記サーバによる前記サービス提供の再開の通知を受けると、前記保留部によって保留された前記データを前記サーバに送信する送信部と、を備える、
情報処理装置。
（付記２）
前記サーバから前記端末へ提供される前記サービスに伴うデータに前記サーバと前記端末との間の接続に関するパラメータを含むセッション情報が含まれている場合、前記サービス提供の中断前におけるセッション情報と前記サービス提供の再開後におけるセッション情報の対応を記憶するセッション情報記憶部、をさらに備える、
付記１に記載の情報処理装置。
（付記３）
前記セッションを終了させる手順を記憶するセッション終了手順記憶部と、
前記管理部によって前記サーバによる前記サービス提供の中断の通知を受けると、前記セッション終了記憶部と前記セッション情報記憶部を参照し、前記端末と前記サーバとの間のセッションを終了するセッション終了部と、をさらに備える、
付記２に記載の情報処理装置。
（付記４）
前記サーバと前記端末との間の通信の履歴を保存する履歴保存部と、
前記管理部によって前記サーバによる前記サービス提供の再開の通知を受けると、前記履歴保存部に保存された通信の履歴と前記セッション情報記憶部に記憶された情報に基づいて、前記サーバによって提供される前記サービスの状態を前記サービス提供の中断時点の状態に復元する復元部と、をさらに備える、
付記２または付記３に記載の情報処理装置。
（付記５）
前記履歴保存部に保存する対象となる通信を特定する情報を保存する特定部をさらに備える、
付記４に記載の情報処理装置。
（付記６）
前記セッション情報記憶部を参照して前記端末から送信された中断前の前記サーバに対するデータを再開後の前記サーバに対するデータに変換する変換部、をさらに備える、
付記２から付記５のいずれか一項に記載の情報処理装置。
（付記７）
前記サーバへの接続方式が前記サービスの中断および再開によって変更される場合に、中断前の前記サービスへの接続方式と再開後の前記サービスへの接続方式の対応を記憶する対応記憶部と、
前記対応記憶部を参照して、中断前の前記サービスへ送信されるデータを再開後の前記サービスへ送信されるデータに変換する接続方式変換部と、をさらに備える、
付記１から付記６のいずれか一項に記載の情報処理装置。
（付記８）
サービスを提供するサーバと前記サーバから前記サービスの提供を受ける端末との間の通信を中継する情報処理装置が、
前記サーバによる前記サービス提供の中断および再開の通知を前記サービスの稼働状況を監視する装置から受ける管理ステップと、
前記管理ステップによって前記サーバによる前記サービスの提供の中断の通知を受けると、前記端末から前記サーバへ送信されるデータを保留する保留ステップと、
前記管理ステップによって前記サーバによる前記サービス提供の再開の通知を受けると、前記保留ステップによって保留された前記データを前記サーバに送信する送信ステップと、を実行する、
情報処理方法。
（付記９）
前記サーバから前記端末へ提供される前記サービスに伴うデータに前記サーバと前記端末との間の接続に関するパラメータを含むセッション情報が含まれている場合、前記サービス提供の中断前におけるセッション情報と前記サービス提供の再開後におけるセッション情報の対応を記憶するセッション情報記憶ステップ、をさらに実行する、
付記８に記載の情報処理方法。
（付記１０）
前記情報処理装置は前記セッションを終了させる手順を記憶するセッション終了手順記憶部を備え、
前記管理ステップによって前記サーバによる前記サービス提供の中断の通知を受けると、セッション終了記憶部に記憶された情報と前記セッション情報記憶ステップで記憶された情報を参照し、前記端末と前記サーバとの間のセッションを終了するセッション終了ステップ、をさらに実行する、
付記９に記載の情報処理方法。
（付記１１）
前記サーバと前記端末との間の通信の履歴を保存する履歴保存ステップと、
前記管理部によって前記サーバによる前記サービス提供の再開の通知を受けると、前記履歴保存ステップで保存された通信の履歴と前記セッション情報記憶ステップで記憶された情報に基づいて、前記サーバによって提供される前記サービスの状態を前記サービス提供の中断時点の状態に復元する復元ステップと、をさらに実行する、
付記９または付記１０に記載の情報処理方法。
（付記１２）
前記履歴保存ステップで保存する対象となる通信を特定する情報を保存する特定ステップ、をさらに実行する、
付記１１に記載の情報処理方法。
（付記１３）
前記セッション情報記憶ステップで記憶された情報を参照して前記端末から送信された中断前の前記サーバに対するデータを再開後の前記サーバに対するデータに変換する変換ステップ、をさらに実行する、
付記９から付記１２のいずれか一項に記載の情報処理方法。
（付記１４）
前記情報処理装置は前記サーバへの接続方式が前記サービスの中断および再開によって変更される場合に、中断前の前記サービスへの接続方式と再開後の前記サービスへの接続方式の対応を記憶する対応記憶部を備え、
前記対応記憶部に記憶された情報を参照して、中断前の前記サービスへ送信されるデータを再開後の前記サービスへ送信されるデータに変換する接続方式変換ステップ、をさらに実行する、
付記８から付記１３のいずれか一項に記載の情報処理方法。
（付記１５）
サービスを提供するサーバと前記サーバから前記サービスの提供を受ける端末との間の通信を中継する情報処理装置に、
前記サーバによる前記サービス提供の中断および再開の通知を前記サービスの稼働状況を監視する装置から受ける管理ステップと、
前記管理ステップによって前記サーバによる前記サービスの提供の中断の通知を受けると、前記端末から前記サーバへ送信されるデータを保留する保留ステップと、
前記管理ステップによって前記サーバによる前記サービス提供の再開の通知を受けると、前記保留ステップによって保留された前記データを前記サーバに送信する送信ステップと、を実行させる、
プログラム。
（付記１６）
前記サーバから前記端末へ提供される前記サービスに伴うデータに前記サーバと前記端末との間の接続に関するパラメータを含むセッション情報が含まれている場合、前記サービス提供の中断前におけるセッション情報と前記サービス提供の再開後におけるセッション情報の対応を記憶するセッション情報記憶ステップ、をさらに実行させる、
付記１５に記載のプログラム。
（付記１７）
前記情報処理装置は前記セッションを終了させる手順を記憶するセッション終了手順記憶部を備え、
前記管理ステップによって前記サーバによる前記サービス提供の中断の通知を受けると、セッション終了記憶部に記憶された情報と前記セッション情報記憶ステップで記憶された情報を参照し、前記端末と前記サーバとの間のセッションを終了するセッション終了ステップ、をさらに実行させる、
付記１６に記載のプログラム。
（付記１８）
前記サーバと前記端末との間の通信の履歴を保存する履歴保存ステップと、
前記管理部によって前記サーバによる前記サービス提供の再開の通知を受けると、前記
履歴保存ステップで保存された通信の履歴と前記セッション情報記憶ステップで記憶された情報に基づいて、前記サーバによって提供される前記サービスの状態を前記サービス提供の中断時点の状態に復元する復元ステップと、をさらに実行させる、
付記１６または付記１７に記載のプログラム。
（付記１９）
前記履歴保存ステップで保存する対象となる通信を特定する情報を保存する特定ステップ、をさらに実行させる、
付記１８に記載のプログラム。
（付記２０）
前記セッション情報記憶ステップで記憶された情報を参照して前記端末から送信された中断前の前記サーバに対するデータを再開後の前記サーバに対するデータに変換する変換ステップ、をさらに実行させる、
付記１６から付記１９のいずれか一項に記載のプログラム。
（付記２１）
前記情報処理装置は前記サーバへの接続方式が前記サービスの中断および再開によって変更される場合に、中断前の前記サービスへの接続方式と再開後の前記サービスへの接続方式の対応を記憶する対応記憶部を備え、
前記対応記憶部に記憶された情報を参照して、中断前の前記サービスへ送信されるデータを再開後の前記サービスへ送信されるデータに変換する接続方式変換ステップ、をさらに実行させる、
付記１５から付記２０のいずれか一項に記載のプログラム。
【符号の説明】
【０１７６】
１・・・負荷分散サーバ
２・・・サービス
２ａ〜２ｃ・・・サーバ
２ｄ・・・旧ロジック
２ｅ・・・新ロジック
２ｆ〜２ｈ・・・ステート
３・・・データベース（ＤＢ）
４・・・サーバ
５・・・ネットワーク環境
１０、５１０・・・プロキシサーバ
１０ａ、５１０ａ・・・プロキシサービス
１０ｂ、５１０ｂ・・・プロキシクライアント
１１・・・サービス
１２・・・クライアント
２０１、２０１ａ・・・アクセスプロキシ部
２０２・・・アクセス依頼部
２０３・・・モード管理部
２０４・・・アクセス変換情報部
２０５・・・変換情報保存部
２１０・・・アクセス管理部
２１１・・・アクセス履歴部
２１２・・・セッション情報部
２１３・・・ステート復元部
２１４、２１４ａ・・・モード処理振分部
２１５・・・終了処理部
２１６・・・終了シーケンス部
２１７、２１７ａ・・・サービスアクセス部
２１８・・・アクセス管理情報部
２１９・・・インターフェース対応情報部
２２０、２２０ａ・・・運用管理部
２５０・・・全アクセス履歴部
２５１・・・リカバリ処理部
２５２・・・履歴クリア部
【図１】
2015197759.tif 000003
【図２】
2015197759.tif 000004
【図３】
2015197759.tif 000005
【図４】
2015197759.tif 000006
【図５】
2015197759.tif 000007
【図６】
2015197759.tif 000008
【図７】
2015197759.tif 000009
【図８】
2015197759.tif 000010
【図９】
2015197759.tif 000011
【図１０】
2015197759.tif 000012
【図１１】
2015197759.tif 000013
【図１２】
2015197759.tif 000014
【図１３】
2015197759.tif 000015
【図１４】
2015197759.tif 000016
【図１５】
2015197759.tif 000017
【図１６】
2015197759.tif 000018
【図１７】
2015197759.tif 000019
【図１８】
2015197759.tif 000020
【図１９】
2015197759.tif 000021
【図２０】
2015197759.tif 000022
【図２１】
2015197759.tif 000023
【図２２】
2015197759.tif 000024
【図２３】
2015197759.tif 000025
【図２４Ａ】
2015197759.tif 000026
【図２４Ｂ】
2015197759.tif 000027
【図２５Ａ】
2015197759.tif 000028
【図２５Ｂ】
2015197759.tif 000029
【図２５Ｃ】
2015197759.tif 000030
【図２６】
2015197759.tif 000031
【図２７】
2015197759.tif 000032
【図２８】
2015197759.tif 000033
【図２９】
2015197759.tif 000034
【図３０Ａ】
2015197759.tif 000035
【図３０Ｂ】
2015197759.tif 000036
【図３０Ｃ】
2015197759.tif 000037
【図３１】
2015197759.tif 000038
【図３２】
2015197759.tif 000039
【図３３】
2015197759.tif 000040