![]() ![]() ![]() ![]() ![]() ![]() ![]() |
この章では、CORBA Client Data Cachingデザイン・パターンについて説明します。 このデザイン・パターンの目的は、サーバーからの永続的な状態情報をクライアントがローカルでデータ集中型の処理に利用できるようにすることです。 このようにすれば、CORBAクライアント・アプリケーションでデータを取り出すために何度もサーバー・アプリケーションに呼出しを行う必要がなくなります。
このデザイン・パターンでは、分散クライアント/サーバー・アプリケーションのスケーラビリティと性能が改善されます。 CORBAオブジェクトの属性を取り出すリモート呼出しのオーバーヘッドは、システムのロードや他の要素によっては非常に大きくなる場合があります。 また、永続的なデータ・レコードをCORBAオブジェクトとして公開する場合は、非常に多くの同時アクティブ・オブジェクトをシステムで管理しなければならなくなる可能性があるのでアプリケーションの規模を適切に調整できなくなります。 クライアント・アプリケーションのデータが集中する処理、またはユーザー入力を必要とする処理(フィールドの編集など)は、データの取得に複数のリモート呼出しを要する場合はクライアント・アプリケーションとシステムの両方の速度を低下させる可能性があります。
このデザイン・パターンは、CORBAプロセス・オブジェクトからクライアント・アプリケーションに大量のデータを渡さなければならない状況で使用するのが適しています。 クライアント・アプリケーションのローカル言語オブジェクトはデータのコンテナになり、そのコンストラクタはローカル・オブジェクトの状態を設定するために使用します。
このデザイン・パターンは、ローカル言語オブジェクト(この章ではDataObject
と呼ぶ)を作成するクライアント・アプリケーションで実装します。 サーバー・アプリケーションでは、永続ストレージのエンティティとやり取りするCORBAプロセス・オブジェクトを実装します。 このCORBAオブジェクトは、この章ではDataManager
オブジェクトと呼びます。
DataManager
CORBAオブジェクトのOMG IDLでは、クライアント・アプリケーションとサーバー・アプリケーションの間でデータを転送する際に使用するデータ構造を定義します。 このデザイン・パターンでは、「楽観的ロック」が採用されています。つまり、クライアント・アプリケーションでローカル・コピーが使用されている間はほかのサーバー・プロセスによってデータが変更されることはないと想定し、サーバー・アプリケーションで管理されるデータが更新用にロックされることはありません。
クライアント・アプリケーションでローカルのDataObject
がインスタンス化されると、そのオブジェクトのコンストラクタから(DataObject
にデータ構造を渡す) DataManager
CORBAオブジェクトのオペレーションが呼び出されます。 DataObject
では、渡されたデータを利用してクラス変数を設定します。
クライアント・アプリケーションからサーバー・マシンに変更された状態を渡す必要がある場合、クライアント・アプリケーションではDataObject::writeData()
メソッドを呼び出します。このメソッドでは、今度はDataManager
CORBAオブジェクトのwriteRecord()
オペレーションが呼び出されます。 この呼出しでは、データ構造がwriteRecord()
オペレーションにパラメータとして渡されます。 DataManager
CORBAオブジェクトでは、永続ストレージを適切に更新します。
次の図は、CORBA Client Data Cachingデザイン・パターンのしくみを示しています。
DataObject
のメソッドでは、DataManager
CORBAオブジェクトのオペレーションを呼び出してデータを読み書きします。
クライアント・アプリケーションに渡されるデータ構造は、必要最小限のデータを提供するように設計されていなければなりません。 大量のデータが伴う場合は、必要なフィールドのサブセットを格納する複数のデータ構造を使用した方が効率的になる場合があります。 CORBAプロセス・オブジェクトのオペレーションは、必要とされるデータのサブセットのみが操作に関与するように設計します。そうすれば、ネットワーク・トラフィックが削減されます。
![]() ![]() ![]() |