JPH11272534A

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

Info

Publication number: JPH11272534A
Application number: JP10163109A
Authority: JP
Inventors: Takao Okubo; 隆夫大久保; Hirotaka Hara; 裕貴原; Takahide Matsuzuka; 貴英松塚
Original assignee: Fujitsu Ltd
Current assignee: Fujitsu Ltd
Priority date: 1998-01-20
Filing date: 1998-06-11
Publication date: 1999-10-08

Abstract

(57)【要約】【課題】ネットワーク上の複数のサーバ間において同
一のオンラインドキュメントを共有するシステムにおけ
るドキュメント分散処理方法に関し，どの拠点において
も参照・更新を可能とし，かつ多重更新発生の問題を解
決することを目的とする。【解決手段】文書を更新するサーバ10a では，メッセ
ージ通信手段2aにより他のサーバ10b に対して更新開始
通知を送信する。サーバ10b はこれを受け取り，ロック
管理手段5bにより該当する文書にロックをする。サーバ
10a で文書更新を終了すると, メッセージ通信手段2aに
より更新文書またはそのメタ情報がサーバ10b に送信さ
れる。サーバ10b では，更新文書等を受け取った時点で
文書ロックを解除する。このとき，ロック完了通知前の
更新開始，論理オブジェクトのみの配布，優先度の高い
サーバによる改版承認の処理を行う。

Description

【発明の詳細な説明】

【０００１】

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

【０００２】本発明は，同一内容の文書を複数のサイト
で共有する方式に係り，特に，複数拠点で分散されたオ
ンラインドキュメントを使用する際に，必要最小限のデ
ータ通信を利用し，ドキュメントの同時共有および任意
の拠点における更新を可能としたドキュメント分散処理
方法，およびマルチサーバ環境においてサーバを追加登
録，または変更する場合のドキュメント分散処理システ
ムのサーバ管理方法に関する。

【０００３】

【従来の技術】従来，複数拠点間で文書を共有する技術
として，以下の方法がある。（１）ワークフロー等を利用し，単一の文書を拠点間で
転送する方法。

【０００４】（２）同一文書の複製を拠点間で保有し，
複製された文書に対し参照・更新を行う方法。後者の（２）に示す同一文書の複製を拠点間で保有する
方法の場合には，複数の拠点で同一文書に関する更新が
発生し，内容の異なる文書が複数存在する可能性がある
が，この対処方法として，以下の方法がある。

【０００５】（２−ａ）更新可能な拠点を１箇所に限定
し，他の拠点では更新を禁止する方法。（２−ｂ）複数の拠点での更新を許可し，複製を統合す
る際に何らかの手段で文書間の差異の修正を行う方法。

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

【０００７】

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

【０００８】また，（２−ａ）に示す方法は，更新を行
える拠点が限定されているため，やはり自由に更新を行
うことができないという問題がある。（２−ｂ）に示す
方法は，多重更新が頻繁に発生してしまうことが問題で
あり，多重更新により生じてしまった差異を解決する手
段として一般に有効な方法がない。

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

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

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

【００１２】

【課題を解決するための手段】図１は，本発明のドキュ
メント分散処理方法の原理説明図である。図１におい
て，ネットワーク４０で結ばれた複数の拠点には，それ
ぞれ，サーバ１０ａ，１０ｂと，レポジトリ２０ａ，２
０ｂ，サーバに接続するクライアント３０ａ，３０ｂが
存在する。各拠点はサーバ・クライアント構成になって
いる。

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

【００１４】メッセージ通信手段２ａ，２ｂは，他サー
バへのメッセージ送信および他サーバからのメッセージ
受信を担当する手段である。レポジトリ管理手段３ａ，
３ｂは，レポジトリ２０ａ，２０ｂに格納されている論
理オブジェクトや実体の参照，検索，更新等を行う。

【００１５】版数管理手段４ａ，４ｂ，は，ドキュメン
トの版管理を担当する。ロック管理手段５ａ，５ｂは，
ドキュメントのロック，ロック解除，ロック状態の管理
を担当する。

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

【００１７】レポジトリ２０ａ，２０ｂは，ドキュメン
トの実体ファイルや論理オブジェクトを格納する記憶手
段である。例えば，データベースに類似する構造を持つ
格納領域を持つ。

【００１８】クライアント３０ａ，３０ｂは，文書を編
集・参照するドキュメントアプリケーションを持つ。本
発明では，同一ドキュメント（文書）が各サーバに配置
される。あるサーバ１０ａで生成・更新されたドキュメ
ントの内容は，ネットワーク４０を介して他のサーバ１
０ｂが持つドキュメントに反映される。

【００１９】本発明は，以下のように作用する。（１）サーバ１０ａは，あるドキュメントの更新を開
始すると，メッセージ通信手段２ａによりサーバ１０ｂ
に対して更新開始通知を送る。サーバ１０ｂは，メッセ
ージ通信手段２ｂにより更新開始通知を受け取り，ロッ
ク管理手段５ｂにより該当するドキュメントに対する更
新をロックする。

【００２０】サーバ１０ａは，更新が終了したときにメ
ッセージ通信手段２ｂにより更新終了通知を送り，サー
バ１０ｂは，ロック管理手段５ｂにより更新終了通知を
受け取ったときに前記ロックを解除する。

【００２１】これにより同一ドキュメントに対する多重
更新を回避することができる。（２）サーバ１０ａは，あるドキュメントの更新を開
始すると同時にサーバ１０ｂに対して更新開始通知を送
り，ユーザインタフェース（ＵＩ）７ａによりロック完
了通知を受け取る前に自クライアントに対して更新開始
を承認し，更新を進め，他のサーバ１０ｂからのロック
完了通知による更新の承認の有無は，更新が終了するま
での間に判定する。

【００２２】これにより，ロック完了通知の受信を待た
ずに更新を開始することができ，実際の処理開始までの
時間の短縮ができる。（３）レポジトリ２０ａでは，ドキュメントの実体フ
ァイルとこれにリンクするドキュメントのメタ情報であ
る論理オブジェクトとを分離して持ち，サーバ１０ａは
ドキュメントを作成または更新する際に，論理オブジェ
クトの複製のみを送信し，その後，他のサーバ１０ｂか
らの請求または所定の時間間隔により，作成または更新
されたドキュメントの実体の複製を送信する。

【００２３】この論理オブジェクトは，最新の実体を持
つサーバの情報を含む。サーバ１０ａがドキュメントの
実体とその論理オブジェクトを持ち，サーバ１０ｂが論
理オブジェクトだけを持つ状態で，サーバ１０ｂがドキ
ュメントを参照または更新する場合，サーバ１０ｂは，
論理オブジェクトをもとに最新の実体を保持するサーバ
１０ａから最新の実体を取得する。

【００２４】これにより，更新ごとに発生する実体の送
受信のための通信量を軽減することができる。（４）各サーバ１０ａ，１０ｂに優先度を設定し，ド
キュメントの更新を開始するサーバ１０ａは，自サーバ
の優先度を付加した更新開始通知を，他のすべてのサー
バ１０ｂへ送信する。更新開始通知を受信したサーバ１
０ｂにおいて，指定されたドキュメントがロック状態で
ある場合，そのサーバ１０ｂでは，現在のロック要求に
係るサーバの優先度と，受信したサーバ１０ａの優先度
とを比べて，最終的に優先度の高いサーバによるロック
のみを実施する。

【００２５】これにより，複数のサーバで同時に更新を
開始した場合に，更新の競合を回避することができる。（５）各サーバごとに優先度に対応する独自のドキュ
メント版体系を設定し，ドキュメントを更新するサーバ
（例えばサーバ１０ａ）は，最も優先度の高いサーバ
（例えばサーバ１０ｂ）に対し改版申請を送信し，改版
が承認された場合には，承認された版を持つドキュメン
トを正式版として採用する。その際に必要であれば，そ
の正式版のドキュメントを他のサーバへ送信する。

【００２６】これにより，複数のサーバで改版が発生し
た場合でも，同一の版で異なる内容のドキュメントが存
在してしまうという事態を防止し，版の分裂を解決する
ことが可能となる。

【００２７】（６）サーバの優先度が最も高いサーバ
との通信が途絶している場合には，通信が途絶したサー
バの次に高い優先度を持つサーバに対して改版申請を送
信する。

【００２８】これにより，いずれかのサーバとの通信が
途絶した状態の場合であっても，残りのサーバ間で同一
のドキュメントの版管理を行うことができる。（７）また，各ドキュメント単位にサーバの優先度を
設定する。

【００２９】これにより，ドキュメントごとに優先度の
高いサーバが異なり，改版の承認に関する処理が分散さ
れるので，通信の集中を回避することができる。図２
は，本発明によるサーバ管理のための構成を説明する図
である。

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

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

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

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

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

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

【００３６】

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

【００３７】本実施の形態を説明する前提として，遠隔
の拠点間で文書を相互に共有するような業務を行う場合
を例とする。各拠点には，コンピュータと，ファイルや
論理オブジェクトを格納可能なレポジトリ（データベー
ス）と，サーバアプリケーションが存在する。レポジト
リは，文書（ドキュメント）を版（バージョン）管理
し，版ごとに文書を格納できる機能を持つ。また，拠点
はすべてネットワークに接続されており，任意の拠点間
でメッセージ通信，ファイルや論理オブジェクトの転送
が可能である。各拠点は，サーバ・クライアント構成に
なっており，クライアントには文書を編集・参照するド
キュメントアプリケーションが実装されている。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

【００５３】クライアントから参照・更新のために文書
を利用する場合には，論理オブジェクトを経由して実体
ファイルの取得を行う。また，文書を論理オブジェクト
と実体ファイルとに分離して実装することで，文書の新
規作成時や更新時には，文書実体を配布せずに論理オブ
ジェクトのみを配布し，実体ファイルは，通常更新が発
生しない時間帯や通信負荷が小さい時間帯などを指定し
ておき，定期的に配布する。

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

【００５５】さらに，論理オブジェクトに，最新実体の
保有の有無，最新実体を保有するサーバの識別子の情報
を追加することもできる。図１１は，最新の実体の取得
処理の処理フローチャートである。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

【００７４】次に，遠隔地の３拠点において，文書を互
いに共有するような業務に本発明を適用した実施例を説
明する。ネットワークで結ばれた拠点Ａ，Ｂ，Ｃでは，
比較的大きなサイズの文書を扱い，文書の更新が行われ
る主な拠点は，文書の種類によってほぼ決まっているも
のとする。例えば「設計書」という種類の文書は，主に
拠点Ａで更新され，拠点Ｂ，Ｃでも更新はされるが頻度
は少ないものとする。

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

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

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

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

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

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

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

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

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

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

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

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

【００８７】（Ｐ１２）サーバＡは，自己の持つサー
バ一覧テーブルにサーバＸを追加登録し，そのサーバ一
覧テーブルとデータを新規サーバＸに送信する。（Ｐ１３）以後，依頼されたサーバＡは，サーバＸか
ら転送終了の依頼があるまで，他のサーバ（例えばサー
バＢ）から自サーバに配送されてきたデータをすべて新
規サーバＸに転送する。

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

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

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

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

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

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

【００９４】図２２は，第２の管理方式の手順の例を示
す図である。（Ｐ２１）現在，ある資源の管理を管理サーバＡが行
っており，その管理を新管理サーバＹに移行するものと
する。新管理サーバＹは，現在の管理サーバＡに対し
て，資源の管理情報の配送と，自サーバへの処理の移行
の依頼を申請する。

【００９５】（Ｐ２２）管理サーバＡは，新管理サー
バＹに対し，資源管理の承認を通知するとともに，資源
の管理情報を送信する。（Ｐ２３）以降，管理サーバＡは，新管理サーバＹか
ら転送終了の依頼があるまで，サーバＢ〜Ｄから管理サ
ーバＡに到着したその資源に対する処理要求を新管理サ
ーバＹに転送する。

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

【００９７】（Ｐ２６）管理サーバＡは，サーバＢ〜
Ｄから確認通知を受け取ったら，新管理サーバＹへの処
理要求の転送を終了する。図２３は，第２の管理方式に
おける処理フローチャートである。

【００９８】ある資源に対する新管理サーバは，現在の
管理サーバに対して，資源管理情報の取得と自サーバへ
の資源管理処理の移行を依頼する（ステップＳ２１
１）。現在の管理サーバは，新管理サーバに対し，移行
の承認と資源管理情報を送信する。以降，他のサーバか
ら管理サーバにその資源に対する処理要求が到着した場
合，その処理要求を新管理サーバに転送する（ステップ
Ｓ２１２）。

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

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

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

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

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

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

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

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

【０１０７】（Ｐ３３）以降，管理サーバＡは，その
資源に対するサーバＢ，Ｃからの処理要求を新管理サー
バＹに転送する。（Ｐ３４）新管理サーバＹは，システムＳおよびＴを
統合した新サーバ一覧テーブルおよび管理サーバの移行
通知を，サーバＢ，Ｃ，Ｚに配送する。

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

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

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

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

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

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

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

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

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

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

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

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

【０１２０】

【発明の効果】本発明のドキュメント分散処理方法は，
以下の効果を奏する。１）同一ドキュメントの複製を各サーバに配布しておく
ことにより，各サーバが任意の時点でドキュメントの更
新を行うことができる。

【０１２１】２）あるドキュメントの更新を開始するサ
ーバが他のサーバに対して通知を行い，受け取った他の
サーバは更新終了までそのドキュメントに対する更新を
ロックすることにより，同一ドキュメントに対する多重
の更新を回避することができる。

【０１２２】３）ドキュメントの更新開始と同時に他の
サーバに対して，更新開始通知もしくは改版の承認申請
を出し，承認を待つ間に更新を進めてしまうことによ
り，承認待ちのための手順および時間を省略することが
できる。

【０１２３】４）ドキュメントの実体であるファイル
と，実体にリンクする論理オブジェクトとを分離し，デ
ータ量の少ない論理オブジェクトは新規作成・更新ごと
に他のドキュメントアプリケーションサーバに反映させ
る一方，実体は，例えば定期的な時間間隔で複製を行う
ことにより，更新ごとに発生するデータ通信量を軽減す
ることができる。

【０１２４】５）上記４）の方式で，最新の実体を持つ
サーバの情報を保持することにより，各サーバが更新な
どにより最新の実体を必要とする場合に，それを保持す
るサーバから取得することができる。

【０１２５】６）各サーバに優先度を設定することによ
り，別々のサーバで同時に更新を開始した場合に競合を
回避することができる。７）各サーバごとに優先度に対応する独自のドキュメン
ト版体系を設定することにより，仮に複数のサーバで同
時に改版が発生してしまった場合でも，最も優先度の高
い版体系を正式版として採用することで版の分裂を解決
することができる。

【０１２６】８）各サーバごとの優先度付き版体系を利
用し，いずれかのサーバとの通信が途絶している場合で
も残りのサーバ同士でドキュメントの更新を継続し，全
サーバ復活後に正式版に統合することができる。

【０１２７】９）サーバの優先度をドキュメント単位に
設定することにより，１箇所のサーバへの通信集中を回
避することができる。また，本発明のドキュメント分散
処理システムのサーバ管理方法によれば，ネットワーク
上の複数のサーバ間において同一のオンラインドキュメ
ントを共有し，かつ，どのサーバにおいても参照・更新
を可能とするようなマルチサーバによるドキュメント分
散処理システムの環境において，同期によって他の処理
が待たされることなく，かつ，一貫性を保持しながらサ
ーバの追加，変更を行うことができる。

【図面の簡単な説明】

【図１】本発明の原理説明図である。

【図２】本発明によるサーバ管理のための構成を説明す
る図である。

【図３】文書の複製と配布を説明する図である。

【図４】送信処理および受信処理の処理フローチャート
である。

【図５】第１の処理方式の手順の例を示す図である。

【図６】第１の処理方式における処理フローチャートで
ある。

【図７】第２の処理方式の手順の例を示す図である。

【図８】第２の処理方式における処理フローチャートで
ある。

【図９】第３の処理方式における文書の実装形態の例を
示す図である。

【図１０】第３の処理方式を説明する図である。

【図１１】最新の実体の取得処理の処理フローチャート
である。

【図１２】第４の処理方式を説明する図である。

【図１３】第４の処理方式における処理フローチャート
である。

【図１４】多重更新が発生する場合の例を示す図であ
る。

【図１５】第５の処理方式の手順の例を示す図である。

【図１６】第５の処理方式における処理フローチャート
である。

【図１７】通信途絶が発生した場合の手順の例を示す図
である。

【図１８】第６の処理方式によるタイムアウトが発生し
た場合の処理フローチャートである。

【図１９】サーバ一覧テーブルの構成例を示す図であ
る。

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

【図２１】第１の管理方式における処理フローチャート
である。

【図２２】第２および第３の管理方式の手順の例を示す
図である。

【図２３】第２の管理方式における処理フローチャート
である。

【図２４】第３の管理方式における処理フローチャート
である。

【図２５】第４の管理方式の手順の例を示す図である。

【図２６】第４の管理方式における処理フローチャート
である。

【図２７】文書を互いに共有するような業務を行うシス
テムにサーバｘを追加する場合の実施例を示す図であ
る。

【図２８】それぞれ文書を共有するような業務を行うシ
ステムＳとシステムＴとを統合する場合の実施例を示す
図である。。

【符号の説明】

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

Claims

【特許請求の範囲】

【請求項１】ネットワーク上の複数のサーバ間におい
て同一のオンラインドキュメントを共有し，かつ，どの
サーバにおいても参照・更新を可能とするシステムにお
いて，同一のドキュメントの複製を各サーバに配布し，
あるドキュメントの更新を開始するサーバが他のサーバ
に対して更新開始通知を送り，更新が終了したときに更
新終了通知を送り，前記他のサーバは，前記更新開始通
知を受け取ったときに該当するドキュメントに対する更
新をロックし，更新終了通知を受け取ったときに前記ロ
ックを解除することを特徴とするドキュメント分散処理
方法。
【請求項２】ネットワーク上の複数のサーバ間におい
て同一のオンラインドキュメントを共有し，かつ，どの
サーバにおいても参照・更新を可能とするシステムにお
いて，同一のドキュメントの複製を各サーバに配布し，
あるサーバがあるドキュメントを更新する場合に，その
ドキュメントの更新開始と同時に他のサーバに対して更
新開始通知を送り，更新開始通知に対する前記他のサー
バからの承認の応答を受け取る前に，そのドキュメント
の更新を進め，前記他のサーバからの更新の承認の有無
は，更新が終了するまでの間に判定することを特徴とす
るドキュメント分散処理方法。
【請求項３】ネットワーク上の複数のサーバ間におい
て同一のオンラインドキュメントを共有し，かつ，どの
サーバにおいても参照・更新を可能とするシステムにお
いて，ドキュメントをその内容である実体と，その実体
にリンクするメタ情報を持つ論理オブジェクトとに分離
し，ドキュメントを作成または更新した場合に，他のサ
ーバに対して論理オブジェクトの複製のみを送信し，そ
の後，他のサーバからの請求または所定の契機で，前記
作成または更新された実体の複製を送信することを特徴
とするドキュメント分散処理方法。
【請求項４】ネットワーク上の複数のサーバ間におい
て同一のオンラインドキュメントを共有し，かつ，どの
サーバにおいても参照・更新を可能とするシステムにお
いて，各サーバに優先度を設定するとともに，各サーバ
ごとに前記優先度に対応する独自のドキュメント版体系
を設定し，ドキュメントを更新するサーバは，最も優先
度の高いサーバに対し改版申請を送信し，改版が承認さ
れた場合にその版を正式版とすることを特徴とするドキ
ュメント分散処理方法。
【請求項５】ネットワーク上の複数のサーバ間におい
て同一のオンラインドキュメントを共有し，かつ，どの
サーバにおいても参照・更新を可能とするシステムにお
いて，各サーバに優先度を設定するとともに，各サーバ
ごとに前記優先度に対応する独自のドキュメント版体系
を設定し，ドキュメントを更新するサーバは，前記優先
度が最も高いサーバに対して改版申請を送信し，前記優
先度が最も高いサーバとの通信が途絶している場合に
は，前記通信が途絶したサーバの次に高い優先度を持つ
サーバに対して改版申請を送信し，改版が承認された版
を正式版とすることを特徴とするドキュメント分散処理
方法。
【請求項６】ネットワーク上の複数のサーバ間におい
て同一のオンラインドキュメントを共有し，かつ，どの
サーバにおいても参照・更新を可能とするシステムにお
いて，システムへの新規サーバの登録依頼があった場合
に，任意の依頼されたサーバは，依頼された時点におけ
る共有ドキュメントの複製を，新規サーバへ配送すると
ともに，その後に更新されたドキュメントのデータの新
規サーバへの配送を，全サーバへの新規サーバの登録が
完了するまで代行することを特徴とするドキュメント分
散処理システムのサーバ管理方法。
【請求項７】ネットワーク上の複数のサーバ間におい
て同一のオンラインドキュメントを共有し，かつ，どの
サーバにおいても参照・更新を可能とするシステムにお
いて，あるドキュメントの管理情報を管理する管理サー
バを他のサーバに変更する場合に，元の管理サーバは，
依頼されたドキュメントの管理情報を新しい管理サーバ
へ配送するとともに，そのドキュメントの管理情報に対
する他のサーバからの要求を，新しい管理サーバに対し
て転送し，新しい管理サーバは，前記ドキュメントの管
理情報を取得した後，その管理情報の管理を開始し，他
のサーバに対して管理サーバの移行を通知することを特
徴とするドキュメント分散処理システムのサーバ管理方
法。
【請求項８】ネットワーク上の複数のサーバ間におい
て同一のオンラインドキュメントを共有し，かつ，どの
サーバにおいても参照・更新を可能とするシステムにお
いて，あるドキュメントの管理情報を管理する管理サー
バをシステムから削除する場合に，削除される管理サー
バは，前記ドキュメントの管理情報の管理を引き継ぐサ
ーバに対して，そのドキュメントの管理情報を配送する
とともに，そのドキュメントの管理情報に対する他のサ
ーバからの要求を，管理を引き継ぐ管理サーバに対して
転送し，管理を引き継ぐ管理サーバからの引き継ぎの確
認後に他のサーバに対して自サーバの削除を依頼し，管
理を引き継ぐ管理サーバは，前記ドキュメントの管理情
報を取得した後，その管理情報の管理を開始し，他のサ
ーバに対して管理サーバの移行を通知することを特徴と
するドキュメント分散処理システムのサーバ管理方法。
【請求項９】ネットワーク上の複数のサーバ間におい
て同一のオンラインドキュメントを共有し，かつ，どの
サーバにおいても参照・更新を可能とするシステムにお
いて，それぞれ別々にオンラインドキュメントを共有す
る複数のシステムを一つに統合するために，第１のシス
テムにおけるドキュメントの管理情報を管理する管理サ
ーバを第２のシステムにおける管理サーバに変更するに
あたって，前記第１のシステムにおける管理サーバは，
自システムのドキュメントの管理情報を，前記第２のシ
ステムにおける管理サーバへ配送するとともに，そのド
キュメントの管理情報に対する他のサーバからの要求
を，前記第２のシステムにおける管理サーバに対して転
送し，前記第２のシステムにおける管理サーバは，前記
ドキュメントの管理情報を取得した後，その管理情報の
管理を開始し，他のサーバに対して管理サーバの移行を
通知することを特徴とするドキュメント分散処理システ
ムのサーバ管理方法。
【請求項１０】ネットワーク上の複数のサーバ間にお
いて同一のオンラインドキュメントを共有し，かつ，ど
のサーバにおいても参照・更新を可能とするシステムに
おけるサーバが用いるプログラムを記録した記録媒体で
あって，同一のドキュメントの複製を各サーバに配布す
る処理と，あるドキュメントの更新を開始する場合に，
他のサーバに対して更新開始通知を送り，更新が終了し
たときに更新終了通知を送る処理と，他のサーバから更
新開始通知を受け取ったときに該当するドキュメントに
対する更新をロックし，更新終了通知を受け取ったとき
に前記ロックを解除する処理とを，計算機に実行させる
プログラムを記録したことを特徴とするサーバプログラ
ムの記録媒体。
【請求項１１】ネットワーク上の複数のサーバ間にお
いて同一のオンラインドキュメントを共有し，かつ，ど
のサーバにおいても参照・更新を可能とするシステムに
おけるサーバが用いるプログラムを記録した記録媒体で
あって，同一のドキュメントの複製を各サーバに配布す
る処理と，あるドキュメントを更新する場合に，そのド
キュメントの更新開始と同時に他のサーバに対して更新
開始通知を送る処理と，更新開始通知に対する前記他の
サーバからの承認の応答を受け取る前に，そのドキュメ
ントの更新を開始する処理と，他のサーバからの更新の
承認の有無を，更新が終了するまでの間に判定する処理
とを，計算機に実行させるプログラムを記録したことを
特徴とするサーバプログラムの記録媒体。
【請求項１２】ネットワーク上の複数のサーバ間にお
いて同一のオンラインドキュメントを共有し，かつ，ど
のサーバにおいても参照・更新を可能とするシステムに
おけるサーバが用いるプログラムを記録した記録媒体で
あって，ドキュメントをその内容である実体と，その実
体にリンクするメタ情報を持つ論理オブジェクトとに分
離し，ドキュメントを作成または更新した場合に，他の
サーバに対して論理オブジェクトの複製のみを送信する
処理と，その後，他のサーバからの請求または所定の契
機で，前記作成または更新された実体の複製を送信する
処理とを，計算機に実行させるプログラムを記録したこ
とを特徴とするサーバプログラムの記録媒体。
【請求項１３】ネットワーク上の複数のサーバ間にお
いて同一のオンラインドキュメントを共有し，かつ，ど
のサーバにおいても参照・更新を可能とするシステムに
おけるサーバが用いるプログラムを記録した記録媒体で
あって，各サーバに設定された優先度を管理するととも
に，各サーバごとに前記優先度に対応して設定された独
自のドキュメント版体系を管理する処理と，ドキュメン
トを更新する場合に，最も優先度の高いサーバに対し改
版申請を送信し，改版が承認された場合にその版を正式
版とする処理とを，計算機に実行させるプログラムを記
録したことを特徴とするサーバプログラムの記録媒体。
【請求項１４】ネットワーク上の複数のサーバ間にお
いて同一のオンラインドキュメントを共有し，かつ，ど
のサーバにおいても参照・更新を可能とするシステムに
おけるサーバが用いるプログラムを記録した記録媒体で
あって，各サーバに設定された優先度を管理するととも
に，各サーバごとに前記優先度に対応して設定された独
自のドキュメント版体系を管理する処理と，ドキュメン
トを更新する場合に，前記優先度が最も高いサーバに対
して改版申請を送信し，前記優先度が最も高いサーバと
の通信が途絶している場合には，前記通信が途絶したサ
ーバの次に高い優先度を持つサーバに対して改版申請を
送信し，改版が承認された版を正式版とする処理とを，
計算機に実行させるプログラムを記録したことを特徴と
するサーバプログラムの記録媒体。
【請求項１５】ネットワーク上の複数のサーバ間にお
いて同一のオンラインドキュメントを共有し，かつ，ど
のサーバにおいても参照・更新を可能とするシステムに
おけるサーバが用いるプログラムを記録した記録媒体で
あって，システムへの新規サーバの登録依頼があった場
合に，依頼された時点における共有ドキュメントの複製
を，新規サーバへ配送する処理と，その後に更新された
ドキュメントのデータの新規サーバへの配送を，全サー
バへの新規サーバの登録が完了するまで代行する処理と
を，計算機に実行させるプログラムを記録したことを特
徴とするサーバプログラムの記録媒体。
【請求項１６】ネットワーク上の複数のサーバ間にお
いて同一のオンラインドキュメントを共有し，かつ，ど
のサーバにおいても参照・更新を可能とするシステムに
おけるサーバが用いるプログラムを記録した記録媒体で
あって，あるドキュメントの管理情報を管理する機能を
他のサーバに移行するとき，移行するドキュメントの管
理情報を移行先の管理サーバへ配送する処理と，そのド
キュメントの管理情報に対する他のサーバからの要求
を，移行先の管理サーバに対して転送する処理と，自サ
ーバが移行先のサーバとなるとき，移行元のサーバから
ドキュメントの管理情報を取得した後，その管理情報の
管理を開始し，他のサーバに対して管理サーバの移行を
通知する処理とを，計算機に実行させるプログラムを記
録したことを特徴とするサーバプログラムの記録媒体。
【請求項１７】ネットワーク上の複数のサーバ間にお
いて同一のオンラインドキュメントを共有し，かつ，ど
のサーバにおいても参照・更新を可能とするシステムに
おけるサーバが用いるプログラムを記録した記録媒体で
あって，自サーバをシステムから削除する場合に，自サ
ーバが管理するドキュメントの管理情報を，管理を引き
継ぐサーバに対して配送する処理と，そのドキュメント
の管理情報に対する他のサーバからの要求を，前記管理
を引き継ぐ管理サーバに対して転送する処理と，前記管
理を引き継ぐ管理サーバからの引き継ぎの確認後に他の
サーバに対して自サーバの削除を依頼する処理と，自サ
ーバが他のサーバから，あるドキュメントの管理情報の
管理を引き継ぐ場合に，前記ドキュメントの管理情報を
取得した後，その管理情報の管理を開始し，他のサーバ
に対して管理サーバの移行を通知する処理とを，計算機
に実行させるプログラムを記録したことを特徴とするサ
ーバプログラムの記録媒体。
【請求項１８】ネットワーク上の複数のサーバ間にお
いて同一のオンラインドキュメントを共有し，かつ，ど
のサーバにおいても参照・更新を可能とするシステムに
おけるサーバが用いるプログラムを記録した記録媒体で
あって，それぞれ別々にオンラインドキュメントを共有
する複数のシステムを一つに統合するために，自サーバ
が管理する自システムにおけるドキュメントの管理情報
の管理機能を，他のシステムにおける管理サーバに変更
するにあたって，自システムのドキュメントの管理情報
を，前記第２のシステムにおける管理サーバへ配送する
処理と，そのドキュメントの管理情報に対する他のサー
バからの要求を，前記第２のシステムにおける管理サー
バに対して転送する処理と，自サーバが他のシステムの
管理サーバからドキュメントの管理情報の管理機能を引
き継ぐ場合に，そのドキュメントの管理情報を取得した
後，その管理情報の管理を開始し，他のサーバに対して
管理サーバの移行を通知する処理とを，計算機に実行さ
せるプログラムを記録したことを特徴とするサーバプロ
グラムの記録媒体。