JP2004507801A - 階層独立のデータアクセスフレームワーク - Google Patents

Abstract

種々の環境において用いるデータアクセスアプリケーションを開発するフレームワークを提供する。データオペレーションが２階層環境における中間階層サーバ上で実行される場合、上記オペレーションおよびその効果は上記クライアントに通信されて、これにより、上記オペレーションおよび効果が上記クライアントで再現され得る。３階層環境において、中間階層サーバ上で動作するイベントマネジャーは、クライアントに伝達されるオペレーションの上記効果を取り込む。クライアントキャッシュは、データオペレーション用の制限されたデータ量を格納して、中間階層オペレーションの上記効果を受信する。ライトウェイトプロキシにより、クライアントは、上記クライアントがコールの効果を再現するために必要なすべてのプログラミング論理を含まずとも、中間階層サーバ上で実現される方法を上記コールすることが可能になる。
【選択図】図１Ｃ

Description

【０００１】
（背景）
本発明は、コンピュータシステムおよびデータアクセスアプリケーションプログラムのフィールドに関する。具体的には、階層（ｔｉｅｒ）から独立したデータアクセスアプリケーションを開発および動作するシステムおよび方法を提供する。
【０００２】
今日のアプリケーション開発ツールは通常、アプリケーション（例えば、データにアクセスおよび／またはデータを操作するプログラム）を開発することを可能にし、指定された形態を有する演算環境内においてのみ動作する。例えば、ある開発ツールは、２階層環境（例えば、クライアント／サーバアーキテクチャ）のアプリケーションを設計する際に用いられ得、異なるツールは独立型コンピュータシステム上で起動するアプリケーションに用いられる。通常、ある種類の環境（例えば、２階層）に開発されたアプリケーションは、再度のコンパイルを含む著しい改変無しには、異なる環境（例えば、３階層）において動作し得ない。
【０００３】
独立型アプリケーションから２階層（例えば、クライアント／サーバ）環境に進化したデータベースアプリケーションとちょうど同じように、３階層環境は今日ますます普及してきている。データベースのオペレーション用の例示の３階層環境は、ユーザのコンピュータシステム（例えば、クライアント）、中間階層コンピュータサーバ、およびデータベースまたは他のデータの集まりを含むデータベースサーバから構成され得る。２階層環境または３階層環境用のデータアクセスアプリケーションを開発する現在のアプリケーション開発ツールにより、ターゲット環境に通常限定されているアプリケーションが得られる。２階層環境において開発され、動作するアプリケーションは、相当変えなければ、３階層環境において動作することは不可能であり、そして、３階層環境において開発され、動作するアプリケーションも、相当変えなければ、２階層環境において動作することは不可能である。
【０００４】
既存のアプリケーション開発システムでの１つの問題は、多階層の間でデータ処理を効率的に分割しながら、性能および拡張性を最大限に活かすことが不可能である点である。これが試みられた１つの非効率的な様態は、リモートの手順および／または方法を用いてであった。特に、ＣＯＲＢＡ（共通オブジェクトリクエストブローカリングアーキテクチャ）、ＲＰＣ（リモート手順コール）、ＥＪＢ（エンタープライズＪａｖａ（Ｒ）ビーンズ）およびＲＭＩ（リモート方法実施）はそれぞれ、リモートの手順または方法のコールの所定の形態を実現する。これらのシステムにより、例えば、１階層において動作するクライアントが別の階層に透過的なコールを行うことが可能になる。しかし、この効果は他の階層に処理の負担を単に移行するだけである。これらのシステムは、処理を階層間で共有することを可能にしたり、またはプログラミングの均一性（ｕｎｉｆｏｒｍｉｔｙ）および／またはトランスポート性を促進するために何もしない。特に、これらのシステムは、ある階層上のデータオペレーションの結果が別の階層上で再現または反映されていることを保証しない。
【０００５】
多階層を有する環境における関連の問題は、アプリケーションまたはアプリケーションの一部が通常、アプリケーションまたはアプリケーションの一部が最終的に動作する階層上で開発およびテストされる必要があることである。そうでない場合、アプリケーションまたはアプリケーションの一部を、最終的なオペレーション階層にトランスポートした場合に、実質的に変える必要がある。ここでも、この問題は、既存のアプリケーション環境が、データオペレーションの効果および関連のイベントを関与階層（例えば、クライアントおよび中間階層サーバ）間で均一にすることができないことに起因する。
【０００６】
多階層の演算システムおよび環境の既存のアプリケーションツールはさらに、通信スキームが非効率的であるという不利益を被りやすい。特に、階層間通信の細分性はかなり低い傾向にあり、したがって、少量のデータさえ伝送するため、または小さなデータアクセスオペレーションを実行するために複数の通信が必要である。したがって、階層間で高い程度のプログラミングの均一性を有する多階層のシステムにおいて、ネットワークの性能は非常に低い。逆に、高いレベルのネットワークまたは通信の性能を維持するために、プログラミングの均一性を犠牲にする必要がある。
【０００７】
多階層環境間でプログラミングの均一性を促進することを試みる別の方法は、相互接続されたコンピュータシステム間で単にデータの同期を取ることである。特に、サーバによって維持されるかまたはキャッシュされるデータのいくつかは、クライアントシステム上で再現され得る。しかし、これは単に、データ状態をコピーするだけであり、アプリケーションを階層間でトランスポートできるようにも均一にもほとんどしない。特に、多階層上でデータ状態の同期を取ることは、データに状態を変更させる特定のトランザクションを再生または監査する必要がある情報を維持しない。例えば、ある階層で有効になったデータ変更は別の階層にコピーされ得るが、データ変更に関連した副作用またはイベントは、この結果、階層間のアプリケーションの均一性を制限しない。
【０００８】
したがって、現在のアプリケーション開発環境は、異なる多階層環境において動作され得るアプリケーションまたはプログラミングモデルを生成し、同時に、高性能（特に、ネットワーク性能）、均一性および拡張性を促進することを阻んでいる。したがって、アプリケーションが、ある環境（例えば、２階層、すなわちクライアント／サーバ）に対して開発および実現され得ながら、別の環境（例えば、３階層）においても容易に利用され得、そして、ある環境（例えば、３階層）に対して開発および実現され得ながら、別の環境（例えば、２階層、すなわちクライアント／サーバ）においても容易に利用され得る、アプリケーション開発フレームワークが望まれる。特に、このようなシステムは、特定のデータアクセスアプリケーションのオペレーションまたは挙動が異なる階層間で非常に均一であることを保証し得る。すなわち、上述したような２階層環境または３階層環境において、ユーザによって要求されたデータオペレーションが第１の階層上に影響を及ぼし得、このオペレーションの影響または結果が、オペレーションが第２の階層に固有であるかのように第２の階層に適用される。
【０００９】
さらに、プログラミングモデルは、特定の階層（例えば、「シン（ｔｈｉｎ）」クライアントなど）の制限されたリソース内で機能し、階層間における通信（例えば、ネットワーク）性能が許容可能なレベルで維持される。
【００１０】
（要旨）
本発明の一実施形態において、改変せずに、２階層演算環境または３階層演算環境のいずれかにおいて、データアクセスアプリケーションを開発および／または動作するシステムおよび方法を提供する。具体的には、以下に説明するアプリケーション開発フレームワーク内で開発されたアプリケーションは、上記アプリケーションが実行された場合に、単に適切なスイッチまたはパラメータを指定することによって、いずれかの環境において機能する。
【００１１】
このアプリケーション開発フレームワークおよび演算環境において、キャッシュはクライアントシステム（例えば、ユーザのコンピュータシステム）上で実現される。上記システムは、「シン」クライアントであり得る。上記「シン」キャッシュはサーバ（例えば、中間階層サーバまたはデータベースサーバ）によって提供されたデータで満たされている。例示するように、上記サーバによって上記クライアントに提供されたデータ量は、上記キャッシュのサイズおよび／または、ユーザの要求されたオペレーションを実行するために上記クライアントによって必要とされるデータ量に依存する。上記クライアントキャッシュは小さく保たれ得て、これにより、上記クライアント上で大量のリソースが必要であることが回避される。
【００１２】
以前のアプリケーション開発環境において行われたように、個々のデータ値より高いレベルに焦点を置くことによって、階層間（例えば、クライアントとサーバとの間）の通信を効率的にする。特に、階層間通信を、ある行内の個々のフィールドまたは属性ではなく、データベースの行またはレコードのレベルで実行し得る。したがって、あるデータベースレコードを更新するかまたは伝送するために複数の通信を必要とする代わりに、すべてのレコードを１つの通信で伝送し得る。本発明の一実施形態において、１つのデータオペレーションに影響を与えるために１つの往復通信のみを用いることによって、階層間通信の数をさらに制限する。例えば、クライアントシステムがユーザの要求を満たすためにサーバからデータを必要とする場合、上記要求は適切なサーバに伝えられて、上記サーバは、すべての要求されたデータ（または、上記クライアントがキャッシュ内に格納したり、または一度にユーザに表示し得るできるだけ多くのデータ）を任意の関連のイベントと共に探してリターン通信内にロードする。上記クライアントは、上記リターン通信を受信して、そのコンテンツを用いて、上記サーバ上で生じたオペレーション／イベントを再現して、上記要求を満たす。したがって、上記データオペレーションの効果は、階層間通信の効果または効率を高いレベルで維持している場合であっても、上記サーバおよびクライアントの両方に均一に適用される。
【００１３】
イベントマネジャーは、１つ以上の階層（例えば、中間階層サーバおよび／またはクライアント）内で動作して、上記ホストシステム上で生じるイベント（例えば、データ、オペレーション、例外）を取り込み、認識し、および別の階層に報告する。したがって、データオペレーションがある階層内のシステムに影響を与える場合、その効果は取り込まれて、別の階層に転送されて、これにより、協働システムが同じ効果または結果を再現または適用し得る。
【００１４】
ロバスト性の高い（例えば、高いレベルのリソースを有する）クライアントの必要をなくすには、サーバ上で実現される方法をライトウェイトプロキシによってクライアント上に表し得る。本発明の現在の実施形態の効率的な通信スキームを用いて、ライトウェイトプロキシは上記サーバ上の対応する方法をコールし得る。結果、上記サーバ上で動作する上記イベントマネジャーは、上記方法を実現する上記結果を取り込んで、上記コールのすべての効果を１つの通信で上記クライアントに報告する。上記通信は、上記クライアント上で受信および「再生」または再現される。
【００１５】
（詳細な説明）
以下の説明を提示して、当業者に本発明を作製および使用することを可能にする。以下の説明は、本発明および本発明の用件の特定の用途のコンテキストにおいて提供する。開示する実施形態に対する種々の改変は当業者に容易に理解され、そして本明細書で規定する概括的な原理は、本発明の意図および範囲から逸脱せずに他の実施形態および用途に適用され得る。したがって、本発明は、示す実施形態に限定されることを意図せず、本明細書に開示する原理および特徴と一致する最も広い範囲によることが意図される。
【００１６】
本発明の現在の実施形態が例示するように実行されるプログラム環境は、汎用コンピュータ、または手持ち式コンピュータなどの特殊目的のデバイスを組み込む。このようなデバイス（例えば、プロセッサ、メモリ、データ記憶装置、ディスプレイ）の詳細は周知であり、説明を明瞭にするために省略する。
【００１７】
本発明の技術を種々の技術を用いて実現し得ることも理解されるべきである。例えば、本明細書に説明する方法を、コンピュータシステム上で実行するソフトウェア内で実現してもよいし、マイクロプロセッサの組み合わせ、または他の特別に設計された特定用途集積回路、プログラム可能論理デバイス、またはこれらの組み合わせのいずれかを用いてハードウェア上で実現してもよい。特に、本明細書において説明する方法を、例えば、搬送波、ディスクドライブまたはコンピュータ読み出し可能媒体などの記憶媒体上に常駐する一連のコンピュータ上で実行可能な命令によって実現し得る。搬送波の例示的な形態は、ローカルネットワーク、またはインターネットなどの一般にアクセス可能なネットワークにわたってデジタルデータストリームを伝える、電気信号、電磁信号または光信号の形態を取り得る。
【００１８】
本発明の一実施形態は、Ｊａｖａ（Ｒ）フレームワーク用のＯｒａｃｌｅ　Ｃｏｒｐｏｒａｔｉｏｎのビジネスコンポーネントに用いる場合に特に適している。特に、データアクセスアプリケーションを、Ｏｒａｃｌｅ　ＣｏｒｐｏｒａｔｉｏｎのＪＤｅｖｅｌｏｐｅｒがホストするＪａｖａ（Ｒ）用のビジネスコンポーネントの設計時間モジュールを用いて設計および開発し得る。ＪＤｅｖｅｌｏｐｅｒは、相互通信的なＪａｖａ（Ｒ）開発環境であり、これは、開発者がＪａｖａ（Ｒ）アプリケーションを迅速に、かつ、相互通信的に開発することを可能にする。あるいは、当業者に明らかであるように、他のプログラミングツールまたはＩＤＥ（相互通信開発環境）をＪＤｅｖｅｌｏｐｅｒの代わりに用いてもよい。次いで、この結果得られるデータアクセスアプリケーションを、Ｊａｖａ（Ｒ）のビジネスコンポーネントのランタイムモジュールを含む演算環境において動作し得る。
【００１９】
以下に説明する本発明の実施形態において、プログラミングオブジェクト、コントロールおよび他のツールを提供して、データベース管理システムとインターフェースを取り、ユーザ用のデータにアクセスし、ユーザ用のデータを操作および表示する。したがって、本発明のこのような一実施形態を用いると、データアクセスアプリケーションを開発しおよび／または実質的にあらゆる種類のコンピュータシステム（例えば、デスクトップ、ワークステーション、「シン」クライアント、サーバ）上で動作することが可能になる。以下に説明するような演算環境において、データアクセスアプリケーションは、階層間のデータの均一性（例えば、データ状態および演算イベントの均一性）を促進する。本発明の実施形態においてアプリケーション開発者に提供されたＡＰＩ（アプリケーションプログラミングインターフェース）を、Ｊａｖａ（Ｒ）などのオブジェクト指向プログラミング言語を用いて構築および実現し得る。
【００２０】
（導入）
データベースアプリケーションおよびデータにアクセスする他のアプリケーションは、中央集権型（ｃｅｎｔｒａｌｉｚｅｄ）システム（例えば、メインフレームおよびダムターミナル）から今日のクライアント／サーバの２階層および３階層の演算環境に進化してきた。例えば、クライアント／サーバのアーキテクチャにおいて、クライアントコンピュータおよびサーバコンピュータの両方は、データを格納および／または操作するだけに十分なリソースを所有し得る。中央集権型システムにおいて用いられる実質的にすべてのデータアクセスアプリケーションは、クライアント／サーバまたは３階層の環境において機能する際に大規模な改変を必要とした。
【００２１】
２階層環境はデータアクセスアプリケーションにおいて依然一般的であるが、多くの組織は３階層環境を採用している。典型的な２階層環境において、ユーザアプリケーションは、コンピュータシステム上で起動し、そして別個のデータベースサーバと相互通信して格納されたデータを取り出し、操作しあるいはアクセスする。ユーザアプリケーションはこのアーキテクチャ内のほとんどのビジネス論理を含む。しかし、例示の３階層環境において、ユーザがユーザのクライアントシステム（例えば、ラップトップ、ノートブックまたはデスクトップコンピュータ）上でデータ操作を開始し得るが、ここで、中間階層サーバがクライアントとデータベースサーバとの間に置かれる。中間階層サーバは、例えば、データベースサーバ上に格納されたデータへのアクセスを管理するように設計されているデータアクセスアプリケーションを動作するアプリケーションサーバを含み得る。したがって、３階層システムにおいて、ほとんどのビジネス論理は、複数のクライアントに利用可能になる３階層サーバに移動される。利点の中でも、このアーキテクチャはデータセキュリティ、監査および会計責任を向上させる。
【００２２】
したがって、２階層環境と３階層環境との主な差異は、アプリケーションによって用いられるか呼び出されるほとんどのビジネス論理の場所であり得る。２階層システムにおいて、ビジネス論理の場所はクライアントコンピュータ上で動作するユーザプログラムである。３階層システムにおいて、ビジネス論理の場所は中間階層サーバである。結果、例示的な２階層システムは、複雑なビジネス論理を実行する必要があるため、各クライアントコンピュータが比較的ロバスト性を有するか、またはリソースに富んでいることを必要とし得る。しかし、例示の３階層システムにおいて、ほとんどのビジネス論理を実行する負担は、中間階層サーバ上にかかり、中間階層サーバにおいて、この負担は複数のクライアントによって共有され得る。したがって、利益の中でも、３階層環境はシンクライアントにより適切であり得る。
【００２３】
中央集権型システムから２階層アーキテクチャ（すなわち、拡張的なソフトウェア改変）に移す際に遭遇し得る困難を回避するために、データアクセスアプリケーションが、変えることなく（例えば、再度のコンパイルを必要とせず）２階層環境または３階層環境のいずれかで動作し得るように、データアクセスアプリケーションを開発することが有利である。多階層環境においてデータアクセスアプリケーションを開発および実現する１つの例示的なフレームワークを、以下のセクションにおいて、種々のコンポーネントを実現する方法と共に開示する。
【００２４】
開示したフレームワークまたは同様のフレームワークを用いることによって、データアクセスアプリケーションを、２階層環境または３階層環境のいずれかにおいて用いて、次いで２階層環境または３階層環境のいずれかにおいて動作するように開発し得る。例示するように、アプリケーションが実行される時に適切なパラメータを単に指定することによって、アプリケーションはいずれかの環境において動作し得る。例えば、アプリケーションが２階層モードにおいて起動する場合に、１つのスイッチまたはパラメータを指定し得、そして、３階層モードの場合に、別のスイッチまたはパラメータアプリケーションを指定し得る。
【００２５】
以下に説明するフレームワークにおいて、ユーザは、リソースがほとんどないまたは限られている「シン」クライアントであり得るクライアントコンピュータシステムを動作し得る。しかし、ユーザのコンピュータシステムはシンクライアントである必要はなく、本明細書において説明する本発明の１つより多い実施形態はほとんどまたはまったく改変せずにロバスト性の高いクライアントシステムと共に動作する。
【００２６】
１つ以上のデータベースまたは他のデータの集まりは、３階層環境において、中間階層サーバによってクライアントシステムから離されているデータベースサーバ上に維持されている。中間階層サーバはアプリケーションサーバプログラムを動作して、データへのアクセスを管理する。例えば、ある形態において、３階層環境は、デスクトップ、ノートブックまたは他の演算デバイスを動作して、インターネットなどのネットワークを介して中間階層サーバと通信するユーザを含み得る。ファイアウォール、プロキシサーバ、ゲートウェイまたは他のセキュリティまたはアクセスシステムを、クライアントと中間階層サーバとの間に置き得る。
【００２７】
通常、本発明の現在の実施形態における３階層環境におけるクライアントコンピュータシステムは、中間階層サーバよりリソースが少なく（例えば、プロセッサの速度が遅い、メモリが少ない、記憶容量が少ない）、中間階層サーバを介してクライアントコンピュータシステムはデータにアクセスする。クライアントコンピュータと中間階層サーバとの間の通信リンクは、データおよび他の情報がこれらの２階層間で交換される、新しく効率的な方法（以下に説明する）のせいで、比較的遅い（例えば、１．５４４Ｍｂｐｓより遅い）場合がある。しかし、当業者であれば理解するように、より高速なリンクを用いて、フレームワークのオペレーションおよび効率をさらに向上させ得る。
【００２８】
図１は、データアクセスアプリケーションが本発明の現在の実施形態によって、開発され得るおよび／または動作する例示的な３階層環境を示す。環境１００は、クライアント１０２ａ、１０２ｂおよび１０２ｃ、中間階層サーバ１０４ならびにデータベースサーバ１０６を含む。種々の通信リンク（例えば、専用通信リンク、ダイアルアップ通信リンク）を用いて、データベースサーバ１０６を中間階層サーバ１０４に接続し得、そして中間階層サーバ１０４をクライアント１０２ａ、１０２ｂ、１０２ｃに接続し得る。例示するように、クライアント１０２ｂ、１０２ｃは、ネットワーク１１２を用いて中間階層サーバ１０４と通信し、ネットワーク１１２は、個人ネットワークまたは一般のネットワーク（例えば、インターネット）であり得る。
【００２９】
以下は新しいデータアクセスフレームワークの１つ以上の実施形態に組み込み得るいくつかの主なコンポーネントである。これらは、クライアントキャッシュ（クライアントシステム上に維持されている）、イベントマネジャー（例えば、中間階層のサーバ上で動作している）、ライトウェイトプロキシ（ｌｉｇｈｔｗｅｉｇｈｔ　ｐｒｏｘｙ）（クライアントコンピュータ上で動作している）、およびＪａｖａ（Ｒ）などのオブジェクト指向プログラミング言語の使用である。本発明のこれらの局面を以下のセクションにおいてさらに説明する。
【００３０】
さらに、クライアントシステムと中間階層サーバとの間で新しい通信の方法を実現する。特に、以下のセクションに説明するように、これらの２階層間における通信を収集するかまたは総合して、通信（例えば、ネットワーク）の性能レベルを向上させる。通信の新しい形態は、ある階層が別の階層にデータ交換、例外および他のイベントを通知することを可能にすることによって、階層間のデータおよびプログラミングの均一性を向上させる。次いで、これらは、他の階層上で実現され得るか、または他の階層上で実施され得る。要するに、データ操作が実行される場合はいつでも、オペレーションの副作用または結果、およびオペレーションによってトリガーされるあらゆるイベントが取り込まれて、１つの通信を介して他の階層に伝達される。次いで、これらは、伝達された階層において、再現または「再生」され得る。実質的にすべてのデータおよび／またはデータオペレーションまたは他のイベントに関する他の情報が１つの通信で送信されるため、伝送する必要がある通信はより少ない。これにより、階層間通信の効率が向上する。
【００３１】
クライアントシステム上で動作するユーザアプリケーションによって要求されたデータオペレーションに関して、データ更新、関連したイベントなどをクライアントシステム上に蓄積して、次いで、中間階層サーバへの１つの通信内にパッケージ化する。同様に、任意の要求されたデータ、中間階層サーバ上で遭遇する任意の例外、任意の関連したイベントおよびデータ変更などを中間階層サーバ上に収集して、１つの通信でクライアントに返し得る。
【００３２】
特に、ユーザがデータオペレーションまたはデータ要求を開始すると、オペレーションが中間階層サーバ上にまず実行され得る。この場合、中間階層サーバはオペレーション（そして、恐らく、他の要求またはオペレーション）を含むクライアントシステムからメッセージを受信する。次いで、中間階層サーバは必要な処理を実行し（例えば、データベースサーバにアクセスし、１つ以上のデータベースの行またはレコードを探し出す）、そしてすべての結果（例えば、データ、例外、他のイベント）を１つの通信でクライアントに返す。クライアントが通信を受信すると、クライアントは返答して、または通信のコンテンツを付与して、ユーザのデータを更新し、同じイベントを発射し（ｆｉｒｅ）（すなわち、実行し）、同じ例外を適用するなどを行い得る。当業者であれば、このスキームが、１つのフィールド、属性またはデータ値が一度に取り出され、これはあるデータオペレーションを実施するために多くの通信を必要とし、そしてこの結果、ネットワーク性能が下がっている既存の方法よりはるかに効率的であることを理解する。
【００３３】
しかし、ユーザオペレーションをクライアントシステム上でまず実行し得る。この場合、中間階層は、オペレーションを識別するメッセージおよび／またはこのオペレーションの結果を、クライアント上に適用された場合に受信する。次いで、中間階層は、オペレーションを実行し得るか、またはこの結果を単に適用し得る。しかし、例示するように、中間階層サーバは、中間階層サーバ（これはクライアント上でトリガーされない）上に常駐するプログラミング論理内に指定されている他のイベントをトリガーし得るため、このオペレーションを実行する。次いで、オペレーションの結果（例えば、副作用、他のイベント）は通常通り、クライアントに返される。
【００３４】
例示するように、クライアントキャッシュを複数のデータオブジェクトまたはアイテムを格納するようにクライアントシステム上で構成する。特に、ユーザの指定されたオペレーション、そして恐らく、限られた数の引き続くオペレーションの実行を促進するだけに十分なデータを格納するようにキャッシュを設計するが、これはキャッシュが中間階層サーバ上に格納され得るように、大量のセットのデータを再現することを意味しない。例示するように、クライアントキャッシュは、中間階層サーバから受信された通信に応答して、データアクセスフレームワークによって満たされる。
【００３５】
本発明の一実施形態において、ユーザのデータのオペレーション／要求が受信および適用された場合に、中間階層において生じるイベント、例外、警告、メッセージを傍受するようにイベントマネジャーを構成し得る。特に、イベントマネジャーが適切なオペレーションを行ったり、または中間階層サーバ上で生じた同じ副作用を適用し得るように、イベントマネジャーは、これらの例外およびメッセージをクライアントシステムに伝達する。
【００３６】
したがって、イベントマネジャーは、単なるデータ状態ではなく個々のイベントが多階層演算環境の階層間で伝播されることを保証することを支援する。特に、以前の環境において、データ値が階層間で伝達され得るが、データ値と関連付けられた環境（例えば、イベント）ではない。さらに、上述のイベントマネジャーは、正しいタイミングまたは例外などのイベントの連続を実施し得る。したがって、中間階層イベントマネジャーは、イベントが中間階層上で起こったちょうどその順番で、データを備えたクライアントコンピュータにイベントを伝播し得る。次いで、クライアントは正しい順序でイベントを再生し得る。クライアント上のユーザインターフェースコントロールは、例えば、ディスプレイを更新したり、またはアイテムのリストをスクロールするために必要なデータ用に別の階層上に設けられたソースに依存することが多い。イベントの要素が正しい順序でユーザインターフェースコントロールに提供されることを保証することが重要である。
【００３７】
ライトウェイトプロキシは、クライアントシステム上で動作し、そしてクライアントが中間階層サーバ上の対応するオブジェクトを呼び出したり、または操作するオブジェクトを表す。例えば、従業員オブジェクト（例えば、中間階層上またはデータベース内に常駐しているオブジェクト）の場合、従業員オブジェクトのライトウェイトプロキシはクライアントシステム上に常駐し得る。ライトウェイトプロキシにより、ユーザが２階層環境または３階層環境のいずれで動作するかに関わらず、ユーザが従業員オブジェクト上で均一な様態で動作することが可能になる。特に、ユーザが、従業員を昇給させるために、従業員オブジェクトの「昇給」方法を呼び出すと、プロキシは、中間階層上の対応する「昇給」方法へのコールをルート化し得、次いで、「昇給」方法は実際の実現を実行する。「昇給」のコールに関連付けられた結果またはイベントは、クライアントに戻されて、クライアント上で再現される。
【００３８】
以前の多階層演算環境において、プロキシを用いて階層にわたってオブジェクトにアクセスし得るが、マーシャル方法、すなわち交換方法のパラメータによってのみアクセスし得る。上述の「昇給」の例において、クライアントコンピュータから中間階層上の「昇給」オブジェクトへのコールは、１つのパラメータとして昇給率または昇給額を含み得る。以前の環境は、このパラメータを供給して、リターン値（例えば、新しい給料）のみもって応答する。しかし、本発明の一実施形態において、すべてのデータ変更、イベントおよび例外は、クライアントシステム上ですべて再生され得るようにリターン値をもって送信される。したがって、クライアント上のライトウェイトプロキシによって呼び出される中間階層上の「昇給」方法が他のプログラミング論理に実行させる（例えば、給料支払い簿を更新させる）場合、これらの効果もクライアントに伝達される。
【００３９】
本発明の現在の実施形態において、データにアクセスし操作しながら、多階層演算環境の階層間における均一性を促進する、アプリケーション開発および／またはオペレーションフレームワークを提供する。特に、すべてのデータオペレーションおよびデータ上のオペレーションに関連付けられたイベント（例えば、データオペレーションの「副作用」）は、クライアントコンピュータシステムとサーバ（これを介してデータがアクセスされる）との間で同期を取られるか、または再現される。したがって、多階層間で維持される同一のデータ状態だけでなく、データが変えられる様態も各階層に公知である。これは、「何」（すなわち、データ）が変わったかという問題のみに取り組んだ以前の多階層システムとはかなり異なる。本発明の現在の実施形態において、多階層システムを提供して、階層間で、「いかに」そのデータが変わったかを調整する。
【００４０】
図１Ｂは、本発明の一実施形態が適用され得る例示的な２階層環境のブロック図である。例示の２階層環境において、中間階層１０４はクライアントおよび中間階層サーバとして機能する。したがって、中間階層１０４は、ユーザプログラム２０４ａ、中間階層オブジェクト（例えば、プログラミングオブジェクト）２０４ｂおよび中間階層サーバキャッシュ２０４ｃを含む。ユーザプログラムは、中間階層オブジェクトを介してデータサーバ１０６上に格納されたデータにアクセスする。ユーザプログラム２０４ａは、ユーザのプログラミング論理を含み、中間階層オブジェクト２０４ｂと協働する。特に、ユーザプログラムは中間階層オブジェクトのコールを開始し得る。中間階層オブジェクトが呼び出された場合、中間階層オブジェクトは、種々のデータに変更させ、そしてイベントを発射し（すなわち、実行し）、そして、中間階層オブジェクトがインストールされたプログラミング論理によって決定される他の副作用を生じさせ得る。
【００４１】
中間階層プログラミングオブジェクトの実行から生じるデータ変更（例えば、データベースサーバ１０６上に格納されるデータへの変更）は中間階層サーバキャッシュ２０４ｃ内に格納され、発射されたイベントはユーザプログラムに返される。したがって、図１Ｂに示す２階層環境において、ユーザプログラムはプロキシを用いずデータアクセスフレームワーク（例えば、中間階層オブジェクト２０４ｂ）内のオブジェクトに直接アクセスし得、そして別個のクライアントキャッシュを必要としない。プログラミングのコールおよびコールのリターンは、３階層環境のように、正式な階層間通信にパッケージ化される必要はない。
【００４２】
図１Ｃは、本発明の一実施形態による、図１Ａの環境１００のような例示の３階層環境のさらなる詳細を示すブロック図である。図１Ｃにおいて、図１Ａのクライアント１０２ａなどの例示のクライアントは、ユーザプログラム３０２ａ、１つ以上のライトウェイトプロキシ３０２ｂ、コーディネータ３０２ｃおよびクライアントキャッシュ３０２ｄを含む。この実施形態における中間階層サーバ１０４は、イベントマネジャー３０４ａ、中間階層オブジェクト３０４ｂ（これを介してデータベースサーバ１０６上のデータがアクセスされる）、および中間階層サーバキャッシュ３０４ｃを含む。
【００４３】
本発明の一実施形態の１つの利点は、図１Ｃの３階層環境のユーザプログラム３０２ａが図１Ｂの２階層環境のユーザプログラム２０４ａと実質的に同じである点である。ユーザプログラムが実行されると、ユーザはスイッチまたはパラメータを指定して、プログラムが２階層モードまたは３階層モードのいずれで起動するかを示し得る。次いで、適切なプログラムモジュールがロードされ、そしてプログラムが指定されたモードで起動する。いずれかのオペレーションモードにおいて、ユーザプログラムを開発して、インターフェース（例えば、Ｊａｖａ（Ｒ）インターフェース）を用いて中間階層オブジェクトにアクセスする。
【００４４】
図１Ｃの実施形態において、ユーザプログラム３０２ａが用いるインターフェースは、方法の仕様を提供するが実現は提供しない。したがって、ユーザプログラムは、中間階層オブジェクトの知識に対して直接アクセスを有さず、または中間階層オブジェクトの知識を有さない。代わりに、ライトウェイトプロキシを提供する。ライトウェイトプロキシは、特定の中間階層オブジェクトのコールを中間階層（ここで、対応する方法がコールされる）にルーチングする。
【００４５】
ユーザプログラム３０２ａが中間階層オブジェクト３０４ｂのうちの１つを表すライトウェイトプロキシ３０２ｂをコールすると、コールはコーディネータ３０２ｃ（これは、データアクセスフレームワークを表す）に伝達される。以下のセクションに説明するように、コーディネータ３０２ｃは、クライアントから、１つ以上のオブジェクトコール、データオペレーション、結果、イベントなどを集めて、これらを１つの効率的なメッセージにして、中間階層サーバ１０４のイベントマネジャー３０４ａに転送し得る。例えば、クライアントキャッシュ３０２ｄは、中間階層サーバにまだ送信されていない、データ変更、オペレーションおよび／または他の影響または結果を保持している場合がある。コーディネータは、これらすべてをメッセージにパッケージ化する。ＣＯＲＢＡ（共通オブジェクトリクエストブローカリングアーキテクチャ）、ＥＪＢ（エンタープライズＪａｖａ（Ｒ）ビーンズ）または所定の他の同様のシステムを用いて、コーディネータ３０２ｃとイベントマネジャー３０４ａとの間で通信を交換し得る。
【００４６】
イベントマネジャー３０４ａは、中間階層サーバ３０４ｂによって表されるプログラミング論理にコールを伝達し、この時に適切な方法が実行される。プログラミング論理のコンフィギュレーションに依存して、第１のコールの結果として、他のオブジェクトを呼び出すかまたはコールし得る。コールからのすべての最終結果、副作用、イベント、データ変更など（現在の説明においては一括して「結果」と呼ぶ）をイベントマネジャーによって取り込む。
【００４７】
イベントマネジャー３０４ａが、クライアントに返信される１つの統合された通信内に含まれる結果を記録または格納し、これにより、イベントマネジャー３０４ａは結果を適用し、そのキャッシュを更新し、同じイベントを発射することなどができ得る。したがって、イベントマネジャーがすべての結果を集めた後、イベントマネジャーは１つの通信内にこれらを納め、通信をクライアントに伝送する。例示するように、中間階層サーバ上で起こった順序で、結果をクライアントが読んで適用し得るように結果を構成する。
【００４８】
コーディネータ３０２ｃが中間階層サーバから通信を受信すると、コーディネータ３０２ｃはそのコンポーネント部分を再生する。特に、データ変更を用いてクライアントキャッシュ３０２ｄを更新しながら、ユーザプログラム３０２ａに対してイベントを発射するか、ユーザプログラム３０２ａにイベントを返す。
【００４９】
３階層環境において用いられるデータアクセスフレームワークの種々のコンポーネントのさらなる詳細をここで以下のセクションにおいて説明する。
【００５０】
（クライアントキャッシュ）
本発明の現在の実施形態において、クライアントシステムは１つ以上のキャッシュ（シンクライアント用に幾分小さくあり得る）を用いて、性能を向上させながら、種々のデータオペレーションを実行する。クライアントキャッシュは、中間階層サーバ上に設けられたオブジェクトキャッシュと比較され得る。ちょうど中間階層サーバのオブジェクトキャッシュが中間階層上でのデータオペレーションの効率を向上させるように、クライアントキャッシュはクライアントコンピュータに対して同様の利益を提供する。したがって、クライアントキャッシュのコンテンツは中間階層サーバのキャッシュのコンテンツのサブセットであり得る。しかし、オブジェクトキャッシュは通常、クライアントキャッシュよりずいぶん大きい。例えば、中間階層サーバのオブジェクトキャッシュが数千のデータオブジェクト（例えば、データベースのレコードまたは行）を格納する一方、中間階層サーバに接続されているクライアントシステムのクライアントキャッシュは、いくつのオブジェクトを、アプリケーションはユーザに一度に表示するように設計されているか、クライアントのオブジェクトおよびリソースのサイズに依存して、１００より少ないデータオブジェクトを格納し得る。クライアントキャッシュのサイズを制限することによって、キャッシュを管理するのに必要なリソースがより少なくなる。データアクセスフレームワークの現在の実施形態の一局面は、性能を犠牲にすることなくシンクライアントと共に用いるのに適している。
【００５１】
クライアントシステムは、クライアントキャッシュのコンテンツを管理して、ユーザのデータオペレーションに関連するデータでコンテンツを満たそうとする。したがって、クライアントシステムは、中間階層サーバがクライアントに適切なデータ量を提供して、これにより、クライアントがさらなるデータを要求する頻度を減らせ得るように、中間階層サーバにキャッシュのサイズまたは容量を通知し得る。または、ユーザによって要求された特定のデータオペレーションが特定の量のデータ（例えば、データベースの次のＮのレコードまたは行）のみを必要とする場合、クライアントはそのデータ要求（例えば、中間階層サーバに対する要求）を適切に構築し得る。インテリジェンスをクライアント（または、中間階層サーバ）によって付与して、ユーザが実行する次のデータオペレーションを準備するために、中間階層サーバからどのデータオブジェクトを事前に提供するべきかを予測または推測し得る。任意の適切なキャッシュスキーム（例えば、最近一番用いられていないスキーム）を用いて、クライアントキャッシュを管理し、そして、既存のキャッシュエントリを新しいデータで換え得る。
【００５２】
当業者であれば理解するように、ユーザまたはユーザアプリケーションによって要求されたデータオペレーションをクライアント上（例えば、クライアントキャッシュ内）に格納されたデータから満たし得る場合、ユーザアプリケーションの性能が高められる。この場合、データオペレーションはローカル（例えば、クライアント上で）で実行される。しかし、ちょうど中間階層上で起こるイベントがクライアント上で再現または再生されるように、クライアント上のデータオペレーションおよびその効果（単数または複数）は、オペレーションが中間階層サーバに同様に適用され得るように中間階層サーバに転送される。クライアント上でまず実行される所定の簡単なオペレーションを、中間階層サーバにこれを送信する前に集め得る。他のより複雑なオペレーションを、クライアント上での実行の直後に中間階層に送信し得る。
【００５３】
他のデータオペレーションは、（例えば、クライアントキャッシュまたはオペレーション内にない必要なデータが実行されるように中間階層に行くように構成されているため）クライアント上ですぐには満足のいくものとはならない。この場合、クライアントはオペレーションを中間階層に転送し、中間階層はオペレーションを実行し、この効果を取り込み、そしてこれをクライアントに返す。次いで、クライアントは、オペレーションを実行し、その効果を適用して、ユーザまたはユーザアプリケーションに適切に応答し得る。ライトウェイトプロキシの使用は、クライアントキャッシュを最新の状態に保つことを支援する。
【００５４】
（クライアント／中間階層サーバ通信）
簡単に上述したように、本発明の現在の実施形態において（３階層環境における）クライアントと中間階層サーバとの間で交換されるデータおよび他の情報を収集するかまたは総合して、通信（例えば、ネットワーク）の性能を上げる。
【００５５】
以前の多階層データアクセスアプリケーションにおいて、階層間通信の性能は非常に非効率的であることが多かった。特に、オブジェクトのコールが階層にわたって試みられた場合、または、ある階層が第１の階層上で起こっているイベントを別の階層に通知しようとした場合に、階層間で交換されたデータおよび情報の細分性またはレベルは非常に低くあり得た。この結果、データベーステーブルを更新したりまたはデータベーステーブルを取り出すなどの１つのオペレーションを実行または伝播するために多くの通信が必要であった。
【００５６】
したがって、データアクセスアプリケーションの開発者は、良好なネットワーク／通信性能または階層間の良好なデータの均一性のいずれかを選択する必要があった。例えば、開発者が階層間でのデータ状態の均一性を保証することを所望する場合、階層間通信は必要な量の情報を交換するために「常に通信中」のままである必要があった。これにより、ネットワーク性能が下がり、データオペレーションが遅くなり得る。対照的に、ネットワーク性能を向上させるために、開発者は、クライアントシステムとデータサーバとの間で高い均一性を維持することができなかった。
【００５７】
しかし、通信が、新しいデータアクセスフレームワークの現在の実施形態におけるクライアントと中間階層サーバとの間で構築されている様態により、ネットワーク性能を犠牲にせずに、階層間で非常に良好な均一性が可能になる。
【００５８】
特に、低レベルのデータオブジェクト（例えば、データベースの１レコード内の１つのフィールドの値）を１つのクライアント／中間階層通信の対象にする代わりに、この実施形態における階層間通信はより高くに焦点を置く。一実施形態において、例えば、データベースの行（または、行内の複数の属性）は、１つの通信で伝送される最も低いレベルのオブジェクトであり得る。さらに、そして以下のサブセクションに説明するように、あるデータの更新が別のイベントをトリガーして他のデータを更新またはリフレッシュする場合（例えば、マスター／詳細の構成で）、すべてのデータ変更およびイベントは１つの通信で報告され得る。イベント、例外およびデータをインターリーブあるいは組み合わせて１つの階層間通信にすると、階層間にわたるアプリケーションプログラムの均一性を維持する能力が異常に促進される。
【００５９】
例示するように、クライアントキャッシュ内のアイテムの細分性のレベルは、クライアント／中間階層通信内に含まれたオブジェクトの細分性と合致する。したがって、例えば、データベースの個々の行は階層間で伝達され、各行がアプリケーションを処理する順序のうちの１つの順序に対応する場合、ユーザが一度に即時アクセスを有する所定の数の順序（例えば、２０〜５０）を格納するようにクライアントキャッシュを構成し得る。
【００６０】
したがって、以前のデータアクセスアプリケーションにあるように、データベースのレコード／行内の各フィールド／属性の別個のデータ要求を必要とする代わりに、データベースのすべての行ははるかに効率的な様態で取り出され得る。例示するように、第１のデータ要求（例えば、１つ以上のデータオブジェクト）がクライアントシステムから中間階層サーバに伝達されると、中間階層サーバはクライアントキャッシュのサイズを知る。この値は、クライアントの要求内に含まれ得るか、別個の通信を介して多階層サーバに提供され得る。次いで、中間階層サーバは、要求されたデータ（例えば、サーバのキャッシュまたはデータベースサーバから）および十分なさらなるデータ（例えば、要求されたオブジェクトの後の次のＮのデータオブジェクト）を取り出して、クライアントキャッシュを満たす。以下により詳細に説明するように、要求されたデータは１つの通信内に（例えば、Ｊａｖａ（Ｒ）シリアル化を用いて）パックされて、クライアントに転送される。クライアントは、通信を受信し、コンテンツをアンパックし、クライアントキャッシュを満たして、アプリケーションに返す。
【００６１】
あるいは、データアプリケーションを特定数の行、属性または他のデータオブジェクトと協働するように構成すると、中間階層は、アプリケーションが用い得るちょうどのオブジェクト数を取り出して、クライアントに提供し得る。
【００６２】
（例えば、各更新を個々に送信する代わりに）すべての集まりを送信する前に、複数のデータの更新をクライアント内で蓄積することを可能にすることによって、クライアントから中間階層サーバへの通信をさらに向上させる。規則的な間隔で、または特定のイベントの際に更新を転送し得る。例示するように、更新は中間階層によって受信され、中間階層のオブジェクトキャッシュに適用されて、クライアントおよび中間階層サーバ上のデータの同期を取る。イベント、例外およびデータを両方の方向で階層にわたって伝播することによって、プログラミングおよびデータの均一性を促進する。
【００６３】
本発明の一実施形態において、クライアントに提出されたデータオペレーション（例えば、ユーザ、ユーザアプリケーション、形態から）は実行モードを割り当てられる。第１のモードすなわち優先モードは、オペレーションが中間階層に即、報告されることを示し得る。しかし、中間階層が（例えば、クライアントキャッシュ内にすでにあるデータと）関与せずにオペレーションが実行され得る場合、優先モードであっても、データは中間階層に報告される必要がない場合がある。しかし、あらゆるデータ変更は報告されなければならない。もちろん、要求されたオペレーションが中間階層サーバ（例えば、優先オペレーション）の関与を必要とし、クライアント上で実行され得ない（例えば、必要なデータが利用不可能である）場合、オペレーションは実行されるために中間階層サーバに即伝達される。
【００６４】
第２の実行モードまたは遅延型実行モードにおいて、特定数のオペレーションが蓄積され、および／または優先モードのオペレーションが提出された後、オペレーションは、クライアント上に蓄積されて、中間階層サーバに転送され得る。例示するように、遅延型実行モードにおいて、オペレーションはローカルに（例えば、クライアントキャッシュ内のデータを用いて）実行され、可能な場合には、次いで、後に中間階層サーバに転送される。
【００６５】
本発明の１つの別の実施形態において、データアクセスフレームワークにより、フレームワーク内のコンポーネントおよびオブジェクトがイベントおよび他のオブジェクトへの興味を登録することが可能になる。したがって、中間階層サーバは、中間階層サーバが特定のデータオペレーション（例えば、従業員の給料の変更）に興味を有することをクライアントに指定し得る。このような場合、このようなオペレーションを中間階層サーバに即、転送するように、恐らく、指定し得ない場合にオペレーションに割り当てられ得る任意のモードとは関係なく、クライアントを構成し得る。中間階層サーバは、例えば、特定のオペレーションに実行される、所定の指定すなわちカスタム論理を維持し得る。有利に、本発明のこの実施形態において、どの階層であろうともオペレーションを実現するためにより複雑な「副作用」を有する階層は、オペレーションおよびその効果を他の階層に通信する前にまずオペレーションを受信および実行する。
【００６６】
（マスター／詳細の調整）
本発明の一実施形態において、クライアントと中間階層サーバとの間の通信を制限する効率的なスキームの一例として、マスター／詳細のデータ構成が処理される様態をここに説明する。当業者であれば理解するように、データベースおよびデータアクセスアプリケーションは、関連データを操作するためにマスター／詳細の構成を用いることが多い。例えば、組織の雇用または人材のデータベースにおいて、マスター／詳細の関係を用いて、部署（マスター）と部署内の従業員（詳細）に関する情報を表示し得る。または具体的には、マスター／詳細の関係により、詳細のアイテム（例えば、この部署内の従業員）を見たりまたはこれにアクセスし得るように、マスターアイテム（例えば、部署）の選択することが可能になる。
【００６７】
ユーザインターフェースオブジェクト（例えば、テキストボックス、グリッド）は、各マスターに関連付けられ得るか、または詳細なコンポーネントに関連付けられ得る。例示するように、テキストボックスにより、ユーザが、部署名または部署数などの特定数のマスターデータを入力することが可能になる。指定されたマスター要素を受信すると、指定された部署内の従業員に関するデータが取り出され得て、（例えば、テーブル内に）表示され得る。さらに、ユーザは別のユーザインターフェースオブジェクト（例えば、「次」または「→」またはボタン）を選択して、次のマスターアイテム（例えば、部署）を選択し得る。次いで、従業員の詳細が更新またはリフレッシュされるなどである。
【００６８】
上述した３階層環境などの多階層を用いると、マスター／詳細の構成の調整を、クライアントまたは中間階層サーバのいずれかで実行し得る。しかし、必要なデータを格納および処理するだけに十分なリソースが必要であるため、本発明の一実施形態において、シンクライアント（例えば、リソースが限られているシステム）が環境内で動作し得るようにマスター／詳細の構成の調整を中間階層サーバ上で実行する。具体的には、クライアントシステムにおけるマスター／詳細の構成を実現または管理するには、クライアントシステムは、さらなるリソース、プログラミング論理、データなどを必要とし得る。
【００６９】
したがって、この実施形態において、クライアント上のユーザインターフェースオブジェクトは、マスター／詳細のデータを選択または表示するコンポーネント（例えば、テキストボックス、グリッド）を含み得る。これらのコンポーネントは、クライアントキャッシュにフックされ、そしてキャッシュが要求されたデータ（例えば、次の部署内の従業員）で満たされた場合、自動的にリフレッシュされ得る。しかし、マスター／詳細の関係は、実際には中間階層によって管理される。したがって、すべてのマスター／詳細のオペレーションは、実行されるように中間階層サーバに転送される。次いで、オペレーションおよびその効果（例えば、新しく選択された部署の新しいセットの従業員）はクライアントに返されて、クライアント上で実現される。
【００７０】
特に、ユーザが特定の部署を識別したり、または次の部署を要求する場合、クライアントは中間階層サーバへの通信をコールするかまたは送信する。中間階層サーバは、要求された部署データを探し出す。中間階層上で動作する（および以下のセクションで説明する）イベントマネジャーは、（マスター／詳細の構成のために）新しいセットの従業員が必要であることを認識し、中間階層サーバがクライアントのコールに応答した場合に、必要数の従業員のレコードまたは行が返されることを保証する。クライアントに送信された従業員のレコードの数は、クライアントキャッシュの範囲サイズ、クライアント上のユーザインターフェースオブジェクト内に表示され得るレコード数、データアクセスアプリケーションが一度に操作するように構成されているレコード数などに依存し得る。
【００７１】
図２は、クライアントシステム上のマスター／詳細のデータを更新するために用いられ得る（片道）往復通信を示す。当業者であれば理解するように、以前のデータアクセスアプリケーションは通常、同じオペレーションを実行するためにさらに多くの通信を必要とした。
【００７２】
図２において、クライアント１０２ｂから中間階層サーバ１０４までの通信２０２は、ユーザによって要求されたデータオペレーションを識別する。この場合、ユーザは「次」の部署の情報を要求している。特に、クライアントは、恐らく、名前および／または番号によって識別されており、そして恐らく、いくつかの他の情報（例えば、部署内の従業員数）を備えている部署のリストを維持し得る。
【００７３】
中間階層サーバ１０４は要求されたオペレーションを受信する。中間階層上のマスター（例えば、部署）オブジェクトは、指定された部署に設定されており、これにより、自動的に、部署の従業員データが取り出され（例えば、中間階層のキャッシュまたはデータベースサーバから）、そして中間階層サーバ上で更新されるようになる。
【００７４】
次いで、クライアント１０２ｂがデータの従業員グリッドを更新し得るように、従業員データをクライアント１０２ｂに返信する必要がある。本発明の例示の実施形態において、中間階層サーバ上の詳細な（例えば、従業員）オブジェクトは、イベントマネジャー（以下のセクションにさらに説明する）によってトラップまたは処理されるイベントを発射する。イベントマネジャーは、中間階層サーバ上の従業員オブジェクトが、クライアントが通知される必要があるマスター／詳細の関係で新しいセットの従業員を報告していることを認識する。したがって、イベントマネジャーは、クライアント上のマスター／詳細の更新を再現するために必要な他の情報で新しい部署の従業員データを組み立てる。クライアントに送信される従業員データの量は、クライアントのキャッシュ内に収まるデータ量（例えば、レコード数）によって決定され得る。
【００７５】
この例において、中間階層サーバ１０４からクライアント１０２ｂに返信される通信はいくつかのアイテムからなる。例示するように、通信のフォーマットはデータが更新または変更された順序、そして関連したイベントが中間階層サーバ上で起こった順序を反映する。したがって、通信２０４は、選択された、または「次」の部署のデータ（例えば、部署数、部署名、従業員数）に関する第１の部分２０４ａを含む。次の部署は、クライアントキャッシュ内にすでにあってもよいし、クライアントキャッシュ内になくてもよい。（例示の実施形態の場合のように）次の部署がクライアントキャッシュ内にすでにある場合、中間階層はこの事実を認識しており、一部には、２０４ａはクライアントを次の部署（例えば、従業員を１０人有する、エンジニアリングという名の部署２０）に行くように単に指示する。この例では、部署のレコードは、中間階層サーバ上で変更または影響を受けた最初のアイテムであるため、通信２０４の第１の部分である。
【００７６】
しかし、次の部署がクライアントキャッシュ内にない場合、部分２０４ａは必要な部署データを含む。クライアントがキャッシュ内に新しい部署の空間を作るように、中間階層サーバからの命令によって、部署のデータを部分２０４ａに先行させてもよい。命令は「スクロール開始」などであり得る。スクロール開始に続いて、命令はクライアントキャッシュ内に置かれる部署データ（例えば、「２０、エンジニアリング、１０人の従業員」であり得る。部署データに後続するものは、クライアントに部署イベントを発射して、クライアントキャッシュを更新するように伝える「スクロール終了」などの「スクロール開始」に対して相補的な命令である。
【００７７】
通信２０４の第２の部分２０４ｂは、中間階層サーバからクライアントに、要求されたデータ（例えば、従業員のレコード）用にそのキャッシュ内に空間を作る命令または指令を含む。第２の部分２０４ｂは、どのぐらいの空間がキャッシュ内に（例えば、エントリをクリア、消去または移動することによって）作られるべきかを指定し得る。例示の実施形態において用いられる命令は「リフレッシュ開始」である。
【００７８】
通信２０４の第３の部分２０４ｃは、クライアント１０２ｂ上の従業員オブジェクトを満たすまたは更新するために用いられる個々の従業員レコード（例えば、従業員数および従業員名からなる）を含む。最後に、通信の第４の部分２０４ｄは、これがそのリフレッシュオペレーションを完了し得ることをクライアントに通知する。したがって、第４の部分２０４ｄは、クライアントによって受信された場合に、クライアントにリフレッシュイベントを発射させる「リフレッシュ終了」などの命令を含み得る。
【００７９】
例示のマスター／詳細の更新におけるリターン通信の適用、およびマスター／詳細のデータに関連付けられたユーザインターフェースコントロール上のこの効果を以下のように要約し得る。クライアント１０２ｂは、中間階層サーバ１０４から通信２０４を受信する。クライアントは、指定された部署および従業員データでクライアントキャッシュを満たして、イベントが通信内で遭遇する際にイベントを発射する。部署データ（例えば、テキストボックス）のユーザインターフェースコントロールは、部署データがすでにクライアント上にあるか否かに依存して、「次の部署にナビゲートする」の命令か「スクロール開始」の命令を受信する。テキストボックスはクリアされ、そして部署２０は表示される。次いで、部分２０４ｄの「リフレッシュ終了」の命令に遭遇した場合、従業員データのユーザインターフェースコントロール（例えば、グリッド）はクリアされて、通信２０４の部分２０４ｃの従業員データで満たされる。
【００８０】
したがって、クライアントと中間階層サーバとの間で伝達する通信は、データの変更／更新、新しいデータ、イベント、およびデータアクセスアプリケーションがクライアント上および中間階層サーバ上の両方で同じ挙動または効果を有することを保証する際に有用な他の情報を含み得ることが理解され得る。例示するように、本発明の現在の実施形態において、ある通信はあるユーザアクションに関連するが、あるユーザアクションは、多くのシステムレベルのイベントに関連し得る。通信が受信された場合に、通信が「再生」されて、イベント（単数または複数）を再現し得るように、イベントが正しい順序で集められ、収集され、または総合される。
【００８１】
ある階層（例えば、中間階層）において行われているデータオペレーションおよびイベントが別の階層（例えば、クライアント）に伝えられ、別の階層内で適用される様態のため、アプリケーションの開発者は、本発明の現在の実施形態によって開発されたデータアクセスアプリケーションを容易にカスタマイズし得るか、または変え得る。例えば、あるユーザインターフェースオブジェクト（例えば、テキストボックス）が部署データオブジェクトと関連付けられ、別のユーザインターフェースオブジェクト（例えば、グリッド）が指定された部署オブジェクトに対応する従業員データに関連付けられている上述のマスター／詳細のシナリオを考えられたい。本発明の一実施形態がマスターおよび詳細のデータが階層間で同期を取られることを保証し得るという１つの様態は詳細に説明した。
【００８２】
プログラマまたは開発者は、このマスター／詳細の構成を変えて、カスタムのビジネス論理を追加することを所望し得る。例えば、選択された部署および／または従業員に関連付けられたプロジェクトデータを表示することが所望され得る。プログラマは新しい部署が選択されるごとに部署内のアクティブなプロジェクトが識別されるというユーザの要求を満たすことを所望し得、そしてこの部署の従業員が表示される。したがって、プログラマは別のユーザインターフェースコントロールまたはオブジェクトをユーザのフォームに追加し得る。
【００８３】
本発明の一実施形態において、カスタムのビジネス論理は、これを中間階層サーバ内にフックすることによって収容され得る。特に、プログラマは図２と共に説明した部署をナビゲーションする（例えば、次の部署をナビゲーションする）イベントを無効にし得る。この場合、ナビゲーションイベントが中間階層サーバ上で行われる場合、ビジネス論理はプロジェクトデータの表示または更新を開始する。クライアントへのリターン通信（例えば、図２の通信２０４）を改変して、従って、プロジェクトデータを取り込み、そしてイベントをリフレッシュする。
【００８４】
カスタマイズされた論理が中間階層サーバ上で実行される場合、図２の通信２０４に類似した通信はユーザのクライアントに返されて、同じデータがユーザに提示されていることを保証する。したがって、通信２０４は例示するように、セクション２０４ｄの後、以下の順序で追加された３つのさらなるセクションを受信する。第１に、「リフレッシュ開始」または同様の命令を発して、プロジェクトデータ用にクライアントキャッシュ内をクリアするか、またはクライアントキャッシュ内に空間を設ける。第２に、実際のプロジェクトデータを追加する。最後に、「リフレッシュ終了」または同様の命令を追加して、プロジェクトリフレッシュイベントを終了する。部署および従業員データの場合と同じく、プロジェクトリフレッシュイベントが発射した場合、プロジェクトデータ用のユーザインターフェースコントロール（例えば、グリッド）がクリアそして更新される。
【００８５】
本発明の一実施形態において、クライアントおよび中間階層サーバが交換する通信が通常、一度に１つのユーザイベントを対処するため、クライアントキャッシュのサイズまたは範囲はユーザインターフェースオブジェクトを満たすだけに十分大きいことのみが必要である。したがって、上述の実施例において、クライアントキャッシュ（単数または複数）は、あるユーザフォーム上に表示され得る部署、従業員およびプロジェクトの数を格納するだけに十分大きいことのみが必要である。これにより、情報が収集されるか、または総合された様態のために、クライアントと中間階層との間で交換される必要があるデータの量が最小限に抑えられ、そしてクライアントと中間階層との間で伝達するネットワークトラフィックが減る。
【００８６】
（イベントマネジャー）
上述したように、イベントマネジャーは中間階層サーバ上で動作して、データオペレーションまたは中間階層サーバ上で起こる他のイベントがクライアントに取り込みおよび報告されて、オペレーション／イベントを再現することを保証する。特に、イベントマネジャーは、イベントが中間階層サーバ上で起こった場合にイベントを取り込み、イベントがクライアント上で再生され得るようにクライアントへの通信内にエントリを構成または格納し、そして、最初のユーザイベントまたはコールの最後に通信を転送する。したがって、イベントマネジャーは中間階層サーバ上で最初に行われるデータ改変がクライアントに知らされることを保証する。
【００８７】
本発明の一実施形態において、イベントマネジャーは３階層環境において動作する中間階層サーバ上でのみ必要である。２階層のオペレーションモードにおいて、アプリケーションは、アプリケーションプログラムは、中間階層オブジェクトと間接的に（例えば、同じコンピュータ上で）相互通信を行って、イベントおよびデータをコールしおよび受信し得る。
【００８８】
図２と共に上述したような中間階層上で実行されるデータオペレーションをクライアントに通知することに加え、中間階層のイベントマネジャーはさらに、これらの階層間でのマーシャルの例外に責任を有する。特に、試されたデータオペレーションまたは中間階層上の他のイベントが例外を生成すると、この例外はクライアントに報告される必要がある。
【００８９】
本発明の現在の実施形態において、ある階層から別の階層にイベントマネジャーがいかに例外を伝え得るかを示すために、ユーザがデータフィールド（例えば、部署名）の値をＸからＹに変更するデータオペレーションを考えられたい。これは「ＸからＹまでの属性名を設定しなさい」などの命令に等しくあり得る。当業者であれば理解するように、このフィールドを含むデータベースレコードをロックしてデータの統合性を促進することが望ましい。しかし、例えば、別のユーザが同じレコードを更新するが、トランザクションをまだ行っていない場合にロックの衝突が生じ得る。したがって、レコードをロックしようとする例外がシステム（例えば、中間階層サーバ）上に適用される。中間階層上でロックの衝突が生じた場合、これはクライアントにも報告または適用される必要がある。
【００９０】
テーブル１は、プログラミングコードのトライ／キャッチ（ｔｒｙ／ｃａｔｃｈ）ブロックがオブジェクト指向プログラミング言語でいかに実現されて、試行されたオペレーションを実行し、部署名をユーザによって入力された名前に変更し得るかを示す。
【００９１】

このコードまたはこの均等物は、２階層、または他のシステム（すなわち、別の階層で）はオペレーションの進展を通知される必要がない他の環境における中間階層サーバ上で実行する場合、この目的を十分に果たす。特に、例示したコードは、指定されたレコードをロックしようと試み、成功した場合には、ループから抜け出し、通常のオペレーションを続行する。しかし、レコードがロックされ得ない場合、ルーチンは再度試行する。
【００９２】
図１などの３階層環境において、例外が中間階層上に適用された場合、例外はイベントマネジャーによって取り込まれて、図２の通信２０４などのリターン通信でクライアントに通信される。この通信がクライアントにおいて受信および適用される場合、クライアントは同じ例外を適用する。
【００９３】
（ライトウェイトプロキシ）
現在のデータアクセスフレームワーク内に提供されている種々のアプリケーション開発オブジェクトのすべてまたは多くがサブクラスに分けられ得ることに留意されたい。さらに、本発明の一実施形態において、種々のプログラミングオブジェクトが階層間にわたって利用可能であり得る。クライアントがプログラミング論理および中間階層サーバのオブジェクトと共に（例えば、１つのコンピュータシステム上に）配置されるため、オペレーションの２階層モードにおいて、これは必要ではない場合がある。
【００９４】
しかし、オペレーションの３階層モードの一実施形態において、中間階層オブジェクトへのアクセスが、クライアント上にインストールされた「ライトウェイト」プロキシを介して利用可能になる。この実施形態において、複数のクライアントが必要とするプログラミング論理を、中間階層サーバ上にインストールされたオブジェクト上に構築する。したがって、プログラミング論理はすべてのクライアント間で均一である。
【００９５】
図２と共に上述した実施例を用いると、部署および従業員のクラスは中間階層上に常駐し得る。したがって、これらは中間階層オブジェクトであると考えられ得る。これらのオブジェクトを用いるために開発されたユーザプログラムをクライアント上にインストールし得る。本発明のこの実施形態において、部署および従業員オブジェクトのインターフェースを生成し、データアクセスフレームワークの一部としてクライアント上にこれをインストールする。中間階層上の実際の部署および従業員オブジェクトがいかにアクセスされるかを考慮せずに、これらのインターフェースを用いてユーザプログラムを開発し得る。
【００９６】
中間階層オブジェクトのライトウェイトプロキシをクライアント上にも配置する。ユーザプログラムが３階層モードで起動される場合、部署および従業員インターフェースは、コールされた場合、ライトウェイトプロキシを呼び出す。ユーザプログラムが２階層モードで起動された場合、中間階層オブジェクトがユーザプログラムと共に配置されるため、部署および従業員オブジェクトを直接コールし得る。
【００９７】
しかし、オペレーションの３階層モードにおいて、部署および従業員の中間階層オブジェクトのライトウェイトプロキシのタスクは、対応する方法がコールされる中間階層へのオブジェクトコールをルーチン化することである。オブジェクトコールに関するデータ変更、例外およびイベントは、中間階層上に集められ、図２の通信２０４などの統合された通信で返される。
【００９８】
本発明の一実施形態において、部署および従業員のインターフェースならびにライトウェイトプロキシは、部署および従業員のクラスが中間階層用に作成される場合に、Ｊａｖａ（Ｒ）用のＯｒａｃｌｅ　Ｃｏｒｐｏｒａｔｉｏｎのビジネスコンポーネントの設計タイムコンポーネントによって自動的に生成される。
【００９９】
この実施例を拡張して、従業員のクラスと関連付けられた「昇給」方法を、中間階層サーバ上で実現し得る。「昇給」方法用に方法の仕様を有する階層から独立したインターフェース（例えば、Ｅｍｐ）を生成する。Ｅｍｐの３階層実現用のライトウェイトプロキシ（例えば、Ｅｍｐ＿ｐｒｏｘｙ）も生成する。ついで、ユーザはアプリケーションを展開して、従業員クラス、特に「昇給」方法を用いる。ユーザはＥｍｐインターフェースを自身のプログラムに組み込んで方法をコールする。
【０１００】
ユーザプログラムが２階層環境で実行される場合、ユーザプログラムは（ユーザプログラムおよび「昇給」が共に配置されているため）「昇給」を直接コールする。ユーザプログラムが３階層環境において起動する場合、Ｅｍｐ．ＧｉｖｅＲａｉｓｅはＥｍｐ＿ｐｒｏｘｙ．ＧｉｖｅＲａｉｓｅをコールする。次いで、Ｅｍｐ＿ｐｒｏｘｙは、要求／呼び出しを中間階層（例えば、中間階層イベントマネジャー）に送信し、中間階層において、「昇給」方法が呼び出される。中間階層上の呼び出しに関連付けられたあらゆる副作用および他のイベントは、イベントマネジャーによって取り込まれ、統合された通信でクライアントに返される。Ｅｍｐ＿ｐｒｏｘｙは通信を受信し、これを再生して、「昇給」方法呼び出しのイベント、変更および副作用を再現する。
【０１０１】
（データアクセスフレームワークを適用する１つの方法）
図３Ａ〜図３Ｂは、本発明の一実施形態による、多階層演算環境（例えば、図１に示した多階層演算環境など）におけるデータアクセスフレームワークを用いる１つの方法を示す。特に、例示する手順により、階層間で高いプログラミングモデルの均一性および高いレベルの通信の効率性を維持している場合であっても、ユーザのデータオペレーションを実行することが可能になる。
【０１０２】
状態３００は、必要なデータアクセスツールをインストールまたは構成する開始の状態である。特に、演算環境におけるクライアントおよび中間階層システムを、Ｊａｖａ（Ｒ）（または、他のオブジェクト指向プログラミング言語）用のＯｒａｃｌｅ　Ｃｏｒｐｏｒａｔｉｏｎのビジネスコンポーネントのランタイムモジュールを動作するように構成する。このモジュールによって提供されるＡＰＩは、先のセクションにおいて説明した本発明の種々の局面（例えば、効率的な通信、ライトウェイトプロキシ）を容易にし、可能にする。さらに、ユーザアプリケーションをクライアントシステム上で構成する。この実施例において、Ｊａｖａ（Ｒ）、およびＪＤｅｖｅｌｏｐｅｒまたは別の適切な開発ツールのいずれかのためのＯｒａｃｌｅ　Ｃｏｒｐｏｒａｔｉｏｎのビジネスコンポーネントの設計タイムコンポーネントを用いて、アプリケーションを設計および開発する。
【０１０３】
状態３０２において、データオペレーション（例えば、データ変更、あるフォームのデータの要求）がユーザアプリケーションからクライアントシステムにおいて受信される。データオペレーションは、例えば、ユーザがマスター／詳細のフォーム内のマスターデータアイテムなど、１つのデータを選択または変更するフォームによって自動的に生成され得る。
【０１０４】
状態３０４において、データオペレーションが中間階層に敏感である（ｓｅｎｓｉｔｉｖｅ）か否かが判定される。特に、オペレーションが実行されるように中間階層サーバに即転送されるべきか否かが判定される。本発明の一実施形態において、中間階層は、特定のイベントまたはオペレーション（例えば、ユーザが次のマスターの行をナビゲートする場合など）に対する興味を登録し得る。中間階層サーバはさらに、例えば、特定のデータオブジェクトを含む指定されたイベントまたはオペレーションが生じた際に、カスタムコードまたはオブジェクト指定コードが実行されるように中間階層上にインストールされる場合に、イベント、オペレーションおよび／またはデータオブジェクトへの興味を登録し得る。中間階層に敏感であるイベントおよびオペレーションは、実行されるために中間階層サーバに直接転送される。以下に説明するように、他の待ち状態のイベント／オペレーションを同時に送信し得る。
【０１０５】
本発明の現在の実施形態において、クライアントは、オペレーションをローカルに実行して、次いで、オペレーションおよび／またはその効果／結果を中間階層サーバに転送するのではなく、中間階層サーバから返ってきた情報から中間階層に敏感であるオペレーションの結果のみを（すなわち、オペレーションの後に）適用する。オペレーションが中間階層に敏感である場合、例示の手順は状態３１６に進んで、オペレーションを即転送する。あるいは、オペレーションが中間階層に敏感でない場合、手順は状態３０６で続行する。
【０１０６】
状態３０６において、オペレーションが通常、中間階層の関与を必要とするか否かが判定される。例えば、オペレーションが単なるデータ取り出しの要求（例えば、属性の入手のコール）であり、データ値を変更（例えば、属性の設定のコール）しない場合、中間階層は、データがローカルに（例えば、クライアントキャッシュ内で）利用可能であるか否かに関与する必要はない。
【０１０７】
オペレーションが中間階層操作を必要とする場合、例示の手順は状態３１２に進む。そうでない場合、手順は状態３０８で続行する。
【０１０８】
状態３０８において、クライアントは、オペレーションに必要なデータがローカルに（例えば、クライアントキャッシュ内で）利用可能であるか否かを判定する。利用可能でない場合、オペレーションは、オペレーションを満たす（例えば、必要なデータを取り出す）ために中間階層に転送される必要がある。このイベントにおいて、手順は状態３１６において続行する。
【０１０９】
しかし、必要なデータがクライアント上ですでに利用可能な場合、状態３１０において、オペレーションが、中間階層の関与なくローカルに実行される。次いで、例示の手順は状態３４２に進んで、ユーザにオペレーション結果を返すかまたは表示し、この後に手順は終了する。
【０１１０】
状態３１２において、要求されたデータオペレーションは中間階層の関与を必要とすることが判定されるが、即時的な関与は必要ではない。例えば、ユーザは新しい属性、行または他のデータ値を追加または変更し得たが、これらは中間階層に所定の時間に通信される必要があるのであって、即通信される必要はない。したがって、オペレーションは遅延可能である。したがって、状態３１２において、クライアントはクライアント上で利用可能なデータを用いてオペレーションの条件を満たすことを試みる。これが行われ得るか否かに関わらず、次いで、オペレーションは中間階層サーバに転送されることを待っている他のオペレーション（ある場合）の集まりに付加される。上述したように、複数のオペレーション（例えば、中間階層に敏感でないオペレーション）すべてを即転送するその前に、クライアント上にこれらを蓄積することによって通信の効率を向上させる。
【０１１１】
工程３１４において、クライアントは、現在説明したデータオペレーションおよび任意の他の待ち状態のオペレーション／イベントを転送する前に所定の基準が満たされるまで待つ。本発明の異なる実施形態において、クライアントは、特定のイベントまたはオペレーションまたは特定の種類のイベントまたはオペレーション（例えば、中間階層に敏感であるオペレーション）を待ち得る。一実施形態において、クライアントは、所定数のオペレーションまたはイベントが待ち状態になるまで待ち得る。別の実施形態において、クライアントは、待ち状態のオペレーションを中間階層に伝えるために用いられるオペレーションメッセージが所定のサイズに達するまで待ち得る。待ち状態のオペレーション（単数または複数）を中間階層に送信する時間になるまで、さらなるオペレーションおよび／またはイベントが付加され得る。
【０１１２】
中間階層に敏感なわけではないが、あまりに長く遅延されるべきではない特定の種類のオペレーションが要求された場合、または、所定の他の基準が満たされた場合、オペレーションメッセージ（すなわち、中間階層への１つ以上のオペレーションまたはイベントを含むメッセージ）を定期的な間隔でクライアントから中間階層サーバに送信し得る。
【０１１３】
状態３１６において、オペレーションを中間階層サーバに送信する１つ以上の基準が満たされる。例えば、中間階層への即時伝送を必要とする中間階層に敏感であるオペレーションが受信され得る。または、１つ以上の待ち状態のオペレーションが転送されるときを判定する閾値が満たされ得る。したがって、すべての待ち状態のオペレーション（および／または新しい中間階層に敏感であるオペレーション）がオペレーションメッセージ内に置かれ、中間階層サーバに伝達される。
【０１１４】
状態３１８において、中間階層サーバは、オペレーションメッセージを受信して、コンテンツをアンパックする。
【０１１５】
状態３２０において、中間階層サーバは、オペレーションメッセージからオペレーションを取り出し、そして状態３２２において、このオペレーションを実行する。オペレーションの結果として、種々のデータアイテムを、追加、変更、取り出し、あるいは操作し得る。さらに、カスタムコード（例えば、ビジネス論理）の実行などの副作用を実行し得る。例示するように、オペレーションが要求されたおよび／またはクライアント上で実行された順序で、オペレーションを取り出しおよび実行する。したがって、いくつかのオペレーションはクライアント上でまず実行されてしまっている場合があり、他のオペレーションは中間階層サーバ上で初めて実行される。
【０１１６】
状態３２４において、中間階層サーバ上で常駐するイベントマネジャーは、オペレーションの実行から生じる副作用およびイベントを取り込みそして記述する。したがって、イベントマネジャーは影響を受けたデータ、およびオペレーションによってトリガーされたイベントの任意の効果を保存または複製する。例示するように、イベントマネジャーは、オペレーションがクライアント上ですでに実行されたか否かに関わらず、オペレーションの結果をすべて取り込み、オペレーションの結果はクライアントに返されて、均一性を保証する。しかし、別の実施形態において、中間階層サーバはこのようなオペレーションに関するすべての結果を取り込む必要はない。
【０１１７】
状態３２６において、中間階層サーバ（例えば、イベントマネジャー）は、任意の他のオペレーションがオペレーションメッセージ内に残っているか否かを判定する。残っている場合、例示の手順は状態３２０に返る。そうでない場合、すべてのオペレーションが取り出されて適用された場合、手順は状態３２８において続行する。
【０１１８】
状態３２８において、クライアントに送信されるリターン通信が生成される。リターン通信は、データ変更、他のイベントおよび各オペレーションの結果を含む。例示するように、クライアントが通信を受信して、副作用、データ変更および任意の他のイベントまたはオペレーションの結果を再生し得るように、図２の通信２０４と同様にリターン通信をフォーマット化する。
【０１１９】
状態３３０において、クライアントは、リターン通信を受信して、オペレーションを再生するために、このリターン通信の構文解析を開始する。
【０１２０】
状態３３２において、第１のエントリはリターン通信から取り出される。状態３３４において、エントリがデータ変更である場合、例示の手順は状態３３６に続く。エントリがイベントである場合、手順は状態３３８に進む。
【０１２１】
状態３３６において、リターン通信から取り出されたデータを用いて、クライアントキャッシュを更新して、この後に、手順が状態３４０に進む。状態３３８において、取り出されたイベントが適用または発射される。
【０１２２】
状態３４０において、別のエントリがリターン通信内にあるか否かが判定される。リターン通信内にある場合、例示の手順は状態３３２に返る。そうでない場合、手順は状態３４２に続く。本発明の一実施形態において、エントリがクライアント上ですでに実行されたオペレーションに対応している場合（例えば、状態３０８において）であっても、リターン通信内の全てのエントリをクライアント上で再生する。これは、階層間のプログラミングおよびデータの均一性を保証することに役立つ。あるいは、しかし、インテリジェンスを適用して、労力の複製を回避し、まだ適用されていないデータ変更のみをクライアント上に適用する。
【０１２３】
状態３４２において、状態３０２において要求されたデータオペレーションの結果または効果は表示または返される。例えば、データオペレーションが更新されたマスターデータ要素に関する場合、対応するマスター／詳細のデータが表示され得る。次いで、例示した手順は終了の状態３５０において終了する。
【０１２４】
当業者であれば、図３Ａ〜図３Ｂに示す方法が本発明の現在の実施形態のデータアクセスフレームワークを用いる単なる１つの方法であることを理解する。本発明の範囲を越えることなく、種々の他の方法を得ることが可能である。
【０１２５】
本発明の実施形態の上述の説明を、例示および説明のみを目的として提示してきた。上述の説明は、包括的であること、または開示する形態に本発明を限定することが意図されない。多くの改変および変形が当業者に明らかである。したがって、上述の開示は、本発明を限定することを意図せず、本発明の範囲は上掲の特許請求の範囲によって規定される。
【図面の簡単な説明】
【図１Ａ】図１Ａは、本発明の一実施形態による、例示の多階層演算環境を示すブロック図である。
【図１Ｂ】図１Ｂは、本発明の一実施形態による、例示の多階層演算環境を示すブロック図である。
【図１Ｃ】図１Ｃは、本発明の一実施形態による、例示の多階層演算環境を示すブロック図である。
【図２】図２は、本発明の一実施形態による、あるデータオペレーションに影響を与える、クライアントと中間階層サーバとの間の１セットの通信を示す。
【図３Ａ】図３Ａは、本発明の現在の実施形態による、データアクセスフレームワーク内でデータオペレーションを実行する方法を示すフローチャートを含む。
【図３Ｂ】図３Ｂは、本発明の現在の実施形態による、データアクセスフレームワーク内でデータオペレーションを実行する方法を示すフローチャートを含む。

Claims (28)

1. 多階層データアクセスアプリケーションを動作しながら、多階層演算環境の２階層間で高い程度の均一性を維持するシステムであって、
   多階層演算環境の第１の階層で動作するクライアントであって、
   １セットのデータオブジェクトを格納するように構成されたクライアントキャッシュと、
   プログラミングオブジェクト用のライトウェイトプロキシであって、該プログラミングオブジェクトは該多階層演算環境の第２の階層内に常駐する、ライトウェイトプロキシと
   を含む、クライアントと、
   該多階層演算環境の該第２の階層で動作するサーバであって、
   該サーバ上の第１のイベントをモニタリングし、該第１のイベントの結果を取り込むように構成されたイベントマネジャーであって、該結果は第１のデータオブジェクトを含む、イベントマネジャーと、
   該第１のイベントの該結果を含む該第１のイベントを１つの通信で該クライアントに伝達するように構成された通信モジュールと
   を含むサーバとを含み、
   該クライアントは、ユーザからデータオペレーションを受信して、該データオペレーションを該サーバに伝達するように構成されており、該データオペレーションは該第１のイベントを得、
   該クライアントは該１つの通信を受信して、該クライアント上で該第１のイベントの該結果を適用する、システム。
2. 前記サーバはサーバキャッシュをさらに含み、該サーバキャッシュは該１セットのデータオブジェクトのスーパーセットを格納するように構成されている、請求項１に記載のシステム。
3. 前記サーバは、前記データオペレーションが該サーバにおいて受信された場合に、前記多階層演算環境の第３の階層において動作しているデータサーバ上のデータベースにアクセスするように構成されている、請求項１に記載のシステム。
4. 前記１つの通信は第２のイベントをさらに含む、請求項１に記載のシステム。
5. 前記クライアントは、前記１つの通信を受信した後に前記クライアントキャッシュ内に前記データオブジェクトを格納する、請求項１に記載のシステム。
6. 多階層演算環境の異なる階層上にデータオペレーションを均一に適用する方法であって、
   多階層演算環境の第１の階層におけるクライアントコンピュータシステム上で第１のデータオペレーションを受信する工程と、
   該クライアントコンピュータシステムから該多階層演算環境の第２の階層におけるサーバに該第１のデータオペレーションを通信する工程と、
   該サーバ上における該第１のデータオペレーションを実行して１セットの効果を生成する工程であって、該１セットの効果は１つ以上のデータオブジェクトを含む、工程と、
   該１セットの効果をリターン通信で該クライアントに伝達する工程と、
   該リターン通信を構文解析して該１つ以上のデータオブジェクトを取り出す工程と、
   該クライアント上で該第１のデータオペレーションを適用する工程と
   を包含する、方法。
7. 前記クライアントはユーザによって動作される演算デバイスであり、前記サーバはサーバコンピュータシステムであり、該サーバコンピュータシステムを介して、該ユーザは該多階層演算環境の第３の階層におけるデータサーバ上に格納されたデータオブジェクトの集まりにアクセスし得る、請求項６に記載の方法。
8. 前記クライアントおよび前記サーバは、１つの通信デバイス上に共に配置されている、請求項６に記載の方法。
9. 前記通信する工程は、１セットのデータオペレーションを前記サーバに通信する工程を包含し、該１セットのデータオペレーションは前記第１のデータオペレーションを含む、請求項６に記載の方法。
10. 前記構文解析する工程は、クライアントキャッシュ内に前記１つ以上のデータオブジェクトを格納する工程を包含する、請求項６に記載の方法。
11. 前記１セットの効果は、前記サーバ上で前記第１のデータオペレーションを実行する工程に応答して実行される第１のイベントを含む、請求項６に記載の方法。
12. 前記適用する工程は、前記クライアント上で前記第１のイベントを発射する工程を含む、請求項１１に記載の方法。
13. 前記適用する工程は、
    前記クライアント上で前記第１のデータオペレーションを再現して、前記第１のコンピュータシステムと前記第２のコンピュータシステムとの間で均一性を維持する工程と、
    １つ以上の前記１セットの効果を該クライアント上で実現する工程と
    を包含する、請求項６に記載の方法。
14. 前記１セットの効果は、前記１つ以上のデータオブジェクトのうちの１つに関連付けられた一連のプログラミング命令の実行をさらに含む、請求項６に記載の方法。
15. 多階層データアクセス演算環境における階層間のプログラミングの均一性を促進する方法であって、
    多階層演算環境の第１の階層において動作するクライアントにおいてデータ要求を受信する工程であって、該データ要求は第１のデータオブジェクトを必要とする、工程と、
    該データ要求を該サーバに伝達する工程と、
    該データ要求を該サーバ上で実行する工程であって、該実行は、該第１のデータオブジェクトの操作を含む１つ以上の効果と、該第１のデータオブジェクトに関連付けられた第１のイベントとを有する、工程と、
    該クライアントへのリターン通信を生成する工程であって、該リターン通信は該効果を含む、工程と、
    該第１のデータオブジェクトをクライアントキャッシュ内に格納する工程と、
    該クライアント上に該効果を実現して、該データ要求の実行を再現して、該クライアントと該サーバとの間でプログラミングの均一性を促進する工程と
    を包含する、方法。
16. 前記効果を実現する工程は、前記クライアント上で前記第１のイベントを発射する工程を包含する、請求項１５に記載の方法。
17. 前記データ要求が前記サーバへの即時伝送を必要とする優先順位の高い要求であるか否かを判定する工程をさらに包含する、請求項１５に記載の方法。
18. 前記伝達する工程は、１つのメッセージで前記データ要求を１つ以上の他の要求と共に前記サーバに伝達する工程を包含する、請求項１５に記載の方法。
19. 前記伝達する工程の前に、前記クライアント上で前記データ要求を実行する工程をさらに包含する、請求項１５に記載の方法。
20. 前記伝達する工程は、前記クライアント上で実行される前記データ要求の前記サーバ効果に転送する工程を包含する、請求項１９に記載の方法。
21. 多階層演算環境であって、
    第１のユーザデータオペレーションを受信するようにユーザによって動作されるクライアント演算デバイスであって、
    第１のセットのデータオブジェクトを格納するように構成されたクライアントキャッシュであって、該第１のセットのデータオブジェクトは別の演算デバイスから該クライアント演算デバイスにおいて受信され、該別の演算デバイス上で該第１のデータオペレーションがまず実行される、クライアントキャッシュと、
    該別の演算デバイス上に常駐するプログラミングオブジェクトのライトウェイトプロキシであって、該ライトウェイトプロキシは該第１のデータオペレーションに応答して該プログラミングオブジェクトをコールするように構成されている、ライトウェイトプロキシと
    を含むクライアント演算デバイスと、
    該クライアント演算デバイスから該第１のデータオペレーションを受信するように構成されたサーバであって、
    該クライアントキャッシュ内に格納された該１セットのデータオブジェクトのサブセットを格納するように構成されたサーバキャッシュと、
    該第１のデータオペレーションを実行するように構成されたプロセッサと、
    該第１のデータオペレーションを実行する結果を組み立てるように構成されているイベントマネジャーであって、該結果は、１つ以上のデータオブジェクトおよび該１つ以上のデータオブジェクトに関連付けられた第１のイベントを含む、イベントマネジャーと
    を含むサーバと
    を含み、該サーバは、該第１のデータオペレーションを実行する工程に応答して、第１の通信を該クライアント演算デバイスに伝達し、該第１の通信は該第１のデータオペレーションおよび該結果を含む、多階層演算環境。
22. 前記第１の通信に応答して、前記クライアント演算デバイスは前記第１のイベントを実行し、前記１つ以上のデータオブジェクトで前記クライアントキャッシュを更新する、請求項２１に記載の多階層演算環境。
23. 前記クライアント演算デバイスは第２のデータオペレーションを実行して、前記クライアントキャッシュ内に格納された前記１セットのデータオブジェクトのサブセットを操作し、
    前記クライアント演算デバイスは第２の通信を前記サーバに伝達し、該第２の通信は、前記第２のデータオペレーションおよび該データオブジェクトのサブセットを含む、請求項２１に記載の多階層演算環境。
24. 前記サーバは、前記第２の通信から前記第２のデータオペレーションおよび前記データオブジェクトのサブセットを取り出して、該サーバ上に該第２のデータオペレーションを再現する、請求項２３に記載の多階層演算環境。
25. 前記第１の通信は、前記プログラミングオブジェクトの実行の間に、前記サーバ上で生成される例外を含み、
    該例外は、該第１の通信を受信した後に、前記クライアントコンピュータシステム上に適用される、請求項２１に記載の多階層演算環境。
26. 命令を格納するコンピュータ読み出し可能記憶媒体であって、該命令は、コンピュータによって実行された場合に、該コンピュータに多階層データアクセス演算環境における階層間のプログラミングの均一性を促進する方法を実行させ、該方法は、
    多階層演算環境の第１の階層において動作するクライアントにおいてデータ要求を受信する工程であって、該データ要求は第１のデータオブジェクトを必要とする、工程と、
    該データ要求を該サーバに伝達する工程と、
    該データ要求を該サーバ上で実行する工程であって、該実行は、該第１のデータオブジェクトの操作を含む１つ以上の効果と、該第１のデータオブジェクトに関連付けられた第１のイベントとを有する、工程と、
    該クライアントへのリターン通信を生成する工程であって、該リターン通信は該効果を含む、工程と、
    該第１のデータオブジェクトをクライアントキャッシュ内に格納する工程と、
    該クライアント上に該効果を実現して、該データ要求の実行を再現して、該クライアントと該サーバとの間のプログラミングの均一性を促進する工程と
    を包含する、コンピュータ読み出し可能記憶媒体。
27. 第１のデータオペレーションおよび該第１のデータオペレーションの結果を、該第１のデータオペレーションが実行された第１の演算デバイスから、多階層環境における第２の演算デバイスに通信するように構成されたデータ構造を含むコンピュータ読み出し可能記憶媒体であって、該データ構造は、
    該第１のデータオペレーションの間に該第１の演算デバイス上にアクセスされる第１のセットのデータオブジェクトと、
    該第１のセットのデータオブジェクトに関連付けられた第１のイベントと
    を含み、
    該データ構造は、該第１の演算デバイスから該第２の演算デバイスに通信され、該第２の通信デバイス上で、該第１のデータオペレーションは、該第２の演算デバイス上のメモリを該第１のセットのデータオブジェクトで更新して、該第１のイベントを該第２の演算デバイス上で実行することによって再現される、コンピュータ読み出し可能記憶媒体。
28. 前記データ構造は、
    前記第１の演算デバイス上にアクセスされた第２のセットのデータオブジェクトと、
    該第２のセットのデータオブジェクトに関連付けられた第２のイベントと
    をさらに含む、請求項２７に記載のコンピュータ読み出し可能記憶媒体。

Images