EJB の設計



\| WebLogic Server ホーム \| エンタープライズ JavaBeans \| 前へ \| 次へ \| 目次 \| PDF 版

EJB の設計

以下の節では、WebLogic Server エンタープライズ JavaBeans（EJB）を設計するためのガイドラインを示します。一部のヒントは、EJB と同じようにリモートオブジェクトモデルと Remote Method Invocation（RMI）にも適用できます。

セッション Bean の開発

セッション Bean の設計方法のひとつに、モデル/ビュー設計の使用があります。ビューがグラフィカルユーザインタフェース（GUI）フォームであり、モデルは GUI にデータを供給するコードです。典型的なクライアント/サーバシステムでは、モデルはビューと同じサーバに存在し、サーバと通信します。

モデルは、セッション Bean の形態でサーバに配置します。それは、モデルセッション Bean が最終的な表示に影響しないことを除けば、HTML フォームのサポートを提供するサーブレットを配置することに似ています。GUI フォームインスタンス（サーバでフォームの型として機能する）ごとに 1 つのモデルセッション Bean インスタンスが必要です。たとえば、フォームに表示する 100 個のネットワークノードがある場合は、それらのノードに相当する値の配列を返す getNetworkNodes() というメソッドを対応する EJB に用意します。

このアプローチでは、全体的なトランザクションの時間が短くなり、ネットワークの帯域幅が最小限で済みます。それに対して、GUI フォームでエンティティ EJB のファインダメソッドを呼び出し、100 個のネットワークノードの参照を個別に取り出すアプローチを考えてみてください。それらの参照の 1 つ 1 つで、クライアントではデータストアに戻ってデータを取り出さなければならないため、かなりのネットワーク帯域幅が消費され、パフォーマンスが許容できないほど低下する場合があります。

エンティティ Bean の設計

エンティティ Bean を使用した RDBMS データの読み書きは、貴重なネットワークリソースを消費します。ネットワークトラフィックは、WebLogic Server と基底のデータストアの間だけでなく、クライアントと WebLogic Server の間でも発生する場合があります。以下のアドバイスに従ってエンティティ EJB データを適切にモデル化し、不要なネットワークトラフィックを防止してください。

エンティティ Bean のホームインタフェース

コンテナは、コンテナにデプロイされる各エンティティ Bean のホームインタフェースの実装を提供し、クライアントが JNDI を通じてホームインタフェースにアクセスできるようにします。エンティティ Bean のホームインタフェースを実装するオブジェクトは EJBHome オブジェクトと呼ばれます。エンティティ Bean のホームインタフェースを通じて、クライアントは以下の処理を行うことができます。

create() メソッドを使用して、ホーム内に新しいエンティティオブジェクトを作成する
finder() メソッドを使用して、ホーム内の既存のエンティティオブジェクトを検索する
remove() メソッドを使用して、ホームからエンティティオブジェクトを削除する
特定のエンティティ Bean のインスタンスに固有でないホームメソッドを実行する

エンティティ EJB は大まかにする

システムのすべてのオブジェクトをエンティティ EJB としてモデル化しないでください。特に、ほんの数バイトの小さなデータをエンティティ EJB にすることは避けてください（ネットワークリソースのトレードオフが成立しないため）。

たとえば、スプレッドシートのセルなどは細かすぎるので、ネットワーク経由で頻繁にアクセスすることは避ける必要があります。ただし、インボイスの項目の論理的なグループやスプレッドシートのセルの集合は、ビジネスロジックが必要な場合は、エンティティ EJB としてモデル化できます。

追加のビジネスロジックをエンティティ EJB にカプセル化する

大まかなオブジェクトであっても、ビジネスロジックが不要であれば、エンティティ EJB としてモデル化するのは適切ではありません。たとえば、エンティティ EJB のメソッドの機能がデータ値の設定または読み込みだけの場合は、モデルかに RDBMS クライアントで JDBC 呼び出しを使用するか、またはセッション EJB を使用する方が適切です。

エンティティ EJB では、モデル化したデータに対してビジネスロジックをカプセル化します。たとえば、「プラチナ」と「ゴールド」の顧客で別々のビジネスルールを使用するバンキングアプリケーションでは、すべての顧客の口座がエンティティ EJB としてモデル化されます。その場合、EJB メソッドでは特定の顧客タイプのデータフィールドを設定するか、読み込むときに適切なビジネスロジックを適用できます。

エンティティ EJB のデータアクセスを最適化する

エンティティ EJB では、結局は、データストアのフィールドがモデル化されます。できる限りエンティティ EJB を最適化して、データベースアクセスを合理化し、最小限に抑える必要があります。特に、以下の点に注意します。

EJB データに対して結合の複雑さを制限します。
データストアでディスクアクセスが必要となる長時間の処理を避けます。
クライアントとデータストア間の往復回数を最低限に抑えるために、EJB メソッドでできる限り多くのデータが返されるようにします。たとえば、EJB クライアントでデータフィールドを読み込む場合は、一括処理の get/setAttributes() メソッドを使用してネットワークトラフィックを最小限に抑えます。

メッセージ駆動型 Bean の設計

メッセージ駆動型 Bean は、WebLogic JMS メッセージングシステムでメッセージコンシューマとして機能します。メッセージ駆動型 Bean の設計の詳細については、メッセージ駆動型 Bean の使い方.を参照してください。

EJB での継承の使用

共通のコードを共有する互いに関連する Bean のグループをビルドする場合は、継承を利用することをお勧めします。ただし、EJB の実装に適用される継承の制限に注意する必要があります。

Bean 管理のエンティティ EJB の場合、ejbCreate() メソッドでは主キーが返されなければなりません。Bean 管理の EJB クラスから継承するどのクラスも、Bean 管理の EJB クラスが返すものとは異なる主キークラスを返す ejbCreate() メソッドを実装することはできません。この制限は、新しいクラスが基本の EJB の主キークラスから派生する場合でも適用されます。また、この制限は、Bean の ejbFind() メソッドにも適用されます。

また、その他の EJB 実装から継承する EJB はインタフェースを変更します。たとえば、次の図は、リモートからアクセスできる新しいメソッドが派生 Bean で追加される状況を説明しています。

図2-1 リモートからアクセス可能なメソッドを追加する派生 Bean（BBean）

さらに、AHome.create() と BHome.create() では別々のリモートインタフェースが返されるので、BHome インタフェースは AHome インタフェースから継承することはできない、という制限もあります。特定のクラスに固有のメソッド、スーパークラスから継承するメソッド、またはサブクラスでオーバーライドされるメソッドを Bean で実装するために継承を使用することはできます。継承の例については、WebLogic Server 配布キットにあるクラス内の EJB 1.1 JavaBean のサブクラス Child のサンプルを参照してください。

デプロイされた EJB へのアクセス

WebLogic Server では、EJB のホームインタフェースとリモートで機能するリモートインタフェースの実装が自動的に作成されます。つまり、EJB と同じサーバにあるクライアントでも、リモートコンピュータ上にあるクライアントでも、デプロイされた EJB に同じようにアクセスできるということです。

EJB では、Java Naming and Directory Interface （JNDI）を使用して環境プロパティを指定する必要があります。さまざまなマシン、アプリケーションサーバ、コンテナなど、ネットワーク上のあらゆる場所にあるホーム EJB が含まれるように、EJB クライアントの JNDI ネームスペースをコンフィグレーションできます。

ただし、エンタープライズアプリケーションシステムを設計するときには、EJB とクライアントの間でネットワークを経由してデータを転送することの影響も考慮する必要があります。ネットワークのオーバーヘッドがあるため、Bean へのアクセスは、リモートクライアントからよりも「ローカル」クライアント（サーブレットまたは別の EJB）からの方がはるかに効率的です。リモートクライアントの場合は、データをマーシャリングし、ネットワーク経由で転送して、また復元しなければなりません。

EJB にローカルクライアントからアクセスする場合とリモートクライアントからアクセスする場合の違い

EJB へローカルクライアントからアクセスする場合と、リモートクライアントからアクセスする場合の違いは、Bean の InitialContext を取得する方法にあります。リモートクライアントでは、WebLogic Server InitialContext ファクトリを使用して InitialContext を取得します。通常、WebLogic Server のローカルクライアントでは、次の抜粋部分のように、getInitialContext メソッドを使用してこのルックアップを実行します。

コードリスト 2-1 ルックアップを実行するローカルクライアントのコード例

...

Context ctx = getInitialContext("t3://localhost:7001", "user1", "user1Password");

...

static Context getInitialContext(String url, String user, String password) {

   Properties h = new Properties();

   h.put(Context.INITIAL_CONTEXT_FACTORY,

      "weblogic.jndi.WLInitialContextFactory");

   h.put(Context.PROVIDER_URL, url);

   h.put(Context.SECURITY_PRINCIPAL, user);

   return new InitialContext(h);

EJB の内部クライアント（サーブレットなど）では、単純に、次のようなデフォルトのコンストラクタを使用して InitialContext を作成できます。

Context ctx = new InitialContext();

EJB インスタンスの同時アクセスに関する制限

データベース同時実行性は同時アクセスオプションのデフォルトかつ推奨設定ですが、複数のクライアントが排他的同時アクセスオプションを使用して、EJB に順次的にアクセスすることもできます。この排他的オプションを使用する場合、2 つのクライアントでエンティティ EJB の同じインスタンス（主キーが同じインスタンス）へのアクセスが同時に試行されると、2 番目のクライアントは EJB が利用可能になるまでブロックされます。データベースの同時実行性オプションの詳細については、排他的ロックサービスを参照してください。

ステートフルセッション EJB に同時にアクセスすると、RemoteException が発生します。ステートフルセッション EJB に関するこのアクセス制限は、EJB クライアントが WebLogic Server の内部にあるのかそれともリモートにあるのかに関係なく適用されます。ただし、allow-concurrent-calls オプションを、ステートフルセッション Bean インスタンスがメソッドの同時呼び出しを許可するように指定できます。

複数のサーブレットクラスがセッション EJB にアクセスする場合は、サーブレットクラスのインスタンスごとではなくサーブレットスレッドごとに独自のセッション EJB インスタンスを使用する必要があります。同時アクセスを避けるために、JSP またはサーブレットはリクエストスコープでステートフルセッションを使用できます。

EJB 参照のホームハンドルへの格納

EJB インスタンスの EJBHome オブジェクトを取得した後、クライアントでは getHomeHandle() を呼び出してそのホームオブジェクトへのハンドルを作成できます。getHomeHandle() では、後で同じ EJB インスタンスのホームインタフェースを取得するために使用できる HomeHandle オブジェクトが返されます。

クライアントでは、HomeHandle オブジェクトを別のクライアントに引数として渡すことができ、受け取り側のクライアントではそのハンドルを使用して同じ EJBHome オブジェクトへの参照を取得できます。[サーバ] ノードをクリックします。クライアントでは、HomeHandle をシリアライズし、後の使用を目的としてファイルに格納することもできます。

ファイアウォールを介したホームハンドルの使用

デフォルトでは、WebLogic Server ではその IP アドレスが EJB の HomeHandle オブジェクトに格納されます。このことは、特定のファイアウォールシステムで問題になる場合があります。ファイアウォールを介して渡されたホームハンドルを使用するときに EJBHome オブジェクトが見つからない場合は、次の手順に従います。

WebLogic Server を起動します。
WebLogic Server Administration Console を起動します。
左ペインで [サーバ] ノードを展開し、サーバを選択します。
右ペインでコンフィグレーション情報を確認します。
[チューニング] タブを選択します。
[許可されたリバース DNS] ボックスをチェックし、DNS の逆引き参照を有効にします。

DNS の逆引き参照が有効になると、WebLogic Server では IP アドレスではなくサーバの DNS 名が EJB ホームハンドルに格納されます。

トランザクションリソースの保持

通常、データベーストランザクションは、オンライントランザクション処理システムで最も貴重なリソースの 1 つです。WebLogic Server で EJB を使用する場合、トランザクションリソースはそのデータベース接続との関係によってさらに価値が高まります。

WebLogic Server では、1 つの接続プールを使用して複数の同時データベース要求に対応できます。接続プールの効率は、そのプールを使用するデータベーストランザクションの数と長さによって大きく左右されます。トランザクション非対応のデータベース要求の場合、WebLogic Server では同じ接続を別のクライアントが使用できるように接続の割り当てと割り当て解除を非常に敏速に行うことができます。ただし、トランザクション対応の要求の場合、そのトランザクションの間、接続はクライアントによって「予約状態」になります。

トランザクションをシステム上で最適な方法で使用するには、常に「内部から外部」という方法でトランザクションの境界を設定します。トランザクションの開始と終了ができる限りシステム（データベース）の「内部」になるようにして、必要な場合にのみ「外部」（クライアントアプリケーション方向）に向かうようにします。以降の節では、この規則について詳しく説明します。

トランザクションの管理をデータストアに許可する

多くの RDBMS システムは、オンライントランザクション処理（OLTP）トランザクション用の高性能ロックシステムを備えています。Tuxedo などのトランザクション処理（TP）モニタを利用すれば、RDBMS システムでは複数のデータストアにまたがる複雑な意志決定支援のクエリを管理することもできます。基底のデータストアにそのような機能がある場合は、できる限りその機能を使用します。RDBMS による自動的なトランザクションの境界設定を妨げないようにしてください。

EJB に対して Bean 管理のトランザクションの代わりにコンテナ管理のトランザクションを使用する

Bean 管理によるトランザクションの境界設定はなるべく使用しません。特殊な目的のために Bean 管理のトランザクションが必要となる場合以外は、WebLogic Server のコンテナ管理によるトランザクションの境界設定を使用してください。

Bean 管理のトランザクションが必要になるのは、以下のような場合です。

1 回のメソッド呼び出しで複数のトランザクションを定義する場合。WebLogic Server では、メソッドごとにトランザクションの境界を設定します。
注意: ただし、1 回のメソッド呼び出しで複数のトランザクションを使用する代わりに、メソッドを複数のメソッドに分け、それぞれがコンテナ管理のトランザクションを使用する方法をお勧めします。
複数の EJB メソッド呼び出しに「またがる」トランザクションを定義する場合。たとえば、あるメソッドを使用してトランザクションを開始し、別のメソッドでトランザクションをコミットまたはロールバックするステートフルセッション EJB を定義する場合です。
注意: EJB オブジェクトの機能についての詳しい情報が必要になるため、このような動作はできる限り避けてください。ただし、どうしても必要な場合は、Bean 管理によるトランザクションの調整を利用し、個々のメソッドに対するクライアントの呼び出しを調整する必要があります。

アプリケーションからトランザクションの境界を設定しない

通常、クライアントアプリケーションは長期間にわたってアクティブな状態を維持できるとは限りません。クライアントによってトランザクションが開始され、コミットする前にそのクライアントが終了すると、WebLogic Server で貴重なトランザクションと接続のリソースが失われてしまいます。さらに、クライアントがトランザクションの途中で終了しない場合でも、ユーザによるデータのコミットまたはロールバックに依存する場合はトランザクションが途中で終わってしまうこともあります。できる限り、トランザクションの境界は WebLogic Server または RDBMS のレベルで設定してください。

トランザクションの境界設定の詳細については、トランザクション管理の責任範囲を参照してください。

コンテナ管理の EJB には常にトランザクションデータソースを使用する

コンテナ管理の EJB で使用するために JDBC データソースファクトリをコンフィグレーションする場合は必ず、非トランザクションデータソース（DataSource）ではなくトランザクションデータソース（TXDataSource）をコンフィグレーションします。非トランザクションデータソースを使用すると、JDBC 接続は自動コミットモードで動作し、データベースに対する毎回の挿入および更新操作は、コンテナ管理トランザクションの一部として扱われず直ちにコミットされます。