ガイドライン: Enterprise JavaBeans (EJB) の設計
トピック
概論
このガイドラインでは、EJB の設計を中心に説明します。EJB の識別やモデリングの方法など補足のガイダンスは、『ガイドライン: EJB』で説明します。
特定の種類の EJB の設計についての固有のガイダンスは、次のガイドラインで提供されます。
ローカルおよびリモートのインターフェースは、『概念:
J2EE の概要: Enterprise JavaBeans』で説明されています。
ローカル・インターフェースは、リモート・インターフェースより効率的です。ローカル・インターフェースは、EJB に対して常にローカルな特定のクライアントが存在する場合に提供する必要があります。
このトピックに関するより具体的なガイダンスは、各種類の EJB ついてのガイドラインで提供されます。
パラメーターの引き渡し
性能は、リモート・コールの数と各コールで転送されるデータ量によって大きく影響されます。これは、リモート・クライアントが要求するすべてのデータを返す特別なコールを提供することで対処できます。例えば、関連するエンティティー Bean のセットに対するファサードとして作用するセッション Bean は、データを複数のエンティティー Bean から直列化可能な値オブジェクトにコピーし、このデータを単一のリモート・コールで返すことができます。これについて詳しくは、「Core
J2EE Patterns - Value Object Pattern」 ([ALU01]) に記述されています。
これはインターフェースの汎用性をできる限り保ちつつ、大量の不要なデータを送信しないよう配慮してバランスを取る必要があります。
トランザクションの区切りとは、トランザクションの開始、コミット、アボートを指します。
EJB 設計者は、Bean 管理によるトランザクション区切りとコンテナー管理によるトランザクション区切りのどちらを実装するか決定する必要があります。
アプリケーションによって実行されるビジネス論理のシーケンスで、トランザクション境界の位置を決定する必要があります。詳しくは、『作業: ユース・ケース設計、トランザクションのモデリング』および『概念: J2EE の概要』の『トランザクション管理 』というタイトルのセクションを参照してください。
可能な限り、コンテナー管理のトランザクションを使用してください。こうするとコードがシンプルになり、開発者はアプリケーションのビジネス論理に集中できます。
一般に、トランザクションの粒度が大きいほど全体の性能は上がります。EJB へのメソッド・コールのシーケンスを作成するとします (例えば、getX、getY、setZ)。デフォルトでは、メソッドごとに新しいトランザクションで実行され、性能は低下します。これらを同一のトランザクションで呼び出すために別のメソッドを作成し (例えば、セッション EJB のメソッド processXYZ)、呼び出し先のメソッドのトランザクション属性を Required に設定すると、それらは既存のトランザクション (つまり、セッション Bean 内の呼び出し側のメソッドのトランザクション) を使用します。
基本的な EJB のセキュリティーの概念は、『概念:
J2EE プラットフォームの概要 - セキュリティー』を参照してください。
セキュリティー・ロール とメソッド・パーミッション を定義することによって EJB のセキュリティー要件を定義します。セキュリティー・ロールとメソッド・パーミッションは、 EJB の配置記述子で定義されます。セキュリティー・ロールをユーザーやユーザー・グループにマップするのは、サーバーの責務です (管理ツール使用)。
セキュリティー・ロールは、単一の名前でグループ化された類似のタイプのアクティビティーのセットを定義します。メソッド・パーミッションは、特定のセキュリティー・ロールにメソッド呼び出しのための権限を付与します。例えば、エンティティー EJB Employee があり、メソッド setAddress、setSalary などを持つとします。manager というセキュリティー・ロールは、メソッド setAddress および setSalary のメソッド・パーミッションを付与され、employee というセキュリティー・ロールは、メソッド setAddress のメソッド・パーミッションを付与されます。
状況によっては、配置記述子で宣言的なメソッド・パーミッションを使用するアプリケーションのセキュリティー要求のサポートはできないことがあります。
この場合、javax.ejb.EJBContext インターフェースの getCallerPrincipal メソッドと isCallerInRole メソッドを使用します。
J2EE 1.4 (厳密にいうと EJB 2.1) 以降、ステートレス・セッション Bean とメッセージ駆動型 Bean では、EJB Timer Service によって、バッチ処理のスケジュールにタイマーを使用できます。
EJB Timer Service によって、時間ベースのイベントのスケジュールへのコールバックが可能になります。コンテナーは、時刻指定されたイベントに対する信頼性の高いトランザクションによる通知サービスを提供します。タイマー通知のスケジュールには、特定の時刻、一定時間の経過後、一定の時間間隔の設定が可能です。
Timer Service は、EJB コンテナーによって実装され、Enterprise Bean は EJBContext インターフェースを介してこのサービスにアクセスできます。
EJB Timer Service は、あまり高精度ではないタイマー通知サービスであり、アプリケーション・レベルのプロセスのモデリングに使用するために設計され、リアルタイムのイベントのモデリングを対象とはしていません。
直接アクセスとエンティティー Bean
永続データ用のエンティティー Bean を使用すると、永続データのアクセスに標準的で多機能のメカニズムが提供されます。Bean 管理による持続性またはコンテナー管理による持続性を使用する決定をすると、クライアントから隠蔽され、設計に若干の柔軟性が加わります。EJB では、トランザクション、リソース管理、ロード・バランシングや、J2EE 環境で提供されるほかの機能を活用できます。
しかし、エンティティー Bean を使用せず、データベースに直接アクセスしたい場合もあります。例えば、データには常に単一のクライアントから読み取り専用でアクセスする場合、 データベースに直接アクセスしたほうが効率的です。
データベースに直接アクセスする場合 (例えば、ステートレス・セッション Bean から)、すべてのデータベース・アクセスをデータ・アクセス・オブジェクト・クラス内にカプセル化します。これは、基盤となるストレージ・メカニズムを隠蔽し、カプセル化する Java クラスであり、データ・ソースへのインターフェースが変更された場合に、変更の影響を受けません。
詳しくは、「Core J2EE Patterns - Data Access Object Pattern」 (参考資料 ALU01) を参照してください。
事実上、すべての EJB コンテナーは、クライアント間で作成済みの接続のセットのプーリングと共有化をサポートします。これらの接続は、必要に応じて EJB に割り当てられます。EJB には、作成や初期化という労力をかけずに接続を確立できるという利点があります。接続はプールに戻されて、リサイクルされます。プールのサイズは、使用された接続をリサイクルできるだけの十分な大きさにする必要があります。
コンテナー管理による持続性を持つエンティティー Bean の場合、コンテナーがデータベース接続とデータベース接続プールへのアクセスを管理します。
Bean 管理による持続性を持つエンティティ Bean (または、データベースにアクセスするセッション Bean または メッセージ駆動型 Bean) の場合、開発者が接続ルーチンのコーディングを行わなければなりません。次のガイドラインを適用します。
- データベース・アクセス・コードは DAO クラス内で独立させます。
- データベースの実際の URL をハードコーディングしないでください。代わりに、Java Naming and Directory Interface (JNDI) ルックアップを使用して取得できる論理名を使用します。こうすると、複数アプリケーションで、異なるデータベース名を使用して、EJB を再利用できます。
- 通常は、接続プールを使用し、必要な期間のみ接続を保持してください。例えば、エンティティー Bean が、接続、テーブル行の更新、切断の処理を行うとします。この場合、多くの EJB で同じ接続を共有できます。JDBC 仕様には、接続プーリングのサポートも含まれています。
|