JP6750054B2 - ウェブページを構築しモデル化するためのシステム - Google Patents

Description

＜関連出願の参照＞
本特許出願は、２０１８年０２月２６日出願の米国仮特許出願６２／６３５、１６１に対して優先権を主張し、この出願は、参照によりその全体が本明細書に組み込まれる。

＜背景技術＞
ウェブ開発者がウェブページを開発するとき、開発者はそのページのコンポーネントを駆動するために基本論理に依存するフレームワークを使用することができる。代表的なフレームワークは、ウェブページの構造及び動作の側面を定義するために、特別なアプリケーションプログラミングインターフェイス（ＡＰＩ）を定義するＪａｖａＳｃｒｉｐｔライブラリを公開することができる。実際には、ウェブ開発者がウェブページのためのハイパーテキストマークアップ言語（ＨＴＭＬ）ドキュメントを作成するとき、開発者はそのような公開されているＪａｖａＳｃｒｉｐｔライブラリへの参照をドキュメントに配置することができ、そして、そのページがブラウザによってレンダリングされるときに所望の方法でそのページの構造及び動作を制御するためのＪａｖａＳｃｒｉｐｔ ＡＰＩを呼び出すであろうコードのセットをドキュメントに書き込んで含めることができる。

しかし残念ながら、そのようなウェブ開発フレームワークのプロバイダはフレームワークを時々変更したり、特定のフレームワークやフレームワークのバージョンのサポートを中止したりする可能性がある。これが発生すると、ウェブ開発者は、より新しいサポートされたフレームワークを利用するために、新しく命令的な（命令文を用いた）コードを書き又はその他の変更を行って、廃止されたフレームワークを使用していたウェブページを書き換えることを余儀なくされる可能性がある。しかし、問題のウェブページが高度に複雑な場合は特に、この処理は実用的ではない。従って、改善が望まれている。

この問題に対処するための システムが開示され、これにより、ウェブ開発者が、カスタムのウェブコンポーネントの使用を通じて、また、必要に応じてシステムのプロバイダによって更新又は変更されるようにすることができる基本スクリプトライブラリへの参照を通じて、ページの書換えを必要とせずにウェブページを作成することを可能にする。本システムは、ウェブ開発者が、その開発者がこれらの結果を達成するための方法を定義するために命令的なコーディングに従事する必要なしに、そのページの所望の構造及び動作を宣言するマークアップを用いて、そのようなページを宣言的に（宣言文を用いて）作成することを可能にする。更に、本システムのウェブコンポーネントは、コンポーネント間のデータバインディングをサポートするように構成されるようにすることができ、そして、本システムは、ウェブ開発者が、ページ上のコンポーネントのプロパティをそのページ上の他のコンポーネントによって発行されたアクションに宣言的にバインドすることを可能にする。

これを容易にするために、本システムは更に、ウェブページ記述を効率的に表現及び記憶し、ブラウザによるレンダリングのための関連するＨＴＭＬドキュメントを動的に構築するページビルダサブシステムを含むことができる。

特に、本ページビルダシステムは、ウェブページの記述を、リレーショナルデータベース内に、そのページ内のコンポーネントの階層的配置とそれらの間のデータバインディングを定義する相互に関連する様々なテーブルを用いて、メタデータとして記憶することができる。例えば、本システムは、ウェブ開発者がコンポーネント階層及びデータバインデ
ィングを指定して上述のようにカスタムのウェブコンポーネントを組み込んだウェブページをデザイン又は作成することができるインタフェースを提供することができ、そして、本システムは、上記カスタムのコンポーネントを駆動させるであろう基本スクリプトライブラリへの参照を含むページ構造を表現することに関連するデータベースレコードを生成し記憶することにより、開発者の仕様書に応えることができる。

そして、本ページビルダシステムは、上記データベースに問い合わせて上記関連するページ構造を確立することによってブラウザのウェブページリクエストに応答することができ、そして、上記問合せの結果に基づいて、適切なコンポーネント宣言と基本スクリプトライブラリへの参照を含むＨＴＭＬドキュメントを動的に構築することができる。そして、本ページビルダシステムは、基本スクリプトファイルとできる限りともに、上記構築されたＨＴＭＬドキュメントをリクエストしているブラウザにレンダリングのために返すことができる。これらのＨＴＭＬドキュメントはリクエストに応じて動的に構築されるため、新しく提供されたスクリプトが開発者が宣言した階層、データバインディング、及びその他のパラメータを引き続きサポートするであろうことが提供される場合には、基本スクリプトライブラリ及び関連する参照は、ページ書換えを必要とすることなく、必要に応じて変更されるようにすることができる。

従って、第１の例示的実施形態は、そのような動作を実行又はサポートするように構成されたコンピューティングシステムを含むようにすることができる。例えば、コンピューティングシステムは、ウェブページの構造を宣言する入力であって、そのウェブページのコンポーネント間のコンポーネント階層構造及びデータバインディングの宣言を含むものを受信し、そして、すぐに応答して、上記コンポーネントの構造及び動作を解釈実行可能に定義するための基本スクリプトへの参照を含む上記ウェブページの表現を、データベースの複数のテーブルに協調的に生成して記憶するように構成されるようにすることができる。更に、そのコンピューティングシステムはその後に、クライアント装置からそのようなページのためのリクエストを受信し、そして、そのリクエストに応答して、（ｉ）上記ページのコンポーネントツリー構造を確認するために上記データベースに問い合わせ、（ｉｉ）その確認されたコンポーネントツリー構造に基づいて、上記確認されたコンポーネントツリー構造を表現し、上記基本スクリプトを動作するようにロードするためのコンポーネントローダを含むマークアップドキュメントを構築し、そして、（ｉｉｉ）その構築されたマークアップドキュメントを上記クライアント装置上で実行されるウェブブラウザによるレンダリングのために出力する、ように構成されるようにすることができる。

第２の例示的実施形態では、製造品は、コンピューティングシステムによる実行時に前記コンピューティングシステムに、第１の例示的実施形態に従った動作を実行させるプログラム命令を記憶した、非一過性コンピュータ読取り可能媒体を含むようにすることができる。

第３の例示的実施形態では、コンピューティングシステムは、少なくとも１つのプロセッサ、並びにメモリ及びプログラム命令を含むようにすることができる。そのプログラム命令は、メモリに記憶されるようにすることができ、上記少なくとも１つのプロセッサによる実行時に上記コンピューティングシステムに第１の例示的実施形態に従った動作を実行させることができるようにすることができる。

第４の例示的実施形態は、そのような動作を実行し又は支援するように構成されたシステムを含むようにすることができる。このシステムは、ウェブページのコンポーネントの階層的配置を協調的に定義する複数の相互に関係するレコードであって、そのウェブページの上記コンポーネントの構造及び動作を解釈実行可能に定義するための基本スクリプトへの参照を含むものと、そのウェブページの上記コンポーネント間のデータバインディン
グを協調的に定義する複数の相互に関係するレコードと、を含むデータベースを含むことができる。更に、本システムは、コンピューティング装置上で実行されるウェブサーバアプリケーションであって、クライアント装置から上記ウェブページのためのリクエストを受信し、（ｉ）上記ウェブページの上記コンポーネントの上記階層的配置を表現するコンポーネントツリー構造を確認し、上記ウェブページの上記コンポーネント間のデータバインディングを確認するために上記データベースに問い合わせ、（ｉｉ）上記確認されたコンポーネントツリー構造及びデータバインディングに基づいて、上記確認されたコンポーネントツリー構造及びデータバインディングを表現し、上記基本スクリプトを動作するようにロードするためのコンポーネントローダを含むマークアップドキュメントを構築し、そして、（ｉｉｉ）上記構築されたマークアップドキュメントを上記クライアント装置上で実行されるウェブブラウザによるレンダリングのために出力することによって上記リクエストに応答する、ように構成されるものを含むことができる。

第５の例示的実施形態では、システムは、他の例示的な実施形態の各動作を実行するための種々の手段を含むようにすることができる。

これら及び他の実施形態、態様、利点、及び変形例は、添付の図面を適宜参照しながら以下の詳細な説明を読むことによって、当業者には明らかになるであろう。更に、本明細書に提供されたこの概要並びに他の説明及び図は、実施例としてのみ実施形態を説明することを意図しており、従って、多数の変形形態が可能であることを意図している。例えば、特許請求されるような実施形態の範囲内に留まりながら、構造要素及び処理ステップが、再構成され、組み合わせられ、分散され、排除され、又は他の方法で変更されるようにすることができる。

例示的実施形態による、コンピューティング装置の概略図を示す。 例示的実施形態による、サーバ装置クラスタの概略図を示す。 例示的な実施形態による、リモートネットワーク管理アーキテクチャを示す。 例示的実施形態による、リモートネットワーク管理アーキテクチャを含む通信環境を示す。 例示的実施形態による、リモートネットワーク管理アーキテクチャを含む他の通信環境を示す。 例示的実施形態によるフローチャートである。 例示的実施形態を使用してレンダリングされたウェブページを示す。 図６に示されるようなページを表すＨＴＭＬドキュメントの一部を示すスクリーンショットを示す。 図７のＨＴＭＬをレンダリングするブラウザによって確立され得る、結果として生じるＨＴＭＬのページ詳細を示す。 例示的実施形態におけるページビルダインタフェースの属性部分を示す。 例示的実施形態におけるページビルダインタフェースのプロパティ部分を示す。 例示的実施形態におけるページビルダインタフェースのアクション部分を示す。 例示的実施形態で使用するためのデータベーススキーマの一部を示す。 例示的実施形態で使用するためのデータベーススキーマの別の部分を示す。 ページリクエストに応答してＨＴＭＬドキュメントを配信することを構築するための実施例の処理フローを示す。 例示的実施形態で動作可能なシステムの簡略ブロック図である。 例示的実施形態によるフローチャートである。

方法、装置、及びシステムの実施例が、本明細書に記載されている。「例」及び「好例の」という言葉は、本明細書では、「例、実施例、例示として役に立つ」ということを意味するために使われることを理解すべきである。本明細書において「例」又は「好例の」として表現される任意の実施形態又は特徴は、そのように明言されていない限り、必ずしも他の実施形態又は特徴よりも好ましい又は有利であると解釈される必要はない。従って、本明細書で示されている主題の範囲から逸脱することなく、他の実施形態を使用することができ、及び他の変更をなすことができる。

従って、本明細書に記載の例示的実施形態は、限定することを意図するものではない。本明細書に一般的に記載され、そして図に示されるような本開示の態様は、多種多様な異なる構成で配置され、置換され、組み合わされ、分離され、及び設計されるようにすることができることが、容易に理解されるであろう。例えば、機能を「クライアント」コンポーネントと「サーバ」コンポーネントに分離することは、さまざまな方法で発生する可能性がある。

更に、文脈が他に示唆しない限り、各図に示される特徴は互いに組み合わせて使用されるようにすることができる。従って、図は一般的に、例示された特徴の全てが各実施形態に必要というわけではないことを理解して、１つ以上の全体的な実施形態の構成態様として見なされるべきである。

更に、本明細書又は特許請求の範囲における要素、ブロック、又はステップの任意の列挙は、明確にすることの目的のためである。従って、そのような列挙は、これらの要素、ブロック、又はステップが、特定の構成に囚われること、又は特定の順序で実行されることを、要求又は示唆すると解釈されるべきではない。

Ｉ．序説
大企業は、相互に関連する多数の業務を含む複雑な実体である。これらのうちのいくつかは、人事（ＨＲ）、サプライチェーン、情報技術（ＩＴ）、及び財務などのように、企業をまたいで見られるものもある。しかしながら、それぞれの企業は、欠くことのできない機能を提供したり、競争上の優位性を生み出したりする、それ独自の業務も有する。

広く実施されている業務をサポートするために、企業は通常、顧客関係管理（ＣＲＭ）及び人的資本管理（ＨＣＭ）パッケージのような、既製のソフトウェアアプリケーションを使用する。しかしながら、独自の要件を満たすためにカスタムソフトウェアアプリケーションも必要になる場合がある。大企業は、多くの場合、数十から数百のカスタムソフトウェアアプリケーションを有する。それでもなお、本明細書の実施形態によって提供される利点は、大企業に限定されず、任意の規模の企業、又は任意の他の種類の組織に適用されるようにすることができる。

多くのそのようなソフトウェアアプリケーションは、企業内のそれぞれの部門によって開発されている。これらは簡単なスプレッドシートからカスタムメイドのソフトウェアツール及びデータベースまである。しかし、サイロ化されたカスタムソフトウェアアプリケーションの急増は、多くの欠点を有している。それは、業務を運営し成長させ革新し法的規制を満たすという、企業の能力に悪影響を及ぼす。企業は、サブシステムとデータを統合する単一のシステムがないために、その業務を統合し合理化し強化することが難しいことを見いだすかもしれない。

カスタムアプリケーションを効率的に作成するために、企業は、不必要な開発の複雑さを排除する、遠隔にホストされるアプリケーションプラットフォームの恩恵を受けるであろう。このようなプラットフォームの目標は、ソフトウェアエンジニアや他の役割を担う個人が独自の価値の高い機能の開発に集中できるように、時間を消費し繰返しのあるアプリケーション開発作業を減らすことである。

この目標を達成するために、企業全体のワークフローをインテリジェントに自動化するために、サービスとしてのアプリケーションプラットフォーム（ａＰａａＳ）の概念が導入される。ａＰａａＳシステムは、企業から遠隔にホストされるが、安全な接続を介して企業内のデータ、アプリケーション、及びサービスにアクセスすることができる。そのようなａＰａａＳシステムは、いくつかの有利な能力及び特性を有することができる。これらの利点と特性は、ＩＴ、人事、ＣＲＭ、顧客サービス、アプリケーション開発、及びセキュリティに関する、企業の運用とワークフローを向上させることができる。

ａＰａａＳシステムは、モデル−ビュー−コントローラ（ＭＶＣ）アプリケーションの開発及び実行をサポートすることができる。ＭＶＣアプリケーションは、情報の表示をその情報がユーザに提示される方法から分離するために、それらの機能を３つの相互接続された部分（モデル、ビュー、及びコントローラ）に分割し、それによって効率的なコード再利用及び並列開発を可能にする。これらのアプリケーションはウェブベースとすることができ、そして、生成、読取り、更新、削除（ＣＲＵＤ）の能力を提供することができる。これにより、新しいアプリケーションを、共通のアプリケーションインフラストラクチャ上に構築することができる。

ａＰａａＳシステムは、グラフィカルユーザインタフェース（ＧＵＩ）開発用の標準化されたウィジェットのセットなどの、標準化されたアプリケーションコンポーネントをサポートすることができる。このように、ａＰａａＳシステムを使用して構築されたアプリケーションは共通のルックアンドフィールを有する。他のソフトウェア構成要素及びモジュールも同様に標準化されるようにすることができる。場合によっては、このルックアンドフィールは、企業のカスタムロゴ及び／又は配色を用いて、ブランド設定又はスキン設定することができる。

ａＰａａＳシステムは、メタデータを使用してアプリケーションの動作を設定する機能をサポートすることができる。これにより、アプリケーションの動作を特定のニーズを満たすように迅速に適応させることができる。このようなアプローチは開発時間を短縮し、柔軟性を高める。更に、ａＰａａＳシステムは、メタデータの作成及び管理を容易にするＧＵＩツールをサポートすることができ、従ってメタデータ内のエラーを減らすことができる。

ａＰａａＳシステムは、アプリケーション間の明確に定義されたインタフェースをサポートするので、ソフトウェア開発者は望ましくないアプリケーション間の依存関係を避けることができる。従って、ａＰａａＳシステムは、持続的状態情報及び他のデータが記憶されているサービス層を実装することができる。

ａＰａａＳシステムは、その上のアプリケーションがレガシアプリケーション及びサードパーティアプリケーションと対話することができるように、豊富な統合機能のセットをサポートすることができる。例えば、ａＰａａＳシステムは、従来の人事、ＩＴ、及び経理システムと統合する、カスタムの従業員オンボーディングシステムをサポートすることができる。

ａＰａａＳシステムは、エンタプライズレベルのセキュリティをサポートすることがで
きる。更に、ａＰａａＳシステムは遠隔でホストされる可能性があるため、企業内のシステム又は企業外でホストされるサードパーティのネットワークやサービスと対話するときには、セキュリティ手順もまた利用すべきである。例えば、ａＰａａＳシステムは、一般的なセキュリティの脅威を検出し識別するために、企業内及び他の関係者の間でデータを共有するように構成されるようにすることができる。

ａＰａａＳシステムの他の機能（feature）、機能（functionality）、及び利点が存在する可能性がある。この説明は例示目的であり、限定的であることを意図しない。

ａＰａａＳ開発プロセスの一例として、ソフトウェア開発者は、ａＰａａＳシステムを使用して新しいアプリケーションを作成するように任命されるようにすることができる。最初に、開発者はデータモデルを定義することができ、それはアプリケーションが使用するデータのタイプ及びそれらの間の関係を指定する。そして、ａＰａａＳシステムのＧＵＩを介して、開発者はデータモデルを入力する（例えばアップロードする）。ａＰａａＳシステムは、対応する全てのデータベーステーブル、フィールド、及びリレーションシップを自動的に作成し、これらは、オブジェクト指向サービスレイヤを介してその後アクセスできる。

更に、ａＰａａＳシステムは、クライアントサイドのインタフェースとサーバサイドのＣＲＵＤロジックを備えた、完全機能のＭＶＣアプリケーションを構築することもできる。この生成されたアプリケーションは、ユーザにとっての更なる開発の基盤として機能し得る。有利なことには、開発者は基本的なアプリケーション機能に多大な時間を費やす必要がない。更に、アプリケーションはウェブベースでもよいので、任意のインターネット対応クライアント装置からアクセスすることができる。代替的又は追加的に、例えばインターネットサービスが利用できないときに、アプリケーションのローカルコピーにアクセスすることができるようにすることができる。

ａＰａａＳシステムは、アプリケーションに追加できる豊富な一連の定義済み機能もサポートすることができる。これらの機能は、検索、電子メール、テンプレート作成、ワークフロー設計、レポート作成、分析、ソーシャルメディア、スクリプト作成、モバイル対応の出力、及びカスタマイズされたＧＵＩのサポートを含む。

以下の実施形態は、例示的なａＰａａＳシステムの構造的及び機能的態様、並びにそれらの特徴及び利点を説明する。

ＩＩ．コンピューティング装置とクラウドベースのコンピューティング環境の実施例
図１は、本明細書の実施形態に従って動作するように構成されたコンピューティング装置に含まれ得るいくつかのコンポーネントを示す、コンピューティング装置１００を例示する簡略ブロック図である。コンピューティング装置１００は、クライアント装置（例えば、ユーザによって能動的に動作される装置）、サーバ装置（例えば、クライアント装置に計算サービスを提供する装置）、又は他の何らかのタイプの計算プラットフォームとすることができる。特定の動作を実行するために時としてクライアント装置として動作するサーバ装置もあれば、サーバ機能を組み込んだクライアント装置もある。

この実施例では、コンピューティング装置１００は、プロセッサ１０２、メモリ１０４、ネットワークインタフェース１０６、及び入出力ユニット１０８を含み、それらは全てシステムバス１１０又は同様の機構によって結合されるようにすることができる。いくつかの実施形態では、コンピューティング装置１００は、他のコンポーネント及び／又は周辺装置（例えば、取外し可能ストレージ、プリンタなど）を含むことができる。

プロセッサ１０２は、中央処理装置（ＣＰＵ）、コプロセッサ（例えば、数学、グラフィック、又は暗号化コプロセッサ）、デジタル信号プロセッサ（ＤＳＰ）、ネットワークプロセッサ、及び／又はプロセッサ動作を実行する集積回路もしくはコントローラの形態などの、任意の種類のコンピュータ処理要素のうちの１つ以上とすることができる。場合によっては、プロセッサ１０２は、１つ以上のシングルコアプロセッサとすることができる。他のケースでは、プロセッサ１０２は、複数の独立した処理ユニットを有する１つ以上のマルチコアプロセッサであってもよい。プロセッサ１０２はまた、実行中の命令及び関連データを一時的に記憶するためのレジスタメモリ、並びに最近使用された命令及びデータを一時的に記憶するためのキャッシュメモリを含むことができる。

メモリ１０４は、ランダムアクセスメモリ（ＲＡＭ）、読出し専用メモリ（ＲＯＭ）、及び不揮発性メモリ（例えば、フラッシュメモリ、ハードディスクドライブ、ソリッドステートドライブ、コンパクトディスク（ＣＤ）、デジタルビデオディスク（ＤＶＤ）、及び／又はテープストレージ）を含むがこれらに限定されない、任意の形態のコンピュータ使用可能メモリとすることができる。従って、メモリ１０４は、主記憶装置と長期記憶装置の両方を表す。他の種類のメモリは、生物学的メモリを含むことができる。

メモリ１０４は、プログラム命令及び／又はプログラム命令が動作するようにすることができるデータを記憶することができる。例として、メモリ１０４は、これらのプログラム命令を非一過性コンピュータ読取り可能記録媒体上に記憶してもよく、その結果、命令は、本明細書又は添付の図面において開示される方法、処理、又は動作の任意のものを実行するために、プロセッサ１０２によって実行可能である。

図１に示されるように、メモリ１０４は、ファームウェア１０４Ａ、カーネル１０４Ｂ、及び／又はアプリケーション１０４Ｃを含むことができる。ファームウェア１０４Ａは、ブートあるいはさもなくばコンピューティング装置１００の一部又は全部を起動するために使用される、プログラムコードとすることができる。カーネル１０４Ｂは、メモリ管理、プロセスのスケジューリング及び管理、入出力、並びに通信のためのモジュールを含むオペレーティングシステムとすることができる。カーネル１０４Ｂはまた、オペレーティングシステムがコンピューティング装置１００のハードウェアモジュール（例えば、メモリユニット、ネットワーキングインタフェース、ポート、及びバス）と通信することを可能にするデバイスドライバを含むことができる。アプリケーション１０４Ｃは、Ｗｅｂブラウザ又は電子メールクライアント、並びにこれらのプログラムによって使用される任意のソフトウェアライブラリなどの、１つ以上のユーザ空間ソフトウェアプログラムとすることができる。メモリ１０４はまた、これら並びに他のプログラム及びアプリケーションによって使用されるデータを記憶することができる。

ネットワークインタフェース１０６は、イーサネット（例えば、ファストイーサネット、ギガビットイーサネットなど）などの１つ以上の有線インタフェースの形態を取ることができる。ネットワークインタフェース１０６は、同軸ケーブル又は電力線などの１つ以上の非イーサネット媒体を介した通信、あるいは同期光ネットワーク（ＳＯＮＥＴ）又はデジタル加入者線（ＤＳＬ）技術などの広域媒体を介した通信もサポートすることができる。ネットワークインタフェース１０６は更に、ＩＥＥＥ８０２.１１（Ｗｉｆｉ）、Ｂ
ＬＵＥＴＯＯＴＨ（米国登録商標）、全地球測位システム（ＧＰＳ）、又は広域無線インタフェースなどの１つ以上の無線インタフェースの形態をとることができる。しかしながら、他の形態の物理層インタフェース及び他の種類の標準又は独自の通信プロトコルが、ネットワークインタフェース１０６を介して使用されてもよい。更に、ネットワークインタフェース１０６は、複数の物理インタフェースを含んでもよい。例えば、コンピューティング装置１００のいくつかの実施形態は、イーサネット、ＢＬＵＥＴＯＯＴＨ（米国登録商標）、及びＷｉｆｉインタフェースを含むことができる。

入出力ユニット１０８は、例示的コンピューティング装置１００を用いて、ユーザと周辺機器との対話を容易にすることができる。入出力ユニット１０８は、キーボード、マウス、タッチスクリーンなどのような、１つ以上の種類の入力装置を含むことができる。同様に、入出力ユニット１０８は、スクリーン、モニタ、プリンタ、及び／又は１つ以上の発光ダイオード（ＬＥＤ）などのような、１つ以上の種類の出力装置を含むことができる。追加的又は代替的に、コンピューティング装置１００は、例えばユニバーサルシリアルバス（ＵＳＢ）又は高品位マルチメディアインタフェース（ＨＤＭＩ）ポートインタフェースを使用して、他の装置と通信することができる。

いくつかの実施形態では、コンピューティング装置１００の１つ以上のインスタンスは、ａＰａａＳアーキテクチャをサポートするためにデプロイされるようにすることができる。これらのコンピューティング装置の正確な物理的位置、接続性、及び構成は、未知であってよく、及び／又はクライアント装置にとって重要ではなくともよい。従って、コンピューティング装置は、さまざまなリモートデータセンタの場所に収容されるようにすることができる「クラウドベースの」装置と呼ばれることがある。

図２は、例示的実施形態による、クラウドベースのサーバクラスタ２００を示す。図２では、コンピューティング装置（例えば、コンピューティング装置１００）の動作は、サーバ装置２０２、データ記憶装置２０４、及びルータ２０６間に分散させることができ、それらは全てローカルクラスタネットワーク２０８によって接続することができる。サーバクラスタ２００内のサーバ装置２０２、データ記憶装置２０４、及びルータ２０６の数は、サーバクラスタ２００に割り当てられたコンピューティングタスク及び／又はアプリケーションに依存するようにすることができる。

例えば、サーバ装置２０２は、コンピューティング装置１００の様々なコンピューティングタスクを実行するように構成されるようにすることができる。従って、コンピューティングタスクは、１つ以上のサーバ装置２０２の間で分散されるようにすることができる。これらのコンピューティングタスクが並列に実行され得る限り、このようなタスクの分散は、これらのタスクを完了して結果を返すまでの合計時間を短縮できる。簡略の目的のために、サーバクラスタ２００及び個々のサーバ装置２０２の両方が「サーバ装置」と呼ばれてよい。この命名法は、１つ以上の別個のサーバ装置、データ記憶装置、及びクラスタルータがサーバ装置動作に含まれることを暗に意味していると理解されるべきである。

データ記憶装置２０４は、ハードディスクドライブ及び／又はソリッドステートドライブのグループへの読出し及び書込みアクセスを管理するように構成されたドライブアレイコントローラを含むデータストレージアレイとすることができる。ドライブアレイコントローラはまた、単独で又はサーバ装置２０２と共に、データ記憶装置２０４に記憶されたデータのバックアップ又は冗長コピーを管理して、ドライブの障害又は１つ以上のサーバ装置２０２がクラスタデータ記憶装置２０４のユニットにアクセスすることを妨げる他の種類の障害から保護するように構成されるようにすることもできる。ドライブ以外の他の種類のメモリが使用されてもよい。

ルータ２０６は、サーバクラスタ２００のために内部及び外部通信を提供するように構成されたネットワーキング機器を含むことができる。例えば、ルータ２０６は、（ｉ）クラスタネットワーク２０８を介したサーバ装置２０２とデータ記憶装置２０４との間のネットワーク通信、及び／又は（ｉｉ）ネットワーク２１２への通信リンク２１０を介したサーバクラスタ２００と他の装置との間のネットワーク通信を提供するように構成された１つ以上のパケット交換及び／又はルーティング装置（スイッチ及び／又はゲートウェイを含む）を含むことができる。

更に、クラスタルータ２０６の設定は、サーバ装置２０２とデータ記憶装置２０４のデータ通信要件、ローカルクラスタネットワーク２０８のレイテンシとスループット、通信リンク２１０のレイテンシとスループットとコスト、及び／又は、コストや速度やフォールトトレランス（耐故障性）や回復力や効率やシステムアーキテクチャの他の設計目標に寄与できる他の要因に、少なくとも部分的に基づくことができる。

可能な実施例として、データ記憶装置２０４は、構造化照会言語（ＳＱＬ）データベースなどの、任意の形態のデータベースを含むことができる。テーブル、アレイ、リスト、ツリー、及びタプルを含むがこれらに限定されない様々な種類のデータ構造が、そのようなデータベースにおいて情報を記憶することができる。更に、データ記憶装置２０４内の任意のデータベースは、モノリシック（一体構造）でもよく、又は複数の物理装置にわたって分散されてもよい。

サーバ装置２０２は、クラスタデータ記憶装置２０４との間でデータを送受信するように構成することができる。この送信及び読出しは、それぞれ、ＳＱＬクエリ又は他の種類のデータベースクエリ、及びそのようなクエリの出力の形をとることができる。追加のテキスト、画像、ビデオ、及び／又はオーディオも同様に含まれるようにすることができる。更に、サーバ装置２０２は、受信したデータをウェブページ表現に編成することができる。そのような表現は、ハイパーテキストマークアップ言語（ＨＴＭＬ）、拡張マークアップ言語（ＸＭＬ）、又は他の何らかの標準化された若しくは独自のフォーマットなどのマークアップ言語の形態をとることができる。更に、サーバ装置２０２は、限定はしないが、Ｐｅｒｌ、Ｐｙｔｈｏｎ、ＰＨＰハイパーテキストプリプロセッサ（ＰＨＰ）、アクティブサーバページ（ＡＳＰ）、ＪａｖａＳｃｒｉｐｔなどの様々なタイプのコンピュータ化スクリプト言語を実行する機能を有することができる。これらの言語で書かれたコンピュータプログラムコードは、クライアント装置へのウェブページの提供、並びにウェブページとのクライアント装置の対話を容易にすることができる。

ＩＩＩ．リモートネットワーク管理アーキテクチャの実施例
図３は、例示的実施形態による、リモートネットワーク管理アーキテクチャを示す。このアーキテクチャは、全てインターネット３５０を介して接続された３つの主要コンポーネント、管理対象ネットワーク３００、リモートネットワーク管理プラットフォーム３２０、及びサードパーティネットワーク３４０を含む。

管理対象ネットワーク３００は、例えば、コンピューティング及び通信タスク、並びにデータの記憶のために企業によって使用される企業ネットワークとすることができる。従って、管理対象ネットワーク３００は、様々なクライアント装置３０２、サーバ装置３０４、ルータ３０６、仮想マシン３０８、ファイアウォール３１０、及び／又はプロキシサーバ３１２を含むことができる。クライアント装置３０２はコンピューティング装置１００によって具現化されるようにすることができ、サーバ装置３０４はコンピューティング装置１００又はサーバクラスタ２００によって具現化されるようにすることがき、ルータ３０６は任意のタイプのルータ、スイッチ、又はゲートウェイとすることができる。

仮想マシン３０８は、コンピューティング装置１００又はサーバクラスタ２００のうちの１つ以上によって具現化されるようにすることができる。一般に、仮想マシンは、コンピューティングシステムのエミュレーションであり、物理コンピュータの機能（例えば、プロセッサ、メモリ、及び通信リソース）を模倣する。サーバクラスタ２００などの１つの物理的コンピューティングシステムは、最大数千までの個別の仮想マシンをサポートすることができる。いくつかの実施形態では、仮想マシン３０８は、個別の仮想マシンへの物理的コンピューティングリソースの割当て、並びにパフォーマンス及びエラーの報告を
容易にする、集中型サーバ装置又はアプリケーションによって管理されるようにすることができる。企業は、必要に応じて効率的にコンピューティングリソースを割り当てるために、仮想マシンを使用することがよくある。仮想化コンピューティングシステムのプロバイダは、ＶＭＷＡＲＥ（米国登録商標）及びＭＩＣＲＯＳＯＦＴ（米国登録商標）を含む。

ファイアウォール３１０は、管理対象ネットワーク３００から開始される権限のある通信を許可しながら、管理対象ネットワーク３００をその中の装置、アプリケーション、及びサービスにアクセスする権限のない攻撃から保護する１つ以上の専用ルータ又はサーバ装置とすることができる。ファイアウォール３１０はまた、侵入検知、Ｗｅｂフィルタリング、ウイルススキャン、アプリケーション層ゲートウェイ、及びその他のアプリケーションやサービスを提供することができる。図３に示されていないいくつかの実施形態では、管理対象ネットワーク３００は、リモートネットワーク管理プラットフォーム３２０と通信するための１つ以上の仮想プライベートネットワーク（ＶＰＮ）ゲートウェイを含むことができる（下記参照）。

管理対象ネットワーク３００はまた、１つ以上のプロキシサーバ３１２も含むことができる。プロキシサーバ３１２の一実施形態は、管理対象ネットワーク３００、リモートネットワーク管理プラットフォーム３２０、及びサードパーティネットワーク３４０間のデータの通信及び移動を容易にするサーバ装置とすることができる。特に、プロキシサーバ３１２は、リモートネットワーク管理プラットフォーム３２０の１つ以上の計算インスタンスとの安全な通信セッションを確立し維持できるようにすることができる。そのようなセッションを通じて、リモートネットワーク管理プラットフォーム３２０は、管理対象ネットワーク３００及びそのコンポーネントのアーキテクチャおよび構成の態様を発見し管理できるようにすることができる。場合によっては、プロキシサーバ３１２の助けを借りて、リモートネットワーク管理プラットフォーム３２０はまた、管理対象ネットワーク３００によって使用されるサードパーティネットワーク３４０の態様を発見し管理できるようにすることができる。

ファイアウォール３１０などのファイアウォールは、通常、そのようなセッションがファイアウォールの背後から（即ち管理対象ネットワーク３００上の装置から）開始されたか、ファイアウォールがそのセッションをサポートするために明示的に設定されていない限り、インターネット３５０を介して着信する全ての通信セッションを拒否する。プロキシサーバ３１２をファイアウォール３１０の背後に（例えば、管理対象ネットワーク３００内にあり、ファイアウォール３１０によって保護されるように）配置することによって、プロキシサーバ３１２は、ファイアウォール３１０を介してこれらの通信セッションを開始できるようにすることができる。これにより、ファイアウォール３１０はリモートネットワーク管理プラットフォーム３２０からの着信セッションに対応するために特に設定される必要がなく、それによって管理対象ネットワーク３００に対する潜在的なセキュリティリスクが回避されるであろう。

場合によっては、管理対象ネットワーク３００は、いくつかの装置と少数のネットワークとから構成されてもよい。他の展開（deployment）では、管理対象ネットワーク３００は複数の物理的場所にまたがることができ、数百のネットワーク及び数十万の装置を含むことができる。従って、図３に示すアーキテクチャは、桁違いに拡大又は縮小することができる。

更に、管理対象ネットワーク３００のサイズ、アーキテクチャ、及び接続性に依存して、さまざまな数のプロキシサーバ３１２をその中に展開（deploy）することができる。例えば、プロキシサーバ３１２のそれぞれは、管理対象ネットワーク３００の一部に関して
リモートネットワーク管理プラットフォーム３２０と通信することを担当するようにすることができる。代替的又は追加的に、２つ以上のプロキシサーバのセットが、負荷分散、冗長性、及び／又は高可用性の目的で、管理対象ネットワーク３００のそのような一部に割り当てられるようにすることができる。

リモートネットワーク管理プラットフォーム３２０は、ａＰａａＳサービスをユーザ特に管理対象ネットワーク３００の事業者に提供するホスト型環境である。これらのサービスは、例えば、ウェブベースのポータルの形をとることができる。従って、ユーザは、例えばクライアント装置３０２から又は潜在的には管理対象ネットワーク３００の外部のクライアント装置から、リモートネットワーク管理プラットフォーム３２０に安全にアクセスすることができる。ウェブベースのポータルを介して、ユーザは、アプリケーション、レポートの生成、分析の表示、及びその他のタスクの実行を、設計、テスト、及びデプロイすることができる。

図３に示されるように、リモートネットワーク管理プラットフォーム３２０は、４つの計算インスタンス３２２、３２４、３２６、及び３２８を含む。これらのインスタンスのそれぞれは、特定の顧客が利用できる一組のウェブポータル、サービス、及びアプリケーション（例えば、全機能ａＰａａＳシステム）を表すことができる。場合によっては、１人の顧客が複数の計算インスタンスを使用するようにすることができる。例えば、管理対象ネットワーク３００は、リモートネットワーク管理プラットフォーム３２０の企業顧客であるようにすることができ、計算インスタンス３２２、３２４、及び３２６を使用するようにすることができる。１人の顧客に複数のインスタンスを提供する理由は、顧客が独立してそのアプリケーションとサービスを開発しテストしデプロイしたいと希望し得るからである。従って、計算インスタンス３２２は管理対象ネットワーク３００に関連するアプリケーション開発専用とすることができ、計算インスタンス３２４はこれらのアプリケーションのテスト専用とすることができ、計算インスタンス３２６は被試験アプリケーション及びサービスのライブ運用専用とすることができる。計算インスタンスはまた、ホストインスタンス、リモートインスタンス、顧客インスタンス、又はいくつかの他の名称で呼ばれるようにすることもできる。

リモートネットワーク管理プラットフォーム３２０のマルチインスタンスアーキテクチャは、従来のマルチテナントアーキテクチャとは対照的で、それに対してマルチインスタンスアーキテクチャはいくつかの利点を有する。マルチテナントアーキテクチャでは、異なる顧客（例えば、企業）からのデータが、単一のデータベースにまとめられる。これらの顧客のデータは互いに分離されているが、その分離は単一のデータベースを動作するソフトウェアによって実施される。結果として、このシステムのセキュリティ違反は全ての顧客のデータに影響を及ぼし、特に政府、医療、及び／又は金融規制の対象となる事業体にとって、追加のリスクを生み出す可能性がある。更に、１人の顧客に影響を与えるデータベース動作は、そのデータベースを共有する全ての顧客に影響を与えることが予想される。従って、ハードウェア又はソフトウェアのエラーによる機能停止がある場合、この機能停止はそのような全ての顧客に影響する。同様に、データベースを１人の顧客のニーズに合わせてアップグレードする場合、アップグレードプロセス中に全ての顧客がそのデータベースを利用することはできない。しばしば、そのようなメンテナンス期間（maintenance window）は、共有されるデータベースのサイズにより、長くなる。

対照的に、マルチインスタンスアーキテクチャは、各顧客に、専用のコンピューティングインスタンス内でその独自のデータベースを提供する。これにより、顧客データの混入を防ぎ、各インスタンスを独立に管理することができる。例えば、ある顧客のインスタンスがエラー又はアップグレードによる停止を経験しても、他の計算インスタンスは影響を受けない。データベースには１つの顧客のデータしか含まれていないため、メンテナンス
の停止時間は限定される。更に、マルチインスタンスアーキテクチャのよりシンプルな設計が、各顧客データベース及びインスタンスの冗長コピーが地理的に多様な方法でデプロイされるようにすることを可能にする。このことは、障害が検出されたときやメンテナンスが実行されているときに、顧客のインスタンスのライブ（運転中の）バージョンが移動されるようにすることができる、高可用性を促進する。

複数の計算インスタンスを効率的な方法でサポートするために、リモートネットワーク管理プラットフォーム３２０は、単一のハードウェアプラットフォーム上でこれらの複数のインスタンスを実装することができる。例えば、ａＰａａＳシステムがサーバクラスタ２００のようなサーバクラスタ上で実装されるとき、それは様々な量の計算、記憶、及び通信リソースをインスタンス専用にする仮想マシンを動作させることができる。しかし、サーバクラスタ２００の完全仮想化は必要ではないかもしれず、他の機構がインスタンスを分離するために使用されるようにすることができる。いくつかの例では、各インスタンスは、サーバクラスタ２００上に専用アカウント及び１つ以上の専用データベースを有することができる。或いは、計算インスタンス３２２は、複数の物理装置にまたがることができる。

いくつかのケースでは、リモートネットワーク管理プラットフォーム３２０の単一のサーバクラスタは、複数の独立した企業をサポートすることができる。更に、後述するように、リモートネットワーク管理プラットフォーム３２０は、ロードバランシング、冗長性、及び／又は高可用性を容易にするために、地理的に多様なデータセンタにデプロイされた複数のサーバクラスタを含むことができる。

サードパーティネットワーク３４０は、アウトソーシングされた計算、データ記憶、通信、及びサービスホスティングの動作のために使用することができるリモートサーバ装置（例えば、サーバクラスタ２００のような複数のサーバクラスタ）であるようにすることができる。これらのサーバは仮想化されてもよい（即ち、サーバは仮想マシンでもよい）。サードパーティネットワーク３４０の実施例は、ＡＭＡＺＯＮ ＷＥＢ ＳＥＲＶＩＣＥＳ（米国登録商標）及びＭＩＣＲＯＳＯＦＴ（米国登録商標）Ａｚｕｒｅを含むことができる。リモートネットワーク管理プラットフォーム３２０と同様に、サードパーティネットワーク３４０をサポートする複数のサーバクラスタは、負荷分散、冗長性、及び／又は高可用性を目的として、地理的に多様な場所にデプロイされるようにすることができる。

管理対象ネットワーク３００は、アプリケーション及びサービスをそのクライアント及び顧客にデプロイするサードパーティネットワーク３４０の一つ以上を使用することができる。例えば、管理対象ネットワーク３００がオンライン音楽ストリーミングサービスを提供する場合、サードパーティネットワーク３４０は音楽ファイルを記憶し、ウェブインタフェース及びストリーミング機能を提供することができる。この方法では、管理対象ネットワーク３００の企業は、これらの動作のためにそれ自身のサーバを構築し維持する必要がない。

リモートネットワーク管理プラットフォーム３２０は、サードパーティネットワーク３４０と統合してその内部の仮想マシン及び管理対象サービスを管理対象ネットワーク３００に見えるようにするモジュールを含むことができる。そのモジュールは、ユーザが、仮想リソースを要求し、サードパーティネットワーク３４０のための柔軟なレポートを提供することを可能にするようにすることができる。この機能を確立するために、管理対象ネットワーク３００からのユーザは最初にサードパーティネットワーク３４０とのアカウントを確立し、そして一組の関連するリソースを要求することになるだろう。次に、ユーザは、そのアカウント情報をリモートネットワーク管理プラットフォーム３２０の適切なモ
ジュールに入力することができる。これらのモジュールは、その後、アカウント内の管理可能なリソースを自動的に発見し、そしてまた、使用、実績、及び課金に関する報告を提供することもできる。

インターネット３５０は、グローバルインターネットの一部を表すことができる。しかしながら、インターネット３５０は、代替的に、プライベートワイドエリア又はローカルエリアパケット交換ネットワークのような異なる種類のネットワークを表すことができる。

図４は更に、管理対象ネットワーク３００と計算インスタンス３２２との間の通信環境を示し、そして、追加の特徴及び代替の実施形態を紹介する。図４では、計算インスタンス３２２は、データセンタ４００Ａ及び４００Ｂにわたって複製されている。これらのデータセンタは、互いに地理的に離れている、おそらく異なる都市や異なる国にあるようにすることができる。各データセンタは、管理対象ネットワーク３００並びにリモートユーザとの通信を容易にする支援機器を含む。

データセンタ４００Ａにおいて、外部装置への及び外部装置からのネットワークトラフィックは、ＶＰＮゲートウェイ４０２Ａ又はファイアウォール４０４Ａのいずれかを通じて流れる。ＶＰＮゲートウェイ４０２Ａは、インターネットプロトコルセキュリティ（ＩＰＳＥＣ）又はトランスポート層セキュリティ（ＴＬＳ）のようなセキュリティプロトコルを介して、管理対象ネットワーク３００のＶＰＮゲートウェイ４１２とピア（対等）接続することができる。ファイアウォール４０４Ａは、ユーザ４１４及びリモートユーザ４１６のような権限のあるユーザからのアクセスを許可し、権限のないユーザへのアクセスを拒否するように構成されるようにすることができる。ファイアウォール４０４Ａを介して、これらのユーザは計算インスタンス３２２、そしておそらく他の計算インスタンスにアクセスすることができる。ロードバランサ４０６Ａは、計算インスタンス３２２をホストする１つ以上の物理又は仮想サーバ装置の間でトラフィックを分散するために使用されるようにすることができる。ロードバランサ４０６Ａは、データセンタ４００Ａの内部構成（例えば、計算インスタンス３２２）をクライアント装置から隠すことによって、ユーザアクセスを単純化することができる。例えば、計算インスタンス３２２が複数のデータベースへのアクセスを共有する複数の物理又は仮想コンピューティング装置を含む場合、ロードバランサ４０６Ａは、どの１つのコンピューティング装置又はデータベースも他よりも著しくビジーにならないように、ネットワークトラフィック及び処理中タスクをこれらのコンピューティング装置及びデータベースにわたって分散させることができる。いくつかの実施形態では、計算インスタンス３２２は、ＶＰＮゲートウェイ４０２Ａ、ファイアウォール４０４Ａ、及びロードバランサ４０６Ａを含むことができる。

データセンタ４００Ｂは、データセンタ４００Ａ内の構成要素の独自のバージョンを含むことができる。従って、ＶＰＮゲートウェイ４０２Ｂ、ファイアウォール４０４Ｂ、及びロードバランサ４０６Ｂは、それぞれ、ＶＰＮゲートウェイ４０２Ａ、ファイアウォール４０４Ａ、及びロードバランサ４０６Ａと同じ又は類似の動作を実行することができる。更に、リアルタイム又はほぼリアルタイムのデータベース複製及び／又は他の動作によって、計算インスタンス３２２はデータセンタ４００Ａ及び４００Ｂ内に同時に存在することができる。

データセンタ４００Ａと４００Ｂは、図４に示されるように、冗長性と高可用性を容易にすることができる。図４の構成では、データセンタ４００Ａはアクティブであり、データセンタ４００Ｂはパッシブである。従って、データセンタ４００Ｂ内の計算インスタンス３２２のバージョンがほぼリアルタイムで更新されている間に、データセンタ４００Ａは管理対象ネットワーク３００との間の全てのトラフィックを処理している。両方のデー
タセンタがアクティブであるような他の構成もサポートされるようにすることができる。

データセンタ４００Ａがいくつかのやり方で失敗するかさもなければユーザに利用不可となった場合、データセンタ４００Ｂは、アクティブなデータセンタとして引き継ぐことができる。例えば、計算インスタンス３２２のドメイン名をデータセンタ４００Ａの１つ以上のインターネットプロトコル（ＩＰ）アドレスと関連付けるドメインネームシステム（ＤＮＳ）サーバは、そのドメイン名をデータセンタ４００Ｂの１つ以上のＩＰアドレスと再関連付けすることができる。この再関連付けが完了した後（１秒未満又は数秒かかる）、ユーザはデータセンタ４００Ｂを介して計算インスタンス３２２にアクセスすることができる。

図４はまた、管理対象ネットワーク３００の可能な構成を示している。上述したように、図４は、プロキシサーバ３１２及びユーザ４１４は、ファイアウォール３１０を介して、計算インスタンス３２２にアクセスすることができる。プロキシサーバ３１２はまた、構成項目４１０にアクセスすることもできる。図４において、構成項目４１０は、クライアント装置３０２、サーバ装置３０４、ルータ３０６、及び仮想マシン３０８、その上で実行される任意のアプリケーション又はサービス、並びに、装置、アプリケーション、及びサービス間の関係の何れか又は全てを、指すことができる。従って、「構成項目」という用語は、任意の物理若しくは仮想装置、又は遠隔に発見可能な若しくは計算インスタンス３２２によって管理される任意のアプリケーション若しくはサービス、又は発見された装置、アプリケーション、及びサービス間の関係の、省略形とすることができる。構成項目は、計算インスタンス３２２の構成管理データベース（ＣＭＤＢ）内で表すことができる。

上記のように、ＶＰＮゲートウェイ４１２は、ＶＰＮゲートウェイ４０２Ａに専用ＶＰＮを提供することができる。そのようなＶＰＮは、管理対象ネットワーク３００と計算インスタンス３２２との間に著しい量のトラフィックがある場合、又はさもなくば、セキュリティポリシーがこれらのサイト間のＶＰＮの使用を示唆又は要求する場合に、有用とすることができる。いくつかの実施形態では、ＶＰＮを介して直接通信する管理対象ネットワーク３００及び／又は計算インスタンス３２２内の任意の装置には、パブリックＩＰアドレスが割り当てられる。管理対象ネットワーク３００及び／又は計算インスタンス３２２内の他の装置には、プライベートＩＰアドレス（例えば、それぞれサブネット１０．０．０．０／８及び１９２．１６８．０．０／１６と略記される１０．０．０．０〜１０．２５５．２５５．２５５又は１９２．１６８．０．０〜１９２．１６８．２５５．２５５の範囲から選択されるＩＰアドレス）を割り当てることができる。

ＩＶ．装置、アプリケーション、及びサービス発見の実施例
リモートネットワーク管理プラットフォーム３２０が管理対象ネットワーク３００の装置、アプリケーション、及びサービスを管理する場合には、リモートネットワーク管理プラットフォーム３２０は、まず始めに、管理対象ネットワーク３００内にどのような装置が存在するか、これらの装置の構成と動作状態、及びそれらの装置によって提供されるアプリケーションとサービス、並びに発見された装置、アプリケーション、及びサービス間の関係を決定することができる。上記のように、各装置、アプリケーション、サービス、及び関係は構成項目と呼ばれるようにすることができる。管理対象ネットワーク３００内の構成項目を定義するプロセスは、発見（discovery）と呼ばれ、プロキシサーバ３１２
によって少なくとも部分的に容易にされるようにすることができる。

本明細書の実施形態の目的のために、「アプリケーション」は、1つ以上のプロセス、
スレッド、プログラム、クライアントモジュール、サーバモジュール、又は装置若しくは装置のグループ上で実行される任意のその他のソフトウェアを指すことができる。「サー
ビス」は、互いに連携して動作する１つ以上の装置上で実行される複数のアプリケーションによって提供される高水準機能を指すことができる。例えば、高レベルＷｅｂサービスは、１つの装置上で実行され別の装置上で実行されているデータベースアプリケーションからの情報にアクセスする複数のＷｅｂアプリケーションサーバスレッドを含むようにすることができる。

図５Ａは、構成項目がどのように発見されることができるか、並びに、発見された構成項目に関連する情報がどのように記憶されるかの論理的な表現を提供する。簡単のために、リモートネットワーク管理プラットフォーム３２０、サードパーティネットワーク３４０、及びインターネット３５０は示されていない。

図５Ａにおいて、ＣＭＤＢ５００及びタスクリスト５０２は計算インスタンス３２２の内部に記憶されている。計算インスタンス３２２は、プロキシサーバ３１２に発見コマンドを送信することができる。これに応答して、プロキシサーバ３１２は、管理対象ネットワーク３００内の様々な装置、アプリケーション、及びサービスに、プローブ（精査）を送信することができる。これらの装置、アプリケーション、及びサービスは、プロキシサーバ３１２に応答を送信することができ、次いでプロキシサーバ３１２は、ＣＭＤＢ５００に、その中への記憶のために、発見された構成項目に関する情報を提供することができる。ＣＭＤＢ５００に記憶されている構成項目は、管理対象ネットワーク３００の環境を表す。

タスクリスト５０２は、プロキシサーバ３１２が計算インスタンス３２２に代わって実行するアクティビティのリストを表す。発見が行われると、タスクリスト５０２が設定される。プロキシサーバ３１２は、タスクリスト５０２を繰り返し照会して、その中の次のタスクを取得し、そして、タスクリスト５０２が空であるか又は別の停止条件に達するまでこのタスクを実行する。

発見を容易にするために、プロキシサーバ３１２は、プロキシサーバ３１２を経由して到達可能な管理対象ネットワーク３００内の１つ以上のサブネットに関する情報で構成されるようにすることができる。例えば、プロキシサーバ３１２は、サブネットとして１９２．１６８．０／２４のＩＰアドレス範囲を与えられてもよい。次に、計算インスタンス３２２は、この情報をＣＭＤＢ５００に記憶し、これらの各アドレスでの装置の発見のために、タスクリスト５０２にタスクを配置することができる。

図５Ａはまた、構成項目５０４、５０６、５０８、５１０、及び５１２として、管理対象ネットワーク３００内の装置、アプリケーション、及びサービスを示してもいる。上述したように、これらの構成項目は、物理及び／又は仮想装置（例えば、クライアント装置、サーバ装置、ルータ、又は仮想マシン）、それらの上で実行されるアプリケーション（例えば、ウェブサーバ、電子メールサーバ、データベース、またはストレージアレイ）、それらの間の関係、並びに、複数の個別の構成項目を含むサービスの、セットを表す。

タスクリスト５０２にタスクを配置することが、プロキシサーバ３１２にトリガーをかけて発見を開始するか、またはさもなくば、プロキシサーバ３１２に発見を開始させるようにすることができる。代替的又は追加的に、発見は、手動でトリガされてもよく、又はトリガイベントに基づいて自動的にトリガされてもよい（例えば、発見は特定の時間に１日１回自動的に開始されてもよい）。

一般に、発見は、スキャン、分類、識別、および探索という４つの論理的なフェーズで進行するようにすることができる。発見の各フェーズは、プロキシサーバ３１２によって管理対象ネットワーク３００内の１つ以上の装置に送信される様々な種類のプローブメッ
セージを含む。これらのプローブに対する応答は、プロキシサーバ３１２によって受信及び処理されるようにすることができ、それらの表示はＣＭＤＢ５００に送信されるようにすることができる。従って、各フェーズは、より多くの構成項目が発見されてＣＭＤＢ５００に記憶されることをもたらするようにすることができる。

スキャンフェーズでは、プロキシサーバ３１２は、オープン伝送制御プロトコル（ＴＣＰ）及び／又はユーザデータグラムプロトコル（ＵＤＰ）ポートについて、指定された範囲のＩＰアドレス内の各ＩＰアドレスを探索して、装置の一般的なタイプを判断する。ＩＰアドレスにそのようなオープンポートが存在することは、特定のアプリケーションがそのＩＰアドレスを割り当てられた装置上で動作していることを示すことができ、それは次にその装置によって使用されるオペレーティングシステムを識別することができる。例えば、ＴＣＰポート１３５が開いている場合、装置はＷＩＮＤＯＷＳ（米国登録商標）オペレーティングシステムを実行している可能性がある。同様に、ＴＣＰポート２２が開いている場合、装置はＬＩＮＵＸ（米国登録商標）などのＵＮＩＸ（米国登録商標）オペレーティングシステムを実行している可能性がある。ＵＤＰポート１６１が開いている場合、装置は簡易ネットワーク管理プロトコル（ＳＮＭＰ）を介して更に識別することができる可能性がある。他の可能性もある。ひとたび、特定のＩＰアドレスにある装置とそのオープンポートが発見（discover）されると、これらの構成項目はＣＭＤＢ５００に保存される。

分類フェーズでは、プロキシサーバ３１２は更に、発見された各装置をプローブ（精査）してそのオペレーティングシステムのバージョンを判断することができる。特定の装置に使用されるプローブは、スキャンフェーズでその装置について収集された情報に基づいている。例えば、ＴＣＰポート２２が開いている装置が見つかった場合は、ＵＮＩＸ（米国登録商標）固有のプローブのセットが使用されるようにすることができる。同様に、ＴＣＰポート１３５が開いている装置が見つかった場合は、ＷＩＮＤＯＷＳ（米国登録商標）固有のプローブのセットが使用されるようにすることができる。いずれの場合でも、プロキシサーバ３１２が実行するためのタスクの適切なセットがタスクリスト５０２に置かれるようにすることができる。これらのタスクは、プロキシサーバ３１２にログオンすること、又はそうでなければ特定の装置から情報にアクセスする結果をもたらするようにすることができる。例えば、ＴＣＰポート２２が開いていると、プロキシサーバ３１２は、特定の装置へのセキュアシェル（ＳＳＨ）接続を開始し、ファイルシステム内の特定の場所からその上のオペレーティングシステムに関する情報を取得するように指示されるようにすることができる。この情報に基づいて、オペレーティングシステムが決定されるようにすることができる。例として、ＴＣＰポート２２が開いているＵＮＩＸ（米国登録商標）装置は、ＡＩＸ（米国登録商標）、ＨＰＵＸ、ＬＩＮＵＸ（米国登録商標）、ＭＡＣＯＳ（米国登録商標）、又はＳＯＬＡＲＩＳ（米国登録商標）として分類されるようにすることができる。この分類情報は、ＣＭＤＢ５００内に１つ以上の構成項目として記憶されるようにすることができる。

識別フェーズにおいて、プロキシサーバ３１２は、分類された装置に関する特定の詳細を決定することができる。このフェーズの間で使用されるプローブは、分類フェーズで特定の装置について収集された情報に基づくようにすることができる。例えば、装置がＬＩＮＵＸ（米国登録商標）として分類された場合、ＬＩＮＵＸ（米国登録商標）特有のプローブのセットが使用されるようにすることができる。同様に、装置がＷＩＮＤＯＷＳ（米国登録商標）２０１２として分類されている場合は、ＷＩＮＤＯＷＳ（米国登録商標）２０１２固有のプローブのセットが使用されるようにすることができる。分類フェーズの場合と同様に、プロキシサーバ３１２が実行するためのタスクの適切なセットがタスクリスト５０２に置かれるようにすることができる。これらのタスクは、プロキシサーバ３１２が、基本入出力システム（ＢＩＯＳ）情報、シリアル番号、ネットワークインタフェース
情報、これらのネットワークインタフェースに割り当てられたメディアアクセス制御アドレス、その特定の装置で使用されているＩＰアドレスなどの情報を、その特定の装置から読み取る結果をもたらすことができる。この識別情報は、ＣＭＤＢ５００内に１つ以上の構成項目として記憶されるようにすることができる。

探査フェーズでは、プロキシサーバ３１２は、分類された装置の動作状態に関する詳細を決定することができる。このフェーズの間に使用されるプローブは、分類フェーズ及び／又は識別フェーズの間に特定の装置について収集された情報に基づくようにすることができる。再び、プロキシサーバ３１２が実行するためのタスクの適切なセットがタスクリスト５０２に置かれるようにすることができる。これらのタスクは、プロキシサーバ３１２が、プロセッサ情報、メモリ情報、実行中のプロセス（アプリケーション）のリストなどの追加の情報を、その特定の装置から読み取る結果をもたらすことができる。もう一度、発見された情報は、１つ以上の構成項目としてＣＭＤＢ５００に記憶されるようにすることができる。

ルータなどのネットワーク装置上で発見が実行されるときには、ＳＮＭＰを利用することができる。発見は、実行中のプロセスまたは他のアプリケーション関連情報のリストを決定する代わりに又はそれに加えて、ルータに認識されている追加サブネットと、ルータのネットワークインタフェースの動作状態(例えば、アクティブ、非アクティブ、キュー
の長さ、廃棄されたパケットの数など)を決定することができる。追加のサブネットのＩ
Ｐアドレスは、更なる発見手順の候補とすることができる。従って、発見は、反復的又は再帰的に進行するようにすることができる。

ひとたび発見が完了すると、それぞれの発見された装置、アプリケーション、及びサービスのスナップショット表現が、ＣＭＤＢ５００で利用可能である。例えば、発見の後に、管理対象ネットワーク３００内のクライアント装置、サーバ装置、及びルータのための、オペレーティングシステムのバージョン、ハードウェア構成及びネットワーク構成の詳細、並びに、それらの上で実行されているアプリケーションが、記憶されるようにすることができる。この収集された情報は、ユーザが装置のハードウェア構成及び動作状態、並びに複数の装置及びアプリケーションにわたるサービスの特性を見ることを可能にするために、様々な方法でユーザに提示されるようにすることができる。

更に、ＣＭＤＢ５００は、構成項目間の依存性及び関係についてのエントリを含むことができる。より具体的には、特定のサーバ装置上で実行されているアプリケーション、並びにこのアプリケーションに依存するサービスは、ＣＭＤＢ５００においてそのように表されるようにすることができる。例えば、データベースアプリケーションがサーバ装置上で実行されており、このデータベースアプリケーションが新入社員オンボーディングサービス並びに給与計算サービスによって使用されていると仮定する。従って、もしそのサーバ装置がメンテナンスのために運用から外された場合、従業員オンボーディングサービス及び給与計算サービスが影響を受けることは明らかである。同様に、構成項目間の依存性及び関係は、特定のルータに障害が発生したときに影響を受けるサービスを表現することができるようにすることができる。

一般的に、構成項目間の依存性及び関係は、ウェブベースのインタフェース上に表示され、階層的な形で表わされるようにすることができる。従って、そのような依存性及び関係を追加、変更、又は削除することは、このインタフェースによって達成されるようにすることができる。

更に、管理対象ネットワーク３００からのユーザは、特定の連携アクティビティが複数の発見された装置にわたって行われることを可能にするワークフローを開発することがで
きる。例えば、ＩＴワークフローは、ユーザが共通の管理者パスワードを発見された全てのＬＩＮＵＸ（米国登録商標）装置に対して１回の動作で変更することを可能にすることができるかもしれない。

発見が上述の方法で行われるようにするために、プロキシサーバ３１２、ＣＭＤＢ５００、及び／又は１つ以上の資格証明ストア（資格証明記憶機構）が、１つ以上の装置が発見されるようにするための資格証明を用いて設定されるようにすることができる。資格証明は、その装置にアクセスするために必要な任意の種類の情報を含むことができる。これらは、ユーザＩＤとパスワードの組、証明書などを含むことができる。いくつかの実施形態では、これらの資格証明は、ＣＭＤＢ５００の暗号化されたフィールドに記憶されるようにすることができる。プロキシサーバ３１２は、プロキシサーバ３１２がこれらの資格証明を使用して発見される装置にログオンしたりその他のアクセスを行うことができるように、資格証明の復号鍵を含むことができる。

発見処理は、図５Ｂのフローチャートとして示されている。ブロック５２０で、計算インスタンス内のタスクリストに、例えばＩＰアドレスの範囲が設定される。ブロック５２２で、スキャンフェーズが行われる。従って、プロキシサーバは、これらのＩＰアドレス群を使用して装置のＩＰアドレスをプローブし、これらの装置で実行されているオペレーティングシステムを特定しようとする。ブロック５２４で、分類フェーズが行われる。プロキシサーバは、発見された装置のオペレーティングシステムのバージョンを判断しようとする。ブロック５２６で、識別フェーズが行われる。プロキシサーバは、発見された装置のハードウェア構成及び／又はソフトウェア構成を特定しようとする。ブロック５２８で、探査フェーズが行われる。プロキシサーバは、発見された装置上で動作状態と実行中のアプリケーションを判断しようとする。ブロック５３０において、発見された装置及びアプリケーションを表す構成項目の更なる編集が行われるようにすることができる。この編集は本質的に自動化及び／又は手動とすることができる。

図５Ｂに示されるブロックは、実施例の目的のためのものである。発見は、より多くの又はより少ないフェーズを有することができる高度に構成可能な手順であるようにすることができ、各フェーズの動作は異なってもよい。場合によっては、１つ以上のフェーズをカスタマイズされるようにすることができ、或いはそうでなければ上記の例示的な説明から逸脱してもよい。

Ｖ.ウェブページのモデリング及び構築
Ａ.概要
上述のように、ソフトウェアアプリケーションは、企業内の個々の部門によって開発されるようにすることができる。このようなアプリケーションは、エンドユーザとの動的な対話を容易にするために、クライアント装置上で実行されるウェブブラウザによってレンダリングされる１つ以上のウェブページを含む、ウェブアプリケーションの形式を含めるか、または取ることができる。例えば、企業から遠隔でホストされているａＰａａＳシステムは、ウェブページをクライアントのブラウザに提供できる。ａＰａａＳシステム又は他のシステムとの対話を通じて、ソフトウェア開発者はそのようなウェブページを構成し、それらの構造及び動作を定義し、次いでシステムは検索及びレンダリングのためにウェブページを記憶することができる。

更に上述したように、そのような開発者は、ウェブページのコンポーネントを駆動させるために、基本論理に依存するフレームワークを使用することができるが、これらのフレームワークは廃止される可能性があり、その結果、ウェブページを書き換える必要性が生じる。

本明細書に開示されている代表的なシステムは、この及び他の問題を克服するのに役立ち、ウェブページの効率的なモデリングと構築を可能にする。

本システムは、動的ウェブページの機能を容易にするために、コンポーネント間のデータバインディングをサポートする再利用可能なカスタムのウェブコンポーネントを提供する。即ち、コンポーネントは、ページ上の他のコンポーネントによる参照のために（例えば、それらの状態変化に基づいて）アクションを発行し、そして、そのページ上の他のコンポーネントによって発行されたアクションに応答してそれら自身のプロパティを動的に設定するように構成可能である。

このような各コンポーネントは、コンポーネントの構造及び動作を定義し、ウェブ開発者による使用のためにＡＰＩを公開する、基本スクリプト（例えば、ＪａｖａＳｃｒｉｐｔ）を有している。従って、開発者は、そのようなコンポーネントの階層的な配置を定義し、それらのデータバインディングとその他の要求されたパラメータを定義する、単純なマークアップ（例えば、ＨＴＭＬ又はＸＭＬ）を宣言文的に構成することにより、ウェブアプリケーションを設計することができる。更に、コンポーネントのプロバイダは、基本スクリプトがそのコンポーネントの予想される構造及びＡＰＩをサポートする限り、そのコンポーネントを利用するウェブアプリケーションの書換えを必要とせずに、スクリプトのフレームワークが変更になるときに上記基本スクリプトを交換することができる。

そのシステムは、上述のａＰａａＳの説明で議論したように、サーバ又はサーバクラスタによって提供され得る。そのようなシステムは、カスタムのコンポーネントをサポートするように構成できる。本システムは、それぞれの基本スクリプトファイルを含む上記コンポーネントの定義を記憶することができ、かつリクエストに応じてクライアントのブラウザにそれらのコンポーネントの定義を提供するように構成することができる。従って、ウェブ開発者は、カスタムのコンポーネントのインスタンスの階層配置及びインスタンス間のデータバインディングを定義し、サーバ上のコンポーネント定義を参照するコンポーネントローダを含むマークアップドキュメントを作成できる。ブラウザがマークアップドキュメントをレンダリングするとき、ブラウザはコンポーネントローダに従ってシステムからカスタムのコンポーネント定義を取得し、使用するコンポーネントを登録することができる。コンポーネントの定義ごとに、ブラウザはその後マークアップをレンダリングすることができ、基本スクリプトに基づいてシャドウドキュメントオブジェクトモデル（ＤＯＭｓ）を事前設定し、それに応じて定義済みのコンポーネント間データバインディングを実装する。

実装例の実装では、本システムは更に、コンポーネントを使用するマークアップドキュメントの効率的な生成を容易にするため、そのようなサーバ上のデータベースモデルで表現されるべきコンポーネントを使って定義されたウェブページを可能にするページビルダサブシステムを含む。例えば、コンピューティング装置上で実行されているデータベースサーバアプリケーションは、データベースレコードのセットが協調的にウェブページを記述し、ページレイアウト、コンポーネント階層とデータバインディング、コンポーネントスクリプトへの参照、その他情報などを含み、様々なユニフォームリソースロケータ（ＵＲＬ）の各々をそのようなページ表現に関連付けるスキーマを使って、リレーショナルデータベース（例えば、上述したようなＳＱＬデータベースなど）を保守することができる。更に、コンピューティング装置上で実行されるウェブサーバアプリケーションは、ブラウザから特定のＵＲＬのページに対するリクエストを受信したときに、ウェブサーバアプリケーションはすぐに応答してデータベースに問い合わせて関連ページを協調的に記述するデータベースレコードを取得し、ウェブサーバアプリケーションはそのページ記述に従ってマークアップドキュメントを生成し、そして、ウェブサーバアプリケーションはその生成されたマークアップドキュメントをレンダリングのためにブラウザに送信するように
構成されるようにすることができる。

更に、ページビルダサブシステムは、ウェブ開発者がそのようなページをデザインすることを可能にするインタフェースを提供することができる。例えば、そのインタフェースは、ウェブ開発者に利用可能なカスタムのウェブコンポーネントのメニューを提供することができ、ウェブ開発者が、ページに含めるための所望のコンポーネントを選択し、所望の階層構造及び所望のデータバインディング及び他のパラメータを指定できるようにすることができる。ウェブ開発者がそのような選択及び指定を行うと、ページビルダサブシステムは、それに対応して、その後、デザインされたページを協調的に記述し、のちにそのページを表現するマークアップドキュメントを生成及び配信することを容易にするデータベースレコードを生成することができる。

Ｂ.実装の実施例
本システムは、ウェブページの構造が、そのページが表現されメタデータと相互に関連され付けられるようにして、宣言的に記述されるようにすることを可能にし、その結果、そのページ上のどのコンポーネントがレンダリングされるべきで、そしてそのコンポーネントがどのように構成されるべきかが、そのコンポーネントがどのように相互に通信するであろうかを含めて、確立される。そのようなシステムは、新しく有用な方法で互いに通信する可能性がある複雑な制御を有する非常に動的なウェブアプリケーションの効率的な開発を容易にすることができる。

本システムは、ＨＴＭＬの背後で構築され、様々なウェブページコンポーネントが相互に通信する方法を定義するＡＰＩであるため、本システムは、ウェブ開発者が、命令的に（命令文を用いて）ではなく宣言的に（宣言文を用いて）、ウェブページをデザインすることを可能にする。更に、上述したように、本システムによって定義されたコンポーネントは、パッケージ化され、表現され、メタデータとしてデータベースに記憶されるようにすることができ、この結果、本システムが、リクエストされたページの構造を容易に決定し、クライアントブラウザによるレンダリングのための関連するＨＴＭＬドキュメントを即座に生成し配信することを可能にする。

更に、本システムはより高レベルの宣言型ＡＰＩを提供するため、本システムは、ウェブ開発者にとってそれらのフレームワークを学習したりコーディングしたりする必要なく、様々な基本フレームワークの使用をサポートできる。上記より高レベルの宣言型ＡＰＩは、そのより高レベルの宣言を実装するための任意の様々な基本スクリプトやフレームワークを利用することができる。従って、この構成は、ウェブ開発者が特定のフレームワーク（ＡＮＧＵＬＡＲ又は類似のようなもの）を使用してウェブページを作成し、その後そのフレームワークが廃止され、開発者に新しいフレームワークを使用してページ全体を書き直すことを要求する、という共通の問題を克服するのに役立つことができる。本システムは、代わりに、ウェブ開発者が基本スクリプトに晒されることなく、（可能ならフロントエンド設計インタフェースを使用して）ウェブページを宣言的に構成することを可能にする。その結果、本システムのプロバイダは、ウェブコンポーネントの再利用を継続して可能にしながら、テクノロジの変更時など、必要に応じて基本スクリプトを交換することができる。

図６は、本システムを使用してレンダリングされたウェブページの一例である。図６に示すウェブページは様々なコンポーネントで構成されている。例えば、このページにはヘッダのコンポーネント、左側のリストのコンポーネント、通話統合のコンポーネント、チャットのコンポーネント、その他などが含まれる。

図７は、図６に示されるようなページを表現するＨＴＭＬドキュメントの一部を示すス
クリーンショットを図示している。上記議論と調和して、図７におけるマークアップは、比較的単純なＨＴＭＬを使用して宣言的なページを定義する。この実施例のＨＴＭＬには、最上位レベルの「ｓｎ−ｗｏｒｋｓｐａｃｅ−ｌａｙｏｕｔ」コンポーネントと、そのレイアウトコンポーネント内に「ｓｎ−ｗｏｒｋｓｐａｃｅ−ｈｅａｄｅｒ」コンポーネント、「ｓｎ−ｗｏｒｋｓｐａｃｅ−ｔｏｏｌｂａｒ」コンポーネント、「ｓｎ−ｗｏｒｋｓｐａｃｅ−ｎａｖ」コンポーネント、「ｓｎ−ｗｏｒｋｓｐａｃｅ−ｔａｂｓ」コンポーネント、「ｓｎ−ｗｏｒｋｓｐａｃｅ−ｍａｉｎ」コンポーネント、及び「ｓｎ−ｃｏｍｐｏｎｅｎｔ−ｏｐｅｎｆｒａｍｅ」コンポーネントが含まれ、これらの中には他のサブコンポーネントを更に含むものもある。

これらのコンポーネントはそれぞれ、様々な属性とプロパティを有している。例えば、各コンポーネントは、そのコンポーネントを一意に識別するｃｏｍｐｏｎｅｎｔ−ｉｄを有する。更に、コンポーネントは、そのコンポーネントのシャドウＤＯＭレイアウト内に、他のコンポーネントがその中にバインドされるようにすることができるスペースを定義する「ｓｌｏｔ」を含めることができる。また、コンポーネントは、１つ以上の他のコンポーネントによって発行されたアクションをリッスンする（注意して聞く）ための通信メカニズムを定義する「ｌｉｓｔｅｎ ｔｏ」プロパティを含めることができる。

例えば、「ｓｎ−ｗｏｒｋｓｐａｃｅ−ｈｅａｄｅｒ」コンポーネントの実施例は、「ｓｎ−ｃｏｍｐｏｎｅｎｔ−ｇｌｏｂａｌ−ｓｅａｒｃｈ−ｔｙｐｅｈｅａｄ」コンポーネント（そのグローバルに一意な識別子（ＧＵＩＤ）によって参照される）によって発行される「ＧＬＯＢＡＬ＿ＳＥＡＲＣＨ＿ＡＣＴＩＯＮ」をリッスンするように設定されている「ｌｉｓｔｅｎ ｔｏ」プロパティを含む。従って、実施例のページのヘッダコンポーネントは、そのページのｇｌｏｂａｌ−ｓｅａｒｃｈ−ｔｙｐｅｈｅａｄコンポーネントによって発行されたアクションをリッスンする。それ故、ｇｌｏｂａｌ−ｓｅａｒｃｈ−ｔｙｐｅｈｅａｄコンポーネントで何かが発生すると、ｇｌｏｂａｌ−ｓｅａｒｃｈ−ｔｙｐｅｈｅａｄコンポーネントは、その状態を示す又はその状態に対応するＧＬＯＢＡＬ_ＳＥＡＲＣＨ_ＡＣＴＩＯＮを発行することができ、そしてそのアクションは上記ヘッダコンポーネントの「ｓｅａｒｃｈＡｃｔｉｏｎ」プロパティにバインドされるようにすることができ、そのヘッダコンポーネントがそのｓｅａｒｃｈＡｃｔｉｏｎプロパティ値を設定し、及び／又は、呼応して１つ以上のアクションを実行することができる。

図７が示すように、このＨＴＭＬは開発者の観点からは比較的単純である。開発者は、ウェブページコンポーネント間の階層的関係並びにコンポーネント間のデータバインディングを定義するために示されるようにＨＴＭＬを書くことができる。代替的に又は追加的に、本システムは、開発者がそのようなコンポーネントを選択してページ上に配置し、それらの階層、データバインディング、及び他のパラメータを定義することができる、デザインインターフェースを提供することができる。

それぞれのそのようなコンポーネントは、任意の様々なスクリプト又はコーディング言語又は他のフレームワークを用いて事前に定義されるようにすることができ、その結果、そのコンポーネントの特定の構造又は機能性を確立し、そのコンポーネントがブラウザによるレンダリングのために所望のＨＴＭＬに変換されることができるようになる。ブラウザがそのようなページをレンダリングするとき、ブラウザは、上記のようにして、そのコンポーネントを定義するために使用されたそのフレームワークのためにプラグ接続可能なレンダラを呼び出すことによってそれぞれの上記のようなコンポーネントをレンダリングして、１つ以上のシャドウＤＯＭを事前設定し、そのブラウザがレンダリングするための関連するＨＴＭＬ要素を取得することができる。

これを容易にするために、そのウェブページは、カスタム要素、シャドウＤＯＭ、ＨＴ
ＭＬインポート、及びＨＴＭＬテンプレートを含むウェブコンポーネントを有するウェブコンポーネント標準を活用することができる。（カスタム要素は、カスタム要素ＡＰＩを使用して構築された新しく定義されたＨＴＭＬ要素、又はネイティブのＨＴＭＬ要素に基づいて構築することができ、シャドウＤＯＭは基本スクリプトを通してＤＯＭ要素を定義でき、そして、ＨＴＭＬインポート及びテンプレートはページまたはコンポーネントがレンダリングされるときに基本コンポーネントスクリプトを組み込むために使用されるようにすることができる。）

従って、図７の実施例では、ウェブページは、そのページに示される様々なカスタムのマークアップのためのブラウザへの宣言として、カスタム要素を定義することができる。例えば、コンポーネント名「ｓｎ−ｗｏｒｋｓｐａｃｅ−ｌａｙｏｕｔ」に対しては、そのページは、ブラウザに指定されたスクリプト（ＪａｖａＳｃｒｉｐｔスクリプトなど）であって、そしてそのスクリプトによって「ｓｎ−ｗｏｒｋｓｐａｃｅ−ｌａｙｏｕｔ」コンポーネントをレンダリングする方法をブラウザに伝えるものを添付するように指示するカスタム要素宣言を含むことができる。また、そのページは、他のカスタムマークアップのためのカスタム要素宣言もまた同様に含むことができる。

そのように指定された各スクリプトは、その名前、構成、及び挙動などのカスタム要素の態様を定義できる。例えば、上記スクリプトは、関連タグ名と、関連ＡＰＩを実装する関連ＪａｖａＳｃｒｉｐｔクラスとを、指定することができる。更に、上記スクリプトは、どの基本フレームワークがそのコンポーネントをレンダリングするために使用されるであろうかと、どのデータソースがそのコンポーネントによって使用されるであろうかと、そしてどの属性及びアクションがそのコンポーネントに対して定義されているかとを、指定することができる。そして、この基本コンポーネント論理の一部又は大部分はエンドユーザウェブ開発者からは隠されるが、その使用可能なアクション等のＡＰＩなどの特定の態様は、ウェブ開発においてそのコンポーネントの利用を容易にするために、ユーザに公開されるようにすることができる。

ページのマークアップは、そのページがレンダリングされる時に、カスタム要素の定義をロードするためのコンポーネントローダを含むことができる。例えば、このコンポーネントローダは、様々な利用可能なコンポーネントと符号するカスタム要素の定義の定義済みバンドルを、サーバデータ記憶装置から取得するためのＪａｖａＳｃｒｉｐｔ呼出しとすることができる。代表的な実装では、これらのカスタム要素の定義はノードパッケージマネージャ（ＮＰＭ）モジュールとして構築され、次いでレンダリング時にブラウザによる取得のためにバンドルに（例えば、小さな配布可能バンドルに、そして一緒に合併させられてより大きなバンドルに）一緒にパッケージされるようにすることができる。

そのような各カスタム要素は、ブラウザにおいてカスタム要素レジストリに登録されている可能性があるため、スタイル設定及び挙動が公開されることを防止するのに役立つカプセル化境界を提供するために、ブラウザに対してシャドウＤＯＭ内の各コンポーネントの内容をレンダリングするように指示することができる。（これは、開発者が他のコンポーネントに望ましくない方法で影響を与えるコンポーネントを作成するのを防ぎ、サードパーティのコンポーネント開発者がページを壊す可能性のあるコンポーネントを開発するのを防ぐのに役立つ。）

更に、そのようなコンポーネントは、ウェブ開発者がそのコンポーネントの基本スクリプトにさらされる必要なく、ウェブページを構築する際に、ウェブ開発者によって再利用されることができるようにすることができる。ウェブ開発者は、必要に応じて様々なコンポーネントの階層構造、データバインディング、及びその他のパラメータを簡単に宣言でき、そして、図７に示した実施例のように、それらの宣言は、そのコンポーネントのレン
ダリングを容易にするために使用されるであろう基本スクリプトを参照する必要はない。

図８は次に、ブラウザによって図７のＨＴＭＬを処理して確立されるようにすることができる、結果として得られるＨＴＭＬのページの詳細を示す。図８に示されるように、様々なページコンポーネントの実際の構造及び動作は、シャドウＤＯＭに記載されている。そして、シャドウＤＯＭのレンダリングは、システムがそのシャドウＤＯＭをレンダリングするために呼び出すどのレンダラーによっても制御されるようにすることができる。

この構成では、基本レンダラ（例えば、そのスクリプトをレンダリングするために使用される基本スクリプト及びフレームワーク）は、必要に応じてシステムのプロバイダによって交換されるようにすることができる。コンポーネント間のデータバインディングを確立するｌｉｓｔｅｎ−ｔｏ機能は、基本コンポーネントスクリプトの作成者に公開される可能性があるＡＰＩポイントを定義することができる。このように、コンポーネント間のやり取りを容易にするためにウェブ開発者に公開されるＡＰＩポイントを基本スクリプトがサポートする限り、たとえそれぞれの基本スクリプト技術が異なっても又は変更されても、ページ上のコンポーネントは相互に対話できる。このため、このことは、基本コンポーネントフレームワークがそのページのＤＯＭ階層構造に自分自身をバインドする必要性を、回避することができる。むしろ、そのフレームワークは、より一般的に、必要に応じてアクションにバインドされるようにすることができる。

上述したように、本システムは、ウェブページを開発するためのウェブ開発者による使用のために利用することができるようなコンポーネントのライブラリを提供することができ、また、利用可能なコンポーネントのメニューをウェブ開発者に提供することができる。上述したページビルダインタフェースの利用を通じて、又はより機械的な（rote）ＨＴＭＬプログラミングを通じて、ウェブ開発者は、上述のようにして必要なコンポーネントを選択することができ、コンポーネント定義に則して、上記コンポーネントの階層関係、必要なデータバインディング、及び１つ以上の他の特性を指定するウェブページを作成することができる。この処理で問題となるページコンポーネントは、ウェブコンポーネント標準に準拠したウェブコンポーネントであるようにすることができ、或いは、他の形式をとることもできる。

典型的な実装では例えば、ウェブページを設計する際におけるウェブ開発者による使用のために、本システムは、上述したようなページビルダサブシステムを含むことができる。ページビルダサブシステムは、確立されたウェブコンポーネントのメニューをウェブ開発者に提示し、ウェブ開発者が、ウェブページに含めるコンポーネントを選択し、選択されたコンポーネント間の階層関係を定義し、そしてコンポーネント間のデータバインディングを確立することを可能にするインターフェースを提供することができる。次に、ページビルダサブシステムは、そのページがリクエストされたときに関連付けられたＨＴＭＬドキュメントの効率的な生成を可能にするために、上述したように、関連付けられたページ記述をメタデータとしてデータベーステーブルに記憶することができる。（或いは、ウェブ開発者は、そのようなページビルダシステムを使用せずに、そのＨＴＭＬをより直接的に記述してもよいかもしれない。）

図９〜図１１は、ウェブ開発者が代表的なウェブコンポーネントのパラメータを設定するために使用するかもしれないようなページビルダインタフェースの実施例の一部を示し、ここでは「タブ」コンポーネントの例を示している。「画面表示通り出力される」（ウィジウィグ）インタフェースを含む代替のデザインインタフェースが、代わりに又は追加して提供されるようにすることができる。

図９に示されるように、ページビルダインタフェースは、データメニュー及びデータタ
ブ設定の属性（ＣｏｍｐｏｎｅｎｔＡｔｔｒｉｂｕｔｅｓタブからアクセス可能）を指定し、それは、メニュー及びタブがどのようにレンダリングされるかを記述するペイロードを取る。更に、図１０に示されるように、上記インタフェースは、ウェブ開発者が静的に設定することができ又はそのコンポーネントに対して定義されているｌｉｓｔｅｎ−ｔｏ機能を用いて動的に設定されるように構成されるようにすることができるプロパティ（Ｃｏｍｐｏｎｅｎｔ Ｐｒｏｐｅｒｔｉｅｓタブからアクセス可能）を指定する。

更に、図１１に示されるように、上記インタフェースは、アクションをリッスンするように設定されている他のコンポーネントによる受信のために上記コンポーネントが発行又は発する情報を定義する様々なアクション（Ｃｏｍｐｏｎｅｎｔ Ａｃｔｉｏｎｓタブからアクセス可能）を指定する。例えば、本実施例は、ＴＡＢ_ＳＥＬＥＣＴＥＤアクショ
ンを示しており、これはユーザがタブをクリックしたときに呼び出され、コンポーネントにＴＡＢ_ＳＥＬＥＣＴＥＤアクションを発行させるであろうアクションとされるように
することができる。実際には、そのウェブページ上の別のコンポーネントは次に、Ｔａｂｓコンポーネントのそのアクションをリッスンし、関連するプロパティ値を設定することによってそのアクションに応答するように、設定されるようにして、そのアクションを取るなどすることができる。

そのようなページビルダインタフェースなどを使用することにより、ウェブ開発者は、ページに含まれるように（例えば、利用可能なコンポーネントのメニューから）ウェブコンポーネントを選択し、そのコンポーネントの階層的配置を（例えば機械的配置又はコンポーネントの親子関係の他の指定により）指示し、コンポーネント間のデータバインディングを（例えば、コンポーネントのｌｉｓｔｅｎ−ｔｏプロパティの宣言により）確立し、そして、コンポーネントの１つ以上の他のパラメータを設定することにより、ウェブページを開発することができる。ページビルダインタフェースは基本的に、ウェブ開発者がそのようなパラメータを設定することを可能にするために、そのような各コンポーネントの利用可能なＡＰＩポイントをウェブ開発者に、公開することができる。

実施例として、ウェブ開発者がウェブページをデザインするときに、ウェブ開発者は、上述のＴａｂｓコンポーネントを選択し、上記ページのＴａｂｓコンポーネントの特定の階層構造及び配置を宣言し、任意の静的属性値を宣言し、そして、上記ページ上の１つ以上の他のコンポーネントのアクションに基づいて実行時に動的に設定されるようにすることができる任意のｌｉｓｔｅｎ−ｔｏプロパティを宣言することができるかもしれない。（例えば、ページビルダインタフェースを介して、開発者はｓｅｌｅｃｔｅｄＩｔｅｍ、ｄａｔａ−ｍｅｎｕ、及びＴａｂｓコンポーネントのインスタンスの他の態様を定義することができる。）

上述の議論に沿って、ページビルダサブシステムは、（例えば、記憶されたコンポーネント定義を通じて）、各コンポーネントを、そのコンポーネントの詳細を定義する特定のＪａｖａＳｃｒｉｐｔファイルなどの基本スクリプトと、関連付けることができる。ページビルダサブシステムがブラウザに配信のために結果として得られるＨＴＭＬドキュメントを出力するとき、ページビルダサブシステムはまたコンポーネントのカスタム要素の定義をブラウザに配信することができ、そして同時に、ブラウザにそのコンポーネントをどのようにレンダリングするかを定義するＪａｖａＳｃｒｉｐｔファイルを配信することもできる。この構成により、ウェブ開発者は単にページ上のコンポーネントのインスタンスを宣言するだけでよく、そして、本システムは即座に応答して、カスタム要素の使用及び従ってコンポーネントの使用を容易にするカスタム要素のスクリプト及び関連するマークアップを提供することによって、コンポーネントのレンダリングを可能にすることができる。

更に上述したように、本システムがページリクエストに容易に応答できるようにするために、本システムは、リレーショナルデータベースのテーブルとして、ウェブコンポーネントベースのページの記述を記憶するように構成されるようにすることができる。例えば、ページビルダサブシステムは、ウェブ開発者がそのようなページをデザインすることができるインタフェースを提供することができ、ウェブ開発者がそのページをデザイン（例えば、コンポーネントの選択と配置、それらの階層の定義、データバインディングなど）する際に、ページビルダサブシステムは、協調的にページを記述するデータベースレコードを生成し格納することができる。

図１２及び図１３は、データベーススキーマの実施例を示しており、ページビルダサブシステムが、複数の相互に関係するレコードを定義する相互に関係するデータベーステーブルのグループを使用して、ウェブページをどのように表現できるかを示している。図示のスキーマでは、特定のページの定義に関連するテーブルは接頭辞「ｓｙｓ_ｕｘ_ｐａｇｅ」でラベル付けされ、ページ構築ブロックのライブラリに関連するテーブルは接頭辞「ｓｙｓ_ｕｘ_ｌｉｂ」でラベル付けされている。

図１２の左側に示されているものは、ページのルート要素を確立するため、及び１つ以上のＵＲＬ等をページのオーダーメイドの構成に関連付けるための、ページ登録の実施例を記述することに関わるテーブルである。そして、図１２の右側に示されているものは、ページのコンポーネントの階層的配置を協調的に定義する複数の相互に関係するレコードであって、コンポーネントの構造及び動作を解釈実行可能に定義するための基本スクリプトへの参照を含むものを通して、ページ構造を記述することに関わるテーブルである。

表示される配置例では、「ｓｙｓ＿ｕｘ＿ｐａｇｅ」はコンテナレコードとして機能し、ページ構造内のルート要素を指している。次に、「ｓｙｓ_ｕｘ_ｐａｇｅ_ｒｅｇｉｓ
ｔｒｙ」は、ページレコード（構造体）を、ＵＲＬパス／サイト名及びオーダーメイドの構成レコードと関連付ける。図１２は、実施例として、このことを「ａｄｍｉｎ＿ｐａｎｅｌ」データベースレコードの実施例に符号するドキュメントフィールドとして示している。しかし、そのページは、他のＵＲＬやパスに関連付けられるように登録されるようにすることができても差し支えない。

より一般的には、本システムは、ＵＲＬに対する関連するウェブページ構成を確立するために、それぞれ各ｓｙｓ_ｕｘ_ｐａｇｅレコードにデータベース上で関連付けられたＵＲＬ又は他のパスを登録することができ、そして、各ＵＲＬ登録レコードは、それに関連付けられ、ｓｙｓ_ｕｘ_ｐａｇｅレコードによって指定されそのｓｙｓ_ｕｘ_ｐａｇｅレコードに固有のオーダーメイドのスキーマに準拠した、設定レコードを有することができる。これにより、複数のＵＲＬが、与えられた1つのウェブページの構造／設定を利用す
ることが可能になり、それらのＵＲＬに関連するそれらの基本となる各構成データに関してそれぞれ互いに異なるページがあることになる。

そして、（ｓｙｓ_ｕｘ_ｐａｇｅテーブルの）各ルート要素ウェブページは、ページ要素（ｓｙｓ_ｕｘ_ｐａｇｅ_ｅｌｅｍｅｎｔレコード）の階層と、データベースのリレー
ションシップ（関係）を有する。各ページ要素は参照フィールドを介してその親要素を指し示し、それによって構造的階層を表し、その結果、データベースクエリは所与の要素の子である各要素を容易に見つけることができ、従って効率的な検索が可能になって、そのページの完全なツリー表現を確立する。このようにして、上記リレーショナルデータベースレコードは、そのページのＤＯＭツリー表現を協調的に記述する。

更に、各ページ要素は、コンポーネントノードのインスタンスであり、基本ソースファイル、タグ名、スロット、属性、及び階層構造内の他のノードとの通信を可能にするアク
ション（イベント）を指定する。例えば、各コンポーネントは、シャドウＤＯＭ内で子コンポーネントを関連付けることができる１つ以上のスロットを指定することができる。そして、各コンポーネントは１つ以上の属性と１つ以上のプロパティを指定することができる。

より具体的には、図示の実施例では、各ページ要素レコードはコンポーネント定義レコード（「ｓｙｓ_ｕｘ_ｌｉｂ_ｃｏｍｐｏｎｅｎｔ」）への参照を含み、今度はコンポー
ネント定義レコードはその基本スクリプトソースファイル並びにプロパティ及びコンポーネントの他の態様を定義するためのフィールドへの参照を含む。各ページ要素レコードは、１つ以上の属性レコードを参照することによって、様々な属性を含むことができる。更に、コンポーネントはその内部構造を明示するためにシャドウＤＯＭを使用することができるので、コンポーネント定義は、子要素がシャドウＤＯＭ内のどこでレンダリングされるべきかを指し示すことを助けるためのスロットのセットを、指定することができる。ページ要素が作成されてページ構造に配置されると、システムはそのページ要素に、スロット定義レコードを参照するスロットフィールド（「ｓｙｓ_ｕｘ_ｌｉｂ_ｃｏｍｐ_ｓｌｏｔ」）として、それがバインドされるべきその親コンポーネントの定義のスロットへの参照を記録することができる。

図１３は次に、ページビルダサブシステムが、複数の相互に関連するデータベースレコードを用いて、様々なコンポーネント対コンポーネントのデータバインディングをどのように表現できるかを示している。上述のように、各コンポーネントの基本定義は、それが発行するアクションを定義するＡＰＩを指定することができる。これらのアクションは、コンポーネント間の通信を容易にするためにフロントエンドフレームワークによって送り渡されるであろうデータコンテナである。図８では、これらのアクションは「ｓｙｓ_ｕ
ｘ_ｌｉｂ_ｃｏｍｐｏｎｅｎｔ_ａｃｔｉｏｎ」レコードによって定義される。

コンポーネントインスタンスが（「ｓｙｓ_ｕｘ_ｐａｇｅ_ｅｌｅｍｅｎｔ」レコード
として）ページに配置されると、ページビルダサブシステムは、そのコンポーネントのアクションを（コンポーネント定義毎に）、他のコンポーネントにとってリッスンすることができるアクションとして、そのアクションを「ｓｙｓ_ｕｘ_ｐａｇｅ_ａｃｔｉｏｎ」
レコードに記録することによって、ページアクションのカタログに追加することができる。更に、ページ上の各コンポーネントは、ページビルダサブシステムがｓｙｓ_ｕｘ_ｌｉｂ_ｃｏｍｐ_ｐｒｏｐレコードで表現することができる、コンポーネントプロパティを有することができる。ウェブ開発者が申込み元のコンポーネントと発行されたアクションの間のバインディングを指定すると、ページビルダのサブシステムはその後、（ｓｙｓ_ｕ
ｘ_ｐａｇｅ_ａｃｔｉｏｎテーブルへの参照によって）そのアクションと、（ｓｙｓ_ｕ
ｘ_ｐａｇｅ_ｅｌｅｍｅｎｔテーブルへの参照によって）その申込み元の要素と、（ｓｙｓ_ｕｘ_ｐａｇｅ_ｅｌｅｍｅｎｔテーブルへの参照によって）その発行要素と、そして
、（ｓｙｓ_ｕｘ_ｌｉｂ_ｃｏｍｐ_ｐｒｏｐテーブルへの参照によって）その申込み元の要素の対象プロパティと、を指定するそのバインディングを、「ｓｙｓ_ｕｘ_ｐａｇｅ_
ａｃｔｉｏｎ_ｂｉｎｄｉｎｇ」レコードに記録することができる。

このデータベーススキーマの実施例では、ページビルダインタフェースは、ページに配置するコンポーネントを選択するウェブ開発者入力を受け取ることができ、そして、コンポーネントが発行できるアクションを定義するコンポーネントのＡＰＩのメニューをウェブ開発者に提供することができる。更に、上記インタフェースはその後、そのようなアクションのいずれがそのページ空間に利用可能とされてそのページの他のコンポーネントにとって申し込めるようにすべきかを指定する、ウェブ開発者入力を受信することができる。そして、上記インタフェースは、そのページに他のコンポーネントを追加し、そしてそれと発行元コンポーネントとの間のデータバインディングのアクションを確立する、追加
のウェブ開発者入力を受信することができる。ページビルダサブシステムはそれで即座に応答して、申し込まれたアクションと、申込み元のコンポーネントと、発行元／発信元コンポーネントと、（もしページ上の複数のコンポーネントが指し示されたアクションを発行できるであろう場合には、或いはワイルドカードと、）を指定して、上述のようにこのコンポーネント間のデータバインディングをテーブルに記憶することができる。

上述の説明に沿って、このデータベーススキーマは、ウェブコンポーネントの再利用を可能にし、コンポーネント間の動的データバインディングを確立して、ウェブページの効率的なレンダリングを容易にすることができる。

システムがブラウザからＵＲＬやサイト名で指定されたウェブページのリクエストを受信すると、上記システムは様々なホストプロバイダの拡張機能を照会することができ、それにより、（例えば、そのＵＲＬが特定のｓｙｓ＿ｕｘ＿ｐａｇｅに登録されているということを見付けることによって）そのリクエストがページビルダサブシステムに属するということを決定し、そして上記システムはそのためにそのリクエストをページビルダサブシステムにハンドリングのためにルーティングすることができる。ページビルダサブシステムのホストプロバイダはそれで、ＵＸ（ユーザエクスペリエンス）ページリクエストを組み立て、そのリクエストをＵＸページプロセッサクラスに渡すことができる。これにより次に、マークアップを作成し、そのマークアップをリクエストを出しているクライアント／ブラウザにレンダリングのために送信することができる。

即ち、ＵＸページリクエストを受信すると、ＵＸページプロセッサを実装するサーバは、上述したように、ページのツリー表現を構築するためのデータベースクエリを容易に実行することができ、その後、そのツリー表現をＨＴＭＬマークアップに変換することができる。更に、サーバは、そのマークアップを、カスタムのコンポーネントのレンダリングを容易にするためのコンポーネントローダを含む他の適用可能なコンテンツと共に、ＨＴＭＬドキュメント内に含めることができる。そして、サーバは、そのページをレンダリングする際におけるブラウザによる使用のための参照スクリプトファイルを、バンドルすることができる。サーバはそれで、レンダリングのために、ブラウザに応答を配信して、おそらく基本スクリプトファイルと共にブラウザにＨＴＭＬドキュメントを提供することができる。

図１４は、実施例としての、「Ｗｏｒｋｓｐａｃｅ」サイトの例のページに対するこの処理フローを示す。図示の構成では、実施例として、様々なクラスがＪａｖａクラスとされるようにすることができる。ＵＸＰａｇｅＨｏｓｔＰｒｏｖｉｄｅｒクラスは、所与のサイト名のリクエストがページビルダサブシステムで処理されるべきか否かを判定し、サイト名をページレコード（構造）及びオプションの設定レコードに関連付けるエントリのキャッシュを管理することを担当する。示されているように、そのリクエストが「Ｗｏｒｋｓｐａｃｅ」サイトのページに対するものであると判定すると、ＵＸＰａｇｅＨｏｓｔＰｒｏｖｉｄｅｒは、ＵＸＰａｇｅＰｒｏｃｅｓｓｏｒクラスによって実行されるＵｘＰａｇｅＲｅｑｕｅｓｔを生成する。このリクエストに応答して、ＵｘＰａｇｅＰｒｏｃｅｓｓｏｒクラスは次に、リクエストしているクライアントに応答して、様々な他のクラスを利用して、配信用の関連ＨＴＭＬドキュメントを生成することができる。更に、ＵＸＰａｇｅＰｒｏｃｅｓｓｏｒは、ページ上のコンポーネントを駆動するためにどのＪａｖａＳｃｒｉｐｔソースファイルが必要かを判定し、必要に応じてソースコードをバンドルし、上記ＨＴＭＬドキュメントに関連するリソースタグを提供することを担当する。

例示的な実施形態では、ＵｘＰａｇｅＰｒｏｃｅｓｓｏｒクラスを実行しているサーバは、データベースに問い合わせてページのコンポーネントの階層的配置を表現するコンポーネントツリー構造を確認し、そして上記ページの上記コンポーネント間のデータバイン
ディングを確認することができる。例えば、ページのルート要素から開始して、サーバは親フィールドに基づいてデータベースに反復的又は再帰的に問い合わせてページのコンポーネント階層構造を決定することができ、その問合せ結果をページのコンポーネントツリー構造を協調的に定義するＪａｖａデータオブジェクトに記憶することができる。更に、サーバは、データベースに照会して、上記ページの上記コンポーネント間に定義されている任意のデータバインディングを決定することができ、そして、これらのデータバインディングの詳細を、おそらくコンポーネントのツリー構造を定義するＪａｖａデータオブジェクトに記憶することができる。

このようにしてページのコンポーネントツリー構造とデータバインディングを確認したら、サーバは次に、その確認されたコンポーネントツリー構造及びデータバインディングを表現し、基本スクリプトを動作するようにロードするためのコンポーネントローダを含むマークアップドキュメントを構築することができる。例えば、サーバは、スロットやｌｉｓｔｅｎ−ｔｏプロパティなどの特性と共にページコンポーネントの階層宣言を含む、前述の図７に示されるようなマークアップドキュメントを構築することができる。そして、ページのそれぞれのコンポーネントごとの基本スクリプトのデータベース表示に基づいて、サーバは、それらのスクリプトを動作するようにロードするための（例えば、スクリプトをコンピューティング装置によって解釈実行可能なようにロードするための）コンポーネントローダ宣言をマークアップドキュメントに含めることができる。サーバは次に、この構築されたマークアップドキュメントを、リクエストしているウェブブラウザによるレンダリングのために、出力することができる。例えば、サーバは、マークアップドキュメントをブラウザに送信することができる。

マークアップドキュメントを受信すると、ブラウザは次に、コンポーネントローダを実行して、サーバデータ記憶装置からコンポーネントの構造及び動作を定義する基本スクリプトを取得することができる。ブラウザはこのようにしてページの完全なＤＯＭを構築し、そのページをレンダリングすることができる。

実際には、もし代表的なシステムが（例えば、ａＰａａＳアーキテクチャにおいて）多くのクライアントを提供する場合、そのシステムは、ウェブページに対するクライアントの要求に応答して、データベースの大規模なリアルタイムの問合せを行う場合がある。結果として生じるネットワークと処理の負担を管理するのを助けるために、システムはこれらの問合せの特定の結果をキャッシュし、同じページに対する後のリクエストに対して効率的に応答することを容易にするようにすることができる。例えば、システムがページのコンポーネントツリー構造及びデータバインディングをひとたび確認すると、そのシステムは、おそらく定義されたキャッシュ期間の間、そのツリー構造及びデータバインディングを表すＪａｖａデータオブジェクトをデータ記憶装置にキャッシュすることができる。この方法では、システムが後で同じページに対するリクエストを受信すると、システムはデータ記憶装置から以前に確認されたツリー構造及びデータバインディングを容易に取得でき、リクエストしているクライアントによる出力及びレンダリングのために関連マークアップドキュメントを容易に構築することができる。

上記のように、ウェブ開発者はウェブコンポーネントの基本となる内部コード又はスクリプトにアクセスを持つ必要がないため（実際にそうではないようにすることができるため）、このシステムのプロバイダは、基本ロジックがコンポーネントの高水準なコンポーネントの定義及びコンポーネント間の通信モデルのＡＰＩを依然としてサポートする限り、もし望むならおそらく最新のスクリプト言語又は他のフレームワークを使用するように切り替えて、基本コード又はスクリプトをほとんど透過的に交換できる。プロバイダは単にバックエンドスクリプトを修正する必要があるだけなので、これにより、システムプロバイダは、ウェブページ、そして場合によっては非常に複雑なウェブアプリケーションを
書き換える必要なく、最新のテクノロジを常に利用することができるようになる。その結果、本システムを使用するウェブ開発者は、たとえ基本スクリプトの技術が変わっても、将来でも彼らのウェブページに信頼を置いて使用可能にするようにすることができる。これは、ウェブページ自体がフレームワークを使用して作成され、その後廃止され、ウェブページ全体を完全に書き直す必要があるという処理とは対照的である。

更に、他のウェブ開発フレームワークが動作することができる方法とは対照的に、本システムの代表的な実装は、どのようなアプリケーションレベルのコントローラ又はブートストラップも含む必要はない。ウェブ開発者は、ページにタグを付けたり、必要な属性を指定したりなどすることで、個々のコンポーネントを単に取り込むにすぎないようにすることができる。本システムは最終的に個々のコンポーネントに合わせられる（必要に応じて、追加又は削除すること、及び相互に関連付けることができる）ようになっているため、ウェブ開発者はフレームワークがどのようにブートストラップし又は振る舞うかを定義することに関係する必要はない。

更に、本システムはウェブコンポーネントの標準をうまく利用して新しいウェブコンポーネントを定義するため、本システムは、ページ上のコンポーネントに対して、有用な方法で相互に対話するための機能を提供する。即ち、上述したｌｉｓｔｅｎ−ｔｏ機能により、ウェブ開発者はページ上のコンポーネントを（例えば、兄弟関係にあるコンポーネントでさえも）互いに対話させることが可能になる。例えば、２つのカスタムデザインされたコンポーネントは、ウェブ開発者が１つのコンポーネントからのデータ出力をどう処理するか又はそれをどのように組み込んだり使用したりするか或いはそうでなければ他のコンポーネントに影響を与えるかを定義するＪａｖａＳｃｒｉｐｔコードを書く必要なく、構造化された方法で互いにメッセージを交換できる。従って、このシステムによって、ウェブ開発者は基本コードを書く必要なしに、動的ウェブページを開発することができる。

例えば、ページのデザイン目標が、左側にリストを置き、右側に詳細フォームを置くという、単純な実施例を考える。

本システムがなければ、開発者は、リストウィジットを提供するためにいくつかのＪａｖａＳｃｒｉｐｔを書くかもしれず、フォームウィジェットを提供するためにいくつかのＪａｖａＳｃｒｉｐｔを書くかもしれず、そして、開発者は、フォームコントロールが更新されてそのリスト内でユーザが何をクリックしたかを表示するために、リストウィジェット上でアクション「ｉｔｅｍ−ｃｌｉｃｋｅｄ」をリッスンするいくつかのＪａｖａＳｃｒｉｐｔコードを更に書くかもしれず、そのアクションを見たときに右側のフォームにいくつかのコンテンツを書くかもしれない。従って、このプロセスは、いくつかのＪａｖａＳｃｒｉｐｔコードの書込みと、おそらくブートストラップ処理などを必要とする。

一方、本システムを用いた場合、ウェブ開発者の処理は、どのような命令的スクリプトにも関与する必要なく、完全に宣言的とすることができる。ウェブ開発者は、単純に、リストコンポーネントとフォームコンポーネントの宣言を含め、フォームコンポーネントにリストコンポーネントのｉｔｅｍ−ｓｅｌｅｃｔｅｄ（項目選択）アクションをリッスンさせるｌｉｓｔｅｎ−ｔｏタグをフォームコンポーネントに提供するようにすることができる。フォームコンポーネントの基本スクリプトはそれで、必要に応じてそのフィールドにデータを設定することを引き受けるようにすることができる。

Ｃ.システムの実施例
図１５は、本開示に従って動作可能なシステムを示す簡略化したブロック図である。上記のように、このシステムは、上述のａＰａａＳの場合のように、サーバ又はサーバクラスタによって実装することができる。図１５に示されるように、本システムは、データベ
ース１５００とウェブサーバアプリケーション１５０２とを含み、これらはネットワーク又は他の接続機構１５０４によって統合され又は相互接続されるようにすることができる。

図１５の実施形態は、そこに示されている特徴のうちの任意の１つ以上の除去によって簡略化することができる。更に、これらの実施形態は、これまでの任意の図の特徴、態様、及び／又は実装、又はさもなければ本明細書における説明と、組み合わせられるようにすることができる。

図示のように、データベース１５００は、ウェブページのコンポーネントの階層的配置を協調的に定義する複数の相互に関係するレコード１５０６であって、上記ウェブページのコンポーネントの構造及び動作を解釈実行可能に定義するための基本スクリプトへの参照を含むものと、上記ウェブページのコンポーネント間のデータバインディングを協調的に定義する複数の相互に関係するレコード１５０７と、を含む。

ウェブサーバアプリケーション１５０２は、コンピューティング装置上で実行され、様々なウェブサーバの動作を実行するように（例えば、コンピューティング装置に動作を実行させるように）構成されている。例えば、ウェブサーバアプリケーションは、クライアント装置からウェブページのためのリクエストを受信するように構成されている。そして、ウェブサーバアプリケーションは、（ｉ）データベースに問い合わせてウェブページのコンポーネントの階層的配置を表現するコンポーネントツリー構造を確認し、そして上記ウェブページのコンポーネント間のデータバインディングを確認し、（ｉｉ）その確認されたコンポーネントツリー構造及びデータバインディングに基づいて、その確認されたコンポーネントツリー構造及びデータバインディングを表現し、基本スクリプトを動作するようにロードするためのコンポーネントローダを含むマークアップドキュメントを構築し、そして、（ｉｉｉ）その構築されたマークアップドキュメントをクライアント装置上で実行されるウェブブラウザによるレンダリングのために出力する、ことによって、そのリクエストに応答するように構成される。

上述の説明に沿って、ウェブサーバアプリケーションは更に、ウェブページの構造及び動作を宣言するユーザ入力であって、上記ウェブページのコンポーネントの階層的配置と、上記ウェブページのコンポーネント間のデータバインディングの宣言を含むものを受信するように構成されようにすることができる。そして、ウェブサーバアプリケーションは、前述の問合せ及び構築を容易にするために、上記ウェブページのコンポーネントの階層的配置を協調的に定義する前述した複数の相互に関係するレコードと、上記ウェブページのコンポーネント間のデータバインディングを協調的に定義する前述した複数の相互に関係するレコードとを生成して、上記データベースの複数のテーブルに協調的に記憶する、ことにより、上記ユーザ入力に応答するように構成されるようにすることができる。

更に、ウェブサーバアプリケーションは、そこを通してウェブページの構造及び動作を宣言するユーザ入力を受信するためのユーザインタフェースを提供するように、構成されるようにすることができる。例えば、そのユーザインタフェースは、コンポーネントのメニューを定義することができ、コンポーネントのメニューから、ウェブページに含まれるべきコンポーネントのユーザ選択、及びコンポーネント間の階層構造及びデータバインディングのユーザ指定を可能にすることができる。代表的な実施形態では、コンポーネントの構造及び動作を解釈実行可能に定義するための基本スクリプトを含む各コンポーネントは、ユーザ入力を受信する前に定義されるようにすることができる。この配置により、基本スクリプトはコンポーネントのＡＰＩを公開することができ、そして、前述の宣言は公開されたＡＰＩを利用することができる。更に、基本スクリプトは、公開されたＡＰＩを維持しながらスワップ可能にすることができる。

また、上述の説明に沿って、データベースの前述した相互に関係するレコードは、ルート要素レコード、複数のページ要素レコード、複数のコンポーネントレコード、及び複数のデータバインディングレコードを含むことができる。上記ルート要素レコードは、上記ウェブページのトップレベルを定義することができる。上記複数のページ要素レコードは、上記ウェブページのコンポーネントのコンポーネントツリー構造を協調的に定義し、各ページ要素レコードは、コンポーネントレコードのそれぞれ１つを参照するコンポーネント参照を含み、及びツリー構造の関連する親ノードを参照する親参照を含むことができる。

各コンポーネントレコードは、上記ウェブページのそれぞれのコンポーネントを定義することができ、及びウェブブラウザにより解釈実行可能にコンポーネントの構造及び動作を定義するための関連する基本スクリプトを参照するスクリプト参照を含むことができる。上述のデータバインディングレコードは、（ｉ）コンポーネントの状態変化に基づいて上記ウェブページの特定のコンポーネントによって発行されるアクションと、（ｉｉ）上記ウェブページの他のコンポーネントのプロパティとの間のデータバインディングを定義することができる。

このような配置により、データベースに問い合わせて上記ウェブページのコンポーネントの階層的配置を定義するコンポーネントツリー構造を確認する振舞いは、上記データベースに問い合わせて上記ウェブページのルート要素レコードを識別し、そして、ページ要素レコード内の親参照に基づいて上記データベースに再帰的に問い合せ、その結果、上記ウェブページのコンポーネントの階層的配置を定義する上記コンポーネントツリー構造を確立することを含むようにすることができる。

更に、図１３に示すように、データバインディングレコードは、（ｉ）上記ウェブページのコンポーネントによって発行されるべきアクションを定義するアクションレコードと、（ｉｉ）上記ウェブページのコンポーネントのプロパティを定義するプロパティレコードと、（ｉｉｉ）上記アクションレコードによって定義されるアクションと上記プロパティレコードによって定義されるプロパティとの間のデータバインディングを定義するアクションバインディングレコードと、を含むようにすることができる。この配置により、上記データベースに問い合わせて上記ウェブページのコンポーネント間のデータバインディングを確認する振舞いは、前述のアクションバインディングレコードに問い合わせて定義されたデータバインディングを決定することを含むようにすることができる。

加えて、確認されたコンポーネントツリー構造及びデータバインディングを表すマークアップドキュメントを構築する振舞いは、上記確認されたコンポーネントツリー構造に対応する宣言の階層的セットを含み、及び上記確認されたデータバインディングを定義する関連タグを含むように、上記マークアップドキュメントを構造化することを含むようにすることができる。更に、基本スクリプトを動作するようにロードするためのコンポーネントローダを含むマークアップドキュメントを構築する振舞いは、コンポーネントレコードのスクリプト参照から、解釈実行可能に上記ウェブページのコンポーネントの構造及び動作を定義する基本スクリプトを確認し、そして、上記コンポーネントローダにその確認された基本スクリプトを参照させるように、マークアップドキュメントを構造化する、ことを含むようにすることができる。

加えて、上述したように、本システムは、確認されたコンポーネントツリー構造及びデータバインディングを、効率化のためにキャッシュすることができる。例えば、ウェブページに対するリクエストを第１のリクエストと見なすことができ、ウェブサーバアプリケーションは、同じページに対する後の第２のリクエストに対する効率的な応答を容易にす
るために、そのリクエストに関してキャッシングオペレーションを実行するように更に構成することができる。

実施例の実装では、例えば、ウェブサーバアプリケーションが上記ウェブページのコンポーネント間のコンポーネントツリー構造及びデータバインディングを確認した後、ウェブサーバアプリケーションは、その確認されたコンポーネントツリー構造及びデータバインディングを後の検索のためにデータ記憶装置（内部又は外部）にキャッシュするようにすることができる。例えば、ウェブサーバアプリケーションは、上述の確認されたコンポーネントツリー構造及びデータバインディングを、データ記憶装置内のＪａｖａデータオブジェクトに記憶することができる。

その後、ウェブサーバアプリケーションは、上記ウェブページに対する第２のリクエストを受け取ることができる。そして、その第２のリクエストに応答して、ウェブサーバアプリケーションは、（ｉ）上記データ記憶装置からキャッシュされたコンポーネントツリー構造及びデータバインディングを検索し、（ｉｉ）その検索されたコンポーネントツリー構造及びデータバインディングに基づいて、データバインディングと共に検索されたコンポーネントツリー構造を表し、基本スクリプトを動作するようにロードするためのコンポーネントローダを含む第２のマークアップドキュメントを構築し、及び（ｉｉｉ）その構築された第２のマークアップドキュメントをレンダリングのために出力するようにすることができる。

Ｄ．操作の実施例
図１６は、例示的実施形態を説明するフローチャートである。図１６によって説明される処理は、コンピューティング装置１００のようなコンピューティング装置、及び／又はサーバクラスタ２００のようなコンピューティング装置のクラスタによって実行されるようにすることができる。しかしながら、その処理は、他のタイプの装置又は装置サブシステムによって実行されるようにすることができる。例えば、その処理は、ラップトップ又はタブレット装置のようなポータブルコンピュータによって実行されるようにすることができる。

図１６の実施形態は、そこに示されている機能のうちの任意の１つ以上を除去することによって、簡略化されるようにすることができる。更に、これらの実施形態は、これまでの任意の図の特徴、態様、及び／又は実装、又はさもなければ本明細書における説明と、組み合わせられるようにすることができる。

図１６に従って、ブロック１６００において、その処理は、ウェブページの構造を宣言する入力であって、上記ウェブページのコンポーネント間のコンポーネント階層構造及びデータバインディングの宣言を含むものを受信する（例えば、コンピューティング装置上で実行される）ウェブサーバアプリケーションを含む。更に、ブロック１６０２において、その処理は、上記入力に応答して、上記コンポーネントの構造及び動作を解釈実行可能に定義するための基本スクリプトへの参照を含む上記ウェブページの表現を生成して、データベースの複数のテーブルに協調的に記憶することを含む。

ブロック１６０４では、その処理はそれで、その後にクライアント装置から上記ウェブページのためのリクエストを受信する前述のウェブサーバアプリケーションを含む。そして、ブロック１６０６において、その処理は、上記リクエストに応答して、（ｉ）上記データベースに問い合わせて上記ウェブページのコンポーネントツリー構造を確認し、（ｉｉ）その確認されたコンポーネントツリー構造に基づいて、その確認されたコンポーネントツリー構造を表現し、基本スクリプトを動作するようにロードするためのコンポーネントローダを含むマークアップドキュメントを構築し、そして、（ｉｉｉ）その構築された
マークアップドキュメントをクライアント装置上で実行されるウェブブラウザによるレンダリングのために出力する、ことを含む。

上記の説明に沿って、上記ウェブページの表現を生成して上記データベースの複数のテーブルに協調的に記憶することは、コンポーネント階層構造を協調的に定義する複数の相互に関係するレコードとデータバインディングを協調的に定義する複数の相互に関係するレコードとを生成して記憶することを含むことができる。

例えば、相互に関係するレコードは、上述したようにして定義されるようにすることができる、ルート要素レコード、複数のページ要素レコード、複数のコンポーネントレコード、及び複数のデータバインディングレコードを含むようにすることができる。そして、上記データベースに問い合わせて上記ウェブページのコンポーネントツリー構造を確認する振舞いは、上記データベースに問い合わせて上記ウェブページのルート要素レコードを識別し、そして、ページ要素レコード内の親参照に基づいて上記データベースに再帰的に問い合せ、その結果、上記ウェブページのコンポーネントツリー構造を確立する、ことを含むようにすることができる。

ＶＩ．結論
本開示は、本願に記載された特定の実施形態の観点から限定されるものではなく、種々の態様の例証として意図されている。多くの変更及び変形は、当業者にとって明らかなものとなろうから、その範囲から逸脱することなく行うことができる。本明細書に記載されているものに加えて、本開示の範囲内で機能的に同等の方法及び装置は、前述の記載から当業者には明らかであろう。このような変更及びバリエーションは、添付された特許請求の範囲の範囲内に含まれることを意図している。

上記の詳細な説明は、付属の図面に関連して開示されたシステム、装置、及び方法の様々な機能及び動作を説明したものである。ここに説明されている及び図面中の例示的実施形態は、制限を意図したものではない。ここに提供されている主題の範囲から逸脱することなく、他の実施形態が利用可能であり、その他の変更を行うことができる。本開示の態様としては、ここで一般的に説明され図中に例示されているように、多種多様な異なる構成で配置され、置換され、結合され、分離され、及び設計され得ることが容易に理解される。

図面中で及びここで説明されているメッセージフロー図、シナリオ、及びフローチャートのいずれか又は全てに関連して、例示的実施形態に基づいて、各ステップ、ブロック、及び／又は通信は、情報の処理及び／又は情報の送信を表すことができる。代替となる実施形態は、これらの例示的実施形態の範囲内に含まれる。これらの代替となる実施形態において、例えば、ステップ、ブロック、送信、通信、リクエスト、応答、及び／又はメッセージとして説明される動作は、図示され又は説明されるものから順番が異なって実行されるようにすることができ、これらは実質的に同時または逆の順序を含むことができ、関係する機能に依存するようにすることができる。更に、ここで説明したいずれのメッセージフロー図、シナリオ、及びフローチャートでも、より多くの又はより少ないブロック及び／又は動作を使用することができ、これらのメッセージフロー図、シナリオ、及びフローチャートは、一部または全体で相互に組み合わせることができる。

情報の処理を表すステップ又はブロックは、本明細書に記載された方法又は技法の特定の論理機能を実行するように構成できる回路に対応することができる。代わりに又は加えて、情報の処理を表すステップ又はブロックは、モジュール、セグメント、又はプログラムコードの一部（関連データを含む）に対応することができる。プログラムコードは、上記方法又は技法における特定の論理動作又はアクションを実装するためにプロセッサによ
って実行可能な、１つ以上の命令を含むことができる。そのプログラムコード及び／又は関連データは、ＲＡＭ、ディスクドライブ、ソリッドステートドライブ、又は他の記憶媒体を含む記憶装置のような任意のタイプのコンピュータ読取り可能記録媒体に記憶されるようにできる。

上記コンピュータ読取り可能記録媒体はまた、レジスタメモリ及びプロセッサキャッシュのように短期間だけデータを記憶するコンピュータ読取り可能記録媒体のような非一過性のコンピュータ読取り可能記録媒体を含むことができる。上記コンピュータ読取り可能記録媒体は更に、プログラムコード及び／又はデータをより長期間記憶する非一過性のコンピュータ読取り可能記録媒体を含むことができる。従って、上記コンピュータ読取り可能記録媒体は、例えば、ＲＯＭ、光又は磁気ディスク、ソリッドステートドライブ、コンパクトディスク読取り専用メモリ（ＣＤ−ＲＯＭ）のような、セカンダリ又は永続的な長期記憶装置を含むことができる。上記コンピュータ読取り可能記録媒体はまた、任意の他の揮発性又は不揮発性の記憶システムとすることもできる。コンピュータ読取り可能記録媒体（computer readable medium）は、例えば、コンピュータ読み取り可能記録媒体（computer readable storage medium）、又は有形な記憶装置であると考えることができる。

そのうえ、１つ以上の情報伝達を表すステップ又はブロックは、同じ物理装置内のソフトウェア及び／又はハードウェアモジュール間の情報伝達に対応することができる。ただし、その他の情報伝達は、異なる物理装置のソフトウェアモジュール及び／又はハードウェアモジュール間とすることができる。

図中の特定の配置は、制限するものとして見るべきではない。他の実施形態は、与えられた図面に示される各要素のより多い又はより少ないものを含むことができると理解すべきである。更に、例示された要素のいくつかは、結合され、又は省略されるようにすることができる。また更に、例示的実施形態は、図に例示されていない要素を含むことができる。

様々な態様や実施形態が本明細書に開示されたが、その他の態様及び実施形態は、当業者には明らかである。本明細書に開示される種々の態様及び実施形態は、例示の目的のためであり、制限するものではなく、真の範囲は以下の特許請求の範囲により示されるものである。

Claims (18)

1. ウェブページのコンポーネントの階層的配置を協調的に定義する複数の相互関係レコードであって、前記ウェブページの前記コンポーネントの構造及び動作を解釈実行可能に定義するための複数の個別の基本スクリプトへの参照を含む前記複数の相互関係レコードと、前記ウェブページの前記コンポーネント間のデータバインディングを協調的に定義する複数の相互関係レコードと、を含むデータベースであって、前記基本スクリプトは、前記ウェブページの前記コンポーネントのアプリケーションプログラミングインタフェース（ＡＰＩ）を公開し、前記基本スクリプトは、前記公開されたＡＰＩを維持しながら更新可能である、前記データベースと、そして、
   コンピューティング装置上で実行されるウェブサーバアプリケーションであって、
   クライアント装置から前記ウェブページのためのリクエストを受信し、
   前記ウェブページの前記コンポーネントの前記基本スクリプトを更新し、
   前記リクエストに応答して、（ｉ）前記データベースに問い合わせて前記ウェブページの前記コンポーネントの前記階層的配置を表現するコンポーネントツリー構造を確認し、そして上記ウェブページのコンポーネント間のデータバインディングを確認し、（ｉｉ）前記確認されたコンポーネントツリー構造及びデータバインディングに基づいて、前記確認されたコンポーネントツリー構造及びデータバインディングを表現し、前記更新された基本スクリプトを動作するようにロードするためのコンポーネントローダを含むマークアップドキュメントを構築し、そして、（ｉｉｉ）前記構築されたマークアップドキュメントを前記クライアント装置上で実行されるウェブブラウザによるレンダリングのために出力する、
   ように構成される前記ウェブサーバアプリケーションと、
   を備えるシステム。
2. 請求項１に記載のシステムであって、前記ウェブサーバアプリケーションは更に、
   前記ウェブページの前記構造及び動作を宣言するユーザ入力であって、前記ウェブページの前記コンポーネントの前記階層的配置と、前記ウェブページの前記コンポーネント間の前記データバインディングの宣言を含む前記ユーザ入力を受信し、
   前記ユーザ入力に応答して、前記ウェブページの前記コンポーネントの前記階層的配置を協調的に定義する前記複数の相互関係レコードと、前記ウェブページの前記コンポーネント間の前記データバインディングを協調的に定義する前記複数の相互関係レコードとを生成して、前記データベースの複数のテーブルに協調的に記憶し、前記問合せ及び構築を容易にする、
   ように構成される、システム。
3. 請求項２に記載のシステムであって、前記ウェブサーバアプリケーションは、そこを通して前記ウェブページの前記構造及び動作を宣言する前記ユーザ入力を受信するためのユーザインタフェースを提供するように、更に構成される、システム。
4. 請求項３に記載のシステムであって、前記ユーザインタフェースは、コンポーネントのメニューを定義し、前記コンポーネントのメニューから、前記ウェブページに含まれるべきコンポーネントのユーザ選択、及び前記コンポーネント間の階層構造及びデータバインディングのユーザ指定を可能にする、システム。
5. 請求項４に記載のシステムであって、前記コンポーネントの前記構造及び動作を解釈実行可能に定義するための前記基本スクリプトを含む各コンポーネントは、前記ユーザ入力を受信する前に定義される、システム。
6. 請求項１に記載のシステムであって、前記データベースの前記相互関係レコードは、ルート要素レコード、複数のページ要素レコード、複数のコンポーネントレコード、及び複数のデータバインディングレコードを備え、
   前記ルート要素レコードは前記ウェブページのトップレベルを定義し、
   前記複数のページ要素レコードは、前記ウェブページの前記コンポーネントの前記コンポーネントツリー構造を協調的に定義し、各ページ要素レコードは、前記コンポーネントレコードのそれぞれ１つを参照するコンポーネント参照を含み、及び前記ツリー構造の関連する親ノードを参照する親参照を含み、
   各コンポーネントレコードは、前記ウェブページのそれぞれのコンポーネントを定義し、及び前記ウェブブラウザにより解釈実行可能に前記各コンポーネントの構造及び動作を定義するための関連する基本スクリプトを参照するスクリプト参照を含み、
   前記データバインディングレコードは、（ｉ）前記コンポーネントの状態変化に基づいて前記ウェブページの特定のコンポーネントによって発行されるアクションと、（ｉｉ）前記ウェブページの他のコンポーネントのプロパティとの間のデータバインディングを
   定義する、システム。
7. 請求項６に記載のシステムであって、前記データベースに問い合わせて前記ウェブページの前記コンポーネントの前記階層的配置を定義する前記コンポーネントツリー構造を確認することは、
   前記データベースに問い合わせて前記ウェブページの前記ルート要素レコードを識別し、そして、
   前記ページ要素レコード内の前記親参照に基づいて前記データベースに再帰的に問い合せ、その結果、前記ウェブページの前記コンポーネントの前記階層的配置を定義する前記コンポーネントツリー構造を確立する、
   ことを備える、システム。
8. 請求項６に記載のシステムであって、前記データバインディングレコードは、（ｉ）前記ウェブページの前記コンポーネントによって発行されるべき前記アクションを定義するアクションレコードと、（ｉｉ）前記ウェブページの前記コンポーネントのプロパティを定義するプロパティレコードと、（ｉｉｉ）前記アクションレコードによって定義される前記アクションと前記プロパティレコードによって定義される前記プロパティとの間のデータバインディングを定義するアクションバインディングレコードと、を備える、システム。
9. 請求項８に記載のシステムであって、前記データベースに問い合わせて前記ウェブページの前記コンポーネント間の前記データバインディングを確認することは、前記アクションバインディングレコードに問い合わせて前記定義されたデータバインディングを決定することを備える、システム。
10. 請求項６に記載のシステムであって、前記確認されたコンポーネントツリー構造及びデータバインディングを表す前記マークアップドキュメントを構築することは、
    前記確認されたコンポーネントツリー構造に対応する宣言の階層的セットを含み、及び前記確認されたデータバインディングを定義する関連タグを含むように、前記マークアップドキュメントを構造化することを備える、システム。
11. 請求項１０に記載のシステムであって、前記基本スクリプトを動作するようにロードするための前記コンポーネントローダを含む前記マークアップドキュメントを構築することは、
    前記コンポーネントレコードの前記スクリプト参照から、解釈実行可能に前記ウェブページの前記コンポーネントの前記構造及び動作を定義するための前記基本スクリプトを確認し、そして、
    前記コンポーネントローダに前記確認された基本スクリプトを参照させるように、前記マークアップドキュメントを構造化する、
    ことを備える、システム。
12. 請求項１に記載のシステムであって、前記ウェブページのための前記リクエストが最初のリクエストであり、前記ウェブサーバアプリケーションは、
    前記ウェブページの前記コンポーネント間の前記コンポーネントツリー構造及びデータバインディングを確認した後、前記確認されたコンポーネントツリー構造及びデータバインディングを後の検索のためにデータ記憶装置にキャッシュし、
    その後、前記ウェブページに対する第２のリクエストを受け取り、そして、
    前記第２のリクエストに応答して、（ｉ）前記データ記憶装置から前記キャッシュされたコンポーネントツリー構造及びデータバインディングを検索し、（ｉｉ）前記検索されたコンポーネントツリー構造及びデータバインディングに基づいて、データバインディングと共に前記検索されたコンポーネントツリー構造を表し、前記基本スクリプトを動作するようにロードするための前記コンポーネントローダを含む第２のマークアップドキュメントを構築し、及び（ｉｉｉ）前記構築された第２のマークアップドキュメントをレンダリングのために出力する、
    ように更に構成される、システム。
13. 請求項１２に記載のシステムであって、前記確認されたコンポーネントツリー構造及びデータバインディングを後の検索のために前記データ記憶装置にキャッシュすることは、前記確認されたコンポーネントツリー構造及びデータバインディングを前記データ記憶装置内のＪａｖａデータオブジェクトに格納することを備える、システム。
14. ウェブサーバアプリケーションによって、ウェブページの構造を宣言する入力であって、前記ウェブページのコンポーネント間のコンポーネント階層構造及びデータバインディングの宣言を含む前記入力を受信し、
    前記入力に応答して、前記コンポーネントの構造及び動作を解釈実行可能に定義するための複数の個別の基本スクリプトへの参照を含む前記ウェブページの表現を生成して、データベースの複数のテーブルに協調的に記憶し、前記基本スクリプトは、前記ウェブページの前記コンポーネントのアプリケーションプログラミングインタフェース（ＡＰＩ）を公開し、前記基本スクリプトは、前記公開されたＡＰＩを維持しながら更新可能であり、
    その後、クライアント装置から前記ウェブサーバアプリケーションによって、前記ウェブページのためのリクエストを受信し、
    前記リクエストに応答して、前記ウェブページの前記コンポーネントの前記基本スクリプトを更新し、
    前記リクエストに応答して、（ｉ）前記データベースに問い合わせて前記ウェブページのコンポーネントツリー構造を確認し、（ｉｉ）前記確認されたコンポーネントツリー構造に基づいて、前記確認されたコンポーネントツリー構造を表現し、前記更新された基本スクリプトを動作するようにロードするためのコンポーネントローダを含むマークアップドキュメントを構築し、そして、（ｉｉｉ）前記構築されたマークアップドキュメントを前記クライアント装置上で実行されるウェブブラウザによるレンダリングのために出力する、
    ことを備える方法。
15. 請求項１４に記載の方法であって、前記ウェブページの前記表現を生成して前記データベースの前記複数のテーブルに協調的に記憶することは、前記コンポーネント階層構造を協調的に定義する複数の相互関係レコードとデータバインディングを協調的に定義する複数の相互関係レコードとを生成して記憶することを備える、方法。
16. 請求項１５に記載の方法であって、前記相互関係レコードは、ルート要素レコード、複数のページ要素レコード、複数のコンポーネントレコード、及び複数のデータバインディングレコードを備え、
    前記ルート要素レコードは前記ウェブページのトップレベルを定義し、
    前記複数のページ要素レコードは、前記ウェブページの前記コンポーネントツリー構造を協調的に定義し、各ページ要素レコードは、前記コンポーネントレコードのそれぞれ１つを参照するコンポーネント参照を含み、及び前記ツリー構造の関連する親ノードを参照する親参照を含み、
    各コンポーネントレコードは、前記ウェブページのそれぞれのコンポーネントを定義し、及び前記ウェブブラウザにより解釈実行可能に前記各コンポーネントの構造及び動作を定義するための関連する基本スクリプトを参照するスクリプト参照を含み、
    前記データバインディングレコードは、（ｉ）前記コンポーネントの状態変化に基づいて前記ウェブページの特定のコンポーネントによって発行されるアクションと、（ｉｉ）前記ウェブページの他のコンポーネントの特性との間のデータバインディングを定義する、方法。
17. 請求項１６に記載の方法であって、前記データベースに問い合わせて前記ウェブページの前記コンポーネントツリー構造を確認することは、
    前記データベースに問い合わせて前記ウェブページの前記ルート要素レコードを識別し、そして、
    前記ページ要素レコード内の前記親参照に基づいて前記データベースに再帰的に問い合せ、その結果、前記ウェブページの前記コンポーネントツリー構造を確立する、
    ことを備える、方法。
18. コンピューティングシステムによる実行時に前記コンピューティングシステムにウェブサーバ動作を実行させるプログラム命令を記憶した非一過性コンピュータ読取り可能媒体を含む製造品であって、
    ウェブページの構造を宣言する入力であって、前記ウェブページのコンポーネント間のコンポーネント階層構造及びデータバインディングの宣言を含む前記入力を受信し、
    前記入力に応答して、前記コンポーネントの構造及び動作を解釈実行可能に定義するための複数の個別の基本スクリプトへの参照を含む前記ウェブページの表現を生成して、データベースの複数のテーブルに協調的に記憶し、前記基本スクリプトは、前記ウェブページの前記コンポーネントのアプリケーションプログラミングインタフェース（ＡＰＩ）を公開し、前記基本スクリプトは、前記公開されたＡＰＩを維持しながら更新可能であり、
    クライアント装置から前記ウェブページのためのリクエストを受信し、
    前記ウェブページの前記コンポーネントの前記基本スクリプトを更新し、
    前記リクエストに応答して、（ｉ）前記データベースに問い合わせて前記ウェブページのコンポーネントツリー構造を確認し、（ｉｉ）前記確認されたコンポーネントツリー構造に基づいて、前記確認されたコンポーネントツリー構造を表現し、前記更新された基本スクリプトを動作するようにロードするためのコンポーネントローダを含むマークアップドキュメントを構築し、そして、（ｉｉｉ）前記構築されたマークアップドキュメントを前記クライアント装置上で実行されるウェブブラウザによるレンダリングのために出力する、
    ことを含む前記ウェブサーバ動作を前記コンピューティングシステムに実行させる前記プログラム命令を記憶した前記非一過性コンピュータ読取り可能媒体を含む、製造品。

Images