(57)【要約】【課題】  効率的にファイルサーバを管理する。【解決手段】    実データを格納する複数のファイルサーバからファイルシステムを構築し、各ファイルサーバが処理すべきデータを管理するデータベースを備えるサーバ管理装置において、前記ファイルシステムに対して新たにファイルサーバを追加する場合、各ファイルサーバから取得する実データの情報に基づいて、追加される新規ファイルサーバに登録すべきダミーデータの登録数を決定する。そして、決定した登録数に対応するダミーデータを新規ファイルサーバのデータとして前記データベースに登録する。そして、ダミーデータを登録した後、新規追加されたファイルサーバの状態をデータ書き込み無効からデータ書き込み有効に設定する。そして、新規追加されたファイルサーバの状態がデータ書き込み有効に設定された後、前記ダミーデータを順次削減することを特徴とする。【選択図】  図２２
2013206281.tif 000002
【特許請求の範囲】
【請求項１】
実データを格納する複数のファイルサーバからファイルシステムを構築し、各ファイルサーバが処理すべきデータを管理するデータベースを備えるサーバ管理装置であって、
前記ファイルシステムに対して新たにファイルサーバを追加する場合、
各ファイルサーバから取得する実データの情報に基づいて、追加される新規ファイルサーバに登録すべきダミーデータの登録数を決定する決定手段と、
前記決定手段が決定した登録数に対応するダミーデータを前記新規ファイルサーバのデータとして前記データベースに登録する登録手段と、
前記ダミーデータを登録した後、前記新規ファイルサーバの状態をデータ書き込み無効からデータ書き込み有効に設定する設定手段と、
前記新規ファイルサーバの状態がデータ書き込み有効に設定された後、前記ダミーデータを順次削減する削減手段と、
を備えることを特徴とするサーバ管理装置。
【請求項２】
各ダミーデータは、所定の時差をもつ有効期限が設定されており、
前記削減手段は、前記有効期限に従って前記ダミーデータを順次削減することを特徴とする請求項１記載のサーバ管理装置。
【請求項３】
実データを格納する複数のファイルサーバからファイルシステムを構築し、各ファイルサーバから取得する実データに関する情報と、各ファイルサーバに格納される実データの格納先をデータベースに登録して管理するサーバ管理装置であって、
前記ファイルシステムからいずれかのファイルサーバを停止させる場合、停止すべきファイルサーバに登録すべきダミーデータ数を決定する決定手段と、
前記決定手段が決定したダミーデータ数に対応するダミーデータを前記停止すべきファイルサーバのデータとして前記データベースに登録する登録手段と、
前記停止すべきファイルサーバに実データが存在するかどうかを判断する判断手段と、
前記実データが存在しないと判断した場合、登録されたダミーデータを削減する削減手段を有し、
前記決定手段により決定されるダミーデータの数は、他のファイルサーバが処理すべきデータ数よりも多いことを特徴とするサーバ管理装置。
【請求項４】
前記設定手段は、前記ダミーデータを削除した後、停止すべきファイルサーバの状態をデータ書き込み有効からデータ書き込み無効に設定することを特徴とする請求項１記載のサーバ管理装置。
【請求項５】
実データを格納する複数のファイルサーバからファイルシステムを構築し、各ファイルサーバが処理すべきデータを管理するデータベースを備えるサーバ管理装置のサーバ管理方法であって、
前記ファイルシステムに対して新たにファイルサーバを追加する場合、
各ファイルサーバから取得する実データの情報に基づいて、追加される新規ファイルサーバに登録すべきダミーデータの登録数を決定する決定工程と、
前記決定工程が決定した登録数に対応するダミーデータを前記新規ファイルサーバのデータとして前記データベースに登録する登録工程と、
前記ダミーデータを登録した後、前記新規ファイルサーバの状態をデータ書き込み無効からデータ書き込み有効に設定する設定工程と、
前記新規ファイルサーバの状態がデータ書き込み有効に設定された後、前記ダミーデータを順次削減する削減工程と、
を備えることを特徴とするサーバ管理装置のサーバ管理方法。
【請求項６】
各ダミーデータは、所定の時差をもつ有効期限が設定されており、
前記削減工程は、前記有効期限に従って前記ダミーデータを順次削減することを特徴とする請求項５記載のサーバ装置のサーバ管理方法。
【請求項７】
実データを格納する複数のファイルサーバからファイルシステムを構築し、各ファイルサーバから取得する実データに関する情報と、各ファイルサーバに格納される実データの格納先をデータベースに登録して管理するサーバ管理装置のサーバ管理方法であって、
前記ファイルシステムからいずれかのファイルサーバを停止させる場合、停止すべきファイルサーバに登録すべきダミーデータ数を決定する決定工程と、
前記決定工程が決定したダミーデータ数に対応するダミーデータを前記停止すべきファイルサーバのデータとして前記データベースに登録する登録工程と、
前記停止すべきファイルサーバに実データが存在するかどうかを判断する判断工程と、
前記実データが存在しないと判断した場合、登録されたダミーデータを削減する削減工程を有し、
前記決定工程により決定されるダミーデータの数は、他のファイルサーバが処理すべきデータ数よりも多いことを特徴とするサーバ管理装置のサーバ管理方法。
【請求項８】
前記設定工程は、前記ダミーデータを削除した後、停止すべきファイルサーバの状態をデータ書き込み有効からデータ書き込み無効に設定することを特徴とする請求項５記載のサーバ管理装置のサーバ管理方法。
【請求項９】
請求項５乃至８のいずれか１項に記載のサーバ管理装置のサーバ管理方法をコンピュータに実行させることを特徴とするプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、複数のファイルサーバを用いてデータ処理を行うサーバ管理装置、サーバ管理装置のサーバ管理方法、及びプログラムに関するものである。
【背景技術】
【０００２】
近年、サーバコンピュータ側で各種処理を行う形態として、クラウドコンピューティングシステムやＳａａＳ（Software as a Service）という技術が利用されている。
【０００３】
クラウドコンピューティングでは、多くのコンピューティング・リソースを利用し、データ変換やデータ処理を分散実行することで、多くのクライアントからの要求を同時に処理することが可能となる。また、クラウドコンピューティングの特徴を生かすため、サーバでの一連の処理を細かく規定されたタスクの連結で実現し、それらを同時並行で処理することで、多数のジョブをスケーラブルに処理する技術が存在する。
【０００４】
上記処理において、各タスクにてデータ変換やデータ処理された結果、生成されるデータを多重化し、耐障害性を高めて保存するファイルシステムが必要となる場合がある。 その際、闇雲にデータを多重化せず、データの種類・サイズ・属性などによって多重度を変更することにより、ファイルシステム全体の容量を削減することができる。また、ファイルシステム全体のデータ量に従って保存先のファイルサーバを適切に追加・停止し、運用コストを抑えることが重要である。ファイルサーバの追加・削除に際してはシステム全体への影響を極力避ける必要がある。
【０００５】
特許文献１には、ネットワークに複数の計算機が接続された分散処理システムにおいて、管理プログラムが計算機の停止予定時刻／起動予定時刻を管理し、１つの計算機の停止／再開ができる限り分散処理システム全体に影響を与えないように制御している。管理プログラムは計算機の停止予定時刻が近づいた計算機ではプログラム起動を行わせず、起動予定時刻が近づいた計算機ではプログラムの起動を待機させることによって、全体への影響を軽減しながら、計算機の停止／再開を制御している。
【先行技術文献】
【特許文献】
【０００６】
【特許文献１】特開平７―７８０３７号公報
【発明の概要】
【発明が解決しようとする課題】
【０００７】
ここで、保存するデータよって１以上の多重度を指定して多重保存を可能な、複数のファイルサーバからなるファイルシステムを想定する。多重化された各データはそれぞれ異なるファイルサーバに保存される。このようなファイルシステムにおいては、データの保存要求があった際に、特定のファイルサーバにデータが保存されたりされなかったりする。従って、ミラーリングのような場合と異なり、各ファイルサーバに保存されているファイルは必ずしも同じとは限らない。このようなファイルシステムにおいてファイルサーバを追加・停止する場合を考える。
【０００８】
既存技術におけるプログラム起動をデータの保存（取得、更新、削除）処理と置き換えると、データの保存（取得、更新、削除）処理中にファイルサーバが停止することを防ぐことができる。
しかし、想定するファイルシステムにおいては、停止対象のファイルサーバにのみファイルが保存されている場合（多重度１の場合）も考えられるため、ファイルサーバ停止後は、ファイルサーバに保存されているデータにアクセスできなくなる。また、多重度が２以上の場合でも、多重保存されたファイルの１つが停止対象のサーバに保存されている場合は多重度が下がるため、可用性が低下する。
【０００９】
また、複数のファイルサーバにバランスよくデータが保存されるように管理されている状況において、新規にファイルサーバが追加された場合、その新規ファイルサーバにはデータが保存されていない。そのため、他のファイルサーバとのバランスを保つために新規追加したファイルサーバにデータが一気に書き込まれる。
これにより、従って新規追加したファイルサーバ以外の各ファイルサーバのデータ量を低下させることができる。しかし、新規追加したファイルサーバは多くのディスクＩ／Ｏが発生し高負荷になる。また、データの保存処理を待機するため待機中はデータを取得できないなど、ユーザエクスペリエンスが大きく低下する。
【００１０】
本発明は、上記の課題を解決するためになされたもので、本発明の目的は、効率よくファイルサーバを管理することを目的とする。
【課題を解決するための手段】
【００１１】
上記目的を達成する本発明のサーバ管理装置は以下に示す構成を備える。
実データを格納する複数のファイルサーバからファイルシステムを構築し、各ファイルサーバが処理すべきデータを管理するデータベースを備えるサーバ管理装置であって、前記ファイルシステムに対して新たにファイルサーバを追加する場合、各ファイルサーバから取得する実データの情報に基づいて、追加される新規ファイルサーバに登録すべきダミーデータの登録数を決定する決定手段と、前記決定手段が決定した登録数に対応するダミーデータを前記新規ファイルサーバのデータとして前記データベースに登録する登録手段と、前記ダミーデータを登録した後、前記新規ファイルサーバの状態をデータ書き込み無効からデータ書き込み有効に設定する設定手段と、前記新規ファイルサーバの状態がデータ書き込み有効に設定された後、前記ダミーデータを順次削減する削減手段と、を備えることを特徴とする。
【発明の効果】
【００１２】
本発明によれば、効率的にファイルサーバを管理することが可能となる。
【図面の簡単な説明】
【００１３】
【図１】クラウドシステムの全体構成を示す図である。
【図２】クラウドシステムの全体構成を説明するブロック図である。
【図３】図１に示したクライアント端末のシステム構成を示す図である。
【図４】図１に示した画像形成装置の内部構成を示すブロック図である。
【図５】図１に示したスキャンサービスサーバの構成を説明するブロック図である。
【図６】図１に示したスキャンサービスサーバが表示するＵＩ画面の例を示す図である。
【図７】図５に示したチケット管理ＤＢ部で管理されている情報の一例を示す図である。
【図８】テンプレート管理ＤＢ部で管理されているテンプレートの一例を示す図である。
【図９】画像処理ユニットが表示するＵＩ画面の一例を示す図である。
【図１０】図１に示したタスクサービスサーバのシステム構成を示すブロック図である。
【図１１】スキャン処理のシーケンス例を示す図である。
【図１２】図１に示したフローサービスサーバのシステム構成を示すブロック図である。
【図１３】ルート管理サービスサーバの構成を説明するブロック図である。
【図１４】ルート情報管理ＤＢ部で管理されている情報の一例を示す図である。
【図１５】タスク情報管理ＤＢ部で管理されている情報の一例を示す図である。
【図１６】ジョブ管理サービスサーバの構成を説明するブロック図である。
【図１７】ジョブ情報管理ＤＢ部が管理するジョブ情報テーブルを示す図である。
【図１８】一時ファイル管理サービスサーバの全体構成を示すブロック図である。
【図１９】中央管理サーバのシステム構成を示すブロック図である。
【図２０】ファイルサーバ管理ＤＢ部で管理するデータの例を示す図である。
【図２１】サーバ装置のフォルダの階層構造を示す図である。
【図２２】サーバ装置の制御方法を説明するフローチャートである。
【図２３】中央管理サーバが管理するパス情報の一例を示す図である。
【図２４】サーバ装置の制御方法を説明するフローチャートである。
【図２５】中央管理サーバが管理するパス情報の一例を示す図である。
【発明を実施するための形態】
【００１４】
次に本発明を実施するための最良の形態について図面を参照して説明する。
＜システム構成の説明＞
〔第１実施形態〕
【００１５】
図１は、本実施形態を示すサーバ管理装置を適用可能なクラウドシステムの全体構成を示す図である。
【００１６】
図１において、スキャンサービスサーバ１０１、フローサービスサーバ１０２、タスクサービスサーバ１０３、１０４、クライアント端末１０６、画像形成装置１０７、クラウドサービスサーバ１０８は、ネットワーク１１０〜１１２を介して接続されている。
図１において、タスクサービスサーバ１０３、１０４、クライアント端末１０６、画像形成装置１０７、クラウドサービスサーバ１０８は、複数台接続されていることを仮定している。ネットワーク１１０〜１１２は、例えば、インターネット等のＬＡＮ、ＷＡＮ、電話回線、専用デジタル回線、ＡＴＭやフレームリレー回線、ケーブルテレビ回線、データ放送用無線回線等のいずれであり。
またこれらの組み合わせにより実現される、いわゆる通信ネットワークである。ネットワーク１１０〜１１２は、データの送受信が可能であればよい。一般的なクラウドサービスでは、ネットワーク１１０、１１２はインターネット、ネットワーク１１１は企業内ネットワークやサービスプロバイダーのネットワークとなる。
スキャンサービスサーバ１０１、フローサービスサーバ１０２、タスクサービスサーバ１０３、１０４は、一般的にサーバコンピュータ上にて実行されており、これらサービス群がユーザに対してクラウドサービスを提供する。
また、様々な企業などにより、同様にクラウドサービスサーバ１０８がインターネット上に公開されており、これらも一般的にサーバコンピュータ上にて実行されている。
クライアント端末１０６は、例えば、デスクトップパソコン、ノートパソコン、モバイルパソコン、ＰＤＡ（パーソナルデータシスタント）等から成るが、プログラムの実行環境が内蔵された携帯電話であってもよい。クライアント端末１０６では、Ｗｅｂブラウザ（インターネットブラウザ、ＷＷＷブラウザ、Ｗｏｒｌｄ Ｗｉｄｅ Ｗｅｂの利用に供するブラウザ）等のプログラムを実行する環境が内蔵されている。
【００１７】
図２は、図１に示したクライアント端末１０６、各サービスサーバ１０１〜１０４の構成を説明するブロック図である。
図２において、Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ（ＣＰＵ）２０２は、システムバス２０１に接続される各デバイス全体の制御を行う。ＣＰＵ２０２は、ハードディスク（ＨＤＤ）２０５に格納されているアプリケーションプログラム、ＯＳ等を実行し、Ｒａｎｄａｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ（ＲＡＭ）２０３にプログラムの実行に必要な情報、ファイル等を一時的に格納する制御を行う。Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ（ＲＯＭ）２０４は記憶手段であり、内部には、基本Ｉ／Ｏプログラム等の各種データを記憶する。
【００１８】
ＲＡＭ２０３は、一時記憶手段であり、ＣＰＵ２０２の主メモリ、ワークエリア等として機能する。ＨＤＤ２０５は外部記憶手段の一つであり、大容量メモリとして機能し、Ｗｅｂブラウザ等のアプリケーションプログラム、サービス群のプログラム、ＯＳ、関連プログラム等を格納している。
ディスプレイ２０６は表示手段であり、キーボード２０７から入力したコマンド等を表示したりするものである。インタフェース２０８は外部装置Ｉ／Ｆであり、プリンター、ＵＳＢ機器、周辺機器を接続する。
【００１９】
キーボード２０７は、指示入力手段である。システムバス２０１は、装置内におけるデータの流れを司るものである。ネットワークインタフェースカード（ＮＩＣ）２０９は、該ネットワークインタフェースカード２０９、ネットワーク１１０〜１１２を介して外部装置とのデータのやり取りを行う。なお、上記コンピュータの構成はその一例であり、図２の構成例に限定されるものではない。例えば、データやプログラムの格納先は、その特徴に応じてＲＯＭ２０４、ＲＡＭ２０３、ＨＤＤ２０５などで変更することも可能である。
【００２０】
図３は、図１に示したクライアント端末１０６のシステム構成を示す図である。
図３において、Ｗｅｂブラウザ３０１を利用し、スキャンサービスサーバ１０１が提供するＷｅｂアプリケーションへのリクエストの送信と、レスポンスの表示等を行う。クラウドサービスを利用するユーザは本クライアント端末１０６のＷｅｂブラウザ３０１を利用して、クラウドサービスを利用する。
【００２１】
図４は、図１に示した画像形成装置１０７の内部構成を示すブロック図である。
本例では、スキャン・プリントの両機能を併せ持つ装置を例にするが、スキャンサービスを実現するに当たっては、プリント機能のない、スキャン専用装置でも良い。
【００２２】
図４において、画像形成装置１０７は、画像処理ユニット４０１、印刷ユニット４０２、および読み込みユニット４０３から構成される。画像処理ユニット４０１は、ＣＰＵ４０４、直接記憶部４０５、間接記憶部４０６、ユーザインタフェース４０７、外部インタフェース４０８から構成されている。
【００２３】
ＣＰＵ４０４は、所定のプログラムを実行し、画像形成装置１０７の各種制御を指示するユニットである。直接記憶部４０５は、ＣＰＵ４０４がプログラムを実行する際に使用するワークメモリであり、ＣＰＵ４０４が実行するプログラムは直接記憶部４０５にロードされる。直接記憶部４０５は、ＲＡＭ（Random Access Memory）により実現される。
【００２４】
間接記憶部４０６は、アプリケーションプログラム、およびプラットフォームプログラムを含む各種プログラムが記憶されている。間接記憶部４０６に記憶されている各種プログラムは、ＣＰＵ４０４がプログラムを実行する際に直接記憶部４０５へ移動する。間接記憶部４０６は、ＳＳＤ（Solid State Drive）、または、ＨＤＤ(Hard Disc Drive)により実現される。なお、ＣＰＵ４０４はマルチプロセッサでも良い。
【００２５】
ここで、プラットフォームについて詳細に説明する。
プラットフォームの実現により、ユーザが独自に開発した新しいアプリケーションを画像形成装置１０７上で実行できる他、画像形成装置１０７の操作画面をカスタマイズすることが可能になる。
【００２６】
以下、プラットフォームの実現方法について説明する。
ＣＰＵ４０４は、間接記憶部４０６に記憶されたプラットフォームプログラムを直接記憶部４０５に移動する。移動が完了すると、ＣＰＵ４０４は、プラットフォームプログラム（例えば、Ｊａｖａ（登録商標））を実行することができる状態になる。本発明の実施形態では、ＣＰＵ４０４がプラットフォームプログラムを実行することを、プラットフォームが起動すると称する。
なお、プラットフォームは、画像形成装置１０７のファームウェア上で動作することになる。プラットフォームプログラムは、オブジェクト指向で記述されたアプリケーションプログラムを実行するための環境を提供するものである。
【００２７】
プラットフォーム上でアプリケーションプログラムを実行する方法について詳細に説明する。本実施形態において、プラットフォーム上には、スキャンした画像データをクラウドサービスに送信するスキャンソフトウェアが動作している。
スキャンソフトウェアは、ネットワークを介して接続されているスキャンサービスサーバ１０１より、例えば、ＨＴＴＰ（Hyper Text Transfer Protocol）と言った通信プロトコルによってスキャンチケットの一覧の受信を行う。
スキャンチケットにはスキャンの為の設定や、その後の処理フローといった情報が記録されている。以降、スキャンソフトウェアを実行することで実現するソフトウェア部をスキャンソフトウェア部と呼ぶ。
【００２８】
ユーザはスキャンソフトウェア部にて表示されたスキャンチケット一覧より、スキャンチケットを選択し、原稿を読み込ませることでスキャンを完了できる。スキャンソフトウェア部はユーザが選択したスキャンチケットの情報とスキャンした画像データを合わせてスキャンサービスサーバ１０１に送信する。
このように、プラットフォームでアプリケーションプログラムを実行することによって、画像形成装置１０７の制御を実現することができる。
【００２９】
次に、アプリケーションプログラムの実行方法について説明する。
起動したプラットフォームは、間接記憶部４０６に記憶されたアプリケーションプログラムを直接記憶部４０５に移動する。移動が完了すると、プラットフォームは、アプリケーションプログラムを実行することができる状態になる。そして、プラットフォームはアプリケーションプログラムを実行する。このように、アプリケーションプログラムを実行することで提供できるプラットフォームの機能を、本実施形態ではプラットフォームアプリケーションと呼ぶ。さらに、プラットフォームは、本発明の実施形態で開示するフローチャートの各処理の一部を行うことが可能である。
【００３０】
ユーザインタフェース４０７は、ユーザからの処理依頼を受け付けるために必要なユニットである。例えば、キーボード、ポインティングデバイス、タッチパネル等を通してユーザが入力した指示に応じた信号を受け付ける。外部インタフェース４０８は、外部装置からのデータ受信や外部装置へのデータ送信が可能となっている。
例えば、外部装置としては、外付けＨＤＤや外付けＵＳＢメモリ等の外付け記憶装置、またはネットワークを介して接続された別体のホストコンピュータや画像形成装置等の別体装置が含まれる。画像形成装置１０７は、ネットワーク１１０、１１１を介して、クライアント端末１０６、スキャンサービスサーバ１０１と通信可能である。
【００３１】
続いて、クラウドサービスを提供するスキャンサービスサーバ１０１、タスクサービスサーバ１０３、１０４の各サービスに関して説明する。さらには、各サービスの説明とともに、図１１に示すスキャン処理のシーケンス例を示す図を用いて、スキャン処理の流れを合わせて説明する。
図５を用いて、スキャンサービスサーバ（スキャンサービスＳ）１０１に関して説明する。スキャンサービスＳ１０１はクラウドサービスにおけるスキャン機能の提供を行うサービスである。
【００３２】
図５は、図１に示したスキャンサービスサーバ１０１のシステム構成を説明するブロック図である。スキャンサービスサーバ１０１は、Ｗｅｂアプリケーション部５０１、チケット管理ＤＢ部５０２、テンプレート管理ＤＢ部５０３からなる。これら構成要素により各種処理が実行されることでスキャンサービスサーバ１０１がユーザに提供される。なお、上記Ｗｅｂアプリケーション部５０１、チケット管理ＤＢ部５０２、テンプレート管理ＤＢ部５０３の実行主体は、スキャンサービスサーバ１０１のＣＰＵ２０２である。
【００３３】
Ｗｅｂアプリケーション部５０１は、スキャン機能を提供するアプリケーションプログラムを提供する。チケット作成部５１１は、ユーザがスキャンチケットを作成するための一連の機能を実現する。スキャンチケットには、画像形成装置１０７で原稿をスキャンする際の設定や、その後の処理フローの定義、各処理フローで実施されるタスクの為のパラメータが記録されている。
【００３４】
図１１において、チケット作成部５１１は、クライアント端末１０６のＷｅｂブラウザ３０１からのスキャンチケット作成画面リクエストを受け取り（Ｓ１１０１）、スキャンチケット作成画面を生成しレスポンスを行う（Ｓ１１０２）。この際、チケット作成部５１１は、テンプレート管理部５１６より、テンプレート管理ＤＢ部５０３に登録されているスキャンチケットのテンプレートを取得し、テンプレートに含まれるテンプレート名を、クライアント端末１０６のＷｅｂブラウザ３０１に表示する。テンプレート管理ＤＢ部５０３の詳細な内容は、図８に記載されており、前述したテンプレートについても、図８の説明に際に合わせて説明する。また、テンプレート名を表示する画面例は、図６に記載されており、表示画面例についても後述する。
【００３５】
ユーザがクライアント端末１０６のＷｅｂブラウザ３０１にて操作を行い、スキャンチケット作成リクエストを行うと（Ｓ１１０３）、スキャンチケット作成と、チケット管理部５１５への保存を依頼する。
チケット管理部５１５は、チケット保存のリクエストを受け、チケット管理ＤＢ部５０２にチケット情報を保存する。チケット管理ＤＢ部５０２の詳細な内容は図７に記載されている。チケット管理ＤＢ部５０２の詳細は後述する。チケット管理部５１５は、チケット情報を保存した後、レスポンスを行う（Ｓ１１０４）。
【００３６】
外部Ｉ／Ｆ５１４は画像形成装置１０７上で動作するスキャンソフトウェア部との通信を行う。スキャンソフトウェア部より、外部Ｉ／Ｆ５１４を通じて、チケット一覧部５１２の機能や、スキャン受信部５１３の機能へのアクセスを行う。
図１１にて、画像形成装置１０７のスキャンソフトウェア部は、外部Ｉ／Ｆ５１４を通じてチケット一覧部５１２に対して、チケット一覧取得を行う（Ｓ１１０５）。チケット一覧部５１２では、スキャンチケットの一覧をチケット管理部５１５より生成し、スキャンソフトウェア部にレスポンスを返す（Ｓ１１０６）。当該レスポンスを受け取った画像形成装置１０７は、取得したチケット一覧を、図４に示したユーザインタフェース４０７上に表示する。表示画面例は、図９に記載されており、表示画面例の説明は後述する。
【００３７】
図１１のＳ１１０７のスキャン処理により、ユーザは、ユーザインタフェース４０７上に表示されたチケットのいずれかを選択し、画像形成装置１０７に備え付けられたスキャン装置に紙を設置し、スキャンを実行する。
これにより、スキャンソフトウェア部は、スキャン送信にて、外部Ｉ／Ｆ５１４を通じてスキャン受信部５１３に対して、スキャンした画像データとスキャンチケットの送信を行う（Ｓ１１０８）。
【００３８】
スキャン受信部５１３は、送信されたスキャンチケット、および画像データを受信する。スキャン受信部５１３は、受信した画像データを、フローサービスサーバ１０２に投入する（Ｓ１１０９）。フローサービスサーバ１０２は、画像データを正しく受信できた場合には、スキャンサービスサーバ１０１に、画像データを一意に表すＩＤ（ファイルグループＩＤ）を応答する。その後、スキャン受信部５１３は、フローサービスサーバ１０２よりレスポンスを受けて（Ｓ１１１０）、ジョブ投入にて、ファイルグループＩＤ、およびスキャンチケットをフローサービスサーバ１０２に送信する（Ｓ１１１１）。以上がスキャンサービスサーバ１０１のシステム構成と、スキャンジョブの投入までの流れである。
【００３９】
図６は、図１に示したスキャンサービスサーバ１０１がディスプレイ２０６に表示するユーザインタフェース画面の例を示す図である。本例は、チケット作成画面６０１の一例である。
図６において、チケット作成画面６０１では、図５のテンプレート管理ＤＢ部５０３から取得したテンプレート（図中６０２−６０４）を表示する。ユーザは、表示されたテンプレートの中から、実行するテンプレートを選択する。ここで、テンプレートを選択すると、詳細なチケット設定を行う詳細設定画面６０５がクライアント端末に表示される。  本例では、同一画面に詳細設定画面６０５が表示されているが、別ウィンドウで詳細設定画面６０５を開くようにしても構わない。
詳細設定画面６０５中では、選択したテンプレートに応じたスキャンの設定を行うことが出来る。例えば、スキャン設定の例としては、図中に示す様にサイズや、カラー、白黒といった色調、またスキャンデータのフォーマット等の設定がある。
【００４０】
ユーザは、詳細な設定を行った後、チケット発行ボタン６０６を押下すると、図５のチケット管理ＤＢ部５０２に、チケットの情報が新規作成される。チケット管理ＤＢ部５０２に保存されるチケット情報は、後述する。
チケット情報が、チケット管理ＤＢ部５０２に正しく作成された場合には、チケット番号６０７に、チケットに固有に割り当てられたＩＤが表示される。このＩＤは、図７におけるチケットＩＤ７０２と同じ値となる。ユーザは、チケット番号６０７に表示されたＩＤを記憶し、画像形成装置１０７に移動する。
【００４１】
図７は、図５に示したチケット管理ＤＢ部５０２で管理されている情報の一例を示す図である。
図７において、ユーザＩＤ７０１は、該チケットを作成したユーザを一意に表すＩＤである。チケットＩＤ７０２は、チケットを一意に定義するＩＤである。このチケットＩＤは、図６のチケット発行ボタン６０６を押下した際にチケット作成部５１１にて生成され、チケット管理ＤＢ部５０２に保存される。ルートＩＤ７０３は、チケット作成画面６０１にて、ユーザが選択したテンプレートに対応するルートＩＤである。ユーザがチケットを選択し、スキャンを実行した場合には、そのスキャンデータは、ルートＩＤ７０３に定義されたタスクの順番で処理される。パラメータ７０４は、詳細設定画面６０５にて設定したスキャンの設定が記録されている。
【００４２】
図８は、図５に示したテンプレート管理ＤＢ部５０３で管理されているテンプレートの一例を示す図である。テンプレート管理ＤＢ部５０３は、後述する図１３のルート情報管理ＤＢ部１３０１にて管理されるルート情報と、チケット作成画面上に表示されるテンプレートを紐づけるためのデータベースである。ここで、テンプレートは、テンプレートＩＤ８０１、テンプレート名８０２、およびルートＩＤ８０３から構成される。テンプレートＩＤ８０１は、各テンプレートを一意に表すＩＤである。テンプレート名８０２は、図６のチケット作成画面６０１に表示される名前である。ルートＩＤ８０３は、後述する図１４におけるルート情報管理ＤＢ部１３０１にて管理されるルートＩＤ１４０１への外部キーを表す。
【００４３】
図９は、図４に示した画像処理ユニット４０１のユーザインタフェース４０７で表示するユーザインタフェース画面の一例を示す図である。
本画面は、図１１のＳ１１０５にてチケット一覧を取得し、取得したチケット情報が表示される画面例である。画面上には、チケット管理ＤＢ部５０２から取得したチケットＩＤ７０２が表示されている（ＩＤ９０１〜９０６）。なお、画像処理装置を操作しているユーザに対応するチケットのみが表示されても良い。
ユーザは、ユーザインタフェース４０７を用いて、実行するチケットに対応するアイコンを選択し、画像形成装置１０７にスキャン対象の原稿を設置し、スキャンボタン９０７を押下する。
これにより、図１１におけるスキャン送信が実行される（Ｓ１１０８）。スキャン送信が実行されると（Ｓ１１０８）、スキャンサービスサーバ１０１のスキャン受信部５１３に対して、スキャンしたデータと、チケットが送信される。
【００４４】
引き続き、図１０にて、本発明の実施形態に係るタスクサービスサーバ１０３、１０４のシステム構成を説明する。
図１０は、図１に示したタスクサービスサーバ１０３、１０４のシステム構成を示すブロック図である。
各タスクサービスサーバは、スキャンサービスを実現するための要素機能を実現するサービスである。例えば画像データ対して画像処理を行うタスクサービスや、ファイル共有機能を提供するような他のクラウドサービスサーバ１０８に対して、画像データを送信する処理を行うタスクサービスが存在する。
本実施形態においては、タスクサービスサーバ１０３は、画像データに対してＯＣＲ処理を行いＯＣＲ結果のテキストデータを画像データに埋め込む処理を行う。また、タスクサービスサーバ１０４は、クラウドサービスサーバ１０８の中のストレージ機能を提供する特定のサービスに対して、画像データをアップロードし保管する処理を行う。
以下、図１１のスキャン処理のシーケンス図の流れとともに各構成要素の説明を行う。
【００４５】
タスクサービスサーバ１０３、１０４のタスク取得部１０１１は、Ｓ１１１２、Ｓ１１１３、Ｓ１１１９、Ｓ１１２０にて、定期的にフローサービスサーバ１０２に問い合わせを行い、各タスクサービスサーバ１０３、１０４にて処理可能なタスクを取得する。タスクサービスサーバ１０３、１０４のデータ取得部１０１２は、タスク取得部１０１１で取得した情報を元に、Ｓ１１１４、Ｓ１１１５、Ｓ１１２１、Ｓ１１２２にてフローサービスサーバ１０２から処理すべき画像データの取得を行う。
タスクサービスサーバ１０３、１０４のタスク処理部１０１５は、Ｓ１１１６、Ｓ１１２３にて取得した画像データに対して各種処理を行う。タスクサービスサーバ１０３のタスク処理部１０１５は、Ｓ１１１６での処理結果をデータ保存部１０１３を通して、フローサービスサーバ１０２に保存する（Ｓ１１１７）。
タスクサービスサーバ１０４のタスク処理部１０１５は、Ｓ１１２３での処理結果をクラウドサービスサーバ１０８にデータ送信する（Ｓ１１２４）。タスクサービスサーバ１０３、１０４のタスクステータス通知部１０１４は一連のタスク処理の終了結果をフローサービスサーバ１０２に通知する（Ｓ１１１８、Ｓ１１２５）。以上で、スキャンジョブの一連の処理が完了する。
【００４６】
続いて、フローサービスサーバ１０２の詳細な説明を行う。フローサービスサーバ１０２は本実施形態における中心的なサービスサーバであり、ルート管理、ジョブ管理、一時ファイル管理を行うサービスサーバである。
【００４７】
図１２は、図１に示したフローサービスサーバ１０２のシステム構成を説明するブロック図である。
図１２において、フローサービスサーバ１０２は、ルート管理サービス１２０１、ジョブ管理サービス１２０２、一時ファイル管理サービス１２０３の各サーバからなる。これらサーバ上により各種処理が実行されることで各サービスが提供され、それらが連携することで、フローサービスサーバ１０２によりサービスがユーザに提供される。
【００４８】
ルート管理サービス１２０１は、タスクとタスクを連結させたルートの情報を管理する。ジョブ管理サービス１２０２は、ルートの情報に基づきジョブの処理を管理する。一時ファイル管理サービス１２０３は、ジョブ投入時のデータや各タスクの処理結果データの保存を管理する。
引き続きフローサービスサーバ１０２を構成するルート管理サービス１２０１、ジョブ管理サービス１２０２、一時ファイル管理サービス１２０３の詳細な説明を行う。
図１３は、図１２に示したフローサービスサーバ１０２のルート管理サービスサーバの構成を説明するブロック図である。本例のルート管理サービス１２０１は、ルート情報管理ＤＢ部１３０１、タスク情報管理ＤＢ部１３０２、外部Ｉ／Ｆ１３０３からなる。
【００４９】
図１３において、ルート情報管理ＤＢ部１３０１は、タスクの連結をルートという単位で定義するための情報を保持している。タスク情報管理ＤＢ部１３０２は、各処理をタスクという単位で定義し、タスクに関する情報を保持している。外部Ｉ／Ｆ１３０３は、ルート管理サービス１２０１への問い合わせのためのＩ／Ｆであり、ジョブ管理サービス１２０２等からルート情報管理ＤＢ部１３０１やタスク情報管理ＤＢ部１３０２を参照するためのＩ／Ｆである。
【００５０】
図１４は、図１３に示したルート情報管理ＤＢ部１３０１で管理されている情報の一例を示す図である。
図１４において、ルートＩＤ１４０１がルートを一意に識別するＩＤである。シーケンス番号１４０２はそのルートの何番目に実行するタスクであるかを保持する。タスクＩＤ１４０３はどのタスクを実行するかを保持する。
例えば、データ１４１３−１４１５で、ルートＩＤ１４０１が００２のルートを定義している。１４１３が１番目に実行するタスクであり、タスクＩＤ１４０３がＴａｓｋ１のタスクをタスクサービスが実行する。同様に、１４１４が２番目に実行するタスクであり、タスクＩＤ１４０３がＴａｓｋ３のタスクを、１４１５は３番目に実行するタスクであり、タスクＩＤ１４０３がＴａｓｋ５のタスクをタスクサービスが実行する。
【００５１】
図１５は、図１３に示したタスク情報管理ＤＢ部１３０２で管理されている情報の一例を示す図である。
図１５において、タスクＩＤ１５０１がタスクを一意に識別するＩＤである。タスク名１５０２は、そのタスクの名前である。続いて、多重度１５０３と削除１５０４にてそのタスクの重要度の設定を保持する。多重度１５０３は、そのタスクの処理結果を保存する際、どの程度の多重度でデータを保存しておくのかを示す設定である。多重度１５０３が「０」の場合は、処理結果を保存しないタスクであり、その他の場合は多重度の数に相当する箇所で処理結果のデータが記憶される。例えば、Ｔａｓｋ３の多重度は「２」であるため、Ｔａｓｋ３の処理結果は２か所で記憶される。つまり、多重度が大きいほど重要なタスクとなる。
【００５２】
タスクサービスサーバ１０３、１０４のデータ保存部１０１３はデータ保存Ｓ１１１５を実行する際に、本設定を元にフローサービスサーバ１０２にデータ保存依頼を行う。削除１５０４は、そのデータをジョブ終了時まで保持するべきか否かを示すフラグである。
ここで、削除１５０４が「１」の場合にはジョブ処理の途中で削除してもよく、「０」の場合はジョブが終了するまで削除してはいけない。また、値がないものはそもそもデータを保存していないタスクである。削減１５０４は、「０」のものが重要なタスクとなる。
【００５３】
図１６は、図１２に示したジョブ管理サービス１２０２の構成を説明するブロック図である。本例では、ジョブ管理サービス１２０２が、タスクサービスサーバ１０３、１０４からのリクエストに対してタスク情報の授受や、各タスクの状態を管理するためのサービスサーバとして機能する。
【００５４】
外部Ｉ／Ｆ１６０１は、タスクサービスサーバ１０３、１０４、および画像形成装置１０７との通信を行う。外部Ｉ／Ｆ１６０１を通じて、ジョブ管理サービス１２０２の各機能へのアクセスを行う。ジョブ情報管理ＤＢ部１６０２は、作成された各ジョブのステータスや、各ジョブが扱うデータのＩＤを管理する。ジョブ情報管理ＤＢ部１６０２の詳細な内容は、図１７に記載されており、ジョブ情報管理ＤＢ部１６０２の内容に関する説明は後述する。ジョブ追加部１６０３は、スキャンサービスサーバ１０１が、図１１において、外部Ｉ／Ｆ１６０１を通じて発行されるジョブ投入リクエストを受け（Ｓ１１０９）、ジョブ情報管理ＤＢ部１６０２に、ジョブ情報を格納する。
ここで、ジョブ情報とは、図１７に示されるジョブ情報管理ＤＢ部１６０２に存在する各カラムに対応する１７０１〜１７０７に示す情報から構成される。
ジョブ情報取得部１６０４は、タスクサービスサーバ１０３、１０４から外部Ｉ／Ｆ１６０１を通じて発行されるタスク取得リクエストを受け（Ｓ１１１０）、ジョブ情報管理ＤＢ部１６０２から、ジョブ情報を取得する。ここで取得したジョブ情報は、Ｓ１１１１のタスク取得にてタスクサービスサーバ１０３、１０４に渡される。ジョブ情報更新部１６０５は、Ｓ１１１６の結果通知にて、タスクサービスサーバ１０３、１０４から、外部Ｉ／Ｆ１６０１を通じて発行されるジョブ情報更新リクエストを受け、ジョブ情報管理ＤＢ部１６０２の該ジョブの情報を更新する。
【００５５】
ここで、更新される情報として、図１７に示すカレントタスクＩＤ１７０４、およびステータス１７０５、最終更新時刻１７０６がある。カレントタスクＩＤ１７０４を更新する前には、ルート管理サービス１２０１の外部Ｉ／Ｆ１３０３を通じて、ルート情報管理ＤＢ部１３０１から、該ルートＩＤにおける次のタスクＩＤを取得する。取得したタスクＩＤを以て、カレントタスクＩＤ１７０４を更新する。また、ステータス１７０５は「０」、最終更新時刻１７０６は現在時刻で更新する。
【００５６】
続いて、図１７を用いて、ジョブ情報管理ＤＢ部１６０２に保持されるデータについて説明する。
ジョブＩＤ１７０１は、各ジョブ情報に一意に割り当てられるＩＤである。ルートＩＤ１７０２には、図６のチケット作成画面６０１にて選択したテンプレートに対応するルートＩＤが格納される。ファイルグループＩＤ１７０３は、一時ファイル管理サービス１２０３から発行されるＩＤである。カレントタスクＩＤ１７０４は、そのジョブにおいて処理を行うべきタスクを示すタスクＩＤである。
【００５７】
タスクサービスサーバ１０３、１０４は、このカレントタスクＩＤ１７０４を確認し、自タスクサービスに割り当てられたタスクＩＤと等しい行を選択し処理を行う。本ＩＤは、該タスクの処理が完了した際には、ジョブ情報更新部１６０５が、該ルートＩＤの次のタスクのタスクＩＤに更新する。ステータス１７０５には、処理待ち（０）、実行中（１）、エラー発生（２）を表す値が設定される。
【００５８】
タスクサービスサーバ１０３、１０４がジョブを選択する際には、ステータスが０となっている行を選択する。これにより、複数のタスクサービスが同一のタスクを処理するといった事態を防ぐことができる。タスクサービスサーバ１０３、１０４が、ジョブを選択した後に、タスクサービスサーバ１０３、１０４は、外部Ｉ／Ｆ１６０１を通じて、ジョブ情報更新部１６０５よりステータス１７０５が１に変更される。最終更新時刻１７０６は、タスクサービスサーバ１０３，１０４が該ジョブに対して、何らかの処理を実行した際に、更新される。ここで、何らかの処理とは、ステータスの更新処理や、ジョブの取得処理である。
【００５９】
タスクサービスサーバ１０３、１０４がジョブを取得する際に、自タスクＩＤと等しいジョブ情報が複数存在していた場合には、最終更新時刻１７０６が最も古いジョブを選択する。これにより、全てのジョブを平均的に処理することが可能となる。パラメータ１７０７には、詳細設定画面６０５にて設定した設定情報や、タスクサービスサーバ１０３、１０４が、他のタスクサービスサーバ１０３、１０４に渡す設定情報などを記載する。
【００６０】
一時ファイル管理サービス１２０３は、スキャンサービスサーバ１０１やタスクサービスサーバ１０３、１０４からの要求に応じて、ファイルを格納し、その格納先のパスを管理するサービスである。タスクサービスサーバ１０３、１０４からファイル取得要求があった際には保存したファイルのバイナリデータをタスクサービスサーバ１０３、１０４に返却する。また、タスクサービスサーバ１０３、１０４やジョブ管理サービス１２０２からファイル削除の要求があった際には、保存したファイルを削除する。スキャンサービスサーバ１０１やタスクサービスサーバ１０３、１０４は一時ファイル管理サービス１２０３によって、ファイルの格納先のパスやファイルサーバの状態を気にすることなく、ファイルの保存、取得、削除を行うことができる。
【００６１】
続いて、図１８−図２１を用いて、一時ファイル管理サービス１２０３について説明する。
図１８は、本実施形態を示すサーバ管理装置の構成を説明するブロック図である。本例は、中央管理サーバ１８０１が複数のファイルサーバを管理する例である。
図１９において、中央管理サーバ１８０１は、Ｗｅｂアプリケーション部１９０１、バックエンド部１９０２、ファイルサーバ管理ＤＢ部１９３１、パス管理ＤＢ部１９３２からからなる。これら構成要素により各種処理が実行されることでサービスを行う。
【００６２】
Ｗｅｂアプリケーション部１９０１が、一時ファイル管理機能を提供するＷｅｂアプリケーションプログラムである。各機能については後述する。バックエンド部１９０２は、ファイルサーバ１８０２〜１８０４へのファイル保存、取得、削除などの機能を実現する。ファイルサーバ管理ＤＢ部１９３１、パス管理ＤＢ部１９３２は、一時ファイル管理機能を実現するためのデータを管理する。１９４１はファイルサーバ追加部で、新規ファイルサーバを追加する際のファイルサーバ追加処理を制御する。１９４２はファイルサーバ停止部で、ファイルサーバを停止する際のファイルサーバ停止処理を制御する。
ファイルサーバ管理ＤＢ部１９３１は、ファイルの格納先であるファイルサーバ１８０２〜１８０４に関する情報を管理する。
図１９は、図１８に示した中央管理サーバ１８０１の全体構成を示すブロック図である。本例は実データを格納する１以上の多重度が指定された複数のファイルサーバからファイルシステムを構築し、各ファイルサーバから取得する実データに関する情報と、各ファイルサーバに格納される実データの格納先をデータベースに登録して管理する例である。
図１９において、中央管理サーバ１８０１、ファイルサーバＡ１８０２−ファイルサーバＣ１８０４はネットワーク１８１０を介して接続されている。また、ネットワーク１８１０はネットワーク１１０と接続されている。
ネットワーク１８１０はネットワーク１１０と同様のデータの送受信が可能な通信ネットワークである。中央管理サーバ１８０１は一般的にサーバコンピュータ上にて実行される。ファイルサーバ１８０２〜１８０４は一般にサーバコンピュータ上にて実行されており、必要に応じて電子データを保存、削除、取得する機能を有している。
続いて、一時ファイル管理機能を提供する中央管理サーバ１８０１について図１９−図２１を用いて説明する。
【００６３】
図２０は、図１９に示したファイルサーバ管理ＤＢ部１９３１で管理するデータの例を示す図である。
図２０において、ＩＤ２００１は、ファイルサーバを図１に示したフローサービスサーバ１０２の一時ファイル管理サービス１２０３内で一意に識別するための情報である。
【００６４】
ホスト名２００２は、ネットワーク１８１０上におけるファイルサーバの一意のアドレスを示し、Ｗｅｂアプリケーション部１９０１がバックエンド部１９０２を通じてファイルサーバ１８０２〜１８０４にアクセスする際に使用する。
アクティブフラグ２００３は、Ｗｅｂアプリケーション部１９０１がバックエンド部１９０２を通じてホスト名２００２に存在するファイルサーバとの通信の可否を示す真偽値であり、通信可能な場合はＴｒｕｅ、通信不可能な場合はＦａｌｓｅを取る。ここで、通信可能時にＴｒｕｅとするのは、新規ファイルサーバの追加に合わせてダミーデータ格納先を登録した後、追加されたファイルサーバの状態をデータ書き込み無効からデータ書き込み有効に設定するためである。
したがって、通信可能時にＦａｌｓｅとするのは、ファイルサーバの停止に合わせてダミーデータ格納先を登録した後、停止させるべきファイルサーバの状態をデータ書き込み有効からデータ書き込み無効に設定するためである。
共有フォルダ名２００４は、ファイルサーバ１８０２〜１８０４上に作成した共有フォルダ名である。ホスト名２００２と共有フォルダ名２００４から、ファイルサーバ１８０２〜１８０４上に作成した共有フォルダのフルパスが得られる。
【００６５】
パス管理ＤＢ部１９３２は、一時ファイル管理サービス１２０３で管理している、ファイルサーバ１８０２〜１８０４に保存された一時ファイルとフォルダに関する情報を管理する。本実施形態では、一時ファイル管理サービス１２０３で管理するファイルとフォルダをあわせてエンティティと呼ぶ。図２０に示したパス管理ＤＢ部１９３２で管理するデータの例を示す。
パス管理ＤＢ部１９３２において、ファイルＩＤ２０１０は、ファイルサーバ１８０２〜１８０４でエンティティを一意に識別するための情報である。
【００６６】
ファイルグループＩＤ２０１１は、各エンティティを関連するジョブでグループ化するための情報である。従って、同一ジョブによって生成されたエンティティは同一のファイルグループＩＤ２０１１を持つ。タスクＩＤ２０１２は、各エンティティに関連するタスクのタスクＩＤ、またはフォルダを表す「Ｆｏｌｄｅｒ」、またはスキャンサービスサーバ１０１からの要求により格納されたファイルを表す「ｉｎｉｔ」のいずれかの値が入る。
本実施形態では、スキャンサービスサーバ１０１からの要求により格納されたファイルを初期データと呼ぶ。Ｎｏ２０１３は各タスクによって生成されたファイルのファイル番号を示す。パス２０１４は、エンティティの格納先のフルパスを示し、Ｗｅｂアプリケーション部１９０１がバックエンド部１９０２を通じてエンティティにアクセスする際に使用する。ホスト名２０１５は、各エンティティの格納先のファイルサーバのホスト名を示す。作成日２０１６及び有効期限２０１７は各エンティティの作成日及び有効期限を示す。
ファイルサーバ１８０２〜１８０４は、一時ファイル管理サービス１２０３で管理するファイルを格納する。
図２１は、図１８に示したファイルサーバＡ１８０２、ファイルサーバＢ１８０３、ファイルサーバＣ１８０４のフォルダの階層構造を示す図である。
【００６７】
図２１において、２１０１は共有フォルダであり、Ｗｅｂアプリケーション部１９０１がバックエンド部１９０２を通じてアクセス可能とする。
共有フォルダ２１０１は各サーバに少なくとも１つ存在し、ファイルサーバ管理ＤＢ部１９３１の共有フォルダ名２００４と一致する。本発明では共有フォルダ２１０１の深さを０とする。共有フォルダ２１０１の直下にある、深さ１のフォルダ群２１３１の各フォルダ２１１１、２１２１のフォルダ名はファイルグループＩＤ２０１１に対応する。
【００６８】
また、２１１１および２１２１の直下にある深さ２のフォルダ群２１３２の各フォルダ２１１２、２１１３、２１２２、２１２４、２１２７のフォルダ名はタスクＩＤ２０１２に対応する。一時ファイル管理で管理される一時ファイルは、深さ２のフォルダ群２１３２の直下に保存される。このときのファイル名はＮｏ２０１３に対応する。続いて、Ｗｅｂアプリケーション部１９０１が持つ各機能について説明する。
【００６９】
ファイル保存部１９１１は、スキャンサービスサーバ１０１やタスクサービスサーバ１０３、１０４からのリクエストに応じて、ファイルサーバ１８０２〜１８０４にファイルを多重化して保存する機能を実現する。多重度は呼び出し元であるスキャンサービスサーバ１０１やタスクサービスサーバ１０３、１０４から１以上の整数を指定でき、多重度１の場合は多重化せずに保存する場合と同義である。また多重度の最大値は、ファイルサーバ１８０２〜１８０４に存在する共有フォルダ数であり、それ以上は無視される。
【００７０】
ファイル保存部１９１１は、スキャンサービスサーバ１０１からの初期データ保存のリクエストを受信すると、まず現在稼働中のファイルサーバの中から保存先のファイルサーバを選択する。この際、ファイル保存部１９１１は、深さ「１」のフォルダ群２１３１のフォルダ数が少ないファイルサーバから順に指定された多重度分だけ選択する。これは、各ファイルサーバ１８０２〜１８０４の容量を均一化するためである。
スキャンサービスサーバ１０１からの初期データ保存のリクエストには、多重度、タスクＩＤ、Ｎｏが含まれる。ファイル保存部１９１１はファイルグループＩＤを生成し、ファイルグループＩＤ、タスクＩＤ、Ｎｏに基づいて保存先のファイルパスを生成し、後述のファイル保存処理を実行する。
【００７１】
ファイル保存部１９１１がタスクサービスサーバ１０３、１０４からファイル保存のリクエストを受信した場合は、そのリクエストには、多重度、ファイルグループＩＤ、タスクＩＤ、Ｎｏが含まれる。ファイル保存部１９１１は、受信したリクエストに含まれるファイルグループＩＤと同一のファイルグループＩＤを持つ初期データが保存されているファイルサーバをパス管理ＤＢ部１９３２から取得する。
ファイル保存部１９１１は、ファイル保存先のファイルサーバを、取得したファイルサーバの中から多重度分だけランダムに選択する。ファイル保存部１９１１は、選択した各ファイルサーバに対して、ファイルグループＩＤ、タスクＩＤ、Ｎｏに基づいて保存先のファイルパスを決定し、ファイル保存処理を実行する。
【００７２】
ファイル保存処理では、ファイル保存部１９１１がバックエンド部１９０２に対して保存先ファイルパスとファイルのバイナリデータを送信する。バックエンド部１９０２は保存先のファイルサーバとの通信の可否を確認し、通信可能であった場合はファイルを保存先ファイルパスに保存する。多重保存する場合は上記の処理を多重度分繰り返す。バックエンド部１９０２は、全てのファイルの保存が完了したらファイル保存部１９１１に結果を返す。ファイル保存部１９１１はパス管理ＤＢ部１９３２に保存先ファイルパスに関するエントリを多重度分追加する。
ファイル保存処理の完了後、初期データを保存した場合のみ、呼び出し元のスキャンサービスサーバ１０１に対してファイルグループＩＤを返却する。
【００７３】
ファイル取得部１９１２は、タスクサービスサーバ１０３、１０４からの要求に応じてファイルサーバ１８０２〜１８０４に保存されたファイルをタスクサービスサーバ１０３、１０４に返す。ファイル取得部１９１２はタスクサービスサーバ１０３、１０４からのリクエストを受信すると、リクエストに含まれるファイルグループＩＤやタスクＩＤ、Ｎｏに基づいてパス管理ＤＢ部１９３２に問い合わせ、格納先のファイルパスを取得する。
ファイル取得部１９１２はバックエンド部１９０２に対して格納先のファイパスを送信する。バックエンド部１９０２は格納先のファイルサーバとの通信の可否を確認し、通信可能であった場合はファイルのバイナリデータをファイル取得部１９１２に返す。ファイル取得部１９１２はバックエンド部１９０２から返却されたバイナリデータをタスクサービスサーバ１０３、１０４に返す。
【００７４】
ファイル削除部１９１３はタスクサービスサーバ１０３、１０４やジョブ管理サービス１２０２からの要求に応じてファイルサーバ１８０２〜１８０４に格納されたエンティティを削除する。ファイル削除部１９１３はタスクサービスサーバ１０３、１０４やジョブ管理サービス１２０２からのリクエストを受信すると、リクエストに含まれるファイルグループＩＤやタスクＩＤ、Ｎｏに基づいてパス管理ＤＢ部１９３２に問い合わせる。
【００７５】
ファイル削除部１９１３は、取得した格納先のエンティティパスをバックエンド部１９０２に対して格納先のエンティティパスを送信する。バックエンド部１９０２は格納先のファイルサーバとの通信の可否を確認し、通信可能であった場合はエンティティを削除する。バックエンド部１９０２は削除が完了したら、ファイル削除部１９１３に結果を返す。エンティティの削除に成功したら、ファイル削除部１９１３はパス管理ＤＢ部１９３２から削除したエンティティに関するエントリを削除する。
続いて、バッチアプリケーション１９０４が持つ各機能について説明する。
【００７６】
ファイルサーバ追加部１９４１は、新規ファイルサーバを新規追加する際に起動するバッチアプリケーションである。ファイルサーバ追加部１９４１を利用して一時ファイル管理サービス１２０３にファイルサーバを新規に追加する手順を、図２２、図２３を用いて説明する。
【００７７】
〔ファイルサーバの追加処理〕
図２２は、本実施形態を示すサーバ装置の制御方法を説明するフローチャートである。本例は、図１２に示した一時ファイル管理サービス１２０３にファイルサーバを追加する流れに対応する。なお、本願のフローチャートの各ステップは、中央管理サーバ１８０１のＣＰＵ２０２が制御プログラムをＲＡＭ２０３にロードして実行することで実現されるが、以下の説明では制御プログラムまたはモジュールを制御主体として説明する。
本実施形態では、中央管理サーバ１８０１のパス管理ＤＢ部１９３２にエントリが存在するがファイルサーバＡ１８０２、ファイルサーバＢ１８０３、ファイルサーバＣ１８０４に対応するエンティティが存在しないデータをダミーデータと呼ぶ。一方、パス管理ＤＢ部１９３２のエントリに対応するエンティティがファイルサーバＡ１８０２、ファイルサーバＢ１８０３、ファイルサーバＣ１８０４に存在するデータを実データと呼ぶ。
【００７８】
一時ファイル管理サービス１２０３の運用管理者は、新規追加したいファイルサーバＹを起動し、ネットワーク１８１０に接続し、中央管理サーバ１８０１から通信可能な状態に設定する。一時ファイル管理サービス１２０３の運用管理者は、中央管理サーバ１８０１のファイルサーバ追加部１９４１を起動する。
まず、Ｓ２３０１で、中央管理サーバ１８０１のモジュールの１つであるファイルサーバ追加部１９４１は、新規追加ファイルサーバＹ（図２３参照）と通信可能であることを確認する。
【００７９】
Ｓ２３０２で、新規追加するファイルサーバＹからの応答がないとファイルサーバ追加部１９４１が判断した場合は、本処理を終了する。
Ｓ２３０２で、新規追加ファイルサーバＹからの応答があったとファイルサーバ追加部１９４１が判断した場合、Ｓ２３０３へ進む。そして、Ｓ２３０３で、ファイルサーバ追加部１９４１は、新規追加ファイルサーバＹに関する情報をファイルサーバ管理ＤＢ部１９３１に追加登録指示する。この指示により、新規追加ファイルサーバＹに関する情報が中央管理サーバ１８０１のファイルサーバ管理ＤＢ部１９３１に追加登録される（Ｓ２３０４）。
なお、Ｓ２３０３で、ファイルサーバ追加部１９４１は、新規追加ファイルサーバＹに対するアクティブフラグを「Ｆａｌｓｅ」として追加登録指示することで、新規追加ファイルサーバＹへの書き込みをこの時点では許可しないように制御する。
続いて、Ｓ２３０５で、ファイルサーバ追加部１９４１は、新規追加ファイルサーバ以外で現在稼働中の各ファイルサーバの深さ１のフォルダ群２１３１のフォルダ数をパス管理ＤＢ部１９３２から取得する（Ｓ２３０６）。そして、ファイルサーバ追加部１９４１は、各ファイルサーバのジョブフォルダ数を計数する。
次に、Ｓ２３０７で、ファイルサーバ追加部１９４１は、パス管理ＤＢ部１９３２にダミーデータ２２１３〜２２１５の登録を指示して、パス管理ＤＢ部１９３２にダミーデータ２２１３〜２２１５を登録する（Ｓ２３０８）。
【００８０】
図２３は、図１８に示した中央管理サーバ１８０１が管理するパス情報の一例を示す図である。なお、本実施形態では、各ダミーデータ２２１３〜２２１５の格納先には、所定の時差（本実施形態では、例えば５分間隔）をもつ有効期限２０１７をそれぞれ対応づけて前記データベースに登録する例を示す。
図２３において、ダミーデータ２２１３〜２２１５の登録数は、Ｓ２３０５で、ファイルサーバ管理ＤＢ部１９３１より取得したフォルダ数の最小値と同数とする。ダミーデータ２２１３〜２２１５は、それぞれ一意のファイルグループＩＤ２０１１を持ち、タスクＩＤ２０１２は「Ｆｏｌｄｅｒ」、パス２０１４は「Ｄｕｍｍｙ」、ホスト名２０１５は新規追加ファイルサーバのホスト名２２１６を指定する。
タスクＩＤ２０１２を「Ｆｏｌｄｅｒ」とし、ファイルグループＩＤを一意の値とすることで、Ｗｅｂアプリケーション部１９０１からは、あたかも新規追加ファイルサーバに深さ１のフォルダ群２１３１が複数存在するように見える。また、ダミーデータの有効期限はダミーデータの作成日２２１７から、例えば５分おきにそれぞれ異なる値を指定する。  次に、ファイルサーバ追加部１９４１は、ファイルサーバ管理ＤＢ部１９３１上の新規追加ファイルサーバＹの情報について、アクティブフラグを「Ｔｒｕｅ」に更新登録する。これにより、新規追加ファイルサーバＹへのファイルの書き込みが可能となる。
【００８１】
次に、Ｓ２３０９で、ファイルサーバ追加部１９４１は、パス管理ＤＢ部１９３２に対して、Ｓ２３０９で登録したダミーデータ２２１３〜２２１５の有無を判定する。ここで、ダミーデータ２２１３〜２２１５が存在しないとファイルサーバ追加部１９４１が判断した場合は、本処理を終了する。
ここで、ダミーデータ２２１３〜２２１５が存在するとファイルサーバ追加部１９４１が判断した場合は、Ｓ２３１０で、ファイルサーバ追加部１９４１は、一定時間待機する。そして、Ｓ２３１１で、ファイルサーバ追加部１９４１は実データ、ダミーデータ２２１３〜２２１５の検索をパス管理ＤＢ部１９３２に指示する。これを受けて、Ｓ２３１２で、パス管理ＤＢ部１９３２が実データ、ダミーデータ２２１３〜２２１５の検索を開始する。
【００８２】
そして、Ｓ２３１３で、パス管理ＤＢ部１９３２が後述の削除対象のダミーデータが存在するかどうかを判定し、削除対象のダミーデータが存在しないとパス管理ＤＢ部１９３２が判断した場合はＳ２３０９に戻る。Ｓ２３１３で削除対象のダミーデータが存在するとパス管理ＤＢ部１９３２が判断した場合は、Ｓ２３１４で、パス管理ＤＢ部１９３２が削除対象のダミーデータを削除して、Ｓ２３０９に戻る。このように、本実施形態では、追加されたファイルサーバの状態がデータ書き込み有効に設定された後、ダミーデータに対応づけられた有効期限に従い無効とすべきダミーデータを順次削減する。これにより、所定時間が経過すると、ダミーデータは全て削除され、実データのみが格納される。
一方、Ｓ２３１３で、ダミーデータが存在しないとパス管理ＤＢ部１９３２が判断した場合は、Ｓ２３０９に戻る。
なお、Ｓ２３１４において、削除対象のダミーデータは以下の（ｉ）、（ｉｉ）である。
【００８３】
（ｉ）新規追加ファイルサーバの実データ数＋ダミーデータ数が現在稼働中の他のファイルサーバの実データ数の少なくとも１つより大きい場合は、実データ＋ダミーデータ数が最小になるようにダミーデータを削除する。ただし、有効期限が長いものから順に削除する。
（ｉｉ）有効期限切れのダミーデータ。有効期限切れのダミーデータとは、有効期限２０１７が中央管理サーバのＯＳの現在時刻より前のデータである。
【００８４】
パス管理ＤＢ部は、（ｉ）、（ｉｉ）の少なくとも一方を満たすダミーデータを削除対象と認定し、Ｓ２３１４で削除する。以上が、一時ファイル管理サービス１２０３にファイルサーバを新規追加する手順である。
【００８５】
以上のようにファイルサーバの新規追加時にパス管理ＤＢ部１９３２にダミーデータ２２１３〜２２１５を追加することで、中央管理サーバ１８０１からは新規追加ファイルサーバにあたかも実データが存在するように見える。このため、ファイル保存部１９１１が初期データを保存する際に、新規追加ファイルサーバへの書き込みの一極集中を防ぐことができ、ディスクＩ／Ｏアクセスの増大を防ぐことができる。また、ダミーデータ２２１３〜２２１５を徐々に削除することで新規追加ファイルサーバへ徐々に実データが書き込まれ、最終的にはダミーデータが「０」となる。
【００８６】
〔ファイルサーバの停止処理〕
図２４は、本実施形態を示すサーバ装置の制御方法を説明するフローチャートである。本例は、ファイルサーバ停止部１９４２を利用してファイルサーバを停止する手順例である。
なお、図１９において、ファイルサーバ停止部１９４２は、ファイルサーバを停止する際にＣＰＵ２０２が起動するバッチアプリケーションである。
【００８７】
一時ファイル管理サービス１２０３の運用管理者は、中央管理サーバ１８０１のファイルサーバ停止部１９４２を起動させる。ファイルサーバ停止部１９４２は、Ｓ２５０１で、ファイルサーバ停止部１９４２は、パス管理ＤＢ部１９３２に各ファイルサーバ１８０２〜１８０４の深さ「１」のフォルダ群２１３１のフォルダ数の取得を要求する。次に、Ｓ２５０２で、パス管理ＤＢ部１９３２が管理する各ファイルサーバ１８０２〜１８０４の深さ「１」のフォルダ群２１３１のフォルダ数をファイルサーバ停止部１９４２に提供する。
次に、Ｓ２５０３で、ファイルサーバ停止部１９４２は、パス管理ＤＢ部１９３２に停止されるサーバ装置のホスト名を指定してダミーデータ２４１３〜２４１５の登録を指示する。そして、Ｓ２５０４で、パス管理ＤＢ部１９３２は、ダミーデータ２４１３〜２４１５を登録する。
【００８８】
図２５は、図１８に示した中央管理サーバ１８０１が管理するパス情報の一例を示す図である。本例は、中央管理サーバ１８０１のパス管理ＤＢ部１９３２が保持するファイルサーバ終了バッチ起動のファイルパス情報の一例を示す例である。
図２５において、２４１３〜２４１５はダミーデータで、投入直後のパス管理ＤＢ部１９３２の状態に対応する。ダミーデータ２４１３〜２４１５は、Ｓ２５０１で、取得したフォルダ数の最大値の２倍を登録する。ダミーデータ２４１３〜２４１５はそれぞれ一意のファイルグループＩＤ２０１１を持ち、タスクＩＤ２０１２は「Ｆｏｌｄｅｒ」、パス２０１４は「Ｄｕｍｍｙ」、ホスト名２０１５は、停止対象ファイルサーバのホスト名２４１５として、「ＳｅｖｅｒＸ」を指定する。また、ダミーデータの有効期限２０１７は、例えば１週間とする。
【００８９】
Ｓ２５０５で、ファイルサーバ停止部１９４２は、停止対象のファイルサーバに実データが存在するかどうかを判断する。ここで、停止対象のファイルサーバに実データが存在するとファイルサーバ停止部１９４２が判断した場合、Ｓ２５０６で一定時間待機する。一方、停止対象のファイルサーバに実データが存在しないとファイルサーバ停止部１９４２が判断した場合は、Ｓ２５０９へ進む。
次に、Ｓ２５０７で、ファイルサーバ停止部１９４２は、パス管理ＤＢ部１９３２から削除したい停止対象ファイルサーバ２４１６上の実データの有無の取得を要求し、Ｓ２５０８へ進む。そして、Ｓ２５０８で、パス管理ＤＢ部１９３２は、ファイルサーバ停止部１９４２に実データの有無を応答する。Ｓ２５０８の応答を受けたファイルサーバ停止部は、再度Ｓ２５０５の処理を実行する。
一方、Ｓ２５０９では、ファイルサーバ停止部１９４２は、ファイルサーバ管理ＤＢ部１９３１から停止対象ファイルサーバ２４１６に関するエントリ（ＶＭ：バーチャルマシーン）の削除を指示する。そして、Ｓ２５１０で、ファイルサーバ管理ＤＢ部１９３１は、停止対象ファイルサーバ２４１６に関するエントリ（ＶＭ）を削除する。
次に、Ｓ２５１１で、ファイルサーバ停止部１９４２は、停止対象ファイルサーバ１９５０の停止を要求する。そして、Ｓ２５１２で、停止対象ファイルサーバ１９５０が停止をファイルサーバ停止部１９４２に通知して、本処理を終了する。
以上が、一時ファイル管理サービス１２０３からファイルサーバ（例えば停止対象ファイルサーバ１９５０）を停止する手順である。
【００９０】
以上のようにファイルサーバを停止する際に、ファイルサーバ停止部が停止対象ファイルサーバを指定してダミーデータ２４１３〜２４１５を投入する。この投入により、中央管理サーバ１８０１からは停止対象のファイルサーバに多数の実データがあたかも存在するように見える。このため、停止対象ファイルサーバに初期ファイルの保存が行われなくなり、時間の経過とともに停止対象ファイルサーバの実データが「０」になる。この方法により、他に影響を与えることなく停止対象とするファイルサーバを安全に停止させることができる。  本実施形態によれば、多重度を指定して保存可能な、複数のファイルサーバからなるファイルシステムにおいて、ファイルサーバを停止する際に、保存されているデータにアクセスできなくなること、多重度を低下させることを防ぐことができる。また、ユーザエクスペリエンスを低下させることなく、ファイルサーバを新規追加することができる。
これにより、ファイルサーバを追加する処理とファイルサーバを停止される処理とを統一的に実現するファイルシステムの仕組みを構築できる。したがって、クラウドコンピュータ環境において、ユーザの情報を管理して印刷処理や画像処理の状況に適応してファイルサーバを追加したり、停止したりしても、ファイルシステムの稼働環境をより柔軟に管理できる。
また、本願によれば、複数のファイルサーバからなるファイルシステムにおいて、新たにファイルサーバを追加する場合、追加対象の新規ファイルサーバへの負荷の集中を抑えられる。そして、負荷の集中を抑えると共に、短時間でより多くのデータを追加対象のファイルサーバへ格納できる仕組みを提供することが可能となる。
さらに、本願によれば、複数のファイルサーバからなるファイルシステムにおいて、いずれかのファイルサーバを停止させる場合、停止対象のファイルサーバにデータが存在しない状態で停止させることができる仕組みを提供することである。
【００９１】
本発明の各工程は、ネットワーク又は各種記憶媒体を介して取得したソフトウエア（プログラム）をパソコン（コンピュータ）等の処理装置（ＣＰＵ、プロセッサ）にて実行することでも実現できる。
【００９２】
本発明は上記実施形態に限定されるものではなく、本発明の趣旨に基づき種々の変形（各実施形態の有機的な組合せを含む）が可能であり、それらを本発明の範囲から除外するものではない。
【符号の説明】
【００９３】
１０１  スキャンサービスサーバ
１０２  フローサービスサーバ
１０３、１０４  タスクサービスサーバ
【図１】
2013206281.tif 000003
【図２】
2013206281.tif 000004
【図３】
2013206281.tif 000005
【図４】
2013206281.tif 000006
【図５】
2013206281.tif 000007
【図６】
2013206281.tif 000008
【図７】
2013206281.tif 000009
【図８】
2013206281.tif 000010
【図９】
2013206281.tif 000011
【図１０】
2013206281.tif 000012
【図１１】
2013206281.tif 000013
【図１２】
2013206281.tif 000014
【図１３】
2013206281.tif 000015
【図１４】
2013206281.tif 000016
【図１５】
2013206281.tif 000017
【図１６】
2013206281.tif 000018
【図１７】
2013206281.tif 000019
【図１８】
2013206281.tif 000020
【図１９】
2013206281.tif 000021
【図２０】
2013206281.tif 000022
【図２１】
2013206281.tif 000023
【図２２】
2013206281.tif 000024
【図２３】
2013206281.tif 000025
【図２４】
2013206281.tif 000026
【図２５】
2013206281.tif 000027