ガイドライン: セッション Bean の識別
トピック
概論
このガイドラインでは、セッション Bean の識別を中心に説明します。セッション Bean に関する補足ガイダンスは、『ガイドライン: セッション Bean』で説明します。EJB に関する一般的なガイダンスは、『ガイドライン: Enterprise JavaBeans (EJB)』で説明します。
セッション Bean の識別
セッション Bean は制御ロジックを提供するように設計されるので、特にこの制御ロジックにクライアントとの会話が含まれる場合、制御クラスはセッション Bean の有力な候補になります。セッション Bean は、ビジネス層でオブジェクトのセットに対する Facade として識別される場合が多くあります (以下の『セッション Facade パターン』を参照してください)。また、J2EE 1.4 以降では、ステートレス・セッション Bean を使用して Web サービスを実装できます。
J2EE 1.3 で作業をしている場合、標準的な方法は、すべてのリモート・クライアント・アクセスを、セッション EJB を介して扱うことです。セッション EJB は、ローカル・コンポーネント・インターフェースを介して同一の JVM でエンティティー EJB を操作します。
セッション Bean のモデリング
『ガイドライン: Enterprise JavaBeans (EJB) の識別』を参照してください。
ステートフルとステートレス
セッション Bean には、ステートフルとステートレスの 2 種類があります。 セッション Bean の識別には、その責務を定義することが含まれます。責務の 1 つは、コール間のクライアント状態を維持することです。
ステートフル・セッション Bean は、クライアントと EJB コンテナーの間の会話に関する状態情報を保持します。
ステートフル・セッション Bean インスタンスは、クライアントとの会話の期間にのみ存在します。通常の場合、ステートフル・セッション Bean は、クライアントに対してこのデータを使用してサービスを実行します。ステートフル・セッション Bean が提供するサービスは、ほかのビジネス・オブジェクト (セッション Bean とエンティティー Bean) の相互作用を調整することがあります。例えば、購入する対象が入っているショッピング・カートは、クライアントがアプリケーションと相互作用しているときの情報を保持するので、ステートフル・セッション Bean を使用して実装されることがあります。ステートフル・セッション Bean は特定のクライアントに割り振られるので、ステートレス・セッション Bean よりも多くのシステム・リソースを消費します。これは、クライアント状態を保持するという利点のためです。一般に、ステートフル・セッション Bean の「パッシブ化」(ディスクへの書き込み) と、必要に応じたそれらの再アクティブ化によって、コンテナーはこれらのリソースを管理します
ステートレス・セッション Bean は、クライアントと EJB コンテナーの間の会話に関する状態情報を保持しません。
「ステートレス」とは、具体的にはクライアント会話状態がないことを意味します。したがって、ステートレス・セッション Bean は、任意のクライアントが使用できるデータベース接続などほかの種類の状態を含むことができます。
ステートレス・セッション Bean が実行する汎用サービスは、以前のメソッド・コールからのクライアント状態データを使用しないで、必要なすべての入力を現在のメソッド・コール内のパラメーターとして受け取ります。または、メソッド・コール中にほかのソースから (例えば、エンティティー Bean から、または JDBC を介してデータベースにアクセスすることにより) データを取得します。通常の場合、ステートレス・セッション Bean は、準備完了プールから抽出され、着信要求を処理するために必要に応じてディスパッチされます。すべてのインスタンスは同等であるため、ステートレス・セッション Bean はクライアントについて知る必要はありません。これにより、パフォーマンスとスケーラビリティーを向上させることができます。インスタンスをアクティビティーの特定のセッションに「関連付ける」のではなく、隣接しない複数の要求によって共有できるため、ステートレス・セッション Bean のほうがより効率的です。
通常は、クライアントとの会話の性質に最も適したセッション Bean の種類を選択してください。
ステートフル・セッション Bean をステートレス・セッション Bean 内に強制的に適合させる戦略もあります。例えば、クライアント上にクライアント状態を格納し、呼び出しごとに再送信する方法や、メソッド呼び出しごとにデータベースにクライアント状態を格納したり、データベースからクライアント状態を検索したりする方法があります。しかし、これらの戦略は、ネットワーク・トラフィックとデータ・アクセスのオーバーヘッドによって、実際にはスケーラビリティーを低下させることがあります。
Web サービスを実装するためにセッション Bean を作成する場合は、JSR 1.3 API 仕様での定義に従ってステートレス・セッション Bean を使用する必要があります。
クライアント状態を設計するための別のアプローチについては、『ガイドライン: J2EE アプリケーションの状態の設計』を参照してください。
セッション Facade パターン
セッション Bean は、一般的に、ビジネス層のオブジェクト間の相互作用をカプセル化する Facade として使用されます。
セッション Bean は、この複雑さを抽象化する役割を果たし、クライアントに対してより単純なインターフェースを提供します。このパターンについて詳しくは、『J2EE パターン - セッション Facade パターン』([ALU01]) を参照してください。
例えば、エンティティー Bean 間の結合を最小限にするために、エンティティー間の Bean ロジックを抽出してセッション Bean 内に移動するのは、一般的にお勧めできる方法です。セッション Bean Facade がリモート・クライアントへのアクセスを提供するため、エンティティー Bean にはローカル・インターフェースを介してアクセスできます。密接に関連する複数のエンティティー Bean が存在する場合は、このアプローチが最も効果的です。
Web サービス・エンドポイント
既に説明したように、ステートレス・セッション Bean を使用して Web サービスを実装できます。このような Bean は、サービス実装 Bean とも呼ばれ、次の要件を満たす必要があります。
- デフォルトの public コンストラクターを持つ。
- サービス・エンドポイント・インターフェースで宣言されるすべてのメソッドを実装、ビジネス・メソッドは public であり、final や static ではない。
- ステートレスである。
- クラスは public であり、final や abstract ではない。
セッション Bean を使用した Web サービスの実装について詳しくは、EJB
2.1 および JSR-109
の仕様を参照してください。
|