JP2000509531A - カスタムＷｅｂサイトを動的に作成し管理するためのシステム - Google Patents

Abstract

(57)【要約】 本発明は、カスタムＷｅｂサイトを作成し管理するシステム、具体的にはＷｅｂクライアント（２００）からＷｅｂサーバ（２０１）への動的Ｗｅｂページ生成要求を管理するためのシステムを教示する。Ｗｅｂサーバ実行可能プログラム（２０１（Ｅ））が要求を処理する代わりに、インターセプタ（４００）が要求をインターセプトし、これをディスパッチャ（４０４）にルーティングする。ディスパッチャ（４０２）は、インターセプトされた要求を受け取り、要求を検査し、要求を複数のページ・サーバ（４０４）の１つにディスパッチする。指定されたページ・サーバ（４０４）は要求を処理し、Ｗｅｂサーバ実行可能プログラム（２０１（Ｅ））は同時に他のＷｅｂクライアント要求を処理する。

Description

【発明の詳細な説明】 カスタムＷｅｂサイトを動的に作成し管理するためのシステム発明の分野 本発明は、インターネット技術の分野に関する。詳細には、本発明は、カスタ ム・ワールド・ワイド・ウェブ・サイトの作成および管理に関する。関連技術の説明 ワールド・ワイド・ウェブ（Ｗｅｂ）は、インタラクティブなドキュメントま たはＷｅｂページを介してユーザにインターネット上の情報へのアクセスを提供 するインターネット上のすべてのコンピュータを表す。これらのＷｅｂページは 、グラフィックス、音声、ビデオ、およびテキストの任意の組合せを非線形非連 続方式で接続するために使用されるハイパーテキスト・リンクを含んでいる。ハ イパーテキスト・リンクは、ハイパーテキスト・マークアップ言語（ＨＴＭＬ） と呼ばれる特殊なソフトウェア言語を使用して作成される。 Ｗｅｂページは、作成された後、Ｗｅｂ上、ＷｅｂサーバまたはＷｅｂサイト 上に常駐する。Ｗｅｂサイトは多数のＷｅｂページを含むことがある。Ｗｅｂブ ラウザを稼働するＷｅｂクライアント・マシンは、ハイパーテキスト転送プロト コル（ＨＴＴＰ）と呼ばれる通信プロトコルを介してＷｅｂサイトにあるこれら のＷｅｂページにアクセスすることができる。Ｗｅｂブラウザは、ワールド・ワ イド・ウェブ・クライアント上で稼働し、簡単なユーザ・インタフェースを介し てＷｅｂサイトへのアクセスを可能にするソフトウェア・インタフェースである 。Ｗｅｂブラウザにより、Ｗｅｂクライアントは、Ｕｎｉｆｏｒｍ Ｒｅｓｏｕ ｒｃｅ Ｌｏｃａｔｏｒ（ＵＲＬ）を指定することによってＷｅｂサイトに特定 のＷｅｂページを要求することができる。ＵＲＬは、ＷｅｂページおよびＷｅｂ 上のその場所を識別するＷｅｂアドレスである。適切なＷｅｂサイトがＵＲＬを 受け取ったとき、要求されたＵＲＬに対応するＷｅｂページの場所を探し当て、 必要な場合、ＨＴＭＬ出力を生成する。次いでＨＴＭＬ出力は、ＨＴＴＰを介し て クライアントの画面上でフォーマットするためにクライアントに送られる。 ＷｅｂページおよびＷｅｂサイトは作成するのが極めて簡単であるが、インタ ーネット上のＷｅｂサイトの急増により多くの問題が浮き彫りになっている。Ｗ ｅｂページ設計者がＷｅｂページの内容を変更する範囲および能力はウェブペー ジの静的な特性によって制限されていた。Ｗｅｂページは、作成された後、手動 で変更されるまで静的なままである。このことは、Ｗｅｂサイト・マネージャが それらのＷｅｂサイトを効果的に管理する能力を限定していた。 共通ゲートウェイ・インタフェース（ＣＧＩ）規格は、Ｗｅｂページに動的な コンテンツを掲載できるようにするという問題を解決するために開発された。Ｃ ＧＩ「呼」または手順は、アプリケーションが動的なコンテンツを使用して動的 に作成されたＨＴＭＬ出力を生成できるようにする。こうしたＣＧＩアプリケー ションは、作成された後、「新しい」または動的なデータを収集するために変更 する必要はない。代わりに、Ｗｅｂページが呼び出されたとき、ＣＧＩ「呼」ま たは手順を使用し、必要なデータを動的に収集し、Ｗｅｂページを生成する。 ＣＧＩアプリケーションはまた、Ｗｅｂサイト管理者がＷｅｂサイトを管理す る能力を高めた。管理者はもはや静的なＷｅｂページを絶えず更新する必要はな い。多くのベンダが動的なＷｅｂページの発行に対処するためにＣＧＩベースの 開発用ツールを開発している。たとえば、Ｓｐｉｄｅｒ^TMやＢｌｕｅｓｔｏｎｅ^TM などの会社では、それぞれＣＧＩベースのＷｅｂページ開発用ツールを制作し ている。他の会社Ｈａｈｔ Ｓｏｆｔｗａｒｅ^TMでは、ＣＧＩスクリプト言語の 代わりに、ＢＡＳＩＣのようなスクリプト言語を使用するＷｅｂページ生成ツー ルを開発した。 ただし、ＣＧＩアプリケーションを生成するツールは、Ｗｅｂサイトの多数の Ｗｅｂページおよび要求を管理する問題を解決していない。たとえば、単一の会 社が何百ものＷｅｂページをそのＷｅｂサイトで保持していることもある。また 、現在のＷｅｂサーバ・アーキテクチャでは、Ｗｅｂサーバが効果的にＷｅｂペ ージを管理し、Ｗｅｂクライアントの要求を処理することができない。したがっ て、これらの何百ものＷｅｂページを首尾一貫した形で管理し、Ｗｅｂページへ のアクセスの要求をすべて処理することは困難な作業である。既存の開発ツール は、 動的なＷｅｂページの生成を容易にする機能が制限されており、Ｗｅｂ要求また はＷｅｂサイトを管理する問題に対処していない。発明の概要 したがって、本発明の目的は、カスタムＷｅｂサイトを作成し、管理するため の方法および装置を提供することである。具体的には、本発明は、動的なＷｅｂ ページ生成要求を管理するための方法および装置を請求する。 一実施態様では、本発明は、Ｗｅｂサーバへの動的なＷｅｂページ生成要求を 管理するためのコンピュータ実施方法であって、Ｗｅｂサーバからの要求をペー ジ・サーバにルーティングし、ページ・サーバが要求を受け取り、他の要求を処 理するためＷｅｂサーバを解放するステップと、要求を処理するステップであっ て、前記Ｗｅｂサーバが他の要求を処理するときに、前記処理が前記ページ・サ ーバによってＷｅｂサーバと同時に実施されるステップと、要求に応答してＷｅ ｂページを動的に生成するステップであって、Ｗｅｂページが１つまたは複数の データ・ソースから動的に取り出されたデータを含むステップを含むコンピュー タ実施方法。他の実施態様は、１つまたは複数のソースへの接続キャッシュ、各 ページ・サーバのページ・キャッシュ、およびＷｅｂページを設定するためのカ スタムＨＴＭＬ拡張テンプレートも含む。 本発明のその他の目的、特徴、および利点は、添付図面および詳細な説明を読 めば明らかになろう。図面の簡単な説明 第１図は、本発明が動作する通常のコンピュータ・システムを示す図である。 第２図は、Ｗｅｂサーバ環境における通常の従来技術を示す図である。 第３図は、通常の従来技術によるＷｅｂサーバ環境を示す流れ図である。 第４図は、本発明の一実施形態を示す図である。 第５図は、本発明の一実施形態に従ったＷｅｂブラウザ要求の処理を示す流れ 図である。好ましい実施形態の詳細な説明 本発明は、カスタムＷｅｂサイトを作成し管理するための方法および装置に関 する。以下の詳細な説明において、本発明を深く理解できるように多くの具体的 な詳細が示される。しかし、これらの具体的な詳細は本発明の実践に使用される 必要がないことは、当業者には明らかであろう。その他の例において、周知の構 造、インタフェースおよびプロセスについては、本発明を不必要にあいまいなも のにしないため、詳細には示されていない。 第１図は、本発明が動作する通常のコンピュータ・システム１００を示してい る。本発明の好ましい実施形態は、ニューヨーク市、ＡｒｍｏｎｋのＢＭ Ｃｏ ｒｐｏｒａｔｉｏｎの製造によるＩＢＭ^TMパーソナル・コンピュータ上で実施さ れる。代替実施形態は、ニューヨーク市、ＡｒｍｏｎｋのＩＢＭ Ｃｏｒｐｏｒ ａｔｉｏｎの製造によるＲＳ／６０００^TMワークステーション上で実施されるこ ともある。他のコンピュータ・システム・アーキテクチャも採用できることは、 当業者には明らかであろう。 一般に、第１図に示されているようなコンピュータ・システムは、情報を伝達 するためのバス１０１、バス１０１に接続され情報を処理するためのプロセッサ １０２、バス１０１に接続されプロセッサ１０２の情報および命令を格納するた めのメイン・メモリ１０３、バス１０１に接続されプロセッサ１０２の静的情報 と命令を格納するための読み取り専用メモリ１０４、バス１０１に接続されコン ピュータ・ユーザに情報を表示するための表示装置１０５、バス１０１に接続さ れプロセッサ１０２に情報とコマンド選択を伝達するための入力装置１０６、お よびバス１０１に接続され情報と命令を格納するための、磁気ディスクおよび関 連付けられたディスク・ドライブのような大容量記憶装置１０７を含んでいる。 デジタル情報を含むデータ記憶媒体１０８は、大容量記憶装置１０７と共に動作 するように構成され、プロセッサ１０２がバス１０１を介してデータ記憶媒体上 のデジタル情報にアクセスできるようになっている。 プロセッサ１０２は、各種の汎用プロセッサ、もしくはＩｎｔｅｌ^TMＣｏｒｐ ｏｒａｔｉｏｎの製造によるＰｅｎｔｉｕｍ^TMマイクロプロセッサまたはＩＢＭ Ｃｏｒｐｏｒａｔｉｏｎの製造によるＲＳ／６０００^TMプロセッサのようなマ イクロプロセッサのいずれであってもよい。ただし特定のコンピュータ・システ ムにおいて、その他の多様なプロセッサも使用できることは、当業者には明らか であろう。表示装置１０５は、液晶装置、陰極線管、または他の適切な表示装置 でもよい。大容量記憶装置１０７は、ハード・ディスク、フロッピー・ディスク 、ＣＤ−ＲＯＭ、磁気テープ、もしくは他の磁気または光データ記憶媒体上に格 納された情報の読取りと書込みを行うための、従来のハード・ディスク・ドライ ブ、フロッピー・ディスク・ドライブ、ＣＤ−ＲＯＭドライブ、または他の磁気 または光データ記憶装置である。データ記憶媒体１０８は、ハード・ディスク、 フロッピー・ディスク、ＣＤ−ＲＯＭ、磁気テープ、もしくは他の磁気または光 データ記憶媒体である。 一般に、プロセッサ１０２は、大容量記憶装置１０７を使用してデータ記憶媒 体１０８から処理命令およびデータを取り出し、実行のためにこの情報をランダ ム・アクセス・メモリ１０３にダウンロードする。次に、プロセッサ１０２は、 ランダム・アクセス・メモリ１０３または読み取り専用メモリ１０４からの命令 ストリームを実行する。入力装置１０６におけるコマンド選択および情報入力は 、プロセッサ１０２によって実行される命令の流れを方向づけるために使用され る。同等の入力装置１０６は、従来のマウスまたはトラックボール装置などのポ インティング装置であってもよい。この処理実行のの結果は、表示装置１０５に 表示される。 本発明の好ましい実施形態は、ソフトウェア・モジュールとして実装され、こ れは従来の方法でコンピュータ・システム１００のようなコンピュータ・システ ム上で実行されることもある。周知の技法を使用して、好ましい実施形態のアプ リケーション・ソフトウェアは、データ記憶媒体１０８上に格納され、続いてコ ンピュータ・システム１００内でロードされ実行される。起動されると、好まし い実施形態のソフトウェアは、以下に述べる方法で動作を行う。 第２図は、通常の従来技術のＷｅｂサーバ環境を示している。Ｗｅｂクライア ント２００は、Ｗｅｂサーバ２０１またはＷｅｂサーバ２０２にＵＲＬ要求を行 うことができる。Ｗｅｂサーバ２０１および２０２は、Ｗｅｂクライアント要求 の処理を行うＷｅｂサーバ実行可能プログラム２０１（Ｅ）および２０２（Ｅ） をそれぞれ含んでいる。各Ｗｅｂサーバは、複数のＷｅｂページ２０１（Ｅ）− （ｎ）および２０２（１）−（ｎ）を備えている。Ｗｅｂクライアント２００に よって指定されるＵＲＬにより、要求は、たとえばＷｅｂサーバ実行可能プログ ラム２０１（Ｅ）によってＷｅｂページ２０１（１）、またはＷｅｂサーバ実行 可能プログラム２−２（Ｅ）からＷｅｂページ２０２（１）のいずれかにルーテ ィングされる。Ｗｅｂクライアント２００は、他のＷｅｂページを取り出すため にＵＲＬ要求を続けて行うことができる。Ｗｅｂクライアント２００はまた、各 Ｗｅｂページ内のハイパーリンクを使用して、他のＷｅｂページまたは同じＷｅ ｂページ内の他の場所に「ジャンプ」することもできる。 第３図は、この従来技術のＷｅｂサーバ環境を示す流れ図である。処理ブロッ ク３００において、ＷｅｂクライアントはＵＲＬ要求を行う。このＵＲＬ要求は 、処理ブロック３０２において、要求をルーティングする適切なＷｅｂサーバを 決定するためにＷｅｂブラウザに検査される。次に処理ブロック３０４において 、要求はＷｅｂブラウザから適切なＷｅｂサーバに転送され、処理ブロック３０ ６において、Ｗｅｂサーバ実行可能プログラムがＵＲＬを検査し、これがＨＴＭ ＬドキュメントまたはＣＧＩアプリケーションのいずれであるかを決定する。要 求がＨＴＭＬドキュメント３０８に対するものであれば、Ｗｅｂサーバ実行可能 プログラムはドキュメントを処理ブロック３１０に配置する。次に処理ブロック ３１２において、ドキュメントはフォーマッティングおよび表示のために要求元 のＷｅｂブラウザを通じて転送される。 ただし、ＵＲＬ要求がＣＧＩアプリケーション３１４に対するものであれば、 Ｗｅｂサーバ実行可能プログラムはＣＧＩアプリケーションを処理ブロック３１ ６に配置する。次に処理ブロック３１８において、ＣＧＩアプリケーションは、 実行してＨＴＭＬ出力を出力し、最後に処理ブロック３２０において、ＨＴＭＬ 出力はフォーマッティングおよび表示のために要求元のＷｅｂブラウザに転送さ れる。 しかし、この従来技術のＷｅｂサーバ環境では、Ｗｅｂ要求またはＷｅｂサイ トを管理するための機構を何ら提供しない。Ｗｅｂサイトの成長に伴い、またＷ ｅｂクライアントおよび要求の増加に伴って、Ｗｅｂサイトの管理は危急の必要 性を帯びてくる。 たとえば、大規模なＷｅｂサイトは１日に何千という要求または「ヒット」を 受けることがある。現在のＷｅｂサーバは、こうした要求をそれぞれ、単一のマ シン、またはＷｅｂサーバマシンで処理する。これらのマシンがたとえ、トラン ザクションを独立した「スレッド」によって処理できる「マルチスレッド」オペ レーティング・システムを稼働しているとしても、すべてのスレッドは単一のマ シン上にあってプロセッサを共用している。そのように、Ｗｅｂ実行可能プログ ラム・スレッドは、要求を処理スレッドに渡すことができるが、両スレッドは依 然としてＷｅｂサーバ・マシン上のプロセッサに処理される必要がある。非常に 多くの要求が、単一マシン上の複数スレッドによって同時に処理される場合には 、Ｗｅｂサーバは処理速度が大幅に落ち、極めて非効率的になる可能性がある。 本発明では、区分アーキテクチャの利用によりカスタムＷｅｂサイトおよびサー バの作成と管理を容易にすることで、この必要性に対処している。 第４図は、本発明の一実施形態を示している。Ｗｅｂクライアント２００は、 処理されるＵＲＬ要求を決定された適切なルーティングに発行する。この実施形 態においては、要求はＷｅｂサーバ２０１にルーティングされる。ただし、Ｗｅ ｂサーバ実行可能プログラム２０１（Ｅ）がＵＲＬ要求を処理するのではなく、 インターセプタ４００が要求をインターセプトし、これをディスパッチャ４０２ にルーティングする。一実施形態においては、インターセプタ４００は、Ｗｅｂ サーバ２０１の拡張機能としてＷｅｂサーバ・マシン上に常駐する。この実施形 態は、Ｎｅｔｓｃａｐｅ社のＮｅｔｓｉｔｅ^TMのように、このような拡張機能を サポートするＷｅｂサーバに適している。イリノイ大学のＮａｔｉｏｎａｌ Ｃ ｅｎｔｅｒ ｆｏｒ Ｓｕｐｅｒｃｏｍｐｕｔｉｎｇ Ａｐｐｌｉｃａｔｉｏｎ ｓのＮＣＳＡ^TMのようなパブリック・ドメインＷｅｂサーバの多くは、このタイ プの拡張機能をサポートしていない。従って代替実施形態において、インターセ プタ４００は、「中間プログラム」を介してＷｅｂサーバ２０１に接続される独 立したモジュールである。この中間プログラムは、インターセプタ４００をＷｅ ｂサーバ２０１に接続する簡単なＣＧＩアプリケーション・プログラムでもよい 。同じ機能を行う代替中間プログラムも、実施することができる。 本発明の一実施形態では、ディスパッチャ４０２は、Ｗｅｂサーバ２０１とは 別のマシン上に常駐する。この実施形態では、すべての処理が単一マシン上のプ ロセッサによって行われる従来技術のＷｅｂサーバにおける、先に述べた制限事 項を克服する。要求を、Ｗｅｂサーバ実行可能プログラム２０１（Ｅ）とは別の マシン上に常駐するディスパッチャ４０２にルーティングすることにより、要求 はＷｅｂサーバ実行可能プログラム２０１（Ｅ）とは別のプロセッサによって処 理される。従って、Ｗｅｂサーバ実行可能プログラム２０１（Ｅ）は、Ｗｅｂサ ーバ２０１上のクライアント要求にも引き続き自由にサービスを行い、しかも要 求はディスパッチャ４０２が常駐するマシンにおいて「オフライン」で処理され る。 しかし、ディスパッチャ４０２は、Ｗｅｂサーバとして同一マシン上にも常駐 することができる。Ｗｅｂサイト管理者の裁量で、Ｗｅｂサイトのサイズ、Ｗｅ ｂページの数、Ｗｅｂサイトのヒット数などの、特定のＷｅｂサイトに関係する 各種の要因を考慮しながら、ディスパッチャ４０２をＷｅｂサーバ２０１として 同一マシン上に構成することもできる。この実施形態は、前述の利点、すなわち Ｗｅｂサーバ・マシンからＷｅｂ要求の処理をオフロードするという利点を享受 していないことになるが、この実施形態は小規模なＷｅｂサイトが成長できる柔 軟性を与えてくれる。たとえば、小規模Ｗｅｂサイトの管理者は、当初ディスパ ッチャ４０２およびＷｅｂサーバ２０１の両方に単一マシンを使用し、次いでＷ ｅｂサイトの成長に応じてディスパッチャ４０２を別のマシン上にオフロードす ることができる。従ってＷｅｂサイトは、サイトにＷｅｂサーバとディスパッチ ャとして構成された別個のマシンがあるかどうかにかかわらず、本発明の他の特 徴を利用することができる。 ディスパッチャ４０２は、インターセプトされた要求を受け取り、その要求を 複数のページ・サーバ４０４（１）−（ｎ）の１つにディスパッチする。たとえ ばページ・サーバ４０４（１）は、ディスパッチされた要求を受け取ると、要求 を処理して、データ・ソース４０６、データ・ソース４０８、データ・ソース４ １０のような適切なデータ・ソースからデータを取り出す。データ・ソースは、 本発明のアプリケーションにおいて使用される場合、データベース、スプレッド シート、ファイルおよび他の種類のデータ・リポジトリを含んでいる。ページ・ サーバ４０４（１）は、複数のデータ・ソースからデータを取り出し、これらの 複数データ・ソースからのデータを単一ウェブページに組み込むことができる。 一実施形態では、各ページ・サーバ４０４（１）−（ｎ）は、ネットワーク上 の別個のマシン上に常駐し、要求の処理を分散している。ディスパッチャ４０２ は、ネットワーク上の各ページ・サーバに関する各種の情報を保持し、この情報 に基づいて要求をディスパッチする。たとえば、ディスパッチャ４０２は、所定 のページ・サーバがアクセスできるデータ・ソースに関する動的な情報を保持し ている。このように、ディスパッチャ４０２は、特定の要求を検査し、どのペー ジ・サーバがＵＲＬ要求にサービスを行うことができるかを決定する。次にディ スパッチャ４０２は、適切なページ・サーバに要求を渡す。 たとえば、ＵＲＬ要求がデータ・ソースからの財務データを求める場合、ディ スパッチャ４０２はまず情報リストを調べる。ディスパッチャ４０２は、たとえ ばページ・サーバ４０３（３）がデータ・ソース４０８の要件データにアクセス できると決定する。したがって、ディスパッチャ４０２は、ＵＲＬ要求をページ ・サーバ４０４（３）にルーティングする。この「接続キャッシング」機能につ いては、「パフォーマンス」節でさらに詳細に説明される。 代わりにディスパッチャ４０２は、特定のページ・サーバがすでに、必要なデ ータをページ・サーバのページ・キャッシュ（「パフォーマンスの節でさらに詳 細に説明される）に入れているかどうかを決定する能力も備えている。従ってデ ィスパッチャ４０２は、ページ・サーバ４０４（１）および４０４（２）が共に データ・ソース４０８に記録されており、ページ・サーバ４０４（２）が財務情 報をすでにページ・サーバ４０４（２）のページ・キャッシュに入れていると決 定する。この場合、ディスパッチャ４０２は、ＵＲＬ要求をページ・サーバ４０ ４（２）にルーティングして、要求をさらに効率的に処理する。 最後に、ディスパッチャ４０２は、いくつかのまたはすべてのページ・サーバ ４０４（１）−（ｎ）がデータ・ソース４０８にログされていると決定する。こ のシナリオでは、ディスパッチャ４０２は、各ページ・サーバがサービスを行っ ている複数の要求を調べ、最もすいているページ・サーバに要求をルーティング することができる。この「ロード・バランシング」機能は、ビジー状態のＷｅｂ サイトにおいてパフォーマンスを大幅に高めることができるが、これについては 以下の「スケーラビリティ」の節でさらに詳細に説明される。 たとえば、ページ・サーバ４０４（２）は、要求を受け取ると、要求を処理す る。ページ・サーバ４０４（２）が要求を処理している間に、Ｗｅｂサーバ実行 可能プログラム２０１（Ｅ）は同時に他のＷｅｂクライアント要求を処理するこ とができる。このように、この区分アーキテクチャでは、ページ・サーバ４０４ （２）およびＷｅｂサーバ実行可能プログラム２０１（Ｅ）が共に、異なる要求 を同時に処理できるようになり、Ｗｅｂサイトの効率を高めることができる。ペ ージ・サーバ４０４（２）は、Ｗｅｂクライアント要求に応じてＷｅｂページを 動的に生成し、動的Ｗｅｂページは、要求元Ｗｅｂクライアント２００に転送さ れるか、または後に取り出すことができるようＷｅｂサーバ２０１にアクセス可 能なマシン上に格納される。 また本発明の一実施形態はまたＨＴＭＬ拡張機能または「ｄｙｎａ」タグをＷ ｅｂページ設計者に提供する。このｄｙｎａタグは、Ｗｅｂページ設計者にカス タム化ＨＴＭＬ機能をもたらし、設計者が、取り出されたデータのソースと配置 を指定するカスタム化ＨＴＭＬテンプレートを構築できるようになっている。た とえば、一実施形態では、「ｄｙｎａｔｅｘｔ」ＨＴＭＬ拡張機能タグはデータ ・ソースおよび列名を指定し、記録するデータ・ソース、およびデータを取り出 す列名をＨＴＭＬテンプレートが識別できるようになっている。代替として、「 ｄｙｎａ−ａｎｃｈｏｒ」タグにより設計者はハイパーリンク・クエリーを構築 できるようになり、同時に「ｄｙｎａｂｌｏｃｋ」タグにより設計者はデータの ブロックを反復できるようになる。ページ・サーバは、これらのＨＴＭＬテンプ レートを使用して、動的なＷｅｂページを作成する。次に、上記のように、これ らの動的なＷｅｂページは要求元Ｗｅｂクライアント２００に転送されるか、ま たは後に取り出すことができるようＷｅｂサーバ２０１にアクセス可能なマシン 上に格納される。 本発明は、パフォーマンス、セキュリティ、拡張性およびスケーラビリティの 領域における利点を始めとして、従来技術のＷｅｂサーバに優る数多くの利点を 提供する。 パフォーマンス 本発明の一実施形態では、接続キャッシングおよびページ・キャッシングを利 用してパフォーマンスを向上させる。各ページ・サーバは、多数のデータ・ソー スへの接続のキャッシュを保持するように構成される。たとえば、第４図に示さ れるように、ページ・サーバ４０４（１）は、データ・ソース４０６、データ・ ソース４０８、またはデータ・ソース４１０からデータを取り出すことができる 。ページ・サーバ４０４（１）は、データ・ソース４０６、データ・ソース４０ ８、およびデータ・ソース４１０の各々への接続を含む接続キャッシュ４１２（ １）を保持することができるので、ページ・サーバからこれらのデータ・ソース への接続時間を除くことができる。 さらに、本発明の他の実施形態は、仕上がったＷｅｂページのキャッシングを サポートし、利用されるデータ・ソースのパフォーマンスを最適化している。第 ４図においてページ・キャッシュ４１４として示される、この「ページ・キャッ シング」機能により、Ｗｅｂサイト管理者は、繰り返しアクセスするＷｅｂペー ジをキャッシュに入れてデータ・ソースのパフォーマンスを最適化できるように なる。Ｗｅｂページがいったんキャッシュに入れられると、その後の要求または 「ヒット」は、データ・ソースを再度アクセスするのではなく、キャッシュに入 れられたＷｅｂページを利用する。これにより、データ・ソースのパフォーマン スを大幅に向上させることができる。 セキュリティ 本発明により、Ｗｅｂサイトの管理者は、複数レベルのセキュリティを利用し てＷｅｂサイトを管理できるようになる。一実施形態では、ページ・サーバは、 Ｗｅｂサーバの提供するすべての標準暗号化およびサイト・セキュリティ機能を 利用できる。他の実施形態では、ページ・サーバが特定のデータ・ソースに対し て上記の接続キャッシュ４１２（１）−（ｎ）をバイパスし、ユーザがアクセス を試みる特定のデータ・ソースに対してユーザ提供のＩＤとパスワードの入力を 求めるように構成することができる。 さらに、本発明の他の実施形態では、データ・ソースのリアルタイム・アクセ スを要求することはない。上記のＷｅｂページ・キャッシング機能により、内部 情報システムから非インタラクティブなコンテンツを公開したいが、これらの内 部情報システムへのリアルタイムのインターネット・アクセス能力は望んでいな いというサイトのために、さらにセキュリティを追加できる。この例では、ペー ジ・サーバは、「複製およびステージング・エージェント」として動作し、Ｗｅ ｂページをリアルタイムではなくバッチで作成する。次にこれらの「複製」Ｗｅ ｂページは、後にアクセスできるように「ステージング」され、たとえ後にはペ ージ・サーバとディスパッチャが存在しなくても、このシナリオにおけるＷｅｂ ページへのアクセスは可能である。 他の実施形態では、ページ・サーバがＷｅｂライブラリを１度通過することが でき、従来の形態の別個に利用できるファイルにあるＷｅｂサイトをコンパイル する。Ｗｅｂライブラリは、関連するＷｅｂブックとＷｅｂページの集合である 。より具体的には、Ｗｅｂライブラリは、関連付けられたすべてのデータ・ソー ス情報を加えた、Ｗｅｂドキュメント・テンプレートの階層編成である。従って 、Ｗｅｂサイト全体に関する情報は、単一の物理ファイルに含まれるので、複数 のページ・サーバにわたりＷｅｂサイトを配置するという問題を簡略化すること になる。この実施形態におけるＷｅｂサイトの配置のプロセスは、本質的には単 一ファイルの単純コピーである。 拡張性 本発明の一実施形態では、Ｗｅｂサイト管理者にＯｂｊｅｃｔ Ｌｉｎｋｉｎ ｇ ａｎｄ Ｅｍｂｅｄｄｉｎｇ（ＯＬＥ）２．０拡張機能を提供し、ページ作 成プロセスを拡張している。これらのＯＬＥ２．０拡張機能では、Ｗｅｂ上で発 信された情報がユーザ提供の機能で処理できるようになる。ＯＬＥ２．０オート メーションの作成をサポートするＶｉｓｕａｌ Ｂａｓｉｃ、Ｖｉｓｕａｌ Ｃ ＋＋、またはＰｏｗｅｒＢｕｉｌｄｅｒなどの開発ツールを利用すると、Ｗｅｂ サイトの管理者は機能を追加し、前述のページ・サーバの動作を変更することが できる。この拡張性により、本発明の一実施形態は既存のテクノロジーに組み込 まれ、カスタムＷｅｂサーバを無限大に開発することができる。 たとえば、ＯＬＥ２．０拡張機能では、Ｗｅｂサイト管理者は既存のビジネス ・ルールをＯＬＥ２．０オートメーション・インタフェースにカプセル化して、 Ｗｅｂ上でアクセスするようにできる。ビジネス・ルールの一例には、分割払い または担保付き融資の支払いに係わるステップがある。たとえば、支払いには、 現在の残高、前回支払いの日付と利子を考慮に入れることもある。すでに多くの 組織では、クライアント・サーバ環境用Ｖｉｓｕａｌ Ｂａｓｉｃ、メインフレ ーム上のＣＩＣＳプログラムなど各種のアプリケーションを使用して、この種の ビジネス・ルールを実施している。こうしたアプリケーションがＯＬＥ２．０に 対応している場合には、ページ・サーバの「ｄｙｎａｏｂｊｅｃｔ」ＨＴＭＬ拡 張タグを使用してアプリケーションをＯＬＥ２．０オートメーション・インタフ ェースにカプセル化することができる。このように、ページ・サーバは拡張性が あり、既存のアプリケーションを新しいページ・サーバ機能とに組み込むことが できる。 スケーラビリティ 本発明の一実施形態では、「プラグ・アンド・プレイ」のスケーラビリティが かなえられる。第４図を参照すると、前述のように、ディスパッチャ４０２は、 ディスパッチャ４０２がサービスを行うように構成されているすべてのページ・ サーバに関する情報を保持する。従って、任意の数のページ・サーバを第４図に 示された構成に「差し込む」ことができ、ディスパッチャ４０２で情報が動的に 更新されるとページ・サーバは直ちに起動される。従って、Ｗｅｂサイト管理者 は、各ページ・サーバのオーバーヘッドを管理し、パフォーマンスを向上させる ために必要に応じて各ページ・サーバのロードを変更することができる。このよ うに、ページ・サーバはそれぞれ、マルチサーバ環境において他のページ・サー バと協働することになる。ディスパッチャ４０２は、各ページ・サーバ上のロー ドを調べ、各ページ・サーバの使用可能な資源に従って新しい要求をルーティン グすることができる。複数のページ・サーバにわたるこの「ロードバランシング 」 は、Ｗｅｂサイトのパフォーマンスを大幅に向上させることができる。 第５図は、本発明の一実施形態に従ったＷｅｂブラウザ要求の処理を示す流れ 図である。処理ブロック５００において、ＷｅｂブラウザはＵＲＬ要求をＷｅｂ サーバに送る。処理ブロック５０２において、ＷｅｂサーバはＵＲＬ要求を受け 取り、処理ブロック５０４においてインターセプタが要求の処理をインターセプ トする。処理ブロック５０６において、インターセプタはディスパッチャに接続 し、ＵＲＬ要求をディスパッチャに送る。処理ブロック５０８において、ディス パッチャは、どのページ・サーバが要求を処理できるかを決定する。処理ブロッ ク５１０において、ディスパッチャはまた、どのページ・サーバが最も要求の処 理量が少ないかも決定し、処理ブロック５１２において、ディスパッチャはＵＲ Ｌ要求を適切なページ・サーバに送る。処理ブロック５１４において、ページ・ サーバは要求を受け取り、ＨＴＭＬドキュメントを生成する。次に処理ブロック ５１６で、ページ・サーバはキャッシュされたＨＴＭＬドキュメントの名前を通 知してディスパッチャに応答する。処理ブロック５１８において、ディスパッチ ャはドキュメント名でインターセプタに応答し、処理ブロック５２０において、 インターセプタは要求されたＵＲＬを新しく生成されたＨＴＭＬドキュメントに 置き換える。次に処理ブロック５２２において、Ｗｅｂサーバは新しいＨＴＭＬ ドキュメントを要求元クライアントに送る。最後に処理ブロック５２４において 、Ｗｅｂブラウザはページ・サーバによって作成されたＨＴＭＬドキュメントを 受け取り、表示する。 以上、カスタムＷｅｂサイトを作成し、管理するための方法および装置が開示 された。本明細書に記載のこれらの特定の構成および方法は、本発明の原理を示 すものにすぎない。本発明の範囲から逸脱することなく本発明の形態および詳細 に多くの変更を加えることができることが当業者なら理解できよう。本発明は、 特定の好ましい実施形態に関して示されているが、そのように限定するものでは なく、本発明は添付の請求の範囲によってのみ限定される。

───────────────────────────────────────────────────── フロントページの続き (81)指定国 ＥＰ(ＡＴ，ＢＥ，ＣＨ，ＤＥ， ＤＫ，ＥＳ，ＦＩ，ＦＲ，ＧＢ，ＧＲ，ＩＥ，ＩＴ，Ｌ Ｕ，ＭＣ，ＮＬ，ＰＴ，ＳＥ)，ＯＡ(ＢＦ，ＢＪ，ＣＦ ，ＣＧ，ＣＩ，ＣＭ，ＧＡ，ＧＮ，ＭＬ，ＭＲ，ＮＥ， ＳＮ，ＴＤ，ＴＧ)，ＡＰ(ＧＨ，ＫＥ，ＬＳ，ＭＷ，Ｓ Ｄ，ＳＺ，ＵＧ)，ＥＡ(ＡＭ，ＡＺ，ＢＹ，ＫＧ，ＫＺ ，ＭＤ，ＲＵ，ＴＪ，ＴＭ)，ＡＬ，ＡＭ，ＡＴ，ＡＴ ，ＡＵ，ＡＺ，ＢＡ，ＢＢ，ＢＧ，ＢＲ，ＢＹ，ＣＡ， ＣＨ，ＣＮ，ＣＵ，ＣＺ，ＣＺ，ＤＥ，ＤＥ，ＤＫ，Ｄ Ｋ，ＥＥ，ＥＥ，ＥＳ，ＦＩ，ＦＩ，ＧＢ，ＧＥ，ＧＨ ，ＨＵ，ＩＬ，ＩＳ，ＪＰ，ＫＥ，ＫＧ，ＫＰ，ＫＲ， ＫＺ，ＬＣ，ＬＫ，ＬＲ，ＬＳ，ＬＴ，ＬＵ，ＬＶ，Ｍ Ｄ，ＭＧ，ＭＫ，ＭＮ，ＭＷ，ＭＸ，ＮＯ，ＮＺ，ＰＬ ，ＰＴ，ＲＯ，ＲＵ，ＳＤ，ＳＥ，ＳＧ，ＳＩ，ＳＫ， ＳＫ，ＴＪ，ＴＭ，ＴＲ，ＴＴ，ＵＡ，ＵＧ，ＵＳ，Ｕ Ｚ，ＶＮ，ＹＵ (72)発明者 ホーウェル，ロナルド・エル アメリカ合衆国・75030・テキサス州・ロ ーレット・ピイオー ボックス 1491

Claims (1)

1. 【特許請求の範囲】 １．Ｗｅｂサーバへの動的なＷｅｂページ生成要求を管理するためのコンピュ ータ実施方法であって、 前記Ｗｅｂサーバからの前記要求をページ・サーバにルーティングするステッ プであって、ページ・サーバが前記要求を受け取り、他の要求を処理するために 前記Ｗｅｂサーバを解放する、ステップと、 前記要求を処理するステップであって、前記Ｗｅｂサーバが前記他の要求を処 理するときに、前記処理が前記ページ・サーバによって前記Ｗｅｂサーバと同時 に実施されるステップと、 前記要求に応答してＷｅｂページを動的に生成するステップであって、前記Ｗ ｅｂページが１つまたは複数のデータ・ソースから動的に取り出されたデータを 含むステップと を含むコンピュータ実施方法。 ２．前記要求をルーティングする前記ステップが、 前記要求を前記Ｗｅｂサーバでインターセプトするステップと、 前記Ｗｅｂサーバからの前記要求をディスパッチャにルーティングするステッ プと、 前記要求を前記ページ・サーバにディスパッチするステップとを含む請求項１ に記載のコンピュータ実施方法。 ３．前記要求を処理する前記ステップが、前記データをそこから取り出すべき 前記１つまたは複数のデータ・ソースを識別するステップを含む請求項２に記載 のコンピュータ実施方法。 ４．前記Ｗｅｂページを動的に生成する前記ステップが、前記１つまたは複数 のデータ・ソースから前記データを動的に取り出すステップを含む請求項３に記 載のコンピュータ実施方法。 ５．前記要求を処理する前記ステップが、前記ページ・サーバが前記１つまた は複数のデータ・ソースへの接続キャッシュを維持するステップを含む請求項４ に記載のコンピュータ実施方法。 ６．前記要求を処理する前記ステップが前記１つまたは複数のデータ・ソース にログインするステップを含む請求項４に記載のコンピュータ実施方法。 ７．前記Ｗｅｂページを動的に生成する前記ステップが、前記Ｗｅｂページを 含むページ・キャッシュを維持するステップを含む請求項４に記載のコンピュー タ実施方法。 ８．前記ページ・サーバが前記Ｗｅｂページを構成するためのカスタムＨＴＭ Ｌ拡張テンプレートを含む請求項４に記載のコンピュータ実施方法。 ９．前記要求を処理する前記ステップが、前記１つまたは複数のデータ・ソー スから動的に取り出された前記データを前記カスタムＨＴＭＬ拡張テンプレート 中に挿入するステップをさらに含む請求項８に記載のコンピュータ実施方法。 １０．それぞれ１つまたは複数のＷｅｂページを有する１つまたは複数のＷｅ ｂサーバを含むＷｅｂサイトを管理するコンピュータ実施方法であって、 前記Ｗｅｂサイトの前記１つまたは複数のＷｅｂサーバの各Ｗｅｂサーバから の前記１つまたは複数のＷｅｂページを含むマスタＷｅｂ管理ページを生成する ステップと、 前記Ｗｅｂ管理ページを使用して、新しい場所に前記Ｗｅｂサイトを再生成す るステップと を含むコンピュータ実施方法。 １１．動的Ｗｅｂページ生成要求を管理するネットワーク・システムであって 、 １つまたは複数のデータ・ソースと、 処理手段を有するページ・サーバと、 前記要求を生成するための手段を含む第１のコンピュータ・システムと、 前記第１のコンピュータからの前記要求を受け取るための手段を含む第２のコ ンピュータ・システムと を含み、前記第２のコンピュータ・システムがまたルータを含み、前記ルータが 前記第２のコンピュータ・システムからの前記要求を前記ページ・サーバにルー ティングし、前記ページ・サーバが前記要求を受け取り、他の要求を処理するた めに前記第２のコンピュータ・システムを解放し、前記ページ・サーバ処理手段 が前記要求を処理し、前記要求に応答してＷｅｂページを動的に生成し、前記Ｗ ｅｂページが前記１つまたは複数のデータ・ソースから動的に取り出されたデー タを含むネットワーク・システム。 １２．前記第２のコンピュータ・システム中の前記ルータが、 前記要求を前記第２のコンピュータ・システムでインターセプトし、前記要求 をルーティングするインターセプタと、 前記インターセプタから前記ルーティングされた要求を受け取り、前記要求を 前記ページ・サーバにディスパッチするディスパッチャと を含む請求項１１に記載のネットワーク・システム。 １３．動的Ｗｅｂページ生成要求を受け取るＷｅｂサーバであって、 前記要求を受け取るＷｅｂサーバ実行可能プログラムと、 前記要求をインターセプトし、前記Ｗｅｂサーバ実行可能プログラムからの前 記要求をページ・サーバにルーティングするインターセプト手段と を含むＷｅｂサーバ。 １４．動的Ｗｅｂページ生成要求を受け取るページ・サーバであって、 前記要求を受け取る手段と、 １つまたは複数のデータ・ソースへの接続キャッシュを維持する手段と、 前記要求を処理する手段と を含むページ・サーバ。 １５．前記要求を処理する前記手段が前記１つまたは複数のデータ・ソースか らデータを動的に取り出す手段をさらに含む請求項１４に記載のページ・サーバ 。 １６．プロセッサにＷｅｂサーバへの動的Ｗｅｂページ生成要求を管理させる ためにその中に組み込まれたコンピュータ命令を有するコンピュータ読取り可能 媒体であって、前記製品中の前記コンピュータ命令が、 前記Ｗｅｂサーバからの前記要求をページ・サーバにルーティングし、前記ペ ージ・サーバが前記要求を受け取り、他の要求を処理するために前記Ｗｅｂサー バを解放するステップと、 前記要求を処理するステップであって、前記処理が前記ページ・サーバによっ て実施されるステップと、 Ｗｅｂページを動的に生成するステップであって、前記Ｗｅｂページが１つま たは複数のデータ・ソースから取り出されたデータを含むステップとを前記プロ セッサに実施させるコンピュータ読取り可能媒体。