JP2005100344A - 情報処理装置、セッションの復旧方法、セッション復旧プログラム及び記録媒体 - Google Patents

Abstract

【課題】 ネットワークを介して接続しているサーバ装置とのセッションが無効となった場合に、その旨をユーザに意識させることなくセッションを復旧させることができる情報処理装置の提供を目的とする。
【解決手段】 ネットワークを介して接続するサーバ装置とのセッションを開設し、前記セッションに基づいて前記サーバ装置と通信を行う情報処理装置であって、前記セッションを開設するために入力された認証情報を保持する認証情報保持手段と、前記セッションが無効となった旨を検知するセッション無効化検知手段と、前記セッション無効化検知手段によって前記セッションが無効となった旨が検知された場合に、前記認証情報保持手段に保持されている前記認証情報を用いて前記サーバ装置に対しセッションの開設を要求するセッション復旧手段とを有することにより上記課題を解決する。
【選択図】 図４

Description

本発明は、サーバ装置との間にセッションを開設し当該セッションに基づいてサーバ装置に所定の処理を実行させる情報処理装置に関する。

近年のＷｅｂシステムは、図１に示されるような形態によって構成されるのが一般的である。図１は、一般的なＷｅｂシステムの構成例を示す図である。

図１におけるＷｅｂシステム５００は、相互にネットワークによって接続されたＷｅｂクライアント５０１、Ｗｅｂサーバ５０２、アプリケーションサーバ５０３及びアプリケーションサーバ５０４等から構成されている。

Ｗｅｂクライアント５０１は、Ｗｅｂブラウザを備えたＰＣ等の端末である。Ｗｅｂサーバ５０２は、いわゆるＷｅｂサーバであり、Ｗｅｂクライアント５０１から要求されたＷｅｂページの生成等を行い、当該ＷｅｂページをＷｅｂクライアント５０１に対して送信する。

アプリケーションサーバ５０３及び５０４は、業務ロジック等が実装されているサーバであり、Ｗｅｂサーバ５０２からの要求をうけて業務ロジックに係る処理を実行し、その結果をＷｅｂサーバ５０２に対して提供する。

ここで、ネットワーク境界が存在するＷｅｂクライアント５０１とＷｅｂサーバ５０２との間と、Ｗｅｂサーバ５０２とアプリケーションサーバ５０３及び５０４との間には、それぞれ処理の継続性を保つためにセッションが開設される。

通常、セッションを開設するためには、ユーザは認証を受ける必要があり、アプリケーションサーバ５０３やアプリケーションサーバ５０４に対するアクセスが最初に発生するタイミング等において、ユーザ名及びパスワードの入力が要求される。
特開平５−１２０２３２号公報 特開２００３−５０７６１号公報

しかしながら、各セッションは、セキュリティ上の観点及びマシン負荷の軽減の観点等より、所定の時間が経過するとタイムアウトによって無効となってしまうことがある。したがって、図１において、Ｗｅｂクライアント５０１からの要求に基づいて、Ｗｅｂサーバ５０２がアプリケーションサーバ５０３及び５０４とのセッションを開設した場合、Ｗｅｂサーバ５０２とアプリケーションサーバ５０３との間でやり取りが行われている間等に、Ｗｅｂサーバ５０２とアプリケーションサーバ５０４とのセッションがタイムアウトしてしまうことがある。

かかる場合に、Ｗｅｂサーバ５０２がアプリケーションサーバ５０４に対して改めて処理要求を行うと、Ｗｅｂサーバ５０２は、アプリケーションサーバ５０４よりタイムアウトエラーを受け取り、処理を継続することができないか、又は、改めてＷｅｂクライアント５０１において、ユーザ名及びパスワードの入力といった煩雑な作業をユーザに強いる必要があるという問題がある。

また、セッションか復旧された場合であっても、復旧後に実行しようとする処理が、セッションが無効となる前に実行された処理の結果に基づいて実行されるようなものである場合、例えば、一次的な検索結果に基づいて実行される絞込み検索であるような場合は、その前提となる処理の結果はセッションの無効化と共にクリアされてしまっているため、ユーザは、再度、前提となる処理を実行するための操作（例えば、一次的な検索の指示等）を行わなければならないという問題がある。

なお、特許文献１には、タイムシェアリング・システムにおけるセッションが切断された場合の一時ファイルの救済に関する発明が開示されている。また、特許文献２には、映像や音楽の配信を受けるためのセッションが切断された場合に、切断が起こった以降の情報の配信を受けることができる発明が開示されている。

しかし、これらの発明は共に、セッションを復旧する際にユーザが改めて認証情報を入力しなければならないといった問題や、セッションが無効となるまでに行われた一つ以上の操作を改めて行わなければならないといった問題を解決するものではない。

本発明は、上記の点に鑑みてなされたものであって、ネットワークを介して接続するサーバ装置とのセッションが無効となった場合に、その旨をユーザに意識させることなく復旧させることのできる情報処理装置、セッションの復旧方法、セッション復旧プログラム及び記録媒体の提供を目的とする。

そこで上記課題を解決するため、本発明は、請求項１に記載されるように、ネットワークを介して接続するサーバ装置とのセッションを開設し、前記セッションに基づいて前記サーバ装置と通信を行う情報処理装置であって、前記セッションを開設するために入力された認証情報を保持する認証情報保持手段と、前記セッションが無効となった旨を検知するセッション無効化検知手段と、前記セッション無効化検知手段によって前記セッションが無効となった旨が検知された場合に、前記認証情報保持手段に保持されている前記認証情報を用いて前記サーバ装置に対しセッションの開設を要求するセッション復旧手段とを有することを特徴とする。

このような情報処理装置では、サーバ装置とのセッションを開設するための用いたユーザ名及びパスワード等の認証情報を保持しておくため、当該セッションが無効となった場合は、保持されている認証情報を用いてサーバ装置とのセッションを再度開設させることができる。よって、ユーザにセッションが無効となった旨を意識させることなく、セッションを復旧させることができる。

また上記課題を解決するため、本発明は、上記情報処理装置におけるセッションの復旧方法、前記方法をコンピュータに実行させるためのセッション復旧プログラム、又は前記セッション復旧プログラムを記録した記録媒体としてもよい。

本発明によれば、ネットワークを介して接続しているサーバ装置とのセッションが無効となった場合に、その旨をユーザに意識させることなくセッションを復旧させることができる情報処理装置、セッションの復旧方法、セッション復旧プログラム及び記録媒体を提供することができる。

以下、図面に基づいて本発明の実施の形態を説明する。図２は、本発明の実施の形態における文書管理システムの構成例を示す図である。図２に示されるように、本実施の形態における文書管理システム１は、Ｗｅｂサーバ１０と、文書管理サーバ２０及び３０と、端末４０とから構成され、各構成要素は、インターネットやＬＡＮ等のネットワーク５０（有線、無線の別を問わない）を介して接続されている。

Ｗｅｂサーバ１０は、端末４０が要求する情報を表示するＷｅｂページを端末４０に提供するための機能を有するコンピュータである。ここでＷｅｂページとは、汎用的なＷｅｂブラウザで表示可能なＨＴＭＬ，ＸＭＬ形式等のデータをいう。Ｗｅｂサーバ１０は、端末４０に対するＷｅｂページの提供に際し、必要に応じて文書管理サーバ２０又は３０の機能を利用する。

文書管理サーバ２０及び３０は、文書情報（文書データの実データや属性情報等）を管理する文書データベースが実装されたコンピュータであり、文書情報の登録、検索、及び更新等の諸機能をＷｅｂサービス（文書管理サービス）としてネットワーク５０上に提供する。なお、本実施の形態において文書管理サーバ２０と文書管理サーバ３０とは、機能としては同等のものが実装されているが、それぞれが管理している文書情報の内容は異なる。

端末４０は、Ｗｅｂサーバ１０が提供するＷｅｂページを閲覧するためのＷｅｂブラウザを備えたＰＣ、ＰＤＡ（Personal Digital(Data) Assistants）、又は携帯電話等の通信端末である。

次に、Ｗｅｂサーバ１０の詳細について説明する。図３は、本発明の実施の形態におけるＷｅｂサーバのハードウェア構成例を示す図である。図３のＷｅｂサーバ１０は、それぞれバスBで相互に接続されているドライブ装置１００と、補助記憶装置１０２と、メモリ装置１０３と、演算処理装置１０４と、インタフェース装置１０５とを有するように構成される。

Ｗｅｂサーバ１０での処理を実現するプログラムは、CD―ROM等の記録媒体１０１によって提供される。プログラムを記録した記録媒体１０１がドライブ装置１００にセットされると、プログラムが記録媒体１０１からドライブ装置１００を介して補助記憶装置１０２にインストールされる。

補助記憶装置１０２は、インストールされたプログラムを格納すると共に、必要なファイルやデータ等を格納する。例えば補助記憶装置１０２は、プログラムの処理に必要な、後述するテーブルを格納している。

メモリ装置１０３は、プログラムの起動指示があった場合に、補助記憶装置１０２からプログラムを読み出して格納する。演算処理装置１０４は、メモリ装置１０３に格納されたプログラムに従ってＷｅｂサーバ１０に係る機能を実行する。インタフェース装置１０５は例えばモデム、ルータ等で構成され、図２のネットワーク５０に接続するために用いられる。

図４は、第一の実施の形態における文書管理システムの機能構成例を示す図である。図４に示されるように、Ｗｅｂサーバ１０は、ｈｔｔｐｄ１１、Ｗｅｂページ生成モジュール１２、ロジック部１３、リカバリ処理モジュール１４、ＳＯＡＰプロキシ１５、及びアカウント管理テーブル１６等から構成される。

ｈｔｔｐｄ１１は、端末４０より送信されるＨＴＴＰリクエストを受信し、Ｗｅｂページ生成モジュール１２に対し、当該ＨＴＴＰリクエストにおいて要求されている情報を表示するＷｅｂページの生成を要求するデーモンプログラムである。ｈｔｔｐｄ１１は、また、Ｗｅｂページ生成モジュール１２が生成したＷｅｂページをＨＴＴＰレスポンスに含めて端末４０に対して送信する。

Ｗｅｂページ生成モジュール１２は、端末４０より要求されたＷｅｂページを生成する処理を実行するモジュールである。ロジック部１３は、端末４０より要求されたＷｅｂページに表示させる情報を生成又は取得等するためのロジックが実装されている部分であり、処理結果として得た情報をＷｅｂページ生成モジュール１２に対して出力する。

リカバリ処理モジュール１４は、Ｗｅｂサーバ１０と文書管理サーバ２０又は３０とのセッションがタイムアウト等により無効となった場合に、当該セッションの復旧処理を実行するモジュールである。

ＳＯＡＰプロキシ１５は、文書管理サーバ２０又は３０の機能を呼び出すためのメソッドインタフェースをロジック部１３に対して提供するモジュールであり、ロジック部１３からのメソッド呼び出しに応じ、当該メソッドに対応する処理の実行を要求するＳＯＡＰメッセージを文書管理サーバ２０又は３０に対して送信する。

アカウント管理テーブル１６は、端末４０のユーザによって入力されたユーザ名及びパスワード等の認証情報を保持しておくためのテーブルである。

文書管理サーバ２０及び文書管理サーバ３０は、それぞれ文書管理サービス２１、文書管理サービス３１を有している。文書管理サービスは、文書管理機能をＷｅｂサービスとして提供するためのものであり、Ｗｅｂサーバ１０からのＳＯＡＰメッセージに応じて処理を実行し、当該処理結果をＳＯＡＰメッセージとしてＷｅｂサーバ１０に対して返信する。

以下、図４の文書管理システムの処理手順について説明する。図５、図６及び図７は、第一の実施の形態の文書管理システムにおけるセッションの復旧処理を説明するためのシーケンス図である。

端末４０のユーザが、文書管理サーバ２０において管理されている文書データの一覧情報を参照すべく、文書管理サーバ２０の文書データの一覧情報を表示するＷｅｂページ（以下、「文書一覧ページ」という。）に対するＵＲＬをＷｅｂブラウザ４１に入力すると、Ｗｅｂブラウザ４１は、Ｗｅｂサーバ１０に対して文書一覧ページの送信を要求するＨＴＴＰリクエストを送信する（Ｓ１０１）。

ステップＳ１０１に続いてステップＳ１０２に進み、ＨＴＴＰリクエストを受信したｈｔｔｐｄ１１によって、Ｗｅｂページ生成モジュール１２が呼び出されると、Ｗｅｂページ生成モジュール１２は、ロジック部１３に対して文書管理サーバ２０における文書データの一覧情報（以下、「文書一覧」という。）の取得を要求する（Ｓ１０３）。

ステップＳ１０３に続いてステップＳ１０４に進み、ロジック部１３は、文書管理サーバ２０とのセッションは既に開設されているか否かを判断する。ここでは、まだ、文書管理サーバ２０とのセッションは開設されていないものとする。したがって、ロジック部１３は、セッションが開設されていないため文書管理サーバ２０にアクセスできない旨を示すエラー情報をＷｅｂページ生成モジュール１２に対して出力する（Ｓ１０５）。

ステップＳ１０５に続いてステップＳ１０６に進み、Ｗｅｂページ生成モジュール１２は、ロジック部１３より出力されたエラー情報に基づいて、文書管理サーバ２０とのセッションを開設するために必要な、端末４０のユーザのユーザ名及びパスワードをユーザに入力させるためのＷｅｂページ（以下、「ログインページ」という。）をｈｔｔｐｄ１１に対して出力する。

ステップＳ１０６に続いてステップＳ１０７に進み、ｈｔｔｐｄ１１がログインページをＷｅｂブラウザ４１に対して送信すると、Ｗｅｂブラウザ４１はログインページを表示する。

ステップＳ１０７に続いてステップＳ１０８に進み、ユーザがログインページにおいて文書管理サーバ２０にアクセスするためのユーザ名及びパスワードを入力すると、Ｗｅｂブラウザ４１は、当該ユーザ名及びパスワードを伴って、改めて文書一覧ページの送信を求めるＨＴＴＰリクエストをＷｅｂサーバ１０に対して送信する。

ステップＳ１０８に続いてステップＳ１０９に進み、ｈｔｔｐｄ１１がＷｅｂページ生成モジュール１２を呼び出すと、Ｗｅｂページ生成モジュール１２は、ユーザ名及びパスワードを伴って、ロジック部１３に対して文書一覧を要求する（Ｓ１１０）。

ステップＳ１１０に続いてステップＳ１１１に進み、ロジック部１３は、ＳＯＡＰプロキシ１５を介して文書管理サーバ２０における文書管理サービス２１のセッション開設メソッド（セッションの開設を要求するメソッド）をＳＯＡＰのＲＰＣによって呼び出す。すなわち、ロジック部１３が、ＳＯＡＰプロキシ１５のセッション開設メソッドを呼び出すと（Ｓ１１１）、ＳＯＡＰプロキシ１５は、文書管理サービス２１のセッション開設メソッドに対する呼び出し情報を含むＳＯＡＰメッセージをＳＯＡＰリクエストとして文書管理サービス２１に対して送信する（Ｓ１１２）。なお、セッション開設メソッドの引数には、Ｗｅｂブラウザ４１より送信されたユーザ名とパスワードとが指定される。

ステップＳ１１２に続いてステップＳ１１３に進み、文書管理サービス２１は、ＳＯＡＰリクエストに含まれているユーザ名及びパスワードに基づいてユーザの認証を行い、認証された場合は、Ｗｅｂサーバ１０とのセッションを開設する。

ステップＳ１１３に続いてステップＳ１１４に進み、文書管理サービス２１が、新たに開設したセッションのセッションＩＤを含むＳＯＡＰメッセージをＳＯＡＰレスポンスとしてＳＯＡＰプロキシ１５に対して送信すると、ＳＯＡＰプロキシ１５は、ＳＯＡＰレスポンスに含まれているセッションＩＤを取り出し、当該セッションＩＤをロジック部１３に対して出力する（Ｓ１１５）。

ステップＳ１１５に続いてステップＳ１１６に進み、ロジック部１３は、文書管理サービス２１とのセッションが正常に開設されたことを受けて、当該セッションの開設に用いられたユーザ名とパスワードとをアカウント管理テーブル１６に登録する。

図８は、アカウント管理テーブルの構成例を示す図である。図８に示されるように、アカウント管理テーブル１６は、サービス名、ユーザ名及びパスワード等のデータ項目を有している。サービス名は、開設されたセッションに係るＷｅｂサービスの名前を登録するための項目である。ここでは、文書管理サービス２１とのセッションを開設したため、「文書管理サービス２１」と登録されている。ユーザ名及びパスワードは、文書管理サービス２１とのセッションに係るユーザのユーザ名及びパスワードである。アカウントテーブル１６によって、Ｗｅｂサービスごとに当該Ｗｅｂサービスとのセッションの開設に用いられたユーザ名及びパスワードが保持されている。

ステップＳ１１６に続いてステップＳ１１７に進み、ロジック部１３は、開設されたセッションのセッションＩＤに基づいてＳＯＡＰプロキシ１５を介して文書管理サービス２１の文書一覧取得メソッドをＳＯＡＰのＲＰＣによって呼び出すことにより、文書管理サービス２１に対して文書管理サーバ２０において管理されている文書データの一覧情報（文書一覧）の提供を要求する（Ｓ１１８）。

ステップＳ１１８に続いてステップＳ１１９に進み、文書管理サービス２１が、文書一覧を含むＳＯＡＰメッセージをＳＯＡＰレスポンスとしてＳＯＡＰプロキシ１５に対して送信すると、ＳＯＡＰプロキシ１５は、ＳＯＡＰレスポンスより文書一覧を取り出し、当該文書一覧をロジック部１３に対して出力する（Ｓ１２０）。

ステップＳ１２０に続いてステップＳ１２１に進み、ロジック部１３が文書一覧をＷｅｂページ生成モジュール１２に対して出力すると、Ｗｅｂページ生成モジュール１２は、当該文書一覧を表示する文書一覧ページを生成する（Ｓ１２２）。

ステップＳ１２２に続いてステップＳ１２３に進み、Ｗｅｂページ生成モジュール１２が文書一覧ページをｈｔｔｐｄ１１に対して出力すると、ｈｔｔｐｄ１１は、文書一覧ページをＷｅｂブラウザ４１に対して送信する。文書一覧ページは、Ｗｅｂブラウザ４１よって表示され、ユーザは、文書管理サーバ２０において管理されている文書一覧を確認することができる。

ここで、文書一覧ページに表示された文書一覧の中に所望の文書データが含まれていなかった等の理由により、ユーザが文書管理サーバ２０以外の文書管理サーバ（本実施の形態においては文書管理サーバ３０）における文書一覧を確認しようとしたとする。

すなわち、ステップＳ２０１（図６）において、ユーザが、文書管理サーバ３０における文書一覧を表示する文書一覧ページに対するＵＲＬをＷｅｂブラウザ４１に入力すると、Ｗｅｂブラウザ４１は、Ｗｅｂサーバ１０に対して文書一覧ページの送信を要求するＨＴＴＰリクエストを送信する。

以降は、文書管理サーバ３０を対象として、図５のステップＳ１０２〜Ｓ１２４と同様の処理が実行される（Ｓ２０２〜Ｓ２２４）。その結果、Ｗｅｂサーバ１０と文書管理サービス３１との間に新たなセッションが開設され、文書管理サーバ３０における文書一覧を表示する文書一覧ページがＷｅｂブラウザ４１によって表示される。

ユーザが、当該文書一覧ページ上でしばらくの間文書管理サーバ３０における文書データの操作（文書データの印刷、文書データの配信等）を行った後、改めて文書管理サーバ２０の文書一覧を確認しようとしたとする。

すなわち、ステップＳ３０１（図７）において、ユーザが、ステップＳ１０１と同様に、文書管理サーバ２０における文書一覧を表示する文書一覧ページに対するＵＲＬをＷｅｂブラウザ４１に入力すると、Ｗｅｂブラウザ４１は、Ｗｅｂサーバ１０に対して文書一覧ページの送信を要求するＨＴＴＰリクエストを送信する。

ステップＳ３０１に続いてステップＳ３０２に進み、ｈｔｔｐｄ１１がＷｅｂページ生成モジュール１２を呼び出すと、Ｗｅｂページ生成モジュール１２は、ロジック部１３に対して文書管理サーバ２０における文書一覧の取得を要求する（Ｓ３０３）。

文書管理サーバ２０とのセッションは既に開設されているため、ロジック部１３は、ＳＯＡＰプロキシ１５を介して文書管理サービス２１の文書一覧取得メソッドをＳＯＡＰのＲＰＣによって呼び出す（Ｓ３０４、Ｓ３０５）。

ステップＳ３０５に続いてステップＳ３０６に進み、文書管理サービス２１は、Ｗｅｂサーバ１０とのセッションが既にタイムアウトによって無効になっていないかを判断する。ここでは、ユーザが、文書管理サーバ３０における文書データに対する操作を行っていた間に、当該セッションがタイムアウトしていたものとする。したがって、文書管理サービス２１は、セッションがタイムアウトしている旨を通知するエラー情報（タイムアウトエラー）を含むＳＯＡＰメッセージをＳＯＡＰレスポンスとしてＳＯＡＰプロキシ１５に対して送信する（Ｓ３０７）。

ステップＳ３０７に続いてステップＳ３０８に進み、ＳＯＡＰプロキシ１５がＳＯＡＰレスポンスに含まれているエラー情報を取り出して、ロジック部１３に対して出力すると、ロジック部１３は、当該エラー情報に基づいて、セッションが無効となっている旨を検知する。

従来であれば、ここで、ステップＳ１０６（図５）と同様に、Ｗｅｂページ生成モジュール１２に対してエラーを出力することにより、ログインページによってユーザに改めてユーザ名及びパスワードを入力させる必要があるが、本実施の形態におけるロジック部１３は、Ｗｅｂページ生成モジュール１２に対してエラーは出力せずに、リカバリ処理モジュール１４に対して、文書管理サービス２１とのセッションの復旧処理の実行を要求する（Ｓ３０９）。

ステップＳ３０９に続いてステップＳ３１０に進み、リカバリ処理モジュール１４は、アカウント管理テーブル１６（図８）より、ステップＳ１１６（図５）において登録されている、文書管理サービス２１に対するユーザ名及びパスワードを取得する。

ステップＳ３１０に続いてステップＳ３１１に進み、リカバリ処理モジュール１４は、当該ユーザ名及びパスワードを引数に指定して、文書管理サービス２１のセッション開設メソッドをＳＯＡＰのＲＰＣによって呼び出す（Ｓ３１２）。

ステップＳ３１２に続いてステップＳ３１３に進み、文書管理サービス２１は、ユーザ名及びパスワードに基づいてユーザの認証を行い、Ｗｅｂサーバ１０とのセッションを改めて開設する。

ステップＳ３１３に続いてステップＳ３１４に進み、文書管理サービス２１が新たに接続したセッションのセッションＩＤを含むＳＯＡＰメッセージをＳＯＡＰレスポンストとしてＳＯＡＰプロキシ１５に対して送信すると、ＳＯＡＰプロキシ１５は、ＳＯＡＰレスポンスよりセッションＩＤを取り出し、当該セッションＩＤをリカバリ処理モジュール１４に対して出力する（Ｓ３１５）。

ステップＳ３１５に続いてステップＳ３１６に進み、リカバリ処理モジュール１４は、ロジック部１３に対してセッションＩＤを出力する。

以降において、改めて接続されたセッションに基づいて、ステップＳ１１７からステップＳ１２４までの処理と同様の処理が実行されることにより、文書管理サーバ２０における文書一覧を表示する文書一覧ページがＷｅｂブラウザ４１上に表示される（Ｓ３１７〜Ｓ３２４）。

上述したように、第一の実施の形態におけるＷｅｂサーバ１０は、当初入力されたユーザ名及びパスワード等の認証情報をアカウント管理テーブル１６に保持しておく。したがって、文書管理サービス２１又は３１とのセッションが無効となった場合でも、当該認証情報を用いてセッションの再度の開設を文書管理サービス２１等に要求することができる。よって、ユーザにセッションが無効となった旨を意識させることなく、セッションを復旧させることができる。

なお、アカウント管理テーブル１６においてユーザ名及びパスワード等を長期間保持するのは、セキュリティ上の観点より好ましくない場合もある。その場合は、ユーザ名及びパスワード等を暗号化したり、ユーザ名及びパスワード等を保持しておく期間を定めておき当該保持期間が経過したら削除したりするようにしてもよい。

ところで、Ｗｅｂサーバ１０と文書管理サービス２１又は３１とのセッションが無効となった後に、その旨を知らない端末４０より要求された処理が、当該セッションが無効になる前に実行された処理の結果に基づいて実行されるようなものである場合（例えば、セッションが無効となる前に実行された文書一覧の検索に対する、絞り込み検索等）、当該処理（絞込み検索等）を実行するために必要な情報として文書管理サービス２１等においてキャッシュされていた情報（それまでの検索結果等）は全てクリアされてしまっているため、単にセッションを復旧させただけでは、当該処理を実行させることはできない。したがって、端末４０のユーザは、セッションが無効となる直前の状態を得るためにそれまでに行った操作を改めて行わなければならない。そこで、第二の実施の形態として、単にセッションを復旧するだけではなく、セッションが無効となる直前の状態に基づいて処理が継続できるようにした例について説明する。

図９は、第二の実施の形態における文書管理システムの機能構成例を示す図である。図９中、図４と同一部分には同一符号を付し、その説明は省略する。図９のＷｅｂサーバ１０は、呼び出し履歴管理テーブル１７を更に構成要素として有している。呼び出し履歴管理テーブル１７は、ロジック部１３がＳＯＡＰプロキシ１５を介して呼び出した文書管理サービス２１及び３１のメソッドの呼び出し情報の履歴を保持しておくためのテーブルである。

以下、図９の文書管理システムの処理手順について説明する。図１０、図１１、図１２及び図１３は、第二の実施の形態の文書管理システムにおける復旧処理を説明するためのシーケンス図である。

図１０の処理は、図５において説明した処理とほぼ同様に、Ｗｅｂブラウザ４１からの文書一覧ページの要求に基づいて（Ｓ４０１）、Ｗｅｂサーバ１０と文書管理サービス２１との間にセッションが開設され（Ｓ４１１〜Ｓ４１５）、文書管理サービス２１において検索された文書一覧を表示させる文書一覧ページがＷｅｂブラウザ４１に提供されるというものである（Ｓ４１７〜Ｓ４２５）。この間、文書管理サービス２１とのセッションを開設する際に用いられたユーザ名及びパスワードがアカウント管理テーブル１６に登録される（Ｓ４１６）。また、図１０において新たに追加された処理として、ロジック部１３は、ＳＯＡＰプロキシ１５を介して文書管理サービス２１の文書一覧取得メソッドを呼び出した後に、その文書一覧取得メソッドの呼び出し情報を呼び出し履歴管理テーブル１７に登録する（Ｓ４２１）。

図１４は、呼び出し履歴管理テーブルの構成例を示す図である。図１４に示されるように、呼び出し履歴管理テーブル１７は、サービス名、メソッド名及び引数情報等の項目より構成されるテーブルである。サービス名は、メソッドの呼び出し対象とされたＷｅｂサービスのサービス名である。メソッド名は、呼び出されたメソッドのメソッド名である。引数情報は、メソッドの呼び出し時に当該メソッドに指定された引数の値である。図１４においては、文書管理サービス２１の文書一覧取得メソッドが呼び出された際の呼び出し情報が登録された例を示している。なお、ここでの引数情報は、例えば検索条件等が相当する。

図１１のステップＳ４２６に進み、ユーザが文書一覧ページにおいて、新たな検索条件を指定して絞り込み検索を指示すると、Ｗｅｂブラウザ４１は、絞り込み検索を要求するＨＴＴＰリクエストをＷｅｂサーバ１０に対して送信する。Ｗｅｂブラウザ４１からのＨＴＴＰリクエストに基づいて、ｈｔｔｐｄ１１によってＷｅｂページ生成モジュール１２が呼び出され（Ｓ４２７）、更に、ロジック部１３に対して絞り込み検索が指示される（Ｓ４２８）。ロジック部１３は、文書管理サービス２１の絞り込み検索メソッドをＳＯＡＰプロキシ１５を介して呼び出し、絞り込み検索の結果としての文書一覧を取得する（Ｓ４２９〜Ｓ４３２）。

ステップＳ４３２に続いてステップＳ４３３に進み、ロジック部１３は、ステップＳ４２９において呼び出した絞り込み検索メソッドの呼び出し情報を呼び出し履歴管理テーブル１７に登録する。これで、呼び出し履歴管理テーブル１７には、文書一覧取得時の呼び出し情報と絞込検索時の呼び出し情報とが登録されたことになる。以降、文書一覧に基づいて文書一覧ページが生成され、当該文書一覧ページがＷｅｂブラウザ４１に送信される（Ｓ４３４〜Ｓ４３７）。なお、当該文書一覧ページにおいて、更に絞り込み検索が指示された場合は、ステップＳ４２６〜Ｓ４３７の処理が繰り返され、呼び出し履歴管理テーブル１７に新たなレコードが追加される。

ここで、例えば、タイムアウトや文書管理サーバ２０のダウン等により、Ｗｅｂサーバ１０と文書管理サービス２１とのセッションが無効になったとする。ただし、セッションが無効になったとしても、端末４０のＷｅｂブラウザ４１には相変わらず絞り込み検索の結果を示す文書一覧ページが表示されたままであるため、ユーザはセッションが無効となった旨を知る由もない。

そこで、ユーザが更に絞り込み検索を指示すると、図１２のステップＳ５０１に進む。ステップＳ５０１〜ステップＳ５０５において、Ｗｅｂブラウザ４１からのＨＴＴＰリクエストに基づいて文書管理サービス２１の絞り込み検索メソッドが呼び出されると、文書管理サービス２１は、Ｗｅｂサーバ１０とのセッションが無効（例えば、タイムアウト）になっている旨を検知し（Ｓ５０６）、その旨を示す通知（例えば、タイムアウトエラー）をＳＯＡＰプロキシ１５に対して送信する（Ｓ５０７）。タイムアウトエラーは、ＳＯＡＰプロキシ１５からロジック部１３に通知される（Ｓ５０８）。

ステップＳ５０８に続いてステップＳ５０９に進み、ロジック部１３が、リカバリ処理モジュール１４に対して、文書管理サービス２１とのセッションの復旧処理の実行を要求すると、ステップＳ３１０〜ステップＳ３１６（図７）と同様の手順で、リカバリ処理モジュール１４によりセッションの復旧処理が実行される（Ｓ５１０〜Ｓ５１６）。

ステップＳ５１６に続いてステップＳ５１７に進み、ロジック部１３は、セッションが無効となる直前の状態を復元すべく、その復元処理をリカバリ処理モジュール１４に対して要求する。すなわち、現在要求されている絞り込み検索を実行するためには、それまでに実行された検索の結果が存在する状態が前提となるため、かかる状態を再現させるためである。

ステップＳ５１７に続いてステップＳ５１８に進み、リカバリ処理モジュール１４は、呼び出し履歴管理テーブル１７より、呼び出し情報を古い順に一つ取得すると、当該呼び出し情報に基づいて、メソッドの呼び出し先となる文書管理サービス、呼び出すべきメソッド名、及び引数情報を特定し、当該メソッド（文書一覧取得メソッド又は絞り込み検索メソッド）を呼び出す（Ｓ５１９）。メソッドの呼び出しは、ＳＯＡＰプロキシ１５によってＳＯＡＰリクエストとして文書管理サービス２１に送信される（Ｓ５２０）。

ステップＳ５２０に続いてステップＳ５２１に進み、文書管理サービス２１は、呼び出されたメソッドに対応した処理（例えば、文書一覧の検索等）を実行し、その処理結果（文書一覧）をＳＯＡＰプロキシ１５に対して返信する。ステップＳ５２１に続いてステップＳ５２２に進み、ＳＯＡＰプロキシ１５は、文書一覧をリカバリ処理モジュール１４に対して出力する。

上述したステップＳ５１９〜ステップＳ５２２までの処理が、呼び出し履歴テーブル１７に登録されている呼び出し情報の分だけ実行されると（Ｓ５２３）、リカバリ処理モジュール１４は、状態の復元処理が完了した旨をロジック部１３に対して通知する（Ｓ５２４）。

状態が復元されたのを受け、ロジック部１３は、Ｗｅｂブラウザ４１より要求された絞り込み検索を実行するための処理を開始する。すなわち、ステップＳ４２９〜ステップＳ４３７（図１１）において説明した手順と同様の手順で、絞込検索が実行され、その検索結果を示す文書一覧ページがＷｅｂブラウザ４１に対して送信される（図１３：Ｓ５２５〜Ｓ５３３）。

次に、図１２及び図１３において説明した状態の復元処理について、条件分岐等をより明確にするため、フローチャートを用いて説明する。図１５及び図１６は、状態の復元処理を説明するためのフローチャートである。

ステップＳ１００１において、端末４０（Ｗｅｂブラウザ４１）からの絞り込み検索等の要求が受信されると、ロジック部１３は、文書管理サービス２１に対して要求された処理の実行を要求する（Ｓ１００２）。ロジック部１３は、文書管理サービス２１からの返信に基づいて、セッションがタイムアウト等によって無効となっているか否かを判断する（Ｓ１００３）。セッションが有効な場合（Ｓ１００３でＮｏ）は、文書管理サービス２１から返信されている文書一覧等の処理結果がＷｅｂページとしてＷｅｂブラウザ４１に対して返信される（図１６：Ｓ１０１５）
セッションが無効となっていた場合（Ｓ１００３でＹｅｓ）は、ロジック部１３は、リカバリ処理モジュール１４に対してセッションの復旧を要求する（Ｓ１００４）。リカバリ処理モジュール１４は、セッションの開設するために認証を受ける必要があるか否かを判断し（Ｓ１００５）、認証が不要である場合（Ｓ１００５でＮｏ）は、そのまま文書管理サービス２１のセッション開設メソッドを呼び出すことにより、文書管理サービス２１とのセッションを復旧する（Ｓ１００９）。

セッションの開設に認証を受ける必要がある場合は、リカバリ処理モジュール１４は、ユーザ名及びパスワード等の認証情報がアカウント管理テーブル１６に登録されているか否かを確認する（Ｓ１００６）。アカウント管理テーブル１６に認証情報が登録されている場合は、リカバリ処理モジュール１４は、アカウント管理テーブル１６より認証情報を取得し、当該認証情報に基づいて文書管理サービス２１とのセッションを再接続する（Ｓ１００９）。一方、アカウント管理テーブル１６に認証情報が登録されていない場合は、Ｗｅｂブラウザ４１に対してログインページが送信され、当該ログインページに入力された認証情報に基づいてセッションの再接続が行われる（Ｓ１００８、Ｓ１００９）。

セッションが復旧されると、状態の復元処理が実行される（図１６：Ｓ１０１０）。すなわち、リカバリ処理モジュール１４は、現在Ｗｅｂブラウザ４１より要求された処理を実行するために前提となる処理の実行の要否を判断し（Ｓ１０１１）、前提処理が不要である場合（Ｓ１０１１でＮｏ）は、Ｗｅｂブラウザ４１より要求されている処理の実行を文書管理サービス２１に要求する（Ｓ１０１４）。

一方、前提処理が必要である場合は、リカバリ処理モジュール１４は、呼び出し履歴管理テーブル１７に前提処理に対応した呼び出し情報が登録されているか否かを確認する（Ｓ１０１２）。呼び出し情報が登録されている場合（Ｓ１０１２でＹｅｓ）は、リカバリ処理モジュール１４は、前提処理に対応したメソッド（文書一覧取得メソッド、絞り込み検索メソッド等）を呼び出すことにより状態を復元させる。状態が復元されると、ロジック部１３は、Ｗｅｂブラウザ４１より要求されている処理の実行を文書管理サービス２１に対して要求し（Ｓ１０１４）、その処理結果として返信された情報（文書一覧等）を、ＷｅｂページとしてＷｅｂブラウザ４１に対して送信する。なお、ステップＳ１０１２において、呼び出し情報が呼び出し履歴テーブル１７に登録されていない旨が確認された場合（Ｓ１０１２でＮｏ）は、状態を復元することは困難であるためＷｅｂブラウザ４１に対してエラーが通知される（Ｓ１０１６）。

上述したように、第二の実施の形態におけるＷｅｂサーバ１０によれば、セッションが無効となる前の状態を自動的に復元させることができる。したがって、セッションが無効となる前の状態が前提となる処理の実行が要求された場合であっても、当該セッションが無効となったことをユーザに意識させることなく要求された処理を実行させることができる。

なお、どの呼び出し情報まで遡って復元させるか、すなわちトランザクションの単位は、例えば、ロジック部１３において予め定義（プログラム等）しておき、その定義にしたがって、ロジック部１３が呼び出し履歴管理テーブル１７において区切りを設けてもよいし、Ｗｅｂブラウザ４１に提供するＷｅｂページを生成するＷｅｂページ生成モジュール１２にトランザクションの単位を判断させ、Ｗｅｂページ生成モジュール１２が呼び出し情報の記録の開始及び終了をロジック部１３に対して指示するようにしてもよい。

また、呼び出し履歴テーブル１７における呼び出し情報は、セキュリティ上の観点より、暗号化して登録したり、不要となったものは随時削除したりするようにしてもよい。

以上、本発明の好ましい実施例について詳述したが、本発明は係る特定の実施形態に限定されるものではなく、特許請求の範囲に記載された本発明の要旨の範囲内において、種々の変形・変更が可能である。

一般的なＷｅｂシステムの構成例を示す図である。 本発明の実施の形態における文書管理システムの構成例を示す図である。 本発明の実施の形態におけるＷｅｂサーバのハードウェア構成例を示す図である。 第一の実施の形態における文書管理システムの機能構成例を示す図である。 第一の実施の形態の文書管理システムにおけるセッションの復旧処理を説明するためのシーケンス図である。 第一の実施の形態の文書管理システムにおけるセッションの復旧処理を説明するためのシーケンス図である。 第一の実施の形態の文書管理システムにおけるセッションの復旧処理を説明するためのシーケンス図である。 アカウント管理テーブルの構成例を示す図である。 第二の実施の形態における文書管理システムの機能構成例を示す図である。 第二の実施の形態の文書管理システムにおける復旧処理を説明するためのシーケンス図である。 第二の実施の形態の文書管理システムにおける復旧処理を説明するためのシーケンス図である。 第二の実施の形態の文書管理システムにおける復旧処理を説明するためのシーケンス図である。 第二の実施の形態の文書管理システムにおける復旧処理を説明するためのシーケンス図である。 呼び出し履歴管理テーブルの構成例を示す図である。 状態の復元処理を説明するためのフローチャートである。 状態の復元処理を説明するためのフローチャートである。

符号の説明

１ 文書管理システム
１０ Ｗｅｂサーバ
１１ ｈｔｔｐｄ
１２ Ｗｅｂページ生成モジュール
１３ ロジック部
１４ リカバリ処理モジュール
１５ ＳＯＡＰプロキシ
１６ アカウント管理テーブル
１７ 呼び出し履歴管理テーブル
２０、３０ 文書管理サーバ
２１、３１ 文書管理サービス
４０ 端末
４１ Ｗｅｂブラウザ
５０ ネットワーク
１００ ドライブ装置
１０１ 記録媒体
１０２ 補助記憶装置
１０３ メモリ装置
１０４ 演算処理装置
１０５ インタフェース装置
Ｂ バス

Claims (13)

1. ネットワークを介して接続するサーバ装置とのセッションを開設し、前記セッションに基づいて前記サーバ装置と通信を行う情報処理装置であって、
   前記セッションを開設するために入力された認証情報を保持する認証情報保持手段と、
   前記セッションが無効となった旨を検知するセッション無効化検知手段と、
   前記セッション無効化検知手段によって前記セッションが無効となった旨が検知された場合に、前記認証情報保持手段に保持されている前記認証情報を用いて前記サーバ装置に対しセッションの開設を要求するセッション復旧手段とを有することを特徴とする情報処理装置。
2. 前記認証情報は、ユーザのユーザ名及びパスワードを含むことを特徴とする請求項１記載の情報処理装置。
3. 前記認証情報保持手段は、前記認証情報を前記セッションに係るサーバ装置と関連付けて保持することを特徴とする請求項１又は２記載の情報処理装置。
4. 前記セッション無効化検知手段は、前記セッションにおける前記サーバ装置からの応答において、前記セッションがタイムアウトしている旨が示されている場合に、前記セッションが無効となった旨を判断することを特徴とする請求項１乃至３いずれか一項記載の情報処理装置。
5. 前記セッションに基づいて前記サーバ装置に対して行った処理要求の履歴情報を保持する要求履歴保持手段を更に有し、
   前記セッション復旧手段は、復旧された前記セッションに基づいて、前記要求履歴保持手段に保持されている前記履歴情報に示される前記処理要求を前記サーバ装置に対して行うことを特徴とする請求項１乃至４いずれか一項記載の情報処理装置。
6. 前記サーバ装置に対して行った前記処理要求の履歴情報は、前記サーバ装置に当該処理要求を送信するためのメソッドの呼び出し情報の履歴であることを特徴とする請求項５記載の情報処理装置。
7. 前記メソッドの呼び出し情報は、前記メソッドのメソッド名及び引数情報を含むことを特徴とする請求項６記載の情報処理装置。
8. 前記サーバ装置は、当該サーバ装置における機能をＷｅｂサービスとして提供することを特徴とする請求項１乃至７いずれか一項記載の情報処理装置。
9. ネットワークを介して接続するサーバ装置とのセッションを開設し、前記セッションに基づいて前記サーバ装置と通信を行う情報処理装置におけるセッションの復旧方法であって、
   前記セッションを開設するために入力された認証情報を保持する認証情報保持手順と、
   前記セッションが無効となった旨を検知するセッション無効化検知手順と、
   前記セッション無効化検知手順において前記セッションが無効となった旨が検知された場合に、前記認証情報保持手順において保持されている前記認証情報を用いて前記サーバ装置に対しセッションの開設を要求するセッション復旧手順とを有することを特徴とするセッションの復旧方法。
10. 前記セッションに基づいて前記サーバ装置に対して行った処理要求の履歴情報を保持する要求履歴保持手順と、
    前記セッション復旧手順において開設された前記セッションに基づいて、前記要求履歴保持手順において保持されている前記履歴情報に示される前記処理要求を前記サーバ装置に対して行う状態復元手順とを更に有することを特徴とする請求項９記載のセッションの復旧方法。
11. コンピュータに、
    ネットワークを介して接続するサーバ装置とのセッションを開設するために入力された認証情報を保持する認証情報保持手順と、
    前記セッションが無効となった旨を検知するセッション無効化検知手順と、
    前記セッション無効化検知手順において前記セッションが無効となった旨が検知された場合に、前記認証情報保持手順において保持されている前記認証情報を用いて前記サーバ装置に対しセッションの開設を要求するセッション復旧手順とを実行させるためのセッション復旧プログラム。
12. 前記セッションに基づいて前記サーバ装置に対して行った処理要求の履歴情報を保持する要求履歴保持手順と、
    前記セッション復旧手順において開設された前記セッションに基づいて、前記要求履歴保持手順において保持されている前記履歴情報に示される前記処理要求を前記サーバ装置に対して行う状態復元手順とを更に有することを特徴とする請求項１１記載のセッション復旧プログラム。
13. 請求項１１又は１２記載のセッション復旧プログラムを記録したコンピュータ読み取り可能な記録媒体。

Images