目的

EJB 設計の目的は、Enterprise JavaBeans (EJB) を作成する設計クラスを識別し特定することです。  

作業: クラス設計』と同様、目的は次のとおりです。

  • あいまいなところがなく EJB を実装するために十分な情報を確実に提供すること。
  • EJB に関連した機能外要求を扱うこと。
  • EJB が使用する設計メカニズムを含むこと。特に、設計されている EJB の種類に固有の設計メカニズムを含むこと。
役割:  設計者 
頻度:  方向付けの後、すべて反復の間に繰り返し発生します。作業のプロトタイプが存在する場合、方向付けで発生する可能性があります。
ステップ
入力とする成果物    結果となる成果物:   
ツール・メンター:   
詳細情報:   

ワークフローの詳細:   

EJB の識別 ページの先頭へ

EJB を分析クラスか初期の設計モデル要素、またはその両方から識別してください。EJB は、設計パターンの一部として識別されます。パターンを組み込むと、この作業の手順 (新しいクラス、操作、属性、関係の追加) の多くが効率的に実行されますが、パターンが定義するルールが適用されます。J2EE パターンの例は、「Core J2EE Patterns」 (参考資料 ALU01) を参照してください。

重要な決定事項がいくつかあります。

  • 「ビジネス論理」を EJB と 非 EJB クラスにどのようにマップするか - 必要なクラスの種類と数。例えば、持続する必要がある「状態」情報を持つオブジェクトを表現するクラスは、エンティティー EJB にマップする必要があります。サービスを実行し、自身の永続データを持たないクラスは、セッション EJB またはメッセージ EJB にマップする必要があります。
  • セッション Bean の場合、ステートフル・セッション Bean またはステートレス・セッション Bean を使用するかしないかの決定 (ステートフルとステートレスのいずれを使用するかの決定は、セッション Bean と、ほかの識別されるクラスの責務を識別する重要な部分です)。ステートレス・セッション Bean のほうが、より効率的です。なぜなら、インスタンスがアクティビティーの特定のセッションと結び付いておらず、不連続の要求間で共有できるからです。さらに、EJB を Web サービスのエンドポイントとして使用する場合は、ステートレスでなければなりません。
  • Bean から使用したり、Bean を組み込んだりする必要がある設計パターンとメカニズム。特定のパターンとメカニズムの使用が、識別される EJB の数と種類に影響します。
    メモ:
    ソフトウェア・アーキテクトは、通常どのパターンとメカニズムをプロジェクトで使用する必要があるかを決定し、設計者 は、ガイドラインに従います。

EJB の識別について詳しくは、『ガイドライン: EJB の識別』を参照してください。

属性の定義 ページの先頭へ

EJB 用の属性を識別してください。

特に、各エンティティー Bean に対して、その永続属性と主キーを識別してください。

エンティティー EJB 属性の定義について詳しくは、『ガイドライン: エンティティー Bean の設計』を参照してください。

操作の定義 ページの先頭へ

この手順は、セッション Bean とエンティティー Bean に適用されます。メッセージ駆動型 Bean には適用されません。

操作の設計は、『作業: クラス設計』の、特に操作の定義の手順でカバーされます。

EJB についての主な決定事項には、次のものがあります。

  • 特定の操作をローカルまたはリモート・クライアントから使用可能にする必要があるかどうか。一般に、EJB にはローカルまたはリモート・コンポーネント・インターフェースのみがあります。J2EE 1.3 以降のバージョンで作業をしている場合は、標準的な実践原則は、すべてのリモート・クライアント・アクセスを、セッション EJB を介して扱うことです。そのセッション EJB はローカル・コンポーネント・インターフェースを介して同一の JVM でエンティティー EJB を操作します。
  • 属性を get/set 操作に対する値オブジェクトにグループ化する方法。エンティティー EJB に対してリモート・インターフェースを提供する場合、Bean のデータのスナップショットを一度に 2 つの方向に渡すために使用する「値オブジェクト」クラスを定義するのが最良の方法です。これは、個々の Bean フィールドに対して get/set コールを繰り返すことと比べると、ネットワークのオーバーヘッドが最小限になります。詳しくは、「Core J2EE Patterns」 (参考資料 ALU01) を参照してください。

EJB 操作の定義について詳しくは、『ガイドライン: EJB の設計』を参照してください。

振る舞いの定義ページの先頭へ

クラスの振る舞いの設計は、『作業: クラス設計』でカバーされます。

EJB を最初に識別した時点で EJB メカニズムが指定されていない場合、使用する EJB メカニズムの識別は、EJB の設計の重要な手順です。決定事項として、次のものがあります。

  • トランザクションを使用するかどうか。使用する場合、Bean 管理のトランザクションとコンテナー管理のトランザクションのどちらを使用するか。
  • セキュリティー・ポリシーの提供が必要かどうか。必要な場合、どのポリシーか、Bean が提供する各メソッドとどのように関連するか、どのユーザー「ロール」を各ポリシーと関連付けるのか。設計者は、承認の使用がプログラム的か宣言的かも決定する必要があります。
  • エンティティー Bean の場合、コンテナー管理による永続性、または Bean 管理による永続性を使用するかどうか。Bean 管理による永続性はより柔軟性がありますが、開発者が担当する部分の作業も多くなります。コンテナー管理の永続性では、多くの作業が自動化されますが、柔軟性は低くなります。

これらのメカニズム決定の多くはソフトウェア・アーキテクトによってプロジェクト・レベルで決定され、その場合設計者はプロジェクト・ガイドラインに従います。

EJB の振る舞いの一部はメソッドによって提供される一方、追加の振る舞いは EJB コラボレーションによって提供されます。EJB の間の参照を作成できます。CMP 2.0 エンティティー EJB の場合は、それらの間にコンテナー管理関係 (CMR) を作成できます。

EJB の振る舞いの設計に関する詳細なガイダンスは、『ガイドライン: EJB の設計』で提供されます。

サポート・クラスの設計 ページの先頭へ

この手順は、すべての EJB に適用されます。

ここで、EJB 設計をサポートする追加の設計クラスが識別されます。共通のサポート・クラスは、主キー・クラス (PK クラス)、データ・アクセス・オブジェクト (DAO) と値オブジェクト (VO) を含みます。 DAO は BMP エンティティー EJB の実装に使用され、データベース操作の詳細を隠蔽します。これによって、アプリケーションをデータベース・サーバーから別のデータベース・サーバーへ移植するのが容易になります。VO は、データを透過的にアクセスし、データ値をコンポーネント間で効率的な方法で引き渡すのに使用されます。

EJB 間の関係と EJB 間のコンテナー管理による関係 (CMR) を作成できます。

アプリケーション・パターンによって、サポートするクラスが追加で定義される可能性があります。 J2EE パターンについて詳しくは、「Core J2EE Patterns」 (参考資料 ALU01) を参照してください。

クラスの設計について一般的なガイダンスは、『作業: クラス設計』を参照してください。



Rational Unified Process   2003.06.15