Process-Entity デザインパターン

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

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

クライアントがデータベースと複数のやり取りを行うのではなく、データベースとのやり取りを求めるすべてのクライアント要求をサーバマシン上の単一プロセスオブジェクトで処理することで、ネットワークトラフィックを軽減できる。
プロセスオブジェクトでは、データフィールドを取捨選択してクライアントに渡すことができる。したがって、データベースレコード全体ではなく必要なデータのみが転送されるので、ネットワークで送信されるデータ量が減り、性能が向上する。
プロセスオブジェクトで、データベースへのアクセスがカプセル化される。クライアントでオブジェクトが呼び出され、そのオブジェクトによってデータベースへのアクセスが行われる。

スケーラビリティとリソース利用率の向上

2 層システムの制限

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

規模が適切に調整されない。クライアント数が劇的に増加した場合、サーバマシンで数千 (あるいは数百万) のデータベースオブジェクトを管理しなければならなくなる可能性がある (各オブジェクトではそれ独自のトランザクションコンテキストが必要)。
ネットワークリソースが効率的に利用されない。データベースオブジェクトがサーバマシンのメモリでインスタンス化される際、クライアントアプリケーションでそのオブジェクトのどのくらいの量のデータが必要とされているのかに関係なくデータベースオブジェクト全体がメモリで読み書きされる。
EJB アプリケーションでは、通常はエンティティ Bean を使用してデータベースにアクセスする。その際、エンティティ Bean はデータベーステーブルの行を表す。ただし、エンティティ Bean にアクセスするために、クライアントアプリケーションでは 2 回の呼び出しを行わなければならない。最初の呼び出しではエンティティ Bean のオブジェクト参照を取得し、2 回目の呼び出しでそのエンティティ Bean のメソッドを呼び出す。オブジェクト参照を取得することは、特に大規模なエンタープライズアプリケーションではクライアントにとってコストのかかる操作となる。

Process-Entity デザインパターンの利点

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

サーバマシンで管理する必要のある CORBA オブジェクトまたは EJB の数が減る。
メッセージトラフィックが減少する。
EJB アプリケーションでは、クライアントアプリケーションでエンティティ Bean のオブジェクト参照を取得する必要がなくなり、また細かな (単一行の) エンティティ Bean を使用しなくて良くなる。

適用可能性

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

CORBA アプリケーションでの要求の流れ

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

クライアントアプリケーションから、データベースエンティティにアクセスするために CORBA プロセスオブジェクトに要求が発行されます。
CORBA オブジェクトからデータベースに要求が送信されます。
データベースから CORBA オブジェクトに応答が返されます。
CORBA オブジェクトからクライアントに応答が返されます。応答に含まれているのは、クライアントが必要とするデータベースの情報のみです。

EJB アプリケーションでの要求の流れ

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

クライアントアプリケーションから、データベースエンティティにアクセスするために RMI over IIOP を使用してエンティティ Bean に要求が発行されます。
エンティティ Bean からデータベースに要求が送信されます。
データベースからエンティティ Bean に応答が返されます。
エンティティ Bean からクライアントに応答が返されます。応答に含まれているのは、クライアントが必要とするデータベースの情報のみです。

構成要素

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

留意事項

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

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

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

CORBA 技術情報

Process-Entity デザインパターン