JP6541647B2 - ランタイムカスタマイゼーションインフラストラクチャ - Google Patents

Description

関連出願への相互参照
この出願は、
２０１３年９月２０日に出願された、「ランタイムカスタマイゼーションインフラストラクチャ（Runtime Customization Infrastructure）」という名称を有する米国仮出願第６１／８８０，７６７号と、
２０１３年１１月２６日に出願された、「ワークブックコンポーザ（Workbook Composer）」という名称を有する米国仮出願第６１／９０９，２０５号と、
２０１４年６月１３日に出願された、「ランタイムカスタマイゼーションインフラストラクチャ（Runtime Customization Infrastructure）」という名称を有する米国出願第１４／３０４，３５６号と、
２０１４年６月１３日に出願された、「ワークブックコンポーザ（Workbook Composer）」という名称を有する米国出願第１４／３０４，３９３号と
に対する優先権および優先権の利益を請求しており、その開示は本願明細書においてすべての目的について参照により援用される。

発明の背景
アプリケーションは、実行時において特定の所望のタスクを実行するソフトウェアプログラムを指す。一般に、いくつかのアプリケーションは、関連技術において周知のように、オペレーティングシステム、（たとえばＪａｖａ（登録商標）プログラミング言語をサポートする）バーチャルマシン、デバイスドライバなどのうちの１つ以上を含むランタイム環境において実行される。

デベロッパはしばしば、所望のアプリケーションを実装／開発するために、（それら自体がアプリケーションである）アプリケーション開発フレームワーク（ＡＤＦ：Application Development Framework）を使用する。ＡＤＦは、直接的／間接的にアプリケーションの開発において使用され得るあらかじめ定義されたコード／データモジュールのセットを提供する。ＡＤＦはさらに、ＩＤＥ（integrated development environment；総合開発環境）、コードジェネレータ、デバッガなどといったツールを提供し得、これにより、デベロッパがアプリケーションの所望のロジックをコーディング／実装することをより速い／より簡素な態様で容易にする。

一般に、ＡＤＦは、たとえば所望のタスクを実行するようコンポーネントを選択し、かつ、当該選択されたコンポーネントの外観、挙動および相互作用を定義することにより、アプリケーションデベロッパがユーザインターフェイスおよびアプリケーションロジックを定義するために使用し得る再使用可能なコンポーネントおよび総合開発環境を提供することによって、アプリケーションの開発を簡素化する。いくつかのＡＤＦは、疎結合（loose coupling）と、より容易なアプリケーション開発およびメンテナンスとを促進するモデル・ビュー・コントローラデザインパターンに基づく。オラクルアプリケーション開発フレームワーク（Oracle Application Development Framework）はこのデザインパターンを利用するＡＤＦの一例である。

オラクルＡＤＦは、ビルトインのＨＴＭＬ５およびＡｊａｘ機能を有する標準ベースのＪａｖａサーバフェイス（ＪＳＦ：Java Server Face）コンポーネントのライブラリを含む。これらのコンポーネントにより、ウェブで展開されるユーザインターフェイスが、以前にシッククライアントアプリケーションのために確保されたあるレベルの機能および相互作用性を有するよう開発され得る。コンポーネントは、使用が容易なコンポーネントのセットにおいて、データ相互作用、データ可視化、および、カプセル化されたブラウザ側動作を提供し、これまでよりもリッチクライアントアプリケーションの開発が容易になる。オラクルＡＤＦはさらに、ＩＤＥにおいて単純なドラッグアンドドロップ動作を通じてビジネスサービスにＵＩを結合することを簡素化するデータ結合フレームワーク（data-binding framework）を提供する。これは、コンシューミングインターフェイスからのビジネスサービスの独立を保ちつつなされる。このフレームワークにより、ＵＩデベロッパは、ビジネスサービスレイヤーの基礎をなすインプリメンテーションから隔離される。これにより、ＵＩを構築するプロセスは、ビジネスサービスレイヤーのインプリメンテーションから真に切り離され、サービス指向アーキテクチャにおけるインプリメンテーションのためにアプリケーションがよりよく配置される。

したがって、望まれるのは、アプリケーション開発フレームワークを使用してアプリケーションユーザインターフェイスを構築することに関連する問題を解決することであり、その問題のいくつかは本願明細書において論じられ得る。さらに、望まれるのは、アプリケーション開発フレームワークを使用してユーザインターフェイスを構築することに関連する障害を低減することであり、そのアプリケーション開発フレームワークのいくつかは本願明細書において論じられ得る。

発明の概要
この開示の以下の部分は、少なくとも主題の基本的な理解を提供する目的のために、この開示において発見される１つ以上のイノベーション、実施形態および／または例の簡素化された概要を提供する。この概要は、如何なる特定の実施形態または例の広範囲な概要も提供することを試みてはいない。さらに、この概要は、実施形態または例の主な／決定的な要素を識別するようには意図されておらず、または、この開示の主題の範囲を定めるようには意図されていない。したがって、この概要の１つの目的は、この開示において発見されるいくつかのイノベーション、実施形態および／または例を簡素化された形で、後述されるさらなる詳細な説明の前置きとして提供することであり得る。

さまざまな実施形態において、デベロッパが、デスクトップ統合フレームワークを使用して開発されたドキュメントのランタイムカスタマイゼーションを行うことを可能にする方法、システムおよび一時的でないコンピュータ読取可能媒体が開示される。ワークブックメタデータは、所与のワークブックが特定のウェブアプリケーションにどのように統合されるかを記述する情報のセットである。ワークブックが発行されている場合、メタデータは、発行されたワークブックにおけるローカルキャッシュおよびワークブック定義ファイルに書き込まれ得る。メタデータ管理は、発行されたワークブックにおけるローカルキャッシュおよびワークブック定義ファイルから独立して、発行されたワークブックの更新およびカスタマイゼーションを可能にするよう、メタデータサービスによって扱われ得る。

さまざまな実施形態において、ウェブベースのアプリケーションのためのユーザインターフェイスとして機能するデスクトップアプリケーションのドキュメントを作成するための方法は、そのコンテンツが第２のアプリケーションに関連付けられるネイティブアプリケーションフォーマットで作成されたドキュメントであることを示す情報を第１のアプリケーションから受け取ることを含む。ドキュメントについてのメタデータに関連付けられるルールのセットが決定される。メタデータは、ドキュメントのコンテンツの部分と、第１のアプリケーションと通信する１つ以上のウェブベースのアプリケーションによって提供されるデータモデルに関連付けられるデータとの間のリンクを提供する。ドキュメントについてのメタデータに適用されるようにカスタマイゼーションを構成するルールの決定されたセットに基づいて、ドキュメントについてのメタデータが生成される。ドキュメントが１つ以上のウェブベースのアプリケーションのためのユーザインターフェイスとして機能するように、第２のアプリケーションにドキュメントについてのメタデータが通信される。

ドキュメントについてのメタデータに関連付けられるルールのセットを決定することは、使用するべきドキュメントについてのメタデータのバージョンを規定する少なくとも１つのルールを決定することを含み得る。当該ドキュメントについてのメタデータに関連付けられるルールのセットを決定することは、ドキュメントのユーザに関連付けられる役割に基づいて、使用するべきドキュメントについてのメタデータを規定する少なくとも１つのルールを決定することを含み得る。ドキュメントについてのメタデータに関連付けられるルールのセットを決定することは、時間または日付情報に基づいて、使用するべきドキュメントについてのメタデータを規定する少なくとも１つのルールを決定することを含み得る。ドキュメントについてのメタデータに関連付けられるルールのセットを決定することは、組織の部門に基づいて、使用するべきドキュメントについてのメタデータを規定する少なくとも１つのルールを決定することを含み得る。ドキュメントについてのメタデータに関連付けられるルールのセットを決定することは、メタデータ管理サーバから１つ以上のルールを抽出することを含み得る。

いくつかの実施形態において、ドキュメントについてのメタデータに適用されるようにカスタマイゼーションを構成するルールの決定されたセットに基づいて、ドキュメントについてのメタデータを生成することは、ドキュメントについてベースメタデータに複数のメタデータカスタマイゼーションを適用することを含み得る。

一実施形態において、ウェブベースのアプリケーションのためのユーザインターフェイスとして機能するデスクトップアプリケーションのドキュメントを作成するためのコンピュータ実行可能コードを格納する一時的でないコンピュータ読取可能媒体が提供される。一時的でないコンピュータ読取可能媒体は、そのコンテンツが第２のアプリケーションに関連付けられるネイティブアプリケーションフォーマットで作成されたドキュメントであることを示す情報を第１のアプリケーションから受け取るためのコードと、ドキュメントについてのメタデータに関連付けられるルールのセットを決定するためのコードとを含み、メタデータは、ドキュメントのコンテンツの部分と、第１のアプリケーションと通信する１つ以上のウェブベースのアプリケーションによって提供されるデータモデルに関連付けられるデータとの間のリンクを提供し、一時的でないコンピュータ読取可能媒体は、ドキュメントについてのメタデータに適用されるようにカスタマイゼーションを構成するルールの決定されたセットに基づいて、ドキュメントについてのメタデータを生成するためのコードと、ドキュメントが１つ以上のウェブベースのアプリケーションのためのユーザインターフェイスとして機能するように、第２のアプリケーションにドキュメントについてのメタデータを通信するためのコードとを含む。

一実施形態において、ウェブベースのアプリケーションのためのユーザインターフェイスとして機能するデスクトップアプリケーションのドキュメントを作成するためのシステムが提供される。システムは、プロセッサと、指示のセットを格納するメモリとを含み、指示のセットは、プロセッサによって実行されると、そのコンテンツが第２のアプリケーションに関連付けられるネイティブアプリケーションフォーマットで作成されたドキュメントであることを示す情報を第１のアプリケーションから受け取り、ドキュメントについてのメタデータに関連付けられるルールのセットを決定するように、プロセッサを構成し、メタデータは、ドキュメントのコンテンツの部分と、第１のアプリケーションと通信する１つ以上のウェブベースのアプリケーションによって提供されるデータモデルに関連付けられるデータとの間のリンクを提供し、指示のセットはさらに、プロセッサによって実行されると、ドキュメントについてのメタデータに適用されるようにカスタマイゼーションを構成するルールの決定されたセットに基づいて、ドキュメントについてのメタデータを生成し、ドキュメントが１つ以上のウェブベースのアプリケーションのためのユーザインターフェイスとして機能するように、第２のアプリケーションにドキュメントについてのメタデータを通信するようにプロセッサを構成する。

この開示の主題の性質および均等物（ならびに提供される如何なる固有または明白な利点および改良）のさらなる理解は、この開示の残りの部分、任意の添付の図面および請求の範囲への参照により、上記のセクションに加えて実現されるはずである。

この開示において発見されるイノベーション、実施形態および／または例を適切に記載および説明するために、１つ以上の添付の図面に対して参照がなされ得る。１つ以上の添付の図面を説明するよう用いられる付加的な詳細または例は、特許請求される発明のいずれか、ここで記載される実施形態および／もしくは例のいずれか、またはこの開示において示されるいずれかのイノベーションの現在理解されている最良の形態の範囲への限定と見なされるべきではない。

本発明に従った一実施形態においてアプリケーション開発フレームワーク（ＡＤＦ）を示すブロック図である。 本発明に従った一実施形態において図１のＡＤＦのためのデスクトップ統合フレームワークを示すブロック図である。 本発明に従った一実施形態において図２のデスクトップ統合フレームワークを使用して、ドキュメントをデザインするための方法のフローチャートである。 本発明に従った一実施形態において図２のデスクトップ統合フレームワークを使用してドキュメントと相互作用するための方法のフローチャートである。 本発明に従った一実施形態において、基礎をなすモデルによってビューがドリブンされ得るドキュメントコンポーネントのスクリーンショットの図である。 本発明に従った一実施形態において図２のデスクトップ統合フレームワークを使用してコンポーネントのモデルドリブンの局面をデザインするための方法のフローチャートである。 本発明に従った一実施形態においてメタデータ管理を提供する図２のＡＤＦのためのデスクトップ統合フレームワークを示すブロック図である。 本発明に従った一実施形態においてメタデータ管理を提供するために図２のデスクトップ統合フレームワーク間の相互作用を示すブロック図である。 本発明に従った一実施形態においてメタデータ管理を有する図２のデスクトップ統合フレームワークを使用してドキュメントを実行するための方法のフローチャートである。 本発明に従った一実施形態においてメタデータをカスタマイズするためのユーザインターフェイスのスクリーンショットの図である。 実施形態のうちの１つを実現するための分散システムの簡略図を示す図である。 本発明のさまざまな実施形態が実現され得る例示的なコンピュータシステムを示す図である。

発明の詳細な説明
以下の記載において本発明の実施形態が完全に理解されるように説明目的のために具体的な詳細を記載する。しかしながら、さまざまな実施形態がこれらの特定の詳細なしで実施されてもよいということは明白であろう。図および記載は、限定的であるように意図されない。

イントロダクション
Ｊａｖａ ＥＥは、今日のエンタープライズアプリケーションの多くの基礎をなす標準的で、ロバストで、スケーラブルで、かつ、セキュアなプラットフォームである。Ｊａｖａ ＥＥは、Ｊａｖａ言語を使用して、多層アプリケーションを構築するための仕様のセットを提供する。過去においては、アプリケーションのロバスト性と、ロバスト性を達成するのに必要とされる複雑性との間に直接的な相関性が存在した。しかしながら、オラクルＡＤＦ（Oracle ADF）のようなＡＤＦの出現により、標準パターンおよびプラクティスに従うことによって非常にリッチなＪａｖａ ＥＥアプリケーションのインプリメンテーションが提供され得、労力が大幅に低減される。

サービス指向アーキテクチャ（ＳＯＡ：Service Oriented Architecture）原理を利用するコンポジットアプリケーションを組織が構築する必要性の増加により、デベロッパは、非常にアジャイルなアプリケーションを作成することを強いられる。アジャイルなアプリケーションにおいてこれらのベストプラクティスを実現することは通常、かなりの量のインフラストラクチャコードを記述することを伴い、これにより、はじめてＪａｖａ ＥＥアプリケーションを構築するデベロッパにとって別の支障が加わる。ロバストで、パフォーマンスが高く（performant）、メンテナンス可能なアプリケーションの提供に加えて、オラクルＡＤＦは、アジャイルなＳＯＡベースのアプリケーションを実現するようインフラストラクチャコードを提供し、これにより、組織が「自作する（rolling their own）」ことに伴う労力が除去される。

オラクルＡＤＦはさらに、Ｏｒａｃｌｅ ＪＤｅｖｅｌｏｐｅｒ １１ｇ開発ツールを通じて、Ｊａｖａ ＥＥ開発に対して視覚的および宣言的なアプローチ（visual and declarative approach）を提供する。オラクルＡＤＦは、モデル・ビュー・コントローラデザインパターンを実現し、かつ、オブジェクト／リレーショナルマッピング、データ持続性、再使用可能なコントローラレイヤー、リッチウェブユーザインターフェイスフレームワーク、ＵＩへのデータ結合、セキュリティ、およびカスタマイゼーションといったエリアに到るソリューションでこのアーキテクチャのすべてのレイヤーをカバーする統合ソリューションを提供する。コアウェブベースＭＶＣアプローチを超えて、ＡＤＦはさらに、オラクルＳＯＡと、完全なコンポジットアプリケーションの作成の簡素化するＷｅｂＣｅｎｔｅｒ Ｐｏｒｔａｌフレームワークとを統合する。

たとえば、オラクルＡＤＦは、ＡＤＦにおけるビルトインビジネスサービスにサービスインターフェイスを結合することによって、サービスとしてデータを公開するアジャイルなアプリケーションを開発することを容易にする。ビジネスサービスインプリメンテーションの詳細のこの分離は、メタデータを介してオラクルＡＤＦにおいて実行される。このメタデータドリブンのアーキテクチャの使用により、アプリケーションデベロッパが、サービスがどのようにアクセスされるかの詳細ではなく、ビジネスロジックおよびユーザ体験に集中することが可能になる。

オラクルＡＤＦは、ＡＤＦモデルレイヤーにおいてメタデータにこれらのサービスのインプリメンテーションの詳細を格納する。これにより、デベロッパは、ユーザインターフェイスを修正することなく、サービスを交換することが可能になり、アプリケーションが非常にアジャイルになる。さらに、ユーザインターフェイスを作成するデベロッパは、ビジネスサービスアクセスの詳細に悩まされる必要がない。代わりに、デベロッパはアプリケーションインターフェイスおよび相互作用ロジックの開発に集中することができる。ユーザ体験を作り出すことは、ビジュアルページデザイナに所望のビジネスサービスをドラッグアンドドロップし、どのタイプのコンポーネントがそのデータを表わすべきか示すといったように単純であり得る。

図１は、本発明に従った一実施形態において、アプリケーション開発フレームワーク（ＡＤＦ）１００を示すブロック図である。図１は、この開示において示される１つ以上の発明のさまざまな実施形態または実現例を組み込み得るシステムの簡略図である。図１は、本願明細書において開示される発明の実施形態または実現例を単に例示しているだけであり得、請求の範囲に記載されるような任意の発明の範囲を限定するべきでない。当業者は、この開示および本願明細書において示される教示を通じて、図において示される実施形態または実現例に対する他の変形例、修正例および／または代替例を認識し得る。

ＡＤＦ１００は一例ではオラクルＡＤＦとして具現化され得る。したがって、ＡＤＦ１００はモデル・ビュー・コントローラ（ＭＶＣ：Model-View-Controller）デザインパターンに基づく。ＭＶＣアプリケーションは、１）データソースとの相互作用を扱うとともにビジネスロジックを実行するモデルレイヤーと、２）アプリケーションユーザインターフェイスを扱うビューレイヤーと、３）アプリケーションフローを管理するとともにモデルレイヤーとビューレイヤーとの間のインターフェイスとして機能するコントローラとに分離される。これらの３つのレイヤーにアプリケーションを分離することによって、アプリケーションを横断するコンポーネントのメンテナンスおよび再使用が簡素化される。他のレイヤーからの各レイヤーの独立によって、疎結合されたサービス指向アーキテクチャ（ＳＯＡ）が得られる。

この実施形態において、エンタープライズアプリケーションを形成するモジュールが、当該モジュールＡＤＦ１００内に存在するのが示され、ＡＤＦを使用して開発され、次いで、ＡＤＦ１００のコンテキストにおいて実行されることを示す。簡明性のために、ＪＡＶＡプログラミング言語と、オラクル社から入手可能な開発ツールであるＪＤｅｖｅｌｏｐｅｒ １０．１．３の一部として利用可能なオラクルＡＤＦとを使用してアプリケーションが開発されると仮定して、ＡＤＦのさまざまな内部の詳細は示されない。しかしながら、以下に記載される本発明の特徴は、関連する技術の当業者には明らかであろうように、本願明細書において提供される開示を読むことによって、プログラミング言語およびアプリケーション開発フレームワークの任意の所望の組合せを用いて実現され得る。

さまざまな実施形態において、ＡＤＦ１００により、アプリケーションが複数のレイヤーの形態で開発され、各レイヤーは、あらかじめ定義された仕様に従って所望のロジックを実現するコードモジュール／ファイルを含む。したがって、一実施形態において、ＡＤＦ１００によって、アプリケーションは、アプリケーションのユーザインターフェイスを提供するコードモジュール／ファイルを含むビューレイヤー１１０と、アプリケーションのフローを制御するコードモジュールを含むコントローラレイヤー１２０と、基礎をなすデータに対して抽象化レイヤーを提供するデータ／コードモジュールを含むモデルレイヤー１３０と、さまざまなソースからのデータへのアクセスを提供するとともにビジネスロジックを扱うコードモジュールを含むビジネスサービスレイヤー１４０といった４つのレイヤーとして開発され得る。

オラクルＡＤＦにより、レイヤーの各々を実現する際に、デベロッパは使用することを好む技術を選択する。図１は、オラクルＡＤＦアプリケーションを構築する場合に、デベロッパに利用可能なさまざまなオプションを示す。Ｊａｖａ ＥＥアプリケーションのさまざまなコンポーネントを統合し開発を非常にフレキシブルにする接着剤（glue）がオラクルＡＤＦモデルレイヤーである。ＥＪＢ、Ｗｅｂ Ｓｅｒｖｉｃｅｓ、ＪａｖａＢｅａｎｓ、ＪＰＡ／ＥｃｌｉｐｓｅＬｉｎｋ／ＴｏｐＬｉｎｋオブジェクトおよび他の多くのものは、すべてオラクルＡＤＦモデルのためのビジネスサービスとして使用され得る。ビューレイヤーは、ＪＳＦ、デスクトップスイングアプリケーション（Desktop Swing Application）、およびＭＳオフィスフロントエンドを用いて実装されるウェブベースのインターフェイスと、モバイルデバイスのためのインターフェイスとを含み得る。

そのようなレイヤーアプローチを使用するアプリケーションの開発はしばしば、さまざまなアプリケーションを横断するコンポーネント／コードモジュールのメンテナンスおよび再使用を簡素化するということが理解され得る。さらに他のレイヤーからの各レイヤーの独立は、開発されたビジネス／エンタープライズアプリケーションを複数／異なるシステム上で展開する場合に望ましくあり得る疎結合のサービス指向アーキテクチャ（ＳＯＡ）に繋がる。

１つの局面において、ビューレイヤー１１０は、開発されるアプリケーションのユーザインターフェイスを表わす。ビューレイヤー１１０は、各々がユーザインターフェイスのすべてまたは一部を提供しビュータイプに対応するさまざまな態様でアクセス可能であるデスクトップ、モバイルおよびブラウザベースのビューを有するのが示される。たとえば、ウェブページは、対応するＵＲＬを含むクライアント要求を受信することに応答してアプリケーションによって送信され得る。その後、ウェブページは、要求を行ったクライアントシステムに関連付けられるディスプレイユニット（図示せず）上にブラウザによって表示され得、これにより、要求を行ったクライアントシステムのユーザがエンタープライズアプリケーションと相互作用することが可能になる。オラクルＡＤＦは、ビジネスサービスの再使用を可能にするビジネスサービスへのマルチチャンネルアクセスと、Ｗｅｂクライアント、クライアント・サーバ・スイングデスクトップベース・アプリケーション（client-server swing desktop-based application）、マイクロソフトエクセルスプレッドシート、または、スマートフォンのようなモバイルデバイスなどからのアクセスとをサポートする。

（ウェブページのような）ビューレイヤーを形成するコードファイル／モジュールは、ハイパーテキストマークアップ言語（ＨＴＭＬ：hypertext markup language）、Ｊａｖａサーバページ（ＪＳＰ：Java server page）およびＪａｖａサーバフェイス（ＪＳＦ：Java Server Face）のうちの１つ以上を用いて実現され得る。代替的には、ＳｗｉｎｇのようなＪａｖａコンポーネントおよび／または拡張マークアップ言語（ＸＭＬ：extensible markup language）を使用してユーザインターフェイスが実現され得る。さらに示されるように、ユーザインターフェイスは、マイクロソフトによるワードおよびエクセルのようなデスクトップアプリケーションについてのユーザの経験および熟知性にレバレッジをかけ得る。

上に示されるように、ユーザが開発した関連するコード／データモジュールが上記レイヤーの各々において提供される。しかしながら、各レイヤーは典型的に、ＡＤＦ１００によって提供される他のあらかじめ定義されたコード／データモジュールを含む。たとえば、あらかじめ定義されたモジュールのうちのいくつかは、ウェブページを開発するためのテンプレート、開発したコードに所望の機能を含ませるためのテンプレートなどとして、開発の間に使用され得る。（ＵＲＬ書換モジュールのような）他のあらかじめ定義されたモジュールは、開発されたアプリケーションと共に展開され得、エンタープライズアプリケーションの実行の間に、付加的な機能（内部名への要求されたＵＲＬのマッピング）をユーザに提供し得る。

コントローラレイヤー１２０は、アプリケーションのフローを制御するコードモジュール／ファイルを含む。各コントローラオブジェクトは、ビューレイヤー１１０において情報を提示する所望の態様に従って実現されるソフトウェア命令および／またはデータを含む。所望の態様は、別のウェブページにおけるリンクがユーザによってクリック／選択される場合に特定のウェブページが表示されることと、エラーが実行の間に発生する場合に、格納／抽出されるべき特定のデータを示すページが表示されることなどとを含み得る。

１つの局面において、コントローラレイヤー１２０はアプリケーションフローを管理し、ユーザ入力を扱う。たとえば、サーチボタンがページ上でクリックされると、コントローラは、どのアクションを実行するべきか（サーチを行う）と、どこにナビゲートするべきか（結果ページ）とを決定する。ＪＤｅｖｅｌｏｐｅｒにおいて、ウェブベースのアプリケーションについては、ＪＳＦコントローラ機能を拡張する標準的なＪＳＦコントローラまたはＡＤＦコントローラといった２つのコントローラオプションが存在する。どちらのコントローラが使用されるかにかかわらず、アプリケーションフローは典型的に、ページおよびナビゲーションルールをダイアグラムにレイアウトすることによってデザインされる。アプリケーションのフローは、より小さく再使用可能なタスクフローへ細分され得、フローにおけるメソッドコールおよび決定ポイントのような非視覚的コンポーネントを含み、単一の包含ページの領域の内で実行される「ページフラグメント」フローを作成する。

コントローラレイヤー１２０を形成するコードモジュール／ファイルはしばしば、クライアント要求を受信するととともに対応する応答として所望のウェブページを送信するＪａｖａサーブレットとして実現される。また、たとえば、コントローラオブジェクトは、Apache Jakarta Strutsコントローラとして、または、ＪＳＦ規格に従って実現され得る。

モデルレイヤー１３０は、上に論じたコントローラオブジェクトのような、他のレイヤーにおいてさまざまなビジネスサービスを使用するオブジェクトに当該さまざまなビジネスサービスを接続するか、または、示されるように当該さまざまなビジネスサービスを直接的にデスクトップアプリケーションに接続するデータ／コードモジュールを含む。モデルレイヤー１３０の各抽象データオブジェクトは、任意のタイプのビジネスサービスにアクセスするために使用され得る対応するインターフェイスを提供し、基礎をなすビジネスサービスレイヤー１４０において実行する。データオブジェクトは、クライアントからサービスのビジネスサービスインプリメンテーションの詳細を抽象化し、および／または、ビューコンポーネントにデータ制御メソッド／属性を公開し、ビューレイヤーとデータレイヤーとの分離を提供する。

１つの局面において、モデルレイヤー１３０は、インターフェイスを定義するためにメタデータファイルを利用するデータ制御およびデータ結合という２つのコンポーネントからなる。データ制御は、クライアントからビジネスサービスインプリメンテーションの詳細を抽象化する。データ結合は、ＵＩコンポーネントにデータ制御メソッドおよび属性を公開し、ビューとモデルとのクリーンな分離を提供する。モデルレイヤーのメタデータアーキテクチャにより、デベロッパは、任意のタイプのビジネスサービスレイヤーインプリメンテーションをビューレイヤーおよびコントローラレイヤーに結合する際に、同じ開発経験を得る。

オラクルＡＤＦは、開発プロセスの全体にわたって宣言プログラミングパラダイムの使用を強調し、インプリメンテーションの詳細に入ることを必要とすることなくユーザがアプリケーション作成のロジックに集中することを可能にする。ハイレベルでは、Ｆｕｓｉｏｎウェブアプリケーションのための開発プロセスは、アプリケーションワークスペースを作成することを通常伴う。ウィザードを使用して、デベロッパによって選択される技術に必要とされるライブラリおよび構成が自動的に追加され、アプリケーションがパッケージおよびディレクトリを有するプロジェクトへと構造化される。

データベースオブジェクトをモデリングすることによって、オンラインデータベースまたは任意のデータベースのオフラインレプリカが作成され得、定義が編集され、スキーマが更新される。その後、ＵＭＬモデラーを使用して、当該アプリケーションのためにユースケース（use case）が作成され得る。また、アプリケーション制御およびナビゲーションがデザインされ得る。アプリケーション制御およびナビゲーションのフローを視覚的に決定するために、ダイアグラマ（diagrammer）が使用され得る。当該フローを記述する基礎となるＸＭＬが自動的に作成され得る。アプリケーションに単純にリソースライブラリをドラッグアンドドロップすることによって、インポートされたライブラリをデベロッパが閲覧および使用することを可能にするよう、リソースライブラリが使用され得る。データベーステーブルから、エンティティオブジェクトがウィザードまたはダイアログを使用して作成され得る。それらのエンティティオブジェクトから、アプリケーションにおけるページによって用いられるようにビューオブジェクトが作成される。検証ルールおよび他のタイプのビジネスロジックが実現され得る。

この例において、ビジネスサービスレイヤー１４０は、データ持続性レイヤーとの相互作用を管理する。これにより、データ持続性、オブジェクト／リレーショナルマッピング、トランザクション管理およびビジネスロジック実行といったサービスが提供される。オラクルＡＤＦにおけるビジネスサービスレイヤーは、シンプルＪａｖａクラス、ＥＪＢ、Ｗｅｂ ｓｅｒｖｉｃｅｓ、ＪＰＡオブジェクト、およびオラクルＡＤＦビジネスコンポーネントといったオプションのうちのいずれかにおいて実現され得る。さらに、ファイル（ＸＭＬまたはＣＳＶ）およびＲＥＳＴからデータが直接的に消費され得る。

したがって、各ビジネスサービスは、対応するデータ持続性レイヤーとの相互作用を管理し、オブジェクト／リレーショナルマッピング、トランザクション管理、ビジネスロジックの実行などといったサービスを提供する。ビジネスサービスレイヤーは、シンプルＪａｖａクラス、Ｅｎｔｅｒｐｒｉｓｅ Ｊａｖａ Ｂｅａｎｓ、ウェブサービスなどのうち１つ以上を使用して実現され得る。

ビジネスコンポーネントは、たとえば、データベース、ウェブサービス、レガシーシステム、および、アプリケーションサーバなどとの相互作用を提供するようオラクルＡＤＦビジネスコンポーネントを使用して実現されるビジネスサービスを表わす。一実施形態において、ビジネスサービスレイヤー１４０のビジネスコンポーネントは、ビジネスサービスインプリメンテーションを提供するように協働するアプリケーションモジュール、ビュー／クエリーオブジェクトおよびエンティティオブジェクトの混合を含む。アプリケーションモジュールは、アプリケーション／トランザクションデータとともに動作するために、ＵＩクライアントが通信するトランザクションコンポーネント／コードモジュールであり得る。アプリケーションモジュールは、ユーザトランザクションに関する更新可能なデータモデルおよびプロシージャ／関数（一般にサービスメソッドと称される）を提供し得る。

エンティティオブジェクトは、データベーステーブルにおける対応する行を表わし得、当該対応する行に格納されるデータの操作（更新、削除など）を簡素化する。エンティティオブジェクトはしばしば、所望のビジネスルールが一貫して実施されることを保証するために、対応する行のためのビジネスロジックをカプセル化する。エンティティオブジェクトはさらに、存在するデータベースに格納される行同士の間に存在する関係を反映するよう、他のエンティティオブジェクトに関連付けられ得る。

デスクトップ統合
ＡＤＦデスクトップ統合は、オラクルアプリケーション開発フレームワークをマイクロソフトエクセルのようなデスクトップアプリケーションの世界へ拡張する。アプリケーションデベロッパは、ユーザがクリティカルなビジネスデータにアクセスし編集することを可能にするよう、他のデスクトップベースのアプリケーションのスプレッドシートおよびドキュメントといった統合されたドキュメントを迅速に開発し得る。このフレームワークは、各ウェブアプリケーションのセキュリティおよびビジネスロジックインフラストラクチャにシームレスに統合する。さらに、このフレームワークは、エンドユーザがネットワークへの実際の接続なしでデータを編集することを可能にする。ひとたび再接続されると、ＡＤＦデスクトップ統合は、アプリケーションのバックエンドに対して、トランスピアレントにすべてのユーザ変更をアップロードおよび有効化し得る。したがって、ＡＤＦデスクトップ統合は、デベロッパがウェブベースのアプリケーションによって提供される機能をデスクトップアプリケーションに拡張することを可能にする。さらに、エンドユーザはＡＤＦデスクトップ統合を好む場合がある。なぜならば、ＡＤＦデスクトップ統合は、複雑な計算の実行または大量のデータのアップロードといった情報管理タスクを容易かつシームレスに行うために、ユーザの好むデスクトップアプリケーションにおける見慣れたユーザインターフェイスを提供するからである。

図２は、本発明に従った一実施形態において図１のＡＤＦ１００のためのデスクトップ統合フレームワーク２００を示すブロック図である。デスクトップ統合フレームワーク２００は、この開示内に提示された１つ以上の発明のさまざまな実施形態または実現例を組み込み得る。デスクトップ統合フレームワーク２００は、本願明細書において開示される発明の実施形態または実現例を単に例示しているだけであり、請求の範囲に記載されるような任意の発明の範囲を限定するべきでない。当業者は、この開示および本願明細書において示される教示を通じて、図において示される実施形態または実現例に対する他の変形例、修正例および／または代替例を認識し得る。

この例において、デスクトップ統合フレームワーク２００は、クライアントコンピュータシステム２１０およびサーバコンピュータシステム２２０を含む。クライアントコンピュータシステム２１０は、アクセスを提供および／またはアプリケーション２３０をホスティングするように構成されるハードウェアおよび／またはソフトウェア要素を表す。クライアントコンピュータシステム２１０は、パーソナルコンピュータシステム、ラップトップ、タブレット、およびモバイルデバイスなどとして具現化され得る。クライアントコンピュータシステム２１０は、１つ以上のコンピュータ上で実行される１つ以上のオペレーティングシステム、アプリケーション、およびブラウザなどを含み得る。クライアントコンピュータシステム２１０は、本願明細書において開示される発明の実施形態または実現例を単に例示しているだけであり、請求の範囲に記載されるような任意の発明の範囲を限定するべきでない。当業者は、この開示および本願明細書において示される教示を通じて、図において示される実施形態または実現例に対する他の変形例、修正例および／または代替例を認識し得る。

アプリケーション２３０は、ユーザがドキュメントを生成、編集、または別の態様で相互作用することを可能にする１つ以上のソフトウェア要素を表す。アプリケーション２３０のいくつかの例は、テキストエディタ、ワードプロセッシングアプリケーション、スプレッドシートアプリケーション、ならびに、画像編集および操作プログラムなどである。さまざまな実施形態において、デスクトップ統合フレームワーク２００は、マイクロソフトワードおよびマイクロソフトエクセルのようなマイクロソフトオフィス製品のようなデスクトップアプリケーションに特有の構成で動作する。

アプリケーション２３０は、ＡＤＦ−ＤＩクライアントコンポーネント２４０をさらに含むか、または、そうでなければＡＤＦ−ＤＩクライアントコンポーネント２４０と通信し、かつ、ドキュメント２５０を作成する。ＡＤＦ−ＤＩクライアントコンポーネント２４０は、ウェブベースまたは他のネットワークアクセス可能なアプリケーションによって提供される機能をアプリケーション２３０に拡張する１つ以上のソフトウェア要素を表す。たとえば、ＡＤＦ−ＤＩクライアントコンポーネント２４０は、エンドユーザが、アプリケーション２３０に関連付けられる見慣れたユーザインターフェイスを利用することを可能にし、これにより、ドキュメント２５０を使用して、サーバコンピュータシステム２２０にアクセスすることにより通常実行される情報管理タスクを行う。これらのタスクは、サーバコンピュータシステム２２０によってホスティングされたウェブベースまたは他のネットワークアクセス可能なアプリケーションによって実行または扱われ得る。さまざまな実施形態において、アプリケーション２３０において実行されるそのような情報管理タスクによって操作されたデータは、サーバコンピュータシステム２２０に同期される。

ドキュメント２５０は、電子情報の１つ以上のコンピュータデータファイルまたはユニットを表わす。ドキュメント２５０は、テキスト、画像、オーディオ、ビデオおよび他のマルチメディア情報を含み得る。ドキュメント２５０はさらに、アプリケーション２３０に特有のメタデータに関連付けられ得る。ドキュメント２５０（またはアプリケーション２３０）は、ドキュメント２５０に関連付けられるコンテンツを作成し、相互作用し、管理するためのネイティブな機能を提供し得る。さまざまな局面において、アプリケーション２３０は、アプリケーション２３０の機能またはドキュメント２５０のコンテンツと相互作用するための１つ以上のインターフェイスを提供する。

サーバコンピュータシステム２２０は、アプリケーションサーバ２６０にアクセスを提供および／またはアプリケーションサーバ２６０をホスティングするよう構成されるハードウェアおよび／またはソフトウェア要素を表わす。サーバコンピュータシステム２２０は、ローカルサーバコンピュータシステムおよびクラウドサービスなどとして具現化され得る。サーバコンピュータシステム２２０は、１つ以上のコンピュータ上で実行される１つ以上のオペレーティングシステム、サーバ、サービス、およびアプリケーションなどを含み得る。サーバコンピュータシステム２２０は、本願明細書において開示される発明の実施形態または実現例を単に例示しているだけであり、請求の範囲に記載されるような任意の発明の範囲を限定するべきでない。当業者は、この開示および本願明細書において示される教示を通じて、図において示される実施形態または実現例に対する他の変形例、修正例および／または代替例を認識し得る。

アプリケーションサーバ２６０は、ユーザがウェブベースのアプリケーションまたはネットワークベースのアプリケーションと相互作用することを可能にする１つ以上のソフトウェア要素を表わす。アプリケーションサーバ２６０のいくつかの例は、アプリケーション機能が何かであるかにかかわらず、アプリケーションサーバインプリメンテーションの作成に対する一般化されたアプローチを提供するソフトウェアフレームワークか、または、特定のインプリメンテーションインスタンスのサーバ部分のいずれかである。さまざまな実施形態において、アプリケーションサーバ２６０は、Ｊａｖａプラットフォーム、エンタープライズエディション、またはＡＰＩのコアセットおよびＪａｖａアプリケーションサーバの機能を定義するＪａｖａ ＥＥに特有の構成で動作する。アプリケーションサーバ２６０は、サーブレット、ＪａｖａＳｅｒｖｅｒ Ｐａｇｅ、およびＥｎｔｅｒｐｒｉｓｅ ＪａｖａＢｅａｎｓなどを含み得る。アプリケーションサーバ２６０は、本願明細書において開示される発明の実施形態または実現例を単に例示しているだけであり、請求の範囲に記載されるような任意の発明の範囲を限定するべきでない。当業者は、この開示および本願明細書において示される教示を通じて、図において示される実施形態または実現例に対する他の変形例、修正例および／または代替例を認識し得る。

ＡＤＦ−ＤＩサーバコンポーネント２７０は、アプリケーションサーバ２６０の部分のような１つ以上のサーバコンポーネントを表わす。一般に、ＡＤＦ−ＤＩクライアントコンポーネント２４０は、ビューレイヤー１１０およびコントローラレイヤー１２０の両方として機能し、モデルレイヤー１３０として部分的に機能するＡＤＦ−ＤＩサーバコンポーネント２７０と通信して、データを同期させて、アプリケーションサーバ２６０によってホスティングされるアプリケーション、または、ＡＤＦモデル２８０を使用するアプリケーションサーバ２６０と通信するアプリケーションにおけるビジネスロジックを実行する。上で論じたように、モデルレイヤー１３０は、データ値に対して使用されるモデルレベルのビジネスルール、セキュリティおよびアプリケーションロジックとともに、アプリケーション２３０内のＡＤＦ−ＤＩクライアントコンポーネント２４０によって提示される現在のビューに関係するデータ値を表わす。この例において、ＡＤＦ−ＤＩクライアントコンポーネント２４０およびＡＤＦ−ＤＩサーバコンポーネント２７０は、エンドユーザがアプリケーション２３０に関連付けられる見慣れたユーザインターフェイスを利用することを可能にし、ＡＤＦモデル２８０にアクセスするようドキュメント２５０を使用してビュー／コントローラタスクを行う。

１つの局面において、デベロッパは、デザインモードにおいてドキュメント２５０を作成するためにアプリケーション２３０内で作業するよう、ＡＤＦ−ＤＩクライアントコンポーネント２４０を利用する。デベロッパは、アプリケーション２３０のネイティブツールを利用して所望の態様でドキュメント２５０を構造化およびフォーマットする。その後、デベロッパは、アプリケーションサーバ２６０にドキュメント２５０を統合するよう、ＡＤＦ−ＤＩクライアントコンポーネント２４０を使用してドキュメント２５０にコンポーネントを追加し得る。コンポーネントのいくつかの例は、入力コンポーネント（たとえばフォームコンポーネント）、出力コンポーネント、ラベル、リスト、ボタン、画像、およびテーブルなどである。

その後、ドキュメント２５０に加えられるコンポーネントは、ＡＤＦ−ＤＩサーバコンポーネント２７０によって提供されるまたはＡＤＦ−ＤＩサーバコンポーネント２７０を通じて提供される対応するモデルにマッピングされる。たとえば、モデルレイヤー１３０によって公開されるＡＤＦ−ＤＩサーバコンポーネント２７０によって提供されるまたはＡＤＦ−ＤＩサーバコンポーネント２７０を通じて提供される人間モデルの名前属性にドキュメント２５０内の入力／出力メカニズムを提供するよう、テキストボックスコンポーネントがマッピングされ得る。

１つの局面において、コンポーネントは、多くのアプリケーションによって使用され得る（または同じアプリケーションによって複数回使用され得る）機能を提供する再使用可能なエンティティである。コンポーネントは、ドキュメント２５０内に埋め込まれ得、０以上の視覚的表現を有し得る。視覚的表現を有さないコンポーネントは、表示されないが、何らかの他の機能を提供し得る。コンポーネントは一般に、プログラミングインターフェイス、データ結合インターフェイス、および視覚的インターフェイスのような１つ以上のインターフェイスを提供する。コンポーネント２００は１つ以上の視覚的表現を有し得る。さらに以下に記載されるように、コンポーネントは、存在するモデルによってドリブンされる視覚的表現を有し得る。

１つの局面において、コンポーネントは、あるデザインタイムにて任意の数のビューを特定し得、そのいずれかがランタイムにて表示され得る。ビューアセンブリは、ランタイムにて実際に表示されるビューのセットである。アプリケーションまたはコンポーネントのためのビューアセンブリは、ある時点で表示のために選択されるビュー構成におけるビューからなる。

ひとたびすべての所望のコンポーネントが含まれ、アプリケーションサーバ２６０およびＡＤＦモデル２８０にアクセス可能なデータおよび／またはモデルメタデータにマッピングされると、ドキュメント２５０は、アプリケーションサーバ２６０上に「発行（published）」またはそうでなければ利用可能にされ得る。アプリケーションサーバ２６０は、ユーザがブラウザを介してドキュメントにアクセスすることを可能にする発行されたドキュメントへのダウンロードリンクを提供し得、サーバコンピュータシステム２２０にアクセス可能であるデータベースに格納されたデータのようなデータを閲覧、作成、および／または、操作するようアプリケーション２３０内において作動を開始し得る。さまざまな実施形態において、発行されたドキュメントは、コンポーネント、データマッピング、およびデベロッパがドキュメントと関連付けた任意のロジック、を定義するドキュメントメタデータとは別に格納される。いくつかの実施形態において、発行されたドキュメントはすべてのドキュメントメタデータを含む。

図３は、本発明に従った一実施形態において、図２のデスクトップ統合フレームワーク２００を使用してドキュメントをデザインするための方法３００のフローチャートである。図３に示される方法３００の実現または処理は、コンピュータシステムまたは情報処理デバイスのようなロジックマシンの中央処理装置（ＣＰＵまたはプロセッサ）によって実行される際にソフトウェア（たとえば命令またはコードモジュール）によって実行され得るか、電子デバイスまたは特定用途向け集積回路のハードウェアコンポーネントによって実行され得るか、または、ソフトウェアおよびハードウェア要素の組合せによって実行され得る。図３に示される方法３００は、ステップ３１０において開始する。

ステップ３２０において、ドキュメントが受け取られる。一般に、ドキュメントは、そのようなドキュメントをネイティブで作成するアプリケーションによってか、または、ネイティブフォーマットでドキュメントを作成するライブラリを使用して、作成される。図２に従うと、ユーザは、存在するドキュメントを開くか、または、たとえばマイクロソフトエクセルにおいて新しいスプレッドシートを作成するといったようにアプリケーション２３０において新しいドキュメントを作成し得る。ドキュメントデベロッパは、ネイティブおよびノンネイティブなツールを使用して任意の所望の態様でドキュメントを編集、構造化、またはフォーマットし得る。

ステップ３３０において、ドキュメントメタデータが受け取られる。ドキュメントメタデータは、アプリケーションサーバ２６０から得られるデータに基づいてドキュメントのコンテンツを与えるよう、ＡＤＦ−ＤＩクライアントコンポーネント２４０によって利用される情報を含む。１つの局面において、ドキュメントメタデータは、ドキュメントに含まれる各コンポーネント、および、ビジネスサービスレイヤー１４０において利用可能なデータまたはメタデータにコンポーネントがどのように結合されるかということを示す。ドキュメントメタデータはさらに、デベロッパによって提供されるアクセス情報、静的データ、および他のロジックまたはデータ操作情報を提供し得る。上で論じたように、デベロッパは、アプリケーションサーバ２６０にドキュメント２５０を統合するよう、ＡＤＦ−ＤＩクライアントコンポーネント２４０を使用してドキュメント２５０にコンポーネントを追加し得る。

さまざまな実施形態において、ＡＤＦ−ＤＩクライアントコンポーネント２４０は、ドキュメントに追加され得るいくつかまたはすべてのコンポーネントについて１つ以上の特性を含むエクスプレッションビルダーを提供する。各プロパティは、その対応するコンポーネントの挙動の局面を定義し得る。たとえば、プロパティは、コンポーネントにマッピングされるモデルもしくはオブジェクトを特定し得る、および／または、コンポーネントに対応するモデルもしくはオブジェクトの１つ以上の属性を特定し得る。別の例において、プロパティは、テーブルカラムヘッダーおよびワークシートリボンコマンドなどのようなドキュメント２５０の局面を特定し得る。

ステップ３４０において、ドキュメントおよびドキュメントメタデータが発行される。上で論じたように、発行されたドキュメントは、ドキュメントメタデータとは別に格納され得る。いくつかの実施形態において、発行されたドキュメントは、ドキュメントメタデータのすべてまたは一部を含み得る。一般に、発行されたドキュメントは、ＡＤＦ−ＤＩクライアントコンポーネント２４０が、ドキュメントを初期化し、ＡＤＦ−ＤＩサーバコンポーネント２７０からの付加的な情報を要求して、ランタイムにてユーザのためにドキュメント２５０のコンテンツを与えることを可能にする少なくとも十分なメタデータを含む。図３はステップ３５０で終了する。

ランタイムの間、ユーザは発行されたドキュメント２５０をダウンロードし、アプリケーション２３０を用いてそれを開く。一実施形態において、ＡＤＦ−ＤＩクライアントコンポーネント２４０は、アプリケーションプラグインまたはモジュールとしてインストールされている。その後、ＡＤＦ−ＤＩクライアントコンポーネント２４０は、ドキュメント２５０がフレームワークコンポーネントを含むよう記述されていることを検出し得、かつ、ドキュメントメタデータ、実データ、および、実行される必要がある任意のロジックを要求するようＡＤＦ−ＤＩサーバコンポーネント２７０にコンタクトする。たとえば、ＡＤＦ−ＤＩクライアントコンポーネント２４０はまず、どのコンポーネントが含められるべきかと当該コンポーネントをどこに含むべきかとを定義するドキュメントメタデータを、ＡＤＦ−ＤＩサーバコンポーネント２７０からまたはＡＤＦ−ＤＩサーバコンポーネント２７０を通じて抽出し得る。ＡＤＦ−ＤＩクライアントコンポーネント２４０は、選択されたコンポーネントが使用するかまたはそうでなければ動作することになるＡＤＦモデル２８０からのデータを、ＡＤＦ−ＤＩサーバコンポーネント２７０からまたはＡＤＦ−ＤＩサーバコンポーネント２７０を通じて抽出し得る。ＡＤＦ−ＤＩクライアントコンポーネント２４０はさらに、ドキュメント２５０に関連付けられる任意のロジックをＡＤＦ−ＤＩサーバコンポーネント２７０からまたはＡＤＦ−ＤＩサーバコンポーネント２７０を通じて抽出し得る。その後、最終的に、ＡＤＦ−ＤＩクライアントコンポーネント２４０は、ドキュメントメタデータ、実データおよびロジックを利用してドキュメント２５０のコンテンツを与え得る。

したがって、ユーザは、ドキュメントテンプレートを抽出し得るとともに、ＡＤＦ−ＤＩクライアントコンポーネント２４０によって実行される処理とアプリケーションサーバ２６０から得られたデータとに基づき自動的に更新およびフォーマットされたドキュメントコンテンツを有し得る。その後、ユーザは、アプリケーション２３０に関連付けられる見慣れたユーザインターフェイスを利用して、ドキュメント２５０を使用してタスクを実行する。

さまざまな局面において、ユーザがドキュメント２５０と相互作用または操作する際に、ＡＤＦ−ＤＩクライアントコンポーネント２４０およびＡＤＦ−ＤＩサーバコンポーネント２７０は、通信したままであり得、これにより更新を送信および受信する。モデルレイヤー１３０における対応するモデルのデータへのドキュメント２５０の１つ以上のコンポーネント内でなされた変更は、ＡＤＦモデル２８０において持続され得る。

図４は、本発明に従った一実施形態において、図２のデスクトップ統合フレームワーク２００を使用してドキュメントと相互作用するための方法４００のフローチャートである。図４に示される方法４００の実現または処理は、コンピュータシステムまたは情報処理デバイスのようなロジックマシンの中央処理装置（ＣＰＵまたはプロセッサ）によって実行される際にソフトウェア（たとえば命令またはコードモジュール）によって実行され得るか、電子デバイスまたは特定用途向け集積回路のハードウェアコンポーネントによって実行され得るか、または、ソフトウェアおよびハードウェア要素の組合せによって実行され得る。図４に示される方法４００は、ステップ４１０において開始する。

ステップ４２０において、ドキュメントが受け取られる。図２に従うと、ユーザは、たとえばドキュメントリンクをクリックすることによって、所望のドキュメントを抽出するようアプリケーションサーバ２６０と相互作用し得る。ドキュメントは、クライアントコンピュータシステム２１０にダウンロードまたはそうでなければ通信され得、アプリケーション２３０において開かれ得る。

ステップ４３０において、ドキュメントメタデータが処理される。上で論じたように、ドキュメントメタデータは、アプリケーションサーバ２６０から得られたデータに基づいてドキュメントのコンテンツを与えるよう、ＡＤＦ−ＤＩクライアントコンポーネント２４０によって利用される情報を含む。したがって、ＡＤＦ−ＤＩクライアントコンポーネント２４０は、どのコンポーネントがドキュメントに追加されるべきかと、どこに追加されるべきかとを決定する。ＡＤＦ−ＤＩクライアントコンポーネント２４０はさらに、何のデータが各コンポーネントによって使用されるかと、何のデータがデベロッパによって定義される任意のロジックを適用するかとを決定する。

ステップ４４０において、ドキュメントデータが処理される。上で論じたように、発行されたドキュメントは、ドキュメントメタデータとドキュメントによって使用される実データとは別に格納され得る。一般に、発行されたドキュメントは、ＡＤＦ−ＤＩクライアントコンポーネント２４０が、ドキュメントを初期化し、ＡＤＦ−ＤＩサーバコンポーネント２７０からの付加的な情報を要求して、ユーザのためにドキュメント２５０のコンテンツを与えることを可能にする少なくとも十分なメタデータを含む。

ステップ４５０において、ドキュメントが与えられる。上で論じたように、ＡＤＦ−ＤＩクライアントコンポーネント２４０は、選択されたコンポーネントが使用するかまたはそうでなければ動作することになるＡＤＦモデル２８０からのデータを、ＡＤＦ−ＤＩサーバコンポーネント２７０からまたはＡＤＦ−ＤＩサーバコンポーネント２７０を通じて抽出し得る。ＡＤＦ−ＤＩクライアントコンポーネント２４０はさらに、ドキュメント２５０に関連付けられる任意のロジックをＡＤＦ−ＤＩサーバコンポーネント２７０からまたはＡＤＦ−ＤＩサーバコンポーネント２７０を通じて抽出し得る。その後、最終的に、ＡＤＦ−ＤＩクライアントコンポーネント２４０は、ドキュメントメタデータ、実データおよびロジックを利用してドキュメント２５０のコンテンツを与え得る。

ステップ４６０において、ドキュメントに対する更新が存在するかどうかについて決定がなされる。ドキュメントへの更新が存在し得るさまざまな理由が存在し得る。ユーザがドキュメント２５０と相互作用するかまたはドキュメント２５０を操作する際、ＡＤＦ−ＤＩクライアントコンポーネント２４０およびＡＤＦ−ＤＩサーバコンポーネント２７０は、更新を送信および受信するよう通信したままであり得る。モデルレイヤー１３０における対応するモデルのデータへのドキュメント２５０の１つ以上のコンポーネント内でなされた変更は、ＡＤＦモデル２８０において持続され得る。いくつかの実施形態において、ユーザによる相互作用は新しいデータセットを必要とする場合がある。したがって、方法４００のフローは、ステップ４５０において与えられる付加的なドキュメントデータを処理するようステップ４４０に戻る。図４はステップ４７０で終了する。

モデルドリブンの局面
さまざまな実施形態において、デスクトップ統合フレームワーク２００は、デベロッパが、ビューおよびデータが対応するモデルまたはモデル属性によってドリブンされるコンポーネントドキュメント２５０を含めることを可能にする。１つの局面において、コンポーネントは、ユーザのマウスがデータの部分上にある場合またはデータが選択される場合に表示されるコンポーネントの与えられたコンテンツに関する有用な情報を含むツールティップ（tool tip）を提供し得る。ツールティップは、モデルまたはオブジェクトを介して定義され得、ドキュメントのコンポーネントが与えられる際に自動的に構成され得る。別の局面において、リストコンポーネントの要素には、モデルまたはオブジェクトに関連付けられる１つ以上の属性の以前に存在した値がポピュレートされ得る。したがって、デベロッパは、ドキュメントが与えられる場合にコンポーネントが提示するビューにおける値を特定することが必要とされない。

図５は、本発明に従った一実施形態において、基礎をなすモデルによってビューがドリブンされ得るドキュメントコンポーネントのスクリーンショット５００の図である。この例において、ツリー５１０は、ドキュメント２５０において提示され得る１つ以上のビューのリストを提供する。この例において、ＥｍｐＶｉｅｗ５２０は、「Ｅｍｐｎｏ」、「Ｅｎａｍｅ」、「Ｊｏｂ」、「Ｍｇｒ」などとラベル付けされたテキスト、リスト、画像、および日付などといった１つ以上のコンポーネントを含む。

１つの局面において、コンポーネント５３０に関連付けられる従業員オブジェクトの基礎をなすデータモデルまたは属性が「Ｈｉｒｅｄａｔｅ」とラベル付けされる。当該データモデルまたは属性は、所与の従業員が組織によって雇われた日付に関連付けられる日付値を格納するように構成される。さまざまな実施形態において、コンポーネント５３０のビューまたは挙動は、デベロッパによるさらなる別の構成が存在しない日付値（date value absent further configuration）を属性が格納するという事実によってドリブンされ得る。たとえば、コンポーネント５３０に対応するセルを有するエクセルワークブックをＡＤＦ−ＤＩクライアントコンポーネント２４０が与える時に、ＡＤＦ−ＤＩクライアントコンポーネント２４０は、ユーザが従業員の雇用の日付を表わす値を格納するセルを選択すると、エクセルのネイティブの機能内または機能外にて日付ポップアップが提供され、これによりユーザが新しい雇用日付を選択または既存の雇用日付を修正することを可能にするように、セルを構成し得る。

別の局面において、コンポーネント５４０に関連付けられる従業員オブジェクトの基礎をなすデータモデルまたは属性は「Ｄｅｐｔｎｏ」とラベル付けされる。当該データモデルまたは属性は、ある従業員に関連付けられる部門またはチームについての識別子を格納するように構成される。さまざまな実施形態において、コンポーネント５４０のビューまたは挙動は、属性が、デベロッパによるさらなる別の構成が存在しないデータモデル（data model absent further configuration）において特定される複数の所定の値のうちの１つを格納するという事実によってドリブンされ得る。たとえば、コンポーネント５４０に対応するセルを有するエクセルワークブックをＡＤＦ−ＤＩクライアントコンポーネント２４０が与える時に、ＡＤＦ−ＤＩクライアントコンポーネント２４０は、従業員が割り当てられている部門またはチームを表わす値を格納するセルをユーザが選択すると、ドロップダウンリストがエクセルのネイティブの機能内または機能外にて提供され、これによりデータモデルから導き出される部門またはチームの所定のリストからユーザが選択することを可能にするように、セルを構成し得る。

図６は、本発明に従った一実施形態において、図２のデスクトップ統合フレームワーク２００を使用してコンポーネントのモデルドリブンの局面をデザインするための方法６００のフローチャートである。図６に示される方法６００の実現または処理は、コンピュータシステムまたは情報処理デバイスのようなロジックマシンの中央処理装置（ＣＰＵまたはプロセッサ）によって実行される際にソフトウェア（たとえば命令またはコードモジュール）によって実行され得るか、電子デバイスまたは特定用途向け集積回路のハードウェアコンポーネントによって実行され得るか、または、ソフトウェアおよびハードウェア要素の組合せによって実行され得る。図６に示される方法６００は、ステップ６１０において開始する。

ステップ６２０において、コンポーネント仕様が受け取られる。一般に、コンポーネント仕様は、当該コンポーネントがどのように定義されるかを特定する情報を指す。図２に従うと、アプリケーション２３０において、デベロッパは、存在するドキュメントを開くか、または、たとえばマイクロソフトエクセルにおいて新しいスプレッドシートを作成するといったように新しいドキュメントを作成し得る。次いで、デベロッパは、ネイティブおよびノンネイティブなツールを使用して任意の所望の態様でドキュメントを編集、構造化、またはフォーマットし得る。さらに、デベロッパは、複数の所定のコンポーネントから選択を行い、それらのコンポーネントをドキュメント２５０に追加し得る。

ステップ６３０において、データ結合仕様が受け取られる。一般に、データ結合仕様は、そのソースなどのようなデータとコンポーネントがどのように相互作用するかを特定する情報を指す。さまざまな実施形態において、ＡＤＦ−ＤＩクライアントコンポーネント２４０は、この情報を利用して、コンポーネント仕様に加えてコンポーネントをさらに構成する。１つの局面において、ＡＤＦ−ＤＩクライアントコンポーネント２４０は、コンポーネントに関連付けられる１つ以上のモデルまたはオブジェクトに基づいて、各コンポーネントがどのように１つ以上のビューを提示するかを示す。ＡＤＦ−ＤＩクライアントコンポーネント２４０は、モデル局面および値などを抽出して、コンポーネントと、任意の関連付けられるビューと、関連付けられる挙動とを構成するようＡＤＦ−ＤＩサーバコンポーネント２７０と相互作用し得る。さまざまな実施形態において、ＡＤＦ−ＤＩクライアントコンポーネント２４０は、ユーザが上に論じられたエクスプレッションビルダーを使用することに応答して、コンポーネント仕様およびデータ結合仕様を受け取り得る。

ステップ６４０において、コンポーネントのモデルドリブンの局面が決定される。ＡＤＦ−ＤＩクライアントコンポーネント２４０は、ＡＤＦモデル２８０における属性プロパティまたはヒントとして知られるモデル局面および値などを抽出してコンポーネント、任意の関連付けられるビュー、および関連付けられる挙動を構成するようＡＤＦ−ＤＩサーバコンポーネント２７０と相互作用し得る。構成情報は、発行されたドキュメントに関連付けられ得るドキュメントメタデータに格納され得る。

一例において、ユーザに提示されるラベルは、当該ラベルに対応するデータオブジェクトの名称としばしば異なる。たとえば、「ＥｍｐＮａｍｅ」と称される属性が存在する場合、ＵＩにおいて、デベロッパは、「従業員名」を表示することを望む。大抵のＵＩフレームワークは、デベロッパがユーザフレンドリなラベルを特定することを可能にする。しかしながら、現われる必要がある各場所にユーザフレンドリなラベルを特定することは効率的ではない。「モデルドリブン」なアプローチは、モデルレベルにてＥｍｐＮａｍｅ属性にユーザフレンドリなラベルを関連付けることである。その後、ＥｍｐＮａｍｅを与えることを望む各ＵＩ要素（ページ、ワークシートなど）は、デザインタイムにおいてＥｍｐＮａｍｅのラベルを間接的に「参照」し、ランタイムにてそれを動的にフェッチする。このアプローチは、データオブジェクトのさまざまな異なる潜在的なプロパティに適用される。他の例は「読取専用」、「必須」などを含む。図６はステップ６５０で終了する。

メタデータ管理
いくつかの実施形態において、ワークブック統合を定義するメタデータは、メタデータサービスによって管理され得る。図７は、本発明に従った一実施形態においてメタデータ管理を提供する、図２のデスクトップ統合フレームワーク２００における相互作用を示すブロック図である。この例において、ドキュメントメタデータは、デザインタイムおよびランタイムの両方においてリポジトリ２９５内部に格納され得る。ドキュメント２５０がたとえばカスタマーサイトにおいて発行された後、リポジトリ２９５においてメタデータがカスタマイズされ得る。ＡＤＦ−ＤＩサーバコンポーネント２７０は、管理ルールのセットに基づいてドキュメントメタデータの１つ以上のバージョンを提供するようメタデータサーバ２９０と通信する。管理ルールは、たとえば時間、日付、ユーザの役割、構成などのようなドキュメントがメタデータのどのバージョンを利用するかを規定する基準および／または条件を定義し得る。これは、より多くの機能が追加される場合のように、ワークブック定義スキーマが時間にわたり変化することを可能にする。

したがって、さまざまな実施形態において、デスクトップ統合フレームワーク２００は、カスタマイズ可能なものとしてデベロッパがワークブックを指定することを可能にする。デベロッパは、良好に定義されたワークブック初期化ポイントにて、メタデータサーバ２９０から抽出されるワークブックメタデータを構成し得る。ワークブックメタデータは、現在のユーザのカスタマイゼーションのコンテキストについてカスタマイズされ得る。別の局面において、ランタイムワークブックは、メタデータサーバ２９０から抽出されたカスタマイズされたメタデータを使用して与えられ得る。

さまざまな実施形態において、ＡＤＦ−ＤＩクライアントコンポーネント２４０は、ＡＤＦ−ＤＩサーバコンポーネント２７０へドキュメントメタデータを転送し、ＡＤＦ−ＤＩサーバコンポーネント２７０は、メタデータサーバ２９０にワークブック定義ファイル（ベースドキュメントメタデータ）およびカスタマイゼーションを格納させる。デベロッパは、ベースドキュメントおよび／またはカスタマイゼーションを管理するためのファイルベースまたはデータベースリポジトリを使用するよう選択し得る。

図８は、本発明に従った一実施形態において、メタデータ管理を提供する、図７のデスクトップ統合フレームワーク間の相互作用を示すブロック図である。ブロック８１０において、クラスパス上において対応するワークブック定義ファイルを特定するよう、暗示されたメタデータパスが使用され得るような態様で、カスタマイゼーションが可能にされたワークブックが発行される。たとえば、デザインタイムワークブックを「/PROJECT_ROOT/src/apps/workbooks/myDTWorkbook.xlsx」として、それが発行される場合、当該ワークブック定義ファイルは、「/PROJECT_ROOT/src/apps/workbooks/myDTWorkbook.xlsx-workbook-definition.xml」に生成される。アプリケーションが展開されると、このワークブック定義ファイルは、パス「/apps/workbooks/myDTWorkbook.xlsx-workbook-definition.xml」を使用して、クラスパスリポジトリによって発見され得る。したがって、ランタイムワークブックは、暗示されたメタデータパスを使用してそのワークブックメタデータをロードし得るために、「/PROJECT_ROOT/public_html/oracle/apps/workbooks/」フォルダに発行されるべきである。上で論じたように、デベロッパは、ベースドキュメントおよび／またはカスタマイゼーションを管理するためのファイルベースまたはデータベースリポジトリを使用するよう選択し得る。

ブロック８２０におけるワークブック初期化の際、ＡＤＦ−ＤＩクライアントコンポーネント２４０は、現在のワークブックのメタデータについて、サーバコンピュータシステム２２０への要求を発する。ブロック８３０において、ＡＤＦ−ＤＩサーバコンポーネント２７０は、ＭＤＳセッション（たとえば現在のＡＤＦコンテキスト（ADF Context）からメタデータサーバ２９０を介して標準的なＭＤＳセッション）を使用してワークブックメタデータを抽出する。ＭＤＳセッションに関連付けられるカスタマイゼーションのコンテキストに基づいて、メタデータサーバ２９０はワークブックメタデータに全てのカスタマイゼーションを適用する。ブロック８２０において、カスタマイズされたワークブックメタデータは、ＡＤＦ−ＤＩクライアントコンポーネント２４０に返され、ワークブックのメタデータキャッシュに書き込まれる。ブロック８６０において、キャッシュされたカスタマイズされたワークブックメタデータは、ランタイムワークブックを初期化するよう使用される。

図９は、本発明に従った一実施形態において、１つ以上のカスタマイゼーションを含む図２のデスクトップ統合フレームワーク２００を使用してドキュメントを実行するための方法９００のフローチャートである。図９に示される方法９００の実現または処理は、コンピュータシステムまたは情報処理デバイスのようなロジックマシンの中央処理装置（ＣＰＵまたはプロセッサ）によって実行される際にソフトウェア（たとえば命令またはコードモジュール）によって実行され得るか、電子デバイスまたは特定用途向け集積回路のハードウェアコンポーネントによって実行され得るか、または、ソフトウェアおよびハードウェア要素の組合せによって実行され得る。図９に示される方法９００は、ステップ９１０において開始する。

ステップ９２０において、ドキュメントおよび初期メタデータが受け取られる。たとえば、ユーザは、発行されたドキュメント２５０をアプリケーションサーバ２６０からダウンロードすることを要求し得る。ステップ９３０において、メタデータカスタマイゼーションが要求される。１つの局面において、ドキュメントダウンロードは、ドキュメント２５０にて完了し得、その時、ドキュメント２５０がアプリケーション２３０で開かれ得る。その後、ＡＤＦ−ＤＩクライアントコンポーネント２４０は、ドキュメント２５０が与えられる必要があると検出し得る。ＡＤＦ−ＤＩクライアントコンポーネント２４０はＡＤＦ−ＤＩサーバコンポーネント２７０とコンタクトし、ドキュメントのデザインに従って与えられるべきドキュメントメタデータおよび任意の実データを得る。

さまざまな局面において、ワークブック初期化の際、ＡＤＦ−ＤＩクライアントコンポーネント２４０は、現在のワークブックのメタデータについてサーバコンピュータシステム２２０への要求を発する。ＡＤＦ−ＤＩサーバコンポーネント２７０は、メタデータサーバ２９０を介して現在のＡＤＦコンテキストから標準ＭＤＳセッションを得、このＭＤＳセッションを使用してワークブックメタデータを抽出する。ＭＤＳセッションに関連付けられるカスタマイゼーションのコンテキストに基づいて、メタデータサーバ２９０は、ワークブックメタデータに全てのカスタマイゼーションを適用する。カスタマイズされたワークブックメタデータは、ＡＤＦ−ＤＩクライアントコンポーネント２４０に返される。カスタマイズされたワークブックメタデータは、ランタイムワークブックを初期化するために使用される。

ステップ９４０において、ドキュメントおよびカスタマイズされたメタデータが処理される。ＡＤＦ−ＤＩクライアントコンポーネント２４０は、コンポーネントの配置を決定し、ステップ９５０においてＡＤＦ−ＤＩサーバコンポーネント２７０によって提供される実データを利用して当該コンポーネントをドキュメント２５０のコンテンツとして与える。図９はステップ９６０で終了する。

ワークブックコンポーザ
さまざまな実施形態において、カスタマイゼーションがさまざまなツールおよびインターフェイスを利用してなされ得る。エンドユーザがデスクトップ統合フレームワークを使用して開発されたドキュメントのランタイムカスタマイゼーションを提供することを可能にする方法、システムおよび一時的でないコンピュータ読取可能媒体が開示される。ワークブックメタデータは、所与のワークブックが特定のウェブアプリケーションにどのように統合されるか記述する情報のセットである。ワークブックが発行されている場合、メタデータは、発行されたワークブックにおけるローカルキャッシュとワークブック定義ファイルとに書き込まれ得る。メタデータ管理は、メタデータサービスによって扱われ得、発行されたワークブックおよびワークブック定義ファイルにおけるローカルキャッシュから独立して、発行されたワークブックの更新およびカスタマイゼーションを可能にする。ワークブックカスタマイゼーションエディタは、統合されたワークブックのさまざまなカスタマイゼーションを実行するために使用される。

図１０は、本発明に従った一実施形態においてメタデータをカスタマイズするためのユーザインターフェイス１０００のスクリーンショットである。この例において、ユーザインターフェイス１０００は、統合されたワークシートを所与のワークブックから選択する能力、選択されたワークシート上のコンポーネントを閲覧および選択する能力、または、選択されたコンポーネントを編集または削除する能力を提供する。いくつかの実施形態において、ユーザインターフェイス１０００は、新しいワークシートを追加する能力、新しいコンポーネントを追加する能力、または、アクションセットのような既存のコンポーネントの高度なプロパティを編集する能力を提供し得る。

動作の一例において、ウェブアプリケーションが送られて、Ａｃｍｅ社にインストールされる。Ａｃｍｅ社のビジネスアナリストであるラルフは、統合されたワークブックをレビューし、いくつかの調節が必要であると判断する。ラルフは、ウェブアプリケーションにログインし、ユーザインターフェイス１０００にナビゲートする。ラルフは、ベースワークブックの新しいカスタマイゼーションを作成することを決定する。ラルフは、テーブルにおける標準的な６５カラムから５カラムを除去する。なぜならば、ラルフは、Ａｃｍｅ社がそれらのカラムを必要としない／望まないことを知っているからである。ラルフはカスタマイゼーションを保存する。ここで、当該カスタマイゼーションは、ワークブックカスタマイゼーションに関連付けられるカスタマイゼーションのコンテキストと一致するユーザについて利用可能である。そのようなユーザは、６０カラムを有するテーブルを見ることになる。

別の例において、ユーザインターフェイス１０００は、承認されたユーザが所与の統合されたワークブックのさまざまな局面を編集することを可能にするＡＤＦタスクフロー（ADF Task Flow）の部分を形成する。上で論じたように、ユーザインターフェイス１０００は、選択されたワークブックから、統合されたワークシートのリストを提供し得る。ユーザインターフェイス１０００は、ユーザがワークブックおよび／またはワークシートを選択および／または削除することを可能にする機能を含み得る。ユーザインターフェイス１０００は、選択されたワークシートに現われるかまたはそうでなければ選択されたワークシートに関連付けられるコンポーネントのリストを含み得る。ユーザインターフェイス１０００は、ユーザがコンポーネントを選択し、削除し、編集することを可能にする機能を含み得る。ユーザインターフェイス１０００は、ユーザがテキスト入力（Input-Text）、テキスト出力（Output-Text）、ラベル（Label）、値のリスト（List-of-Values）といったコンポーネントのプロパティを編集することができる機能を含み得る。たとえば、ドキュメント２５０のデベロッパは、コンポーネントＩＤ、値、注釈などといったコンポーネントのどの局面が閲覧可能（閲覧のみ）であるか、または、スタイル、ツールティップ、リードオンリ、ポジションのように編集可能であるか特定し得る。デベロッパは、たとえばソース、ＳｈｏｒｔＤｅｓｃ、ポジションなどといったイメージコンポーネントについて、また、ラベル、ポジションなどといったボタンコンポーネントについて、コンポーネントのどの局面が編集可能であるか特定し得る。別の局面において、デベロッパは、テーブルコンポーネントのどの局面が閲覧可能（閲覧のみ）および編集可能であるかを特定し得る。いくつかの例は、コンポーネントの削除のみで編集可能でない読取専用テーブルを含むか、または、ポジション、カラムの編集（削除、編集、再配置すべきかどうか）、セル／ヘッダスタイル、ツールティップ、ビジブル（Visible）、ヘッダラベルの編集を許可し、かつ、特別なカラムの削除を防止する。

さまざまな局面において、ホストアプリケーションは、（メタデータパスおよびワークブック名を含む）編集されるべきワークブックおよびカスタマイゼーションのコンテキストのようなさまざまな情報をユーザインターフェイス１０００に提供する。さらに、ホストアプリケーションは、ユーザインターフェイス１０００のどのユーザがどのワークブック（存在する場合）を編集してもよいのかを制御することを担い得る。

結論
図のうちのいくつかに示されるシステムは、さまざまな構成で提供され得る。いくつかの実施形態において、システムは、システムの１つ以上のコンポーネントがクラウドコンピューティングシステムにおいて１つ以上のネットワークにわたって分散される分散システムとして構成され得る。

図１１は、実施形態のうちの１つを実現するための分散システム１１００の簡略図を示す。例示される実施形態において、分散システム１１００は、１つ以上のネットワーク１１１０にわたって、ウェブブラウザまたはプロプラエタリクライアント（たとえばオラクルフォームズ（Oracle Forms）などといったクライアントアプリケーションを実行および動作するように構成される１つ以上のクライアントコンピューティングデバイス１１０２、１１０４、１１０６および１１０８を含む。サーバ１１１２は、ネットワーク１１１０を介してリモートクライアントコンピューティングデバイス１１０２、１１０４、１１０６および１１０８と通信可能に結合され得る。

さまざまな実施形態において、サーバ１１１２は、システムのコンポーネントのうちの１つ以上によって提供される１つ以上のサービスまたはソフトウェアアプリケーションを実行するように適合され得る。いくつかの実施形態において、これらのサービスは、ウェブベースのサービスもしくはクラウドサービスとして、または、ソフトウェアアズアサービス（ＳａａＳ：Software as a Service）モデルで、クライアントコンピューティングデバイス１１０２、１１０４、１１０６および／または１１０８のユーザに提供され得る。クライアントコンピューティングデバイス１１０２、１１０４、１１０６および／または１１０８を操作するユーザは、１つ以上のクライアントアプリケーションを利用して、これらのコンポーネントによって提供されるサービスを利用するようサーバ１１１２と相互作用する。

図に示される構成において、システム１１００のソフトウェアコンポーネント１１１８、１１２０および１１２２は、サーバ１１１２上で実現されるのが示される。他の実施形態において、システム１１００のコンポーネントおよび／またはこれらのコンポーネントによって提供されるサービスのうちの１つ以上が、クライアントコンピューティングデバイス１１０２、１１０４、１１０６および／または１１０８の１つ以上によって実現され得る。次いで、クライアントコンピューティングデバイスを操作するユーザは、１つ以上のクライアントアプリケーションを利用し、これらのコンポーネントによって提供されるサービスを使用する。これらのコンポーネントは、ハードウェア、ファームウェア、ソフトウェアまたはその組合せで実現され得る。分散システム１１００と異なり得るさまざまな異なるシステム構成が可能であるということが認識されるべきである。したがって、図において示される実施形態は、実施形態のシステムを実現するための分散システムの一例であり、限定するようには意図されない。

クライアントコンピューティングデバイス１１０２、１１０４、１１０６および／または１１０８は、ポータブルハンドヘルドデバイス（たとえばｉＰｈｏｎｅ（登録商標）、携帯電話、ｉＰａｄ（登録商標）、コンピューティングタブレット、携帯情報端末（ＰＤＡ））もしくはウェアラブルデバイス（たとえばＧｏｏｇｌｅ Ｇｌａｓｓ（登録商標）ヘッドマウントディスプレイ）であり得るか、または、Ｍｉｃｒｏｓｏｆｔ Ｗｉｎｄｏｗｓ Ｍｏｂｉｌｅ（登録商標）のような実行しているソフトウェアおよび／もしくはｉＯＳ、Ｗｉｎｄｏｗｓ Ｐｈｏｎｅ、Ａｎｄｒｏｉｄ、ＢｌａｃｋＢｅｒｒｙ１０およびＰａｌｍ ＯＳなどといったさまざまなモバイルのオペレーティングシステムであるか、または、インターネット、電子メール、ショートメッセージサービス（ＳＭＳ：short message service）、Ｂｌａｃｋｂｅｒｒｙ（登録商標）または他の通信プロトコルが有効化されたものである。クライアントコンピューティングデバイスは、例としてＭｉｃｒｏｓｏｆｔ Ｗｉｎｄｏｗｓ（登録商標）、Ａｐｐｌｅ Ｍａｃｉｎｔｏｓｈ（登録商標）および／またはＬｉｎｕｘ（登録商標）オペレーティングシステムのさまざまなバージョンが実行されるパーソナルコンピュータおよび／またはラップトップコンピュータを含む汎用のパーソナルコンピュータであり得る。クライアントコンピューティングデバイスは、たとえばＧｏｏｇｌｅ ＣｈｒｏｍｅＯＳのようなさまざまなＧＮＵ／Ｌｉｎｕｘオペレーティングシステムを含むがそれらに限定されないさまざまな商業的に利用可能なＵＮＩＸ（登録商標）またはＵＮＩＸライクなオペレーティングシステムのいずれかが実行されるワークステーションコンピュータであり得る。代替的または付加的には、クライアントコンピューティングデバイス１１０２、１１０４、１１０６および１１０８は、シンクライアントコンピュータ、インターネットが有効化されたゲームシステム（たとえばＫｉｎｅｃｔ（登録商標）ジェスチャ入力デバイスを有するかまたは有さないＭｉｃｒｏｓｏｆｔ Ｘｂｏｘゲームコンソール）、および／または、パーソナルメッセージデバイスといった、ネットワーク１１１０上で通信可能である任意の他の電子デバイスであり得る。

例示的な分散システム１１００が４つのクライアントコンピューティングデバイスを有するのが示されるが、任意数のクライアントコンピューティングデバイスがサポートされ得る。センサなどを有するデバイスのような他のデバイスがサーバ１１１２と相互作用し得る。

分散システム１１００におけるネットワーク１１１０は、さまざまな商業的に利用可能なプロトコルのうちのいずれかを使用してデータ通信をサポートし得る当業者によく知られている任意のタイプのネットワークであり得、当該プロトコルは、ＴＣＰ／ＩＰ（transmission control protocol/Internet protocol；トランスミッションコントロールプロトコル／インターネットプロトコル）、ＳＮＡ（systems network architecture；システムネットワークアーキテクチャ）、ＩＰＸ（Internet packet exchange；インターネットパケットエクスチェンジ）、およびＡｐｐｌｅＴａｌｋなどを含むがこれらに限定されない。単に例として、ネットワーク１１１０は、イーサネット（登録商標）および／またはトークンリングなどに基づいたもののようなローカルエリアネットワーク（ＬＡＮ）であり得る。ネットワーク１１１０はワイドエリアネットワークおよびインターネットであり得る。ネットワーク１１１０はバーチャルネットワークを含み得、当該バーチャルネットワークは、バーチャルプライベートネットワーク（ＶＰＮ：virtual private network）、イントラネット、エクストラネット、公衆交換電話網（ＰＳＴＮ：public switched telephone network）、赤外線ネットワーク、無線ネットワーク（たとえばＩＥＥＥ（Institute of Electrical and Electronics；電気電子技術者協会）８０２．１１スイート、Ｂｌｕｅｔｏｏｔｈ（登録商標）、および／もしくは任意の他の無線プロトコルのいずれかに基づき動作するネットワーク）、ならびに／または、これらおよび／もしくは他のネットワークの任意の組合せを含むがこれらに限定されない。

サーバ１１１２は、１つ以上の汎用コンピュータ、専用サーバコンピュータ（例として、ＰＣ（パーソナルコンピュータ）サーバ、ＵＮＩＸ（登録商標）サーバ、ミッドレンジサーバ、メインフレームコンピュータ、ラックマウントサーバなどを含む）、サーバファーム、サーバクラスタまたは任意の他の適切な構成および／もしくは組合せから構成され得る。さまざまな実施形態において、サーバ１１１２は、上記の開示に記載される１つ以上のサービスまたはソフトウェアアプリケーションを実行するよう適合され得る。たとえば、サーバ１１１２は、本開示の実施形態に従った、上に記載された処理を実行するためのサーバに対応し得る。

サーバ１１１２は、上に論じられたもののいずれかを含むオペレーティングシステムと、任意の商業的に利用可能なサーバオペレーティングシステムとを実行し得る。サーバ１１１２はさらに、ＨＴＴＰ（hypertext transport protocol；ハイパーテキストトランスポートプロトコル）サーバと、ＦＴＰ（file transfer protocol；ファイル転送プロトコル）サーバと、ＣＧＩ（common gateway interface；コモンゲートウェイインターフェイス））サーバと、ＪＡＶＡ（登録商標）サーバと、データベースサーバなどとを含む、さまざまな付加的なサーバアプリケーションおよび／または中間層アプリケーションのいずれかを実行し得る。例示的なデータベースサーバは、オラクル、マイクロソフト、Ｓｙｂａｓｅ、ＩＢＭ（International Business Machines）などから商業的に利用可能なものを含むがこれらに限定されない。

いくつかの実現例において、サーバ１１１２は、クライアントコンピューティングデバイス１１０２、１１０４、１１０６および１１０８のユーザから受け取られるデータフィードおよび／またはイベント更新を分析および統合するよう、１つ以上のアプリケーションを含み得る。例として、データフィードおよび／またはイベント更新は、Ｔｗｉｔｔｅｒ（登録商標）フィード、Ｆａｃｅｂｏｏｋ（登録商標）更新、または、１つ以上のサードパーティ情報ソースおよび連続的なデータストリームから受け取られるリアルタイム更新を含み得るがこれらに限定されない。当該リアルタイム更新は、センサデータアプリケーション、金融相場表示器（financial ticker）、ネットワークパフォーマンス測定ツール（たとえばネットワーク監視およびトラフィック管理アプリケーション）、クリックストリーム解析ツール、および自動車交通監視などに関連付けられるリアルタイムイベントを含み得る。サーバ１１１２はさらに、クライアントコンピューティングデバイス１１０２、１１０４、１１０６および１１０８の１つ以上のディスプレイデバイスを介してデータフィードおよび／またはリアルタイムイベントを表示するために１つ以上のアプリケーションを含み得る。

分散システム１１００はさらに、１つ以上のデータベース１１１４および１１１６を含み得る。データベース１１１４および１１１６はさまざまな場所に存在し得る。例として、データベース１１１４および１１１６のうちの１つ以上は、サーバ１１１２に対してローカルである（および／またはサーバ１１１２に存在する）一時的でないストレージ媒体上に存在し得る。代替的には、データベース１１１４および１１１６は、サーバ１１１２からリモートであり得、ネットワークベースまたは専用の接続を介してサーバ１１１２と通信し得る。実施形態の１つのセットにおいて、データベース１１１４および１１１６は、ストレージエリアネットワーク（ＳＡＮ：storage-area network）に存在し得る。同様に、サーバ１１１２に起因する機能を実行するための任意の必要なファイルは、適切なように、サーバ１１１２上にローカルにおよび／またはリモートに格納され得る。実施形態の１つのセットにおいて、データベース１１１４および１１１６は、オラクルによって提供されるデータベースのような、ＳＱＬフォーマットのコマンドに応答してデータを格納、更新および抽出するように適合されるリレーショナルデータベースを含み得る。

図１２は、本発明のさまざまな実施形態が実現され得る例示的なコンピュータシステム１２００を示す。システム１２００は、上に記載されたコンピュータシステムのいずれかを実現するよう使用され得る。当該図に示されるように、コンピュータシステム１２００は、バスサブシステム１２０２を介して多くの周辺サブシステムと通信する処理ユニット１２０４を含む。これらの周辺サブシステムは、処理加速ユニット１２０６、Ｉ／Ｏサブシステム１２０８、ストレージサブシステム１２１８、および通信サブシステム１２２４を含み得る。ストレージサブシステム１２１８は、有形的なコンピュータ読取可能ストレージ媒体１２２２およびシステムメモリ１２１０を含む。

バスサブシステム１２０２は、コンピュータシステム１２００のさまざまなコンポーネントおよびサブシステムを意図されるように互いと通信させるためのメカニズムを提供する。バスサブシステム１２０２は単一のバスとして概略的に示されるが、バスサブシステムの代替的な実施形態は複数のバスを利用してもよい。バスサブシステム１２０２は、メモリバスまたはメモリコントローラと、周辺バスと、さまざまなバスアーキテクチャのうちのいずれかを使用するローカルバスとを含むいくつかのタイプのバス構造のうちのいずれかであり得る。たとえば、そのようなアーキテクチャは、産業標準アーキテクチャ（ＩＳＡ：Industry Standard Architecture）バスと、マイクロチャネルアーキテクチャ（ＭＣＡ：Micro Channel Architecture）バスと、エンハンスドＩＳＡ（ＥＩＳＡ：Enhanced ISA）バスと、ビデオエレクトロニクス標準組織（ＶＥＳＡ：Video Electronics Standards Association）ローカルバスと、ＩＥＥＥ Ｐ１３８６．１規格に対して製造されるメザニーン（Mezzanine）バスとして実現され得るペリフェラルコンポーネントインターコネクト（ＰＣＩ：Peripheral Component Interconnect）バスとを含み得る。

１つ以上の集積回路として実現され得る処理ユニット１２０４（たとえば従来のマイクロプロセッサまたはマイクロコントローラ）は、コンピュータシステム１２００の動作を制御する。１つ以上のプロセッサが処理ユニット１２０４に含まれ得る。これらのプロセッサは、シングルコアまたはマルチコアプロセッサを含み得る。ある実施形態において、処理ユニット１２０４は、各処理ユニットに含まれるシングルまたはマルチコアプロセッサを有する１つ以上の独立した処理ユニット１２３２および／または１２３４として実現され得る。他の実施形態において、処理ユニット１２０４はさらに、シングルチップに２つのデュアルコアプロセッサを統合することにより形成されるクアッドコア処理ユニットとして実現され得る。

さまざまな実施形態において、処理ユニット１２０４は、プログラムコードに応答してさまざまなプログラムを実行し得、複数の同時に実行されているプログラムまたはプロセスを維持し得る。任意の所与の時間において、実行されるべきプログラムコードのうちのいくつかまたはすべては、プロセッサ１２０４および／またはストレージサブシステム１２１８において存在し得る。好適なプログラミングを通じて、プロセッサ１２０４は上に記載されたさまざまな機能を提供し得る。コンピュータシステム１２００はさらに、デジタル信号プロセッサ（ＤＳＰ）および／または特殊目的プロセッサなどを含み得る処理加速ユニット１２０６を含み得る。

Ｉ／Ｏサブシステム１２０８は、ユーザインターフェイス入力デバイスおよびユーザインターフェイス出力デバイスを含み得る。ユーザインターフェイス入力デバイスは、キーボードと、マウスまたはトラックボールのようなポインティングデバイスと、ディスプレイに組み込まれるタッチパッドまたはタッチスクリーンと、スクロールホイールと、クリックホイールと、ダイヤルと、ボタンと、スイッチと、キーパッドと、音声コマンド認識システムを有する音声入力デバイスと、マイクロフォンと、他のタイプの入力デバイスとを含み得る。ユーザインターフェイス入力デバイスは、たとえば、ジェスチャおよび音声コマンドを使用する自然なユーザインターフェイスを通じて、ユーザがＭｉｃｒｏｓｏｆｔ Ｘｂｏｘ（登録商標）３６０ゲームコントローラのような入力デバイスを用いて制御および相互作用を行い得るＭｉｃｒｏｓｏｆｔ Ｋｉｎｅｃｔ（登録商標）モーションセンサのようなモーション感知および／またはジェスチャ認識デバイスを含み得る。ユーザインターフェイス入力デバイスはさらに、Ｇｏｏｇｌｅ Ｇｌａｓｓ（登録商標）まばたき検出器のようなアイジェスチャ（eye gesture）認識デバイスを含み得る。当該アイジェスチャ認識デバイスは、ユーザの目の活動（たとえば写真を撮る間またはメニューの選択をする間の「まばたき」）を検出し、入力デバイス（たとえば、Ｇｏｏｇｌｅ Ｇｌａｓｓ（登録商標））への入力としてアイジェスチャを変換する。さらに、ユーザインターフェイス入力デバイスは、ユーザが音声コマンドを通じて音声認識システム（たとえばＳｉｒｉ（登録商標）ナビゲータ）と相互作用することを可能にする音声認識検出デバイスを含み得る。

ユーザインターフェイス入力デバイスはさらに、３次元（３Ｄ）マウスと、ジョイスティックまたはポインティングスティックと、ゲームパッドおよびグラフィックタブレットと、スピーカ、デジタルカメラ、デジタルカムコーダ、ポータブルメディアプレイヤー、ウェブカメラ、イメージスキャナ、指紋スキャナ、バーコードリーダ３Ｄスキャナ、３Ｄプリンタ、レーザ距離測定器および視線トラッキングデバイスといったオーディオ／ビジュアルデバイスとを含み得るがこれらに限定されない。さらに、ユーザインターフェイス入力デバイスはたとえば、コンピュータ断層撮影デバイス、磁気共鳴映像デバイス、ポジトロン断層（position emission tomography）デバイス、医療超音波検査デバイスといった医療用画像入力デバイスを含み得る。ユーザインターフェイス入力デバイスはさらに、たとえばＭＩＤＩキーボードおよびデジタル楽器などのような音声入力デバイスを含み得る。

ユーザインターフェイス出力デバイスは、ディスプレイサブシステム、インジケータライト、または音声出力デバイスのような非視覚的ディスプレイを含み得る。ディスプレイサブシステムは、陰極線管（ＣＲＴ）、液晶ディスプレイ（ＬＣＤ）またはプラズマディスプレイを使用するもののようなフラットパネルデバイス、投写デバイス、およびタッチスクリーンなどであり得る。一般に、「出力デバイス」という用語の使用は、コンピュータシステム１２００からユーザまたは他のコンピュータに情報を出力するためのすべての可能なタイプのデバイスおよびメカニズムを含むように意図される。たとえば、ユーザインターフェイス出力デバイスは、モニタ、プリンタ、スピーカ、ヘッドフォン、自動車ナビゲーションシステム、プロッタ、音声出力デバイスおよびモデムといった、テキスト、グラフィックスおよびオーディオ／ビデオ情報を視覚的に伝えるさまざまなディスプレイデバイスを含み得るがこれらに限定されない。

コンピュータシステム１２００は、現在、システムメモリ１２１０内に位置するのが示されているソフトウェア要素を含むストレージサブシステム１２１８を含み得る。システムメモリ１２１０は、処理ユニット１２０４上でロード可能および実行可能であるプログラム命令と、これらのプログラムの実行の間に生成されるデータとを格納し得る。

コンピュータシステム１２００の構成およびタイプに依存して、システムメモリ１２１０は、（ランダムアクセスメモリ（ＲＡＭ）のように）揮発性および／または（リードオンリメモリ（ＲＯＭ）、フラッシュメモリなどのように）不揮発性であり得る。ＲＡＭは典型的に、処理ユニット１２０４に直ちにアクセス可能であるか、または、処理ユニット１２０４によって現在動作および実行されているデータおよび／もしくはプログラムモジュールを含む。いくつかの実現例において、システムメモリ１２１０は、スタティックランダムアクセスメモリ（ＳＲＡＭ）またはダイナミックランダムアクセスメモリ（ＤＲＡＭ）のような複数の異なるタイプのメモリを含み得る。いくつかの実現例において、たとえば起動の間、コンピュータシステム１２００内において要素間で情報を転送するのを補助する基本ルーチンを含む基本入出力システム（ＢＩＯＳ）は、典型的にＲＯＭに格納され得る。限定ではなく例として、システムメモリ１２１０はさらに、クライアントアプリケーション、ウェブブラウザ、中間層アプリケーション、リレーショナルデータベース管理システム（ＲＤＢＭＳ：relational database management system）などを含み得るアプリケーションプログラム１２１２と、プログラムデータ１２１４と、オペレーティングシステム１２１６とを示す。例として、オペレーティングシステム１２１６は、Ｍｉｃｒｏｓｏｆｔ Ｗｉｎｄｏｗｓ（登録商標）、Ａｐｐｌｅ Ｍａｃｉｎｔｏｓｈ（登録商標）、および／またはＬｉｎｕｘオペレーティングシステム、さまざまな商業的に利用可能なＵＮＩＸ（登録商標）またはＵＮＩＸライクのオペレーティングシステムのさまざまなバージョン（さまざまなＧＮＵ／ＬｉｎｕｘオペレーティングシステムおよびＧｏｏｇｌｅ Ｃｈｒｏｍｅ（登録商標）ＯＳなどを含むがこれらに限定されない）、および／または、ｉＯＳ、Ｗｉｎｄｏｗｓ（登録商標）Ｐｈｏｎｅ、Ａｎｄｒｏｉｄ（登録商標）ＯＳ、ＢｌａｃｋＢｅｒｒｙ（登録商標）１０ ＯＳおよびＰａｌｍ（登録商標）ＯＳオペレーティングシステムといったモバイルオペレーティングシステムを含み得る。

ストレージサブシステム１２１８はさらに、いくつかの実施形態の機能を提供する基本的なプログラミングおよびデータ構造を格納するための有形的なコンピュータ読取可能ストレージ媒体を提供し得る。プロセッサによって実行されると上記の機能を提供するソフトウェア（プログラム、コードモジュール、指示）がストレージサブシステム１２１８に格納され得る。これらのソフトウェアモジュールまたは命令は、処理ユニット１２０４によって実行され得る。ストレージサブシステム１２１８は、さらに本発明に従って使用されるデータを格納するためのリポジトリを提供し得る。

ストレージサブシステム１２００はさらに、コンピュータ読取可能ストレージ媒体１２２２に接続され得るコンピュータ読取可能ストレージ媒体リーダ１２２０を含み得る。一緒および随意に、システムメモリ１２１０と組み合わせて、コンピュータ読取可能ストレージ媒体１２２２は、リモートストレージデバイス、ローカルストレージデバイス、固定ストレージデバイス、および／または、リムーバブルストレージデバイスに加え、コンピュータ読取可能な情報を一時的および／またはより永久的に包含、格納、送信、および抽出するためのストレージ媒体を包括的に表す。

コードまたはコードの部分を含むコンピュータ読取可能ストレージ媒体１２２２は、ストレージ媒体および通信媒体を含む当該技術において公知または使用される任意の適切な媒体を含み得、当該媒体の例としては、情報の格納および／または送信のための任意の方法または技術において実現される揮発性媒体、不揮発性媒体、リムーバブル媒体および非リムーバブル媒体があるが、これらに限定されない。これは、ＲＡＭ、ＲＯＭ、電気的消却プログラム可能型ＲＯＭ（ＥＥＰＲＯＭ：electronically erasable programmable ROM）、フラッシュメモリもしくは他のメモリ技術、ＣＤ−ＲＯＭ、デジタルバーサタイルディスク（ＤＶＤ）もしくは他の光学ストレージ、磁気カセット、磁気テープ、磁気ディスクストレージもしくは他の磁気ストレージデバイス、または他の有形的なコンピュータ読取可能媒体といった有形的なコンピュータ読取可能ストレージ媒体を含み得る。これはさらに、所望の情報を送信するために使用され得るとともにコンピューティングシステム１２００によってアクセスされ得るデータ信号、データ伝送または任意の他の媒体といった非有形的なコンピュータ読取可能媒体を含み得る。

例として、コンピュータ読取可能ストレージ媒体１２２２は、非リムーバブル不揮発性磁気媒体に対して読出または書込を行うハードディスクドライブと、リムーバブル不揮発性磁気ディスクに対して読出または書込を行う磁気ディスクドライブと、ＣＤ ＲＯＭ、ＤＶＤおよびＢｌｕ−Ｒａｙ（登録商標）ディスクまたは他の光学媒体といったリムーバブル不揮発性光学ディスクに対して読出または書込を行う光学ディスクドライブとを含み得る。コンピュータ読取可能ストレージ媒体１２２２は、Ｚｉｐ（登録商標）ドライブ、フラッシュメモリカード、ユニバーサルシリアルバス（ＵＳＢ）フラッシュドライブ、セキュアデジタル（ＳＤ）カード、ＤＶＤディスク、およびデジタルビデオテープなどを含み得るがこれらに限定されない。コンピュータ読取可能ストレージメディア１２２２はさらに、フラッシュメモリベースのＳＳＤ、エンタープライズフラッシュドライブ、およびソリッドステートＲＯＭなどのような不揮発性メモリに基づいたソリッドステートドライブ（ＳＳＤ）と、ソリッドステートＲＡＭ、ダイナミックＲＡＭ、スタティックＲＡＭ、ＤＲＡＭベースのＳＳＤ、磁気抵抗ＲＡＭ（ＭＲＡＭ：magnetoresistive RAM）ＳＳＤ、ならびに、ＤＲＡＭおよびフラッシュメモリベースのＳＳＤの組合せを使用するハイブリッドＳＳＤといった揮発性メモリに基づくＳＳＤとを含み得る。ディスクドライブおよびそれらの関連付けられるコンピュータ読取可能媒体は、コンピュータ読取可能な指示、データ構造、プログラムモジュールおよびコンピュータシステム１２００のための他のデータの不揮発性ストレージを提供し得る。

通信サブシステム１２２４は、他のコンピュータシステムおよびネットワークにインターフェイスを提供する。通信サブシステム１２２４は、コンピュータシステム１２００からデータを受け取るとともに他のシステムにデータを送信するためのインターフェイスとして機能する。たとえば通信サブシステム１２２４は、コンピュータシステム１２００がインターネットを介して１つ以上のデバイスに接続することを可能にし得る。いくつかの実施形態において、通信サブシステム１２２４は、（たとえば、携帯電話技術、３Ｇ、４ＧまたはＥＤＧＥ（enhanced data rates for global evolution）のような高度なデータネットワーク技術、ＷｉＦｉ（ＩＥＥＥ ８０２．１１ファミリ規格、他のモバイル通信技術、またはその任意の組合せを使用する）無線音声および／またはデータネットワークにアクセスするための無線周波数（ＲＦ）トランシーバコンポーネント、グローバルポジショニングシステム（ＧＰＳ：global positioning system）受信コンポーネント、および／または、他のコンポーネントを含み得る。いくつかの実施形態において、通信サブシステム１２２４は、無線インターフェイスに加えてまたは無線インターフェイスの代わりに、有線ネットワーク接続（たとえばイーサネット）を提供し得る。

いくつかの実施形態において、通信サブシステム１２２４はさらに、コンピュータシステム１２００を使用し得る１人以上のユーザに代わって、構造化されたデータおよび／または構造化されていないデータフィード１２２６、イベントストリーム１２２８およびイベント更新１２３０などの形態にある入力通信を受け取り得る。

例として、通信サブシステム１２２４は、Ｔｗｉｔｔｅｒ（登録商標）フィード、Ｆａｃｅｂｏｏｋ（登録商標）更新、リッチサイトサマリ（ＲＳＳ：Rich Site Summary）フィードのようなウェブフィード、および／または、１つ以上のサードパーティの情報ソースからのリアルタイム更新といったソーシャルネットワークおよび／または他の通信サービスのユーザからデータフィード１２２６をリアルタイムで受け取るように構成され得る。

さらに、通信サブシステム１２２４は、リアルタイムイベントのイベントストリーム１２２８および／またはイベント更新１２３０を含み得る連続的なデータストリームの形態でデータを受け取るように構成され得る。当該連続的なデータストリームは、性質において明示的な終わりを有さない連続的または無限であり得る。連続的なデータを生成するアプリケーションの例はたとえば、センサデータアプリケーション、金融相場表示器、ネットワークパフォーマンス測定ツール（たとえばネットワーク監視およびトラフィック管理アプリケーション）、クリックストリーム解析ツール、および自動車交通監視などを含み得る。

通信サブシステム１２２４はさらに、構造化されたおよび／または構造化されていないデータフィード１２２６、イベントストリーム１２２８、およびイベント更新１２３０などを、コンピュータシステム１２００に結合された１つ以上のストリーミングデータソースコンピュータと通信する１つ以上のデータベースに出力するように構成され得る。

コンピュータシステム１２００は、ハンドヘルドポータブルデバイス（たとえばｉＰｈｏｎｅ（登録商標）携帯電話、ｉＰａｄ（登録商標）コンピューティングタブレット、ＰＤＡ）、ウェアラブルデバイス（たとえばＧｏｏｇｌｅ Ｇｌａｓｓ（登録商標）ヘッドマウントディスプレイ）、ＰＣ、ワークステーション、メインフレーム、キオスク、サーバラック、または任意の他のデータ処理システムを含むさまざまなタイプのうちの１つであり得る。

コンピュータおよびネットワークの絶えず変化する性質により、図において示されるコンピュータシステム１２００の記載は特定の例としてのみ意図される。当該図に示されたシステムよりも多くまたは少ないコンポーネントを有する多くの他の構成が可能である。たとえば、カスタマイズされたハードウェアも使用され得、および／または、特定の要素が、ハードウェア、ファームウェア、ソフトウェア（アプレットを含む）、または組合せで実現され得る。さらに、ネットワーク入出力デバイスのような他のコンピューティングデバイスへの接続も採用され得る。本願明細書において提供される開示および教示に基づいて、当業者は、さまざまな実施形態を実現する他の態様および／または方法を認識するであろう。

上記明細書において、本発明の局面はその特定の実施形態を参照して記載されるが、当業者は本発明がそれに限定されないことを認識するであろう。上記の発明のさまざまな特徴および局面は個々にまたは共同で使用され得る。さらに、実施形態は、明細書のより広い精神および範囲から逸脱することなく本願明細書において記載された環境および適用例を越えて、任意数の環境および適用例において利用され得る。したがって、明細書および図面は、限定ではなく例示であるとみなされるべきである。

その教示がこの開示内に示され得る１つ以上の発明のいずれかのさまざまな実施形態がソフトウェア、ファームウェア、ハードウェアまたはその組合せにおけるロジックの形で実現され得る。ロジックは、この開示において示された発明のさまざまな実施形態において開示され得るステップのセットを実行するために、ロジックマシンの中央処理装置（ＣＰＵまたはプロセッサ）を指示するように適合される命令のセットとして、マシンアクセス可能なメモリ、マシン読取可能な物品、有形的なコンピュータ読取可能媒体、コンピュータ読取可能ストレージ媒体、または他のコンピュータ／マシン読取可能媒体に格納され得る。ロジックは、この開示に示される発明のさまざまな実施形態における方法またはプロセスを行うよう実行される際に、コードモジュールがコンピュータシステムまたは情報処理デバイスのプロセッサにより作動状態になると、ソフトウェアプログラムまたはコンピュータプログラムプロダクトの一部を形成し得る。本願明細書において提供されるこの開示および教示に基づいて、示された発明の１つ以上のさまざまな実施形態の開示されたオペレーションまたは機能のいずれかをソフトウェア、ファームウェア、ハードウェアまたはその組合せで実現するための他の態様、変形例、修正例、代替例および／または方法を当業者は理解するであろう。

その教示がこの開示に示され得るそれらの発明のいずれか１つの開示された例、実現例およびさまざまな実施形態は、当業者にこの開示の教示を妥当な明瞭さで伝えるために単に例示的である。これらの実現例および実施形態は例示的な図または特定の図を参照して記載され得る際に、記載される方法および／または特定の構造のさまざまな修正例または適合例は当業者に明らかになり得る。本願明細書において発見されるこの開示およびこれらの教示に依存し、かつ、当該教示によって技術を進歩させたすべてのそのような修正例、適合例または変形例は、その教示がこの開示内に示され得る１つ以上の発明の範囲内に存在すると考えられるべきである。したがって、開示内に示された発明が具体的に示される実施形態にまったく限定されないということが理解されるので、この記載および図は限定的な意味で考えられるべきでない。

したがって、上記の記載および如何なる添付の図面、説明および図は、例示的であるが限定的ではないように意図される。したがって、この開示に示される如何なる発明の範囲も、上記の記載および図に示されるそれらの実施形態を単純に参照してではなく、それらの完全な範囲または均等物とともに係属中の請求項を参照して決定されるべきである。

Claims (16)

1. ウェブベースの複数のレイヤーからなるアプリケーションのためのユーザインターフェイスとして機能するデスクトップアプリケーションのドキュメントを作成するための方法であって、
   コンピュータシステムのうちのサーバコンピュータにてドキュメントを作成することと、
   前記ドキュメントについてのメタデータに関連付けられるルールのセットを前記サーバコンピュータによって決定することとを含み、前記メタデータは、前記ドキュメントに含まれる各コンポーネント、および、前記複数のレイヤーのうちの一つのレイヤーにおいて利用可能なデータにコンポーネントがどのように結合されるかを示し、前記方法はさらに、
   ドキュメントの初期化の際に前記コンピュータシステムのうちのクライアントコンピュータから前記サーバコンピュータに与えられる要求に応答して、当該サーバコンピュータにおいて抽出されたメタデータに、当該ドキュメントに含まれる項目の要否に応じたカスタマイゼーションを適用することにより、前記ドキュメントのユーザのためにカスタマイズされたメタデータを前記サーバコンピュータによって生成することと、
   前記ドキュメントが前記１つ以上のウェブベースのアプリケーションのためのユーザインターフェイスとして機能するように、前記サーバコンピュータから前記クライアントコンピュータに前記ドキュメントについての前記カスタマイズされたメタデータを送信することとを含む、方法。
2. 前記ドキュメントについての前記メタデータに関連付けられる前記ルールのセットを前記サーバコンピュータによって決定することは、使用するべき前記ドキュメントについての前記メタデータのバージョンを規定する少なくとも１つのルールを決定することを含む、請求項１に記載の方法。
3. 前記ドキュメントについての前記メタデータに関連付けられる前記ルールのセットを前記サーバコンピュータによって決定することは、前記ドキュメントのユーザに関連付けられる役割に基づいて、使用するべき前記ドキュメントについての前記メタデータを規定する少なくとも１つのルールを決定することを含む、請求項１に記載の方法。
4. 前記ドキュメントについての前記メタデータに関連付けられる前記ルールのセットを前記サーバコンピュータによって決定することは、時間または日付情報に基づいて、使用するべき前記ドキュメントについて前記メタデータを規定する少なくとも１つのルールを決定することを含む、請求項１〜３のいずれか１項に記載の方法。
5. 前記ドキュメントについての前記メタデータに関連付けられる前記ルールのセットを前記サーバコンピュータによって決定することは、組織の部門に基づいて、使用するべき前記ドキュメントについての前記メタデータを規定する少なくとも１つのルールを決定することを含む、請求項１〜４のいずれか１項に記載の方法。
6. 前記ドキュメントについての前記メタデータに関連付けられる前記ルールのセットを前記サーバコンピュータによって決定することは、メタデータ管理サーバから１つ以上のルールを抽出することを含む、請求項１〜５のいずれか１項に記載の方法。
7. 前記ドキュメントについての前記メタデータに適用されるようにカスタマイゼーションを構成する前記ルールの決定されたセットに基づいて、前記ドキュメントについての前記メタデータを前記サーバコンピュータによって生成することは、前記ドキュメントについてのベースメタデータに複数のメタデータカスタマイゼーションを適用することを含む、請求項１〜６のいずれか１項に記載の方法。
8. ウェブベースの複数のレイヤーからなるアプリケーションのためのユーザインターフェイスとして機能するデスクトップアプリケーションのドキュメントを作成するためのコンピュータ実行可能コードを含むコンピュータ読取可能プログラムであって、
   コンピュータシステムのうちのサーバコンピュータにてドキュメントを作成するためのコードと、
   前記ドキュメントについてのメタデータに関連付けられるルールのセットを前記サーバコンピュータによって決定するためのコードとを含み、前記メタデータは、前記ドキュメントに含まれる各コンポーネント、および、前記複数のレイヤーのうちの一つのレイヤーにおいて利用可能なデータにコンポーネントがどのように結合されるかを示し、さらに、
   ドキュメントの初期化の際に前記コンピュータシステムのうちのクライアントコンピュータから前記サーバコンピュータに与えられる要求に応答して、当該サーバコンピュータにおいて抽出されたメタデータに、当該ドキュメントに含まれる項目の要否に応じたカスタマイゼーションを適用することにより、前記ドキュメントのユーザのためにカスタマイズされたメタデータを前記サーバコンピュータによって生成するためのコードと、
   前記ドキュメントが前記１つ以上のウェブベースのアプリケーションのためのユーザインターフェイスとして機能するように、前記サーバコンピュータから前記クライアントコンピュータに前記ドキュメントについての前記カスタマイズされたメタデータを送信するためのコードとを含む、コンピュータ読取可能プログラム。
9. 請求項１〜７のいずれか１項に記載の方法をコンピュータシステムに実行させるためのコンピュータ実行可能コードを含むコンピュータ読取可能プログラム。
10. ウェブベースの複数のレイヤーからなるアプリケーションのためのユーザインターフェイスとして機能するデスクトップアプリケーションのドキュメントを作成するためのシステムであって、
    プロセッサと、
    指示のセットを格納するメモリとを含み、
    前記指示のセットは、前記プロセッサによって実行されると、
    ドキュメントを作成し、
    前記ドキュメントについてのメタデータに関連付けられるルールのセットを決定するように前記プロセッサを構成し、前記メタデータは、前記ドキュメントに含まれる各コンポーネント、および、前記複数のレイヤーのうちの一つのレイヤーにおいて利用可能なデータにコンポーネントがどのように結合されるかを示し、さらに
    ドキュメントの初期化の際にクライアントコンピュータから前記システムに与えられる要求に応答して、当該システムにおいて抽出されたメタデータに、当該ドキュメントに含まれる項目の要否に応じたカスタマイゼーションを適用することにより、前記ドキュメントのユーザのためにカスタマイズされたメタデータを生成し、
    前記ドキュメントが前記１つ以上のウェブベースのアプリケーションのためのユーザインターフェイスとして機能するように、前記クライアントコンピュータに前記ドキュメントについての前記カスタマイズされたメタデータを送信するように前記プロセッサを構成する、システム。
11. 前記ドキュメントについての前記メタデータに関連付けられる前記ルールのセットを決定するために、前記プロセッサは、使用するべき前記ドキュメントについての前記メタデータのバージョンを規定する少なくとも１つのルールを決定するように構成される、請求項１０に記載のシステム。
12. 前記ドキュメントについての前記メタデータに関連付けられる前記ルールのセットを決定するために、前記プロセッサは、前記ドキュメントのユーザに関連付けられる役割に基づいて、使用するべき前記ドキュメントについての前記メタデータを規定する少なくとも１つのルールを決定するように構成される、請求項１０または１１に記載のシステム。
13. 前記ドキュメントについての前記メタデータに関連付けられる前記ルールのセットを決定するために、前記プロセッサは、時間または日付情報に基づいて、使用するべき前記ドキュメントについての前記メタデータを規定する少なくとも１つのルールを決定するように構成される、請求項１０〜１２のいずれか１項に記載のシステム。
14. 前記ドキュメントについての前記メタデータに関連付けられる前記ルールのセットを決定するために、前記プロセッサは、組織の部門に基づいて、使用するべき前記ドキュメントについての前記メタデータを規定する少なくとも１つのルールを決定するように構成される、請求項１０〜１３のいずれか１項に記載のシステム。
15. 前記ドキュメントについての前記メタデータに関連付けられる前記ルールのセットを決定するために、前記プロセッサは、メタデータ管理サーバから１つ以上のルールを抽出するように構成される、請求項１０〜１４のいずれか１項に記載のシステム。
16. 前記ドキュメントについての前記メタデータに適用されるようにカスタマイゼーションを構成する前記ルールの決定されたセットに基づいて前記ドキュメントについての前記メタデータを生成するために、前記プロセッサは、前記ドキュメントについてベースメタデータに複数のメタデータカスタマイゼーションを適用するように構成される、請求項１０〜１５のいずれか１項に記載のシステム。