(57)【要約】【課題】ネットワーク上の複数のサーバ間において同一のオンラインドキュメントを共有し，かつ，どのサーバにおいても参照・更新を可能とするようなマルチサーバによるドキュメント分散処理システムの環境において，同期によって他の処理が待たされることなく，かつ，一貫性を保持しながらサーバの追加，変更を行うことを可能とする。【解決手段】サーバ１０のサーバ登録手段５１が，システムへの新規サーバの登録依頼があった場合に，依頼された時点における共有ドキュメントの複製を，新規サーバへ配送する処理を行うとともに，その後に更新されたドキュメントのデータの新規サーバへの配送を，全サーバへの新規サーバの登録が完了するまで代行する処理を行う。【選択図】図２
2005032270.tif 000002
【特許請求の範囲】
【請求項１】
ネットワーク上の複数のサーバ間において同一のオンラインドキュメントを共有し，かつ，どのサーバにおいても参照・更新を可能とするシステムにおいて，
システムへの新規サーバの登録依頼があった場合に，任意の依頼されたサーバは，依頼された時点における共有ドキュメントの複製を，新規サーバへ配送するとともに，その後に更新されたドキュメントのデータの新規サーバへの配送を，全サーバへの新規サーバの登録が完了するまで代行する
ことを特徴とするドキュメント分散処理システムのサーバ管理方法。
【請求項２】
ネットワーク上の複数のサーバ間において同一のオンラインドキュメントを共有し，かつ，どのサーバにおいても参照・更新を可能とするシステムにおいて，
あるドキュメントの管理情報を管理する管理サーバを他のサーバに変更する場合に，
元の管理サーバは，依頼されたドキュメントの管理情報を新しい管理サーバへ配送するとともに，そのドキュメントの管理情報に対する他のサーバからの要求を，新しい管理サーバに対して転送し，
新しい管理サーバは，前記ドキュメントの管理情報を取得した後，その管理情報の管理を開始し，他のサーバに対して管理サーバの移行を通知する
ことを特徴とするドキュメント分散処理システムのサーバ管理方法。
【請求項３】
ネットワーク上の複数のサーバ間において同一のオンラインドキュメントを共有し，かつ，どのサーバにおいても参照・更新を可能とするシステムにおいて，
あるドキュメントの管理情報を管理する管理サーバをシステムから削除する場合に，
削除される管理サーバは，前記ドキュメントの管理情報の管理を引き継ぐサーバに対して，そのドキュメントの管理情報を配送するとともに，そのドキュメントの管理情報に対する他のサーバからの要求を，管理を引き継ぐ管理サーバに対して転送し，管理を引き継ぐ管理サーバからの引き継ぎの確認後に他のサーバに対して自サーバの削除を依頼し，
管理を引き継ぐ管理サーバは，前記ドキュメントの管理情報を取得した後，その管理情報の管理を開始し，他のサーバに対して管理サーバの移行を通知する
ことを特徴とするドキュメント分散処理システムのサーバ管理方法。
【請求項４】
ネットワーク上の複数のサーバ間において同一のオンラインドキュメントを共有し，かつ，どのサーバにおいても参照・更新を可能とするシステムにおいて，
それぞれ別々にオンラインドキュメントを共有する複数のシステムを一つに統合するために，第１のシステムにおけるドキュメントの管理情報を管理する管理サーバを第２のシステムにおける管理サーバに変更するにあたって，前記第１のシステムにおける管理サーバは，自システムのドキュメントの管理情報を，前記第２のシステムにおける管理サーバへ配送するとともに，そのドキュメントの管理情報に対する他のサーバからの要求を，前記第２のシステムにおける管理サーバに対して転送し，
前記第２のシステムにおける管理サーバは，前記ドキュメントの管理情報を取得した後，その管理情報の管理を開始し，他のサーバに対して管理サーバの移行を通知する
ことを特徴とするドキュメント分散処理システムのサーバ管理方法。
【請求項５】
ネットワーク上の複数のサーバ間において同一のオンラインドキュメントを共有し，かつ，どのサーバにおいても参照・更新を可能とするシステムにおけるサーバが用いるプログラムを記録した計算機読み取り可能な記録媒体であって，
システムへの新規サーバの登録依頼があった場合に，依頼された時点における共有ドキュメントの複製を，新規サーバへ配送する処理と，
その後に更新されたドキュメントのデータの新規サーバへの配送を，全サーバへの新規サーバの登録が完了するまで代行する処理とを，
計算機に実行させるためのプログラムを記録したことを特徴とするサーバプログラムの記録媒体。
【請求項６】
ネットワーク上の複数のサーバ間において同一のオンラインドキュメントを共有し，かつ，どのサーバにおいても参照・更新を可能とするシステムにおけるサーバが用いるプログラムを記録した計算機読み取り可能な記録媒体であって，
あるドキュメントの管理情報を管理する機能を他のサーバに移行するとき，移行するドキュメントの管理情報を移行先の管理サーバへ配送する処理と，
そのドキュメントの管理情報に対する他のサーバからの要求を，移行先の管理サーバに対して転送する処理と，
自サーバが移行先のサーバとなるとき，移行元のサーバからドキュメントの管理情報を取得した後，その管理情報の管理を開始し，他のサーバに対して管理サーバの移行を通知する処理とを，
計算機に実行させるためのプログラムを記録したことを特徴とするサーバプログラムの記録媒体。
【請求項７】
ネットワーク上の複数のサーバ間において同一のオンラインドキュメントを共有し，かつ，どのサーバにおいても参照・更新を可能とするシステムにおけるサーバが用いる計算機読み取り可能なプログラムを記録した記録媒体であって，
自サーバをシステムから削除する場合に，自サーバが管理するドキュメントの管理情報を，管理を引き継ぐサーバに対して配送する処理と，
そのドキュメントの管理情報に対する他のサーバからの要求を，前記管理を引き継ぐ管理サーバに対して転送する処理と，
前記管理を引き継ぐ管理サーバからの引き継ぎの確認後に他のサーバに対して自サーバの削除を依頼する処理と，
自サーバが他のサーバから，あるドキュメントの管理情報の管理を引き継ぐ場合に，前記ドキュメントの管理情報を取得した後，その管理情報の管理を開始し，他のサーバに対して管理サーバの移行を通知する処理とを，
計算機に実行させるためのプログラムを記録したことを特徴とするサーバプログラムの記録媒体。
【請求項８】
ネットワーク上の複数のサーバ間において同一のオンラインドキュメントを共有し，かつ，どのサーバにおいても参照・更新を可能とするシステムにおけるサーバが用いるプログラムを記録した計算機読み取り可能な記録媒体であって，
それぞれ別々にオンラインドキュメントを共有する複数のシステムを一つに統合するために，自サーバが管理する自システムにおけるドキュメントの管理情報の管理機能を，他のシステムにおける管理サーバに変更するにあたって，自システムのドキュメントの管理情報を，前記第２のシステムにおける管理サーバへ配送する処理と，
そのドキュメントの管理情報に対する他のサーバからの要求を，前記第２のシステムにおける管理サーバに対して転送する処理と，
自サーバが他のシステムの管理サーバからドキュメントの管理情報の管理機能を引き継ぐ場合に，そのドキュメントの管理情報を取得した後，その管理情報の管理を開始し，他のサーバに対して管理サーバの移行を通知する処理とを，
計算機に実行させるためのプログラムを記録したことを特徴とするサーバプログラムの記録媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
複数拠点（サーバ）における事務系，開発系の業務などで，各拠点間で同一のドキュメント（文書）を互いに参照・更新することがある。ドキュメントがオンライン上のファイルであるような場合には，単一の文書を転送するか，同一内容の文書を複数のサイトで共有する方法がある。
【０００２】
本発明は，同一内容の文書を複数のサイトで共有する方式に係り，特に，マルチサーバ環境においてサーバを追加登録，または変更する場合のドキュメント分散処理システムのサーバ管理方法およびサーバプログラムの記録媒体に関する。
【背景技術】
【０００３】
従来，複数拠点間で文書を共有する技術として，以下の方法がある。
（１）ワークフロー等を利用し，単一の文書を拠点間で転送する方法。
（２）同一文書の複製を拠点間で保有し，複製された文書に対し参照・更新を行う方法。
【０００４】
後者の（２）に示す同一文書の複製を拠点間で保有する方法の場合には，複数の拠点で同一文書に関する更新が発生し，内容の異なる文書が複数存在する可能性があるが，この対処方法として，以下の方法がある。
（２−ａ）更新可能な拠点を１箇所に限定し，他の拠点では更新を禁止する方法。
（２−ｂ）複数の拠点での更新を許可し，複製を統合する際に何らかの手段で文書間の差異の修正を行う方法。
【０００５】
また，従来のマルチサーバによる資源管理の技術は，マスタ・スレーブ方式のような集中型のものがほとんどであった。マスタ・スレーブ方式のシステムに新しいサーバを登録する場合には，マスタに相当するサーバに登録を依頼し，依頼されたマスタサーバは，新しいサーバに資源を配布できるようにするための変更を行い，トランザクション中の制御も１箇所で実行していた。
【０００６】
なお，ネットワーク上の複数のサーバ間において同一のデータを共有し，かつ，どのサーバにおいても参照・更新を可能とするシステムについて，例えば下記の特許文献１に記載されている。
【特許文献１】特開平９−２４４９３５号公報
【発明の開示】
【発明が解決しようとする課題】
【０００７】
従来の（１）に示す方法は，文書を更新する手順が拠点間で予め決定されている場合には問題がないが，複数拠点で任意に参照・更新を行う必要があるような非定型業務の場合には不適である。
【０００８】
また，（２−ａ）に示す方法は，更新を行える拠点が限定されているため，やはり自由に更新を行うことができないという問題がある。
【０００９】
（２−ｂ）に示す方法は，多重更新が頻繁に発生してしまうことが問題であり，多重更新により生じてしまった差異を解決する手段として一般に有効な方法がない。
【００１０】
また，従来のマスタ・スレーブ方式のシステムの場合には，新しいサーバの追加，既存のサーバの削除などが必要となったとき，特定の１箇所でサーバの登録変更が行われるため，管理情報の一貫性の保持についての問題は発生しなかった。しかし，ネットワーク上の複数のサーバ間において同一のオンラインドキュメントを共有し，かつ，どのサーバにおいても参照・更新を可能とするようなドキュメント分散処理システムは，マスタに相当するデータやトランザクションを一括管理するサーバは存在せず，すべてのサーバが対等に存在し，自由にサーバの追加変更が行えるマルチサーバ環境であることが望ましい。
【００１１】
このような各サーバが対等なマルチサーバ環境では，任意の箇所でのサーバ変更が発生することがあるために，サーバごとにサーバの登録状態の不整合が発生するという問題がある。サーバ登録の不整合があると，資源に関する更新処理が失敗したり，生成されたドキュメントが届かないことが起こる。これを回避するためには，ドキュメントを参照，更新するシステムのサービスを一旦止めて，全サーバで同期的にサーバを追加・削除するなどの必要があり，その間におけるサービス性が著しく阻害される。
【００１２】
本発明は上記問題点の解決を図り，サービス性のよいドキュメント分散処理システムを実現することを目的とする。特に，本発明は，各サーバが対等なマルチサーバ環境でも，同期のためのサービスの中断によって，他の処理が待たされることがないようにすること，かつ，一貫性を保持しながらサーバの追加，変更を可能にすることを目的とする。また，本発明に関連する発明は，複数の拠点における任意の更新を許容するが，１箇所の拠点で更新を行っている間のみ，他の拠点では更新を許可しない方式によって，多重更新の発生頻度を減少させ，かつ更新の際のロック要求に関する待機時間を短縮するような方式を提供することを目的とする。
【課題を解決するための手段】
【００１３】
図１は，本発明の原理説明図である。図１において，ネットワーク４０で結ばれた複数の拠点には，それぞれ，サーバ１０ａ，１０ｂと，レポジトリ２０ａ，２０ｂ，サーバに接続するクライアント３０ａ，３０ｂが存在する。各拠点はサーバ・クライアント構成になっている。
【００１４】
メッセージ処理手段１ａ，１ｂは，他サーバへ送信するメッセージの作成，および他サーバから到着したメッセージの処理を行う手段である。本システムでは，ドキュメントの論理オブジェクト（ドキュメントのメタ情報）および実体もメッセージに変換して配送するので，メッセージ処理手段１ａ，１ｂは，配送の際にオブジェクト／ファイルからメッセージへの変換および配送されてきたメッセージからオブジェクト／ファイルへの復元も担当する。
【００１５】
メッセージ通信手段２ａ，２ｂは，他サーバへのメッセージ送信および他サーバからのメッセージ受信を担当する手段である。
【００１６】
レポジトリ管理手段３ａ，３ｂは，レポジトリ２０ａ，２０ｂに格納されている論理オブジェクトや実体の参照，検索，更新等を行う。版数管理手段４ａ，４ｂ，は，ドキュメントの版管理を担当する。ロック管理手段５ａ，５ｂは，ドキュメントのロック，ロック解除，ロック状態の管理を担当する。
【００１７】
時刻監視手段６ａ，６ｂは，メッセージ通信のタイムアウト発生および定期レプリケーション時刻の通知を，メッセージ処理手段１ａ，１ｂに対して行う。ユーザインタフェース（ＵＩ）７ａ，７ｂは，利用者からのドキュメントの参照，更新操作を受け付ける手段である。
【００１８】
レポジトリ２０ａ，２０ｂは，ドキュメントの実体ファイルや論理オブジェクトを格納する記憶手段である。例えば，データベースに類似する構造を持つ格納領域を持つ。クライアント３０ａ，３０ｂは，文書を編集・参照するドキュメントアプリケーションを持つ。
【００１９】
本発明では，同一ドキュメント（文書）が各サーバに配置される。あるサーバ１０ａで生成・更新されたドキュメントの内容は，ネットワーク４０を介して他のサーバ１０ｂが持つドキュメントに反映される。
【００２０】
図２は，本発明によるサーバ管理のための構成を説明する図である。図１に示す各サーバ１０ａ，１０ｂ，…のメッセージ処理手段１は，サーバの登録，削除，ドキュメントの管理情報を管理するサーバの変更，複数のシステムの統合のために，図２に示すように，サーバ登録手段５１，サーバ削除手段５２，管理サーバ変更手段５３，システム統合手段５４を持つ。サーバ一覧テーブル５５は，システムに登録されているサーバの情報を保存するテーブルである。
【００２１】
サーバ登録手段５１は，システムへの新規サーバの登録依頼があった場合に，依頼された時点における共有ドキュメントの複製を，新規サーバへ配送する処理を行うとともに，その後に更新されたドキュメントのデータの新規サーバへの配送を，全サーバへの新規サーバの登録が完了するまで代行する処理を行う。
【００２２】
また，サーバ削除手段５２は，自サーバをシステムから削除する場合に，自サーバのレポジトリ管理手段３が管理するドキュメントの管理情報を，管理を引き継ぐサーバに対して配送する処理と，そのドキュメントの管理情報に対する他のサーバからの要求を，管理を引き継ぐ管理サーバに対して転送する処理と，管理を引き継ぐ管理サーバからの引き継ぎの確認後に他のサーバに対して自サーバの削除を依頼する処理とを行う。また，サーバ削除手段５２は，自サーバが他のサーバからドキュメントの管理情報の管理を引き継ぐ場合に，そのドキュメントの管理情報を取得した後，レポジトリ管理手段３によりその管理情報の管理を開始し，他のサーバに対して管理サーバの移行を通知する処理を行う。
【００２３】
管理サーバ変更手段５３は，あるドキュメントの管理情報を管理する機能を他のサーバに移行するとき，移行するドキュメントの管理情報を移行先の管理サーバへ配送する処理と，そのドキュメントの管理情報に対する他のサーバからの要求を，移行先の管理サーバに対して転送する処理とを行う。さらに，自サーバが管理移行先のサーバとなるときには，移行元のサーバからドキュメントの管理情報を取得した後，レポジトリ管理手段３によりその管理情報の管理を開始し，他のサーバに対して管理サーバの移行を通知する処理を行う。
【００２４】
システム統合手段５４は，それぞれ別々にオンラインドキュメントを共有する複数のシステムを一つに統合するために，自サーバのレポジトリ管理手段３が管理する自システムにおけるドキュメントの管理情報の管理機能を，他のシステムにおける管理サーバに変更するにあたって，自システムのドキュメントの管理情報を，他のシステムにおける管理サーバへ配送する処理と，そのドキュメントの管理情報に対する他のサーバからの要求を，前記他のシステムにおける管理サーバに対して転送する処理とを行う。さらに，自サーバが他のシステムの管理サーバからドキュメントの管理情報の管理機能を引き継ぐ場合には，そのドキュメントの管理情報を取得した後，その管理情報の管理を開始し，他のサーバに対して管理サーバの移行を通知する処理を行う。
【００２５】
以上の各処理手段をサーバの計算機によって実現するためのプログラムは，計算機が読み取り可能な可搬媒体メモリ，半導体メモリ，ハードディスクなどの適当な記録媒体に格納することができる。
【発明の効果】
【００２６】
本発明のドキュメント分散処理システムのサーバ管理方法によれば，ネットワーク上の複数のサーバ間において同一のオンラインドキュメントを共有し，かつ，どのサーバにおいても参照・更新を可能とするようなマルチサーバによるドキュメント分散処理システムの環境において，同期によって他の処理が待たされることなく，かつ，一貫性を保持しながらサーバの追加，変更を行うことができる。
【発明を実施するための最良の形態】
【００２７】
以下に，本発明の実施の形態を説明する。はじめに，本発明に関連するドキュメント分散処理方法の実施の形態を説明する。
【００２８】
本実施の形態を説明する前提として，遠隔の拠点間で文書を相互に共有するような業務を行う場合を例とする。
【００２９】
各拠点には，コンピュータと，ファイルや論理オブジェクトを格納可能なレポジトリ（データベース）と，サーバアプリケーションが存在する。レポジトリは，文書（ドキュメント）を版（バージョン）管理し，版ごとに文書を格納できる機能を持つ。また，拠点はすべてネットワークに接続されており，任意の拠点間でメッセージ通信，ファイルや論理オブジェクトの転送が可能である。各拠点は，サーバ・クライアント構成になっており，クライアントには文書を編集・参照するドキュメントアプリケーションが実装されている。
【００３０】
図３は，このようなシステムにおける文書の複製と配布を説明する図である。図３に示すように，同一文書を複製したものを各サーバＡ，Ｂ，Ｃに配置する。サーバＡまたはサーバＡに接続されているクライアントにより文書１を生成または更新した場合には，サーバＡは，ネットワークで結ばれた他のサーバＢ，Ｃに対し文書１の複製を送信する。
【００３１】
図４は，送信処理および受信処理の処理フローチャートである。送信処理では，図４（Ａ）に示すように，文書を作成・更新したサーバは，文書を複製し（Ｓ１０１），その複製を他のサーバに送信する（Ｓ１０２）。受信処理では，図４（Ｂ）に示すように，サーバは複製を受信し（Ｓ１０３），複製を自己の文書に反映させる（Ｓ１０４）。なお後述するが，文書の複製は，文書の実体を複製する以外に，文書に関するメタ情報である論理オブジェクトのみを複製してもよい。
【００３２】
〔第１の処理方式〕
第１の処理方式では，サーバは更新開始時に他のサーバに対して，更新開始を通知する。他のサーバは更新開始通知を受けとった時点でその文書をロックする。ロックされた文書は，ロックが解除されるまでそのサーバでは更新不可能になる。更新を完了したサーバは，他のサーバに更新後の文書を配布する。他のサーバは，配布された文書を受け取った時点でロックを解除し，更新結果を自己の文書に反映させる。
【００３３】
図５は，第１の処理方式の手順の例を示す図である。サーバＡは，クライアントからの更新開始を契機に，他のサーバＢ，Ｃに対して，ロック要求を含む更新開始通知を送信する。他のサーバＢ，Ｃは，更新開始通知を受信した時点でその文書をロックし，ロック完了通知をサーバＡに返信する。
【００３４】
その後，更新を終了したサーバＡはその文書のロックを解除し，他のサーバＢ，Ｃに対して更新後の文書（更新文書）を配布する。他のサーバＢ，Ｃは，更新文書を受信した時点で文書のロックを解除し，自サーバの文書に更新結果を反映させる。
【００３５】
図６は，第１の処理方式における処理フローチャートである。図６（Ａ）に示す送信処理においては，クライアントが文書更新の開始を宣言すると（Ｓ１１０），他のサーバに対してロック要求を含む更新開始通知を送信する（Ｓ１１１）。他のサーバからのロック完了通知を受信し（Ｓ１１２），その後に文書を更新し（Ｓ１１３），その文書の論理オブジェクトまたは実体の複製を他のサーバへ送信する（Ｓ１１４）。  
【００３６】
図６（Ｂ）に示す受信処理においては，文書更新を開始したサーバからロック要求を含む更新開始通知を受信すると（Ｓ１１５），文書をロックし（Ｓ１１６），直ちにロック完了通知を送信する（Ｓ１１７）。続いて，文書の論理オブジェクトまたは実体の複製を受信し（Ｓ１１８），文書のロックを解除する（Ｓ１１９）。
【００３７】
〔第２の処理方式〕
上記第１の処理方式では，他のすべてのサーバＢ，Ｃでロックが行われ，その結果として返される結果（ロック完了通知）を確認した後に，更新開始の許可を利用者（クライアント）に与えているため，通信に時間を要するような環境では，利用者が更新開始を宣言してから実際に更新処理を始めるまで，かなりの時間待たされることになる。
【００３８】
第２の処理方式では，この点を改良し，文書を更新するサーバは，他サーバからのロック完了通知の受信を待たずに，自サーバのクライアントに更新を許可し，ロックの正否（他サーバからの更新承認）の判定は更新終了まで延期する。これにより，クライアントは，更新を先行的に実行することができ，時間の短縮が可能になる。
【００３９】
図７は，第２の処理方式の手順の例を示す図である。サーバＡは，クライアントから更新開始の依頼を受けると，サーバＢおよびサーバＣに対しロック要求を含む更新開始通知を送信した後，直ちにクライアントに更新開始ＯＫを出して更新を許可する。サーバＢ，Ｃは，ロック要求を含む更新開始通知を受信して，該当する文書をロックし，ロック完了通知をサーバＡに返す。
【００４０】
サーバＡでは，更新終了までに他サーバからのロック完了通知を受信し，他サーバＢ，Ｃによる更新承認の判定を行い，更新を終了する。もし，更新終了までの間に，他サーバＢ，Ｃからロック完了通知を受信しなかった場合には，クライアントによる文書の更新を無効にして文書を更新開始前の状態に戻すか，またはその文書をローカル版として保存し，処理を終了する。
【００４１】
図８は，第２の処理方式における処理フローチャートである。図８（Ａ）に示す送信処理においては，クライアントが文書更新の開始を宣言すると（Ｓ１２０），他のサーバに対してロック要求を送信して（Ｓ１２１），直ちに文書更新を許可する（Ｓ１２２）。更新が終了するまでの間に，他のサーバからのロック完了通知を受信し，他のすべてのサーバからロック完了通知を受信したなら（Ｓ１２３），更新された文書の実体または論理オブジェクトの複製を他のサーバに送信する（Ｓ１２４）。  
【００４２】
図８（Ｂ）に示す受信処理においては，文書更新を開始したサーバからロック要求を受信し（Ｓ１２５），その文書をロックし（Ｓ１２６），ロック完了通知を要求元のサーバへ送信する（Ｓ１２７）。文書を更新したサーバから，文書の実体または論理オブジェクトの複製を受信したなら（Ｓ１２８），それを自サーバ内の文書に反映し，ロックを解除する（Ｓ１２９）。
【００４３】
〔第３の処理方式〕
文書を共有するシステムにおいて，いずれかのサーバで文書が新規作成・更新された場合には，更新内容を他のサーバに反映させる必要があるが，更新のたびに文書内容の転送を行う方法では，ファイルサイズが大きい場合やサーバ間の通信に時間がかかる場合には通信の負荷が問題となる。
【００４４】
第３の処理方式では，各サーバにおける文書を，文書の実体である文書ファイル（以下，実体ファイルという）そのものと，文書に関する情報（実体ファイルへのリンク，文書名，作成者，作成日付，版数等）のみで構成される論理オブジェクトとの二つに分離して実装する。図９は，文書の実装形態の例を示す図である。
【００４５】
クライアントから参照・更新のために文書を利用する場合には，論理オブジェクトを経由して実体ファイルの取得を行う。
【００４６】
また，文書を論理オブジェクトと実体ファイルとに分離して実装することで，文書の新規作成時や更新時には，文書実体を配布せずに論理オブジェクトのみを配布し，実体ファイルは，通常更新が発生しない時間帯や通信負荷が小さい時間帯などを指定しておき，定期的に配布する。
【００４７】
図１０は，第３の処理方式を説明する図である。サーバＡで文書を新規作成または更新すると，図１０（Ａ）に示すように，他のサーバＢ，Ｃに対しては，更新後の論理オブジェクト（新）のみを複製して即時に配布する。更新後の文書の実体ファイル（新）は，直ちに送ることはしないで，図１０（Ｂ）に示すように，通常，更新が発生しない時間帯などに定期的に複製して配布を行う。
【００４８】
さらに，論理オブジェクトに，最新実体の保有の有無，最新実体を保有するサーバの識別子の情報を追加することもできる。
【００４９】
図１１は，最新の実体の取得処理の処理フローチャートである。利用者が更新を開始するなど，最新の文書の実体が必要な場合には，自サーバの持つ論理オブジェクトに対し，最新実体の有無を問い合わせる（Ｓ１３０，Ｓ１３１）。自サーバが最新の実体ファイルを保有していない場合には，論理オブジェクトより最新の実体ファイルを保有するサーバの識別子を得て，そのサーバに最新の実体ファイルを要求し，必要な最新の実体ファイルを転送してもらい（Ｓ１３２），文書処理を行う（Ｓ１３３）。自サーバが最新の実体ファイルを保有している場合には，その実体ファイルを使用して文書処理を行う（Ｓ１３３）。
【００５０】
〔第４の処理方式〕
複数のサーバが同時に更新を開始した場合，互いに文書のロックができないため，個々のサーバでそれぞれ更新が行われてしまう。そこで，同一文書に対するロック要求が複数のサーバから発生した場合には，いずれかのロックを有効にするために，各サーバにあらかじめ異なる優先度を設定し，文書をロックする際に，ロックを要求した（更新の発生した）サーバの優先度を同時に記録する。このため，他のサーバに対してロックを要求する場合には，優先度情報を付加して送信する。
【００５１】
ロックを要求されたサーバでは，既にその文書がロック状態である場合，ロックを要求したサーバの優先度を比較する。もし，新しくロックを要求したサーバの優先度がロック中のサーバの優先度よりも高い場合には，現在のロックをキャンセルし，新たに到着したロック要求を実行する。新しくロックを要求したサーバの優先度がロック中のサーバの優先度よりも低い場合には，現在のロックを優先し，新たに到着したロック要求を拒絶する。
【００５２】
図１２は，第４の処理方式を説明する図である。サーバＡ，Ｂ，Ｃにおいて，サーバＡの優先度がサーバＢの優先度より高いとする。図１２（Ａ）に示すように，サーバＣにおいてサーバＢからの依頼による文書ロック状態である場合に，サーバＡからのロック要求が到着したときには，サーバＡの優先度がサーバＢの優先度より高いため，サーバＣは，現在のサーバＢによる文書ロックをキャンセルし，到着したサーバＡによるロック要求を実行する。
【００５３】
一方，図１２（Ｂ）に示すように，サーバＣにおいてサーバＡからの依頼による文書ロック状態である場合に，サーバＢからのロック要求が到着したときには，既に優先度の高いサーバＡによる文書ロックがされているのでこれを優先し，サーバＣは，サーバＢからのロック要求を却下する。
【００５４】
図１３は，第４の処理方式における処理フローチャートである。あるサーバが，文書ロック状態であり（Ｓ１４０），他のサーバからロック要求を受信したなら（Ｓ１４１），受信したロック要求の要求元のサーバの優先度と，現在のロックを要求したサーバの優先度とを比較し（Ｓ１４２），要求元サーバの優先度が現ロックの要求元サーバの優先度より高い場合には，現在の文書ロックをキャンセルし，受信したサーバのロック要求を実行する（Ｓ１４３）。受信したサーバの優先度が現ロックの要求元のサーバの優先度より高くない場合には，受信したロック要求を却下する（Ｓ１４４）。
【００５５】
〔第５の処理方式〕
前述した処理方式では，先行的に更新を行うことを許容しているため，更新に要する時間が短い等の原因で，図１４に示すように多重更新が発生してしまう可能性がある。この場合，同じ版に更新してしまうと，同一の版で異なる内容の文書が存在してしまうという問題が発生する。
【００５６】
そこで，各サーバ単位に独自の版体系を設定し，配布された版から分枝できるようにする。そして，サーバの優先度に対応して版体系に優先度を設定し，このうち最も優先度の高い版体系をそのシステムにおける正式版とする。
【００５７】
図１５は，第５の処理方式の手順の例を示す図である。まず，サーバＢは，文書の更新時に，他のサーバであるサーバＣに対してロック要求を送信するともに，そのシステムで最も優先度の高いサーバＡに対して正式版の改版申請を送信する。同様に，サーバＣも文書を更新するときには，他のサーバＢにロック要求を送信し，サーバＡに対して改版申請を送信する。
【００５８】
サーバＡでは，改版申請された文書がロックされていなければ，先に到着したサーバＢの改版申請に対して改版承認のメッセージを返送する。改版承認を既に発行した後に届いたサーバＣの改版申請に対しては，改版却下のメッセージを返送する。
【００５９】
改版承認を受け取ったサーバＢは，他のサーバＡ，Ｃに対して承認された新版の実体または論理オブジェクト（以下，文書オブジェクトという）を複製し配布することにより，改版を行う。これにより，サーバＢにおいて更新された文書１の正式な版数は「Ａ−２」となる。
【００６０】
サーバＡでは，サーバＢから配布された新版文書オブジェクト（文書１，版：Ａ−２）を正式版とする。また，改版申請を却下されたサーバＣでは，文書更新が取り消され，サーバＢから配布された新版文書オブジェクト（文書１，版：Ａ−２）を正式版とする。ここで，サーバＣ内で文書１（版：Ｃ−２）の更新が完了していた場合には，この文書１（版：Ｃ−２）は，サーバＣのローカル版文書として保存される。
【００６１】
図１６は，第５の処理方式の処理フローチャートである。更新サーバにおいては，図１６（Ａ）に示すように，文書更新を開始すると（Ｓ１５０），正式版を発行するサーバに対して改版申請を送信して（Ｓ１５１），文書を更新する（Ｓ１５２）。まず，自サーバにおける独自の版体系で改版し（Ｓ１５３），正式版を発行するサーバからの改版承認を受信するまで待機し（Ｓ１５４），改版承認を受信したなら，承認された正式版で改版を行う（Ｓ１５５）。  
【００６２】
正式版を発行するサーバにおいては，図１６（Ｂ）に示すように，文書更新を開始したサーバから改版申請を受信すると（Ｓ１５６），既に他のサーバに改版承認を送信したかどうかを判断し（Ｓ１５７），既に改版承認を送信している場合には，新しい申請元のサーバに対し改版却下を送信し（Ｓ１５８），未だ改版承認を送信していない場合には，改版承認を送信する（Ｓ１５９）。
【００６３】
〔第６の処理方式〕
上述した第５の処理方式では，仮に最も優先度の高いサーバとの通信が途絶している場合に，ローカル版以外の改版が行えなくなってしまうという問題が生じる。そこで，改版申請を送信してから応答を受信するために待つ時間の限界（タイムアウト）を設定し，タイムアウトが発生した場合に，次に優先度の高いサーバに対して改版申請を再送信し，そのサーバにより改版承認が得られたときに，得られた版の文書オブジェクト（実体または論理オブジェクト）を複製し配布する。
【００６４】
図１７は，通信途絶が発生した場合の手順の例を示す図である。サーバＣが更新時に，システム内で優先度が最も高いサーバＡに対して改版申請を送信したにもかかわらず，そのサーバＡもしくは通信路の障害等によりその通信が途絶した場合には，サーバＣは，改版申請の応答に対するタイムアウトを検出し，次に優先度の高いサーバＢに対して改版申請を再送信する。サーバＢがサーバＣに対して改版承認を発行すると，サーバＣは，更新を完了した新版文書オブジェクト（版：Ｃ−２）を複製し，サーバＢに配布して改版を行う。
【００６５】
図１８は，第６の処理方式によるタイムアウトが発生した場合の処理フローチャートである。更新サーバにおいて，文書更新を開始すると（Ｓ１６０），正式版を発行するサーバに対して改版申請を送信して（Ｓ１６１），文書を更新する（Ｓ１６２）。自サーバにおける独自の版体系で改版し（Ｓ１６３），正式版を発行するサーバからの改版承認を受信したかどうかを判断する（Ｓ１６４）。改版承認を受信したなら，承認された正式版で改版を行う（Ｓ１６５）。改版承認を受信しないときにはタイムアウト発生まで待機して（Ｓ１６６），タイムアウト発生であれば，次の優先度のサーバに対し改版申請を送信して（Ｓ１６７），Ｓ１６４以下の処理を行う。なお，改版申請が却下された場合に，その文書を自サーバのみのローカル版文書として扱うことは，前述した第５の処理方式と同様である。
【００６６】
〔第７の処理方式〕
上述した第５および第６の処理方式においては，最も優先度の高いサーバに通信が集中する傾向がある。そこで，本方式では，負荷分散のために，各文書単位にサーバの優先度を設定する。これにより，文書ごとに最も優先度の高いサーバが分散されるので，通信の集中を回避することができる。
【００６７】
次に，遠隔地の３拠点において，文書を互いに共有するような業務に本発明を適用した実施例を説明する。
【００６８】
ネットワークで結ばれた拠点Ａ，Ｂ，Ｃでは，比較的大きなサイズの文書を扱い，文書の更新が行われる主な拠点は，文書の種類によってほぼ決まっているものとする。例えば「設計書」という種類の文書は，主に拠点Ａで更新され，拠点Ｂ，Ｃでも更新はされるが頻度は少ないものとする。
【００６９】
文書は，文書内容が格納された実体ファイルと論理オブジェクトとに分離して各拠点のリポジトリに格納される。各拠点には，サーバ，クライアントの装置が設置され，利用者はクライアントから各拠点にあるサーバに接続して作業を行う。クライアントからは文書の作成・登録，参照および編集が可能である。
【００７０】
サーバＡで「設計書」である文書１を新規作成した場合，サーバＢおよびサーバＣに対して文書１の論理オブジェクトが配布される。したがって，サーバＢ，Ｃの利用者は，クライアント上で新規生成された文書１の情報（文書名，作成者，作成日時，バージョン等）を論理オブジェクトから取得することができる。
【００７１】
ここで，文書の実体（ファイル）はサーバＢおよびサーバＣ上には送られていない。サーバＢ上で文書１を参照したい場合，利用者はクライアントから文書１の実体を要求する。そうすると，サーバＢは，サーバＡに対して実体の配布を要求し，サーバＡからサーバＢへ実体のコピーが行われる。コピーが完了するとクライアントを介して利用者に通知が行われる。
【００７２】
また，その日に作成された文書１は，１日１回，作業の少ない時間帯を指定して，すべてのサーバに対して一括して実体（ファイル）を配布するように設定する。したがって，前日に作成された文書は翌日以降にはどの拠点においても，配布要求を行わずに，直ちに取得することができる。
【００７３】
「設計書」はサーバＡで最も多く更新が行われるので，更新の優先度をサーバＡが最も高く，次いでサーバＢ，サーバＣの順とする。サーバＡは最も優先度が高いので，サーバＢ，サーバＣの利用者が先に更新を開始していても，後からサーバＡで同じ文書の更新が開始されたなら，サーバＢ，Ｃの利用者は，更新のキャンセルを要求される場合がある。
【００７４】
また，サーバＢ，サーバＣでは同じ１．０版から更新を行った場合，更新の終了直後ではサーバＢにおいては１．１／Ｂ版，サーバＣにおいては１．１／Ｃ版のようなそのサーバ固有の版（ローカル版）が生成される。その後，サーバＡからの２．０版への改版許可が得られた時点で，１．１／Ｂのようなローカル版は，グローバル版である２．０版に置き換えられる。なお，ローカル版はそのサーバにおいて保存される。
【００７５】
次に，本発明のドキュメント分散処理システムのサーバ管理方法の実施の形態を説明する。すべてのサーバが対等に存在し，自由にサーバの追加変更を行えるマルチサーバ環境を実現するために，以下に説明する管理方式を用いる。
【００７６】
図１９は，サーバ一覧テーブルの構成例を示す図である。サーバ一覧テーブルには，サーバ名，宛て先（アドレス），サーバの属性に関する情報を記憶する。サーバの属性には，例えばそのサーバがどのような管理情報を管理しているかなどの情報が含まれる。このサーバ一覧テーブルは，全サーバが同じ内容のものを保持し，各サーバ間の通信に用いられる。
【００７７】
〔第１の管理方式〕
各サーバがデータ（ドキュメント）の複製を共有し，任意のサーバでデータ更新が行えるようなマルチサーバシステムにおいて，サーバを登録する場合を考える。あるサーバで更新されたデータは，その複製が別のサーバに配送される。
【００７８】
もし，データが特定のサーバだけで更新されるのであれば，新規登録のサーバは，データの更新を管理するサーバからデータを取得すればよい。しかし，データが任意の箇所で更新される可能性があるので，あるサーバからデータを取得している間に他のサーバがデータを更新した場合には，登録した時にはその新しい更新データを取得することができず，その結果，サーバ間で所有するデータに差異が生じてしまうおそれがある。
【００７９】
本発明では，サーバの登録が完了し，新規サーバが他の全サーバからデータを受け取ることが確認されるまで，任意の登録されている１サーバを指定し，指定されたサーバが新規サーバへのデータの配送を代行するようにする。この手順を図２０に示す。
【００８０】
図２０は，第１の管理方式の手順の例を示す図である。
【００８１】
（Ｐ１１）  本システムへの追加登録を希望する新規サーバＸは，すでにシステムに登録されているサーバＡ〜Ｄの一つ（例えばサーバＡ）に，現時点で登録されているサーバの情報を持つサーバ一覧テーブルの送付と，現時点で共有されているデータの複製の配送および新たな更新データの配送代行を依頼する。
【００８２】
（Ｐ１２）  サーバＡは，自己の持つサーバ一覧テーブルにサーバＸを追加登録し，そのサーバ一覧テーブルとデータを新規サーバＸに送信する。
【００８３】
（Ｐ１３）  以後，依頼されたサーバＡは，サーバＸから転送終了の依頼があるまで，他のサーバ（例えばサーバＢ）から自サーバに配送されてきたデータをすべて新規サーバＸに転送する。
【００８４】
（Ｐ１４）  新規サーバＸは，サーバ一覧テーブルをもとに，登録されているサーバＢ〜Ｄ（またはサーバＡ〜Ｄ）に対して，自サーバの登録を依頼する。
【００８５】
（Ｐ１５）  サーバＢ〜Ｄは，新規サーバＸからの登録依頼を受け取った場合，新規サーバＸを自サーバが持つサーバ一覧テーブルに登録し，登録完了を新規サーバＸに通知する。この登録以降，サーバＢ〜Ｄは，新規サーバＸに対して直接更新されたデータを配送する。
【００８６】
（Ｐ１６）  新規サーバＸは，サーバＢ〜Ｄから登録完了通知を受け取ると，最初に配送の代行を依頼したサーバＡに対して，代行の終了を依頼する。代行を行っているサーバＡは，代行終了（転送終了）依頼を受け取ったら，新規サーバＸへの配送代行を終了する。
【００８７】
図２１は，第１の管理方式における処理フローチャートである。新規登録を希望する新規サーバは，現時点で登録されているサーバ一覧を任意のサーバより取得し（ステップＳ２０１），サーバ一覧に登録されているサーバの一つにデータ配送の代行を依頼する（ステップＳ２０２）。代行を依頼されたサーバは，自分に配送されたデータをすべて新規サーバに転送する（ステップＳ２０３）。
【００８８】
新規サーバは，サーバ一覧をもとに，登録されたサーバすべてに対して自サーバの登録を依頼する（ステップＳ２０４）。他のサーバは，新規サーバからの登録依頼を受け取ったら，新規サーバを自己のサーバ一覧に追加登録し，登録完了を通知する。以降，他のサーバは，新規サーバに対して更新したデータを配送する（ステップＳ２０５）。
【００８９】
新規サーバは，すべてのサーバから登録完了通知を受け取ったら，最初に配送代行を依頼したサーバに対して，配送代行の終了を依頼する（ステップＳ２０６）。代行を依頼されたサーバは，代行終了（転送終了）依頼を受け取ったら，新規サーバへの配送代行を終了する（ステップＳ２０７）。
【００９０】
〔第２の管理方式〕
マルチサーバ環境において，ある資源を管理するサーバを，他のサーバに変更する必要が生じることがある。ここで，ある資源の状態が，別のサーバによる資源の使用によって変更されるとすると，ある時点をもって一度に新しいサーバに資源管理を移行させなければならない。しかし，一般に，管理サーバの変更の認知には各サーバごとに時間的なずれが生じるので，新しい管理サーバへの処理要求と古い管理サーバに対する処理要求とが混在する時間帯が存在する。これらの要求は，一貫性を保持するためにどちらか一方のサーバで処理されることが必要になる。資源の状態とは，例えばドキュメントの版数などである。この問題を解決するための手順を図２２に示す。
【００９１】
図２２は，第２の管理方式の手順の例を示す図である。
【００９２】
（Ｐ２１）  現在，ある資源の管理を管理サーバＡが行っており，その管理を新管理サーバＹに移行するものとする。新管理サーバＹは，現在の管理サーバＡに対して，資源の管理情報の配送と，自サーバへの処理の移行の依頼を申請する。
【００９３】
（Ｐ２２）  管理サーバＡは，新管理サーバＹに対し，資源管理の承認を通知するとともに，資源の管理情報を送信する。
【００９４】
（Ｐ２３）  以降，管理サーバＡは，新管理サーバＹから転送終了の依頼があるまで，サーバＢ〜Ｄから管理サーバＡに到着したその資源に対する処理要求を新管理サーバＹに転送する。
【００９５】
（Ｐ２４）  新管理サーバＹは，資源管理情報を取得したなら，資源管理を開始し，サーバＢ〜Ｄに対して管理サーバの移行を通知する。
【００９６】
（Ｐ２５）  サーバＢ〜Ｄは，移行通知を受け取ったら，管理サーバＡに対して確認通知を発行し，通知以降，その資源に関しては新管理サーバＹに処理要求を発行するようにする。
【００９７】
（Ｐ２６）  管理サーバＡは，サーバＢ〜Ｄから確認通知を受け取ったら，新管理サーバＹへの処理要求の転送を終了する。
【００９８】
図２３は，第２の管理方式における処理フローチャートである。ある資源に対する新管理サーバは，現在の管理サーバに対して，資源管理情報の取得と自サーバへの資源管理処理の移行を依頼する（ステップＳ２１１）。現在の管理サーバは，新管理サーバに対し，移行の承認と資源管理情報を送信する。以降，他のサーバから管理サーバにその資源に対する処理要求が到着した場合，その処理要求を新管理サーバに転送する（ステップＳ２１２）。
【００９９】
新管理サーバは，資源管理情報を取得したら，資源管理処理を開始し，他のサーバに対して管理サーバの移行を通知する（ステップＳ２１３）。他のサーバは，移行通知を受け取ったら，旧管理サーバに対して確認通知を発行する。以降は，その資源に関しては新管理サーバに処理要求を発行する（ステップＳ２１４）。旧管理サーバは，管理するすべてのサーバから確認通知を受け取ったら，新管理サーバへの処理要求の転送を終了する（ステップＳ２１５）。
【０１００】
〔第３の管理方式〕
ある管理サーバをシステムから削除する場合，これまで削除する管理サーバが管理していた資源は別のサーバに移行させる必要がある。そのための第３の管理方式の手順では，第２の管理方式の手順により資源の管理を新たな管理サーバへ移行し，その後に旧管理サーバを削除することにより，システムを停止することなく管理サーバを削除できるようにする。この手順の例を，図２２を用いて説明するが，（Ｐ２１）〜（Ｐ２５）までの処理は，第２の管理方式の処理と同様であるので説明を省略する。
【０１０１】
（Ｐ２６’）  管理サーバＡは，サーバＢ〜Ｄから管理サーバ移行の確認通知を受け取ったら，転送処理を終了し，サーバＢ〜Ｄに対して自サーバの削除を依頼する。サーバＢ〜Ｄ上において，サーバ一覧テーブルから旧管理サーバＡが削除され，処理が完了する。
【０１０２】
図２４は，第３の管理方式における処理フローチャートである。図２４のフローチャートのステップＳ２２１〜Ｓ２２４までの処理は，図２３の処理フローチャートのステップＳ２１１〜Ｓ２１４と同様であるので，説明を省略する。
【０１０３】
ステップＳ２２５で，旧管理サーバは，管理するすべてのサーバから確認通知を受け取ったら，転送処理を終了し，各サーバに対して自サーバの登録削除を依頼する。各サーバは，旧管理サーバの登録を削除し，処理を完了する（ステップＳ２２６）。
【０１０４】
〔第４の管理方式〕
複数のサーバがそれぞれ登録された二つのドキュメント分散処理システムを統合し，一つのシステムにする場合を考える。その際，資源に共通の管理サーバを変更する場合（例えば，各システムで別々に設定していた管理サーバを一つにする場合）には，第２の管理方式と同様の移行処理が必要になる。図２５にその手順を示す。
【０１０５】
図２５は，第４の管理方式の手順の例を示す図である。図２５では，システムＳとシステムＴとを統合し，システムＴにおいて管理サーバＡが管理していた資源の管理を，管理サーバＡから新管理サーバＹに移行する場合の例を示している。
【０１０６】
（Ｐ３１）  新管理サーバＹは，資源管理処理の移行を管理サーバＡに依頼申請する。
【０１０７】
（Ｐ３２）  管理サーバＡは，移行の承認を通知するとともに，資源管理情報および管理サーバＡに登録されているシステムＴのサーバ一覧テーブルを新管理サーバＹに送信する。
【０１０８】
（Ｐ３３）  以降，管理サーバＡは，その資源に対するサーバＢ，Ｃからの処理要求を新管理サーバＹに転送する。
【０１０９】
（Ｐ３４）  新管理サーバＹは，システムＳおよびＴを統合した新サーバ一覧テーブルおよび管理サーバの移行通知を，サーバＢ，Ｃ，Ｚに配送する。
【０１１０】
（Ｐ３５）  サーバＢ，Ｃ，Ｚは，サーバ一覧テーブルと移行通知を受け取ったら，自サーバのサーバ一覧テーブルを更新し，管理サーバＡに対して確認通知を発行する。以降その資源に関しては新管理サーバＹに要求を発行するようにする。管理サーバＡは，サーバＢ，Ｃ，Ｚから確認通知を受け取ったら，新管理サーバＹへの処理要求の転送を終了する。
【０１１１】
図２６は，第４の管理方式における処理フローチャートである。新たに統合システムの管理サーバとなる管理サーバ（新管理サーバという）は，管理処理の移行を他のシステムの管理サーバ（旧管理サーバという）に依頼する（ステップＳ２３１）。旧管理サーバは，移行の承認と資源管理情報および旧管理サーバに登録されているサーバ一覧を新管理サーバに送信する。以降，旧管理サーバは，その資源に対する処理要求を新管理サーバに転送する（ステップＳ２３２）。
【０１１２】
新管理サーバは，統合するシステムに登録されている新サーバ一覧および管理サーバの移行通知を各サーバに送信する（ステップＳ２３３）。各サーバは，新サーバ一覧と移行通知を受け取ったら，自サーバのサーバ一覧を更新し，旧管理サーバに対して確認通知を発行する。以降，その資源に関しては新管理サーバに処理要求を発行する（ステップＳ２３４）。旧管理サーバは，すべてのサーバから確認通知を受け取ったら，新管理サーバへの処理要求の転送を終了する（ステップＳ２３５）。
【０１１３】
次に，文書を互いに共有するような業務に本発明を適用した実施例を説明する。まず，文書を互いに共有するような業務を行うシステムにサーバｘを追加する場合を図２７を用いて説明する。
【０１１４】
初期状態では，サーバａ，ｂ，…，ｉ，…ｎは，それぞれ文書１（版：１），文書２（版：１），文書３（版：１）を持ち，サーバｘは，未登録の時点では何も文書を持っていない。
【０１１５】
はじめに，サーバｘは，サーバａに対し，サーバ一覧（テーブル）と文書データを要求する。サーバａは，要求を受け取った時点で，サーバｘへの複製文書の転送処理を開始し，サーバｘにサーバ一覧とサーバａが持っている文書データを配布する。この間，サーバｘは，他のサーバｂ，…，ｉ，…ｎに登録されていないので，サーバｉで文書１を第２版に改版したとすると，文書１（２版）は，直接サーバｘには届かないが，本発明では，サーバａは配布された文書１（２版）をサーバｘに転送するので，サーバｘは，これをサーバａ経由で受け取ることができる。
【０１１６】
サーバｘは，サーバａからサーバ一覧と文書データを受け取ったら，サーバａ，ｂ，…，ｉ，…ｎに対してサーバｘの登録を依頼する。サーバａ，ｂ，…，ｉ，…ｎにおいて，サーバｘがサーバ一覧に登録されると，以後各自のサーバで改版した文書は，サーバｘに対しても配送されるようになる。これ以降に，サーバｉが，文書２を更新して２版にしたときには，サーバｘは，文書２（２版）の複製を直接サーバｉからの配送によって取得することができる。
【０１１７】
サーバａ，ｂ，…，ｉ，…ｎは，サーバｘに対して登録完了を通知する。サーバｘは，すべてのサーバで登録完了されたことを確認したら，サーバａに対して転送処理の終了を依頼する。すべての処理完了後，サーバｘを含めた各サーバは，文書１（１版，２版），文書２（１版，２版），文書３（１版）を所有しており，保有する文書の一貫性が保たれることになる。
【０１１８】
次に，それぞれ自システムにおける文書を共有するシステムＳとシステムＴが独立して稼働している状態で，システムＳとシステムＴとを統合し，同時に統合後の全体の管理サーバをサーバＳａに統一する場合の例を，図２８を用いて説明する。
【０１１９】
まず，システムＳのサーバＳａは，改版管理処理の移行をシステムＴのサーバＴａに依頼する。サーバＴａが，文書の管理情報およびシステムＴに登録されているサーバの一覧（Ｔａ，Ｔｂ，…，Ｔｉ，…，Ｔｍ）を，サーバＳａに送信する。サーバＴａは，以降，文書の改版要求をサーバＳａに転送する。この時点で，サーバＴｉが，文書４を１版から２版に改版したい場合には，サーバＴｉは，サーバＴａに改版要求を発行するが，この要求はサーバＴａによりサーバＳａに転送され，サーバＳａが要求を処理する。
【０１２０】
サーバＳａは，管理情報とサーバ一覧を受け取ったら，サーバＳａ，Ｓｂ，…，Ｓｉ，…，ＳｎとサーバＴａ，Ｔｂ，…，Ｔｉ，…，Ｔｍとを統合した新たなサーバ一覧を作成し，この新サーバ一覧と改版管理サーバのサーバＳａへの移行通知を，サーバＳａ，Ｓｂ，…，Ｓｉ，…，ＳｎとサーバＴａ，Ｔｂ，…，Ｔｉ，…，Ｔｍに送信する。
【０１２１】
各サーバは，サーバ一覧と移行通知を受け取ったら，自サーバのサーバ一覧を更新し，サーバＴａに対して確認通知を発行し，以降，その資源に関してはサーバＳａに要求を発行するようにする。この時点以降にサーバＴｉが文書を更新しても，改版要求は，サーバＳａに直接送られるようになる。サーバＴａは，サーバＳａ，Ｓｂ，…，Ｓｉ，…，Ｓｎの全サーバから確認通知を受け取ったら，処理要求のサーバＳａへの転送を終了する。
【図面の簡単な説明】
【０１２２】
【図１】本発明の原理説明図である。
【図２】本発明によるサーバ管理のための構成を説明する図である。
【図３】文書の複製と配布を説明する図である。
【図４】送信処理および受信処理の処理フローチャートである。
【図５】第１の処理方式の手順の例を示す図である。
【図６】第１の処理方式における処理フローチャートである。
【図７】第２の処理方式の手順の例を示す図である。
【図８】第２の処理方式における処理フローチャートである。
【図９】第３の処理方式における文書の実装形態の例を示す図である。
【図１０】第３の処理方式を説明する図である。
【図１１】最新の実体の取得処理の処理フローチャートである。
【図１２】第４の処理方式を説明する図である。
【図１３】第４の処理方式における処理フローチャートである。
【図１４】多重更新が発生する場合の例を示す図である。
【図１５】第５の処理方式の手順の例を示す図である。
【図１６】第５の処理方式における処理フローチャートである。
【図１７】通信途絶が発生した場合の手順の例を示す図である。
【図１８】第６の処理方式によるタイムアウトが発生した場合の処理フローチャートである。
【図１９】サーバ一覧テーブルの構成例を示す図である。
【図２０】第１の管理方式の手順の例を示す図である。
【図２１】第１の管理方式における処理フローチャートである。
【図２２】第２および第３の管理方式の手順の例を示す図である。
【図２３】第２の管理方式における処理フローチャートである。
【図２４】第３の管理方式における処理フローチャートである。
【図２５】第４の管理方式の手順の例を示す図である。
【図２６】第４の管理方式における処理フローチャートである。
【図２７】文書を互いに共有するような業務を行うシステムにサーバｘを追加する場合の実施例を示す図である。
【図２８】それぞれ文書を共有するような業務を行うシステムＳとシステムＴとを統合する場合の実施例を示す図である。
【符号の説明】
【０１２３】
１ａ，１ｂ，１  メッセージ処理手段
２ａ，２ｂ，２  メッセージ通信手段
３ａ，３ｂ，３  レポジトリ管理手段
４ａ，４ｂ  版数管理手段
５ａ，５ｂ  ロック管理手段
６ａ，６ｂ  時刻監視手段
７ａ，７ｂ，７  ユーザインタフェース（ＵＩ）
１０ａ，１０ｂ，１０  サーバ
２０ａ，２０ｂ  レポジトリ
３０ａ，３０ｂ  クライアント
４０  ネットワーク
５１  サーバ登録手段
５２  サーバ削除手段
５３  管理サーバ変更手段
５４  システム統合手段
５５  サーバ一覧テーブル
【図１】
2005032270.tif 000003
【図２】
2005032270.tif 000004
【図３】
2005032270.tif 000005
【図４】
2005032270.tif 000006
【図５】
2005032270.tif 000007
【図６】
2005032270.tif 000008
【図７】
2005032270.tif 000009
【図８】
2005032270.tif 000010
【図９】
2005032270.tif 000011
【図１０】
2005032270.tif 000012
【図１１】
2005032270.tif 000013
【図１２】
2005032270.tif 000014
【図１３】
2005032270.tif 000015
【図１４】
2005032270.tif 000016
【図１５】
2005032270.tif 000017
【図１６】
2005032270.tif 000018
【図１７】
2005032270.tif 000019
【図１８】
2005032270.tif 000020
【図１９】
2005032270.tif 000021
【図２０】
2005032270.tif 000022
【図２１】
2005032270.tif 000023
【図２２】
2005032270.tif 000024
【図２３】
2005032270.tif 000025
【図２４】
2005032270.tif 000026
【図２５】
2005032270.tif 000027
【図２６】
2005032270.tif 000028
【図２７】
2005032270.tif 000029
【図２８】
2005032270.tif 000030