JP2005032270A - ドキュメント分散処理システムのサーバ管理方法およびサーバプログラムの記録媒体 - Google Patents

Abstract

【課題】ネットワーク上の複数のサーバ間において同一のオンラインドキュメントを共有し，かつ，どのサーバにおいても参照・更新を可能とするようなマルチサーバによるドキュメント分散処理システムの環境において，同期によって他の処理が待たされることなく，かつ，一貫性を保持しながらサーバの追加，変更を行うことを可能とする。
【解決手段】サーバ１０のサーバ登録手段５１が，システムへの新規サーバの登録依頼があった場合に，依頼された時点における共有ドキュメントの複製を，新規サーバへ配送する処理を行うとともに，その後に更新されたドキュメントのデータの新規サーバへの配送を，全サーバへの新規サーバの登録が完了するまで代行する処理を行う。
【選択図】図２

Description

複数拠点（サーバ）における事務系，開発系の業務などで，各拠点間で同一のドキュメント（文書）を互いに参照・更新することがある。ドキュメントがオンライン上のファイルであるような場合には，単一の文書を転送するか，同一内容の文書を複数のサイトで共有する方法がある。

本発明は，同一内容の文書を複数のサイトで共有する方式に係り，特に，マルチサーバ環境においてサーバを追加登録，または変更する場合のドキュメント分散処理システムのサーバ管理方法およびサーバプログラムの記録媒体に関する。

従来，複数拠点間で文書を共有する技術として，以下の方法がある。
（１）ワークフロー等を利用し，単一の文書を拠点間で転送する方法。
（２）同一文書の複製を拠点間で保有し，複製された文書に対し参照・更新を行う方法。

後者の（２）に示す同一文書の複製を拠点間で保有する方法の場合には，複数の拠点で同一文書に関する更新が発生し，内容の異なる文書が複数存在する可能性があるが，この対処方法として，以下の方法がある。
（２−ａ）更新可能な拠点を１箇所に限定し，他の拠点では更新を禁止する方法。
（２−ｂ）複数の拠点での更新を許可し，複製を統合する際に何らかの手段で文書間の差異の修正を行う方法。

また，従来のマルチサーバによる資源管理の技術は，マスタ・スレーブ方式のような集中型のものがほとんどであった。マスタ・スレーブ方式のシステムに新しいサーバを登録する場合には，マスタに相当するサーバに登録を依頼し，依頼されたマスタサーバは，新しいサーバに資源を配布できるようにするための変更を行い，トランザクション中の制御も１箇所で実行していた。

なお，ネットワーク上の複数のサーバ間において同一のデータを共有し，かつ，どのサーバにおいても参照・更新を可能とするシステムについて，例えば下記の特許文献１に記載されている。
特開平９−２４４９３５号公報

従来の（１）に示す方法は，文書を更新する手順が拠点間で予め決定されている場合には問題がないが，複数拠点で任意に参照・更新を行う必要があるような非定型業務の場合には不適である。

また，（２−ａ）に示す方法は，更新を行える拠点が限定されているため，やはり自由に更新を行うことができないという問題がある。

（２−ｂ）に示す方法は，多重更新が頻繁に発生してしまうことが問題であり，多重更新により生じてしまった差異を解決する手段として一般に有効な方法がない。

また，従来のマスタ・スレーブ方式のシステムの場合には，新しいサーバの追加，既存のサーバの削除などが必要となったとき，特定の１箇所でサーバの登録変更が行われるため，管理情報の一貫性の保持についての問題は発生しなかった。しかし，ネットワーク上の複数のサーバ間において同一のオンラインドキュメントを共有し，かつ，どのサーバにおいても参照・更新を可能とするようなドキュメント分散処理システムは，マスタに相当するデータやトランザクションを一括管理するサーバは存在せず，すべてのサーバが対等に存在し，自由にサーバの追加変更が行えるマルチサーバ環境であることが望ましい。

このような各サーバが対等なマルチサーバ環境では，任意の箇所でのサーバ変更が発生することがあるために，サーバごとにサーバの登録状態の不整合が発生するという問題がある。サーバ登録の不整合があると，資源に関する更新処理が失敗したり，生成されたドキュメントが届かないことが起こる。これを回避するためには，ドキュメントを参照，更新するシステムのサービスを一旦止めて，全サーバで同期的にサーバを追加・削除するなどの必要があり，その間におけるサービス性が著しく阻害される。

本発明は上記問題点の解決を図り，サービス性のよいドキュメント分散処理システムを実現することを目的とする。特に，本発明は，各サーバが対等なマルチサーバ環境でも，同期のためのサービスの中断によって，他の処理が待たされることがないようにすること，かつ，一貫性を保持しながらサーバの追加，変更を可能にすることを目的とする。また，本発明に関連する発明は，複数の拠点における任意の更新を許容するが，１箇所の拠点で更新を行っている間のみ，他の拠点では更新を許可しない方式によって，多重更新の発生頻度を減少させ，かつ更新の際のロック要求に関する待機時間を短縮するような方式を提供することを目的とする。

図１は，本発明の原理説明図である。図１において，ネットワーク４０で結ばれた複数の拠点には，それぞれ，サーバ１０ａ，１０ｂと，レポジトリ２０ａ，２０ｂ，サーバに接続するクライアント３０ａ，３０ｂが存在する。各拠点はサーバ・クライアント構成になっている。

メッセージ処理手段１ａ，１ｂは，他サーバへ送信するメッセージの作成，および他サーバから到着したメッセージの処理を行う手段である。本システムでは，ドキュメントの論理オブジェクト（ドキュメントのメタ情報）および実体もメッセージに変換して配送するので，メッセージ処理手段１ａ，１ｂは，配送の際にオブジェクト／ファイルからメッセージへの変換および配送されてきたメッセージからオブジェクト／ファイルへの復元も担当する。

メッセージ通信手段２ａ，２ｂは，他サーバへのメッセージ送信および他サーバからのメッセージ受信を担当する手段である。

レポジトリ管理手段３ａ，３ｂは，レポジトリ２０ａ，２０ｂに格納されている論理オブジェクトや実体の参照，検索，更新等を行う。版数管理手段４ａ，４ｂ，は，ドキュメントの版管理を担当する。ロック管理手段５ａ，５ｂは，ドキュメントのロック，ロック解除，ロック状態の管理を担当する。

時刻監視手段６ａ，６ｂは，メッセージ通信のタイムアウト発生および定期レプリケーション時刻の通知を，メッセージ処理手段１ａ，１ｂに対して行う。ユーザインタフェース（ＵＩ）７ａ，７ｂは，利用者からのドキュメントの参照，更新操作を受け付ける手段である。

レポジトリ２０ａ，２０ｂは，ドキュメントの実体ファイルや論理オブジェクトを格納する記憶手段である。例えば，データベースに類似する構造を持つ格納領域を持つ。クライアント３０ａ，３０ｂは，文書を編集・参照するドキュメントアプリケーションを持つ。

本発明では，同一ドキュメント（文書）が各サーバに配置される。あるサーバ１０ａで生成・更新されたドキュメントの内容は，ネットワーク４０を介して他のサーバ１０ｂが持つドキュメントに反映される。

図２は，本発明によるサーバ管理のための構成を説明する図である。図１に示す各サーバ１０ａ，１０ｂ，…のメッセージ処理手段１は，サーバの登録，削除，ドキュメントの管理情報を管理するサーバの変更，複数のシステムの統合のために，図２に示すように，サーバ登録手段５１，サーバ削除手段５２，管理サーバ変更手段５３，システム統合手段５４を持つ。サーバ一覧テーブル５５は，システムに登録されているサーバの情報を保存するテーブルである。

サーバ登録手段５１は，システムへの新規サーバの登録依頼があった場合に，依頼された時点における共有ドキュメントの複製を，新規サーバへ配送する処理を行うとともに，その後に更新されたドキュメントのデータの新規サーバへの配送を，全サーバへの新規サーバの登録が完了するまで代行する処理を行う。

また，サーバ削除手段５２は，自サーバをシステムから削除する場合に，自サーバのレポジトリ管理手段３が管理するドキュメントの管理情報を，管理を引き継ぐサーバに対して配送する処理と，そのドキュメントの管理情報に対する他のサーバからの要求を，管理を引き継ぐ管理サーバに対して転送する処理と，管理を引き継ぐ管理サーバからの引き継ぎの確認後に他のサーバに対して自サーバの削除を依頼する処理とを行う。また，サーバ削除手段５２は，自サーバが他のサーバからドキュメントの管理情報の管理を引き継ぐ場合に，そのドキュメントの管理情報を取得した後，レポジトリ管理手段３によりその管理情報の管理を開始し，他のサーバに対して管理サーバの移行を通知する処理を行う。

管理サーバ変更手段５３は，あるドキュメントの管理情報を管理する機能を他のサーバに移行するとき，移行するドキュメントの管理情報を移行先の管理サーバへ配送する処理と，そのドキュメントの管理情報に対する他のサーバからの要求を，移行先の管理サーバに対して転送する処理とを行う。さらに，自サーバが管理移行先のサーバとなるときには，移行元のサーバからドキュメントの管理情報を取得した後，レポジトリ管理手段３によりその管理情報の管理を開始し，他のサーバに対して管理サーバの移行を通知する処理を行う。

システム統合手段５４は，それぞれ別々にオンラインドキュメントを共有する複数のシステムを一つに統合するために，自サーバのレポジトリ管理手段３が管理する自システムにおけるドキュメントの管理情報の管理機能を，他のシステムにおける管理サーバに変更するにあたって，自システムのドキュメントの管理情報を，他のシステムにおける管理サーバへ配送する処理と，そのドキュメントの管理情報に対する他のサーバからの要求を，前記他のシステムにおける管理サーバに対して転送する処理とを行う。さらに，自サーバが他のシステムの管理サーバからドキュメントの管理情報の管理機能を引き継ぐ場合には，そのドキュメントの管理情報を取得した後，その管理情報の管理を開始し，他のサーバに対して管理サーバの移行を通知する処理を行う。

以上の各処理手段をサーバの計算機によって実現するためのプログラムは，計算機が読み取り可能な可搬媒体メモリ，半導体メモリ，ハードディスクなどの適当な記録媒体に格納することができる。

本発明のドキュメント分散処理システムのサーバ管理方法によれば，ネットワーク上の複数のサーバ間において同一のオンラインドキュメントを共有し，かつ，どのサーバにおいても参照・更新を可能とするようなマルチサーバによるドキュメント分散処理システムの環境において，同期によって他の処理が待たされることなく，かつ，一貫性を保持しながらサーバの追加，変更を行うことができる。

以下に，本発明の実施の形態を説明する。はじめに，本発明に関連するドキュメント分散処理方法の実施の形態を説明する。

本実施の形態を説明する前提として，遠隔の拠点間で文書を相互に共有するような業務を行う場合を例とする。

各拠点には，コンピュータと，ファイルや論理オブジェクトを格納可能なレポジトリ（データベース）と，サーバアプリケーションが存在する。レポジトリは，文書（ドキュメント）を版（バージョン）管理し，版ごとに文書を格納できる機能を持つ。また，拠点はすべてネットワークに接続されており，任意の拠点間でメッセージ通信，ファイルや論理オブジェクトの転送が可能である。各拠点は，サーバ・クライアント構成になっており，クライアントには文書を編集・参照するドキュメントアプリケーションが実装されている。

図３は，このようなシステムにおける文書の複製と配布を説明する図である。図３に示すように，同一文書を複製したものを各サーバＡ，Ｂ，Ｃに配置する。サーバＡまたはサーバＡに接続されているクライアントにより文書１を生成または更新した場合には，サーバＡは，ネットワークで結ばれた他のサーバＢ，Ｃに対し文書１の複製を送信する。

図４は，送信処理および受信処理の処理フローチャートである。送信処理では，図４（Ａ）に示すように，文書を作成・更新したサーバは，文書を複製し（Ｓ１０１），その複製を他のサーバに送信する（Ｓ１０２）。受信処理では，図４（Ｂ）に示すように，サーバは複製を受信し（Ｓ１０３），複製を自己の文書に反映させる（Ｓ１０４）。なお後述するが，文書の複製は，文書の実体を複製する以外に，文書に関するメタ情報である論理オブジェクトのみを複製してもよい。

〔第１の処理方式〕
第１の処理方式では，サーバは更新開始時に他のサーバに対して，更新開始を通知する。他のサーバは更新開始通知を受けとった時点でその文書をロックする。ロックされた文書は，ロックが解除されるまでそのサーバでは更新不可能になる。更新を完了したサーバは，他のサーバに更新後の文書を配布する。他のサーバは，配布された文書を受け取った時点でロックを解除し，更新結果を自己の文書に反映させる。

図５は，第１の処理方式の手順の例を示す図である。サーバＡは，クライアントからの更新開始を契機に，他のサーバＢ，Ｃに対して，ロック要求を含む更新開始通知を送信する。他のサーバＢ，Ｃは，更新開始通知を受信した時点でその文書をロックし，ロック完了通知をサーバＡに返信する。

その後，更新を終了したサーバＡはその文書のロックを解除し，他のサーバＢ，Ｃに対して更新後の文書（更新文書）を配布する。他のサーバＢ，Ｃは，更新文書を受信した時点で文書のロックを解除し，自サーバの文書に更新結果を反映させる。

図６は，第１の処理方式における処理フローチャートである。図６（Ａ）に示す送信処理においては，クライアントが文書更新の開始を宣言すると（Ｓ１１０），他のサーバに対してロック要求を含む更新開始通知を送信する（Ｓ１１１）。他のサーバからのロック完了通知を受信し（Ｓ１１２），その後に文書を更新し（Ｓ１１３），その文書の論理オブジェクトまたは実体の複製を他のサーバへ送信する（Ｓ１１４）。

図６（Ｂ）に示す受信処理においては，文書更新を開始したサーバからロック要求を含む更新開始通知を受信すると（Ｓ１１５），文書をロックし（Ｓ１１６），直ちにロック完了通知を送信する（Ｓ１１７）。続いて，文書の論理オブジェクトまたは実体の複製を受信し（Ｓ１１８），文書のロックを解除する（Ｓ１１９）。

〔第２の処理方式〕
上記第１の処理方式では，他のすべてのサーバＢ，Ｃでロックが行われ，その結果として返される結果（ロック完了通知）を確認した後に，更新開始の許可を利用者（クライアント）に与えているため，通信に時間を要するような環境では，利用者が更新開始を宣言してから実際に更新処理を始めるまで，かなりの時間待たされることになる。

第２の処理方式では，この点を改良し，文書を更新するサーバは，他サーバからのロック完了通知の受信を待たずに，自サーバのクライアントに更新を許可し，ロックの正否（他サーバからの更新承認）の判定は更新終了まで延期する。これにより，クライアントは，更新を先行的に実行することができ，時間の短縮が可能になる。

図７は，第２の処理方式の手順の例を示す図である。サーバＡは，クライアントから更新開始の依頼を受けると，サーバＢおよびサーバＣに対しロック要求を含む更新開始通知を送信した後，直ちにクライアントに更新開始ＯＫを出して更新を許可する。サーバＢ，Ｃは，ロック要求を含む更新開始通知を受信して，該当する文書をロックし，ロック完了通知をサーバＡに返す。

サーバＡでは，更新終了までに他サーバからのロック完了通知を受信し，他サーバＢ，Ｃによる更新承認の判定を行い，更新を終了する。もし，更新終了までの間に，他サーバＢ，Ｃからロック完了通知を受信しなかった場合には，クライアントによる文書の更新を無効にして文書を更新開始前の状態に戻すか，またはその文書をローカル版として保存し，処理を終了する。

図８は，第２の処理方式における処理フローチャートである。図８（Ａ）に示す送信処理においては，クライアントが文書更新の開始を宣言すると（Ｓ１２０），他のサーバに対してロック要求を送信して（Ｓ１２１），直ちに文書更新を許可する（Ｓ１２２）。更新が終了するまでの間に，他のサーバからのロック完了通知を受信し，他のすべてのサーバからロック完了通知を受信したなら（Ｓ１２３），更新された文書の実体または論理オブジェクトの複製を他のサーバに送信する（Ｓ１２４）。

図８（Ｂ）に示す受信処理においては，文書更新を開始したサーバからロック要求を受信し（Ｓ１２５），その文書をロックし（Ｓ１２６），ロック完了通知を要求元のサーバへ送信する（Ｓ１２７）。文書を更新したサーバから，文書の実体または論理オブジェクトの複製を受信したなら（Ｓ１２８），それを自サーバ内の文書に反映し，ロックを解除する（Ｓ１２９）。

〔第３の処理方式〕
文書を共有するシステムにおいて，いずれかのサーバで文書が新規作成・更新された場合には，更新内容を他のサーバに反映させる必要があるが，更新のたびに文書内容の転送を行う方法では，ファイルサイズが大きい場合やサーバ間の通信に時間がかかる場合には通信の負荷が問題となる。

第３の処理方式では，各サーバにおける文書を，文書の実体である文書ファイル（以下，実体ファイルという）そのものと，文書に関する情報（実体ファイルへのリンク，文書名，作成者，作成日付，版数等）のみで構成される論理オブジェクトとの二つに分離して実装する。図９は，文書の実装形態の例を示す図である。

クライアントから参照・更新のために文書を利用する場合には，論理オブジェクトを経由して実体ファイルの取得を行う。

また，文書を論理オブジェクトと実体ファイルとに分離して実装することで，文書の新規作成時や更新時には，文書実体を配布せずに論理オブジェクトのみを配布し，実体ファイルは，通常更新が発生しない時間帯や通信負荷が小さい時間帯などを指定しておき，定期的に配布する。

図１０は，第３の処理方式を説明する図である。サーバＡで文書を新規作成または更新すると，図１０（Ａ）に示すように，他のサーバＢ，Ｃに対しては，更新後の論理オブジェクト（新）のみを複製して即時に配布する。更新後の文書の実体ファイル（新）は，直ちに送ることはしないで，図１０（Ｂ）に示すように，通常，更新が発生しない時間帯などに定期的に複製して配布を行う。

さらに，論理オブジェクトに，最新実体の保有の有無，最新実体を保有するサーバの識別子の情報を追加することもできる。

図１１は，最新の実体の取得処理の処理フローチャートである。利用者が更新を開始するなど，最新の文書の実体が必要な場合には，自サーバの持つ論理オブジェクトに対し，最新実体の有無を問い合わせる（Ｓ１３０，Ｓ１３１）。自サーバが最新の実体ファイルを保有していない場合には，論理オブジェクトより最新の実体ファイルを保有するサーバの識別子を得て，そのサーバに最新の実体ファイルを要求し，必要な最新の実体ファイルを転送してもらい（Ｓ１３２），文書処理を行う（Ｓ１３３）。自サーバが最新の実体ファイルを保有している場合には，その実体ファイルを使用して文書処理を行う（Ｓ１３３）。

〔第４の処理方式〕
複数のサーバが同時に更新を開始した場合，互いに文書のロックができないため，個々のサーバでそれぞれ更新が行われてしまう。そこで，同一文書に対するロック要求が複数のサーバから発生した場合には，いずれかのロックを有効にするために，各サーバにあらかじめ異なる優先度を設定し，文書をロックする際に，ロックを要求した（更新の発生した）サーバの優先度を同時に記録する。このため，他のサーバに対してロックを要求する場合には，優先度情報を付加して送信する。

ロックを要求されたサーバでは，既にその文書がロック状態である場合，ロックを要求したサーバの優先度を比較する。もし，新しくロックを要求したサーバの優先度がロック中のサーバの優先度よりも高い場合には，現在のロックをキャンセルし，新たに到着したロック要求を実行する。新しくロックを要求したサーバの優先度がロック中のサーバの優先度よりも低い場合には，現在のロックを優先し，新たに到着したロック要求を拒絶する。

図１２は，第４の処理方式を説明する図である。サーバＡ，Ｂ，Ｃにおいて，サーバＡの優先度がサーバＢの優先度より高いとする。図１２（Ａ）に示すように，サーバＣにおいてサーバＢからの依頼による文書ロック状態である場合に，サーバＡからのロック要求が到着したときには，サーバＡの優先度がサーバＢの優先度より高いため，サーバＣは，現在のサーバＢによる文書ロックをキャンセルし，到着したサーバＡによるロック要求を実行する。

一方，図１２（Ｂ）に示すように，サーバＣにおいてサーバＡからの依頼による文書ロック状態である場合に，サーバＢからのロック要求が到着したときには，既に優先度の高いサーバＡによる文書ロックがされているのでこれを優先し，サーバＣは，サーバＢからのロック要求を却下する。

図１３は，第４の処理方式における処理フローチャートである。あるサーバが，文書ロック状態であり（Ｓ１４０），他のサーバからロック要求を受信したなら（Ｓ１４１），受信したロック要求の要求元のサーバの優先度と，現在のロックを要求したサーバの優先度とを比較し（Ｓ１４２），要求元サーバの優先度が現ロックの要求元サーバの優先度より高い場合には，現在の文書ロックをキャンセルし，受信したサーバのロック要求を実行する（Ｓ１４３）。受信したサーバの優先度が現ロックの要求元のサーバの優先度より高くない場合には，受信したロック要求を却下する（Ｓ１４４）。

〔第５の処理方式〕
前述した処理方式では，先行的に更新を行うことを許容しているため，更新に要する時間が短い等の原因で，図１４に示すように多重更新が発生してしまう可能性がある。この場合，同じ版に更新してしまうと，同一の版で異なる内容の文書が存在してしまうという問題が発生する。

そこで，各サーバ単位に独自の版体系を設定し，配布された版から分枝できるようにする。そして，サーバの優先度に対応して版体系に優先度を設定し，このうち最も優先度の高い版体系をそのシステムにおける正式版とする。

図１５は，第５の処理方式の手順の例を示す図である。まず，サーバＢは，文書の更新時に，他のサーバであるサーバＣに対してロック要求を送信するともに，そのシステムで最も優先度の高いサーバＡに対して正式版の改版申請を送信する。同様に，サーバＣも文書を更新するときには，他のサーバＢにロック要求を送信し，サーバＡに対して改版申請を送信する。

サーバＡでは，改版申請された文書がロックされていなければ，先に到着したサーバＢの改版申請に対して改版承認のメッセージを返送する。改版承認を既に発行した後に届いたサーバＣの改版申請に対しては，改版却下のメッセージを返送する。

改版承認を受け取ったサーバＢは，他のサーバＡ，Ｃに対して承認された新版の実体または論理オブジェクト（以下，文書オブジェクトという）を複製し配布することにより，改版を行う。これにより，サーバＢにおいて更新された文書１の正式な版数は「Ａ−２」となる。

サーバＡでは，サーバＢから配布された新版文書オブジェクト（文書１，版：Ａ−２）を正式版とする。また，改版申請を却下されたサーバＣでは，文書更新が取り消され，サーバＢから配布された新版文書オブジェクト（文書１，版：Ａ−２）を正式版とする。ここで，サーバＣ内で文書１（版：Ｃ−２）の更新が完了していた場合には，この文書１（版：Ｃ−２）は，サーバＣのローカル版文書として保存される。

図１６は，第５の処理方式の処理フローチャートである。更新サーバにおいては，図１６（Ａ）に示すように，文書更新を開始すると（Ｓ１５０），正式版を発行するサーバに対して改版申請を送信して（Ｓ１５１），文書を更新する（Ｓ１５２）。まず，自サーバにおける独自の版体系で改版し（Ｓ１５３），正式版を発行するサーバからの改版承認を受信するまで待機し（Ｓ１５４），改版承認を受信したなら，承認された正式版で改版を行う（Ｓ１５５）。

正式版を発行するサーバにおいては，図１６（Ｂ）に示すように，文書更新を開始したサーバから改版申請を受信すると（Ｓ１５６），既に他のサーバに改版承認を送信したかどうかを判断し（Ｓ１５７），既に改版承認を送信している場合には，新しい申請元のサーバに対し改版却下を送信し（Ｓ１５８），未だ改版承認を送信していない場合には，改版承認を送信する（Ｓ１５９）。

〔第６の処理方式〕
上述した第５の処理方式では，仮に最も優先度の高いサーバとの通信が途絶している場合に，ローカル版以外の改版が行えなくなってしまうという問題が生じる。そこで，改版申請を送信してから応答を受信するために待つ時間の限界（タイムアウト）を設定し，タイムアウトが発生した場合に，次に優先度の高いサーバに対して改版申請を再送信し，そのサーバにより改版承認が得られたときに，得られた版の文書オブジェクト（実体または論理オブジェクト）を複製し配布する。

図１７は，通信途絶が発生した場合の手順の例を示す図である。サーバＣが更新時に，システム内で優先度が最も高いサーバＡに対して改版申請を送信したにもかかわらず，そのサーバＡもしくは通信路の障害等によりその通信が途絶した場合には，サーバＣは，改版申請の応答に対するタイムアウトを検出し，次に優先度の高いサーバＢに対して改版申請を再送信する。サーバＢがサーバＣに対して改版承認を発行すると，サーバＣは，更新を完了した新版文書オブジェクト（版：Ｃ−２）を複製し，サーバＢに配布して改版を行う。

図１８は，第６の処理方式によるタイムアウトが発生した場合の処理フローチャートである。更新サーバにおいて，文書更新を開始すると（Ｓ１６０），正式版を発行するサーバに対して改版申請を送信して（Ｓ１６１），文書を更新する（Ｓ１６２）。自サーバにおける独自の版体系で改版し（Ｓ１６３），正式版を発行するサーバからの改版承認を受信したかどうかを判断する（Ｓ１６４）。改版承認を受信したなら，承認された正式版で改版を行う（Ｓ１６５）。改版承認を受信しないときにはタイムアウト発生まで待機して（Ｓ１６６），タイムアウト発生であれば，次の優先度のサーバに対し改版申請を送信して（Ｓ１６７），Ｓ１６４以下の処理を行う。なお，改版申請が却下された場合に，その文書を自サーバのみのローカル版文書として扱うことは，前述した第５の処理方式と同様である。

〔第７の処理方式〕
上述した第５および第６の処理方式においては，最も優先度の高いサーバに通信が集中する傾向がある。そこで，本方式では，負荷分散のために，各文書単位にサーバの優先度を設定する。これにより，文書ごとに最も優先度の高いサーバが分散されるので，通信の集中を回避することができる。

次に，遠隔地の３拠点において，文書を互いに共有するような業務に本発明を適用した実施例を説明する。

ネットワークで結ばれた拠点Ａ，Ｂ，Ｃでは，比較的大きなサイズの文書を扱い，文書の更新が行われる主な拠点は，文書の種類によってほぼ決まっているものとする。例えば「設計書」という種類の文書は，主に拠点Ａで更新され，拠点Ｂ，Ｃでも更新はされるが頻度は少ないものとする。

文書は，文書内容が格納された実体ファイルと論理オブジェクトとに分離して各拠点のリポジトリに格納される。各拠点には，サーバ，クライアントの装置が設置され，利用者はクライアントから各拠点にあるサーバに接続して作業を行う。クライアントからは文書の作成・登録，参照および編集が可能である。

サーバＡで「設計書」である文書１を新規作成した場合，サーバＢおよびサーバＣに対して文書１の論理オブジェクトが配布される。したがって，サーバＢ，Ｃの利用者は，クライアント上で新規生成された文書１の情報（文書名，作成者，作成日時，バージョン等）を論理オブジェクトから取得することができる。

ここで，文書の実体（ファイル）はサーバＢおよびサーバＣ上には送られていない。サーバＢ上で文書１を参照したい場合，利用者はクライアントから文書１の実体を要求する。そうすると，サーバＢは，サーバＡに対して実体の配布を要求し，サーバＡからサーバＢへ実体のコピーが行われる。コピーが完了するとクライアントを介して利用者に通知が行われる。

また，その日に作成された文書１は，１日１回，作業の少ない時間帯を指定して，すべてのサーバに対して一括して実体（ファイル）を配布するように設定する。したがって，前日に作成された文書は翌日以降にはどの拠点においても，配布要求を行わずに，直ちに取得することができる。

「設計書」はサーバＡで最も多く更新が行われるので，更新の優先度をサーバＡが最も高く，次いでサーバＢ，サーバＣの順とする。サーバＡは最も優先度が高いので，サーバＢ，サーバＣの利用者が先に更新を開始していても，後からサーバＡで同じ文書の更新が開始されたなら，サーバＢ，Ｃの利用者は，更新のキャンセルを要求される場合がある。

また，サーバＢ，サーバＣでは同じ１．０版から更新を行った場合，更新の終了直後ではサーバＢにおいては１．１／Ｂ版，サーバＣにおいては１．１／Ｃ版のようなそのサーバ固有の版（ローカル版）が生成される。その後，サーバＡからの２．０版への改版許可が得られた時点で，１．１／Ｂのようなローカル版は，グローバル版である２．０版に置き換えられる。なお，ローカル版はそのサーバにおいて保存される。

次に，本発明のドキュメント分散処理システムのサーバ管理方法の実施の形態を説明する。すべてのサーバが対等に存在し，自由にサーバの追加変更を行えるマルチサーバ環境を実現するために，以下に説明する管理方式を用いる。

図１９は，サーバ一覧テーブルの構成例を示す図である。サーバ一覧テーブルには，サーバ名，宛て先（アドレス），サーバの属性に関する情報を記憶する。サーバの属性には，例えばそのサーバがどのような管理情報を管理しているかなどの情報が含まれる。このサーバ一覧テーブルは，全サーバが同じ内容のものを保持し，各サーバ間の通信に用いられる。

〔第１の管理方式〕
各サーバがデータ（ドキュメント）の複製を共有し，任意のサーバでデータ更新が行えるようなマルチサーバシステムにおいて，サーバを登録する場合を考える。あるサーバで更新されたデータは，その複製が別のサーバに配送される。

もし，データが特定のサーバだけで更新されるのであれば，新規登録のサーバは，データの更新を管理するサーバからデータを取得すればよい。しかし，データが任意の箇所で更新される可能性があるので，あるサーバからデータを取得している間に他のサーバがデータを更新した場合には，登録した時にはその新しい更新データを取得することができず，その結果，サーバ間で所有するデータに差異が生じてしまうおそれがある。

本発明では，サーバの登録が完了し，新規サーバが他の全サーバからデータを受け取ることが確認されるまで，任意の登録されている１サーバを指定し，指定されたサーバが新規サーバへのデータの配送を代行するようにする。この手順を図２０に示す。

図２０は，第１の管理方式の手順の例を示す図である。

（Ｐ１１） 本システムへの追加登録を希望する新規サーバＸは，すでにシステムに登録されているサーバＡ〜Ｄの一つ（例えばサーバＡ）に，現時点で登録されているサーバの情報を持つサーバ一覧テーブルの送付と，現時点で共有されているデータの複製の配送および新たな更新データの配送代行を依頼する。

（Ｐ１２） サーバＡは，自己の持つサーバ一覧テーブルにサーバＸを追加登録し，そのサーバ一覧テーブルとデータを新規サーバＸに送信する。

（Ｐ１３） 以後，依頼されたサーバＡは，サーバＸから転送終了の依頼があるまで，他のサーバ（例えばサーバＢ）から自サーバに配送されてきたデータをすべて新規サーバＸに転送する。

（Ｐ１４） 新規サーバＸは，サーバ一覧テーブルをもとに，登録されているサーバＢ〜Ｄ（またはサーバＡ〜Ｄ）に対して，自サーバの登録を依頼する。

（Ｐ１５） サーバＢ〜Ｄは，新規サーバＸからの登録依頼を受け取った場合，新規サーバＸを自サーバが持つサーバ一覧テーブルに登録し，登録完了を新規サーバＸに通知する。この登録以降，サーバＢ〜Ｄは，新規サーバＸに対して直接更新されたデータを配送する。

（Ｐ１６） 新規サーバＸは，サーバＢ〜Ｄから登録完了通知を受け取ると，最初に配送の代行を依頼したサーバＡに対して，代行の終了を依頼する。代行を行っているサーバＡは，代行終了（転送終了）依頼を受け取ったら，新規サーバＸへの配送代行を終了する。

図２１は，第１の管理方式における処理フローチャートである。新規登録を希望する新規サーバは，現時点で登録されているサーバ一覧を任意のサーバより取得し（ステップＳ２０１），サーバ一覧に登録されているサーバの一つにデータ配送の代行を依頼する（ステップＳ２０２）。代行を依頼されたサーバは，自分に配送されたデータをすべて新規サーバに転送する（ステップＳ２０３）。

新規サーバは，サーバ一覧をもとに，登録されたサーバすべてに対して自サーバの登録を依頼する（ステップＳ２０４）。他のサーバは，新規サーバからの登録依頼を受け取ったら，新規サーバを自己のサーバ一覧に追加登録し，登録完了を通知する。以降，他のサーバは，新規サーバに対して更新したデータを配送する（ステップＳ２０５）。

新規サーバは，すべてのサーバから登録完了通知を受け取ったら，最初に配送代行を依頼したサーバに対して，配送代行の終了を依頼する（ステップＳ２０６）。代行を依頼されたサーバは，代行終了（転送終了）依頼を受け取ったら，新規サーバへの配送代行を終了する（ステップＳ２０７）。

〔第２の管理方式〕
マルチサーバ環境において，ある資源を管理するサーバを，他のサーバに変更する必要が生じることがある。ここで，ある資源の状態が，別のサーバによる資源の使用によって変更されるとすると，ある時点をもって一度に新しいサーバに資源管理を移行させなければならない。しかし，一般に，管理サーバの変更の認知には各サーバごとに時間的なずれが生じるので，新しい管理サーバへの処理要求と古い管理サーバに対する処理要求とが混在する時間帯が存在する。これらの要求は，一貫性を保持するためにどちらか一方のサーバで処理されることが必要になる。資源の状態とは，例えばドキュメントの版数などである。この問題を解決するための手順を図２２に示す。

図２２は，第２の管理方式の手順の例を示す図である。

（Ｐ２１） 現在，ある資源の管理を管理サーバＡが行っており，その管理を新管理サーバＹに移行するものとする。新管理サーバＹは，現在の管理サーバＡに対して，資源の管理情報の配送と，自サーバへの処理の移行の依頼を申請する。

（Ｐ２２） 管理サーバＡは，新管理サーバＹに対し，資源管理の承認を通知するとともに，資源の管理情報を送信する。

（Ｐ２３） 以降，管理サーバＡは，新管理サーバＹから転送終了の依頼があるまで，サーバＢ〜Ｄから管理サーバＡに到着したその資源に対する処理要求を新管理サーバＹに転送する。

（Ｐ２４） 新管理サーバＹは，資源管理情報を取得したなら，資源管理を開始し，サーバＢ〜Ｄに対して管理サーバの移行を通知する。

（Ｐ２５） サーバＢ〜Ｄは，移行通知を受け取ったら，管理サーバＡに対して確認通知を発行し，通知以降，その資源に関しては新管理サーバＹに処理要求を発行するようにする。

（Ｐ２６） 管理サーバＡは，サーバＢ〜Ｄから確認通知を受け取ったら，新管理サーバＹへの処理要求の転送を終了する。

図２３は，第２の管理方式における処理フローチャートである。ある資源に対する新管理サーバは，現在の管理サーバに対して，資源管理情報の取得と自サーバへの資源管理処理の移行を依頼する（ステップＳ２１１）。現在の管理サーバは，新管理サーバに対し，移行の承認と資源管理情報を送信する。以降，他のサーバから管理サーバにその資源に対する処理要求が到着した場合，その処理要求を新管理サーバに転送する（ステップＳ２１２）。

新管理サーバは，資源管理情報を取得したら，資源管理処理を開始し，他のサーバに対して管理サーバの移行を通知する（ステップＳ２１３）。他のサーバは，移行通知を受け取ったら，旧管理サーバに対して確認通知を発行する。以降は，その資源に関しては新管理サーバに処理要求を発行する（ステップＳ２１４）。旧管理サーバは，管理するすべてのサーバから確認通知を受け取ったら，新管理サーバへの処理要求の転送を終了する（ステップＳ２１５）。

〔第３の管理方式〕
ある管理サーバをシステムから削除する場合，これまで削除する管理サーバが管理していた資源は別のサーバに移行させる必要がある。そのための第３の管理方式の手順では，第２の管理方式の手順により資源の管理を新たな管理サーバへ移行し，その後に旧管理サーバを削除することにより，システムを停止することなく管理サーバを削除できるようにする。この手順の例を，図２２を用いて説明するが，（Ｐ２１）〜（Ｐ２５）までの処理は，第２の管理方式の処理と同様であるので説明を省略する。

（Ｐ２６’） 管理サーバＡは，サーバＢ〜Ｄから管理サーバ移行の確認通知を受け取ったら，転送処理を終了し，サーバＢ〜Ｄに対して自サーバの削除を依頼する。サーバＢ〜Ｄ上において，サーバ一覧テーブルから旧管理サーバＡが削除され，処理が完了する。

図２４は，第３の管理方式における処理フローチャートである。図２４のフローチャートのステップＳ２２１〜Ｓ２２４までの処理は，図２３の処理フローチャートのステップＳ２１１〜Ｓ２１４と同様であるので，説明を省略する。

ステップＳ２２５で，旧管理サーバは，管理するすべてのサーバから確認通知を受け取ったら，転送処理を終了し，各サーバに対して自サーバの登録削除を依頼する。各サーバは，旧管理サーバの登録を削除し，処理を完了する（ステップＳ２２６）。

〔第４の管理方式〕
複数のサーバがそれぞれ登録された二つのドキュメント分散処理システムを統合し，一つのシステムにする場合を考える。その際，資源に共通の管理サーバを変更する場合（例えば，各システムで別々に設定していた管理サーバを一つにする場合）には，第２の管理方式と同様の移行処理が必要になる。図２５にその手順を示す。

図２５は，第４の管理方式の手順の例を示す図である。図２５では，システムＳとシステムＴとを統合し，システムＴにおいて管理サーバＡが管理していた資源の管理を，管理サーバＡから新管理サーバＹに移行する場合の例を示している。

（Ｐ３１） 新管理サーバＹは，資源管理処理の移行を管理サーバＡに依頼申請する。

（Ｐ３２） 管理サーバＡは，移行の承認を通知するとともに，資源管理情報および管理サーバＡに登録されているシステムＴのサーバ一覧テーブルを新管理サーバＹに送信する。

（Ｐ３３） 以降，管理サーバＡは，その資源に対するサーバＢ，Ｃからの処理要求を新管理サーバＹに転送する。

（Ｐ３４） 新管理サーバＹは，システムＳおよびＴを統合した新サーバ一覧テーブルおよび管理サーバの移行通知を，サーバＢ，Ｃ，Ｚに配送する。

（Ｐ３５） サーバＢ，Ｃ，Ｚは，サーバ一覧テーブルと移行通知を受け取ったら，自サーバのサーバ一覧テーブルを更新し，管理サーバＡに対して確認通知を発行する。以降その資源に関しては新管理サーバＹに要求を発行するようにする。管理サーバＡは，サーバＢ，Ｃ，Ｚから確認通知を受け取ったら，新管理サーバＹへの処理要求の転送を終了する。

図２６は，第４の管理方式における処理フローチャートである。新たに統合システムの管理サーバとなる管理サーバ（新管理サーバという）は，管理処理の移行を他のシステムの管理サーバ（旧管理サーバという）に依頼する（ステップＳ２３１）。旧管理サーバは，移行の承認と資源管理情報および旧管理サーバに登録されているサーバ一覧を新管理サーバに送信する。以降，旧管理サーバは，その資源に対する処理要求を新管理サーバに転送する（ステップＳ２３２）。

新管理サーバは，統合するシステムに登録されている新サーバ一覧および管理サーバの移行通知を各サーバに送信する（ステップＳ２３３）。各サーバは，新サーバ一覧と移行通知を受け取ったら，自サーバのサーバ一覧を更新し，旧管理サーバに対して確認通知を発行する。以降，その資源に関しては新管理サーバに処理要求を発行する（ステップＳ２３４）。旧管理サーバは，すべてのサーバから確認通知を受け取ったら，新管理サーバへの処理要求の転送を終了する（ステップＳ２３５）。

次に，文書を互いに共有するような業務に本発明を適用した実施例を説明する。まず，文書を互いに共有するような業務を行うシステムにサーバｘを追加する場合を図２７を用いて説明する。

初期状態では，サーバａ，ｂ，…，ｉ，…ｎは，それぞれ文書１（版：１），文書２（版：１），文書３（版：１）を持ち，サーバｘは，未登録の時点では何も文書を持っていない。

はじめに，サーバｘは，サーバａに対し，サーバ一覧（テーブル）と文書データを要求する。サーバａは，要求を受け取った時点で，サーバｘへの複製文書の転送処理を開始し，サーバｘにサーバ一覧とサーバａが持っている文書データを配布する。この間，サーバｘは，他のサーバｂ，…，ｉ，…ｎに登録されていないので，サーバｉで文書１を第２版に改版したとすると，文書１（２版）は，直接サーバｘには届かないが，本発明では，サーバａは配布された文書１（２版）をサーバｘに転送するので，サーバｘは，これをサーバａ経由で受け取ることができる。

サーバｘは，サーバａからサーバ一覧と文書データを受け取ったら，サーバａ，ｂ，…，ｉ，…ｎに対してサーバｘの登録を依頼する。サーバａ，ｂ，…，ｉ，…ｎにおいて，サーバｘがサーバ一覧に登録されると，以後各自のサーバで改版した文書は，サーバｘに対しても配送されるようになる。これ以降に，サーバｉが，文書２を更新して２版にしたときには，サーバｘは，文書２（２版）の複製を直接サーバｉからの配送によって取得することができる。

サーバａ，ｂ，…，ｉ，…ｎは，サーバｘに対して登録完了を通知する。サーバｘは，すべてのサーバで登録完了されたことを確認したら，サーバａに対して転送処理の終了を依頼する。すべての処理完了後，サーバｘを含めた各サーバは，文書１（１版，２版），文書２（１版，２版），文書３（１版）を所有しており，保有する文書の一貫性が保たれることになる。

次に，それぞれ自システムにおける文書を共有するシステムＳとシステムＴが独立して稼働している状態で，システムＳとシステムＴとを統合し，同時に統合後の全体の管理サーバをサーバＳａに統一する場合の例を，図２８を用いて説明する。

まず，システムＳのサーバＳａは，改版管理処理の移行をシステムＴのサーバＴａに依頼する。サーバＴａが，文書の管理情報およびシステムＴに登録されているサーバの一覧（Ｔａ，Ｔｂ，…，Ｔｉ，…，Ｔｍ）を，サーバＳａに送信する。サーバＴａは，以降，文書の改版要求をサーバＳａに転送する。この時点で，サーバＴｉが，文書４を１版から２版に改版したい場合には，サーバＴｉは，サーバＴａに改版要求を発行するが，この要求はサーバＴａによりサーバＳａに転送され，サーバＳａが要求を処理する。

サーバＳａは，管理情報とサーバ一覧を受け取ったら，サーバＳａ，Ｓｂ，…，Ｓｉ，…，ＳｎとサーバＴａ，Ｔｂ，…，Ｔｉ，…，Ｔｍとを統合した新たなサーバ一覧を作成し，この新サーバ一覧と改版管理サーバのサーバＳａへの移行通知を，サーバＳａ，Ｓｂ，…，Ｓｉ，…，ＳｎとサーバＴａ，Ｔｂ，…，Ｔｉ，…，Ｔｍに送信する。

各サーバは，サーバ一覧と移行通知を受け取ったら，自サーバのサーバ一覧を更新し，サーバＴａに対して確認通知を発行し，以降，その資源に関してはサーバＳａに要求を発行するようにする。この時点以降にサーバＴｉが文書を更新しても，改版要求は，サーバＳａに直接送られるようになる。サーバＴａは，サーバＳａ，Ｓｂ，…，Ｓｉ，…，Ｓｎの全サーバから確認通知を受け取ったら，処理要求のサーバＳａへの転送を終了する。

本発明の原理説明図である。 本発明によるサーバ管理のための構成を説明する図である。 文書の複製と配布を説明する図である。 送信処理および受信処理の処理フローチャートである。 第１の処理方式の手順の例を示す図である。 第１の処理方式における処理フローチャートである。 第２の処理方式の手順の例を示す図である。 第２の処理方式における処理フローチャートである。 第３の処理方式における文書の実装形態の例を示す図である。 第３の処理方式を説明する図である。 最新の実体の取得処理の処理フローチャートである。 第４の処理方式を説明する図である。 第４の処理方式における処理フローチャートである。 多重更新が発生する場合の例を示す図である。 第５の処理方式の手順の例を示す図である。 第５の処理方式における処理フローチャートである。 通信途絶が発生した場合の手順の例を示す図である。 第６の処理方式によるタイムアウトが発生した場合の処理フローチャートである。 サーバ一覧テーブルの構成例を示す図である。 第１の管理方式の手順の例を示す図である。 第１の管理方式における処理フローチャートである。 第２および第３の管理方式の手順の例を示す図である。 第２の管理方式における処理フローチャートである。 第３の管理方式における処理フローチャートである。 第４の管理方式の手順の例を示す図である。 第４の管理方式における処理フローチャートである。 文書を互いに共有するような業務を行うシステムにサーバｘを追加する場合の実施例を示す図である。 それぞれ文書を共有するような業務を行うシステムＳとシステムＴとを統合する場合の実施例を示す図である。

符号の説明

１ａ，１ｂ，１ メッセージ処理手段
２ａ，２ｂ，２ メッセージ通信手段
３ａ，３ｂ，３ レポジトリ管理手段
４ａ，４ｂ 版数管理手段
５ａ，５ｂ ロック管理手段
６ａ，６ｂ 時刻監視手段
７ａ，７ｂ，７ ユーザインタフェース（ＵＩ）
１０ａ，１０ｂ，１０ サーバ
２０ａ，２０ｂ レポジトリ
３０ａ，３０ｂ クライアント
４０ ネットワーク
５１ サーバ登録手段
５２ サーバ削除手段
５３ 管理サーバ変更手段
５４ システム統合手段
５５ サーバ一覧テーブル

Claims (8)

1. ネットワーク上の複数のサーバ間において同一のオンラインドキュメントを共有し，かつ，どのサーバにおいても参照・更新を可能とするシステムにおいて，
   システムへの新規サーバの登録依頼があった場合に，任意の依頼されたサーバは，依頼された時点における共有ドキュメントの複製を，新規サーバへ配送するとともに，その後に更新されたドキュメントのデータの新規サーバへの配送を，全サーバへの新規サーバの登録が完了するまで代行する
   ことを特徴とするドキュメント分散処理システムのサーバ管理方法。
2. ネットワーク上の複数のサーバ間において同一のオンラインドキュメントを共有し，かつ，どのサーバにおいても参照・更新を可能とするシステムにおいて，
   あるドキュメントの管理情報を管理する管理サーバを他のサーバに変更する場合に，
   元の管理サーバは，依頼されたドキュメントの管理情報を新しい管理サーバへ配送するとともに，そのドキュメントの管理情報に対する他のサーバからの要求を，新しい管理サーバに対して転送し，
   新しい管理サーバは，前記ドキュメントの管理情報を取得した後，その管理情報の管理を開始し，他のサーバに対して管理サーバの移行を通知する
   ことを特徴とするドキュメント分散処理システムのサーバ管理方法。
3. ネットワーク上の複数のサーバ間において同一のオンラインドキュメントを共有し，かつ，どのサーバにおいても参照・更新を可能とするシステムにおいて，
   あるドキュメントの管理情報を管理する管理サーバをシステムから削除する場合に，
   削除される管理サーバは，前記ドキュメントの管理情報の管理を引き継ぐサーバに対して，そのドキュメントの管理情報を配送するとともに，そのドキュメントの管理情報に対する他のサーバからの要求を，管理を引き継ぐ管理サーバに対して転送し，管理を引き継ぐ管理サーバからの引き継ぎの確認後に他のサーバに対して自サーバの削除を依頼し，
   管理を引き継ぐ管理サーバは，前記ドキュメントの管理情報を取得した後，その管理情報の管理を開始し，他のサーバに対して管理サーバの移行を通知する
   ことを特徴とするドキュメント分散処理システムのサーバ管理方法。
4. ネットワーク上の複数のサーバ間において同一のオンラインドキュメントを共有し，かつ，どのサーバにおいても参照・更新を可能とするシステムにおいて，
   それぞれ別々にオンラインドキュメントを共有する複数のシステムを一つに統合するために，第１のシステムにおけるドキュメントの管理情報を管理する管理サーバを第２のシステムにおける管理サーバに変更するにあたって，前記第１のシステムにおける管理サーバは，自システムのドキュメントの管理情報を，前記第２のシステムにおける管理サーバへ配送するとともに，そのドキュメントの管理情報に対する他のサーバからの要求を，前記第２のシステムにおける管理サーバに対して転送し，
   前記第２のシステムにおける管理サーバは，前記ドキュメントの管理情報を取得した後，その管理情報の管理を開始し，他のサーバに対して管理サーバの移行を通知する
   ことを特徴とするドキュメント分散処理システムのサーバ管理方法。
5. ネットワーク上の複数のサーバ間において同一のオンラインドキュメントを共有し，かつ，どのサーバにおいても参照・更新を可能とするシステムにおけるサーバが用いるプログラムを記録した計算機読み取り可能な記録媒体であって，
   システムへの新規サーバの登録依頼があった場合に，依頼された時点における共有ドキュメントの複製を，新規サーバへ配送する処理と，
   その後に更新されたドキュメントのデータの新規サーバへの配送を，全サーバへの新規サーバの登録が完了するまで代行する処理とを，
   計算機に実行させるためのプログラムを記録したことを特徴とするサーバプログラムの記録媒体。
6. ネットワーク上の複数のサーバ間において同一のオンラインドキュメントを共有し，かつ，どのサーバにおいても参照・更新を可能とするシステムにおけるサーバが用いるプログラムを記録した計算機読み取り可能な記録媒体であって，
   あるドキュメントの管理情報を管理する機能を他のサーバに移行するとき，移行するドキュメントの管理情報を移行先の管理サーバへ配送する処理と，
   そのドキュメントの管理情報に対する他のサーバからの要求を，移行先の管理サーバに対して転送する処理と，
   自サーバが移行先のサーバとなるとき，移行元のサーバからドキュメントの管理情報を取得した後，その管理情報の管理を開始し，他のサーバに対して管理サーバの移行を通知する処理とを，
   計算機に実行させるためのプログラムを記録したことを特徴とするサーバプログラムの記録媒体。
7. ネットワーク上の複数のサーバ間において同一のオンラインドキュメントを共有し，かつ，どのサーバにおいても参照・更新を可能とするシステムにおけるサーバが用いる計算機読み取り可能なプログラムを記録した記録媒体であって，
   自サーバをシステムから削除する場合に，自サーバが管理するドキュメントの管理情報を，管理を引き継ぐサーバに対して配送する処理と，
   そのドキュメントの管理情報に対する他のサーバからの要求を，前記管理を引き継ぐ管理サーバに対して転送する処理と，
   前記管理を引き継ぐ管理サーバからの引き継ぎの確認後に他のサーバに対して自サーバの削除を依頼する処理と，
   自サーバが他のサーバから，あるドキュメントの管理情報の管理を引き継ぐ場合に，前記ドキュメントの管理情報を取得した後，その管理情報の管理を開始し，他のサーバに対して管理サーバの移行を通知する処理とを，
   計算機に実行させるためのプログラムを記録したことを特徴とするサーバプログラムの記録媒体。
8. ネットワーク上の複数のサーバ間において同一のオンラインドキュメントを共有し，かつ，どのサーバにおいても参照・更新を可能とするシステムにおけるサーバが用いるプログラムを記録した計算機読み取り可能な記録媒体であって，
   それぞれ別々にオンラインドキュメントを共有する複数のシステムを一つに統合するために，自サーバが管理する自システムにおけるドキュメントの管理情報の管理機能を，他のシステムにおける管理サーバに変更するにあたって，自システムのドキュメントの管理情報を，前記第２のシステムにおける管理サーバへ配送する処理と，
   そのドキュメントの管理情報に対する他のサーバからの要求を，前記第２のシステムにおける管理サーバに対して転送する処理と，
   自サーバが他のシステムの管理サーバからドキュメントの管理情報の管理機能を引き継ぐ場合に，そのドキュメントの管理情報を取得した後，その管理情報の管理を開始し，他のサーバに対して管理サーバの移行を通知する処理とを，
   計算機に実行させるためのプログラムを記録したことを特徴とするサーバプログラムの記録媒体。

Images