![]() ![]() ![]() ![]() |
この章では、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 プロセス オブジェクトのオペレーションは、必要とされるデータのサブセットのみが操作に関与するように設計します。そうすれば、ネットワーク トラフィックが削減されます。
![]() ![]() ![]() |