(57)【要約】サーバの多層アーキテクチャにおいてキャッシュの内容の一貫性を維持するための方法およびシステムが説明される。これは、それぞれのサテライト・サーバがローカル・キャッシュを操作するサテライト・サーバからなるフロント層と、それぞれの中央サーバが集中キャッシュを操作する中央サーバからなる中間層とを含む。中央サーバは、オブジェクトを構築し、それらのオブジェクトを集中キャッシュに記憶するために使用されるデータ要素を取り出すためにデータベース・サーバを通じてデータベースとインターフェースを取る。いったん構築されると、オブジェクトは、生存時間（ＴＴＬ）属性を与えられ、集中キャッシュに記憶され、それから、それらのオブジェクトを要求したソフトウェア・アプリケーションに送達される前にそれらのオブジェクトがローカル・キャッシュに記憶されるサテライト・サーバに転送される。それらのオブジェクトは期限切れになったときに無効化され、中央サーバから再構築され、その中央サーバからそれらのオブジェクトが全ての集中キャッシュと、それらのオブジェクトが必要とされるローカル・キャッシュとに転送される。
2009510578.tif 000002
【特許請求の範囲】
【請求項１】
少なくとも１つのサテライト・サーバを含むフロント層（２２０）を含む多層ソフトウェア・アーキテクチャ内でキャッシュの内容の一貫性を維持する方法において、それぞれの前記少なくとも１つのサテライト・サーバはローカル・キャッシュ（２３０）を操作し、前記アーキテクチャは少なくとも１つの中央サーバ（２１２）を含む中間層（２１０）を含み、それぞれの前記少なくとも１つの中央サーバは集中キャッシュ（２１６）を操作し、それぞれの前記少なくとも１つの中央サーバは少なくとも１つのデータベース・サーバ（２０２）を通じて少なくとも１つのデータベース（２０４）とインターフェースを取り、前記少なくとも１つのデータベースはデータ要素（３６０）を含み、前記データ要素はそれぞれの前記少なくとも１つの中央サーバから前記少なくとも１つのデータベース・サーバに発行された問い合わせを用いて取り出される、方法であって、
前記少なくとも１つのデータベースからの少なくとも１つの前記データ要素をもとに前記少なくとも１つの中央サーバでオブジェクトを構築するステップ（３５０）であって、前記オブジェクトを検証するさらなるステップ、前記オブジェクトに生存時間（ＴＴＬ）を属性として与えるさらなるステップ、および前記オブジェクトを前記集中キャッシュ（３４０）に記憶するさらなるステップを含む、構築するステップ（３５０）と、
前記オブジェクトを前記集中キャッシュから前記オブジェクトを要求している前記サテライト・サーバのうちの任意のサテライト・サーバに転送するステップ（３３０、３７０）であって、前記オブジェクトを前記ローカル・キャッシュに記憶するさらなるステップを含む、転送するステップ（３３０、３７０）と、
前記サテライト・サーバ上で実行されており、前記オブジェクトを要求しているソフトウェア・アプリケーションの前記ローカル・キャッシュに前記オブジェクトを送達するステップ（３３５、３７５）と
を含むことを特徴とする、方法。
【請求項２】
前記サテライト・サーバからの要求が全ての利用可能な前記中央サーバ上に負荷分散され（３８５）、前記中央サーバのうちの１つが要求毎に選択されることを特徴とする請求項１に記載の方法。
【請求項３】
前記構築するステップが、新しく構築されたオブジェクト（３５５）を前記選択された中央サーバから全てのその他の前記中央サーバに複製するさらなるステップ（３８０）を含むことを特徴とする請求項１または２に記載の方法。
【請求項４】
前記ローカル・キャッシュ内でオブジェクトが見つからない（３２０、３５０）か、または期限切れである（４０５）ときにはいつも、前記オブジェクトが前記選択された集中キャッシュ（３４０）から要求される（３９０）ことを特徴とする請求項１または２に記載の方法。
【請求項５】
前記選択された集中キャッシュ内で要求されたオブジェクトが見つからない（３５５）ときにはいつも、前記選択された中央サーバにおいて前記構築するステップ（３５０）が開始されることを特徴とする請求項１または２に記載の方法。
【請求項６】
ＴＴＬを属性として与える前記ステップ、および前記オブジェクトを記憶する前記ステップが、前の前記検証するステップが前記オブジェクトの検証に失敗した場合に前記オブジェクトを拒絶するステップ（３５７）によって置き換えられることを特徴とする請求項１または２に記載の方法。
【請求項７】
前記集中キャッシュにおいて要求されたオブジェクトが既に存在し（３４５）、期限切れでない（４４５）ときにはいつも、前記選択された中央サーバにおいて前記構築するステップ（３５０、４５０）がスキップされることを特徴とする請求項１または２に記載の方法。
【請求項８】
１つの前記中央サーバが主中央サーバ（３４０）として指定され、全てのその他の前記中央サーバはバックアップ中央サーバであることを特徴とする請求項１から７のいずれか一項に記載の方法。
【請求項９】
前記選択された中央サーバにおいて前記要求されたオブジェクトが期限切れであると分かった（４５５）ときにはいつも、前記主中央サーバにおいて無効化ハンドラ（４６０）から前記構築するステップが開始される（４８０）ことを特徴とする請求項１から８のいずれか一項に記載の方法。
【請求項１０】
前記期限切れのオブジェクト（４５５）のＴＴＬが、要求元サテライト・サーバに転送される（４８５）前に小さな値に設定されることを特徴とする請求項９に記載の方法。
【請求項１１】
前記集中キャッシュ内および前記ローカル・キャッシュ内に記憶されたオブジェクトが、前記オブジェクトを構築するために使用された少なくとも１つの前記データ要素（５００）が前記データベース内で修正されると直ちに無効化され、
どのオブジェクトが影響を受けるかを判定するステップと、
無効化命令を前記中央サーバの全ての無効化ハンドラにブロードキャストするステップ（５１０）と、
前記集中キャッシュ内の対応するオブジェクトを無効化するステップ（５１５）と、
前記無効化命令を全ての前記ローカル・キャッシュに伝達するステップ（５５０）と、
前記ローカル・キャッシュ内の対応するオブジェクト（５６０）を無効化するステップであって、前記オブジェクトを削除するさらなるステップを含む、無効化するステップと
を含むことを特徴とする前記請求項のいずれか一項に記載の方法。
【請求項１２】
前記集中キャッシュ内のオブジェクトを無効化する前記ステップが、前記オブジェクトを削除するさらなるステップを含むことを特徴とする請求項１１に記載の方法。
【請求項１３】
前記オブジェクトを削除する前記ステップが、再構築されたオブジェクトを全ての前記バックアップ中央サーバに複製するさらなるステップ（５４０）を含む前記主中央サーバ（５２０）において前記オブジェクトを再構築するステップ（５３５）によって置き換えられることを特徴とする請求項１２に記載の方法。
【請求項１４】
それぞれの前記中央サーバが、オブジェクト再構築進行中テーブル（６００）、および前記進行中テーブルから前記オブジェクト再構築を監視するためのスカベンジャ・プロセス（６３５）を含み、
オブジェクト再構築の開始および終了を前記進行中テーブルにロギングするステップ（６１０）と、
前記オブジェクト再構築の完了を検出するために前記進行中テーブルを調べるステップ（６３５）であって、成功裏に完了したオブジェクト再構築のテーブル・エントリを消去するさらなるステップを含む、調べるステップ（６３５）と、
失敗した進行中のオブジェクト再構築を検出するステップと、
失敗したオブジェクト再構築を再試行するステップと
を含むことを特徴とする前記請求項のいずれか一項に記載の方法。
【請求項１５】
前記オブジェクト再構築が前記主中央サーバにおいて実行され、前記ロギングするステップが、オブジェクト再構築の開始をバックアップ中央サーバの全ての前記進行中テーブルに転送するさらなるステップ（６２５）を含むことを特徴とする請求項１４に記載の方法。
【請求項１６】
主中央サーバから転送されたオブジェクトを受信する（６１５）と、オブジェクト再構築の終了がバックアップ中央サーバの前記進行中テーブルにロギングされることを特徴とする請求項１５に記載の方法。
【請求項１７】
前記検出するステップおよび前記再試行するステップが、前記バックアップ中央サーバのうちの１つにおいて実行されることを特徴とする請求項１４に記載の方法。
【請求項１８】
前記構築するステップが、
前記集中キャッシュが一杯であるか否かをチェックし、一杯でない場合は直ちに前記構築するステップに進み、一杯である（７６０）場合は前記集中キャッシュ内のＬＲＵオブジェクトを選択する（７７０）予備ステップと、
前記ＬＲＵオブジェクトが期限切れか否かをチェックし、期限切れでない（７９２）場合は前記ＬＲＵオブジェクトを２次記憶に記憶し（７７５）、期限切れである（７９４）場合は前記ＬＲＵオブジェクトを破棄し（７８０）、どちらの場合も前記構築するステップに進む予備ステップと
を含むことを特徴とする請求項１に記載の方法。
【請求項１９】
前記再構築するステップに進む前に前記２次記憶（７２０）が、前記見つからないオブジェクトを探してさらに検索されることを特徴とする請求項１３に記載の方法。
【請求項２０】
サーバの多層アーキテクチャにおいてキャッシュの内容の一貫性を維持するためのシステムであって、請求項１から１９のいずれか一項に記載の方法の各ステップを実行するように適合された手段を含むことを特徴とする、システム。
【請求項２１】
少なくとも１つのデータベースからのデータ要素を用いてオブジェクトを構築するための手段（３５０）と、期限切れであるときに前記データ・オブジェクトを無効化するための手段（４５０）と、前記期限切れオブジェクトの再構築を管理するための手段（５００、５３５）とを含むことを特徴とする請求項２０に記載のシステム。
【請求項２２】
請求項１から１９のいずれか一項に記載の多層ソフトウェア・システムにおいてキャッシュの内容の一貫性を維持する方法を少なくとも１つのコンピュータに行わせるためのコンピュータ可読コード手段を含むことを特徴とする、コンピュータ可読記憶媒体上に記憶されたコンピュータ・プログラム製品。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は概して多層クライアント／サーバ・ソフトウェア・アーキテクチャに関し、より具体的には、全体の性能を向上するためにフロントおよび中間層のマシンに実装されるキャッシュの内容の間の一貫性を維持するための方法およびシステムに関する。
【背景技術】
【０００２】
１９８０年代の終わり頃に登場したクライアント／サーバ・モデルは、当時一般的であった集中型のメインフレームの時分割コンピューティングと比較してユーザビリティ、柔軟性、相互運用性、およびスケーラビリティを向上するように意図された用途の広いモジュール式のソフトウェア・アーキテクチャである。クライアントはサービスの要求側であり、サーバはそのようなサービスの提供側である。ソフトウェアの設定に応じて、同じマシンがクライアントおよびサーバの両方であることができる。
【０００３】
クライアント／サーバ・アーキテクチャは、全てのインテリジェンスが中央ホストコンピュータ内にあり、キーストロークを捕捉し、その情報をホストに送るだけのデータ処理能力のない端末を通じてユーザがホストとインタラクションした従来のメインフレームのソフトウェア・アーキテクチャを次第に置き換えた。メインフレームのソフトウェア・アーキテクチャのよく知られている制限は、それらのアーキテクチャが容易にグラフィカル・ユーザ・インターフェース（ＧＵＩ）をサポートしないか、または地理的に分散した場所から複数のデータベースにアクセスしないことである。しかし、メインフレームは、分散クライアント／サーバ・アーキテクチャにおいて高性能なサーバとしてまだ使用される。
【０００４】
クライアント／サーバ・アーキテクチャは、ファイル・サーバとして動作するデータベース・サーバを取り入れた。このアーキテクチャにおいて、ユーザの問い合わせは、リレーショナル・データベース管理システムまたはＲＤＢＭＳを使用して直接応答される。必ずファイル全体を転送するのではなく問い合わせ応答を提供することによってネットワーク・トラフィックが削減される。それは、共有データベースに対するＧＵＩフロント・エンドを通じて複数のユーザの更新も改善する。クライアント／サーバ・アーキテクチャにおいて、概して、クライアントとサーバの間のデータ交換のために構造化照会言語（ＳＱＬ）ステートメントが使用される。
【０００５】
図１に示される２層クライアント／サーバ・アーキテクチャ（１００）を用いる場合、ユーザ・システム・インターフェースが、ユーザのデスクトップ（１０２）環境内に置かれ、データベース管理サービスが、多くのクライアントにサービスを提供することができるサーバ（１０４）内にある。処理の管理は、ユーザ・システム・インターフェース環境とデータベース管理サーバ環境との間で分けられる。ローカル・エリア・ネットワークまたはＬＡＮ（１０８）上にあることが最も多い、単一の／複数のサーバ（図示せず）とインターフェースを取る単一の／複数のクライアントを含むトポロジの全ての組合せが当然可能である。
【０００６】
従来の２層アーキテクチャにおいて、第１層、クライアント（１０２）は、ユーザ・インターフェース、主なビジネスおよびデータ処理ロジックを保持する。第１層、クライアント（１０２）は、ユーザ入力の構文を受け取り、チェックし、アプリケーション・ロジックを処理し、データベース要求を生成し、それらの要求をサーバに送信し、ユーザ・タスクに応答を渡す。第２層、データベース・サーバ（１０４）は、クライアントからのデータベース要求を受け取り、処理し、権限をチェックし、整合性制約が破られないことを保証し、問い合わせ／更新処理を実行し、クライアントに応答を送信する。また、第２層、データベース・サーバ（１０４）は、システムカタログを維持し、同時データベース・アクセスを提供し、リカバリー制御を実行する。
【０００７】
２層クライアント／サーバ・アーキテクチャは、ワーク・グループがＬＡＮ上で同時にインタラクションする人が１００人を超えないときの分散コンピューティングのための優れたソリューションであることが分かっている。しかし、ユーザ数が増えるとき、たとえ何も処理が行われていないとしてもサーバが「キープアライブ」メッセージを介して各クライアントとの接続を維持する結果として性能が低下し始める。２層アーキテクチャの第２の制限は、ベンダの独自開発のデータベース・プロシージャを使用した管理サービスの処理の実装がアプリケーションに対するＲＤＢＭＳの柔軟性および選択を制限することである。また、２層アーキテクチャの実装は、あるサーバから別のサーバにプログラムの機能を移動する（再配分する）ことにおいて乏しい柔軟性を示した。
【０００８】
そこで、上記の制限を克服するために９０年代に３層アーキテクチャ（１２０）および多層の変形形態が登場した。３層アーキテクチャにおいて、ユーザ・システム・インターフェース・クライアント環境（１２２）とデータベース管理サーバ環境（１２４）との間に中間層が追加された（１２６）。このアーキテクチャおよび中間層を実装する様々なやり方が存在するが、この後者は、待ち行列管理、アプリケーションの実行、およびデータベースのステージングを担うことが最も多い。概して、中間層がデータにアクセスし、応答をクライアントに返すことになっているので、クライアントはそのクライアントの要求を中間層に送達し、解放される。さらに、中間層は、進行中の処理に関するスケジューリングおよび優先順位付けを追加する。
【０００９】
３層アーキテクチャの上記の変形形態において、クライアント、すなわち第１層はユーザ・インターフェースを実行すること、すなわち入力を確認することのみが必要である可能性があり、この場合、中間層が全てのビジネス・ロジックを保持し、データ処理を行う一方、サーバ、すなわち第３層がデータ妥当性検証を実行し、データベース・アクセスを制御する。
【００１０】
３層クライアント／サーバ・アーキテクチャは、多数のユーザ（概して最大１０００、すなわち２層の１０倍まで）を有するグループに対する性能を向上することが分かっており、特にアプリケーション・コードを層間で共有する必要がないので２層アプローチと比較したとき柔軟性を向上する。３層クライアント／サーバ・アーキテクチャは、クライアントからサーバへの直接接続を用いた２層アーキテクチャよりも著しくスケーラブルである環境をもたらす。３層クライアント／サーバ・アーキテクチャは、単一のトランザクション内で複数の異なるＲＤＢＭＳを更新する能力を提供し、フラット・ファイル、非リレーショナル・データベース管理システムを含む様々なデータ・ソースに、およびさらに現在は高性能なデータベース・サーバとして使用されることが多いメインフレームに接続することができる。したがって、３層および多層アーキテクチャは、大規模な分散クライアント／サーバ環境に最もよく適合する。例えば、航空券予約会社がそれらの会社の顧客、すなわち世界中の旅行代理店にサービスを提供するために配備しなければならず、異種のデータベース（すなわち、航空会社の運賃データベースおよび予約状況データベース）ならびに処理規則などの共有リソースが必要とされる分散クライアント／サーバ環境である。
【００１１】
多層データセンタがそのようなサービスを提供するための主な要件になった場合、計算および通信のオーバヘッドを削減することが、性能およびスケーラビリティをさらに向上するために不可欠である。多層データセンタの様々な層において動的な内容をキャッシュすることは、ヒットした場合は上に位置する層からデータが再びフェッチされる必要がないためにさらに多くの顧客が同時にサービスを提供されることができるように計算および通信のオーバヘッドを削減するためのよく知られた方法である。しかし、中間およびフロント層におけるキャッシングは、そのキャッシング特有の難問を抱えている。キャッシュの整合性およびキャッシュの一貫性が、適宜処理されなければならない問題になる。具体的には、古い航空券利用状況の値が許容されない航空券予約に関して、強い整合性および一貫性が不可欠である。
【発明の開示】
【発明が解決しようとする課題】
【００１２】
したがって、多層ソフトウェア・アーキテクチャにおいて動的なキャッシュの内容の一貫性を維持するための方法およびシステムを提供することが本発明の主要な目的である。
これが、航空券予約システムのために配備され、クライアント側からの非常に高レベルのトランザクションと、航空会社およびその他のそのようなサービス提供者によって提供される運賃データベースおよび利用状況データベースの非常に頻繁な更新とによって特徴付けられる多層アーキテクチャなどの多層アーキテクチャに適合しなければならないことが本発明のより具体的な目的である。
【００１３】
本発明のさらなる目的、特徴、および利点は、添付の図面を参照して以下の説明を検討すると当業者に明らかになるであろう。あらゆる追加的な利点が本明細書に組み込まれることが意図される。
【課題を解決するための手段】
【００１４】
多層ソフトウェア・アーキテクチャにおいてキャッシュの内容の一貫性を維持するための方法およびシステムが説明される。これは、それぞれのサテライト・サーバがローカル・キャッシュを操作するサテライト・サーバからなるフロント層と、それぞれの中央サーバが集中キャッシュを操作する中央サーバからなる中間層とを含む。中央サーバは、オブジェクトを構築するために使用されるデータ要素を取り出すためにデータベース・サーバを通じてデータベースとインターフェースを取る。いったん構築されると、オブジェクトは、生存時間（ＴＴＬ）を属性として与えられ、集中キャッシュに記憶され、それから、それらのオブジェクトを要求したソフトウェア・アプリケーションに送達される前にそれらのオブジェクトがローカル・キャッシュに記憶されるサテライト・サーバに転送される。サテライト・サーバからの要求は、全ての利用可能な中央サーバ上に負荷分散される。中央サーバは処理すべき要求毎に選択される。新しく構築されたオブジェクトは、選択された中央サーバから全てのその他の中央サーバ内に複製される。オブジェクトは、ローカル・キャッシュ内でそのオブジェクトが見つからないか、または期限切れであるときにはいつも、選択された集中キャッシュから要求される。要求されたオブジェクトの構築は、選択された集中キャッシュ内でそのオブジェクトが見つからないときにはいつも、選択された中央サーバにおいて開始される。要求されたオブジェクトが集中キャッシュ内に既に存在し、期限切れでない場合、構築はスキップされる。１つの中央サーバは主中央サーバとして指定され、全てのその他の中央サーバはバックアップ中央サーバである。構築は、要求されたオブジェクトが期限切れであると分かったときにはいつも、主中央サーバにおいて無効化ハンドラから開始される。見つかった期限切れオブジェクトのＴＴＬは、要求元サテライト・サーバに転送される前に小さな値に設定される。集中キャッシュ内およびローカル・キャッシュ内に記憶されたオブジェクトは、どのオブジェクトが影響を与えられるのかを判定し、それから無効化命令を全ての中央サーバの無効化ハンドラにブロードキャストするデータベースにおいてそれらのオブジェクトを構築するために使用された少なくとも１つのデータ要素が修正されると直ちに無効化される。それらの中央サーバの無効化ハンドラは集中キャッシュ内の対応するオブジェクトを無効化し、それから無効化命令を全てのローカル・キャッシュに伝え、今度はそれらの無効化命令がローカル・キャッシュ内の対応するオブジェクトを無効化および削除する。集中キャッシュ内の無効化されたオブジェクトは、削除されるか、または再構築されるかのいずれかである。この後者の場合、再構築されたオブジェクトが全てのバックアップ集中キャッシュに複製される。
【発明を実施するための最良の形態】
【００１５】
本発明の以下の詳細な説明は添付の図面を参照する。説明は例示的実施形態を含むがその他の実施形態も可能であり、本発明の精神および範囲から逸脱することなしに、説明された実施形態に変更がなされることができる。
【００１６】
図２は、本発明が最もよく当てはまる多層ソフトウェア・アーキテクチャの全体を示す。
【００１７】
上位層（２００）は、概して少なくとも１つのデータベース・サーバ（２０２）が世界中から運輸会社およびそのようなサービスのその他の提供者によって提供される利用状況データベースおよび運賃データベースなどの複数のデータベース（２０４）とインターフェースを取る根本的なデータ・ソースである。それらのデータベースは、それらのデータベースのユーザ、すなわち、インターネットを含む私設ネットワークおよび公衆ネットワークの組合せ（２０８）を通じて行われることが最も多いそれらのデータベースの内容の更新および維持を担うユーザ（２０６）によって頻繁に更新される。概して、日常的に、大容量のデータを含む無数のトランザクションが記録される可能性がある。
【００１８】
ここで、中間層（２１０）が、以降で中央データ・サーバまたはＣＤＳと呼ばれる２つのサーバからなることが示される。概して、冗長性を持たせるために主サーバ（２１２）およびバックアップ・サーバ（２１４）が存在する。しかし、１つのサーバ（冗長性なし）と多数のサーバの間の任意の構成が可能である。また、中央サーバは、例えばシステムの保守を容易にするために、または指定された主ＣＤＳが故障しているためにスタンドアロン・サーバとして構成されなければならないことが時折あり得る。さらに、指定されたバックアップ・サーバは、必要なときに一時的に主サーバとして機能しなければならない可能性がある。このことは、本発明の以下の説明においてさらに検討される。
【００１９】
中間層に複数のサーバを持つことはこのアーキテクチャを用いた通常のやり方である。主サーバと同じ役割を果たす２つ以上の冗長なサーバか、または異なるアプリケーション・プログラムを実行する専用サーバが存在してよい。より高い処理性能が必要とされる場合にスケーラビリティをもたらす１つのやり方は、フロント層（２２０）の要求をより多くの中間層のサーバ上に負荷分散することを通じてより多くのクライアント・トランザクションが処理されることができるように中間サーバを追加することからなる。したがって、各ＣＤＳは、常に一貫した内容を保持しなければならない集中キャッシュと呼ばれるそのＣＤＳ独自のキャッシュ（２１６、２１８）を持つ。
【００２０】
本発明によって考慮される種類のアプリケーションにおいて、キャッシュ内に存在するデータ・エンティティは、以下では概してソフトウェア・オブジェクトまたは単にオブジェクトと呼ばれる。概して、問い合わせを通じてデータベースから取得される多くのデータ要素が、それらのオブジェクトを生成するためにまとめられる必要がある。したがって、本発明によるオブジェクトは、例えば、データベース・サーバ（２０２）を通じてデータベース（２０４）から取得されたデータ要素からＣＤＳによって前に構築された特定の旅行運賃である。背景技術のセクションで検討されたようにデータベースがリレーショナル・データベースである場合、これは、オブジェクト、例えばこの具体例の旅行運賃を構築するために必要とされる全てのデータ要素が最終的にＣＤＳ内に集められることができるようにデータベースに対して少なくとも１つのＳＱＬ要求、および通常はさらに多くのＳＱＬ要求を発行することにおいて達成された。したがって、本発明によるオブジェクトは、使用可能な形態にするために処理性能を必要とし、データ・サーバとの通信帯域幅を使用する複雑なオブジェクトであると考えられる。オブジェクトは、それらのオブジェクトを構築するために使用された元の情報がデータベース内で修正されていない限りキャッシュ内にあることができる。再構築は処理性能を消費し、データベース・サーバおよびそのデータベース・サーバのデータベースとの利用可能な通信帯域幅の一部を使用するので再構築はコストがかかる。一貫性に関して言えば、例えば主ＣＤＳの集中キャッシュ（２１６）内に存在する特定のオブジェクトは、バックアップＣＤＳの集中キャッシュ（２１８）内のそのオブジェクトの複製と厳密に同じでなければならず、それらのオブジェクトの内容は、それらのオブジェクトがそこから構築されたデータベース（２０４）のデータ要素と整合していなければならない。このことは、本発明の以下の説明においてさらに検討される。
【００２１】
フロント層（２２０）は、それらのフロント層（２２０）のエンドユーザのためにソフトウェア・アプリケーションを実行する複数のサテライト・サーバから構成される。本発明を説明するために使用される例において、概して、これらのサテライト・サーバは価格調査または運賃検索エンジンである。これらのソフトウェア・アプリケーションは、サテライト・クライアント・サーバ（２２２）上で直接、またはサーバ・ファーム（２２５）を含む独立したフロント層サテライト・サーバ（２２４）上で実行されることができ、そして次にそれらのフロント層サテライト・サーバ（２２４）が、標準的なブラウザと、インターネットで最も普及したアプリケーションであるワールドワイドウェブまたはウェブとを使用して私設または公衆ネットワーク（２２８）、例えばインターネットを通じて遠隔のユーザ（２２６）からアクセスされる。どちらの場合も、アプリケーションは、フロント層と、全てのサテライト・サーバが接続される中間層のＣＤＳとの間の通信のオーバヘッドを削減するために基本的にローカル・キャッシュ（２３０）を利用している。したがって、上述のオブジェクトは、必要なときに種々のローカル・キャッシュにも運ばれる。したがって、ローカル・アプリケーションは、要求されたオブジェクトがそのローカル・キャッシュ内に確かにある場合はＣＤＳまたはデータ・サーバにアクセスする必要がない。これは、データベース・サーバ（２０２）を保護する、すなわち、受信することを防止されなければそれらのデータベース・サーバ（２０２）に到着するであろうエンドユーザ（２２６）からの無数の要求をそれらのサーバが受信することを防止するという最大の利点を有する。
【００２２】
ソフトウェア・アプリケーションが高いキャッシュ・ヒット率を達成するために工夫されるので、それらのソフトウェア・アプリケーションは、それらのソフトウェア・アプリケーションの性能が劇的に改善されたことが分かる。さらに、これは、層間の通信のオーバヘッドを著しく削減し、結局、同じインフラストラクチャ上により多くのエンドユーザを収容することを可能にする。既に上で検討されたようにこの全てはキャッシュの一貫性が維持されることを仮定しており、そのことは以下の図においてさらに検討される。
【００２３】
図３は、アプリケーション・プログラムによるエンドユーザの要求の処理の結果生じるオブジェクトのフェッチの様々な場合を示す。
【００２４】
そのようなアプリケーション・プログラム、例えばフロント層のサーバに置かれた価格調査プログラム（３００）が旅行の価格を計算するためにオブジェクト（３０５）を必要とするとき、ローカル・キャッシュが最初に問い合わせられる（３１０）。ヒットした場合、オブジェクトがローカル・キャッシュから単に取り出される（３１５）。これは、処理全体が当該サーバがアプリケーションを実行することしか必要としないのでオブジェクトを取り出す最も有効なやり方である。
【００２５】
しかし、要求されたオブジェクトがローカル・キャッシュに存在しないとき、ミスが存在する（３２０）。オブジェクトが取り込まれなければならず、ここで、オブジェクトは以降でさらに検討される負荷分散機能を通じて要求が発行される（３９０）主ＣＤＳ（３４０）の集中キャッシュ内に存在するものと初めに仮定される。正にこの上記の場合（３４５）、データ・ハンドラ機能（３５０）は、そのオブジェクトを集中キャッシュから取り出して、そのオブジェクトが記憶される要求元サーバのローカル・キャッシュにそのオブジェクトを転送する（３３０）ことを目的とする。これが行われた後で、要求されたオブジェクトは、ようやくアプリケーション・プログラムに送達されることができる。したがって、ローカル・キャッシュは、場合によってはさらなる要求のために使用されることができるもう１つのオブジェクト（３２５）を含む。
【００２６】
要求されたオブジェクトがローカル・キャッシュに存在せず（３５０）、主ＣＤＳの集中キャッシュにも存在しない（３５５）とき、そのオブジェクトはＣＤＳにおいて構築され、集中キャッシュに記憶されなければならない。これは、要求されたオブジェクト（３５５）を構築するために必要な全てのデータ要素（３６０）をデータベース（３６５）から集めなければならない上述のデータ・ハンドラ（３５０）によって遂行される。オブジェクト構築することは、データベースに対して多くの要求（例えば、ＳＱＬクエリ）を発行することを必要とする可能性がある複雑なプロセスである可能性がある。そのオブジェクトが組み立てられると、オブジェクトの綿密なチェックが実行されて、オブジェクトが要求元アプリケーションによって実際に使用可能であることが確認される。これは、オブジェクト記述言語の構文的および意味的チェックと、さらにアプリケーションのサンプル・コードを用いた試験とを含む。新しいオブジェクトが通常通りこの検証フェーズに合格すると、そのオブジェクトは集中キャッシュに記憶される。記憶する前に生存時間（ＴＴＬ）または有効期限がオブジェクトに付けられ、その結果、図４においてさらに検討されるように期限が切れたときにオブジェクトが削除されることができる。これが行われると、新しいオブジェクトはそのオブジェクトを要求したサーバのローカル・キャッシュに転送され、そのサーバにおいて、そのオブジェクトは最初に記憶され、次にそのオブジェクトを必要とするソフトウェア・アプリケーションに送達される（３７５）。しかし、新しい構築されたオブジェクトの検証が失敗する場合、そのオブジェクトは拒絶され、したがって集中キャッシュに記憶されないか、またはローカル・キャッシュに転送されない（３５７）。
【００２７】
新しいオブジェクトが主ＣＤＳにおいて生成されるとき、そのオブジェクトは、その新しいオブジェクトがその他の中央サーバのキャッシュからも取り出されることができるように（１つまたは複数の）バックアップ中央サーバ（３４２）内にも複製される（３８０）。上述のように、冗長性およびスケーラビリティを与えるために、多くの中間層のサーバは、フロント層のサーバからの要求が１組の利用可能な中央データ・サーバ上に負荷分散されることができるように同時にアクティブであることができる。本発明の範囲を超えている図３に示される負荷分散は、よく知られているラウンドロビン機能と同じように単純であってよい特定のロジックまたはアルゴリズムに従ってフロント層の要求をディスパッチする（３９０）負荷分散機能（３８５）が存在することを述べる以外はさらに検討されない。その場合、受信されたフロント層の要求は、最後のアクティブな中央サーバが到達されるまで順にそれぞれのアクティブな中央サーバに連続的に送信される。そのとき、次の要求は、また最初の番号が付けられた中央サーバに送信され、以下同様である。この簡単なアルゴリズムは非常に有効であることが多い。しかし、各サーバの実際の負荷を測定し、受信された要求を最も負荷がかかっていないサーバにうまく送信する負荷分散など、いくつかのより洗練された負荷分散が存在する。
【００２８】
したがって、見つからないオブジェクトが主ＣＤＳキャッシュから要求されることを述べた上記の説明は修正されなければならない。新しく構築されたオブジェクトがアクティブなサーバ内に複製される（３８０）ので、負荷分散機能（３８５）によってなされる判断に応じて、見つからないオブジェクトはバックアップ集中キャッシュからも要求されることができる。この場合、しかしオブジェクトが選択されたバックアップ集中キャッシュ内に存在しないならば、そのオブジェクトは、あたかも主ＣＤＳが選択されたかのように上で説明されたように構築されなければならない。これが発生するとき、バックアップＣＤＳは一時的に主ＣＤＳとして機能し、このことは、いったん構築されるとオブジェクトはバックアップＣＤＳから全てのアクティブなＣＤＳに複製されるので新しいオブジェクトが全ての中間層の集中キャッシュ内で利用可能になることを意味する。バックアップＣＤＳが一時的に主ＣＤＳとして機能することができる本発明のこの態様は、図６においても検討される。
【００２９】
図４は、キャッシュ内のオブジェクトの経時変化を検討する。既に上で述べたように、全ての構築されたオブジェクトはそれらのオブジェクトに付けられた決められた生存時間（ＴＴＬ）または有効期限を有するので、期限切れの要素がキャッシュから削除されることができ、メモリ内にずっと留まることはない。
【００３０】
ソフトウェア・アプリケーション（４００）がローカル・キャッシュ内の期限切れのオブジェクト（４０５）をフェッチするとき、そのオブジェクトは削除され、したがって要求元アプリケーションには返されない。これは、中間層のＣＤＳ（図３で説明されたように負荷分散機能（図示せず）によって選択されたＣＤＳ）の問い合わせを引き起こす。オブジェクトが集中キャッシュ内に存在し（４４５）、期限切れでない場合、そのオブジェクトは、既に説明されたようにデータ・ハンドラ（４５０）によって呼び出し元アプリケーションのローカル・キャッシュに転送され、そこでそのオブジェクトは記録され（４２５）、そのローカル・キャッシュからそのオブジェクトが要求元アプリケーションに送達される（４３５）。これは、ローカル・キャッシュ内の期限切れオブジェクトを置き換えるプロセスを終了する。要求されたオブジェクトの新しいコピーが集中キャッシュ内で直ちに利用可能である場合、大抵、そのオブジェクトは、別のローカル・キャッシュを使用する別のアプリケーションが同じオブジェクトを既に必要とし、したがってその同じオブジェクトが前にＣＤＳにおいて再構築されたという事実から生じる。
【００３１】
しかし、そうではない場合、すなわち、要求されたオブジェクトが集中キャッシュ内でやはり期限切れである（４５５）場合、そのオブジェクトが再構築されなければならない。これは、無効化ハンドラ（４６０）機能を通じて期限切れオブジェクトの無効化（４７０）も要求するデータ・ハンドラによってデータベース（４６５）から図３で既に説明されたように実行される。したがって、期限切れオブジェクトは、図３で説明されたように、最終的には新しく構築されたオブジェクト（４７５）によって集中キャッシュ内で置き換えられ、全ての中間層のＣＤＳにやはり複製される。ここで、図３で述べられた負荷分散機能によって実行された選択の結果として、期限切れオブジェクト（４５５）が要求されたＣＤＳが主ＣＤＳではなくバックアップＣＤＳである場合、再構築は実際にはバックアップ・データ・ハンドラによって実行されないことに留意することが重要である。むしろ、オブジェクト無効化要求が主ＣＤＳの無効化ハンドラに転送され（４８０）、その結果、再構築を代わりに実行し、元の要求を受信したＣＤＳを含む全ての中間層のＣＤＳが最終的に更新されるように全てのバックアップＣＤＳに再構築されたオブジェクトを複製するのは主ＣＤＳである。
【００３２】
再構築は非常に長いプロセスである可能性があるので、最初に要求されたが期限切れであったオブジェクト（４５５）が、それにも関わらず、要求元アプリケーション（４００）が動かなくならないように要求元ローカル・キャッシュ（４８５）に送達される。しかし、送達の前にオブジェクトのＴＴＬが非常に小さい値に設定される。したがって、再構築が上述のように進行中である間、オブジェクトは（１つまたは複数の）現在の要求のためにまだ利用可能である。したがって、短いＴＴＬが終わった後に受信されるさらなる要求は、新しい再構築されたオブジェクトを使用することになる。この動作のやり方は、航空運賃の新しい組を大規模なネットワーク上に展開するにはどうしても多くの時間がかかるので航空運賃が定期的に、しかし柔軟な更新時間を用いて更新される本発明によって考慮される種類のアプリケーションと相性がよい。
【００３３】
図５は、データ要素がデータベース（５００）内で修正されるときのキャッシュ内のオブジェクトの無効化を示す。この無効化は、データベースがそれらのデータベースのユーザ（５０５）、すなわち、それらのデータベースの内容を更新および管理することを担当しているユーザによって更新される度に行われる。データベース・サーバは、オブジェクトを構築するために使用されたどのデータ要素が変わったのかを検出することができる。次に、影響を受けるオブジェクトの組が、それらのオブジェクトを無効化させ、場合によっては集中キャッシュにおいて再構築させるために判定される。この目的のために、データベースは、オブジェクト無効化命令を全てのＣＤＳ、すなわち主ＣＤＳおよび（１つまたは複数の）バックアップＣＤＳにブロードキャストし（５１０）、これらのＣＤＳにおいて全ての影響を受けるオブジェクトが無効化される（５１５、５２５）。
【００３４】
主ＣＤＳ（５２０）上で、無効化ハンドラ（５３０）は、無効化されたオブジェクトが削除されなければならないのか、それとも再構築されなければならないのかを最初に判断する必要がある。実際、集中キャッシュ内にまだ存在するオブジェクトは再構築されるには及ばない可能性がある。例えば、そのオブジェクトが長時間使用されなかったか、またはほとんど使用されないか、または頻繁に無効化される場合、無効化ハンドラは、無駄にキャッシュ・メモリを占有せず、再構築のために必要な処理性能および通信の帯域幅を節約するために単にそのオブジェクトを削除することを決定することができる。決定は既定の設定に従ってなされる。無効化ハンドラの振る舞いは、ＣＤＳの管理者によって定義および設定される。
【００３５】
さらに、オブジェクトを削除する決定がなされる場合、対応するキャッシュ・メモリ空間が開放される。しかし、無効化ハンドラがオブジェクトが再構築されなければならないと判断する場合、この再構築が、図３で既に説明されたのと同様のやり方でデータベースから行われる。再構築される（５３５）と、オブジェクトは全てのＣＤＳに複製され（５４０）、その結果、それらのＣＤＳが同期され、新しいコピーが全ての集中キャッシュから利用可能になる（５４５）。
【００３６】
オブジェクトの削除または再構築のいずれが実行されるにしても、フロント層のサーバのソフトウェア・アプリケーション（５５５）が古いオブジェクト（５６０）を使用することを防止するために主ＣＤＳの無効化ハンドラがオブジェクトの無効化を全てのサテライト・サーバ（５５０）に伝達する。無効化された、したがってローカル・キャッシュ内でもはや利用可能でないオブジェクトをソフトウェア・アプリケーションが再び必要とするとき、ＣＤＳからのオブジェクトのフェッチと、場合によってはそのオブジェクトの再構築とが図３で既に説明されたように行われる。
【００３７】
また、オブジェクトの削除または再構築が完了すると、無効化が主ＣＤＳから（１つまたは複数の）バックアップＣＤＳに通知される（５７０）。この通知は、次の図において検討されるように無効化ハンドラによって使用される進行中テーブルの管理を処理するために行われる。
【００３８】
図６は、無効化されたオブジェクトの再構築をさらに検討する。
【００３９】
図５で説明されたようにこの再構築が行われなければならないとき、オブジェクト無効化要求を受信すると更新される進行中テーブル（６００）がＣＤＳ内に存在する。進行中の動作、すなわち無効化されたオブジェクトの再構築（６０５）が、主ＣＤＳのテーブルにロギングされ（６１０）、バックアップの進行中テーブルにも転送される（６２５）。また、上述のように、新しいオブジェクトが再構築されている間、無効化された現在のオブジェクトがまだ使用可能であるように、その無効化された現在のオブジェクトのＴＴＬまたは有効期限が小さな値に変更される。
【００４０】
この動作の正常な完了は、オブジェクトが正常に再構築され、全ての検証およびチェックに合格する（６４０）ことである。その場合、そのオブジェクトは既に検討されたようにバックアップＣＤＳに単に転送され（６１５）、その結果、そのオブジェクトは全ての集中キャッシュ内で利用可能になる。同時に、進行中の動作のログが主進行中テーブルから、およびさらに再構築されたオブジェクトを受信する（６１５）バックアップＣＤＳの進行中テーブル（６２０）から消去される。
【００４１】
しかし、場合によっては、これらの動作は長期的なＣＤＳの良好な動作に影響を与えることなしに正常に終了しない可能性がある。
【００４２】
考慮すべき第１の状況は、例えば、必要なデータ要素がデータベースから全て正しく転送されなかった（６３０）ために主ＣＤＳ内のオブジェクトが完全に再構築されることができないときである。その再構築動作の開始が進行中テーブル（５００）にロギングされている再構築動作が再試行されなければならない。したがって、中断している動作が、進行中テーブルを監視し、周期的に調べるスカベンジャ・プロセス（６３５）によって検出される。当然、進行中テーブルにロギングされた中断している動作に関して無効化ハンドラによって試みられる再試行の回数に対する制限が存在する。通常の条件下では、再試行のうちの１回は成功し、動作が上で説明されたように正常に再開する。
【００４３】
考慮すべき第２の状況は、再構築された（６１０）ばかりのオブジェクトが任意の数のバックアップＣＤＳに正常に転送されないときである。これは、バックアップＣＤＳも全て進行中テーブル（６２０）を持っているので主ＣＤＳにおけると同様のやり方で検出される。したがって、バックアップ・スカベンジャ・プロセスが、データベースからのオブジェクト無効化のブロードキャストの結果としてロギングされた中断している動作を検出する。主ＣＤＳが無効化されたオブジェクトを再構築することを期待するバックアップＣＤＳは、通常はいかなるオブジェクトの再構築も受け持たない。しかし、これは、スカベンジャが問題を報告するときにバックアップの無効化ハンドラ（６５０）によって例外的に開始されることができる。この状況に陥ったとき、結局、バックアップの無効化ハンドラが、その自身のキャッシュに関する無効化されたオブジェクトを再構築し（６５５）、一時的に主ＣＤＳとして振る舞う。これは、データベースからの必要なデータ要素の（バックアップＣＤＳへの）再転送を必要とする。その後、進行中テーブルの中断しているアイテムが消去されることができ、影響を受けるバックアップＣＤＳに関して動作が正常に再開することができる。
【００４４】
図７は、本発明の任意的な特徴を簡潔に示す。
【００４５】
キャッシュはそのキャッシュが存在する中央サーバの利用可能なアクティブ・メモリの外に構築されるのでキャッシュは必ず有限のサイズを有する。したがって、キャッシュが一杯になり、新しい要求されたオブジェクトを構築するために十分なメモリが残っていないことが起こりうる。その場合、キャッシュを用いた通常のやり方は、新しいオブジェクトのための空きを作るために最長時間未使用（ＬＲＵ）オブジェクトを削除することである。その他の置換アルゴリズムも適用され得る。どのアルゴリズムが使用されるにしても、最近使用されていない削除されるべき選択されたオブジェクトはまだ有効である可能性がある、すなわち、そのオブジェクトは期限切れではない。既に指摘されたように、本発明によるオブジェクトは、構築されるためにサーバの中央演算処理装置（ＣＰＵ）からのかなりの処理性能を必要とし、バックグラウンドのデータベース（７００）に対する複数のアクセスをさらに必要とする複雑なオブジェクトである。したがって、オブジェクトの再構築はコストがかかり、オブジェクトがキャッシュから削除されるときに期限切れでない場合、破棄することは回避されるべきである。
【００４６】
集中キャッシュが主ＣＤＳ（７２０）またはバックアップＣＤＳのうちの任意のもの（７３０）のいずれかにおいて一杯であり（７６０）、例えばＬＲＵオブジェクトが削除されるように選択された（７７０）とき、そのオブジェクトが期限切れでない（７９２）ならば、この後者は破棄される（７８０）代わりに、サーバから容易にアクセスされることができる２次記憶（７４０、７５０）に記憶される（７７５）ことができる。しかし、オブジェクトが期限切れである（７９４）場合、そのオブジェクトは破棄されなければならない。概して、２次記憶は、サーバに取り付けられたハードディスクからの専用の記憶空間である。したがって、期限切れでないオブジェクトの再構築が回避されることができる。そのようにするために、ＣＤＳは２次記憶に記憶されたオブジェクトを追跡する。アプリケーションがそれらのオブジェクトのうちの１つを再び必要とするとき、そのオブジェクトは再構築される代わりに対応する２次記憶から取り出される。再構築される前に２次記憶において初めに検索される要求されたオブジェクトのための空きを作るために、検索が成功しない場合、またはオブジェクトが２次記憶に記憶されてからそのオブジェクトが期限切れになった場合、同じメカニズムが適用される、すなわちＬＲＵオブジェクトがキャッシュから削除される。
【図面の簡単な説明】
【００４７】
【図１】従来技術、すなわち２層ソフトウェア・アーキテクチャを多層ソフトウェア・アーキテクチャと対比して検討する図である。
【図２】本発明が最もよく当てはまる多層ソフトウェア・アーキテクチャの全体を示す図である。
【図３】アプリケーション・プログラムによるエンドユーザの要求の処理の結果生じるオブジェクトのフェッチ、および中央サーバにおけるオブジェクトの構築の様々な場合を示す図である。
【図４】ローカル・キャッシュおよび集中キャッシュ内のオブジェクトの経時変化を検討する図である。
【図５】データ要素がデータベース内で修正されるときのキャッシュ内のオブジェクトの無効化を示す図である。
【図６】無効化されたオブジェクトの再構築を検討する図である。
【図７】集中キャッシュから削除されなければならない期限切れでないオブジェクトの２次記憶への記憶を示す図である。
【図１】
2009510578.tif 000003
【図２】
2009510578.tif 000004
【図３】
2009510578.tif 000005
【図４】
2009510578.tif 000006
【図５】
2009510578.tif 000007
【図６】
2009510578.tif 000008
【図７】
2009510578.tif 000009
【国際調査報告】
2009510578.tif 000010
2009510578.tif 000011