JP4590105B2 - ウェブサーバコンテンツ複製 - Google Patents

Description

【０００１】
（関連出願の相互参照）
本願は、１９９８年５月２９日に出願された米国特許出願第０９／０８６，８２１号の一部継続出願であり、本願は、１９９８年５月２９日に出願された米国特許出願第０９／０８６，８３６号の一部継続出願であり、本願は、１９９８年５月２９日に出願された米国特許出願第０９／０８６，８７４号の一部継続出願であり、本願は、１９９８年５月２９日に出願された米国特許出願第０９／０８７，２６３号の一部継続出願であり、１９９９年１月２８日に出願された米国仮特許出願第６０／１１７，６７４号、１９９９年８月１９日に出願された米国特許出願第０９／３７７，６１１号、１９９９年８月１９日に出願された米国特許出願第０９／３７６，０１７号の優先権を主張する。
【０００２】
（技術分野）
本発明は、複数のウェブサーバの管理、より具体的には、システムオペレータがウェブサービスシステム内の各ウェブサーバにコンテンツを配信することを可能にする。ウェブサービスシステムに関する。
【０００３】
（背景情報）
コンピュータネットワーク環境において、ウェブサーバは、ユーザのウェブページリクエストに応答するように用いられ、ユーザのウェブページリクエストは、コンピュータネットワークにわたって送信される。コンテンツリクエストとも呼ばれるウェブページリクエストは、典型的には、ユーザのコンピュータで実行するブラウザによって行われる。ウェブサーバは、ウェブページリクエストに対し、１つ以上のコンピュータネットワークアドレス／ポートエンドポイント端点を監視し、リクエスタにウェブページを送信することによりウェブページリクエストに、応答する。ウェブサーバは、特殊用途のデバイスであってもよいし、汎用コンピュータで実行するソフトウェアプログラムによって実現されてもよい。ウェブサーバのサービス容量は、所与の時間間隔で受信され得、応答され得るウェブページリクエストの数を制限する。
【０００４】
ウェブサービスシステムは、１つのウェブサーバまたは１つより多いウェブサーバを含み得る。概して、ウェブサービスシステムが、１つより多いウェブサーバを含む場合、ウェブサービスシステムは、複数のウェブサーバの各々がウェブページリクエストに応答するように設計される。典型的には、ユーザのウェブページリクエストは、ウェブサーバのうちの１つに振り向けられ、そのウェブサーバはそのウェブページリクエストに応答する。また、典型的には、多数のウェブページリクエストを受信するように設計されるウェブサービスシステムが、多くのウェブサーバを含む。
【０００５】
概して、複数のウェブサーバを有するシステムにおいて、単数または複数のシステムオペレータは、様々なサーバによって提供されるコンテンツを管理する。システムオペレータは、システムのコンテンツを調整し、例えば、様々なウェブサーバのコンテンツが同一であることを確認し、もしくは１つのウェブサーバから得られる一部のコンテンツおよび他のウェブサーバから得られる他のコンテンツを有することを時に望み得る。これは、特にコンテンツの更新がユーザに対し明白であるべき場合、達成するのが困難であり、ユーザは、一連の関連するウェブページを含むシステムとのインタラクションの最中である可能性がある。
【０００６】
また、コンテンツの管理は、キャッシュサーバにとって問題である。キャッシュサーバは、連続的な同一のリクエストを満たすのに用いる、ブラウザからウェブサーバに伝えられるリクエストの結果を、「キャッシュする」、つまり一時的に格納する。キャッシュサーバ設計および操作における課題は、格納された（キャッシュされた）コンテンツが元のサーバのコンテンツと一致しなくなるか、すなわち、キャッシュされたコンテンツがいつ無効になるかを判定することである。ハイパーテキスト転送プロトコル（「ｈｔｔｐ」）は、キャッシュサーバがコンテンツのコピーを保たなければならない持続時間を特定する、一部のコンテンツの元のサーバ用の仕組みを含む。しかし、一部のコンテンツについては、コンテンツがどれぐらいの間、有効性を維持するかを、元のサーバが前もって正確に判定することが不可能であり、元のサーバによって特定された終了時間よりも早くにコンテンツが予期せず更新される場合があり得る。
【０００７】
（発明の要旨）
１つまたは多くのウェブサーバを有するウェブサービスシステムにおいて、１つ以上のウェブサーバ上のコンテンツを管理および配信するシステムおよび方法が、システムオペレータにとって有用である。例えば、コンテンツ更新は、しばしば、素早く行われることが所望される。スケジューリングおよび自動化は、効率的かつ一貫した様態で、サーバ上のコンテンツを更新するために用いられ得る。また、可能な限り素早く、コンテンツの更新の失敗を識別し、機能しなくなったサーバを休止させ、サーバを修理し、ウェブサービスシステムにおいてサーバを動作状態に戻すことは、有用である。更新を行うと同時に、トランザクションの分断を最小化しながら、ウェブサイト利用可能性を最大化することが所望される。変更は、例えば、ウェブサーバプロセス（単数または複数）が終了するまでロードされない（および／または更新されない）共有のライブラリを用いてコンテンツが供給される場合、サーバが再開することを必要とし得る。
【０００８】
本発明によるウェブサービスシステムは、システムにおける１つ以上のウェブサーバの変更されたコンテンツを、正確に、かつ、効率的に更新する。その結果ウェブサーバ間の変更は首尾一貫し、変更は過剰なネットワーク帯域幅を要求しない。これは、ウェブサーバとのトランザクションに関係するブラウザにコンテンツの変化が顕著でなく、達成され、コンテンツのバージョンは、より古いコンテンツを用いて開始されるトランザクションの一貫性のため、および更新に問題がある場合に古いコンテンツにウェブサーバが戻ることを可能にするため、保存される。また、本発明のウェブサービスシステムは、コンテンツの変更点を探知し得、適切なときにキャッシュされたコンテンツが無効になったことをキャッシュサーバに知らせ得る。
【０００９】
概して、１つの局面において、本発明は、宛先ファイルシステム上のソースファイルセットの変更点を複製するシステムおよび方法に関する。ソースファイルセット内の変更点は、識別される。変更点は、修正リストに格納される。修正リストは、宛先ファイルシステムへのアクセスを有するエージェントに送信される。１つの実施形態において、変更されたファイルは、エージェントに送信される。他の実施形態において、変更されたファイルは、宛先ファイルシステムにインストールされる。他の実施形態において、ファイルのセットを検査し、ファイルのセットを以前に記録されたセットと比較することによって、変更点が識別される。他の実施形態において、ファイル動作を行うようにデバイスドライバをインストールすること、および、デバイスドライバによって、ソースファイルセットの変更点を記録することによって、変更点が識別される。他の実施形態において、ソースファイルセットの変更点を記述するマニフェスト（ｍａｎｉｆｅｓｔ）を受信することによって、変更点が識別される。他の実施形態において、ファイル属性を以前に記録されたセットのファイル属性と比較することによって、ファイルが比較される。他の実施形態において、ファイル属性は、ファイルサイズ、ファイルの許可、ファイルの所有権、修正時刻、およびハッシュファイルのセットから選択される少なくとも１つの属性を含む。他の実施形態において、方法は、変更点を識別する工程の前に、スクリプトを呼び出す工程を包含する。他の実施形態において、方法は、変更点を送信する工程の前に、スクリプトを呼び出す工程を包含する。他の実施形態において、方法は、変更点を送信する工程の後に、スクリプトを呼び出す工程を包含する。他の実施形態において、方法は、送信が首尾よく完了したかどうかを判定する工程の後、スクリプトを呼び出す工程を包含する。
【００１０】
概して、他の局面において、本発明は、ソースファイルセット内の変更点を、宛先ファイルシステムで複製するシステムおよび方法に関する。ソースファイルセット内の変更点は識別される。識別された変更点は、変更されたファイルを特定するユニフォームリソースロケータを含む、修正リストに格納される。修正リストは、少なくとも２つのウェブサーバに送信される。１つの実施形態において、送信は、マルチキャスティングによって達成される。１つの実施形態において、ファイルのセットを検査し、ファイルのセットを以前に記録されたセットと比較することによって、変更点が識別される。他の実施形態において、ファイル属性を以前に記録されたセットのファイル属性と比較することによって、ファイルのセットが以前に記録されたセットと比較される。他の実施形態において、ファイル属性は、ファイルサイズ、ファイルの許可、ファイルの所有権、修正時刻、およびハッシュファイルのセットから選択される少なくとも１つの属性を含む。
【００１１】
概して、他の局面において、本発明は、ウェブサービスシステムに関する。システムは、ウェブサービスシステムを管理するマネージャを含む。また、システムは、ウェブページリクエストを受信するウェブサーバ、およびマネージャと通信するエージェントを備えるホストを含む。また、システムは、ホストにコンテンツ変更点を提供するコンテンツディストリビュータを含む。１つの実施形態において、システムは、ウェブページリクエストを向けるトラフィックマネージャを含む。他の実施形態において、コンテンツディストリビュータは、ソースファイルセット内の変更点を識別する識別モジュールと、識別された変更点を格納する修正リストと、修正リストを宛先ファイルシステムへのアクセスを有するエージェントに送信するトランスミッタとを含む。他の実施形態において、システムは、変更されたファイルをエージェントに送信するトランスミッタを含む。他の実施形態において、エージェントは、宛先ファイルシステム上に変更されたファイルをインストールする、インストーラを含む。
【００１２】
概して、他の局面において、本発明は、コンテンツディストリビュータに関する。コンテンツディストリビュータは、ソースファイルセット内の変更点を識別する識別モジュールを含む。また、コンテンツディストリビュータは、識別された変更点を格納する修正リストを含む。また、コンテンツディストリビュータは、修正リストを宛先ファイルシステムへのアクセスを有するエージェントに送信するトランスミッタを含む。１つの実施形態において、コンテンツディストリビュータは、変更されたファイルをエージェントに送信するトランスミッタを含む。
【００１３】
本発明の上記および他の目的、局面、特徴、および利点は、以下の説明からより明らかになる。
【００１４】
図面において、同一の参照符号は、概して、異なる図を通じて同じ部分を指す。また、図面は、必ずしも一定の縮尺比で縮尺される必要はなく、概して、本発明の原理を示すことに重点が置かれている。
【００１５】
（説明）
ウェブページを供給するシステムは、複数のウェブサーバを有し、複数のウェブサーバの動作を調整する機能およびツールをシステムオペレータに提供する。システムは、１つのウェブサーバのみを有してもよいが、典型的には、１つより多いウェブサーバを含む。システムは、概して、クライアントコンピュータ上のウェブブラウザから発生するウェブページリクエストを、利用可能なウェブサーバに向けることによって、トラフィックを管理し得る。このようにして、システムは、複数のサーバ間のウェブページリクエストサービス負荷の均衡を取る。システムは、ウェブページリクエスト、およびこれらのウェブページリクエストに対するウェブサーバ応答についてのデータを収集し得、データの報告と、自動および手動解析ツールとを提供する。システムは、特定のイベントを監視し得、このようなイベントの発生時には自動的に動作し得る。イベントは、今にも起こりそうなシステム問題を示す予測または閾値を含む。システムは、自動エラー復旧を提供し、構成要素の欠陥またはネットワーク環境問題のようなイベントから回復するために取られ得る可能な動作を通じてシステムオペレータをガイドする、危機管理能力を含み得る。システムは、システムオペレーションについての現在の情報を、システムオペレータに示し得る。システムは、バージョン管理およびデータのアップデートでコンテンツの複製を管理し得る。これらの機能性の一部または全てが、特定の実施形態において提供され得る。
【００１６】
図１を参照すると、ウェブサービスシステム９０の実施形態が、ブラウザ１からのウェブページリクエストを受信する。このコンテキストにおいて、ウェブページは、ウェブページリクエストに応答して、コンピュータネットワーク２上で利用可能にされ得る電子コンテンツである。リクエストは、典型的には、ウェブブラウザ１から発生される。ウェブページの一例として、表示、実行、再生、処理、ストリーミング、および／または格納され得、他のウェブページへのリンク、またはポインタを含み得る、コンピュータ実行可能または解釈可能な情報、グラフィックス、音、テキスト、および／または映像を含むデータファイルがある。リクエストは、通信ネットワーク２を介して通信され得る。１つの実施形態において、通信ネットワーク２はイントラネットである。他の実施形態において、通信ネットワーク２は、インターネットとして公知のグローバル通信ネットワークである。ブラウザ１は、ユーザによって操作されて、ウェブページリクエストを作成し得る。また、ブラウザ１は、コンピュータまたはコンピュータプログラムによって操作されて、コンピュータプログラミングに基づいて自動的にリクエストを作成し得る。ウェブページリクエストは、ハイパーテキスト転送プロトコル（「ｈｔｔｐ」）フォーマットを用いて作成されてもよいし、リクエスト能力を提供する他のプロトコルを用いて作成されてもよい。
【００１７】
図２を参照すると、様々な構成要素１００〜１２６を含むウェブサービスシステム９０の実施形態が示される。構成要素は、１つ以上のコンピュータネットワークを介して通信する。構成要素の物理的な位置は、様々な構成要素間の通信リンクが十分なデータ通信能力を有する限り、システムの性能またはパフォーマンスに影響を与えない。ウェブサービスシステム９０は、種々の設計のファイアウォールを通って機能し得、遠隔的に設定および管理され得る。
【００１８】
ウェブサービスシステム９０は、１つ以上のホスト１００を管理する。例として、１つのホスト１００が示されている。ウェブサービスシステム９０の実施形態は、任意の数のホスト１００を有し得る。各ホスト１００は、市販されており、ＵＮＩＸ（登録商標）またはＷｉｎｄｏｗｓ（登録商標） ＮＴのようなマルチスレッドのオペレーティングシステムを用いることができるコンピュータシステムであり得る。各ホスト１００は、例えば、インターネットまたはイントラネット、あるいは任意の他のネットワークのような、コンピュータネットワークへの少なくとも１つのネットワーク接続を有し得る。このことによって、ホスト１００が、ウェブページデータリクエストに応答して、ウェブページデータを提供することが可能になる。各ホスト１００は、少なくとも１つのウェブサーバ１０２を含む。
【００１９】
ウェブサーバ１０２は、コンピュータネットワークを介して受信したウェブページリクエストに応答して、ウェブページを提供する任意のウェブサーバであり得る。このようなウェブサーバの２つの例は、Ｍｏｕｎｔａｉｎ Ｖｉｅｗ，ＣａｌｉｆｏｒｎｉａのＮｅｔｓｃａｐｅ Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ Ｃｏｒｐｏｒａｔｉｏｎから市販されているＮＥＴＳＣＡＰＥ ＥＮＴＥＲＰＲＩＳＥ ＳＥＲＶＥＲと、Ｒｅｄｍｏｎｄ，ＷａｓｈｉｎｇｔｏｎのＭｉｃｒｏｓｏｆｔ Ｃｏｒｐｏｒａｔｉｏｎから市販されているＭＩＣＲＯＳＯＦＴ ＩＮＴＥＲＮＥＴ ＩＮＦＯＲＭＡＴＩＯＮ ＳＥＲＶＩＣＥＳ ＳＥＲＶＥＲとがある。ウェブサーバ１０２は、ブラウザおよび／またはウェブページのリクエスタとも呼ばれるウェブクライアントから、ウェブページリクエストを受信することができる。また、ブラウザからのウェブページリクエストは、コンテンツリクエストと呼ばれるか、またはウェブサーバの視点から、「ヒットする」とも呼ばれる。しばしば、ウェブページリクエストは、いくつかのリクエストおよび応答に関わる、ウェブサーバ１０２との通信のシリーズの一部である。セッションと呼ばれる、このようなシリーズは、ウェブサーバとの、広げられたインタラクションである。より短いインタラクション、例えば、商品の購入は、トランザクションと呼ばれる。セッションは、いくつかのトランザクションを含み得る。ユーザは、ウェブサーバ１０２の初期リクエストを作成することで、ウェブサーバ１０２とやりとりし、そのやりとりの結果ウェブサーバ１０２はウェブページを応答として送信する。ウェブページは情報を含み得、ユーザがウェブサーバ１０２またはおそらく他のウェブサーバから作成し得る他のリクエストへのポインタも含み得る。リクエストは、データベースから検索されなければならない情報を求める場合もあれば、データベースに格納される情報を含む場合もある。リクエストは、ウェブサーバ１０２による処理、または他のコンピュータシステムとのインタラクションを必要とする場合もある。高性能なウェブサーバとブラウザとは、様々な方法でインタラクトし得る。
【００２０】
関連するトピックについてのウェブページのセットとして、または、特定のソース、必ずではないが、通常は同じウェブサーバ１０２から、ユーザに提示される、関連するウェブページの集合は、アプリケーションと呼ばれる。アプリケーションの一例として、会社についての情報を提供するページのセットがある。アプリケーションの他の例として、ユーザが自身の貯蓄銀行と取り引きすることを可能にするページのシリーズがある。ウェブページの２つのセットは、１つのアプリケーションとして考えられてもよいし、２つの別個のアプリケーションとして考えられてもよい。例えば、ウェブページのセットは、銀行についての情報を提供し得、ウェブページのカスタマーサービスセットは、銀行との事務処理を可能にし得る。ウェブページのセットが、１つのアプリケーションとして考えられるか、またはいくつかのアプリケーションとして考えられるかは、アプリケーション設計者によって決定される。ウェブサービスシステム９０は、１つ以上のアプリケーションをユーザに送る能力を有する。ウェブサービスシステム９０は、ウェブサーバ１０２の一部のサブセットが、１つのアプリケーションのみの役に立つように設定され得る。１つの実施形態においては、ウェブサーバ１０２の一部のサブセットが、利用可能なアプリケーションのサブセットの役に立ち、他のウェブサーバ１０２は、他のアプリケーションの役に立つ。他の実施形態においては、全てのウェブサーバ１０２が、全ての利用可能なアプリケーションの役に立つ。
【００２１】
ユーザのウェブブラウザからのウェブページリクエストに応答してユーザに提示されるウェブページは、ホスト１００、または、ウェブサーバ１０２にアクセス可能なファイルシステムに格納され得る。一部または全てのウェブページコンテンツは、ウェブサーバ１０２に利用可能なデータを処理することによって、ウェブサーバ１０２によって生成され得る。例えば、トピックについてのドキュメントであるウェブページについて、ウェブページが、作成（設計）され、ウェブサーバ１０２ファイルシステムに格納され得る。ウェブページリクエストに応答して、このようなウェブページは、ファイルシステムに格納されるのと同時に、ユーザに送信され得る。しかし、銀行取引システムにおいては、ユーザの銀行口座についての情報が、データベースに格納される可能性が高い。ウェブサーバ１０２は、ユーザがページをリクエストするたびに、ユーザの口座情報を含むウェブページを生成し得る。しばしば、ウェブページは、部分的にはファイルシステムに格納され、部分的には、リクエストされるとき、ウェブサーバ１０２によって生成される。
【００２２】
ユーザのウェブサーバ１０２とのセッションの「状態」とも呼ばれるステータス情報を格納するため、様々な技術が用いられる。ユーザは、自身とウェブサーバ１０２とのインタラクションの間に、作成するウェブサーバ１０２へのリクエスト、およびこれらのリクエストに対する応答として受信したウェブページを通じて、状態を発展させ得る。一例として、ユーザの状態は、ユーザを識別する情報を含み得る。他の例として、状態は、ユーザが既にリクエストしたウェブページ、またはユーザがシステムとのインタラクションにおいて選択したオプションを特定する情報を含み得る。他の例として、状態は、商品販売アプリケーションからユーザが購入することを選択したアイテムを含み得る。概して、セッションの状態についての一部の情報またはセッションの状態を識別する情報は、例えば、以下で説明するクッキーとして、クライアントウェブブラウザに格納され、一部の情報は、ウェブサーバ１０２に格納され得る。
【００２３】
ホスト１００は、ホスト容量、性能、およびコストについての考慮に依存して、任意の数の、その上で実行されるウェブサーバ１０２を有し得る。１つの実施形態において、ホスト１００は、１つのウェブサーバ１０２を含む。他の実施形態において、ホストは、１つより多いウェブサーバ１０２を含む。ホスト１００上の１つのウェブサーバ１０２は、簡略化された例示的な例であり、ウェブサーバ１０２の取り得る数を限定するものではない。各ウェブサーバ１０２は、エンドポイントとも呼ばれる、少なくとも１つのネットワークアドレスおよびポートを監視する。特定のアドレスおよびポートが、バーチャルな通信のエンドポイントであるので、エンドポイントと呼ばれ、ネットワーク接続は、１つのアドレス／ポートエンドポイントと他のアドレス／ポートエンドポイントとの間で作成される。ウェブサーバ１０２は、そのエンドポイントのうちの１つに向けられたリクエストを受信し、ウェブページの形式のデータでこれらのリクエストに応答する。
【００２４】
複数のネットワークアドレス／ポートエンドポイントでリクエストを受け取るウェブサーバ１０２は、実際には１つのウェブサーバ１０２として実行されるにも関わらず、複数の異なるウェブサーバ１０２であるかのように、動作し得る。このようなウェブサーバは、複数エンドポイントウェブサーバと呼ばれる。説明のため、複数のエンドポイントウェブサーバは、実際に、各ウェブサーバ１０２がネットワークアドレス／ポートエンドポイントでリクエストを受信する、複数のウェブサーバ１０２であるかのように、説明され得る。１つの実施形態において、このような複数エンドポイントウェブサーバは、複数のエンドポイント全てとのインターフェースである、ウェブサーバインターフェース１０４を１つ有する。
【００２５】
各ウェブサーバ１０２は、ウェブサーバインターフェース１０４と関連付けられ得る。ウェブサーバインターフェースは、ウェブサーバ１０２とウェブサービスシステム９０の他の構成要素との間のインターフェースとして役に立つ、プラグイン、フィルタ、または、ウェブサーバ１０２と関連付けられた他のソフトウェアであり得る。このコンテキストにおいて、タームウェブサーバインターフェースは、ホスト１００に存在し得るネットワークインターフェースとは異なる。例えば、ウェブサーバ１０２は、ウェブサーバインターフェース１０４を有する。各ウェブサーバインターフェースは、各ホスト１００上のエージェント１０６と通信し得る。
【００２６】
ホスト１００は、エージェント１０６を含む。エージェント１０６は、ホスト１００とインターフェースをとるウェブサービスシステム９０を提供する。エージェント１０６は、ウェブサーバインターフェース１０４をウェブサービスシステム９０とリンクする。また、エージェント１０６は、ホスト１００をウェブサービスシステム９０とリンクする。複数のウェブサーバを有するホストにおいて、１つより多いエージェントを有することが可能であるとしても、一般的には、ホスト１００上で実行しているエージェント１０６は１つしかない。各エージェント１０６は、システム構成要素についての情報を含むデータベース１０８へのアクセスを有する。
【００２７】
ホスト１００上のエージェント１０６は、ウェブサービスシステムマネージャ１１０と通信する。マネージャ１１０は、ホスト１００およびウェブサーバ１０２のステータスについての情報を、エージェント１０６から受信する。マネージャ１１０は、コマンドをエージェント１０６に送信して、ウェブサーバ１０２を開始、終了、または一時停止させて、ウェブサーバ１０２の負荷を管理するように、ホスト１００を設定し得る。マネージャ１１０は、システム活動およびイベントのロギングにおいて用いられるロギングデータベース１１４へのアクセスを有する。また、マネージャ１１０は、システムの様々な構成要素についての情報を格納するために用いられる、管理されているオブジェクトデータベース１１２へのアクセスを有する。また、マネージャ１１０は、１つ以上のコンソール１１６Ａ〜１１６Ｘ、全体的に１１６と呼ばれるコンソールと通信する。コンソール１１６は、システムオペレータにユーザインターフェースを提供する。システムオペレータは、システムのステータスを監視し、コンソールを通じてシステムを設定し得る。マネージャ１１０は、ウェブサーバ１０２の１つまたはトラフィックマネージャ１２０、あるいは、十分な容量の他のコンピュータのような、ウェブサービスシステム９０の他の構成要素と同じホスト１００上で実行し得る。
【００２８】
マネージャ１１０は、インターセプタとも呼ばれるトラフィックマネージャ１２０と通信する。トラフィックマネージャ１２０は、ウェブページリクエストをウェブサーバに向ける。本発明は、トラフィックマネージャ１２０の任意の特定のタイプによって限定されず、ウェブページリクエストをウェブサーバ１０２に向ける、任意の種類のトラフィックマネージャ１２０と共に動作するように意図される。
【００２９】
１つの実施形態において、トラフィックマネージャ１２０は、マネージャ１１０から情報およびコマンドを受信する。また、トラフィックマネージャ１２０は、制御プログラム１２２から情報およびコマンドを受信する。トラフィックマネージャ制御プログラムは、トラフィックマネージャ１２０と同じコンピュータシステム上にあってもよく、あるいは、他のシステム上で実行してもよい。トラフィックマネージャ１２０は、ウェブページリクエストを受信し、ウェブサーバのうちの１つにリクエストを問い合わせる。ウェブサービスシステム９０の管理能力のうちの一部は、ウェブサーバ１０２によって作成されるウェブページリクエストと、得られるウェブサーバ１０２およびホスト１００上の負荷とを監視することによって達成される。ウェブページリクエストは、ウェブサーバ１０２間の負荷の均衡を取るように、向けられ得る。１つの実施形態において、トラフィックマネージャ１２０は、ユーザが最初に接触する点である。トラフィックマネージャ１２０は、ユーザからウェブページリクエストを受信し、ユーザのウェブブラウザをそのリクエストに関して適切なウェブサーバ１０２に「問い合わせる」。ユーザのウェブブラウザは、適切なウェブサーバ１０２上のウェブページへの照会を用い、ウェブページリクエストに応答することで、問い合わせられる。この照会能力は、ハイパーテキスト転送プロトコルに組込まれる能力で達成され得るが、他の方法でも達成され得る。ユーザは、ウェブブラウザが、適切なウェブサーバ１０２に問い合わせられたことを認識してもよいし、しなくてもよい。ユーザは、そのウェブサーバ１０２上のアプリケーションにアクセスし、そのウェブサーバ１０２からのウェブページリクエストへの応答を受信し得る。１つの実施形態において、ウェブサーバ１０２に負荷が掛けられ過ぎた場合、そのウェブサーバ１０２は、マネージャ１１０の指示の下で、ユーザをトラフィックマネージャ１２０に差し戻すか、またはアプリケーションを送る能力を有する他のウェブサーバ１０２に問い合わせ得る。
【００３０】
トラフィックマネージャ１２０は、ユーザからのリクエストを受信し、ユーザのリクエストをウェブサーバ１０２に向け直す。１つの実施形態において、トラフィックマネージャ１２０が、他のトラフィックマネージャ１２０または単一のエンドポイントのように、全てのユーザを１つのウェブサーバ１０２に向けるように用いられる。このようにして、トラフィックマネージャ１２０は、分路として機能を果たす。すなわち、トラフィックマネージャ１２０は、ホストの１つ以上のウェブサーバに向けられた全てのリクエストを、他のウェブサーバ１０２に向ける。他の実施形態において、トラフィックマネージャ１２０は、マネージャ１１０から、ステータス情報を受信し、その情報を用いてユーザを向け直す。ステータス情報は、サーバ利用可能性および負荷、管理者の変化、ならびにアプリケーションまたはウェブサーバ１０２の開始および終了アクションを含む。トラフィックマネージャ１２０は、速度およびセキュリティのために設計される。トラフィックマネージャ１２０は、システムの正面入り口であり、その性能は、全体ウェブサービスシステム９０の知覚された性能に影響する。トラフィックマネージャ１２０を、ネットワークトポロジーの意味において、可能な限りバックボーンの近傍に配置することが有用であり得る。従って、必然的に、トラフィックマネージャ１２０は、ウェブサービスシステム９０の最も露出される構成要素である。
【００３１】
１つの実施形態において、トラフィックマネージャ１２０は、ハードウェアにおいて実現される。他の実施形態において、トラフィックマネージャ１２０は、ホストコンピュータ上で実行されるソフトウェアプログラムである。ソフトウェア実施形態の１つにおいて、トラフィックマネージャ１２０は、マルチスレッドのオペレーティングシステムを実行する能力を有するサーバクラスコンピュータで実行されるスタンドアロンのプログラムである。ＵＮＩＸ（登録商標）の下で、トラフィックマネージャ１２０は、例えば、デーモンとして実行し得る。Ｗｉｎｄｏｗｓ（登録商標） ＮＴの下で、トラフィックマネージャ１２０は、サービスとして実行し得る。
【００３２】
他の実施形態において、トラフィックマネージャ１２０は、１つのエンドポイントに向けられたリクエストをウェブサーバ１０２に属するエンドポイントに向けるインターネットプロトコルブリッジまたはルーターである。このようにして、トラフィックマネージャ１２０は、ウェブページリクエストを、１つ以上のウェブサーバ１０２に向ける。このようなトラフィックマネージャの一例として、Ｓａｎ Ｊｏｓｅ， ＣａｌｉｆｏｒｎｉａのＣｉｓｃｏ Ｓｙｓｔｅｍｓ， Ｉｎｃ．製のＬＯＣＡＬＤＩＲＥＣＴＯＲがある。さらに別の実施形態において、トラフィックマネージャ１２０は、Ｗｅｓｔｆｏｒｄ， ＭａｓｓａｃｈｕｓｅｔｔｓのＡｒｒｏｗｐｏｉｎｔ Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ， Ｉｎｃ．製のＣＯＮＴＥＮＴ ＳＭＡＲＴ ＷＥＢ ＳＷＩＴＣＨのようなウェブスイッチである。トラフィックマネージャ１２０は、各ウェブページリクエストを受信し、リクエストに基づいて、リクエストをウェブサーバに向ける。
【００３３】
また、ウェブサービスシステム９０は、コンテンツディストリビュータ１２５とも呼ばれるバージョンコントローラを含む。コンテンツディストリビュータ１２５は、ウェブサービスシステム９０内の様々なウェブサーバ１０２上のコンテンツの更新を含むバージョンおよびコンテンツ複製を管理する。コンテンツディストリビュータ１２５のシステムオペレータインターフェースは、コンテンツコントロール１２６によって提供される。１つの実施形態において、コンテンツディストリビュータ１２５およびコンテンツコントロール１２６は、それぞれ、ホスト１００上で動作するスタンドアロンのプロセスである。他の実施形態において、コンテンツディストリビュータ１２５およびコンテンツコントロール１２６は、マネージャ１１０と同じホストで動作する。他の実施形態において、コンテンツディストリビュータ１２５およびコンテンツコントロール１２６は、他のホスト上で動作する。コンテンツディストリビュータ１２５とコンテンツコントロール１２６とは、同じホスト上で動作してもよいし、異なるホスト上で動作してもよい。他の実施形態において、コンテンツディストリビュータ１２５は、マネージャ１１０、またはシステム９０の他の構成要素の機能に組み込まれ得る。
【００３４】
コンテンツディストリビュータ１２５は、情報をエージェント１０６に送信し、エージェント１０６を通じてウェブサーバインターフェース１０４に送信する。送信された情報は、ソースファイルと呼ばれ、概して、階層ディレクトリ構造に編成される、コンテンツディレクトリおよびファイルのセットの変更点を記述する。これらのソースファイルは、ウェブサーバ用のコンテンツの「マスター」コピーである。ディレクトリおよびファイルは、共に、概して、ソースファイルまたはソースファイルセットと呼ばれる。ソースファイルセットは、ステージングサーバとも呼ばれるソースホストに格納され得る。ステージングサーバは、典型的には、コンテンツディストリビュータ１２５が実行しているホストであるが、必ずしもそうでなくてもよい。説明を簡略にするため、以下の説明において、コンテンツディレクトリおよびファイルは、ソースファイルであっても、ホスト１００上であっても、概して、単にファイルと呼ばれる。ソースファイルセットは、ディレクトリおよびファイルの両方を含み得、また、ファイルの変更点は、ディレクトリの追加、削除、および変更を含み得る。
【００３５】
図３を参照すると、ある程度の期間にわたって、ソースファイルセットに対して変更が行われる（工程１８０）。行われる変更には、新しいファイルの作成、古いファイルの削除、現存するファイルを新しいコンテンツで置換（すなわち、ファイル内容の変更）、ならびに、許可制限および所有権のようなファイル属性を変更することが含まれる。また、ファイルの変更について説明する場合でも、ディレクトリの変更も含まれるように意図される。変更は、アプリケーションプログラムおよびオペレーティングシステムユーティリティを含む、当該技術において公知である、このような編集技術およびツールを用いて、ファイルを編集することによって行われる。変更は、テストされ、発展および承認プロセスにおいて承認され得る。実際には、特定の時間では、ファイルの変更点がない場合があり、システムは、これを識別し得る。このような場合、変更点がないことが識別された後、次の起こり得る変化が識別されるまで、さらなる処理が行われない。
【００３６】
コンテンツディストリビュータは、ファイルの変更点を識別する（工程１８１）。ファイルの変更は、多数の方法で識別され得る。１つの実施形態において、コンテンツ設計者は、変更点のリストである、マニフェストを提供する。設計者は、例えば、コンテンツコントロールユーザインターフェース１２６を用いて、または、マニフェストをコンテンツディストリビュータ１２５に通信することによって、変更点を把握し、コンテンツディストリビュータへの変更を手動で識別する。他の実施形態において、設計するためにコンテンツ設計者によって用いられるソフトウェアおよびシステムは、変更点をたどり、コンテンツディストリビュータ１２５に通信される変更点のマニフェストを提供する。
【００３７】
他の実施形態において、コンテンツディストリビュータ１２５は、オペレーティングシステムファイルサービスと一体化し、ソースファイルセットへの変更点を監視する。このような実施形態の１つにおいて、オペレーティングシステムによって呼び出される、ソフトウェアデバイスドライバ「モニタ」がインストールされて、ファイルオペレーションが行われる。デバイスモニタは、オペレーティングシステムと実際のデバイスドライバ（すなわち、ハードディスクドライバソフトウェア）との間でデータを通過させるパススルー（ｐａｓｓ ｔｈｒｏｕｇｈ）デバイスドライバとして機能を果たす。ディスクドライバを通じてディスクＩ／Ｏコマンドを通過させることに加えて、デバイスモニタは、それらのＩ／Ｏコマンドを観察し、ソースファイルセットの変更点を記録する。１つの実施形態において、デバイスモニタは、コンテンツディストリビュータ１２５と一体化される。他の実施形態において、デバイスモニタは、コンテンツディストリビュータ１２５に通信されたマニフェストを生成する。
【００３８】
さらに別の実施形態において、コンテンツディストリビュータ１２５は、現在のソースファイルセットと以前のソースファイルセットとの比較を行って、ソースファイルセットの変更点を判定する。コンテンツディストリビュータは、比較のため、最後に更新されたときに存在したファイルのリストを維持する。このリストには、ファイル名と、ファイルサイズ、ファイルが最後に変更された日付／時間、コンテンツのハッシュコード、許可および／またはアクセスコントロール制限、ユーザ／グループ所有権のような、他のファイル特性とが含まれる。１つの実施形態において、ファイルのリストは、以前のソースファイルセットにおける全てのファイルの完全なコピーを含むが、大きなファイルシステムについては、この実施形態は非効率的である。より効率的な実施形態において、以下で説明するように、以前のファイルのリストおよび特定のファイル属性のみが必要とされる。変更点を識別する工程（工程１８１）、変更点を送信する工程（工程１８２）、および変更点をインストール工程（工程１８３）は、更新と呼ばれることもある。
【００３９】
図４を参照すると、１つの実施形態において、ソースファイルと以前のソースファイルセットとの比較は、ソースファイルセット内のファイル（およびディレクトリ）の解析によって行われる。ソースファイルセット内の各ファイルについて（工程１９０）、コンテンツディストリビュータは、ソースファイルセット内のファイルを、１つの実施形態において、上述したリストの形態である、以前のソースファイルセットを記述する情報と比較する。各ファイルについて、コンテンツディストリビュータは、ファイルが以前のソースファイルセットリスト内にあるかどうか判定する（工程１９１）。以前のソースファイルセットリスト内にない場合、ファイルは新たなファイルとしてリストに挙げられ（工程１９２）、このファイルがソースファイルセットに追加されたことが示され、ファイルでハッシュが計算される（工程１９３）。ファイルがリストに挙げられる場合、ファイルリスト項目がマークされて（工程１９４）、ファイルが依然ファイルセットに含まれていることを示す。これは、後に、以前のリストのファイルがなくなっている、すなわち、削除されたものがあるかどうか判定するために用いられる。
【００４０】
ファイルのサイズは、リスト内の情報と比較される（工程１９５）。ファイルサイズが異なる場合、このファイルは修正されたと考えられ、このようにリストに挙げられる（工程１９６）。ファイルの新たなハッシュが、計算され、リストに格納される（工程１９３）。サイズが同じである場合、日付／時間が比較される（工程１９７）。日付／時間が異なる場合、ファイルのハッシュは、計算され、以前のリストに含まれるハッシュと比較される（工程１９８）。このコンテキストにおいて、ハッシュは、ファイルのコンテンツについて行われ、ファイルコンテンツに関連する単一の数が得られる計算である。このようなハッシュは、メッセージ完全性コードとも呼ばれる。ハッシュコードの例として、チェックサムおよび周期的冗長コードがある。ファイルのハッシュが異なる場合、このファイルは、修正されたとしてリストに挙げられ（工程１９６）、新たなハッシュがリストに格納される（工程１９３）。そうでない場合、ファイル属性（オーナー、グループなど）が変更された場合（工程１９９）、ファイルは、修正された属性を有するものとしてリストに挙げられる（工程２００）。
【００４１】
１つの実施形態において、ファイルコンテンツが変更されていない場合、システムはまた、ファイル属性が変化していないかどうかを判定する（工程１９９）。他の実施形態において、属性情報は、コンテンツ更新の一部として送信される。これらの工程が、ソースファイルセット内の全てのファイルについて完了した場合、工程１９４からのマーキングは、以前にリストに挙げられたファイルがなくなっている、すなわち、ファイルセットから削除されたものがあるかどうかが調べられる（工程２００）。マークされていないファイルは、削除されたとしてリストに挙げられる（工程２０２）。
【００４２】
ソースファイルセットの変更点は、マニフェストとも呼ばれる変更点リスト内にあることが、コンテンツディストリビュータ１２５に知らせられる（ｉｄｅｎｔｉｆｙ）。１つの実勢形態において、追加、削除、コンテンツ修正、および／または属性修正のような、ファイルの変更点を示す項目を含む。例えば、追加ステートメント「ＡＤＤ ｓｏｕｒｃｅ／ｄｉｒ／ｄｉｒ／ｆｉｌｅ １」は、ファイル１が追加されたことを示し、ステートメント「ＣＨＭＯＳ ｓｏｕｒｃｅ／ｆｉｌｅ ２」は、「ｆｉｌｅ２」に関連する許可が変更されたことを示す。例えば、他のステートメントには、ファイルの除去を示す「ＤＥＬＥＴＥ」、およびコンテンツの変更を示す「ＭＯＤＩＦＹ」が含まれる。また、さらなる属性の違いは、ＣＨＭＯＤステートメントを用いるか、または、所有権変更についてのＣＨＯＷＮ、またはグループ関連の変更についてのＣＨＧＲＰのような、自身の特有ステートメントを有する。
【００４３】
図５を参照すると、１つの実施形態において、マニフェストエントリー３００は、少なくとも８つの情報要素３０１〜３０８を含む。１つの実施形態において、各エントリーは、テキストフォーマットで格納されるので、情報は、シンプルテキストエディタでシステムオペレータによって読み出され得るか、他のソフトウェアによって翻訳され得る。他の実施形態において、各エントリーは、テキストフォーマットと同様に、同じ情報を含むが、よりコンパクトな２進数形式で格納される。２進数形式は、変換ツールで、テキストフォーマットに変換され得る。また、テキストフォーマットは、２進数形式に変換され得る。
【００４４】
１つの実施形態において、マニフェストエントリー３００は、ファイルタイプフィールド３０１を含む。可能なファイルタイプは、ディレクトリ、ファイル、記号リンク、ハードリンク、または、ディレクトリ内の最後のファイルの後に来るエンドオブディレクトリマーカーである。テキストフォーマットの実施形態において、各ファイルは、ディレクトリの「ＤＩＲ」、エンドオブディレクトリマーカーの「ＥＮＤ」、通常ファイルの「ＮＲＭ」、記号リンクの「ＬＮＫ」、およびハードリンクの「ＨＬＫ」のような３文字コードで記述される。２進数形式の実施形態において、各選択肢は、整数コードによって表される。例えば、１つの実施形態において、ディレクトリは、数字１で表され、ファイルは２で表され、以下同様に続く。
【００４５】
また、マニフェストエントリー３００は、取得されるアクションフィールド３０２を含む。テキストフォーマットの実施形態において、取得されるアクションは、追加されるファイルの「ＡＤＤ」、変更されたコンテンツの「ＣＨＧ」、変更されたオーナー、グループ、または許可の「ＣＨＰ」、削除されたファイルの「ＤＥＬ」のような３文字コードである。３文字コード「ＮＯＣ」は、ファイルが変更されてないことを記述するために用いられる。２進数形式の実施形態において、各選択肢は、整数コードによって表される。例えば、１つの実施形態において、追加されたファイルは、数字１で表され、変更されたコンテンツは、２で表され、以下同様に続く。
【００４６】
また、マニフェストエントリー３００は、ファイルアクセス許可、およびファイルについての他の情報を記述する、許可フィールド３０３を含む。テキストフォーマットの実施形態において、ＵＮＩＸ（登録商標）形式で、４つの３項目バイナリ入力（すなわち、ｒｗｘｒｗｘｒｗｘ）として、許可は格納される。ここで、第１の３項目バイナリ入力は、実行可能プログラムがユーザとして実行されるかどうかを記述し、続く３つの入力は、それぞれ、オーナー、グループ、およびパブリックの読み出し、書き込みおよび実行許可を示す。バイナリ実施形態において、許可情報は、許可を表す４桁の８進数である、バイナリ整数として格納される。
【００４７】
また、マニフェストエントリー３００は、ファイルのサイズを記述するファイルサイズフィールド３０４を含む。テキストフォーマットの実施形態において、ファイルサイズは、ＡＳＣＩＩ文字で書かれる。２進数形式の実施形態において、ファイルサイズは、整数として格納される。
【００４８】
また、マニフェストエントリー３００は、日付／時刻スタンプ３０５を含む。テキストフォーマットの実施形態において、日付および時刻は、ＡＳＣＩＩ文字で書かれる。２進数形式の実施形態において、日付／時刻は、１９７０年１月１日深夜からの秒数を表す整数として格納される。
【００４９】
また、マニフェストエントリー３００は、所有権情報３０６を含む。この情報は、２つの部分、ファイルオーナーのユーザ識別子、およびグループオーナーのグループ識別子を含む。テキストフォーマット実施形態において、オーナーおよびグループ識別子は、ＡＳＣＩＩストリングとして格納される。２進数形式の実施形態において、オーナーおよびグループ識別子は、整数として、それぞれ格納される。
【００５０】
また、マニフェストエントリー３００は、チェックサム３０７またはハッシュ結果を含む。テキストフォーマットの実施形態において、これは、ＡＳＣＩＩストリングとして格納される。また、マニフェストエントリーは、ファイルの相対パス名３０８を含む。テキストおよび２進数形式の両方の実施形態において、相対パス名３０８は、ＡＳＣＩＩストリングとして格納される。
【００５１】
図６を参照すると、変更点の例示的なリストに、追加されたファイルａａａ（ディレクトリである）、ディレクトリａａａのファイルａｇｅｎｔ．ｒｅｇ、ｑｕｅｓｔｄ．ｒｅｇ、およびｓｑｌｓｅｒｖｅｒ．ｒｅｇ、ならびに、同様にディレクトリであるファイルｂｂｂおよびｃｃｃが示されている。ディレクトリｄｄｄと、ディレクトリｄｄｄ内のファイルａｂｃおよびｅｆｇは、変更されていない。また、ディレクトリｅｆｇも変更されていない。ディレクトリｍｍｍ、ｘｘｘ、およびｙｙｙは削除され、ファイルａｇｅｎｔ．ｒｅｇ、ｑｕｅｓｔｄ．ｒｅｇ、およびｓｑｌｓｅｒｖｅｒ．ｒｅｇはディレクトリｘｘｘから削除されている。
【００５２】
図７を参照すると、図５のフォーマットのマニフェストのテキストフォーマットの実施形態の一例は、図６でリストに挙げられた変更点を反映させている。第１の入力、ＥＮＴＲＹ１において、ディレクトリａａａは、ファイル名３０８においてリストに挙げられている。ファイルａａａは、タイプ３０１「ＤＩＲ」としてリストに挙げられる。このファイルのアクション３０２は、「ＡＤＤ」であり、ファイルが追加されたことを示す。許可３０３は、ＵＮＩＸ（登録商標）形式でリストに挙げられ、ファイルがディレクトリであること、オーナーが許可を読み出し、書き込み、実行することを示す。ファイルサイズ３０４は、０としてリストに挙げられる。ファイルの日付／時刻スタンプ３０５は、５月２７日１７：１２としてリストに挙げられる。ユーザおよびグループ識別子３０６は、両方とも、識別子０としてリストに挙げられる。ファイル３０７のチェックサムは、０である。
【００５３】
第２の入力、ＥＮＴＲＹ２において、ファイル名３０８においてリストに挙げられるファイルは、ａｇｅｎｔ．ｒｅｇである。このファイルは、ａｇｅｎｔ．ｒｅｇである（Ｔｈｉｓ ｆｉｌｅ， ａｇｅｎｔ．ｒｅｇ．）。ＥＮＴＲＹ２が、ａａａディレクトリ入力（ＥＮＴＲＹ１）および終了ステートメント（ＥＮＴＲＹ５）の間にあるので、このファイルは、ディレクトリａａａの中にある。ファイルａｇｅｎｔ．ｒｅｇは、通常のタイプ３０１であり、アクション要素３０２において示すように、新たなファイルとして追加される。許可３０３は、オーナーが許可を読み出し、書き込んだことを示す。ファイルサイズ３０４は、５６９バイトである。ファイルの日付３０５は、１９９８年５月１１日である。ユーザおよびグループ識別子３０６は、両方とも０である。チェックサム３０７は、３５６４８８６２２０である。
【００５４】
第５の入力、ＥＮＴＲＹ５は、ディレクトリａａａのリスト項目の最後を示す、タイプ３０１終了マーカーである。第６の入力、ＥＮＴＲＹ６について、ディレクトリｂｂｂは、ａａａ終了マーカーの後にリストに挙げられているので、ａａａのサブディレクトリではない。
【００５５】
再度、図３を参照すると、１つの実施形態において、コンテンツディストリビュータは、例えば、図４の方法を用いて変更点を判定することによって、マニフェストを作成する。他の実施形態において、マニフェストは、コンテンツディストリビュータに通信される。１つの実施形態において、マニフェストは、マニフェストを特定の位置（すなわち、ディレクトリおよびファイル名）に格納することによって通信され、コンテンツディストリビュータは、それを見出すように設定される。他の実施形態において、マニフェストは、ネットワークを介してコンテンツディストリビュータ１２５にはっきりと送信することによって、コンテンツディストリビュータに通信される。
【００５６】
変更点が識別された後（工程１８１）、例えば、図３の実施形態を用いて、変更点が、エージェントに送信される（工程１８２）。しばしば、変更点は、ホストファイルシステムの特定のディレクトリにマッピングされる。１つの実施形態において、ソースファイルセットは、表１の実施例に示すように、様々なホストのファイルシステムにマッピングされる。
【００５７】
【表１】

表１から明らかであるように、システム管理者は、ソースファイルセット内のファイルを、ステージングサーバファイルシステムから、様々なウェブサーバのファイルシステムにマッピングし得る。ＵＲＬではなく、実際のファイルシステム識別子を用いることによって、ユニフォームリソースロケータ（「ＵＲＬ」）で識別可能でない、共有のライブラリおよび他のファイルのマッピングが可能になる。例えば、ＣＧＩスクリプトは、ウェブサーバからウェブページリクエストを介して、このようなファイルが、概して利用可能でないのでＵＲＬが用いられる場合、マッピングされず、ＵＲＬを有さない。ファイルシステム識別子の代わりに、ＵＲＬを用いることが可能なので、修正され得るファイルのタイプの制限におけるトレードオフ以外において、マッピングは必要ない。ＵＲＬが用いられる場合、ウェブサーバからウェブページリクエストを介してアクセス可能なファイルのみがアクセス可能である。
【００５８】
１つの実施形態において、ソースファイルセットディレクトリ階層内のファイルは、単一のアーカイブファイルに結合され、そのアーカイブファイルは、圧縮される。設定可能な値より大きい任意のファイルは、ネットワークを介するホストシステムまでの通信をより効率的にし、ネットワークへの影響を低減するように、より小さいブロックに分割される。ファイルをより小さいブロックに分割することによって、タイムアウトの場合における再送信の量が最小化される。このような設定可能な値の例は、１メガバイトである。
【００５９】
変更されたファイルのファイルサイズを含む変更点リスト（マニフェスト）は、コンテンツを受け取るべき各エージェントに送信される。エージェントは、変更リストにおけるファイルサイズおよびエージェントが認識している、行わなければならない計算に基づいて、更新のために十分なディスクの空き容量があるかどうかを判定する。例えば、エージェントは、ファイルシステム内に、コンテンツ更新の圧縮されたコピー、および圧縮されてないデータのコピーを２つ、すなわち、一時コピーおよび格納されるべきコピーを格納する、十分な場所があるかどうかを判定し得る。このようにして、エージェントは、ホストが新たなコンテンツによって負荷を掛けられ過ぎるようになる前に、転送を中止することができる。
【００６０】
所定の数のサーバが、更新されたコンテンツを受信することに同意する場合、データは、コンテンツディストリビュータからエージェントに送信される。多くのエージェントが、コンテンツを受信することができない場合、コンテンツディストリビュータは、ジョブを中止し得る。転送を行うために必要なエージェントの率は、設定可能である。例えば、システムオペレータは、５０％のエージェントが変更を受け入れることが可能になるまで転送が行われてはならないことを決定し得る。このようにして、更新されたコンテンツを有するサーバの数が少なすぎることが防がれる。
【００６１】
１つの実施形態において、転送は、ファイル転送プロトコル（「ＦＴＰ」）のような標準ＴＣＰ／ＩＰ転送を用いて行われる。他の実施形態において、転送は、信頼できるマルチキャストプロトコルを用いて行われる。送信失敗がある場合、データのブロックが再送信される。転送が繰り返し失敗する場合、転送は中止され、システムオペレータへの警告を含む様々なアクションが取られ得る。また、コンテンツディストリビュータは、予測されない環境に起因して、転送において成功するエージェントが予期されていた数より少ない場合、変更点のインストールを中止し得る。例えば、多くのエージェントが、ネットワーク接続性を失う場合、新たなコンテンツの役に立つように利用可能なエージェントの数が不十分であることが起こり得る。
【００６２】
再度図１を参照すると、特定のエージェント１０６について更新が失敗する場合、ウェブサービスシステム９０は、システムの影響された部分を「避けて通る（ｒｏｕｔｅ ａｒｏｕｎｄ）」ように試みる。コンテンツディストリビュータがマネージャとは別である実施形態において、コンテンツディストリビュータ１２５は、エージェント１０６が失敗したことをマネージャ１１０に知らせる。マネージャ１１０は、トラフィックマネージャ１２０と通信し、トラフィックマネージャは、そのエージェント１０６と通信するウェブサーバ１０２にウェブページリクエストを向けない。また、マネージャ１１０は、ウェブサーバ１０２から他のサーバにトラフィックを向け得る。
【００６３】
１つの実施形態において、コンテンツディストリビュータ１２５は、失敗した宛先エージェントを目標とする、「追い上げ（ｃａｔｃｈ−ｕｐ）」更新パッケージを作成する。追い上げ更新パッケージは、エージェントに達する必要があるが、達していない変更点を含む。初期的に、これは、第１の更新から、送信において失敗する、変更点のリストである。この追い上げ更新パッケージは、連続的な更新が同じエージェントに達することを失敗する場合でも、増大し得る。更新パッケージが失敗する場合、以前に伝送が失敗した変更点についての新たな更新から依存し得るので、エージェントは、「追い上げ」更新が完了するまで他の更新を受信しない。
【００６４】
再度図３を参照すると、変更点がエージェント１８２に送信された後、変更点がインストールされる（工程１８３）。エージェント１０６およびウェブサーバインターフェース１０４は、協力して、コンテンツをインストールする。新たなコンテンツが受信される場合、エージェントは、更新パッケージを、再度組み立て、その後、解凍し、データを一時データ格納に位置付ける。その後、エージェントは、コンテンツディストリビュータからの信号を待って、サーバコンテンツディレクトリへのファイルのコピーを開始する。信号が受信される場合、サーバコンテンツディレクトリで変更が行われる。また、削除するようにリストに挙げられた任意のファイルが、このとき除去さえる。更新が成功する場合、エージェントは、ファイルの更新において成功したことをコンテンツディストリビュータに知らせる。１つの実施形態において、コピーは、単純な上書きによって達成される。他の実施形態において、古いファイルは、まず、再命名され、かつ／または、代替的なディレクトリに格納される。これによって、変化が素早く入れ替えられるが、より多くのデータ格納を必要とするというトレードオフがある。何らかの理由でコピーが失敗する場合、エージェントは、コンテンツディストリビュータに問題を警告する。エージェントまたはコンテンツディストリビュータのいずれかは、マネージャにも警告し、マネージャは、トラフィックマネージャに、失敗したエージェントを避けるように指令し得る。１つの実施形態において、エージェントは、ウェブサーバのコンテンツ状態を示すバージョン識別子を維持する。１つの実施形態において、バージョン識別子は、整数値である。
【００６５】
１つの実施形態において、ウェブサーバは、更新プロセスの間、一時停止または停止する。ウェブサーバコンテンツディレクトリにファイルがコピーされる場合、ウェブサーバは、リクエスタが首尾一貫していないコンテンツを受信することを避けるために、ウェブページリクエストの処理を止められる。ウェブサーバは、コンテンツ更新プロセスの間にユーザを向け直すように調節される。これは、トラフィックマネージャがリクエストをそのウェブサーバに転送しないように命令するマネージャによって、達成される。同時に、そのウェブサーバ１０２に達するリクエストは、ウェブサーバインターフェース１０４によって、そのウェブサーバ１０２から、トラフィックマネージャ１２０または他のウェブサーバ１０２に転送され得る。トランザクションの最中のユーザは、転送される前にトランザクションを完了するため、所定の長さの時間を与えられ得る。ウェブサーバが、リクエスタを除く場合、更新が起こる。アプリケーションバイナリファイルが、変更されない場合、ウェブサーバは、リクエスタを除き得、リクエスタは、コンテンツ転送が完了した後、サーバに向けられ得る。しかしながら、アプリケーションバイナリファイルが修正された場合、ウェブサーバは再開される必要があり得る。
【００６６】
いくつかの場合において、コンテンツを更新するために、ウェブサーバをディセーブルすることが可能でないこともある。一時的なブラウザの再方向付けのプロセスは、非常に時間が掛かり得、その場合、ファイルの転送およびウェブサーバの更新に必要な時間と共に、容認できないほど長い。サーバの利用可能性を最大限にするため、コンテンツは、ウェブサーバがリクエストに応答し続ける間、更新され得る。これは、変更されるファイルのコピーを作成し、これらのファイルのコピーをウェブサーバにアクセス可能な場所に入れることによって、達成される。エージェントは、ウェブサーバインターフェースに、変更されているファイルについての全てのリクエストを遮らせる。変更していないファイルについてのリクエストは、通常のコンテンツ領域に向けられ得る。変更しているファイルについてのリクエストは、代わりに、安定コピー（ｓｔａｂｌｅ ｃｏｐｙ）に向けられ得、新たなファイルが、通常の領域にインストールされる。エージェントがファイルの修正を完了した後、ウェブサーバインターフェースは、通常領域を再度用いるように信号送信され得る。古いコンテンツから新たなコンテンツへの転換の時に、関連するウェブページのシリーズに関わるトランザクションに関わるユーザは、転換の後しばらく、トランザクションが完了するまで、「古い」コンテンツにアクセスし続ける必要を有し得る。例えば、第１の価格で購入する最中のユーザは、更新された異なる価格を用いるウェブページとのトランザクションを完了すべきではない。
【００６７】
１つの実施形態において、トランザクションの完全性を確実にするため、転換のたびに、バージョン識別子が割り当てられる。１つの実施形態において、チェックポイント識別子とも呼ばれるバージョン識別子は、コンテンツ更新ごとに増分されることによって変更される整数である。ウェブサーバインターフェースは、ブラウザによって予期されるバージョンに基づいて、ウェブページリクエストを遮り、そのバージョンのコンテンツを提供する。このことを行うために、ウェブサーバは、ブラウザによって所望されるバージョンを知る必要がある。１つの実施形態において、この情報は、ＵＲＬに含まれる。しかし、これは、ＵＲＬおよびより複雑なファイル構造の作成という不利な点を有する。また、バージョン変更点は、ユーザにとって、あまり意識されない。
【００６８】
１つの実施形態において、ウェブサーバは、サーバによってブラウザに供給されるページのその後−現在（ｔｈｅｎ−ｃｕｒｒｅｎｔ）バージョンを特定するバージョン識別子を含むブラウザに、クッキーを発行する。クッキーは、ウェブサーバがブラウザに送信するので、ウェブサーバがそのブラウザについて何かを「記憶する（ｒｅｍｅｍｂｅｒ）」ことができる特別なテキストファイルである。ウェブのハイパーテキスト転送プロトコル（ＨＴＴＰ）を用いることによって、ウェブページのリクエストの各々は、全ての他のリクエストから独立する。このため、クッキーのようなメカニズムなしには、ウェブサーバは、以前にブラウザに送信したページがどれかということも知らないか、または、ブラウザの以前の訪問について何も知らない。クッキーは、サーバがブラウザについての自身の情報をブラウザ自身のコンピュータに格納し、ユーザがウェブページリクエストを行う場合、その情報にアクセスすることを可能にするメカニズムである。クッキーには、有効な持続期間が提供され得る、すなわち、ある程度の時間の後、ブラウザによって廃棄される。
【００６９】
１つの実施形態において、このようなクッキーの一例が、コード、「Ｓｅｔ−Ｃｏｏｋｉｅ：ＡｔｒｅｖｅＢＣＤ＝３７；ｅｘｐｉｒｅｓ＝Ｔｈｕｒｓｄａｙ，２０−Ｊａｎｕａｒｙ−１９９９ １２：３２：３４ ＧＭＴ；ｐａｔｈ＝／」として実現される。このコードは、ウェブサーバからブラウザに送信される。ブラウザは、同じドメインにおいてウェブサーバと通信する場合、１９９９年１月２０日の１２：３２：３４ ＧＭＴまで、任意のパスへの全てのリクエストについて「Ｃｏｏｋｉｅ：ＡｔｒｅｖｅＢＣＤ＝３７」という行を含む。プロトコルの「Ｓｅｔ−Ｃｏｏｋｉｅ」および「Ｃｏｏｋｉｅ」部分は、ＨＴＴＰ規格によるヘッダである。「ＡｔｒｅｖｅＢＣＤ」は、クッキーの名前である。ＡｔｒｅｖｅＢＣＤはデフォルトなので、任意の他の名前が用いられ得る。「３７」は、サーバが、終了時まで、現在、および将来（ウェブサーバインターフェースのせいで）において提供し続けるチェックポイントである、クッキーの値である。コード「終了」は、終了時を設定する。この例において、終了時は、１９９９年１月２０日である。「Ｐａｔｈ」コードは、どのページがクッキーを与えるかを制限するために用いられ得るが、「／」は、全てのファイルを含むことを示す。
【００７０】
ウェブサーバがブラウザに発行するクッキーは、ウェブサーバから、ブラウザがコンテンツをリクエストすることを効率的に可能にし、そのコンテンツについてのバージョン識別子を示す。従って、ブラウザが特定のＵＲＬを特定する特定のクッキーで、６つのリクエストを作成する場合、これらの６つのリクエストは、エージェントがその間に新たなバージョンのコンテンツをウェブサーバ１０２に配信した場合にさえ、自己矛盾がない。
【００７１】
１つの実施形態において、より早いコンテンツは、そのコンテンツを特定する全てのクッキーが廃棄されるまで、廃棄されない。コンテンツは、１つのバージョンから次のバージョンへの変更点を含む「バックアップ」領域に格納される。例えば、バージョン２からバージョン３への移行において変更するファイルは、バージョン２−３バックアップ領域に格納される。ウェブサーバインターフェースは、バージョン２からバージョン３への移行で変更されたバージョン２のウェブページリクエストを、適切なバックアップ領域における適切なコンテンツに向ける。
【００７２】
図８を参照すると、簡略化された例において、ウェブサーバは、３４の現在のバージョン識別子を有するコンテンツを有する。クッキーが依然有効である以前のバージョンは、バージョン３３および３２である。現在のバージョン、バージョン３４は、バージョン３４において修正されたファイルＡおよびＢ、バージョン２８において修正されたファイルＣ、バージョン２５において修正されたファイルＤを含む。ファイルＡは、図に示す全てのバージョン（バージョン３２、バージョン３３、およびバージョン３４を含む）において修正された。ファイルＢは、バージョン３０、バージョン３２、上述したように、バージョン３４において修正された。従って、バージョン３１からバージョン３２への変更は、ファイルＡおよびＢの変更点、バージョン１で作成されたファイルＥの削除を含む。従って、バージョン３１からバージョン３２への移行において変更されたファイルを含む３１−３２バックアップ領域には、ファイルＡのバージョン３１、ファイルＢのバージョン３０、ファイルＥのバージョン１が格納されている。バージョン３２からバージョン３３への変更には、ファイルＡの修正が含まれるので、３２−３３バックアップ領域には、ファイルＡのバージョン３２が格納されている。バージョン３３からバージョン３４への変更には、ファイルＡおよびＢの修正、およびファイルＦ（バージョン１０で追加）の削除が含まれるので、３３−３４バックアップ領域において、ファイルＡのバージョン３３、ファイルＢのバージョン３２、ファイルＦのバージョン１０が格納される。
【００７３】
例えば、現在のバージョン以外のコンテンツバージョンを示すクッキーを提示することによって、ウェブサーバがコンテンツをリクエストする場合であって、古いチェックポイントと現在のチェックポイントとの間でファイルが変更される場合、ウェブサーバインターフェースは、ウェブサーバに現在のバージョン領域以外の領域からコンテンツを取らせ得る。１つの実施形態において、ウェブサーバインターフェースは、変更点リストを再び見て、リクエストされたファイルが変更されたかどうか判定し、変更されている場合、どのバックアップ領域に位置するかを判定する。例えば、現在のバージョンがバージョン３４である、図８の例をまた参照すると、ウェブサーバがファイルＡのリクエストを受信し、クッキーはブラウザがバージョン３２を探していることを示す場合、ウェブサーバインターフェースは、バージョン３３の一部として、ファイルＡが修正されたことがわかる。従って、ファイルＡのバージョン３２は、３２−３３バックアップ領域に位置する。ウェブサーバが、同じブラウザから（同じバージョン３２クッキーで）ファイルＢのリクエストを受信する場合、ウェブサーバインターフェースは、バージョン３４でファイルＢが修正され、ファイルＢのバージョン３２が３３−３４バックアップ領域に格納されたと判定する。ウェブサーバがファイルＤのリクエストを受信する場合、ウェブサーバインターフェースは、ファイルがバージョン３２から修正されておらず、そのファイルが現在のバージョン領域から入手され得ることを判定する。
【００７４】
１つの実施形態において、コンテンツディストリビュータは、特定の時間または時間間隔に対するソースファイルセット変更点のスケジューリングされた更新に備える。コンテンツディストリビュータは、システムオペレータの手動コマンドでも、更新し得る。１つの実施形態において、更新は、ファイルがどこからコピーされる必要があるか（すなわち、ソースファイルセット）、どこにコピーされる必要があるか（すなわち、ファイルサーバのファイルシステム）を示すコンテンツマッピング、更新がいつ起こるかを示す開始／日付時間または時間間隔、（上述したように）変更されたファイルのみが更新される必要があるか、または全てのファイルがコピーされる必要があるかどうか、失敗の場合に取られる必要があるアクション、コンテンツの更新においてサーバが再開される必要があるかどうか、コンテンツの更新の間にサーバが一時停止または停止する必要があるかどうか、更新が（システムオペレータがスケジューリングされた更新をディセーブルすることを可能にするように）イネーブルまたはディセーブルされるかどうか、ならびに、サーバが変更を行うように命令される前に更新を許容する必要があるサーバの率によって、特定される。１つの実施形態において、更新は、ジョブと呼ばれる。
【００７５】
例えば、１０分ごとに実行して、変更したファイルを更新し、任意の問題をシステムオペレータに知らせる更新を特定することが可能である。また、月に１度、更新を特定することも可能である。１つの実施形態において、システムは、ファイルをコピーする間はサーバをオフにし、全ての変更されたファイルを更新し、コンテンツが更新された場合、サーバを再開する。
【００７６】
図９を参照すると、いくつかのウェブサービスシステム９０は、関連付けられた１つ以上のキャッシュサーバ２００を有する。キャッシュサーバ２００は、リクエスタ２０１（例えば、ブラウザ）とウェブサービスシステム９０の間に位置するウェブサーバのタイプである。キャッシュサーバ２００は、初期的には、いずれのコンテンツも有さない。それよりは、リクエスタ２０１からの命令でウェブページをリクエストし、ウェブページをそのキャッシュに格納する。市販されているキャッシュサーバの一例として、Ｓａｎｔａ Ｃｌａｒａ， ＣａｌｉｆｏｒｎｉａのＮｅｔｗｏｒｋ Ａｐｐｌｉｃａｎｃｅ，Ｉｎｃ．製のＮＥＴＣＡＣＨＥ製品がある。キャッシュサーバ２００は、ブラウザ２０１から、ウェブサービスシステム９０に位置するコンテンツのウェブページリクエストを受信する。リクエストおよび自身の設定に基づいて、キャッシュサーバ２００は、ウェブページを有する元のウェブサーバ（ウェブサービスシステム９０）から、ウェブページをリクエストする。キャッシュサーバ２００は、元のウェブサーバ９０から、ウェブページを受信し、ブラウザ２０１にウェブページを送信する。また、キャッシュサーバ２００は、所定の期間、そのウェブページを格納する。ページが格納される期間は、コンテンツプロバイダ（元のウェブサービスシステム９０）によって、例えば、ＨＴＴＰプロトコルに従って文書の送達の終了期間を特定することによって、またはキャッシュサーバ２００システム管理者のいずれかによって、決定される期間である。第２のリクエストが、同じリクエスタ２０１、または異なるリクエスタから、終了期間の前にキャッシュサーバ２００に到達する場合、キャッシュサーバは、元のサーバからコンテンツをリクエストすることなしに、リクエストに応答して、ウェブページを再送信し得る。従って、リクエストは、第２のリクエストで、元のサーバまたはネットワークにさらなる要求を出すことなく、履行される。
【００７７】
上述したように、ウェブサービスシステム９０上でファイルが変更する場合、キャッシュサーバ２００上にキャッシュされたファイルは、終了し得ない。その場合、キャッシュサーバ２００は、ウェブサービスシステム９０から利用可能な更新されたバージョンよりも、より初期の（ｅａｒｌｉｅｒ）ウェブページのバージョンを提供する。従って、上述したような変更点リストを用いて、ファイルが変更したことをキャッシュサーバ２００に知らせることが有利である。
【００７８】
図１０を参照すると、キャッシュサーバ２００でファイルの変更が調整されたシステムにおいて、ファイルに変更が行われ（工程１８０）、変更点が識別され（工程１８１）、変更点がウェブサーバに送信され（工程１８２）、変更点がインストールされる（工程１８３）。また、キャッシュサーバは、変更が知らせられる（工程１８４）。キャッシュサーバに知らせる、さらなる工程（工程１８４）は、キャッシュサーバが、もはや用いられないウェブページを破棄する（すなわち、除く）ことを可能にする。１つのキャッシュサーバ、または多くのキャッシュサーバがあり得、様々な通信技術を用いて知らせられ得る。例えば、１つの実施形態において、放送メッセージが用いられる。他の実施形態において、各キャッシュサーバに別個のメッセージが送信される。さらに別の実施形態において、ファイルが、１つ以上のキャッシュサーバとって利用可能なディレクトリに格納される。
【００７９】
図１１を参照すると、図６の方法の実施形態は、変更を行う工程（工程１８０）、変更点を識別する工程（工程１８１）、キャッシュに知らせる工程（工程１８４）を含み得る。１つの実施形態において、知らせること（工程１８４）は、変更点リストをユニフォームリソースロケータ（「ＵＲＬ」）に変換して、コンテンツを識別する工程（工程１８６）を含む。ブラウザは、ＵＲＬを用いて、コンテンツを識別する。上述したように、１つの実施形態において、変更点リストは、ウェブサーバにとってより簡便で、殆どのファイルシステムにおける全てのファイルを示すことを可能にするので、ホストファイルシステムにおけるディレクトリおよびファイルに関して記述される。キャッシュサーバに変更点を提供する場合、ＵＲＬを含むフォーマットで、ファイル（およびディレクトリ）が挙げられる変更点リストを変換することは有用である。ソースディレクトリは、可能なＵＲＬの特定のプレフィックスに対応することがあり得る。例えば、コンテンツディレクトリおよびファイル「Ｃ：＼ＷＥＢＳＰＥＣＴＩＶＥ＼ＨＯＭＥ＼ＡＢＯＵＴ．ＨＴＭＬ」は、ＵＲＬ「ｈｔｔｐ：／／ｗｗｗ．ｗｅｂｓｐｅｃｔｉｖｅ．ｃｏｍ／ｈｏｍｅ／ａｂｏｕｔ．ｈｔｍｌ」に対応し得る。これは、プレフィックスが修正された（この場合、Ｃ：＼ＷＥＢＳＰＥＣＴＩＶＥは、ｈｔｔｐ：／／ｗｗｗ．ｗｅｂｓｐｅｃｔｉｖｅ．ｃｏｍで置き換えられる）ことを含意し、ディレクトリを分割するもの、この場合では、バックスラッシュ「＼」は、ＵＲＬ標準フォーワードスラッシュ「／」で置き換えられている。さらに、ＵＲＬにおいて許容されない文字、例えばスペースが、特定化されたルールに従って符号化される。このような文字の置き換えの一例が、Ｔ．Ｂｅｒｎｅｒｓ−Ｌｅｅらによる、「Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｏｒｓ」という題のＩＥＴＦ Ｎｅｔｗｏｒｋ Ｗｏｒｋｉｎｇ Ｇｒｏｕｐ ＲＦＣ−１７８３文書において記載される。例えば、スペースは、「％２０」で符号化され得、この翻訳は、ＵＲＬプレフィックスに連結される。
【００８０】
リスト項目が、ＵＲＬフォーマットに変換された後、変更されたＵＲＬのリストは、キャッシュサーバに送信される（工程１８７）。キャッシュサーバは、このリストを用いて、古いコンテンツを破棄し得る。図７に示すように、通知を行うためにコンテンツ伝送を行う必要はない。例えば、１つしかウェブサーバがないが、キャッシュが多い場合、図７のシステムは、１つ以上のキャッシュサーバに変更を知らせるように機能を果たす。図７に示すように、変更が行われ（工程１８０）、変更点が識別され（工程１８１）、変更点のリストは、ＵＲＬに変換される（工程１８６）。これらの変更点は、キャッシュサーバに送信される（工程１８７）。他の実施形態において、ＵＲＬへの変換（工程１８６）は、変更が行われる工程（工程１８０）と、変更点を識別する工程（工程１８１）との間に行われる。
【００８１】
図１２を参照すると、１つの実施形態において、図３および図１０の方法は、ユーザ設定可能スクリプトを実行する工程をさらに含む。変更が行われた（工程１８０）後、ユーザ設定可能スクリプトが実行される（工程２８０）。変更点を識別した後（工程１８１）、ユーザ設定可能スクリプトが実行される（工程２８１）。スクリプトは、変更点の送信（工程１８２）と同時に実行される。変更点が送信された後（工程１８２）、ユーザ設定可能スクリプトは再度実行される（工程２８２）。ユーザ設定可能スクリプトは、カスタマーの実現に特有のコンテンツ配信タスクを達成するために、用いられ得る。ユーザ設定可能スクリプトは、オペレーティングシステム機能の適切な呼び出しを通じて実行される。
【００８２】
図１３を参照すると、１つの実施形態において、コールアウトスクリプトに情報が提供される。１つの実施形態において、情報は、標準入力のスクリプトに提供される。他の実施形態において、情報は、ファイル内に提供される。スクリプトは、十分な（ゼロ）ステータスコード、または、１つの実施形態において動作を中止する非ゼロエラーコードのいずれかである。
【００８３】
１つの実施形態において、情報４００は、テキストフォーマットで提供され、ＢＥＧＩＮＰＡＲＡＭＳステートメント４０１で開始し、ＥＮＤＰＡＲＡＭＳステートメント４２０で終了する。情報４００は、互換性のために用いられる、情報ブロックのバージョン数４０２を含む。情報４００は、この例においてＥＸＡＭＰＬＥＪＯＢである、ジョブ名４０３を含む。
【００８４】
情報４００は、ＢＥＧＩＮ、ＩＮ ＰＲＯＧＲＥＳＳ、およびＥＮＤのうちの１つであり得るジョブ４０４の状態を含む。ＢＥＧＩＮ値は、変更点を識別する（すなわち、図１１の工程２８０）前にスクリプトが呼び出されることを示す。ＩＮ ＰＲＯＧＲＥＳＳ値は、変更点を識別した後、変更点が送信される前（または、ちょうど送信されるとき）にスクリプトが呼び出されることを示す（すなわち、図１１の工程２８１）。ＥＮＤ値は、送信が完了したことを示す（すなわち、図１１の工程２８２）。情報４００は、この場合はＡＬＬＩＭＡＧＥＳである、マッピング４０５の名前を含む。情報４００は、この例において、／ＴＭＰ／ＳＴＡＧＩＮＧ／２３４２３．ＴＸＴ．であるマニフェストファイル４０６のパス名を含む。この例において、マニフェストは、テキストファイルであり、上述したテキストフォーマットの実施形態であることを含意する。１つの実施形態において、マニフェストは、スクリプトが呼び出される前にテキストファイルに変換されるように、２進数形式の実施形態に格納される。
【００８５】
情報４００は、ソースファイルセットディレクトリ４０６、および、より早い（変更の前の）バージョンを支持し得るか、自動的に回帰される任意のコンテンツを保持し得る、回帰ディレクトリディレクトリ４０８を含む。宛先４０９のアレイが示される。各アレイの要素は、ファイルの宛先についての情報を含む。この例において、２つの宛先ホスト、ＯＯＬＯＮＧおよびＤＡＲＪＥＥＬＩＮＧがある。アレイの第１の要素は、ＢＥＧＩＮＥＬＥＭＥＮＴステートメント４１０で開始し、ＥＮＤＥＬＥＭＥＮＴステートメント４１４で終了する。アレイ要素は、この場合においてはＯＯＬＯＮＧである、宛先ホストの名前４１１を含む。アレイ要素は、この例においては／ＨＯＭＥ／ＨＴＴＰＤ−ＯＯＬＯＮＧ／ＤＯＣ／ＩＭＡＧＥＳである、宛先ホストの宛先ディレクトリ４１２を含む。アレイ要素は、この例においてはＮＯＲＭＡＬである、転送４１３の状態を含む。アレイの第２の要素は、ＢＥＧＩＮＥＬＥＭＥＮＴステートメント４１５で開始し、ＥＮＤＥＬＥＭＥＮＴステートメント４１９で終了する。第２のアレイ要素は、この場合においてはＤＡＲＪＥＥＬＩＮＧである、宛先ホストの名前４１６を含む。アレイ要素は、この例においては／ＨＯＭＥ／ＨＴＴＰＤ−ＤＡＲＪＥＥＬＩＮＧ／ＤＯＣ／ＩＭＡＧＥＳである、宛先ホストの宛先ディレクトリ４１７を含む。第２のアレイ要素は、この例においてはＮＯＲＭＡＬである、転送４１８の状態を含む。従って、ユーザスクリプトに提供される情報は、同じスクリプトが、ジョブの実行の間に、異なる場合に呼び出されることを可能にし、スクリプトは、提供されるパラメータに依存して、異なるアクションを取り得る。
【００８６】
本明細書の記載の変形例、改変例、および他の実現例は、請求された本発明の精神および範囲から逸脱することなく、当業者によって想起され得る。従って、本発明は、前述の例示的な記載によって規定されるものではなく、特許請求の範囲の精神および範囲によって規定される。
【図面の簡単な説明】
【図１】 図１は、本発明による、ウェブサービスシステムの実施形態のブロック図である。
【図２】 図２は、ウェブサービスシステムの実施形態のより詳細なブロック図である。
【図３】 図３は、図１のコンテンツディストリビュータの実施形態の動作のフローチャートである。
【図４】 図４は、現在のソースファイルセットと前のファイルセットとの比較のフローチャートである。
【図５】 図５は、マニフェストエントリーの実施形態の図である。
【図６】 図６は、変更されたファイルのリストの一例の図である。
【図７】 図７は、図６の変更されたファイルを示すマニフェストの例示的な実施形態の図である。
【図８】 図８は、古いバージョンのメンテナンスの実施形態の一例の図である。
【図９】 図９は、キャッシュサーバと通信するウェブサービスシステムの実施形態のブロック図である。
【図１０】 図１０は、コンテンツを配信する方法の実施形態のフローチャートである。
【図１１】 図１１は、コンテンツディストリビュータの他の実施形態の動作のフローチャートである。
【図１２】 図１２は、コンテンツディストリビュータの他の実施形態の動作のフローチャートである。
【図１３】 図１３は、図１２の実施形態のスクリプトに提供される情報の一例の図である。

Claims (25)

1. マスターソースファイルセット内の変更点を、１つ以上のホストに配置された宛先ファイルシステムで複製する方法であって、該宛先ファイルシステムは、各ホスト内のそれぞれのウェブサーバによってアクセスされ、
   該方法は、
   （ａ）マスターコンピュータ上で該マスターソースファイルセット内の変更点を識別する工程と、
   （ｂ）修正リストに該識別された変更点を格納する工程と、
   （ｃ）該ウェブサーバの各々に該マスターソースファイルセットがすでに変更されたことを通知するために、各ホストにおけるそれぞれのエージェントに、該修正リストを送信する工程であって、該それぞれのエージェントは、同じホスト内で動作する該ウェブサーバのうちのそれぞれの１つのウェブサーバと通信し、該エージェントは、対応するホストにおける該宛先ファイルシステムへのアクセスを有する、工程と、
   （ｄ）該識別された変更点を該エージェントに送信する前に、所定のゼロでない数のエージェントが、それぞれのウェブサーバが該識別された変更点を受信可能であると判定するまで待つ工程と、
   （ｅ）該ウェブサーバのうち、そのウェブサーバでのインストールの完了のために該識別された変更点を受信可能であるウェブサーバに対応する該エージェントに、該ウェブサーバのうちの他の１つのウェブサーバが該識別された変更点のインストールを完了することが不可能であるかどうかにかかわらず、該識別された変更点を送信する工程と、
   （ｆ）工程（ｄ）の後に、該宛先ファイルシステムが該識別された変更点をインストールしたことを示す応答を、該エージェントのうちの少なくとも１つから受信する工程と
   を包含する、方法。
2. （ｇ）前記エージェントに前記マスターソースファイルセットの変更されたファイルのコピーを送信する工程をさらに包含する、請求項１に記載の方法。
3. 前記識別する工程が、
   現在のバージョンのマスターソースファイルセットを検査する工程と、
   前記マスターコンピュータ上で、該現在のバージョンのマスターソースファイルセットを以前のバージョンのマスターソースファイルセットと比較する工程と
   を包含する、請求項１に記載の方法。
4. 前記比較する工程が、前記現在のバージョンのマスターソースファイルセットのファイルのファイル属性を前記以前のバージョンのマスターソースファイルセットのファイルのファイル属性と比較することを包含する、請求項３に記載の方法。
5. 前記ファイル属性が、ファイルサイズ、ファイル許可、ファイル所有権、修正時刻、およびファイルのハッシュからなるグループから選択された少なくとも１つの属性を含む、請求項４に記載の方法。
6. 前記ファイル属性が、ファイル属性のリストに格納される、請求項４に記載の方法。
7. 前記識別する工程が、
   ファイルオペレーションを実行し、前記マスターソースファイルセットの変更点を監視するためにデバイスドライバをインストールする工程と、
   該デバイスドライバによって、該マスターソースファイルセットの変更点を記録する工程と
   を包含する、請求項１に記載の方法。
8. 前記識別する工程が、
   前記マスターソースファイルセットの変更点を記述するマニフェストを受信することを包含する、請求項１に記載の方法。
9. 前記識別する工程の前に、オペレーティングシステム機能を呼び出すことによって、ユーザ設定可能な命令のスクリプトを呼び出す工程をさらに包含する、請求項１に記載の方法。
10. 前記送信する工程の前に、オペレーティングシステム機能を呼び出すことによって、ユーザ設定可能な命令のスクリプトを呼び出す工程をさらに包含する、請求項１に記載の方法。
11. 前記送信する工程の後に、オペレーティングシステム機能を呼び出すことによって、ユーザ設定可能な命令のスクリプトを呼び出す工程をさらに包含する、請求項１に記載の方法。
12. 前記送信する工程が完了したかどうかを判定する工程をさらに包含し、前記呼び出す工程が、該判定する工程の後に生じる、請求項１１に記載の方法。
13. 前記スクリプトを呼び出す工程は、前記送信が成功したことが既知になった後に生じる、請求項１１に記載の方法。
14. 前記送信する工程は、マルチキャスティングすることを包含する、請求項１に記載の方法。
15. 前記修正リストとは別に前記エージェントに信号を送信することをさらに包含し、該信号は、該エージェントが前記少なくとも１つのウェブサーバに前記変更点をインストールすることが許可されていることを示す、請求項１に記載の方法。
16. ウェブサービスシステムであって、
    該ウェブサービスシステムは、
    該ウェブサービスシステムを管理するように構成されたマネージャと、
    １つ以上のホストであって、各ホストは、ウェブページリクエストを受信するウェブサーバと、該マネージャおよび該ウェブサーバと通信するエージェントとを備える、ホストと、
    該１つ以上のホストおよび該マネージャと通信するコンテンツディストリビュータと
    を備え、
    該コンテンツディストリビュータは、該１つ以上のホストに、マスターコンピュータ上でのマスターソースファイルセットの変更点の通知を提供するように構成されており、該コンテンツディストリビュータは、該識別された変更点を該エージェントに送信する前に、所定のゼロでない数のエージェントが、それぞれのウェブサーバが該識別された変更点を受信可能であると判定するまで待ち、その後、該ウェブサーバのうち、そのウェブサーバでのインストールの完了のために該識別された変更点を受信可能であるウェブサーバに対応する該エージェントに、該ウェブサーバのうちの他の１つのウェブサーバが該識別された変更点のインストールを完了することが不可能であるかどうかにかかわらず、該識別された変更点を送信するように構成されており、該コンテンツディストリビュータは、該識別された変更点がインストールされたことを示す応答を受信するように構成されている、ウェブサービスシステム。
17. 前記マネージャと通信するトラフィックマネージャをさらに備え、該トラフィックマネージャは、ウェブページリクエストを前記ウェブサーバに向ける、請求項１６に記載のシステム。
18. 前記コンテンツディストリビュータが、
    （ａ）マスターコンピュータ上で前記マスターソースファイルセット内の変更点を識別する識別モジュールと、
    （ｂ）該マスターソースファイルセットの識別された変更点を格納する修正リストを格納する修正リスト記憶手段と、
    （ｃ）該修正リストを、宛先ファイルシステムへのアクセスを有する前記エージェントに送信する送信器と、
    （ｄ）該宛先ファイルシステムが該識別された変更点を受信したことを示す応答を受信する受信器と
    を備える、請求項１６に記載のシステム。
19. 前記マスターソースファイルセットの変更されたファイルのコピーを前記エージェントに送信する送信器をさらに備える、請求項１８に記載のシステム。
20. 前記エージェントが、前記宛先ファイルシステム上で前記マスターソースファイルセットの変更されたファイルのコピーをインストールするインストーラを備える、請求項１８に記載のシステム。
21. コンピュータと通信するコンテンツディストリビュータであって、
    該コンテンツディストリビュータは、
    （ａ）マスターコンピュータ上でマスターソースファイルセット内の変更点を識別するように構成された識別モジュールと、
    （ｂ）該マスターソースファイルセットの識別された変更点を格納する修正リストを格納するように構成された修正リスト記憶手段と、
    （ｃ）該修正リストを、該コンピュータと通信する１つ以上のエージェントに送信するように構成された送信器であって、該エージェントは、宛先ファイルシステムへのアクセスを有し、該送信器は、該識別された変更点を該エージェントに送信する前に、所定のゼロでない数のエージェントが、それぞれのウェブサーバが該識別された変更点を受信可能であると判定するまで待ち、その後、該ウェブサーバのうち、そのウェブサーバでのインストールの完了のために該識別された変更点を受信可能であるウェブサーバに対応する該エージェントに、該ウェブサーバのうちの他の１つのウェブサーバが該識別された変更点のインストールを完了することが不可能であるかどうかにかかわらず、該識別された変更点を送信する、送信器と、
    （ｄ）該修正リストが送信された後に、該宛先ファイルシステムが該識別された変更点を受信したことを示す応答を該コンピュータから受信するように構成された受信器と
    を備える、コンテンツディストリビュータ。
22. 前記送信器は、前記宛先ファイルシステム上でのインストールのために、前記マスターソースファイルセットの変更されたファイルのコピーを前記エージェントに送信するようにさらに構成されている、請求項２１に記載のコンテンツディストリビュータ。
23. マスターソースファイルセット内の変更点を、それぞれのホストに配置された宛先ファイルシステムで複製する方法であって、該宛先ファイルシステムは、複数のウェブサーバのうちのそれぞれのウェブサーバによってアクセスされ、
    該方法は、
    （ａ）マスターコンピュータ上で該マスターソースファイルセット内の変更点を識別する工程と、
    （ｂ）修正リストに該識別された変更点を格納する工程と、
    （ｃ）それぞれのエージェントに、該修正リストを送信する工程であって、該それぞれのエージェントは、該ウェブサーバのうちのそれぞれのウェブサーバと通信し、該エージェントは、それぞれの宛先ファイルシステムへのアクセスを有し、該宛先ファイルシステムの各々は、それぞれのエージェント、およびそれぞれの同じホスト上で動作するウェブサーバを有し、それにより、それぞれのウェブサーバに、該マスターソースファイルセットがすでに変更されたことを通知する、工程と、
    （ｄ）所定の数のウェブサーバが、更新されたコンテンツを受信可能になることを待つ工程と、
    （ｅ）所定のゼロでない数のウェブサーバが、該更新されたコンテンツを受信可能である場合には、
    （１）該ウェブサーバのうち、そのウェブサーバでのインストールの完了のために該識別された変更点を受信可能であるウェブサーバに対応する該エージェントに、該ウェブサーバのうちの他の１つのウェブサーバが該識別された変更点のインストールを完了することが不可能であるかどうかにかかわらず、該変更点を送信する工程、および、
    （２）該識別された変更点が該エージェントのそれぞれの宛先ファイルシステムにインストールされたことを示す応答を少なくとも１つのウェブサーバから受信する工程と、
    （ｆ）該所定の数よりも少ないウェブサーバが、該更新されたコンテンツを受信可能な場合には、該変更点を該エージェントに送信することを中止する工程と
    を包含する、方法。
24. 新たなコンテンツをサービス可能なエージェントの数が十分で無い場合に、前記変更点のインストールを中止することをさらに包含する、請求項２３に記載の方法。
25. 前記修正リストとは別に前記エージェントに信号を送信することをさらに包含し、該信号は、該エージェントがそれぞれのウェブサーバに前記変更点をインストールすることが許可されていることを示す、請求項２３に記載の方法。

Images