(57)【要約】【課題】共有資源の競合に原因する協調作業のサービスレベルの低下を防止することが可能な情報処理方法及び装置を提供する。【解決手段】複数のクライアントによる協調作業の実行において、セッションに参加している複数の複数のクライアント間で共有されている協調操作対象のデータへの操作頻度が検出される。次に、検出手段で検出された操作頻度が所定値を越えた場合に、複数のクライアントを複数のグループに分割し（Ｓ５００１）、協調操作対象のレプリカを生成し、分割されたグループの夫々に協調操作対象として対応づける（Ｓ５００２）。そして、複数のクライアントの各々が、所属するグループに対応づけられた協調操作対象に対して操作を行うように通知する（Ｓ５００３）。【選択図】  図７
2005100432.tif 000002
【特許請求の範囲】
【請求項１】
複数のクライアントによる協調作業が可能なシステムを構成する情報処理装置であって、
セッションに参加している複数のクライアント間で共有されている協調操作対象のデータへの操作頻度を検出する検出手段と、
前記検出手段で検出された操作頻度が所定値を越えた場合、前記複数のクライアントを複数のグループに分割する分割手段と、
前記分割手段で分割されたグループの夫々に協調操作対象として前記協調操作対象のレプリカを対応づける処理手段とを備え、
前記複数のクライアントの各々は、所属するグループに対応づけられた協調操作対象に対して操作を行うことを特徴とする情報処理装置。
【請求項２】
前記分割手段は、前記協調作業への参加時刻に基づいて前記複数のクライアントを複数のグループに分割することを特徴とする請求項１に記載の情報処理装置。
【請求項３】
前記分割手段は、協調作業対象へのアクセス分布に基づいて前記複数のクライアントを複数のグループに分割することを特徴とする請求項１に記載の情報処理装置。
【請求項４】
前記分割手段は、前記複数のクライアントに対して分割の指示を行い、該複数のクライアントは各クライアント間の交渉によって複数のグループに分割されることを特徴とする請求項１に記載の情報処理装置。
【請求項５】
複数のクライアントによる協調作業が可能なシステムを構成する情報処理装置の情報処理方法であって、
セッションに参加している複数のクライアント間で共有されている協調操作対象のデータへの操作頻度を検出する検出工程と、
前記検出工程で検出された操作頻度が所定値を越えた場合、前記複数のクライアントを複数のグループに分割する分割工程と、
前記分割工程で分割されたグループの夫々に協調操作対象として前記協調操作対象のレプリカを対応づける処理工程とを備え、
前記複数のクライアントの各々は、所属するグループに対応づけられた協調操作対象に対して操作を行うことを特徴とする情報処理方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は複数のユーザによる協調作業が可能な情報処理装置及びその方法に関する。
【背景技術】
【０００２】
高速なネットワークで結合された高性能計算機の普及や、分散計算ソフトウェア技術の発達などにより、複数人から成るグループによる協調作業が行われるシステムが実用化されてきている。従来の協調作業システムでは、システム実現上における各種の制約によって、結果的に協調作業のサービスレベルの低下が防がれていた。
【０００３】
たとえば、発言権（以下、フロア）制御機能などを用いた場合には、フロアをクライアント間で手渡ししてゆくことにより、共有されているデータへの更新アクセスを、フロアを保持している参加者に限定し、他の参加者からの更新要求を認めなかった。そして、この排他制御機能の副作用により、更新要求の集中が防がれ、結果的に協調作業におけるサービス低下を避けることが出来た。
【０００４】
また、専用テレビ会議システムのような単機能型の専用協調作業システムでは、電話回線の許容量などのハードウェア構成上の制約から、システムの能力を越えた数の参加者は存在し得なかった。そのため、例えば、ある協調作業への参加に際して、参加者数が許容量以下であれば特別な参加制約をすることなく参加を許可するが、逆に、許容量を越えていれば、どんな種類の参加も許されない。
【０００５】
また、従来のデータベースサービスなどでは、アクセス権の有無やデータベースの一貫性保持などによるクライアントの制限は行なわれていたが、一方で、サービスレベルの維持を目的としたクライアントの制限は行なわれていないのが現状である。
【発明の開示】
【発明が解決しようとする課題】
【０００６】
近年、高速なネットワークで結合された高性能計算機の普及や、分散計算ソフトウェア技術の発達などによって、複数人からなるグループによる協調作業を計算機上で行うことが可能になってきている。このような状況下では、参加者数をハードウェア構成から制限することはなく、ネットワークあるいは計算機の能力の許す範囲で、参加を受け入れるようになってきている。そのため、システムの能力以上のクライアントが参加してしまうことにより、処理能力不足となり、各クライアントの得られるサービスのレベルが低下するという事態が発生する。
【０００７】
例えば、計算機ネットワークで、クライアント毎に異なった動画像を、決められた画質でリアルタイムに転送することを考えてみる。このとき、計算機ネットワークの容量は有限であることから、無制限にクライアントを受け入れて、複数の動画像データを無秩序に送り出そうとすると、動画像データの転送に衝突が発生し、動画像を待っている各々のクライアントに、適切な動画像データが配送されないという事態となってしまう。同様に、協調作業中におけるデータ共有に関しても、無制限のクライアントの受け入れは、各クライアントへのサービスの低下をもたらす。
【０００８】
特に、本発明が対象とする協調作業中に共有されるデータに関しては、このような状況下での更新要求の集中に原因して、各クライアントへの『レスポンスタイムの遅れ』や『トランザクションアボートの増大』などサービスの低下のみならず、その処理のために他の協調作業処理が阻害されるなどの問題が発生する。つまり、共有データへのアクセスを適切に制御して、協調作業のサービスのレベルを保障することが出来ないと、協調作業の進行に支障が出るという問題がある。協調作業におけるサービスレベルが正しく制御されないことによる具体的な問題点は、以下のようにまとめられる。
【０００９】
（１）データ共有機能自身における各クライアントへのサービスの低下。例えばレスポンスタイムの遅れやトランザクションアボートの増大などである．
（２）他の協調作業処理の阻害。例えば、セッション内の交渉機能の阻害などである。
【００１０】
本発明は、上記の問題に鑑みてなされたものであり、共有資源の競合に原因する協調作業のサービスレベルの低下を防止することが可能な情報処理方法及び装置を提供することを目的とする。
【課題を解決するための手段】
【００１１】
上記の目的を達成するための本発明の一態様による情報処理装置は以下の構成を備えている。即ち、
複数のクライアントによる協調作業が可能なシステムを構成する情報処理装置であって、
セッションに参加している複数のクライアント間で共有されている協調操作対象のデータへの操作頻度を検出する検出手段と、
前記検出手段で検出された操作頻度が所定値を越えた場合、前記複数のクライアントを複数のグループに分割する分割手段と、
前記分割手段で分割されたグループの夫々に協調操作対象として前記協調操作対象のレプリカを対応づける処理手段とを備え、
前記複数のクライアントの各々は、所属するグループに対応づけられた協調操作対象に対して操作を行う。
【００１２】
上記の構成によれば、複数のクライアントによる協調作業の実行において、検出手段は、セッションに参加している複数のクライアント間で共有されている協調操作対象のデータへの操作頻度を検出する。分割手段は、検出手段で検出された操作頻度が所定値を越えた場合、前記複数のクライアントを複数のグループに分割する。更に処理手段は、前記分割手段で分割されたグループに協調操作対象として協調操作対象のレプリカを対応づける。そして、複数のクライアントの各々は、所属するグループに対応づけられた協調操作対象に対して操作を行う。操作対象のレプリカを生成し、一つの操作対象に対する操作を減少させることで、操作負荷が分散されるので、サービスレベルの維持が図られる。即ち、協調作業を管理するサーバ等の１つ当たりのクライアント数を分散することでサービスレベルの維持を図るものである。
【００１３】
また、好ましくは、前記分割手段は、前記協調作業への参加時刻に基づいて前記複数のクライアントを複数のグループに分割する。協調作業について、同レベルの熟練度のクライアントをそろえることで、より効果的な協調作業を行なえるからである。
【００１４】
また、好ましくは、前記分割手段は、協調作業対象へのアクセス分布に基づいて前記複数のクライアントを複数のグループに分割する。更新要求や参照要求の衝突が発生しにくいようにクライアントを分割することが可能となるからである。
【００１５】
また、好ましくは、前記分割手段は、前記複数のクライアントに対して分割の指示を行い、該複数のクライアントは各クライアント間の交渉によって複数のグループに分割される。協調作業を管理するサーバ等の処理負担が軽減されるからである。
【発明の効果】
【００１６】
以上説明したように本発明によれば、共有資源の競合に原因する協調作業のサービスレベルの低下を防止することが可能となる。
【発明を実施するための最良の形態】
【００１７】
以下に添付の図面を参照して本発明の好適な一実施例を説明する。
【００１８】
＜実施例１＞
本実施例１では、複数人が参加する協調編集作業において、共有データへのアクセス履歴を利用して、協調作業におけるレスポンスタイムやトランザクション達成率（コミット成功率）など適切なサービスレベル（Quality of Service）を維持する場合について説明する。特に、協調編集作業中において利用されている共有データ（例えば、編集対象の文書）についての更新度合が所定の値を越えた場合に、協調作業に関与しているクライアントの一部に更新操作禁止の制約を課す例について述べる。
【００１９】
すなわち、本実施例１は、協調作業のサービスレベルを維持するために、
（１）共有データへの更新度合を観測している点と、
（２）協調作業のクライアントの一部を更新操作禁止に制約することで、残りのクライアントのサービスレベルを向上させる点と、
に特徴がある。
【００２０】
また、本実施例１では、データ共有機構内部において同様のサービス維持処理を実現した場合に比べて、個々のデータアクセス要求ではなく、協調作業のクライアントという、より大局的な単位で制約を課せることに特徴がある。
【００２１】
以下、まず本実施例を説明するための装置の構成について説明し、次に、その動作手順について述べる。
【００２２】
［１］構成の説明
図１は、本実施例１の情報処理システムを説明するブロック構成図である。同図において、１０１は入力装置であり、本実施例上で動作するプログラムの利用者が、コマンドやデータを入力する。入力装置１０１は、キーボード、マウス、パッド、あるいは、マイクロフォンなどで構成される。１０２はＣＰＵであり、本実施例の協調編集作業ソフトウェアならびにサービス維持プログラム１０を実行する。ここでは、一つのＣＰＵを使っているが、それぞれに独立なＣＰＵを利用するようなハードウェア形態であっても構わない。
【００２３】
１０３は、本実施例における協調編集作業システムの内容、および、サービス維持プログラム１０の結果（データアクセスモードの変更のメッセージなど）をユーザに表示するための出力装置で、ＣＲＴディスプレイあるいはプロジェクターなどである。ここでは、説明を簡単にするため、単一の表示装置を使って複数の協調編集作業用の表示を行っているが、それぞれに独立な表示装置を使ってもかまわない。
【００２４】
１０４は記憶装置であり、本実施例で説明する協調編集作業、サービス維持プログラム１０などを実現する制御プログラム、ならびに、それらのプログラムが利用するデータを保存する。ここでは、説明を簡単にするために、単一の記憶装置を使っているが、記憶対象毎に異なった記憶装置を用いてもよいし、ハードディスクなどの二次記憶装置を含む階層化された記憶装置であってもよい。
【００２５】
なお、ここにプログラムとして保存されている制御プログラムは、具体的には、サービス維持プログラム１０、観測プログラム２０、調整プログラム３０（図３参照）である。また、この記憶装置１０４は、一時的に使われるデータを記憶する主記憶装置と大量のデータを永続的に保持しておく二次記憶装置とに分かれていても良い。また、装置の状態に関係なく永続的なデータを保存するＲＯＭなど読み出し専用記憶装置が含まれていても良い。
【００２６】
１０５は通信装置であり、計算機ネットワークに接続するＦＤＤＩコントローラなどである。１０６は計算機バスであり、以上に述べた各構成要素１０１〜１０５を結合する。
【００２７】
１００は端末を示し、上記１０１〜１０６によって構成される協調編集作業を行うことが可能である。また、２００及び３００は、端末１００と同様の構成の協調編集作業用の端末である。端末１００、２００、３００は、それぞれの参加者に対して、協調作業を行なうための入出力ならびに処理を行なう。尚、本例では３つの端末を利用する構成について説明するが、端末の数は、２つあるいは４つ以上であってもよい。
【００２８】
５０００は、本実施例で説明する協調編集作業を複数の計算機に渡って実現するための計算機ネットワークであり、例えば、Ｅｔｈｅｒｎｅｔ（登録商標）やＦＤＤＩなどである。本実施例では、汎用の計算機を利用した実現形態について説明しているため、その通信手段として計算機ネットワークを用いているが、これは、ＩＳＤＮなどの広域回線であってもよい。
【００２９】
次に、本実施例１のソフトウェア構成について説明する。
【００３０】
まず、大きくプログラムの実行単位、例えば、ＵＮＩＸ（登録商標）におけるプロセスのレベルで見た場合のソフトウェア構成について説明する。この観点から見た場合、各端末では、協調編集用ソフトウェアが実行されており、協調編集作業への参加者は、それぞれ別々の端末に配置されている。図２に実施例１における協調編集作業の状態を示す。また、いずれかの端末（例えば端末１００）では、セッションサーバーが実行されている。
【００３１】
図３に実施例１におけるセッションサーバのプログラム構成を示す。ここで、セッションサーバは、協調作業を行うに当たって必要となる各種の機能（たとえば、セッション内の交渉機能やデータ共有機構など）を提供するサーバである。以下に詳細を説明するサービス維持プログラム１０や観測プログラム２０などは、このセッションサーバ内で動作する。
【００３２】
［２］動作手順の概要
次に、本実施例における処理の動作手順についての概要を述べ、次に詳細な動作を説明する。
【００３３】
図４は実施例１のシステム上で動作する協調編集作業におけるサービス維持プログラム１０の処理手順を表すフローチャートである。
【００３４】
本処理は、セッションサーバのデータ共有機構によってクライアント（ここでは、協調編集作業用ソフトウェア）間で共有されているデータに関する更新要求の度合いが、あるしきい値を越えた際に、ある条件で選択された一部のクライアントを更新操作禁止に制約すること、すなわち、一部のクライアントを犠牲にすることで、目的とする協調編集作業におけるサービス維持を実現する。
【００３５】
また、本処理は、セッションサーバ内の処理であるが、各クライアントからの要求に応じてセッションサーバ内で進行する協調作業（ここでは、協調編集作業）とは、非同期に実行される。この非同期の実行に関しては、たとえば、Ｍａｃｈオペレーティングシステムに実装されているｔｈｒｅａｄパッケージなどを利用することで実現可能である。この際、協調作業中に共有されるデータに関しては、一貫性を保持したｒｅａｄ操作が行なわれるものとする。
【００３６】
なお、本実施例１では、観測プログラム２０において『該当セッション内の共有されているデータへの更新要求が、１０秒間に２００回以上であるか？』を観測し、調整プログラム３０において『もっとも最近にセッションに参加したクライアント』を選択し、その『更新操作を禁止する』という制約を課すポリシーとする。
【００３７】
まず、 観測のための一定時間待つ（ステップＳ１００１）。例えば、ここでは、観測条件に合わせて１０秒間とする。次に、観測プログラム２０により、共有されているデータへの更新要求度合とそのしきい値との関係を調べる（ステップＳ１００２）。そして、しきい値を越えているなら、ステップＳ１００３よりステップＳ１００４へ進み、調整プログラム３０を実行する。その後、ステップＳ１００１にもどる。また、ステップＳ１００３においてしきい値を越えていないなら、そのままステップ１００１へもどる。
【００３８】
ここでは、説明を簡単にするために協調作業と非同期実行する場合について説明しているが、協調作業との間にデータの一貫性を保障するためには、適切な同期手段、たとえば、ロック機構などを用いてもよい。反対に、一貫性を必要としない場合には、ｄｉｒｔｙ ｒｅａｄの技法などを用いることで実行性能の向上を図ることも考えられる。
【００３９】
本実施例１で説明したサービス維持プログラム１０の動作は、永久ループで構成されており、セッションサーバの実行が続く限り、サービス維持プログラム１０も動作し続けるものとなっている。しかしながら、サービス維持プログラム１０の動作形態はこれに限られるものではなく、例えば、セッションサーバへの協調作業の要求に同期して、サービス維持プログラム１０を動作させるようにしてもよい。
【００４０】
［３］観測プログラム２０
次に、本実施例１のサービス維持プログラム１０のステップＳ１００２において参照した更新要求度合としきい値との関係を測定するための観測プログラム２０を説明する。図５は実施例１による観測プログラムの処理手順を説明するフローチャートである。ここでは、協調編集作業ソフトウェアの中で利用する共有データのアクセス統計情報を観測する例について説明する。
【００４１】
まず、本システムにおけるデータ共有機構に、アクセス統計情報のうち、『過去１０秒間の更新情報』を問い合わせる（ステップＳ２００１）。尚、本システムにおけるデータ共有機構は、協調編集作業において、各端末からの更新要求の回数を測定する機能を有する。
【００４２】
次に、得られた更新情報の更新要求回数をカウントして、予め設定してあったしきい値（本例では２００）と比較する（ステップＳ２００２）。本実施例では、カウントに際して、更新対象のオブジェクトには無関係に、更新要求回数をカウントするものとする。そして、比較結果を観測結果として返す（ステップＳ２００３）。
【００４３】
ここでは、更新要求回数をカウントしているが、実際にコミットされた更新回数をカウントするように構成してもよい。
【００４４】
また、本例では、更新要求の対象となるオブジェクトと無関係に要求回数をカウントしているが、対象となるオブジェクトを限定して、例えば、協調作業の実行性能にクリティカルなオブジェクトへの要求回数をカウントするように構成してもよい。
【００４５】
更に、共有データに対して複数のセッションモードから更新要求等の操作要求がある場合は、複数のセッションモードからの操作要求を観測するように構成してもよい。
【００４６】
［４］調整プログラム３０
次に、本実施例のサービス維持プログラム１０のステップＳ１００４で実行される調整プログラム３０について説明する。図６は、実施例１による調整プログラムの処理手順を表すフローチャートである。本プログラムは、ある条件で選択された一部のクライアントを更新操作禁止に制約することにより、つまり、一部のクライアントに犠牲を強いることにより、協調作業における共有データの更新作業量を減らし、これにより、協調作業のサービスを提供するセッションサーバにかかる負荷の低減を図るものである。なお、本実施例１では、協調編集用ソフトウェアが、クライアントに相当する。
【００４７】
まず、協調作業に参加しているクライアントの一部を選択する（ステップＳ３００１）。ここでの選択条件は、『もっとも最近にセッションに参加したクライアント』である。次に、選択されたすべてのクライアントについて、更新操作禁止となるように制約を課す（ステップＳ３００２）。これは、例えば、協調作業システムのデータ共有機構に制約の内容を保持し、該当するクライアントからの更新要求を無視あるいは拒否するように設定することで実現可能である。
【００４８】
ここでは、説明を簡単にするために、データ共有機構が該当するクライアントからの更新要求を無視あるいは拒否する例について説明したが、実行効率を向上させるために、クライアントに、その旨通知し、以降の更新要求の発行自体を抑制することで実現することも考えられれる。
【００４９】
ここでは、一部のクライアントを選び出し制約を課す例について説明したが、すべてのクライアントに関して、単位時間中にデータ共有機構に発行可能な更新要求の上限を設定するような制約も考えられる。
【００５０】
ここでは、説明を簡単にするため、『もっとも最近にセッションに参加したクライアント』を調整対象として選択したが、他の選択方法も容易に想像できる。たとえば、仮想記憶管理における ＬＲＵ 手法と同様に、最後のアクセスがあったのが最も古いクライアントを選択することである。また、セッションサーバが各クライアント毎に、何らかの優先順位を保持し、それを利用することも可能である。
【００５１】
また、本実施例では、セッションサーバが、協調作業中に利用するデータ共有機構の統計情報を観測することで、本実施例のサービス維持の処理を実現する例について説明したが、協調作業システムの通信機構の統計情報を観測することで同様の処理を実現するように構成してもよい。
【００５２】
また、本実施例では、協調作業の負荷の軽減を図るために、更新操作禁止の制約を課しているが、これは、データ共有機構において、読み出し操作に比べて、更新操作の負荷が高いことを前提としているためである。共有データ機構がより柔軟なアクセスモードを支援している場合は、読み出し操作禁止等の更新操作禁止以外の制約を課してもよい。
【００５３】
また、ここでは、共有データ機構へのアクセス制限という制約を課すことによって調整を行っているが、選択条件によって選びだされたクライアントを協調作業から除去することで、残りのクライアントへのサービスレベルを維持するようなポリシーをとってもよい。
【００５４】
また、本実施例では、クライアントに対して更新操作禁止を指定する処理を示したが、更新要求の低減時に、再び更新操作可能に戻す構成を設けてもよい。また、通信システムにおけるトークンリング方式と同様に、更新操作禁止状態にあるクライアントを、協調作業に関っているクライアント群の中で周期的に切り替えるようにしてもよい。
【００５５】
以上説明したように、本実施例によれば、協調作業における一つのセッションサーバの負荷が適切なレベルに維持され、結果として、セッションサーバの提供するサービスのレベルが維持される。すなわち、観測プログラムが『該当セッション内の共有されているデータへの更新要求が、１０秒間に２００回以上であるか？』を観測し、その観測結果に応じて、調整プログラムが『もっとも最近にセッションに参加したクライアント』を選択し、『更新操作を禁止する』という制約を課すことで、制約を受けない残りのクライアントには、制約操作以前よりも多くのサービスをセッションサーバから受けることが可能となる。この結果として、レスポンスタイムの増大やトランザクション失敗率（アボート率）の増大などのようなサービスレベルの低下を回避することができる。
【００５６】
＜実施例２＞
次に実施例２を説明する。
【００５７】
本実施例２では、実施例１と同様、複数人が参加する協調編集作業においてサービスレベルを維持する。特に、実施例１の調整プログラムによる調整処理において、調整対象として特定のクライアントを選択することをせずに、クライアント群を分割することでデータ共有機構における負荷分散を行うことで、十分なサービスレベルの維持を可能とすることを特徴とする。
【００５８】
［１］実施例２の動作手順の概要
本実施例２では、実施例１と同様の構成の元で、同様のサービスレベルの維持を行なう。ただし、調整プログラム３０の代りに拡張調整プログラムを用いて調整を行い、サービスレベルの維持を図る。
【００５９】
［２］拡張調整プログラム
拡張調整プログラムは、図３に示したセッションサーバ中のサービス維持機能における調整プログラム３０に置き換えられたものである。図７は、実施例２による拡張調整プログラムによる制御を表すフローチャートである。本プログラムは、ある協調作業中のクライアント群を２つのグループに分割することで、協調作業における共有データ機構の更新負荷を減らし、これによって、協調作業の負荷低減を図るものである。
【００６０】
まず、協調作業に参加しているクライアント群を参加時刻順に整列し、前後２つに分割する（ステップＳ５００１）。説明を明確にするために、それぞれをグループＡ、グループＢと呼ぶ。
【００６１】
次に、セッションサーバのデータ共有機構が保持しているオリジナルの共有データのレプリカを生成し、グループＢに関しては、このレプリカを利用するように設定しなおす（ステップＳ５００２）。これは、例えば、オブジェクト指向データベースシステムなどに実装されているバージョニング機能によって実現できる。
【００６２】
次に、２つのグループのクライアントについて、「グループを分割し共有データのレプリカを生成したので、定期的にマージ操作を行う必要がある」旨をメッセージする（ステップＳ５００３）。マージ操作に関しては、バージョニング機能の一部として実装されている。例えば、オブジェクト指向データベースシステムにObjectStoreを利用した場合、関数os_configuration::merge()を利用することでマージ操作を達することができる。
【００６３】
本実施例２では、説明を単純にするために、レプリカ生成後のオリジナルデータとのデータの一貫性については、クライアントがマージ操作を非同期に実行することに委ねている。この他に、データ共有機構を拡張して、オリジナルデータの更新に同期して、レプリカデータの一貫性を保証するようなプロトコルを追加することも考えられる。
【００６４】
例えば、分散データベースシステムにおけるデータコヒーレンシーアルゴリズムが利用できる。ここでは、データ共有機構の負荷の低減を図る目的から、weakconsistencyモデルの実現手法について述べる。つまり、オリジナルデータの更新が発生した際には、そのトランザクションのコミット時点で、レプリカの不活性化（invalidate）を行なって、以降のレプリカデータへのアクセス時にオリジナル側から複写する手法である。このような手法を利用することで、トランザクションがコミットされるまでは、レプリカデータの利用が可能になるので、それだけオリジナルデータ側のデータ共有機構の負荷が低減される。
【００６５】
また、本実施例２では、参加時間順に並べてクライアント群の分割を行ったが、共有データ機構内のデータへのアクセス分布を参照して、参照要求あるいは更新要求の衝突が発生しにくいようなクライアント群の分割を行うことも考えられる。
【００６６】
また、本実施例２では、クライアント群を２つのグループに分割しているが、３つ以上のグループに分割することも上記実施例の記載から実現できることは明らかである。
【００６７】
さらに、本実施例２では、グループの分割をセッションサーバ側の決定に基づいて行っているが、セッションサーバは、アドバイスのメッセージを出すのみで、実際のグループ分割は、クライアント間の交渉に委ねるようにしてもよい。
【００６８】
以上のように、本実施例２によれば、協調作業において、１つのセッションサーバの負荷が適切なレベルに維持され、結果として、実施例１と同様に、セッションサーバの提供するサービスのレベルが維持される。
【００６９】
以上説明したように、上記各実施例によれば、協調作業におけるデータ共有機構へのアクセスを調整することにより、データ共有機構依存の更新負荷の低減を図り、これによって、共有作業のサービスレベルを維持することが可能になる。これらの結果、具体的には、次のような効果が達成される。即ち、（１）レスポンスタイムの向上やトランザクションアボートの減少など、データ共有機能における各クライアントへのサービスの向上、（２）ならびに、他の協調作業処理の阻害の減少である。
【００７０】
尚、上記実施例１では、クライアントに対して機能制限を課すが、操作頻度が所定の閾値を越えた場合は新規のクライアントの参入を禁止するようにしても良い。たとえば、リアルタイムに変更が求められるようなデータを共有するデータベースサービスを想定した場合に適用できる。具体的な例としては、動画を提供するデータベースサーバの能力が４クライアントへのサービス能力しかないにもかかわらず、５クライアント以上の要求が来てしまったなどの状況に適用することができる。
【００７１】
尚、本発明は、複数の機器から構成されるシステムに適用しても１つの機器からなる装置に適用しても良い。また、本発明はシステム或いは装置に本発明により規定される処理を実行させるプログラムを供給することによって達成される場合にも適用できることはいうまでもない。
【図面の簡単な説明】
【００７２】
【図１】本実施例１の情報処理システムを説明するブロック構成図である。
【図２】実施例１における協調編集作業の状態を示す図である。
【図３】実施例１におけるセッションサーバのプログラム構成を示す図である。
【図４】実施例１のシステム上で動作する協調編集作業におけるサービス維持プログラム１０の処理手順を表すフローチャートである。
【図５】実施例１による観測プログラムの処理手順を説明するフローチャートである。
【図６】実施例１による調整プログラムの処理手順を表すフローチャートである。
【図７】実施例２による拡張調整プログラムによる制御を表すフローチャートである。
【符号の説明】
【００７３】
１００、２００、３００ 端末
１０１ 入力装置
１０２ ＣＰＵ
１０３ 出力装置
１０４ 記憶装置
１０５ 通信装置
【図１】
2005100432.tif 000003
【図２】
2005100432.tif 000004
【図３】
2005100432.tif 000005
【図４】
2005100432.tif 000006
【図５】
2005100432.tif 000007
【図６】
2005100432.tif 000008
【図７】
2005100432.tif 000009