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


	BEA ホーム \| イベント \| ソリューション \| パートナ \| 製品 \| サービス \| ダウンロード \| ディベロッパ・センタ \| WebSUPPORT
	e-docs \| サイトマップ \| 検索 \| PDF 版 \| お問い合わせ \| 用語集

Tuxedo ホーム \| CORBA 技術情報 \| 前へ \| 次へ \| 目次

ここでは、次の内容について説明します。

Process-Entity デザイン・パターンについて

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

データベースの細かなすべてのデータを表すサーバ・マシン上の単一の CORBA オブジェクトまたは EJB を設計することで、次のような性能上の利点をもたらす BEA 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 デザイン・パターンの基本設計を示しています。

図3-1 CORBA の Process-Entity デザイン・パターン

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

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

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

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

図3-2 EJB の Process-Entity デザイン・パターン

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

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

構成要素

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

ほかの留意事項

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

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

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