JP4270850B2

JP4270850B2 - 文書集合の修正版を配信する方法及びシステム

Info

Publication number: JP4270850B2
Application number: JP2002341312A
Authority: JP
Inventors: アールサビツキーステフェン; ウォルフグレッグ; ローズブラドリー
Original assignee: Ricoh Co Ltd
Current assignee: Ricoh Co Ltd
Priority date: 2002-02-26
Filing date: 2002-11-25
Publication date: 2009-06-03
Anticipated expiration: 2022-11-25
Also published as: JP2003256259A; US20030163552A1; US7451236B2

Description

【０００１】
【発明の属する技術分野】
本発明は、文書配信及び保管システムに関連する。
【０００２】
【従来の技術】
大きなサイズの組織では、組織の通常の運営中に、数えられない数の文書が発生される。タイミングの良い方法で、情報があて先に達するように、文書の配信と文書の取り出しは、効率的な操作であることが必要とされる。組織が大きな地理的な領域をわたり、広く分散している場合には、これは、つまらないタスクにはならない。情報が加えられ、除去され又は、その他修正されるときには、追加の情報は、同様に、情報が最新であることを保証するためには、効率的に広められなければならない。
【０００３】
種々の考えが考慮されねばならない。物理的な保管の制限は一般的には、組織を通しての文書の理性のない力の大規模な複写に関連する解決方法を排除する。典型的には大規模なマルチメディアファイルの場合には、そのようなファイルを全てのサイトに送るのに要する帯域幅は、禁止的になる。
【０００４】
他の技術は、ピアツーピア構造であり、組織内の各サイトでのファイルサーバは、他のファイルサーバをアクセスできる。しかしながら、このアプローチは、ファイアーウォールのような安全性の特徴の使用を制限する。
【０００５】
共有ファイルシステムは、文書を共有するための他の普通に使用されている構造である。しかしながら、共有ファイルシステムの中央化した性質は、多くのユーザによりロードされたときに劣化した性能を示す。共有ファイルシステムは、ある状況では受け入れることが出来ない、制限された安全性の特徴を有する。
【０００６】
【発明が解決しようとする課題】
本発明の目的は、文書が、各宛先で、オリジンサーバを示す情報により確認される、文書配信及び保管システム及び方法を提供することである。
【０００７】
【課題を解決するための手段】
本発明の実施例に従った文書配信及び保管システム及び方法は、各文書に、それが形成されたサーバシステム（オリジンサーバ）を示す情報を含む（名前のような）識別子を提供することを含む。配信リストは、文書が配信されるサーバを識別する。文書は、各宛先で、オリジンサーバを示す情報を含む、ローカル識別子により識別される。通知リストは、文書が通知されるべきユーザを識別する。
【０００８】
以下に、本発明に従った特定の実施例について説明するように、識別子の命名の慣例は、ワールドワイドウェブ（ＷＷＷ）ユニバーサルリソースロケータ（ＵＲＬ）命名機構に基づいている。識別子は、２つの部分：ローカルサーバを識別する”ｈｔｔｐ：／／ｈｏｓｔｎａｍｅ”及び、”パス”と呼ばれるＵＲＬの残りの部分でありそして各ローカルサーバで同じである”／ＤＲＩ／．．．”を含む。
【０００９】
文書への変更は、同様な方法で配信される。しかしながら、文書は、文書が配信されたどのサーバでも変更できる。変更された文書は、（おそらく、ローカル識別子がオリジンサーバを確認する情報を含むということにより）その対応するオリジンサーバへ送られそして、配信リストに従って配信される。配信リストと通知リストは、同様に変更されることが可能である。これらのリストは、文書及び各々の新たなバージョン（版）の文書と関連したまま残る。
【００１０】
各バージョンの文書は保守される。配信及び通知リストは、１つのバージョンの文書から他のバージョンの文書で、異なることが可能である。
【００１１】
リソースは、ここでは、文書又は、文書の集合を指すのに使用する用語である。文書配信及び保管システムは、リソースの集合を管理する。従って、文書を、個々の未関連の文書として及び、関連する文書の集合として組織化することが可能である。新たなバージョンのリソースを発生する”リソース”への変更は、単一の文書の変更又は、文書の集合の中の２つ又はそれ以上の文書の変更を含むことが可能である。
【００１２】
【発明の実施の形態】
本発明の教示は、添付の図面を参照して、以下の詳細な説明により、容易に理解される。
【００１３】
図１は、本発明の種々の実施例に従った文書管理システム１００一般化された基本的な構成の構成要素を示すハイレベルブロック図である。”文書”は、制限はされないが、テキスト、オーディオ情報、ビジュアル情報、そのような情報の組合せ、等を含む情報の集合である。従って、例えば、動画ビデオ文書は、ビデオ及びオーディオ情報を含むファイルを有しても良い。代わりに、情報の集合は、１つ又はそれ以上の個々のファイル内にあってもよい。例えば、動画ビデオ文書は、ビデオファイルと別のオーディオファイルを有してもよい。この場合には、’文書’は、２つ又はそれ以上のファイルを含む論理的な実体である。用語”リソース”は、個々の文書又は、文書の集合を指すのに使用される。用語”リソース”の特定の意味は、それが使用される文脈から決定できる。リソースが文書の集合を指すときには、用語”集合リソース”が使用される。複数のリソースが、本発明の実施例に従って、配信文書メモリ（ＤＤＳ）内に、集合的に保管される。
【００１４】
図１に示すシステム１００は、複数のコンピュータシステム１０２、１０４、１０６を有する。各コンピュータシステムは、そのユーザに種々のコンピュータサービスを提供することができる。従って、ユーザ１２２は、コンピュータシステム１０２からのサービスを要求する。同様に、ユーザ１２４は、コンピュータシステム１０４からのサービスを要求し、そして、ユーザ１２６は、コンピュータシステム１０６からのサービスを要求する。コンピュータシステム１０２、１０４、１０６に名前をつけるのに共通に使用される用語は、コンピュータがそのユーザにサービスを提供するので、”サーバ”である。ユーザ１２２、１２４、１２６に名前をつけるのに共通に使用される用語は、”クライアント” である。クライアントは、適切なクライアントソフトウェアを介してサーバにアクセスする、人間のユーザでもよい。クライアントは、自動化されたタスクを実行するために、サーバにアクセスする、機械実行する適切なクライアントソフトウェアでもよい。
【００１５】
クライアント（”ユーザ”）１２２、１２４、１２６は、幾つかの既知の通信方法の何れでも、それぞれのサーバにアクセスできる。例えば、クライアントＣ_Ｌは、ローカルエリアネットワーク（ＬＡＮ）を介して、又は、ワイドエリアネットワーク（ＷＡＮ）を介してサーバに接続しうる。クライアントＣ_Ｒは、ダイアルアップ電話接続を介してサーバに接続しうる。クライアントは、無線技術を介してサーバに接続しうる。これらのそして他の通信技術は、当業者の理解する範囲内である。サーバとクライアントの間で採用されている特定の通信媒体は、システムコスト、データスループット等のような、本発明の実行には関連しない考えにより、決められる。
【００１６】
図１は、互いにデータ通信をしているサーバ１０２，１０４，１０６も示す。クライアント−サーバリンクで、多くのどのよう既知の通信技術も、サーバ間でデータ通信を提供するのに、使用できる。クライアント−サーバリンクで、サーバ対サーバ通信に使用される特定の通信技術は、本発明の実施に関連しない考えに主に依存する。しかしながら、リンクは双方向（例えば、両方のサーバが接続を開始する）であるかどうかのような、安全性に関連するリンク特性（例えば、両方のサーバが接続を開始する）は、システム内の文書への安全なアクセスを提供するために、考慮されねばならない。
【００１７】
本発明の特定の実施例に従って、コンピュータシステム１０２、１０４、１０６は、ワールドワイドウェブ（ＷＷＷ）サーバである。ワールドワイドウェブは、本発明の文書管理システムに適する、一般に良く知られたサーバプラットフォームである。ウェブ通信プロトコル、ハイパーテキスト転送プロトコル（ＨＴＴＰ）は、サーバとクライアントの間の通信プロトコルとして及び、文書リソースの名称付けの基礎の両方として働く。典型的には、サーバ対サーバ通信は、ＨＴＴＰに基づいているが、しかし他のプロトコルも使用できる。
【００１８】
従って、この種のクライアントソフトウェアは、一般に、”ウェブブラウザ”と呼ばれる。従来利用できるブラウザが使用されそして、適切に書き込まれた”プラグイン”モジュールが必要ならば供給される。カスタムクライアントも書き込まれることができる。しかしながら、サーバがウェブサーバであるという要求はないことは理解される。カスタムサーバとクライアントソフトウェア及び適切な通信プロトコルは、本発明の開示された教示に従って動作するように書き込まれることができる。
【００１９】
本発明の特定の実施例に従った文書管理システムは、ウェブベースのマルチメディアメッセージングサービスのバックエンドを構成する、協働して動作するウェブサーバの組みを有する、配信及び保管システムである。最も高いレベルでは、文書管理システムは、集合的に”配信された文書メモリ”と呼ばれる関連する”メッセージ”の組みを管理する。配信された文書メモリを有する”メッセージ”は、ウェブリソース：文書又は文書の集合により表される。更なる詳細を以下で説明するように、リソースは形成されそして、１つのサーバにアップロードされ、そして、システム内の他のサーバに配信される。リソースは変更されそして、同様に、サーバに配信される。リソースに関連するユーザは、通知される。
【００２０】
（リソースのコピーを含む）各リソースは、文書配信及び保管システム内の位置を示す情報に、関連する。各リソースは更に、以後”オリジンサーバ”と呼ぶその起源のサーバを示す情報を含む、唯一の識別子に関連する。本発明のこの特定の実施例に従って、リソースは、ウェブページのように扱われ、そして任意のウェブページのように、各リソースはユニバーサルリソースロケータ（ＵＲＬ）に関連する。本発明のこの特定の実施例に従って、ＵＲＬのパス部分は、以後”配信リソース識別子”（ＤＲＩ）と呼ぶ、唯一の識別子を構成する。慣例により純粋に、以下の一般的な名称付けフォーマットが、ＤＲＩに使用される。
．．．／−ＤＤＳ−／ＯＲＩＧＩＮ／．．．，
ここで、ＤＤＳはリソースの特定の集合の名称であり、ＯＲＩＧＩＮはＤＲＩにより確認されるリソースに対するオリジンサーバの完全に限定されたホスト名である。
【００２１】
このように、例えば、リソースが以下のＵＲＬを有するとする：
ｈｔｔｐ：／／ｍａｃｈｉｎｅ１．ｃｏｍ／−ｍｓｇ−／ｍａｃｈｉｎｅ２．ｃｏｍ／２００１／ｊｏｎｅｓ／０／ｔｈｅ−ｄｏｃｕｍｅｎｔ
このリソースは、”−ｍｓｇ−”と名づけられたリソースの集合に属する。このリソースの特定のコピーを含むホストマシンは、”ｍａｃｈｉｎｅ１”と名づけられる。リソースのオリジナルコピー（即ちその発生場所）は、”ｍａｃｈｉｎｅ２”と名づけられたマシン内にある。この例では、リソースは”ｔｈｅ−ｄｏｃｕｍｅｎｔ”と名づけられた単一の文書である。本発明のこの特定の実施例では、リソースはディレクトリ内に含まれ、他のデータストレージ慣例が使用できるが、例えば、リソースはデータベース内に蓄積される。
【００２２】
ホストマシン（”ｍａｃｈｉｎｅ１”）とオリジンマシン（”ｍａｃｈｉｎｅ２”）の両方は、以下のディレクトリ構造とＵＲＬ名称付け構造を有する。各マシンは、それぞれのサーバの”ｄｏｃｕｍｅｎｔｒｏｏｔ”ディレクトリ内に、”−ｍｓｇ−”と呼ばれるディレクトリを有する。各マシンでは、”−ｍｓｇ−”ディレクトリは、”ｍａｃｈｉｎｅ２．ｃｏｍ”上で発生される全てのメッセージを含む、”ｍａｃｈｉｎｅ２．ｃｏｍ”と呼ばれるサブディレクトリを有する。付随的に、各マシン内の”−ｍｓｇ−”ディレクトリは、”ｍａｃｈｉｎｅ１．ｃｏｍ”上で発生されるメッセージのための、”ｍａｃｈｉｎｅ１．ｃｏｍ”と呼ばれるディレクトリをも有する。
【００２３】
リソースが文書の集合である場合には、ＵＲＬのターミナル成分は、ディレクトリ名である。従って、以下のＵＲＬは、文書の集合を有するリソースを識別し、即ち、文書の集合が見つかるディレクトリのみが名称をつけられる、即ち、”／ｍｓｇ／２００１／ｊｏｎｅｓ／０／”。
ｈｔｔｐ：／／ｍａｃｈｉｎｅ１．ｃｏｍ／−ｍｓｇ−／ｍａｃｈｉｎｅ２．ｃｏｍ／２００１／ｊｏｎｅｓ／０／
図２は、本発明の他の実施例の一般的なシステム構成を示す。この特定の例では、オリジンサーバ（例えば、サーバ２０２）及び宛先サーバ（例えば、サーバ２０６）は相互にアクセスできない。しかしながら、１つ又はそれ以上の中間サーバ２４２，２４４が存在し、オリジンと宛先サーバが、中間サーバを介して情報を中継することにより、情報を交換することを可能とする。
【００２４】
図３は、宛先サーバ３０２がファイアウォールメカニズム３０１により保護されている、本発明の他の実施例の一般化されたシステム構成を示す。典型的には、ファイアーウォールは、宛先サーバが他のサーバをアクセスすることを許すが、しかし、（オリジンサーバを含む）外部のサーバ３１２、３１４からの、宛先サーバをアクセスする入力する要求は許さない。各々の他のサーバ３１２，３１４は、宛先サーバ３０２に関連している各マシン内で、それぞれ設定される、キュー（待ち行列）形式の機構３２２、３２４を有する。宛先サーバ３０２は、周期的に、要求について、各マシン内の関連するキュー（待ち行列）をチェックする。以下に説明するように、このキュー（待ち行列）機構はファイアーウォールを有するサーバに、リソースを配信するのに使用される。図３は、ファイアウォール３０３を有する他のサーバ３０４も示す。サーバ３１４は、サーバ３０４によりポーリングされる、サーバ３０４に対応する、第２のキュー（待ち行列）３２６を有する。サーバ３１４は、サーバが複数のサーバについての複数のキュー（待ち行列）を有することができることを示す。
【００２５】
本発明の実施例に従ってリソースを生成する処理の説明のために、図４を参照する。ハイレベルフローチャート４００は、リソースを生成しそして、続いて新たに生成されたリソースを配信する基本的なステップを示す。一般的には、以下のステップが発生する：
−クライアントが、処理を発生するために、オリジンサーバに接続する。
−クライアントが、新たなリソースを生成するようにサーバに要求する（ステップ４０２）。
−クライアントが、サーバ及び／又はユーザの配信リストを含む文書をリソースにアップロードする（ステップ４０４，４０６）。
−クライアントが、コミットし且つ配信を開始することを、サーバに要求する（ステップ４０８）。
−オリジンサーバは、ユーザ（受信者）を、アクセスできるサーバにマップし、そして、それらのサーバを、配信リストに追加する。
−各サーバは、そのローカルサーバに、ローカルサーバのＵＲＬを規定する電子メールを介して、通知する（ステップ４１０）。
−オリジンサーバは、リスト上の各他のサーバにリソースを配信する（ステップ４１２）。
【００２６】
このように、ステップ４０２で、クライアント（人間又はマシン）は、新たなリソースを生成するサービスを要求する。リソースは、単一の文書又は、文書の集合である。サーバは（ステップ４２２で）、サーバにリソースを続いてアップロードすることを容易にするために、リソースを識別する予め定められた情報を、供給する。情報はリソース識別子のリストである。この識別子は、任意の方法で生成できる。例えば、ランダム番号発生技術又は、識別子を生成するアルゴリズムさえ使用できる。これは、オンラインか又はオフラインの何れかでリソースを生成し得る現在の複数のクライアントの中の、リソース識別子の複製を避けそしてそれは、名称を推定することを困難にすることにより安全性を提供する。本発明の特定の実施例に従って、ＤＲＩはリソースを識別するために供給される。
【００２７】
リソースを生成するのに加えて、対応する”配信リスト”と対応する”通知リスト”が、ステップ４０４で、生成されたリソースに関連される。配信リストと通知リストは、最初から作られるか又は、現在あるリストからとられるか又は、必要に応じて変更される。リストは、自動的にコンパイルされる。配信リストは、生成されたリソースのコピーが送信されるサーバを識別する。通知リストは、リソースの生成の通知がされる、ユーザ（人間又は、マシン）を識別する。
【００２８】
リソースの生成の処理中に、リソースの初期コピーと配信及び通知リストが、ステップ４０６で、サーバにアップロードされうる。後の編集がなされ、そして、サーバにアップロードされる。このシーケンスは、リソース生成処理が完了したと考えられるまで、何回も繰返されることが可能である。その時に、リソースは、ステップ４０８で、サーバにＣＯＭＭＩＴ要求を送ることにより、クライアントにより“コミット”される。実際には、通知と配信リストは、リソースと共に集合の一部として扱われる。従って、生成されたリソース及び通知及び配信リストはすぐにコミットされる。
【００２９】
新たに生成されたリソースのコピーは、ステップ４１２で、配信リスト内で確認された各サーバに配信される。これは、配信を行う前に、配信リストを変更するサーバを含む。
【００３０】
通知リスト内のユーザは、ステップ４１０で、新たに生成されたリソースの通知をうける。通知は、種々の方法で達成される。例えば、電子メールは、ネットワーク環境内のユーザ間の通信のための一般的なツールであり、そして、ユーザに通知するのに便利である。”インスタントメッセージング”として知られるメッセージング技術は、受信者に知らせるのに使用できる。ページャのような従来の技術も使用できる。通知は、ファックスサービス、インターネットファックスクーリエサービス等により達成できる。ある環境では、サーバーはイントラネット環境に構成され、そして、全体的なインターネットから分離される。従って、イントラネットに局所的なそれらのクライアントのみが、そのようなサーバをアクセスできる。そのような状況では、サーバは、通知リスト内にある自分のローカルクライアントに通知を供給する。
【００３１】
本発明の特定の実施例に従って、リソースが、ローカルサーバにコミットされたとき（ステップ４０８−４１２）に、以下が実行される。コミット処理の基本的なステップは、（１）ローカルサーバ内の初期処理；（２）配信の準備；（３）配信リスト及び通知リスト処理；（４）ファイル転送、を含む。
【００３２】
本発明の特定の実施例は、ウェブサーバシステムに基づいていることを思い出して欲しい。ウェブサーバは、典型的には、共通ゲートウェイインターフェース（ｃｏｍｍｏｎｇａｔｅｗａｙｉｎｔｅｒｆａｃｅ，ＣＧＩ）として知られるプログラム標準を使用する。ゲートウェイプログラム又は、ＣＧＩスクリプトは、それら自身により実行される実行可能なプログラムである。ＣＧＩスクリプトを書くために、幾つかの更に良く知られたそして一般的に使用されている言語は、Ｃ，Ｃ＋＋、Ｐｅｒｌ、Ｐｙｔｈｏｎ、ＴＣＬ及びシェルを含む。ＣＧＩ標準は種々の情報サーバの下で互換的に実行できるので、ＣＧＩ標準は、使用されるが、しかし、そうでなければ本発明に必要ではない。以下は、リソースがコミットされたときに起こる、動作を提供する、ＣＧＩスクリプトの簡単な説明であり、特定の実行の詳細は、ウェブサーバの関連するプログラム技術の当業者の理解の範囲内である。
【００３３】
リソースが生成されそして、サーバにアップロードされた後に、サーバ内で発生する”初期処理”ステップは、”コミット”と呼ばれるＣＧＩスクリプトにより実行される。スクリプトにより提供される機能は、以下を含む。
【００３４】
（１）コミットされたリソースが新たなレイヤのアップロードセッションであり且つ、ローカルサーバは、そのリソースのオリジンサーバである場合には、新たなレイヤ番号が割当てられる。”レイヤ”及び”レイヤ番号”の概念の説明は、以下に示す。
【００３５】
典型的には、リソースがアップロードされるサーバは、オリジンサーバである。しかしながら、ローカルサーバがオリジンサーバでない場合には、リソースは最初にオリジンサーバに転送される。
【００３６】
（２）リソースに関連するメタデータファイルを更新し且つ確認する。メタデータファイルは、リソースの管理を容易にするリソースに関連する情報を含む。メタデータファイルは、集合内のファイルのリストのような情報を含み得る。ｍｉｍｅ形式のようなファイル形式情報が含まれうる；例えば、画像／ｊｐｅｇ、オーディオ／ｗａｖ等である。画像の高さと幅情報がメタデータファイルに蓄積される。オーディオファイルについてのメタデータは、時間情報の長さを含む。メタデータファイルは、サーバへの正しいアップロードを確認するために、チェックサム情報を含むことができる。わかるように、メタデータファイルは、種々の種類のサポート情報を蓄積するのに使用される。
【００３７】
（３）ロカールサーバへのＰＲＥＰ要求をキューに入れる。ＰＲＥＰ要求は、”配信の準備”ステップのを開始する。ＰＲＥＰ要求をキューに入れる代わりに、コミットＣＧＩが、”準備” ＣＧＩスクリプトへコントロールを転送することにより、”準備及び配信”ステップを開始できる（下を参照）。例えば、ＵＮＩＸ（登録商標）−のような環境では、コミットＣＧＩは、処理を分岐させそして、コントロールを新たな処理に渡す。他の良く知られたそして理解される機構も使用できる。
【００３８】
”配信の準備”動作は、”準備”と呼ばれるＣＧＩスクリプトにより実行される。このＣＧＩスクリプトは、ＰＲＥＰ要求に応答して又は、上述と同じ方法で、コミットスクリプトにより発生された処理として実行される。準備ＣＧＩスクリプトは、配信リストを計算し且つ、新たなリソースの情報が与えられるユーザに通知するための情報を準備する。行われる動作は、以下を含む。
【００３９】
（１）通知リストから、サーバにローカルであるユーザを確認する。リソースのコピーが配信されるサーバを、配信リストから確認する。
【００４０】
（２）配信リストと通知リストから、配信／通知ファイルを計算（又は、更新）する。このファイルは、リソースのコピーが配信されるサーバのリストを含む。ファイルは、ローカルサーバにアクセスできないがしかし、配信ファイル内の１つ又はそれ以上のサーバにアクセスできうる、非ローカルユーザのリストも含む。
【００４１】
（３）（オプション）通知メッセージについてのテンプレート、スケーリングされた画像、ＨＴＭＬ（ハイパーテキストマークアップ言語）画像マップ等を含む、補助ファイルを構成する。例えば、通知は電子メールに添付されて伝送されたサムネール画像でもよい。一般的には、補助ファイルは、通知機能を容易にする、どのような有益な自動的に発生されたファイルでもよい。
【００４２】
（４）例えば、インスタントメッセージ、音声メール通知、ファクシミリ伝送等の、非−標準局所的通知を実行する。これは、特化された通知手順を要求する又はそうでなければ要求する、あるローカルユーザを収容することである。
【００４３】
（５）配信／通知ファイルがからでない場合には、ローカルサーバ上で、ＤＩＳＴ要求を、キューに入れる。ＤＩＳＴ要求は、リソース転送処理を開始する他の処理を開始する。実行に依存して、準備ＣＧＩは、上述のように、”配信リスト処理”を実行する処理を発生することにより、単純にコントロールを転送できる。
【００４４】
オリジンサーバは、知っている全てのサーバを有するリストを計算し、そして、それらのサーバへ配信する。各後続のサーバは、初期リストにない、知っているサーバにのみ配信する。このように、配信は最後に処理を停止する。
【００４５】
”配信リスト処理”機能は、”配信”と呼ばれるＣＧＩスクリプトにより実行される。このスクリプトは、ＤＩＳＴ要求を受信するのに応答して又は、準備ＣＧＩスクリプトによる分離処理として分岐された結果として、実行される。配信ＣＧＩスクリプトは、配信／通知リストを通して実行し、そして、そのローカルユーザに、電子メールを送ることにより又は、他の局所的に定義された方法で、通知する。
【００４６】
配信ＣＧＩスクリプトは、配信／通知リストにリストされたサーバに、新たに生成されたリソースを転送するために、要求をキューにも入れる。一般的には、リソース又は集合を転送するのに、（１）ＨＴＴＰＰＯＳＴ又は、データを”プッシュ”するＰＵＴ要求のシーケンスを使用する、又は、（２）データを”プル”するＨＴＴＰＧＥＴ要求のシーケンスを使用する、２つの技術がある。
【００４７】
図１に示された構成では、ローカルサーバと宛先サーバは相互にアクセス可能であり、どの技術が使用されるかは問題ではない。本発明の特定の実施例に従って、配信ＣＧＩは、リソースが宛先サーバへの転送のためにキュー（待ち行列）に入れられたことを示すために、ＳＥＮＤ要求を、ローカルサーバ上のキューに入れる。別の処理は、キューに入れたＳＥＮＤを、宛先サーバへのリソースを”プッシュ”する要求と解釈し、そして、宛先サーバへリソースのコピーを送る動作のシーケンスを開始する。代わりに、ＴＡＫＥ要求が宛先サーバについてキューに入れられることもできる。宛先サーバに関する適する処理が、リソースをローカルサーバから”プル”するために、動作のシーケンスを開始し、このようにして、宛先サーバ上にリソースのコピーを得る。
【００４８】
宛先サーバ（例えば、サーバ３０４）が図３に示すようにファイアーウォールを有する場合には、ソースサーバ（例えば、サーバ３１４）は、宛先サーバ３０４に、前者は後者にプルされる必要のあるリソースを有していることを示す。これは、例えば、宛先サーバに電子メールを送ることにより、達成される。
【００４９】
代わりに、宛先サーバ３０４は、周期的にソースサーバ３１４に関するキューをポーリングできる。典型的には、ファイアーウォールセキュリティ機構は、保護されたシステム（この場合にはサーバ）が、保護されたネットワークのその外側のサーバ（この場合にはソース）に、要求を発行することを妨げない。図３に示された特定の実施例では、ソースサーバ３１４は、宛先サーバ３０４に対応するキュー（待ち行列）３２６を含む。ソースサーバは、そのキューにＴＡＫＥ要求を入れる。宛先サーバは、周期的に、その対応するキューについてソースサーバをポーリングする。宛先サーバが、キュー内のＴＡＫＥ要求を検出したときには、適切な動作がソースサーバからのリソースへ直接アクセスすることが行われる。ＳＥＮＤとＴＡＫＥ要求は、転送されるべきリソースを確認するのに十分な関連する情報を有する。
【００５０】
”ファイル転送”処理は、”転送”と呼ばれるＣＧＩスクリプトにより実行される。ソースサーバ３１４上のスクリプトのコピーの局所的な実行は、キュー３２６内に入れられているＳＥＮＤ要求によりトリガされる。このイベントに応答して、転送スクリプトは、未決定の関連するＳＥＮＤ要求がある、各宛先サーバへリソースのコピーを転送する。
【００５１】
（ファイアーウォール又は、他の同様な機構のために）宛先サーバはローカルサーバによりアクセスされない図３の場合には、宛先サーバから周期的にポーリングされるキューがローカルサーバ上にある。宛先サーバがＴＡＫＥ要求をそのキュー内で検出した場合には、それは、ＴＡＫＥ要求が検出されたローカルサーバから、コピーを”プル”することにより、リソースのコピーを受信する。
【００５２】
リソースを受信するのに加えて、宛先サーバは宛先／通知ファイルも受信する。ＣＯＭＭＩＴ動作が、そして、各宛先サーバで要求され、そして、コミット処理が各宛先サーバで繰返される。処理は、この再帰的な方法で継続し、全てのサーバがリソースのコピーを受信し且つ、通知リスト内の全てのユーザが通知されるまで、配信リスト内のサーバを通して伝播する。
【００５３】
図２を参照する。図２に示された構成は、サーバ２０２とサーバ２０６の間をブリッジする、１つ又はそれ以上の中間サーバ２４２，２４４を示す。上述のように、この構成は、サーバ（即ち、サーバ２０２）が、他のサーバ（即ち、サーバ２０６）へコピーされるリソースを有するが、しかし何れのサーバも互いにアクセスできない、状況を示す。この場合には、配信リストは、中間サーバに関する情報を有し、これにより、リソースが中間サーバを介して宛先サーバに達するように伝搬することを可能とする。
【００５４】
代わりに、サーチが行われ、要求するサーバは、順に既知の隣接するサーバの各々に質問をする。この動作は、既知のインターネットルート発見プロトコルと同様である。更に、他のサーチの代わりは、既知のサーバ上の自動化された処理へ電子メール要求を送ることであり、中間サーバの名称を要求する。実際には、そのようなサーチは、ルーティング情報が、メッセージと共に、ＮＮＴＰ（”ニュース”）メッセージで使用されるパス情報と同様な方法で、伝播するので、ほとんど必要ない。
【００５５】
図５は、本発明の他の特徴を示し、リソース即ち、文書の集合、についてなされる変更のが配信と通知である。ユーザ（人間のユーザ又は、マシンユーザ）はリソースを変更するときには、変更されたリソースは、サーバに（新たなセッションの集合に）アップロードされそして、続いて配信される。
【００５６】
図５は、一般的な処理を示す。ユーザクライアントは、ステップ５０２で、（配信リストと通知リストを含み得る）リソースを変更するために、そのサーバにアクセスする。これは、リソースを識別する、ＵＲＬのＤＲＩ部分を規定することを含む。これに応じて、サーバは新たなリソースを識別するために、セッションＩＤを供給する。
【００５７】
望みの編集が、リソース及びおそらく配信リストと通知リストになされた後に、クライアントは、ステップ５０６で、変更されたリソースをセッションＩＤと共にサーバにアップロードする。サーバが、そのリソースについてのオリジンサーバでないと決定された場合（ステップ５０１）には、サーバは、リソースを、ステップ５０３で、オリジンサーバにアップロードする。ＤＲＩの呼出しは、オリジンサーバのマシン名を含み、そして、それにより、オリジンサーバはリソースに関連するＵＲＬのＤＲＩ部分を参照することにより、アクセスされうる。
【００５８】
変更されたリソースを含むサーバ（即ち、サーバ２０６）とオリジンサーバ（例えば、サーバ２０２）が相互にアクセスできない場合の、図２に示されたような構成の場合には、変更されたリソースは中間サーバを介してオリジンサーバに伝搬されて戻される。オリジンサーバに戻る中間サーバのチェインに関する情報は、配信リスト内に含まれる。
【００５９】
オリジンサーバが変更されたリソースを受信するときには、幾つかの形式のバージョン制御処理が実行され得る。以下は変更されたリソースのバージョン制御を扱う幾つかの基本的な方法である。
【００６０】
（１）何もしない：単に現在あるリソース上にリソースをアップロードする。
【００６１】
（２）スレッド：変更されたリソースを有する新たなファイルのみを含む、新たなリソースディレクトリを生成する。古いファイルはそれらのＤＲＩにより参照される。
【００６２】
（３）伝統的なバージョン制御（ＶＣ）ツール：リソースがアップロードされたときにはいつでも、ＲＣＳ又はＣＶＳのような伝統的なバージョン制御システムへの、構成要素のファイルをチェックする。（おそらく、ＶＣファイルはオリジンサーバのみに配置されている。）
（４）レイヤー：リソースは常に同じディレクトリ又はレイヤ内にある（そのＵＲＬを保持することを意味する）が、しかし、変更の組みがコミットされたときには、変更されたリソースを含む新たなファイルが、リソースの次の状態を示す、新たなレイヤ番号ｅ_ｉを有する新たなディレクトリに移動される。記号的なリンク又は、ある同様なエイリアシング機構を、不要なファイルの複製を防ぐために使用することができる。レイヤとレイヤ番号のこのアイデアは、以下で更に詳細に説明する。
【００６３】
図５を続けると、オリジンサーバは、現在、変更されたリソースを有する。次に、オリジンサーバは、ステップ５０８−５１０で、変更されたリソースを配信するために、コミット処理を開始する。この点で、変更されたリソースについてのコミット処理は、図４のステップ４０８−４１０を用いて説明したように、新たに生成されたリソースについてと同様な方法で進行する。変更されたリソースは、配信リスト内に規定されたサーバに配信され、そして、通知リスト内にリストされたユーザは、通知される。
【００６４】
図６Ａ−６Ｃを参照して、本発明の特定の実施例に従ったバージョン制御のための”レイヤ”の概念の説明を示す。慣例により、（複数の文書を含むリソースである）集合リソースは、”．．．／ｒｓｒｃ−ｎａｍｅ／ｘ／，”で終わるＵＲＬにより確認され、ここで、” ｒｓｒｃ−ｎａｍｅ”は、この特定のリソースの名称であり、ｘは整数である。特に、集合リソースは、そのパス名がリソースの名称を含み且つ、”．．．／ｘ／．”で終わる、ディレクトリである。リソースは”レイヤｘ”内にあるように参照される。また、慣例により、リソースの”トップレイヤ”はレイヤ０である。トップレイヤは、リソースの最も最新のバージョンを表す。集合リソース内の１つ又はそれ以上のリソースの変更は、後続のレイヤに含まれ、それにより、バージョン履歴が維持される。レイヤ０のトップレイヤは、常に、集合リソースの最も最近のバージョンを示す。
【００６５】
図６Ａを参照すると、部分的なファイルシステムが示されている。ディレクトリＤＤＳ１は、リソースの集合を示す。”ｔａｓｋ２”と名づけられたリソースは、ｆ１、ｆ２及びｆ３と名づけられた文書リソースを含む。説明目的のために、ファイルシステムは、”ｍａｃｈｉｎｅ１”のホスト名を有するマシン上に配置されているとする。リソース”ｔａｓｋ２”の”トップレイヤ”（即ち、レイヤ０）についてのＤＲＩは：
．．．／−ＤＤＳ１−／ｍａｃｈｉｎｅ１．ｃｏｍ／ｔａｓｋ２／０／
である。
【００６６】
本発明の特定の実施例に従って、文書リソースｆ１、ｆ２及びｆ３についてのファイル名は、破線のボックスにより示された、実際の文書への記号的なリンクである。集合リソースについての文書が最初に生成されそしてオリジンサーバにアップロードされたときには、それらは、オリジンサーバのレイヤ１ディレクトリに配置される。図６Ａは、．．．／１／ディレクトに配置されたファイルｆ１、ｆ２及びｆ３を示す。次にレイヤ１ディレクトリ内の各ファイルへの記号的なリンクは、レイヤ０ディレクトリ内に形成される。代わりに、記号的なリンクが、．．．／０／ディレクトリ自身から、．．．／１／ディレクトリへ形成されることができる。この時点で、”トップレイヤ”は、レイヤ１ディレクトリ内の文書を含む。
【００６７】
図６Ｂは、図６Ａの破線のボックスにより識別されるファイルシステムの一部６３０を示す。図６Ｂは、ｔａｓｋ２と名付けられた集合リソース内の１つ又はそれ以上のリソースが変更された場合の例を示す。この例では、文書ｆ３が変更され、そして、ｆ３．１と名付けられた。最初に、ｔａｓｋ２集合リソースの新たなバージョンを含む新たなレイヤ、即ち、パス名
．．．／−ＤＤＳ１−／ｍａｃｈｉｎｅ１．ｃｏｍ／ｔａｓｋ２／２／
を有するレイヤ２が生成されるのがわかる。
【００６８】
レイヤ２ディレクトリは、変更された文書ｆ３．１を含む。しかしながら、未変更の文書ｆ１とｆ２については、レイヤ１ディレクトリ内の実際のファイルを指すために、記号的なリンクが、レイヤ２ディレクトリ内に生成される。レイヤ２は今は、”ｔａｓｋ２”集合リソースの最も最新のバージョンを表す。トップレイヤ中の記号的なリンクは、これに従って更新される。レイヤ０ディレクトリ内に見えるように、ファイルｆ３へのリンクは、今は、レイヤ１ディレクトリ内のファイルｆ３の代わりに、レイヤ２ディレクト内のファイルｆ３．１を指すように更新される。他のリンクは、レイヤ１ディレクトリ内の未変更のファイル（ｆ１，ｆ２）を指したまま残る。このように、レイヤ０は、集合リソース”ｔａｓｋ２”の最新バージョンを表しそして、レイヤ１は、集合リソースの第１バージョンを表す。
【００６９】
図６Ｃは、更に、集合リソース”ｔａｓｋ２”の他の変更を示し、ここでは、文書ｆ２と文書ｆ３．１が変更されている。レイヤ３が生成されそして、変更された文書ｆ２．１とｆ３．１．１を含む。文書ｆ１はその生成から変更されていないので、レイヤ１内のｆ１への記号的なリンクが、レイヤ３内に生成される。レイヤ０内のリンク（トップレイヤ）は、従って、更新され、即ち、文書ｆ２は今は、レイヤ３ディレクトリ内の文書ｆ２．１を指し、そして、文書ｆ３は今は、レイヤ３ディレクトリ内の文書ｆ３．１．１を指す。レイヤディレクトリ０内の文書ｆ１は、レイヤ１ディレクトリ内のｆ１を以前として指す。集合リソースへの連続する変更は、このように追跡され、一方、集合リソースへの以前のバージョンへのアクセスもまだ可能である。
【００７０】
レイヤの中断されない時系列を維持するために、レイヤがオリジンサーバ上でのみ生成されることが必要である。ある他のサーバが、リソースを変更するのに使用される場合には、他のサーバは、更新を含めるために、”セッション”集合を生成する。慣例により、セッションは、
【００７１】
【外１】

で終わるＵＲＬにより表され、ここで、’Ｘ’は、セッションを生成したサーバに唯一の整数である。”コミット”動作がセッションで行われるときには、それは、新たなレイヤに変換されるオリジンサーバに転送され、そして、それはコミットされそして上述のように配信される。
【００７２】
【発明の効果】
上述のように、本発明により、文書が、各宛先で、オリジンサーバを示す情報により確認される、文書配信及び保管システム及び方法を提供できる。
【図面の簡単な説明】
【図１】本発明の例示の実施例に従った文書管理システムのハイレベルブロック図を示す図である。
【図２】本発明の第２の例示の実施例に従った文書管理システムのハイレベルブロック図を示す図である。
【図３】本発明の他の例示の実施例のハイレベルブロック図を示す図である。
【図４】本発明の実施例に従って、どのようにリソースが形成され且つ配信されるかを示す一般的なフローチャートを示す図である。
【図５】本発明の実施例に従って、どのようにリソースへの変更が配信されるかを示す一般的なフローチャートを示す図である。
【図６Ａ】バージョン制御のレイヤナンバリングの処理を示す部分的なファイルシステムを示す図である。
【図６Ｂ】バージョン制御のレイヤナンバリングの処理を示す部分的なファイルシステムを示す図である。
【図６Ｃ】バージョン制御のレイヤナンバリングの処理を示す部分的なファイルシステムを示す図である。
【符号の説明】
１００システム
１０２，１０４，１０６コンピュータシステム
１２２，１２４，１２６ユーザ
２０２，２０６サーバ
２４２，２４４中間サーバ
３０１ファイアウォールメカニズム
３０２宛先サーバ
３０３ファイアウォール
３０４宛先サーバ
３１２、３１４外部のサーバ
３２６第２のキュー

Claims

互いに通信可能な複数のワールドワイドウェブ(WWW)サーバを有する文書管理システムで文書を配信する方法であって、
或るWWWサーバに接続されたクライアントが、ユニバーサルリソースロケータ(URL)を使って文書へアクセスし、該文書を変更するステップと、
前記或るWWWサーバが、前記複数のWWWサーバの内前記文書に一意に関連付けられているオリジンサーバでなかった場合、前記或るWWWサーバが、変更後の文書を前記オリジンサーバへアップロードするステップと、
前記変更後の文書について前記オリジンサーバがバージョン管理を行うステップと、
前記クライアントからの要求に応じて、配信先のWWWサーバ及びユーザを示すリストに従って、前記オリジンサーバが、前記変更後の文書を配信するステップと、
を有し、前記URLは、前記クライアントに対するホストとなるWWWサーバを識別する部分と、パスを識別するパス部分とを含み、前記パス部分は、前記オリジンサーバを示す識別情報と、１つ以上の文書を含む文書集合のディレクトリを示す識別情報と、該文書集合のディレクトリのバージョンを示すレイヤ番号とを少なくとも含み、
前記オリジンサーバのバージョン管理では前記レイヤ番号毎にディレクトリが作成され、
或る文書集合中の少なくとも１つの文書が前記クライアントにより変更されると、前記バージョン管理を行うステップでは、新たなレイヤ番号の付いた新文書集合のディレクトリが該文書のオリジンサーバに作成され、前記新文書集合のディレクトリは、前記或る文書集合のうち変更されなかった文書へのリンクと変更された後の文書とを含むように生成され、前記オリジンサーバにより、前記変更後の文書のURLのパス部分は、前記新文書集合のディレクトリを示す識別情報及び新たなレイヤ番号を含むように更新される
ことを特徴とする方法。
互いに通信可能な複数のワールドワイドウェブ(WWW)サーバと、
或るWWWサーバに接続され、ユニバーサルリソースロケータ(URL)を使って文書へアクセスし、該文書を変更するクライアントと、
を含むシステムであって、前記複数のWWWサーバは、前記文書に一意に関連付けられ且つ変更後の文書についてバージョン管理を行うオリジンサーバを含み、
前記或るWWWサーバが、前記オリジンサーバでなかった場合、前記或るWWWサーバが、前記変更後の文書を前記オリジンサーバへアップロードし、
前記クライアントからの要求に応じて、配信先のWWWサーバ及びユーザを示すリストに従って、前記オリジンサーバが前記変更後の文書を配信し、
前記URLは、前記クライアントに対するホストとなるWWWサーバを識別する部分と、パスを識別するパス部分とを含み、前記パス部分は、前記オリジンサーバを示す識別情報と、１つ以上の文書を含む文書集合のディレクトリを示す識別情報と、該文書集合のディレクトリのバージョンを示すレイヤ番号とを少なくとも含み、
前記オリジンサーバのバージョン管理では前記レイヤ番号毎にディレクトリが作成され、
或る文書集合中の少なくとも１つの文書が前記クライアントにより変更されると、前記オリジンサーバは、新たなレイヤ番号の付いた新文書集合のディレクトリを作成し、前記新文書集合のディレクトリは、前記或る文書集合のうち変更されなかった文書へのリンクと変更された後の文書とを含むように生成され、前記変更後の文書のURLのパス部分は、前記新文書集合のディレクトリを示す識別情報及び新たなレイヤ番号を含むように更新される
ことを特徴とするシステム。