トピック

概論To top of page

J2EE モジュールは、J2EE アプリケーションで最小の独立した導入単位です。『概念: J2EE の概要』で説明されているように、さまざまな種類の J2EE モジュールがあります。

J2EE モジュールの数とサイズは、J2EE アプリケーションの導入とテスト、コンポーネントのほかのアプリケーションでの再利用、システムのほかの導入構成への適応がどの程度容易かに影響します。

J2EE モジュールのアセンブルについては、『ガイドライン: J2EE モジュールのアセンブル』を参照してください。

J2EE モジュールの導入については、『ガイドライン: J2EE モジュールとアプリケーションの導入』を参照してください。

J2EE モジュールの識別To top of page

J2EE モジュールは、統合時に作成されますが、実装 (と実際は設計) で行われる決定を反映しています。J2EE モジュールは、通常、実装サブシステムをパッケージするのに使用されます。これは、一般に『成果物: 設計サブシステム』にマップされます。

J2EE モジュールは、緊密な関係がある EJB とそれらの EJB でのみ使用されるヘルパー・クラスを含む必要があります。通常、そのような関係は設計時に識別され、これらのクラスは設計サブシステムにグループ化されます。設計サブシステムの識別では、再利用、置き換え、複数の導入構成へのサポートの問題についてすでに検討済みである必要があります。しかし、モジュールを特定のノードに導入するよう割り当てると、設計の弱点が明らかになったり、設計サブシステム (または実装サブシステム、またはその両方) に対する変更が必要になったりする可能性があります。

J2EE モジュールを識別し、1 つのコンテナーを対象とする複数のコンポーネントを包含するようにします。Web コンポーネントは Web モジュールにパッケージされ、EJB コンポーネントは、EJB モジュールにパッケージされ、アプリケーション・クライアント・コンポーネントは、アプリケーション・クライアント・モジュールにパッケージされます。

複数のモジュールで使用される通常の Java クラスは、個々の J2EE モジュールにパッケージする必要があります。結果の JAR ファイルはそれらを必要とするモジュール内のクラス・パス参照 (または、そのようなクラス・パス参照の遷移閉包) に現れます。

要約すると、J2EE モジュールを識別するときは、各実装サブシステムに対して 1 つのモジュールを識別するところから開始してください。ただし、サブシステムが、別のコンテナーに導入されるコンポーネントを含み、各コンテナーに対して別のモジュールを定義する場合を除きます。

J2EE モジュールのモデリングTo top of page

J2EE モジュールは、<<EJB-JAR>>、<<JAR>>、または <<WAR>> のタイプを指定するステレオタイプを持つ UML 成果物として、実装モデルで表現されます。

コンポーネント (EJB やサーブレットなど) の J2EE モジュールへのコンポジションは、次のダイアグラムで示されるように、包含されるコンポーネントから、パッケージされるモジュールへの <<implements>> 依存を描くことによって、グラフィカルに表すことができます。<<JARInclude>> 依存も、アーカイブの Java パッケージ全体の包含を示すために作図することができます。

前後の本文を説明するダイアグラム

また、次のダイアグラムのように、アーカイブをパッケージとして表わし、パッケージに含まれるコンポーネントを示す方法もあります。

前後の本文を説明するダイアグラム

 

アーカイブにパッケージされるコンポーネントのモデリングに加えて、最終的にアーカイブの配置記述子に記述されるコンポーネントのプロパティーもモデリングできます。

EJB コンポーネント・プロパティーをモデリングする方法の例を次に示します。

前後の本文を説明するダイアグラム

上のダイアグラムは、BankEJB、LoanEJB、CustomerEJB という 3 つの EJB、および LoanManagerEJB を同一のモジュール EJBJARArchive1 にアセンブリーすることを表しています。EJB メソッド・プロパティー、セキュリティー・ロール、トランザクションのモデリングに注目してください。この例では、CustomerEJB は CustomerTrans で指定されたトランザクション・タイプ (「Required」など) の下で動作します。ソース・コードはロール名「user」を使用し、これは配置記述子で「Customer」ユーザー・ロールにマップされます。 また、別のロールに属するユーザーを呼び出す場合でも、LoanEJB および CustomerEJB のすべてのメソッドは「Customer」のクリデンシャルで実行されます。同様に、LoanManagerEJB メソッドは、「Admin」として実行されます。最終的に、BankEJB のユーザーからアクセスできるメソッドはありません。

Web コンポーネント・プロパティーをモデリングする方法の例を次に示します。

前後の本文を説明するダイアグラム

上のダイアグラムは、サーブレットの Web モジュールへのアセンブリーを示しています。セキュリティー・ロールと制約のモデリング、「Customer」タイプのユーザーが showresults サーブレットのメソッドを実行する場所、WebSecurityContraint1 のプロパティーで定義されたセキュリティー制約の対象に注目してください。

J2EE モジュールのノードへの導入は、配置モデルで表すことができます。 モジュールから導入ノードへのマッピングのモデリングについて詳しくは、『ガイドライン: J2EE アプリケーションの分散性の記述』を参照してください。

配置記述子To top of page

各 J2EE モジュールは、J2EE 標準の配置記述子を含み、さらに、ベンダー固有の記述子が存在する場合があります。配置記述子のさまざまな種類については、『概念: J2EE の概要』に記載されています。通常、標準の J2EE 配置記述子には、主に設計と実装の決定が取り込まれます。RUP で「導入の決定」とされる決定は、ベンダー固有の配置記述子に取り込まれます。例えば、コンポーネントを実行するノード、特定のノードに対するコンポーネントの構成方法などです。

配置記述子には、次の 2 つの目的があります。

  • 設計の決定をコンテナーへ伝える手段。例えば、セッション EJB に対する配置記述子には、セッション EJB がステートフルかステートレスかの状態を示す「session-type」があります。これは、設計とコーディングで一貫性を保つ必要があります。単に配置記述子でこれを変更することはできません。
  • コードの再コンパイルをせずに振る舞いをカスタマイズする手段。例えば、どのロールが特定のメソッドの呼び出しを承認されているかを定義するために、配置記述子を使用できます。これは、EJB のコードを変更しなくても変更できます。

配置記述子の内容は、J2EE モジュールの作成時と、J2EE アプリケーションへのアセンブル時に設定されます。J2EE モジュールのアセンブルについて詳しくは、『ガイドライン: J2EE モジュールのアセンブル』を参照してください。J2EE アプリケーションのアセンブルについて詳しくは、『ガイドライン: J2EE アプリケーションのアセンブル』を参照してください。

 



Rational Unified Process   2003.06.15