【手続補正書】
【提出日】平成20年10月14日(2008.10.14)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
第１のメッセージ・ソースで、第１のデータ・フローにおける第１のメッセージを、第１のメッセージング・レイヤから受ける工程と、
前記第１データ・フローにおいて、第１のデータ・メッセージ再構成可能イテレータでラップされたデータを、前記第１メッセージ・ソースから第１のテーブルに提供する工程と、
前記第１テーブルを越えて第１の制約されたビューを提供する工程と、
を備える方法。
【請求項２】
第２のメッセージ・ソースで、第２のデータ・フローにおける第２のメッセージを、第２のメッセージング・レイヤから受ける工程と、
前記第２データ・フローにおいて、第２のデータ・メッセージ再構成可能イテレータでラップされたデータを、前記第２メッセージ・ソースから第２のテーブルに提供する工程と、
前記第２テーブルを越えて第２の制約されたビューを提供する工程と、
前記第１の制約されたビューおよび前記第２の制約されたビューから、マージ・ビューを生成する工程と、
を備える請求項１に記載の方法。
【請求項３】
前記マージ・ビューを、再構成可能イテレータを介してクライアント・コード／ディスプレイに提供する工程を備える請求項２に記載の方法。
【請求項４】
前記第１データ・フローにおいて、前記第１データ・メッセージ再構成可能イテレータでラップされたデータを、前記第１メッセージ・ソースから前記第１テーブルに、キャッシュする工程と、
第２のフローにおいて、第２のデータ・メッセージ再構成可能イテレータでラップされたデータを、前記第１メッセージ・ソースから第２のテーブルにルーティングする工程と、
前記第２テーブルを越えて第２の制約されたビューを提供する工程とを備え、
前記第１テーブルは、キャッシュ・テーブルであり、前記第２テーブルは、ルーティング・テーブルであることを特徴とする請求項１に記載の方法。
【請求項５】
前記第１の制約されたビューおよび前記第２の制約ビューを、再構成可能イテレータを介してクライアント・コード／ディスプレイに提供する工程を備える請求項４に記載の方法。
【請求項６】
前記第１テーブルを越えて第２の制約されたビューを提供する工程を備える請求項１に記載の方法。
【請求項７】
前記第１の制約されたビューおよび前記第２の制約されたビューを、再構成可能イテレータを介して、クライアント・コード／ディスプレイに提供する工程を備える請求項６に記載の方法。
【請求項８】
格納された実行可能な命令を有するメモリと、
該メモリに結合されるプロセッサであって、該プロセッサによって実行される際に、前記命令は該プロセッサに、第１のメッセージ・ソースで、第１のデータ・フローにおける第１のメッセージを第１のメッセージング・レイヤから受けさせ、前記第１データ・フローにおいて、第１のデータ・メッセージ再構成可能イテレータでラップされたデータを、前記第１メッセージ・ソースから第１のテーブルに提供させ、前記第１テーブルを越えて第１の制約されたビューを提供させるプロセッサと、
を備える装置。
【請求項９】
前記命令は、前記プロセッサに、第２のメッセージ・ソースで、第２のデータ・フローにおける第２のメッセージを第２のメッセージング・レイヤから受けさせ、前記第２データ・フローにおいて、第２のデータ・メッセージ再構成可能イテレータでラップされたデータを、前記第２メッセージ・ソースから第２のテーブルに提供させ、前記第２テーブルを越えて第２の制約されたビューを提供させ、前記第１の制約されたビューおよび前記第２の制約されたビューから、マージ・ビューを生成させる、請求項８に記載の装置。
【請求項１０】
前記命令は、前記プロセッサに、前記マージ・ビューを、再構成可能イテレータを介してクライアント・コード／ディスプレイに提供させる、請求項９に記載の装置。
【請求項１１】
前記第１テーブルは、キャッシュ・テーブルであり、前記第２テーブルは、ルーティング・テーブルであり、
前記命令は、前記プロセッサに、前記第１データ・フローにおいて、前記第１データ・メッセージ再構成可能イテレータでラップされたデータを、前記第１メッセージ・ソースから前記キャッシュ・テーブルにキャッシュさせ、第２のデータ・フローにおいて、第２のデータ・メッセージ再構成可能イテレータでラップされたデータを、前記第１メッセージ・ソースから前記ルーティング・テーブルにルーティングさせ、前記ルーティング・テーブルを越えて第２の制約されたビューを提供させる、請求項８に記載の装置。
【請求項１２】
前記命令は、前記プロセッサに、前記第１の制約されたビューおよび前記第２の制約されたビューを、再構成可能イテレータを介してクライアント・コード／ディスプレイに提供させる、請求項１１に記載の装置。
【請求項１３】
前記命令は、前記プロセッサに、第２の制約されたビューを、前記第１テーブルを越えて提供させる、請求項８に記載の装置。
【請求項１４】
前記命令は、前記プロセッサに、前記第１の制約されたビューおよび前記第２の制約されたビューを、再構成可能イテレータを介して、クライアント・コード／ディスプレイに提供させる、請求項１３に記載の装置。
【請求項１５】
ネットワーク・ソケットと、
格納された実行可能な命令を有するメモリと、
該メモリおよび前記ネットワーク・ソケットに結合されたプロセッサであって、該プロセッサによって実行される際に、前記命令は、前記プロセッサに、第１のメッセージ・ソースで、第１のデータ・フローにおける第１のメッセージを、第１のメッセージング・レイヤから受けさせ、前記第１データ・フローにおいて、第１のデータ・メッセージ再構成可能イテレータでラップされたデータを前記第１メッセージ・ソースから第１のテーブルに提供させ、前記第１テーブルを越えて第１の制約されたビューを提供させるプロセッサと、
を備えるシステム。
【請求項１６】
前記命令は、前記プロセッサに、第２のメッセージ・ソースで、第２のデータ・フローにおける第２のメッセージを第２のメッセージング・レイヤから受けさせ、前記第２データ・フローにおいて、第２のデータ・メッセージ再構成可能イテレータでラップされたデータを、前記第２メッセージ・ソースから第２のテーブルに提供させ、前記第２テーブルを越えて第２の制約されたビューを提供させ、前記第１の制約されたビューおよび前記第２の制約されたビューから、マージ・ビューを作成させる、請求項１５に記載のシステム。
【請求項１７】
前記プロセッサに結合されたクライアント・コード／ディスプレイを備え、
前記命令は、前記プロセッサに、前記マージ・ビューを再構成可能イテレータを介して前記クライアント・コード／ディスプレイに提供させる、請求項１５に記載のシステム。
【請求項１８】
前記第１テーブルは、キャッシュ・テーブルであり、前記第２のテーブルは、ルーティング・テーブルであり、
前記命令は、前記プロセッサに、前記第１データ・フローにおいて、前記第１データ・メッセージ再構成可能イテレータでラップされたデータを、前記第１メッセージ・ソースから前記キャッシュ・テーブルにキャッシュさせ、第２のフローにおいて、第２のデータ・メッセージ再構成可能イテレータでラップされたデータを、前記第１メッセージ・ソースから前記ルーティング・テーブルにルーティングさせ、前記ルーティング・テーブルを越えて第２の制約されたビューを提供させる、請求項１５に記載のシステム。
【請求項１９】
前記プロセッサに結合されたクライアント・コード／ディスプレイを備え、
前記命令は、前記プロセッサに、前記第１の制約されたビューおよび前記第２の制約されたビューを、再構成可能イテレータを介して前記クライアント・コード／ディスプレイに提供させる、請求項１８に記載のシステム。
【請求項２０】
前記命令は、前記プロセッサに、前記第１テーブルを越えて第２の制約されたビューを提供させる、請求項１９に記載のシステム。
【請求項２１】
前記プロセッサに結合されたクライアント・コード／ディスプレイを備え、
前記命令は、前記プロセッサに、前記第１の制約されたビューおよび前記第２の制約されたビューを、再構成可能イテレータを介して前記クライアント・コード／ディスプレイに提供させる、請求項２０に記載のシステム。
【請求項２２】
格納された命令を有するコンピュータ読み取り可能媒体を備え、
プロセッサによって実行される際に、前記命令は、該プロセッサに、第１のメッセージ・ソースで、第１のデータ・フローにおける第１のメッセージを第１のメッセージング・レイヤから受けさせ、前記第１データ・フローにおいて、第１のデータ・メッセージ再構成可能イテレータでラップされたデータを、前記第１メッセージ・ソースから第１のテーブルに提供させ、前記第１テーブルを越えて第１の制約されたビューを提供させる、物品。
【請求項２３】
前記命令は、前記プロセッサに、第２のメッセージ・ソースで、第２のデータ・フローにおける第２のメッセージを第２のメッセージング・レイヤから受けさせ、前記第２データ・フローにおいて、第２のデータ・メッセージ再構成可能イテレータでラップされたデータを、第２のメッセージ・ソースから第２のテーブルに提供させ、前記第２テーブルを越えて第２の制約されたビューを提供させ、前記第１の制約されたビューおよび前記第２の制約されたビューから、マージ・ビューを作成させる、請求項２２に記載の物品。
【請求項２４】
前記命令は、前記プロセッサに、前記マージ・ビューを、再構成可能イテレータを介してクライアント・コード／ディスプレイに提供させる、請求項２３に記載の物品。
【請求項２５】
前記命令は、前記プロセッサに、前記第１データ・フローにおいて、前記第１データ・メッセージ再構成可能イテレータでラップされたデータを、前記第１のメッセージ・ソースから前記第１テーブルにキャッシュさせ、第２のデータ・フローにおいて、第２のデータ・メッセージ再構成可能イテレータでラップされたデータを、前記第１メッセージ・ソースから第２のテーブルにルーティングさせ、前記第２テーブルを越えて第２の制約されたビューを提供させ、
前記第１テーブルはキャッシュ・テーブルであり、前記第２テーブルはルーティング・テーブルであることを特徴とする、請求項２２に記載の物品。
【請求項２６】
前記命令は、前記プロセッサに、前記第１の制約されたビューおよび前記第２の制約されたビューを、再構成可能イテレータを介してクライアント・コード／ディスプレイに提供させる、請求項２５に記載の物品。
【請求項２７】
前記命令は、前記プロセッサに、前記第１テーブルを越えて第２の制約されたビューを提供させる、請求項２２に記載の物品。
【請求項２８】
前記命令は、前記プロセッサに、前記第１の制約されたビューおよび前記第２の制約されたビューを、再構成可能イテレータを介してクライアント・コード／ディスプレイに提供させる、請求項２７に記載の物品。
【請求項２９】
前記命令は、前記プロセッサに、前記第１の制約されたビューおよび前記第２の制約されたビューを、再構成可能イテレータを介してクライアント・コード／ディスプレイに提供させる、請求項２８に記載の物品。
【手続補正２】
【補正対象書類名】明細書
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【発明の詳細な説明】
【発明の名称】関連するアプリケーションの相互参照
【技術分野】
【０００１】
本発明は、デジタルデータ処理に関するものであり、より詳細には、再構成可能なオブジェクトを用い、リアルタイム・データ・フローを結合するアプリケーション・フレームワークに関するものである。
【背景技術】
【０００２】
アプリケーション開発者がアプリケーションを製造し、ソフトウェアを開発するために標準的なフレームワークを採用するにつれ、コンピュータアプリケーションプログラムはますます増大し、複雑になっている。一般的に、ソフトウェア開発者によって開発されるコードは、全体的なアプリケーション機能のほんの一部だけを形成する。アプリケーション・フレームワークは、ソフトウェア・コンポーネントであり、既存のオペレーティング・システムに追加されて、予めコード化されたソリューションの大部分を共通のプログラム要件に提供し、およびフレームワークのために特化して記述されるプログラムの実行を管理する。これに対応して、コードがアプリケーション・フレームワークによって提供されるサービスを用いる程度は、システム動作における全体的なパフォーマンスにとって、きわめてクリティカルになってきている。ところが、しばしばこのフレームワークは、非効率的に、又は、誤って用いられている。
【０００３】
アプリケーション・フレームワークはまた、再構成可能なデザインをソフトウェア・システム（又はサブシステム）に提供する。アプリケーション・フレームワークは、一組の抽象クラスとそのインスタンスが特定のソフトウェア・タイプのために共働するメソッドとしてとして表すことができる。アプリケーション・フレームワークはオブジェクト指向設計であり、オブジェクト指向言語で実装することができる。例えば、アプリケーション・フレームワークは、特定のアプリケーション、異なるプログラミング言語および対象となるマシン用のコンパイラ、財務モデリング・アプリケーション又は意志決定支援システムを構築することに向けられることがある。アプリケーション・フレームワークは、特定の機能用に適合されるべきアーキテクチャの配置(place)を規定する。オブジェクト指向環境では、アプリケーション・フレームワークは、抽象クラスおよび具体クラスを含む。このようなフレームワークのインスタンス化は、既存のクラスをコンポーネント化およびサブクラス化することを含む。好適なアプリケーション・フレームワークにより、開発者は、ビジネスに特有の課題の裏で起動するコードに対してではなく、ビジネスに特有の課題に対して、集中してより多くの時間を費やすことが可能になる。
【０００４】
アプリケーション・フレームワークによって提供される予めコード化されたソリューションは、フレームワークのクラス・ライブラリを形成し、ユーザ・インタフェース、データアクセス、暗号、ウェブアプリケーション開発、数値アルゴリズムおよびネットワーク通信の開発をサポートする。このクラス・ライブラリの機能は、フレームワーク用に開発されるカスタム・アプリケーション・プログラムを製造するソフトウェア開発者によって作成されるカスタムコードと結合される。
【０００５】
これらのアプリケーションは、プログラムのランタイム要件を管理するソフトウェア環境で動作する。フレームワークの一部をさらに形成するランタイム・システムは、アプリケーションのバーチャルマシンの出現を提供する。その結果、ソフトウェア開発者は、プログラム・コードを最終的に実行することになる特定の中央演算処理装置（ＣＰＵ）の能力を考慮する必要がない。クラス・ライブラリとランタイム要件は共にフレームワークを構成する。フレームワークは、コンピュータ・アプリケーションの開発を単純化するためのツールであり、セキュリティ脅威に対してアプリケーションおよびコンピュータの脆弱性を低減させる。
【発明の開示】
【発明が解決しようとする課題】
【０００６】
企業向けソフトウェアは、市販ソフト（例えば高度な財務システム、よくあるウェブサイト並びに大規模な管理システム、および監理システム）を含む。最近の企業向けソフトウェア・システムは、通常、標準的なマルチ・ユーザのアプリケーション・サーバ・ソフトウェアに基づいており、現在２つの主要なフレームワークが現在ある。すなわち、Ｊａｖａ（登録商標）ベースのＪ２ＥＥ（Ｊａｖａ（登録商標）２プラットホーム、エンタープライズ・エディション）フレームワークとマイクロソフト（登録商標）による．ＮＥＴフレームワークである。両方とも、大規模なソフトウェア開発のためのコスト削減および開発時間の削減を目的としている。
【０００７】
アプリケーション・フレームワークは、目標に到達するために、いろいろなライブラリを通じて必要な機能を提供する。アプリケーション・フレームワークの中心となる設計の基本方針は、Ｎ次元データのキャッシュを処理することである。特定の実施形態においては、たとえば、２次元（２Ｄ）データをバックエンドのサービスから受け取り、アプリケーション・フレームワークのコンテキスト内部では、その長方形の形状を失う。このデータの長方形の形状は、次いで、クライアント・アプリケーションに届けられる前に、トップレベルのライブラリ内で復元する必要がある。
【０００８】
多くのアプリケーションで繰り返される課題は、低レベルの（時折、バイナリのままの）構造で到達しているデータを高レベル・ビューから、ビュー(view)する必要があるということであり、例えば、あたかもテーブル、即ちテーブルのコンテンツであるかのように、データをビューする必要がある。データの長方形の形状は、行および列（カラム）を含んでおり、人間とマシンとの両方が大量のデータセットをビューするためのごく一般的なやり方である。
【課題を解決するための手段】
【０００９】
一実施形態においては、第１のメッセージ・ソースで、第１のデータ・フローにおける第１のメッセージを、第１のメッセージング・レイヤから受け、第１のデータ・メッセージ再構成可能イテレータでラップされた(wrapped)データを、第１データ・フローにおいて第１のメッセージ・ソースから第１のテーブルに提供し、そして、第１のテーブルを越えて第１の制約されたビューを提供する。
【発明を実施するための最良の形態】
【００１０】
図１は、ネットワーク１０２がサーバ１０４と一つ以上のクライアント・システム１０６、１０８、１１０とをリンクするクライアント／サーバ・システム１００を例示している。サーバ１０４は、本明細書において説明される実施形態に従って、装置、プログラム又は方法を実施することにふさわしいプログラム可能なデータ処理システム又はコンピュータである。サーバ１０４は、ユーザのリクエストを処理する１以上のランタイム・システムのためのコア動作環境を提供している。サーバ１０４は、プロセッサ１１２とメモリ１１４を含んでいる。サーバは、グラフィカル・ユーザ・インタフェース（ＧＵＩ）表示部１３０を含むことができる。メモリ１１４は、オペレーティング・システムと、ネットワーク１０２を介して通信するための伝送制御プロトコル／インターネット・プロトコル（ＴＣＰ／ＩＰ）のスタックと、プロセッサ１１２で実行されるマシン実行可能命令とを格納するのに用いることができる。いくつかの実施例では、サーバ１０４は、多重プロセッサを含むことができ、そのそれぞれは、マシン実行可能命令を実行するのに用いることができることがある。メモリ１１４は、サーバ１０４で実行するマルチ・オペレーティング・システムのプロセスによってアクセスできる共有メモリ領域を含むことができる。クライアント／サーバ・システム１００で用いられるのに好適なサーバ１０４の例は、Ｊａｖａ（登録商標）２プラットホーム又は．ＮＥＴプラットホームと互換性のあるサーバである。
【００１１】
クライアント・システム１０６を参照してここに示すが、クライアント・システム１０６、１０８、１１０の各々は、プロセッサ１２２と、メモリ１２４とを含むことがある。クライアント・システム１０６、１０８、１１０は、本明細書で説明する実施形態に従って、装置、プログラム又は方法を実施するにふさわしいプログラム可能なデータ処理システム又はコンピュータとすることができる。メモリ１２４は、オペレーティング・システムと、ネットワーク１０２を介して通信するためのＴＣＰ／ＩＰスタックと、プロセッサ１２２によって実行されるマシン実行可能命令とを格納するのに用いることができる。いくつかの実施では、クライアント１０６は、多重プロセッサを含むことができ、そのそれぞれは、マシン実行可能命令を実行するのに用いることができる。メモリ１２４は、クライアント１０６で実行しているマルチ・オペレーティング・システムのプロセスによってアクセス可能な共有メモリ領域を含むことができる。
【００１２】
クライアント・システム１０６、１０８、１１０は、複数のアプリケーション又はアプリケーション・インターフェースを実行することができる。アプリケーション又はアプリケーション・インターフェースの各々の例では、ユーザ・セッションを構成することができる。各ユーザ・セッションは、サーバ１０４で処理する一つ以上のリクエストを生成することができる。リクエストは、サーバ１０４又はいずれかのクライアント１０６、１０８、１１０のランタイム・システム１１６、１２６（例えばバーチャル・マシン）上で実行される命令又はコードを含むことができる。ランタイム・システム１１６，１２６は、ユーザ・リクエスト中の命令又はコードを実行し、およびそのコード用のランタイム・サービスを提供するコード実行環境である。コア・ランタイム・サービスは、プロセス管理、スレッド管理、およびメモリ管理（例えば、オブジェクトを共有しているサーバ・メモリ１１４内にオブジェクトを割り当てること、オブジェクトの参照を管理すること、及び、オブジェクトのガーベッジ・コレクションを行うこと）のような機能を含むことができる。拡張ランタイム・サービスは、エラー処理、およびセキュリティ並びに接続の確立といった機能を含むことができる。メッセージ・ソース、テーブル、およびビューリアルタイムを備えるリアルタイム・データ・フロー１１８、１２０は、ネットワーク１０２から、クライアント・システム１０６、１０８、１１０のＧＵＩ表示部１２８まで、及び／又は、ネットワーク１０２からサーバ１０４のＧＵＩディスプレイ部１３０までを確立する。リアルタイム・データ・フロー１１８、１２０のいくつかの実施例では、図２乃至５において以下に更に詳細に説明する。
【００１３】
ランタイム・システム１１６は、例えば、とりわけマイクロソフト（登録商標）による．ＮＥＴフレームワークとして、又は、Ｊａｖａ（登録商標）ベースＪ２ＥＥ（Ｊａｖａ（登録商標）２プラットホーム）フレームワークとして実施することができる。
【００１４】
一実施形態においては、ランタイム・システム１１６は、．ＮＥＴフレームワークとして実施することができる。．ＮＥＴフレームワークは、例えば、とりわけ、マイクロソフト（登録商標）ウインドウズ（登録商標）の管理プログラミング・モデル(managed programming model)を備えることができ、およびマイクロソフト．ＮＥＴフレームワーク３．０、．ＮＥＴフレームワーク２．０、ウインドウズ・プレゼンテーション・ファウンデーション(Windows（登録商標） Presentation Foundation)、ウインドウズ・コミュニケーション・ファウンデーション(Windows（登録商標） Communication Foundation)、及び、ウインドウズ・ワークフロー・ファウンデーション(Windows（登録商標） Workflow Foundation)を備えることができる。．ＮＥＴフレームワーク用のコードは、以下の言語、すなわち、Ｖｉｓｕａｌ  Ｂａｓｉｃ、Ｃ＃、およびＣ＋＋の言語の一つ以上を備えることができる。．ＮＥＴフレームワークは、ＴＯＣでサンプル・ノードを開くことによって、テクノロジーによって体系付けられた、サンプルのローケーティングおよびビューイングを可能にする。「テクノロジー・サンプル」のサブノードは、一般的に簡潔であり、かつ、テクノロジーの特定の側面に対してフォーカスされたサンプルを備えることができる。「アプリケーション・サンプル」のサブノードは、豊富なリアルタイム・アプリケーション(rich real-time application)を構成するために、アプリケーション・プログラミング・インタフェース（ＡＰＩ）を使用する方法をデモンストレートする、より広範であり、かつより複雑なアプリケーションであるサンプルを備えることができる。
【００１５】
．ＮＥＴフレームワークは、ユーザ、システム、及び、装置を接続するためのソフトウェア・コンポーネントを提供する。．ＮＥＴフレームワークは、クライアント１０６、１０８、１１０、サーバ１０４、及び、開発者用ツールにおよぶ。．ＮＥＴフレームワークは、ソフトウェア開発の基礎を形成するシステムを動作させるサーバ１０４に不可欠な部分として実施する場合がある。．ＮＥＴフレームワークは、アプリケーションと構成要素との相互動作性と同様に、１又はそれ以上のインターネット・プロトコル（例えば、ＴＣＰ／ＩＰ）、およびメッセージ・フォーマッテット基準に基づいた統一オブジェクト指向開発環境を提供する。開発者は、イントラネット環境とエクストラネット環境、又はインターネット全体にわたるグローバル・ネットワーク内で相互接続した．ＮＥＴアプリケーションを作成および配布するために、ソフトウェア開発ツールのＮＥＴフレームワーク・セットを用いることができる。
【００１６】
一実施形態において、ランタイム・システム１１６は、Ｊａｖａ（登録商標）ベースＪ２ＥＥ（Ｊａｖａ（登録商標）２プラットホーム）フレームワーク・バーチャル・マシン（ＶＭ）として実施することができる。ＶＭは、抽象計算機(abstract machine)であり、実計算機(real machine)又はプロセッサのような、命令セット領域、レジスター領域のセット、スタック領域、ヒープ領域、及び、メソッド領域を含むことができる。ＶＭは、基本的に、プログラム・コードと、実際のプロセッサまたはプログラム・コードが実行されるハードウェア・プラットホームとの間のインターフェースとして振る舞う。プログラム・コードは、ＶＭのリソースを操作するＶＭ命令セットからの命令を含む。ＶＭは、プロセッサ又はハードウェア・プラットホーム上の命令を実行し、ＶＭが起動して、プロセッサ又はハードウェア・プラットホーム上のリソースを操作し、そしてプログラム・コードの命令を実行する。このように、同一のプログラム・コードは、各プロセッサ若しくはハードウェア・プラットホームのために書き直す必要なく、又はリコンパイルする必要なく、マルチ・プロセッサ又は複数のハードウェア・プラットホーム上で実行することができる。その代わりとしては、ＶＭは、各々のプロセッサ又はハードウェア・プラットホームに対して実行し、そして、同一のプログラム・コードは、各ＶＭで実行することができる。ＶＭは、プロセッサ又はハードウェア・プラットホームにより認識されるコードにおいて実装することができる。その代替として、ＶＭは、プロセッサ１１２に直接組み込まれるコードにおいての実装することができる。
【００１７】
例えば、Ｊａｖａ（登録商標）ソース・プログラムは、バイトコードと呼ばれるプログラム・コードにコンパイルすることができる。バイトコードは、あらゆるプロセッサ又はプラットホーム上で起動しているＪａｖａ（登録商標）ＶＭにおいて実行することができる。Ｊａｖａ（登録商標）ＶＭは、バイトコードの１命令を一度に解釈することができ、あるいは、バイトコードは、ジャスト・インタイム（ＪＩＴ）コンパイラを用いるリアル・プロセッサまたはプラットホーム用に、さらにコンパイルすることができる。
【００１８】
Ｊａｖａ（登録商標）ＶＭに加えて、ＶＭの他の例には、アドバンスド・ビジネス・アプリケーション・プログラミング言語（ＡＢＡＰ）ＶＭと、共通言語ランタイム（ＣＬＲ）ＶＭと、を含む。ＡＢＡＰは、ＳＡＰ  Ｒ／３システム用のアプリケーションを開発するためのプログラミング言語である。これは、ＳＡＰにより開発され、広く導入されたビジネス・アプリケーション・システムである。共通言語ランタイムは、マイクロソフト（登録商標）社のレドモンド(Redmond)、ワッシュ(Wash)により開発された、管理コード実行環境である。簡単のため、本明細書では、バーチャル・マシンに焦点をあてるが、ここに記載される技法が他の種類のランタイム・システムでもまた、用いることができるということは理解されるべきである。
【００１９】
実行時において、ランタイム・システム１１６，１２６は、ローカル・データ・エンティティを生成および参照する。ローカル・エンティティの多くの別の種類は、例えば、ストリング、定数と変数、クラスのインスタンスであるオブジェクト、クラスのランタイム表現、及び、クラス・ランタイム表現をロードするのに用いられるクラスローダーを含んで生成される。
【００２０】
ローカル・エンティティがランタイム・システム１１６、１２６によってもはや用いられないとき、ローカル・エンティティを格納するのに用いられるメモリは、取り戻される必要がある。すなわちメモリは、自由状態にされるか若しくはリリースされて、利用可能なメモリのプールに戻され、その結果、メモリは、新しいデータ・エンティティを格納するのに用いることができる。ある環境では、開発者は、（例えば、指定されたメモリ・セクションを自由にする機能を明示的に呼ぶ(call)することにより）ローカル・エンティティに割り当てたメモリを明示的に取り戻さなければならない場合もある。他の環境では、メモリを取り戻すことは、ガーベッジ・コレクションと呼ばれる技法によって処理される。
【００２１】
ガーベッジ・コレクションは、もはや「ライブ」でない（すなわち、例えば、いくつかの現在参照されるオブジェクトまたはエンティティからも届かないと判断されたため、もはや使用されていないような）、メモリ・アロケータにより分散されたメモリのブロックを特定して取り戻すように設計された処理である。ガーベッジ・コレクションは、時々、ユーザ・プログラムによる明示的なタスクとしてではなく、むしろランタイム・システムによるバックグラウンド・タスクとして処理することができる。また、ガーベッジ・コレクションは、直列式のタスク(inlined task)として処理することもできる。
【００２２】
ガーベッジ・コレクションを通じてメモリを取り戻すシステムは、ユーザに再利用を任せるシステムより勝るいくつかの利点を提供する。特に、ガーベッジ・コレクションを利用するシステムは、ぶらさがりポインタ(dangling pointers)やメモリ・リークのような共通のプログラミング上の問題を取り除くのを支援するので、より信頼性があるという傾向にある。しかしながら、ガーベッジ・コレクション処理での少なくともある部分の間は、メモリへのアクセスは、通例は制限され、そしてランタイム・システムは時々停止しなければならないので、ガーベッジに関連していくらかのコストがかかる。それでも、ガーベッジ・コレクションは、ランタイム・システムでメモリを取り戻すために頻繁に用いられており、そして、多くの知られているガーベッジ・コレクションのアルゴリズム（例えば、参照カウンティング(reference counting)、マーク−スイープ(mark-sweep)、マーク−コンパクト(mark-compact)、及び、コピー(copying)のアルゴリズム）がある。
【００２３】
複数のランタイム・システム１１６、１２６は、サーバ１０４環境及び／又はクライアント・システム１０６、１０８、１１０のパフォーマンスおよびスケーラビリティを増すために、並列に実行することができる。複数のランタイム・システム１１６、１２６が並列に実行される際は、ランタイム・システム１１６、１２６間でエンティティをシェアすることで、リソース（例えば、メモリ）や時間消費を減らすことができる。エンティティをシェアするのに用いることができる多数の公知の技法があり、そして、多くの別の種類のエンティティ（例えば、ストリング、定数、変数、オブジェクト・インスタンス、クラス・ランタイム表現およびクラスローダーを含む）を、シェアすることができる。
【００２４】
シェアされたエンティティの存続期間は、ローカル・エンティティの存続期間とは異なっており、シェアされたエンティティを格納するのに用いているメモリを取り戻すためには、標準的なガーベッジ・コレクション技法を用いることはできない。例えば、シェアされたエンティティのガーベッジ・コレクション用のローカル・ガーベッジ・コレクション処理を用いることはできない。ローカル・メモリ（例えば、1つのランタイム・システムと関連したローカル・エンティティを格納するのに用いられるメモリ）を取り戻すのに通常用いられる、ローカル・ガーベッジ・コレクション処理は、そのランタイム・システムがデータ・エンティティをもはや参照しない際に、データ・エンティティをガーベッジ・コレクトするように典型的には設計されている。しかしながら、1つのランタイム・システムがシェアされたエンティティをもはや参照しない際に、シェアされたエンティティは、必ずしもガーベッジ・コレクトされるべきではない。というのは、他のランタイム・システムが、シェアされたエンティティをまだ参照しているかもしれないからである。したがって、シェアされたエンティティのガーベッジ・コレクションは、参加しているランタイム・システム１１６、１２６の間でいくらかの連携および協力を必要とする。
【００２５】
．ＮＥＴフレームワークのランタイム・システム１２６内で動作しているクライアント・システム１０６、１０８、１１０用に、データを、（例えば、システム又はシンプル・オブジェクト・アクセス・プロトコル［ＳＯＡＰ］サービスを発行（パブリッシュ）および申込み（サブスクライブする）バック−エンドサービスからフロント−エンド・グリッド又はＧＵＩディスプレイ１２８にルーティングすることができ、ここでデータを、エンド−ユーザに表示することができる。例えば、ビジネス・ロジックの後に、フォーマット化や他の処理をデータに適用する。例えば、データは、ネットワーク１０２を介して送られる前に、ＳＯＡＰ、ウェブ・サービス要求メッセージおよびウェブ・サービス応答メッセージ中の情報をエンコードするために用いる軽量エクステンシブル・マークアップ言語（ＸＭＬ）ベースのメッセージ・プロトコルからルーティングされることができる。ＳＯＡＰメッセージは、どんなオペレーティング・システム又はプロトコルからでも独立であり、とりわけＳＭＴＰ、ＭＩＭＥ、およびＨＴＴＰを含む様々なインターネット・プロトコルを用いて移送される。
【００２６】
システム１００、及び／又は、サーバ１０４、及び／又は、クライアント・システム１０６、１０８、１１０用のアプリケーション・フレームワークは、ネットワーク１０２を通じて、リアルタイムＮ次元データのメッセージング、キャッシュおよびルーティングをサポートするアプリケーションを備えることができる。例えば、メッセージングは、ネットワーク１０２を通じて、サーバ１０４と一つ以上のクライアント・システム１０６、１０８、１１０の間で行うことができる。最適化され拡張されたアプリケーション・フレームワークは、適切なアプリケーション・フレームワークを提供して、２Ｄデータを処理することができるが、本実施形態は、この文脈に限定されない。
【００２７】
一実施形態では、アプリケーション・フレームワークは、メッセージング・レイヤのようなバック−エンドサービスから、２Ｄデータを受け取る。その処理では、この２Ｄは、アプリケーション・フレームワークのコンテキスト内で、その長方形の形状を失うことがある（例えば、図７および後に説明するデータ７０２−１，７０２−２を参照のこと）。このデータの長方形の形状は、次いで、クライアント・システム１０６、１０８、１１０のいずれかに届けられる前に、トップレベル・ライブラリにおいて復元(restore)されなければならない。しかし、Ｎ次元データのキャッシュをサポートするために、アプリケーション・フレームワーク内で用いられるデータ構造は、２Ｄデータの場合に対しては最適でないことがある。したがって、拡張アプリケーション・フレームワークは、アプリケーション・フレームワークのコンテキスト内でデータの長方形の形状を復元するのに適合することができる。拡張アプリケーション・フレームワークはまた、サーバ１０４でのメッセージング・ソースからクライアント・システム１０６、１０８、１１０までの完全なデータ・フロー１１８、１２０にわたり、データの長方形の形状を維持できる。拡張アプリケーション・フレームワークは、データの型または形状が固定されるのを可能にし、これにより、可能な限り効率的に内部データ構造を築くことに対し、信頼性を有することができる。ここでの説明においては、拡張アプリケーション・フレームワークおよびアプリケーション・フレームワークは、通常、アプリケーション・フレームワークと称される。      
【００２８】
一実施形態において、開発者は、アプリケーション・フレームワークによって提供されるリソースを用いて、ネットワーク１０２のソケットからクライアント・システム１０６、１０８、１１０のＧＵＩディスプレイ１２８部及び／又はサーバ１０４のＧＵＩディスプレイ１３０部に向けて直進するリアルタイム・データ・フロー１１８、１２０を設定することができる。ネットワーク・ソケットは、ネットワーク１０２からの新たなインカミング接続に対するのコンピュータ通信エンド・ポイントである。クライアント・システム１０６、１０８、１１０とサーバ１０４とにおけるネットワーク・ソケットは、ネットワーク１０２からのインカミング接続を受け入れ、接続を完遂させるためにネットワーク１０２におけるより低レベルなトラフィックを処理し、次いで、読み込みまたは書き込みのための新しい接続を分岐する。サーバ１０４のソケットは、継続して利用可能であり、ネットワーク１０２からの別のインカミング接続を受け入れる。
【００２９】
一実施形態において、アプリケーション・フレームワークには、既に提供されたいくつかのリアルタイム・データ・フロー１１８、１２０のコンポーネントと共に、可能な限り柔軟かつ構成可能である、汎用的でレイヤ化した(layering)フレームワークを採用することができる。一般に、これらのリアルタイム・データ・フロー１１８、１２０は、データのテーブルおよびこれらのテーブルへのビューを有した、構造のようなデータベースに関連したデータ・フローに類似することがある。データ・フローは、アプリケーション・フレームワークにより、連結（ジョイン）し、または結合（マージ）することができる。例えば、アプリケーション・フレームワークは、複数のソースからのリアルタイム・データ・フロー１１８、１２０を、単一の整合した論理長方形ビューに連結するために、マージャ(merger)、即ち内部連結コンポーネントを提供することができる。
【００３０】
図２は、アプリケーション・フレームワークのランタイム・システム１１６、１２６でのデータ・フロー２０２に関する一実施形態を示すブロック図２００である。一実施形態において、データ・フロー２０２は、ランタイム・システム１１６、１２６におけるリアルタイム・データ・フローとすることができる。データ・フロー２０２のアプリケーション・フレームワークのアーキテクチャ上のコンポーネントとして、メッセージ・ソース２０４、テーブル２０６およびビュー２０８を備えている。データ・フロー２０２は、メッセージング・レイヤ２１２とクライアント・コード／ディスプレイ２１０との間でセットアップされ、そしてこれらは、アプリケーション・フレームワーク外にある。アプリケーション・フレームワークの出力は、クライアント・コード／ディスプレイ２１０のためのものであり、それは、例えばアプリケーション・フレームワーク外に表示処理又は計算処理を備えていてもよい。クライアント・コード／ディスプレイ２１０は、アプリケーション・フレームワーク内で形成される仮想の長方形データのビューを可能にする。例えば、メッセージング・レイヤ２１２から受けたデータが、その長方形の形状を失うので、データ・フロー２０２は、データを長方形に見せ、また、クライアント・コード／ディスプレイ２１０に対して長方形の形状であると思わせるような仮想的なやり方で長方形の形状を復元する。以下に説明するように、別のデータ・フローは、ランタイム・システム１１６、１２６におけるアプリケーション・フレームワークで実施されることがある。したがって、この実施形態は、この文脈に限定されない。
【００３１】
データ・フロー２０２の最初のコンポーネントは、メッセージ・ソース２０４である。メッセージ・ソース２０４は、（複数の）メッセージング・レイヤ２１２として示される下位レイヤのメッセージング技法（例えば、ＸＭＬ用のＸＭＬリーダー、リアルタイム・データ・システムからの１バイト配列など）から情報またはデータを受け取る。メッセージング・レイヤ２１２からの情報は、再構成可能なオブジェクト２１４−１の形状でメッセージ・ソース２０４へ移される。メッセージング・レイヤ２１２から来るあらゆるメッセージのための新たなオブジェクトを生成するのではなく、同一の再構成可能なオブジェクト２１２−１を再利用することができる。再構成可能なオブジェクト２１２−１は、その内部コンテンツを有することができる構造(construct)であると考えられることがあり、この内部コンテンツは、その構造とは別のインスタンスに類似するように再構成される。したがって、再構成可能なオブジェクト２１４−１は、全く別のオブジェクトであるかのようにふるまうといった、変更した内部状態を有することがある。再構成可能なオブジェクト２１２−１は、再び初期化される内部コンテンツを有することができるので、このことは、別のオブジェクトの生成を防止する。したがって、ガーベッジ・コレクション処理は、あまり機能せず、データ・フロー２０２の全体的なパフォーマンスが改善される。
【００３２】
メッセージ・ソースは、メッセージング・レイヤ２１２から再構成可能なオブジェクト２１２−１を受けて、再構成可能なオブジェクト２１２−２をテーブル２０６へ移す。メッセージ・ソース２０４は、特定のクライアント・コード／ディスプレイ２１０の実施（例えば、リアルタイムに、パブリッシュおよびサブスクライブをするＳＯＡＰなど）と、データ・フロー２０２との間のアダプタとしてふるまう。メッセージ・ソース２０４は、データ・フロー２０２の再構成可能なオブジェクト構造２１２−１、２１２−３および２１２−４を、クライアント・コード／ディスプレイ２１０からの同等の再構成可能なオブジェクト構造とやりとりしてマップする。アプリケーション・フレームワークにおけるリアルタイムの更新は、キー(key)として表現されることがあり、それ故、メッセージ・ソース２０４は、そのキーを、サブスクリプション用のソフトウェア開発処理表現にマップし、そして、データアップデートの際に、このサブスクリプション用ソフトウェア開発処理表現を複数のキーにマップする。
【００３３】
データ・フロー２０２の次のコンポーネントは、テーブル２０６であり、アプリケーション・フレームワークのデータ・フロー２０２のコアとなる構造エンティティである。テーブルは、メッセージ・ソース２０４から再構成可能なオブジェクト２１２−２を受け取って、再構成可能なオブジェクト２１２−３をビュー２０８へ移す。テーブル２０６は、一組のデータ・エレメント（値）であり、横の行と縦の列（カラム）のモデルにより組織される。カラムは、名前によって特定され、そして、行は、特定のカラムのサブセットに現れている値によって特定され、サブセットは、候補キー(candidate key)として特定される。テーブル２０６は、例えば、参照テーブルを参照することができる。テーブル２０６は、特定の数のカラムを有しているが、任意の数の行を有することができる。実際のデータ行に加えて、テーブル２０６は、テーブル２０６に置かれ、又は特定のカラム内の値に置かれた制約のようないくつかのメタ情報に関連付けられることができる。テーブル２０６に収容されるデータは、データベースに物理的に格納される必要はない。1つの実施形態において、テーブル２０６は、今後の参照のためにデータをキャッシュすることなく、データをルーティングする。
【００３４】
テーブル２０６は、データ・フロー２０２に付随する全てのビューにおいて全てのサブスクリプション（以下に更に詳細を説明するキーおよびカラム）の結合を保持して、この構造を、テーブル２０６に入来する更新（アップデート）に課すという責任を負う。テーブル２０６は、任意のクライアント・コード／ディスプレイ２１０のアップデートのどの部分が実際に登録したのかについて判断し、次いで、これらの部分のディスパッチのみ行うことに責任を負う。以下に更に詳細に記述されるように、テーブル２０６は、キャッシュまたは非キャッシュとすることができる。
【００３５】
データ・フロー２０２の最後のコンポーネントは、ビュー２０８である。ビューは、テーブル２０６から再構成可能なオブジェクト２１２−３を受け取って、再構成可能なオブジェクト２１２−４をアプリケーション・フレームワークの外部のクライアント・コード／ディスプレイ２１０へ移す。ランタイム・システム１１６のアプリケーション・フレームワーク内部のデータ・フロー２０２におけるビュー２０８は、フロー構造である。フロー構造は、データが再構成可能なオブジェクト２１２−２、２１２−３、２１２−４の形状でデータ・フロー２０２を介して広がるため、データを制限するか、変換するか、強化する(enrich)のに用いることができる。図２に示されるビュー２０８は、最も基本的なビューである。ビュー２０８は、テーブル２０６のビューである。ビュー２０８は、制約を受けたテーブル２０６の「ビュー」を提供するものである。ビュー２０８は、見ることができる行／キーおよびカラムを制限する。ビュー２０８はまた、参照テーブルとみなされ、クエリ時間で初期データを計算して、それから、下位レイヤによって提供される更新に基づいてデータセットの更新に進む。一般に、ビュー２０８は、更新経路を通じてフローするデータに対して制約し、強化し、又は、付加することができる。一実施形態において、ビュー２０８がデータを制約する際は、そのビューはテーブル２０６で利用可能なデータのサブセットのみを呈示する。そにも関わらず、ビュー２０８は、ユーザが、ユーザ特有のデータ又は計算されたデータであっても、データ更新と関連付けることを可能にする。
【００３６】
一実施形態において、リアルタイム・データは、再構成可能なイテレータの形態で、データを再構成可能なオブジェクト２１２−２、２１２−３、２１２−３にカプセル化することにより、データ・フロー２０２内のメッセージ・ソース・コンポーネント２０４と、テーブル・コンポーネント２０６と、およびビュー・コンポーネント２０８との間を通される。再構成可能なイテレータも、再構成可能なオブジェクトであると考えられる。例えば、特定の実施に関係なく、再構成可能なイテレータは、コレクションのすべての要素を通じて走査を可能にする再構成可能なオブジェクトとすることができる。イテレータは、時々、特にデータベースのコンテキストの範囲内で、カーソルと呼ばれることがある。再構成可能なオブジェクトに関して先に説明したように、再構成可能イテレータは、軽量(light-weight)であってもよく、メモリ割り当てを招くことなく、新しいデータですぐに再初期化されることができる。再構成可能イテレータは、一種のポインタとして考えることができ、そして、２つの主要な動作をする。すなわち、（１）収集オブジェクトにおいて１つの特定の要素を参照すること（要素アクセスと称する）、および（２）それが次の要素をポイントするように、それ自体を修正すること（要素走査と称する）、である。再構成可能イテレータはまた、いくつかの最初の要素をポイントすることができ、再構成可能イテレータがコンテナにおける全ての要素を使い果たした時を判断することができる。プログラミング言語と使用目的に依存して、再構成可能イテレータは、また追加の動作を提供もすることができ、すなわち、異なる挙動を示すことができる。
【００３７】
再構成可能イテレータの主な目的は、コンテナの内部構造からユーザを孤立させる間、ユーザにコンテナのあらゆる要素を処理させることを可能にすることである。これは、ユーザに単一のシーケンスまたは単一のリストであるかのように処理させる一方で、コンテナがあらゆる方法で要素を格納するのを可能にする。再構成可能イテレータのクラスは、対応するコンテナ・クラスと厳格に整合するように設計されることがある。通常、コンテナは、再構成可能イテレータを作成するための方法を提供する。再構成可能イテレータは、また、それがデータ・フロー２０２においてデータを処理している時、要求があるとすぐに、リアルタイム・データをフィルタし、マップして、強化する柔軟な方法を提供する。アプリケーション・フレームワークでデータ・フロー２０２を処理するメモリのモデルは、以下により詳細に説明される。
【００３８】
説明した実施形態の状況の範囲内においては、一般的には２種類のアプリケーション・フレームワークで採用される再構成可能イテレータがある。「データ・メッセージ・イテレータ」および「データ・イテレータ」である。例えば、データ・フロー２０２のメッセージ・ソース２０４コンポーネントは、下位レイヤであるメッセージング・レイヤ２１２により提供された未加工データを取得し、再構成可能なオブジェクト２１２−１の形状でデータ・メッセージ・イテレータの実施において未加工データをラップする。メッセージ・ソース２０４では、データに課される長方形の形状ではなく、属性と値との組（属性、値）の単なる集合であり、その集合は、プライマリ識別子のある形状により、共にグループ化される。属性は、オブジェクト、要素またはファイルのプロパティを定義するエンティティとすることができる。属性は、名前（またはキー）および値を含むことができる。値は、数、文字列、配列、および、例えば数であるかのように処理できるものとすることができる。構成可能なプライマリ識別子の例は、市場シンボル(market symbol)又は取引識別(trade identification)を備えることができる。次いで、メッセージ・ソース２０４は、再構成可能なオブジェクト２１２−２の形状でテーブル２０６に対して、データ・メッセージ・イテレータでラップされた未加工データを提供する。長方形の形状は、テーブル２０６においてデータに課される。特に、テーブル２０６は、一組の指定された、登録した行とカラムとを備えることができ、それは、これらの指定をインカミング・データにマッチングする。最終結果は、テーブル２０６が、データ・イテレータにデータを通す。このデータ・イテレータは、特定の更新値についての行番号およびカラム番号のような構造情報を検索するためのアクセス機構(accessor)をも提供する点を除いて、データ・メッセージ・イテレータに類似している。
【００３９】
例えば、以下の更新（仮に［キー  カラム  値］と標記する）を考慮する。すなわち、モルガン・スタンレー、取引価格１００である。データ・メッセージ・イテレータ・レベルでは、キーが「モルガン・スタンレー」、カラムが「取引価格」、そして、値が１００である更新があるということが、知られている全てのことである。一旦更新がテーブル２０６を通じて受け渡された場合、「モルガン・スタンレー」の行および「取引価格」のカラムが存在すると想定して、データ・イテレータは、更新が指定された行又はカラムで行われたことを判断するために使用することができる。オプションとして、行およびカラムは、自由に作成され得る。
【００４０】
従って、再構成可能なオブジェクト２１２−１、２１２−２、２１２−３、２１２−４または構造（コンストラクト）は、その内部構造または状態を変化させることができ、その結果、それぞれが実際に異なるオブジェクトを作成し、次いで、ガーベッジ・コレクタのリソースを用いる必要なしに、完全に異なるオブジェクトのようにふるまう。再構成可能なオブジェクト２１２−１、２１２−２、２１２−３、２１２−４を作成することが若干の公知の副次的な作用を有することがあるが、再構成可能なオブジェクト２１２−１、２１２−２、２１２−３、２１２−４を作成することにより、他のオブジェクトを生成する必要性を生じさせないようにしている。Ｊａｖａ（登録商標）および．ＮＥＴのような管理プログラミング言語では、これによりガーベージ・コレクタに対するワーク量が削減され、パフォーマンスが向上する。このように、特定の再構成可能なオブジェクト又はコンストラクトは、そのオブジェクト又はコンストラクトの異なるのインスタンスに似るように再構成された内部構造を有することができる。このことの１つの利点は、ガーベッジ・コレクタを採用する言語において、ガーベッジ・コレクションが引き起こされることはないということである。
【００４１】
オブジェクト指向プログラミングでは、ランタイム・システム１１６、１２６は、オブジェクトを、プログラムの基本構成単位（basic building block）として用いるランタイム・データ・ストレッジの単独ユニットとして取り扱う。これらのオブジェクトは、プログラムが機能の集合として見受けられる従来のビューとは対照的に、即ち、コンピュータへの命令のリストとして、相互に作用する。各々のオブジェクトは、メッセージを受け、データを処理し、および別のオブジェクトにメッセージを送ることができる。各々のオブジェクトは、別個の役割又は責任を有する独立した小さなマシン又は作用主と捉えることができる。
【００４２】
オブジェクト指向プログラミングでは、ランタイム・システム１１６、１２６は、プログラム（即ち、コンピュータが起動させるプログラム）のインスタンスを、１組の動的な相互作用オブジェクトとして処理する。ランタイム・システム１１６、１２６のオブジェクトは、上述したオブジェクトのより一般的な概念を拡張しており、非常に固有化した種類の型(typing)を含む。この型は、オブジェクトに関連したデータを表すデータ・メンバ、および、所定の方法でこのデータ・メンバにアクセスするメソッドを許容する。
【００４３】
ほとんどのオブジェクトの場合、データ・メンバは、メソッドのメンバーを通じてのみアクセスされ、データが常に明確な状態（クラス不変が実施されることになる）のままとなることを保証するのをたやすくする。しかしながら、いくつかの言語では、データ・メンバとメソッドとの間で区別はしない。
【００４４】
各々のオブジェクトがクラスから生成される言語では、オブジェクトは、当該クラスのインスタンスと呼ばれる。各々のオブジェクトが型を有している場合は、同一のクラスを有する２つのオブジェクトは、同一のデータ・タイプを有することとなる。クラスのインスタンスを生成することは、時々、クラスのインスタンス化と呼ばれる。
【００４５】
オブジェクトは、次の特性によって特徴付けられる。すなわち、
(1)同一性：一つのオブジェクトを他のオブジェクトと区別するオブジェクトの特性、
(2)状態：オブジェクトに格納されるデータを記述、
(3)ふるまい：オブジェクトを用いることができるオブジェクト・インターフェースのメソッドを記述する。
【００４６】
一実施形態においては、アプリケーション・フレームワーク内のランタイム・システム１１６、１２６は、データ・フロー２０２において再構成可能なオブジェクト２１２−１、２１２−２、２１２−３，２１２−４、２１２−５を定義および、サポートするように構成し、適応させることがある。この再構成可能なオブジェクト２１２−１、２１２−２、２１２−３、２１２−４，２１２−５は、以下の「Ｆｏｏ」クラスの再構成可能なオブジェクトＦｏｏとして実施することができる。「変数」フィールドでは、再構成可能なオブジェクトの状態を定義し、ＲｅＩｎｉｔｉａｌｉｚｅメソッドは、外界(outside world)での再構成可能なオブジェクトＦｏｏの相互作用を定義する。擬似コードは、以下のとおりである。
class Foo
{ 
int variable;
void ReInitialize(int var)
{
variable = var;
}
}
異なるアクションを表すために何度も再構成可能なオブジェクトＦｏｏを再利用することの一例として、マウスクリックごとに新しいオブジェクトを生成のではなく、同一オブジェクトＦｏｏを更新することがある。別の一例として、ネットワーク１０２からの全てのインカミング・メッセージのための新しいオブジェクトを生成するのではなく、同一の再構成可能オブジェクトＦｏｏを再利用することがある。
【００４７】
再構成可能なオブジェクト２１２−１、２１２−２、２１２−３、２１２−４、２１２−５を最適化することが重要になる１つのエリアでは、配列を用いる。配列は、共通の場(place)であり、配列をリセットすると、管理言語でオブジェクト割り当てを要求することになりがちである。しかしながら、一実施形態においては、配列は、そのどれくらいが用いられているかカウントする整数を定義することにより、オブジェクトを割り当てることなくリセットされることができ、そして、既存の配列があまりに小さい場合に、新たな配列を割り当てだけをすることができる。
【００４８】
一実施形態においては、再構成可能なオブジェクトは、多くの類似する又は同一の再構成可能なオブジェクトの状態を備えることができ、インターフェースを再構成可能なオブジェクトに呈示する。また、このインターフェースは、グループ内の多くの再構成可能なオブジェクトの全てを介して移すためのインターフェースを呈示する。これにより、多くの再構成可能なオブジェクトを一体として格納するのを可能にし、再構成可能なオブジェクトの生成を減らし、その結果、ガーベッジ・コレクションを減らす。
【００４９】
再構成可能イテレータと従来のイテレータ（例えばＸＭＬリーダー、データベース・イテレータ）との違いの一つとして、再構成可能イテレータ（または再構成可能なオブジェクト）およびそのふるまいが、データをコピーするためのアクセスを特定の時点で提供するのではなく、まだなお利用可能であるということがある。
【００５０】
配列を備える再構成可能なオブジェクトＦｏｏの一例は、以下の擬似コードで表現することができ、ここでは、フィールド「m_stuff」および配列「m_iterator」は、「０」にリセットされ、そしてフィールド「m_stuff」は、配列がどれくらい使われかをカウントするのに用いられる。
class Foo
{
int[] m_stuff;
int m-iterator;
void DoSomethingO
{
Log(m_stuff[m_iterator]);
}
void Reset()
{
m_iterator=0;
}
void Advance()
{
++m_stuff;
}
}
再構成可能なオブジェクトＦＯＯの別の特徴は、イテレータ（例えば、「データ・メッセージ・イテレータ」及び／又は「データ・イテレータ」）に含まれるデータを部分的に示すことである。例えば、メッセージ・ソース２０４からのデータの一部は、クライアント・コード／ディスプレイ２１０に示されることがあり、データの別の部分は、別のクライアントに示されることがある。イテレータ内では、ロジックを、構成に基づいて異なるクライアントに、データセットの異なる部分を示すために採用することができる。一実施例では、ビットマップを、現在のクライアントがどの部分のデータを参照することになっているかを記録するために採用されすることができる。この情報は、ユーザが次の項目を求める際に、どの部分のデータセットに進むかについて決定するのに用いられる。
【００５１】
1つの実施形態において、ビットマップは、大いにパフォーマンスを向上させるために、
特定のデータセットについてイテレーションのフローを制御するのに用いることができる。
【００５２】
先に説明したように、アプリケーション・フレームワークは、一般的なレイヤ化したフレームワークとして実施される。すなわち、このような実施においては、データ・フロー２０２を構成することは、一組のレイヤを構成することにほぼ等しい。アプリケーション・フレームワークのコンテキストでは、データ・フロー２０２は、最も下位のネットワーク・レイヤから最も上位の「ビュー」レイヤへのレイヤのスタックとして定義することができる。
【００５３】
データ・フロー２０２は、インターフェースを介して相互作用する。データ・フロー２０２内の複数のコンポーネント（例えば、メッセージ・ソース２０４、テーブル２０６、及びビュー２０８）は、同じインターフェースを実施する。したがって、データ・フロー２０２内の複数のコンポーネント（例えば、メッセージ・ソース２０４、テーブル２０６、及びビュー２０８）は、どのように管理されるかを認識しており、互いと相互作用して正しい最終結果を提供する。整合されたエンティティとして、データ・フロー２０２と相互作用するために、所定の再構成可能なオブジェクト又はコンストラクトを用いて、質問のインターフェースの最上位の実施を抽出することができる。
【００５４】
データ・フロー２０２は、キャッシュ・データ・フローまたは非キャッシュ・データ・フローとして構成することができる。先に述べたように、データ・フロー２０２は、メッセージング・レイヤ２１２からのメッセージ・ソース２０４によって受け取られ、再構成可能なオブジェクトを用いてクライアント・コード／ディスプレイ２１０に向けてテーブル２０６およびビュー２０８を通すようなデータのフローである。データ・フロー２０２をキャッシュする振る舞いは、テーブル２０６の実施により決定される。アプリケーション・フレームワークは、テーブル２０６の２つの実施、即ち、データがテーブル２０６を通される際に全ての「申し込まれた(subscribed)」データをキャッシュするキャッシュの実施と、どのデータもキャッシュしない非キャッシュの実施とを提供する。
【００５５】
図３は、アプリケーション・フレームワークにおけるランタイム・システム１１６、１２６で分岐した混合モード・データ・フロー３０２の一実施形態を示すブロック図３００である。メッセージング・ソース２０２からメッセージ・レイヤ２１２へのデータ・フローを有する再構成可能なオブジェクト３０８の形態で単一接続のベース・フローを用いる混合モード・データ・フロー３０２は、２つの分岐、即ち、キャッシュ・フロー分岐３０４と、非キャッシュ・フロー分岐３０６とに分岐される。キャッシュ申込み(キャッシュ・サブスクリプション)のセットは、キャッシュ・フロー分岐３０４を通じて管理され、非キャッシュ申込みのセットは、非キャッシュ・フロー分岐３０６を通じて管理される。これらフロー分岐３０４、３０６の各々は、ベース・フロー３０８からフィードする。前述のとおり、データ・フロー３０２の中の情報は、再構成可能なオブジェクト又はイテレータ３２０−１、３２０−１、３２０−３、３２０−４を用いることにより交換することができる。情報は、再構成可能なオブジェクト３１８の形態で、ビュー３１２、３１６からクライアント・コード／ディスプレイ２１０まで通される。
【００５６】
キャッシュ・フロー分岐３０４では、メッセージ・ソース２０２は、メッセージング・レイヤ２１２からベース・フローを通じて受けた再構成可能なオブジェクト３０８の未加工データを、データ・メッセージ再構成可能イテレータ３２０−１でラップして、キャッシュ・テーブル３１０に提供および格納する。ラップされたデータが、キャッシュ・テーブル３１０に一旦格納されると、平均アクセス時間を少なくするために、メッセージ・ソース２０２からのオリジナル・データを再フェッチ（re-fetching）又は再計算（re-computing）するのではなく、キャッシュ・テーブル３１０において、ラップされたデータについてのキャッシュされたコピーにアクセスすることにより、将来的に使用される。キャッシュ・テーブル３１０は、ラップされたデータを、再構成可能イテレータ３２０−２および第１のビュー３１２に通す。混合モード・データ・フロー３０２のキャッシュ・フロー分岐３０４における第１のビュー３１２は、混合モードのデータ・フロー３０２を通して伝える際、データを制約し、変換し、又は圧縮するために、フロー構造となる。第１のビュー３１２は、キャッシュ・テーブル３１０を越えて制約される「ビュー」を提供する。
【００５７】
非キャッシュフローブ分岐３０６においては、メッセージ・ソース２０２は、メッセージング・レイヤ２１２からベース・フローを通じて受けた再構成可能なオブジェクト３０８の未加工データを、データ・メッセージ再構成可能イテレータ３２０−３でラップしたルーティング・テーブル３１４に提供および格納する。ルーティング・テーブル３１４は、再構成可能イテレータ３２０−４と第２のビュー３１６に対し、ラップされたデータを通す。混合モード・データ・フロー３０２の非キャッシュ・フロー分岐３０６の第２のビュー３１６は、また、混合モード・データ・フロー３０２を通じて伝える際、データを制約し、変換し又は圧縮するために、フロー構造となり得る。第２ビュー３１６は、ルーティング・テーブル３１４を越えて制約される「ビュー」を提供する。
【００５８】
図４は、アプリケーション・フレームワークにおけるランタイム・システム１１６、１２６でのマルチ・ビュー・データ・フロー４０２の一実施形態を例示している図４００である。前述のとおり、マルチ・ビュー・データ・フロー４０２の情報は、再構成可能なオブジェクト及び／又は再構成可能イテレータを用いて交換される。たとえば、メッセージング・レイヤ２１２からの情報は、単一の接続４０８を介して受け、再構成可能なオブジェクト４２０−１の形態でメッセージ・ソースに通される。メッセージ・ソース２０２からの情報は、再構成可能なオブジェクト４２０−２の形態でテーブル２０６に通される。テーブル２０６は、再構成可能なオブジェクト４２０−３の形態で接続４１０を介してビュー４０４に情報を通す。次いで、ビュー４０４は、再構成可能なオブジェクト４２０−５の形態でクライアント・コード／ディスプレイ２１０に情報を通す。同様に、テーブル２０６は、再構成可能なオブジェクト４２０−４の形態で別の接続４１２を介して別のビュー４０６に情報を通す。次に、ビュー４０６は、再構成可能なオブジェクト４２０−６の形態でクライアント・コード／ディスプレイ２１０に情報を通す。
【００５９】
図４に例示される実施形態では、マルチカスタムビュー４０４、４０６は、より大きなサブスクリプション・セットで生成され得る。即ち、メッセージ・レイヤ２１２への単一の接続４０８のために、マルチ・ビュー４０４，４０６は、例えば、解体する（disjoint）又は重ね合わせる(overlapping)といったサブスクリプション・セットを用いて生成され得る。２つのビュー４０４、４０６が示すが、マルチ・ビュー・データ・フロー４０２は２つ以上、若しくは複数のビューを備えることができると考えられる。クライアント・コード／ディスプレイ２１０は、関連する更新が各々の複数の接続４１４、４１６を介して発生するとき、マルチ・ビュー４０４、４０６から通知を受ける。
【００６０】
マルチ・ビュー・データ・フロー４０２は、フローのサブスクリプション管理を取り扱う。たとえば、マルチ・ビュー４０４、４０６が同一のテーブル２０６にアタッチされていれば、アプリケーション・フレームワークは、あらゆるサブスクリプションの参照カウントを内部管理する。これらのマルチ・ビュー４０４、４０６から同じキーに対してサブスクライブすると、マルチ・ビュー４０４、４０６がサブスクライブを解除する(unsubscribe)まで、サブスクリプションが、「グローバルに」アクティブのままとなる。さらに、たとえば、マルチ・ビュー４０４のうちの１つがサブスクライブを解除しさえすれば、ビュー４０４は、そのサブスクリプションについての更新を伝えるのを止めることになり、他方、残りのビューを続行することになる。
【００６１】
マルチ・ビュー４０４、４０６は、ダイナミックに生成され、ランタイム・システム１１６、１２６によって実行時にテーブル２０６にアタッチされ得る。したがって、ある現在のビューをミラーする一次的なビューを構築することができ、次いで、一旦ディスプレイが変わると、それを解体することができる。この機能は、予め決められたインターフェースを通じて提供することができる。このインターフェースは、３つのメソッドを提供する。
【００６２】
この状況において更に考慮すべき点は、キーがサブスクライブされてときに、サブスクリプションを生成する１つのビュー４０４から何が起きるかということであり、ここでは、そのキーは、別のビュー４０６からすでにサブスクライブされており、テーブル２０６が、キャッシュしているということである。この場合、それぞれのアプリケーション・フレームワーク内のランタイム・システム１１６、１２６は、サブスクリプションを生成するビュー４０４への即時アップデートとしては、キャッシュ値を発行しない。
【００６３】
いくつかの所定の例外を除いて、ランタイム・システム１１６におけるアプリケーション・フレームワーク内で提供されるレイヤは、安全に取り扱われる。ランタイム・システム１１６のパフォーマンスを損なわないために、例外は安全にはされない。特定のネットワーク・スレッディング・モデル(network-threading model)を採用することに基づいて、これらのコンポーネントは、更新スレッドから同期をすることなく、スレッドを安全にさせる。このように、ユース・ケースにペナルティは課さなくするために、ここでは、初期テーブル／ビューの構造は、ユーザによる更なる修正がないことに付随して、（静的又は動的にwildcards／greedyオプションを用いて）セットアップされ、更新スレッドとユーザ・スレッドとの間の同期は、提供しないくすることができる。
【００６４】
図５は、アプリケーション・フレームワークのランタイム・システム１１６、１２６でマージされたビュー・データ・フロー５０２の一実施形態を示している。上述したとおり、アプリケーション・フレームワークは、ストレート・データ・フロー（例えば、図２に示すデータ・フロー２０２）及び／又はブランチ・データ・フロー（例えば、図３に示す分岐データ・フロー３０２、又は図４に示すマルチ・ビュー・データ・フロー４０２）を生成するために用いられる。アプリケーション・フレームワークとランタイム・システム１１６、１２６はさらに、複数のデータ・フロー５０２―１〜ｍのビューを結合（マージ）するための機能を提供することができる。マージされたビューの多数のデータ・フロー５０２−１〜ｍは、たとえば、外部キー・コンセプトを用いて実施される。データ・フロー５０２−１〜ｍのｍ分岐までをマージすることができる。ここで、ｍは任意の整数である。
【００６５】
図示した実施形態では、アプリケーション・フレームワークのランタイム・システム１１６、１２６は、２方向のマージャ（merger）をサポートするために用いられる。しかしながら、このマージャは、ｍ方向のマージャを生成するために繋ぐことができる。第１（プライマリ）のデータ・フロー５０２−１では、第１のメッセージ・ソース５０４−１は、再構成可能なオブジェクト５１６−１の形態で第１のメッセージング・レイヤ５０６−１から未加工データを受け取る。同様に、第２（セカンダリ）のデータ・フロー５０２−２では、第２のメッセージ・ソース５０４−２は、再構成可能なオブジェクト５１８−１の形態で第２のメッセージング・レイヤ５０６−２から未加工データを受け取る。第１メッセージ・ソース５０４−１は、次いで、第１データ・フロー５０２−１の第１テーブル５０８−１に、第１のデータ・メッセージ再構成可能イテレータでラップされた未加工データを提供し、さらに、第２のメッセージ・ソース５０４−２は、次いで、第２のデータ・フロー５０２−２の第２テーブル５０８−２に、第２のデータ・メッセージ再構成可能イテレータ５１８−２でラップされた未加工データを提供する。第１のビュー５１０−１は、再構成可能イテレータ５１６−３を介して第１テーブル５０８−１を越えて制約されるビューを提供し、第２のビュー５１０−２は、再構成可能イテレータ５１８−３を介して第２テーブル５０８−２を越えて制約されるビューを提供する。マージ・ビュー５１２は、例えば、第１ビュー５１０−１及び第２５１０−２から生成することができる。単一の接続５１４のマージャ・インターフェースは、再構成可能イテレータ５２０を通じてクライアント・コード／ディスプレイ２１０に提供される。
【００６６】
図６は、ロジックフロー６００の一実施形態を示す。マージャ・インターフェースを単純化するために、マージ・ビュー５１２は、以下のロジックフローに従ってセットアップされる。空の第１データ・フロー５０２−１（又は、既存のフローに空のトップレベル・ビュー）を生成（６０２）する。空の第２データ・フロー５０２−２（又は、既存のフローに空のトップレベル・ビュー）を生成（６０４）する。第１データ・フロー５０２−１および第２データ・フロー５０２−２を、キー・ビルダのインターフェースの実行インスタンス、及び外部キー・スペック・インスタンス（これらは、以下に更に詳細に説明する）に沿って、新たなマージ・ビュー５１２を生成（６０６）する。第１のトップレベル・ビュー５１０−１および第２のトップレベル・ビュー５１０−２における所要のカラムを生成（６０８）する。第１データ・フロー５０２−１におけるキーを登録（６１０）する。所要のカラムを生成する一方で、データ・マージャ・インターフェースは、発生するイベントを阻止（６１２）し、そして内部に、マッチングするカラムを生成する。このようにして、マージャは、（少なくともトップレベル・ビューの）第１ビュー５１０−１および第２ビュー５１０−２に連結（ジョイント）カラム構造を有することになる。
【００６７】
生成時にマージ・ビュー５１２に通された、この外部キー・スペック・インスタンスは、第１ビュー５１０−１および第２ビュー５１０−２のマージャそれぞれをマージするためにカラムの従属関係を特定（６１４）する。例えば、新たに生成された外部キー・スペック・インスタンスにおいて、第１データ・フロー５０２−１のカラムを特定（６１６）し、カラムはこの外部キーを構成する。マージ・ビュー５１２のインターフェースは、次いで第１データ・フロー５０２−１からのこれらのカラムに対する更新をモニターし、続いて第２データ・フロー５０２−２においてキーを登録又は解除（６１８）する。これらのキーの更新が第２データ・フロー５０２−２から到達すると、マージ・ビュー５１２のインターフェースは、これらの更新を、第１データ・フロー５０２−１からの対応する行にマップ（６２０）する。
【００６８】
アプリケーション・フレームワークのキー・ビルダのインターフェースは、あらゆるカスタム・マージ・ビュー５１２に対して実施することができる。この実施では、外部キー・スペック・インスタンスで指定されるカラムの現在値を与えられた第２データ・フロー５０２−２に対しての新しいサブスプリクション・キーを生成する。このように、カラムの１対１のマッピングは、第１データ・フロー５０２−１の外部キーと、第２データ・フロー５０２−２のプライマリ・キーとの間では、要求されない。キー・ビルダの実施は、それが適当と考えるいかなる方法でも、外部キー・カラムの値と組み合わされ、また、この値に加えられる。唯一要求されることは、第２メッセージ・ソース５０４−２で登録された際に、発生するキーがプライマリ・カラムにマッチするということである。
【００６９】
一実施形態において、マージ・ビュー５１２の実施は、データをローカルにはキャッシュしない。むしろ、仮想マッピングにより完全に機能する。したがって、マージ・ビュー５１２が２つのキャッシュのフローにわたって生成される場合、データは再現されない。しかしむしろ正規でない方法により、データは第１データ・フロー５０２−２および第２データ・フロー５０２−１それぞれの各テーブル５０８−１、５０８−２に格納され、次いで、データは、更新であるか、即ち、マージ・ビュー５１２の表示から読もうとしているクライアント・コード／ディスプレイ２１０のコードであるかの要求に対してのみ、一時的にマップされる。
【００７０】
したがって、リアルタイム・マージ・ビュー５１２では、２つのデータ・メッセージ・ソース５０４−１、５０４−２の間の関係は、データベース・ロジックに類似した標記により規定することができる。しかしながら、上述したように、第１のデータ・フロー５０２−１および第２データ・フロー５０２−２に関するデータは、再構成可能イテレータ５１６−１〜３および５１８−１〜３を用いて表されるため、実際の物理テーブルは、存在しておらず、仮想テーブルだけが存在する。したがって、このシステムは、１秒あたり多数（例えば、何千、何百万等）の更新を処理することができる。
【００７１】
動作において、各々の再構成可能イテレータ５１６−１〜３および５１８−１〜３は、データのマッピング要件に従って、異なる方法で再呈示される。つまり、元のメッセージ・ソース５０４−１、５０４−２は、別のカラム（例えばカラム１３）にマップすることができるマージ・ビュー５１２の１つのカラム（例えばカラム７）から来たようなデータであると説明してきた。元のイテレータを越えてイテレータを階層化することにより、イテレータがマージ・ビュー５１２を表示するような思い違いをさせるかも知れない。しかしながら、再マッピングしているコードは、ラップ・イテレータであるため、マージ・ビュー５１２のリソースには、コストは生じていない。
【００７２】
一実施形態において、上記実施は、ユーザに何を呈示すべきかを決定するために、ビットマップを用いることにより、およびプライマリ／外部キー・セルの現在の値を格納することのみにより、最適化することができる。
【００７３】
図７は、再構成可能イテレータを介してクライアント・コード／ディスプレイ２１０に表示されたデータの一実施形態を示す図７００である。クライアント・コード／ディスプレイ２１０は、図１に示されるクライアント・システム１０６、１０８、１１０の何れに関連したＧＵＩ１２８のユーザに、データを表示することができる。クライアント・コード／ディスプレイ２１０は、データを、第１の値のセット７０２が第１メッセージ・ソース５０４−１からのものであるデータの単一部分として解釈する。
【００７４】
第２の値のセット７０４は、第３のセットの値７０６に対するプライマリ・キーを形成する。第３の値のセット７０６は、第２メッセージ・ソース５０４−２から来たものである（これらの値は、如何なるフォーマットでもよく、例えば、テキスト、日付、及び図示したような必要な数字のみである）。このことは、更新に関する値であると認識されるが、前段落で説明した再構成可能イテレータからの解釈に過ぎない。
【００７５】
動作では、アップデート部分が、加わり、強化(enriched)される。上述の例では、第１の値のセット７０２における値７０２−１〜４は、クライアント・コード／ディスプレイ２１０の左方のソースからの一更新において、出現する。左方ソースの再構成可能イテレータは、次いで、デコレートされることになり、クライアント・コード／ディスプレイ２１０即ちマージ・ビュー５１２のカスタマーは、たとえ値が元のメッセージ・ソース５０４−１における完全に異なる所から来ることができたとしても、値が、第２のカラムＣ２、第４のカラムＣ４、および隣接する行のそれぞれに出現していることを理解する。このことは、列／カラム位置を参照し、デコレータにおいてこれらの参照を変換することによって達成される。
【００７６】
第４の値のセット７０６−１は、同一のイテレータ内から到着することもあり、これらの値を正しいデコレータを有するクライアント・コード／ディスプレイ２１０に通過させ、その結果、クライアント・コード／ディスプレイ２１０は、それらをカラムＣ６−Ｃ９から来たように認識する。また、クライアント・コード／ディスプレイ２１０は、正しい行番号を認識することができる。一実施形態において、第二のメッセージ・ソース５０４−２からの再構成可能イテレータは、キーの値７０４−１、７０４−２（ここでは、３９２５および２０３０）へジャンプして戻ることができるようにする必要がある。なぜなら、第２セット７０４（すなわちカラムＣ５）の複数の値が、第１セット７０２（すなわちカラムＣ１〜Ｃ４）の値と同一であるとすれば、それらすべてが同じ値であることが必要となるからである。このことは、異なる行表示で絶えず値を戻すことにより達成することができる。結果として、異なるカラム番号で繰り返しデコレートできるように、下位の(underlying)再構成可能イテレータは、ジャンプして戻ることができなければならない。
【００７７】
一実施形態において、マージ・ビュー・データ５０２のプロセスは、再構成可能イテレータ・オブジェクトおよびイテレータ・デコレータを再利用することにより、毎回それらを再生成することなく、さらに最適化することができる。
【００７８】
マージ・ビュー５１２の実施は、それらが変更したかどうか判断するために、連結した値７０１−１を格納する。次いで、それらが変更した場合には、第２メッセージ・ソース５０４−２は、マージ・ビュー５１２が以前に指定したキーの更新をもはや要求しないこと、および現在更新する必要のある新たなキーを指定する必要があることが通知される。
外部キーが一意でないことがあるため、参照カウントが、時々必要である。
【００７９】
別の再構成可能イテレータにおけるの更新のイテレータの値のセットを一時的にキャッシュできるビューを有するもまた有用である。このようなキャッシュを行うことなく必要とされる複数の受け渡しにかわり、一つの受け渡しでこのことを処理することができる。一実施形態においては、このことは、単に下位のテーブルにオフセットを格納することにより、および必要な際に現在の値を再抽出するためにそれらを使用することにより、実行されることができる。
【００８０】
ここに呈示する例は、本発明の潜在的なそして具体的な実施態様を例示することを意図している。尚、これらの例は主に当業者のために本発明を例示することを目的とすることは認めることができる。前述の例の１つまたは複数の特定の態様も、本発明の範囲を限定することを意図していない。
【００８１】
尚、本発明の図および説明は、明確化を目的として、他の要素を排除しつつ、本発明の明確な理解に関係する要素を示すように、簡略化されていることは理解されてしかるべきである。例えば、ある種のオペレーティング・システムの詳細や、ネットワーク・プラットホームのモジュールについては、ここでは説明していない。しかしながら、これらおよびその他の要素は、例えば、典型的なプロセッサ、コンピュータ・システムまたは電子メール・アプリケーションにおいては望ましい場合もあり得ることは、当業者には認められよう。しかしながら、このような要素は当技術分野では周知であり、これらは本発明の理解を深めることには役に立たないので、このような要素の論述はここでは設けられていない。
一般に、ここに記載した実施形態の少なくとも一部は、ソフトウェア、ファームウェア、および／またはハードウェアの多くの異なる実施形態で実施してもよいことは、当業者には明白なはずである。ソフトウェア・コードおよびファームウェア・コードは、プロセッサまたは他のいかなる類似のコンピューター・デバイスでも実行することができる。ソフトウェア・コードまたは特殊化制御ハードウェアを、本発明の実施形態を実施するために用いることもできるが、これは限定ではない。例えば、ここに記載した実施形態は、例えばＣまたはＣ＋＋のようないずれかの適したコンピュータ・ソフトウェア言語を用いて、あるいは、例えば、従来のまたはオブジェクト指向技法を用いて、コンピュータ・ソフトウェアで実施することができる。このようなソフトウェアは、例えば、磁気または光記憶媒体のような、１つまたは複数の適したコンピュータ読み取り可能媒体であればいずれの種類であっても、格納することができる。本発明の実施形態の動作および挙動は、特定のソフトウェア・コードや特殊化ハードウェア・コンポーネントに具体的に参照することなく、記載することができる。このような具体的な参照を行わないことは現実にあり得ることである。何故なら、当業者であれば、本明細書に基づけば、それなりの労力だけで、過度な実験を行わなくても、本発明の実施形態を実施するためのソフトウェアおよび制御ハードウェアを設計することができるからである。
【００８２】
更に、本発明の実施形態に付随するプロセスは、コンピュータまたはコンピュータ・システムのような、プログラム可能な機器によって実行することができる。プログラム可能機器にプロセスを実行させることができるソフトウェアは、例えば、コンピュータ・システム（不揮発性）メモリ、光ディスク、磁気テープ、または磁気ディスクのような、いずれの記憶デバイスにでも格納することができる。更に、これらのプロセスの少なくとも一部は、コンピュータ・システムを製造するときにプログラミングし、様々な種類のコンピュータ読み取り可能媒体に格納することができる。このような媒体は、記憶デバイスに関して先に列挙した形態のいずれも、および／または、コンピュータまたはコンピュータ・システムが読み取る、復調／デコードする、または実行することができる命令を伝達するために変調またはそれ以外で操作した搬送波を含むことができる。
【００８３】
また、ここに記載したある種のプロセスの態様は、コンピュータ・システムにプロセス・ステップを実行するように指令する１つ以上のコンピュータ読み取り可能媒体上に格納した命令を用いて実行してもよいことも認めることができよう。コンピュータ読み取り可能媒体は、例えば、ディスケット、コンパクト・ディスク（ＣＤ）、ディジタル・バーサタイル・ディスク（ＤＶＤ）、光ディスク・ドライブ、またはハード・ディスク・ドライブのような、メモリデバイスを含むことができる。また、コンピュータ読み取り可能媒体は、物理的、仮想的、永続的、一時的、半永続的、および／または半一時的であるメモリ・ストレージを含むこともできる。更に、コンピュータ読み取り可能媒体は、１つ以上の搬送波上で送信される１つ以上のデータ信号も含むことができる。
【００８４】
「コンピュータ」又は「コンピュータ・システム」は、例えば、限定ではなく、種々のワイヤレスまたはワイヤライン型のマイクロコンピュータ、マイクロプロセッサ、ミニコンピュータ、サーバ、メインフレーム、ラップトップ、パーソナル・データ・アシスタント（ＰＤＡ）、ワイヤレス電子メール・デバイス（例えば、「BlackBerry」取引指定デバイス(trade-designated device)）、セルラ電話機、ページャ、プロセッサ、ファックス機、スキャナ、あるいはネットワークを通じてデータを送信および／または受信するように構成されているその他のいずれのプログラム可能なデバイスでもよい。本明細書で開示されるコンピュータ・システムおよびコンピュータに基づくデバイスは、データを獲得する、処理する、格納する、且つ／又は通信するのに使用される幾つかのソフトウェア・アプリケーションを格納するためのメモリを含むこともできる。そのようなメモリは、開示した実施形態の動作に対しては、内部であることも、外部であることもあり得ることは認められよう。また、メモリには、ハード・ディスク、光ディスク、フロッピ・ディスク、ＲＯＭ（リード・オンリメモリ）、ＲＡＭ（ランダム・アクセス・メモリ）、ＰＲＯＭ（プログラマブルＲＯＭ）、ＥＥＰＲＯＭ（電気的消去可能ＰＲＯＭ）、および／またはその他のコンピュータ読み取り可能媒体を含むこともできる。
【００８５】
ここに開示した本発明の種々の実施形態では、１つ以上の所与の機能を実行するために、単一の構成要素を多数の構成要素で置き換えることもでき、更に多数の構成要素を単一の構成要素で置き換えることもできる。このような交換が機能しない場合を除いて、このような交換は、発明の範囲に該当するものとする。例えば、ここに記載したいずれのサーバでも、共動機能に合わせて配置および構成した「サーバ・ファーム」(server farm)またはネットワーク型サーバのその他の集合体と置き換えることもできる。尚、サーバ・ファームは、ファームの個々の構成機器間で作業負荷を分散するのに供することができ、多数のサーバの集合および協同パワーを利用することによって、計算プロセスを捗らせることができることは認められよう。このようなサーバ・ファームは、例えば、異なる機械からの処理パワー要求を追跡する、ネットワーク要求に基づいてタスクに優先順位を付けて予定を組むこと、および／または構成機器の故障または動作可能性の低下の場合に付則の事態に備えてバックアップを行うことのようなタスクを遂行する負荷均衡ソフトウェアを採用することができる。
【００８６】
ここでは本発明の種々の実施形態について説明したが、これらの実施形態に対する種々の修正、変更、および改造は、本発明の利点の少なくとも一部を達成することにより、当業者には容易に想起できることは、明白なはずである。したがって、開示した実施形態は、添付した特許請求の範囲に明記した本発明の範囲および主旨から逸脱することなく、このような修正、変更、および改造を全て含むことを意図している。
【図面の簡単な説明】
【００８７】
【図１】図１は、ネットワークがサーバを一つ以上のクライアント・システムにリンクするクライアント／サーバ・システムを例示している。
【図２】図２は、プリケーション・フレームワークにおけるランタイム・システム上のデータ・フローの一実施形態を例示しているブロック図である。
【図３】図３は、アプリケーション・フレームワークにおけるランタイム・システム上の分岐した混合モード・データ・フローの一実施形態を例示しているブロック図である。
【図４】図４は、アプリケーション・フレームワークにおけるランタイム・システム上のマルチ・ビュー・データ・フローの一実施形態を例示している図である。
【図５】図５は、アプリケーション・フレームワークにおけるランタイム・システム上のマージ・ビュー・データ・フローの一実施形態を例示している図である。
【図６】図６は、ロジック・フローの一実施形態を例示している。
【図７】図７は、イテレータによってクライアントに呈示されたデータの一実施形態を表す図である。
【手続補正３】
【補正対象書類名】図面
【補正対象項目名】全図
【補正方法】変更
【補正の内容】
【図１】
2008135035.tif 000001
【図２】
2008135035.tif 000002
【図３】
2008135035.tif 000003
【図４】
2008135035.tif 000004
【図５】
2008135035.tif 000005
【図６】
2008135035.tif 000006
【図７】
2008135035.tif 000007