Process-Entityデザイン・パターン

Process-Entityデザイン・パターンは、データベース・レコード(エンティティ)とのクライアント・アプリケーションのすべてのやり取りをサーバー・マシン上の単一プロセス・オブジェクトで処理する設計ソリューションです。このデザイン・パターンは、クライアントのCORBAまたはEJBアプリケーションでリモート・データベースとの複数のやり取りが普通に実行される状況で効果的です。

データベースの細かなすべてのデータを表すサーバー・マシン上の単一のCORBAオブジェクトまたはEJBを設計することで、次のような性能上の利点をもたらすOracle Tuxedo CORBAクライアント/サーバー・アプリケーションを構築できます。

•

クライアントがデータベースと複数のやり取りを行うのではなく、データベースとのやり取りを求めるすべてのクライアント・リクエストをサーバー・マシン上の単一プロセス・オブジェクトで処理することで、ネットワーク・トラフィックを軽減できます。

•

プロセス・オブジェクトでは、データ・フィールドを取捨選択してクライアントに渡すことができます。したがって、データベース・レコード全体ではなく必要なデータのみが転送されるので、ネットワークで送信されるデータ量が減り、性能が向上します。

•

プロセス・オブジェクトで、データベースへのアクセスがカプセル化されます。クライアントでオブジェクトが呼び出され、そのオブジェクトによってデータベースへのアクセスが行われます。

このトピックには次の項が含まれます:

データベース層を共有データのセットとして提供する従来の2層システムにおいて、純粋なオブジェクト指向手法とは、データベース・レコードを共有CORBAオブジェクト(CORBAアプリケーションの場合)またはエンティティBean (EJBアプリケーションの場合)として表現することです。ただし、この手法には次のような制限があります。

•

規模が適切に調整されません。クライアント数が劇的に増加した場合、サーバー・マシンで数千(あるいは数百万)のデータベース・オブジェクトを管理しなければならなくなる可能性がある(各オブジェクトではそれ独自のトランザクション・コンテキストが必要)。

•

ネットワーク・リソースが効率的に利用されません。データベース・オブジェクトがサーバー・マシンのメモリーでインスタンス化される際、クライアント・アプリケーションでそのオブジェクトのどのくらいの量のデータが必要とされているのかに関係なくデータベース・オブジェクト全体がメモリーで読み書きされます。

•

EJBアプリケーションでは、通常はエンティティBeanを使用してデータベースにアクセスする。その際、エンティティBeanはデータベース表の行を表す。ただし、エンティティBeanにアクセスするために、クライアント・アプリケーションでは2回の呼出しを行わなければならない。最初の呼出しではエンティティBeanのオブジェクト参照を取得し、2回目の呼出しでそのエンティティBeanのメソッドを呼び出す。オブジェクト参照を取得することは、特に大規模なエンタープライズ・アプリケーションではクライアントにとってコストのかかる操作となる。

しかし、クライアントのかわりにデータベースとやり取りするサーバー・マシン上のプロセス・オブジェクトのクラスを設計すれば、次のような利点によって前述の制限を克服できます。

•

EJBアプリケーションでは、クライアント・アプリケーションでエンティティBeanのオブジェクト参照を取得する必要がなくなり、また細かな(単一行の)エンティティBeanを使用しなくてよくなります。

このトピックには次の項が含まれます:

Process-Entityデザイン・パターンは、エンタープライズ・レベルのミッション・クリティカルなアプリケーションでほぼ普遍的に適用できます。このデザイン・パターンは、クライアント・アプリケーションがサーバー・マシン上のデータベース・レコードとやり取りする必要のある状況で使用します。

図3-1は、CORBAアプリケーションのProcess-Entityデザイン・パターンの基本設計を示しています。

このプロセスは、次の順序で行われます。

クライアント・アプリケーションから、データベース・エンティティにアクセスするためにCORBAプロセス・オブジェクトにリクエストが発行されます。

CORBAオブジェクトからクライアントにレスポンスが返されます。レスポンスに含まれているのは、クライアントが必要とするデータベースの情報のみです。

図3-2は、EJBアプリケーションのProcess-Entityデザイン・パターンの基本設計を示しています。

このプロセスは、次の順序で行われます。

クライアント・アプリケーションから、データベース・エンティティにアクセスするためにRMI on IIOPを使用してエンティティBeanにリクエストが発行されます。

エンティティBeanからクライアントにレスポンスが返されます。レスポンスに含まれているのは、クライアントが必要とするデータベースの情報のみです。

クライアント・アプリケーションでは、ファクトリ(CORBAアプリケーションの場合)またはホーム・インタフェース(EJBアプリケーションの場合)からプロセス・オブジェクトの参照を取得します。プロセス・オブジェクトでは、データベースとのすべてのやり取りが実装されます。データベース・レコード(エンティティ)は、プロセス・オブジェクトのクライアント呼出しを処理するために必要なときに取り出されます。プロセス・オブジェクトのオペレーションでは、特定のデータ・フィールドがクライアント・アプリケーションに返されます。クライアント・アプリケーションでは、そのデータで必要なすべての処理を実行します。

プロセス・オブジェクトは、特定のクライアント・リクエストで実際に必要とされる最小限の情報を渡すように設計します。プロセス・オブジェクトのオペレーションは、可能なかぎり「密度の高い」処理が実行されるように実装します。クライアント・アプリケーションは、タスクを遂行するために必要なデータの取得に複数のプロセス・オペレーションを呼び出さないように設計します。

複数のオペレーションを呼び出す必要がある場合は、追加の呼出しがクライアント・アプリケーションからプロセス・オブジェクトにではなく、プロセス・オブジェクトからデータベースに対して行われるようにプロセス・オブジェクトを設計してください。そのように設計することで、クライアント・アプリケーションからネットワーク経由で送信される呼出しの数が減ります。クライアント・アプリケーションからプロセス・オブジェクトに連続的に呼出しを行わなければならない場合は、プロセス・オブジェクトをステートフルにしてください。オブジェクトをステートフルにする方法については、Oracle Tuxedoオンライン・ドキュメントの『CORBAサーバー・アプリケーションの作成』を参照してください。

CORBAアプリケーションでは、OMG IDLで属性を使用しないでください。属性は、ネットワーク経由で取り出すのにコストがかかります。かわりに、クライアント・アプリケーションで必要となりそうなすべての値を格納するデータ構造を返すオペレーションをプロセス・オブジェクトで実装します。