2

Java EE 5 で開発された大規模なソフトウェア システムのビルド システムとディレクトリ構造を設計中です。ビルド システムは ant を使用して実装されます。

テーマごとにグループ化された複数の異なるサービスがあります。各サービスは、Web サービスまたは EJB のいずれかを提供します。各サービスは、専用のアプリケーション サーバー クラスターで実行されます。したがって、複数のクラスターがあり、これらのクラスターの一部は、トピックによって論理的にグループ化できます。

一般的な定義と例を読みましたが、Java EE の用語についてはまだ混乱しています。

  • Java EE アプリケーションとは では、EAR ファイルの内容は何でしょうか?
  • Java EE プロジェクトとは? (この用語は、Netbeans だけでなく、Java Blueprints Guidelines Project Conventions for Enterprise Applications でも使用されています)

すべての EJB および WAR-module-package-files を 1 つの EAR に配置して、この 1 つの EAR に完全なシステムを含める必要がありますか?

それとも、これらのサービスは論理的にのみグループ化されており、技術的にはグループ化されていないという事実にもかかわらず、サービスの各グループを 1 つの EAR に入れる必要がありますか?

それとも、サービスごとに個別の EAR をアセンブルしますか。つまり、ほとんどの場合、単一の EJB jar ファイルのみを含み、場合によっては EJB と WAR ファイルを含みますか?

それとも、アプリケーションの概念を無視して、EJB ファイルと WAR ファイルを構築するだけで、アプリケーション サーバー クラスタごとに 1 つのデプロイメント ファイルしか持たないのでしょうか?

私の主な質問は、EAR ファイルをパッケージ化する利点は何ですか?

現時点では、必要なのは EAR-EJB と WAR ファイルだけで、さらに ant-build-system のネストされたサブプロジェクトの概念とソースのディレクトリ構造が必要ですか?

編集：答えてくれてありがとう！耳にパッケージ化されたアプリケーションは、かなり原子的なサブシステムのように思えます。したがって、ネストされたサブプロジェクト構造 (論理的にのみ、ビルド システムとソースのディレクトリ構造でのみ可視) とかなり大量の EAR があり、それぞれにほとんど 1 つの ejb-jar しか含まれていないと思います。および/または war モジュールと単一のサービスの実装 (単一のアプリケーションサーバークラスターにデプロイされます)。

4

3 に答える 3

1

各 EAR に何を入れるかは、組織的および技術的な問題によって左右されると思います。

EAR の最も重要な技術的役割は、ランタイム環境のクラスローダー ルートだと思います。これは通常、さまざまなバージョンのライブラリと独自のクラスをさまざまな EAR にデプロイできることを意味します。これは、競合する可能性のあるライブラリを使用して 1 つの物理コンテナーが複数のアプリケーションにサービスを提供できるようにするため、コンテナーのルート クラスパスをかなり空 (またはコンテナー ベンダーから提供されたもの) に保つ必要があることを意味します。これは、共通のコード ベースを使用して多数の異なるアプリケーションを開発している場合に朗報です。互いに混乱することなく、多数のプロジェクトを同じサーバー ファームにデプロイできます。

通常、EAR より小さなソフトウェア ユニットをデプロイすることはありません。各 EAR は、多かれ少なかれ完全に自己完結型です。私は通常、所有する組織がアプリケーションまたはサブシステムと見なしているものを、これらのコンテンツに反映させます。通常、同じコンポーネントを複数の EAR にパッケージ化できます。

于 2009-01-03T14:23:20.090 に答える
1

ここにはたくさんの質問があります。

Java EE プロジェクトは、Java EE テクノロジーを使用する EAR または WAR デプロイメントです。JSP を使用した WAR とリレーショナル データベースの JDBC アクセスがある場合、それは Java EE プロジェクトです。当初の意図は、EAR ファイルは「エンタープライズ」であり、それは EJB を意味するというものでした。EAR ファイルには、EJB、WAR、JAR、エンチラーダ全体が含まれます。

サービスの観点からの考え方は少し異なります。メンテナンスが必要な場合は、パッケージ化されたコンポーネントをまとめてダウンおよびアップする必要があるため、展開は慎重に検討する必要があると思います。

そのため、サービスをどのようにパッケージ化するかを慎重に検討してください。IMO、それはすべてかゼロかの包括的な答えではありません。サービスが何を行っているか、それらをどのように組み合わせて使用​​するかを調べて、それらをパッケージ化してデプロイする方法を決定する必要があります。

于 2009-01-03T14:11:17.463 に答える
0

論理的および組織的な考慮事項の両方が関係します。各EARには、特定の機能に関連するすべての要素が含まれます。各EARは自己完結型であり、1つ以上のコンテナーにデプロイできると常に想定できます。私がいつも従ってきた典型的なアプローチは、各EARに1つ以上のjarファイルとwarを含めることです。各戦争または瓶には、いくつかの重要なコンポーネントまたは関連するコンポーネントのセットが含まれています。EARは、アプリケーションのコンポーネントとWebアプリを含むエンタープライズアプリケーションを表します。例として、私が関わった支払い処理システムがあります。EARには、支払い処理システムの実行に必要なすべてのものが含まれていました。これには、半ダースの瓶と3つの戦争が含まれていました。各jarは、いくつかの機能または機能の論理グループを表しています。それぞれの戦争はウェブアプリを表しています。瓶の例」

  • コア機能のための瓶
  • ejbs用のjar
  • 私たちの高度な金融数学の作品のための瓶
  • セキュリティピースなどのjarファイル。複数のjarファイルがあるかどうかは、さまざまな人がさまざまなピースを開発したため、さまざまなEclipseプロジェクトで作業し、必要に応じてそれらをすべて組み合わせたという事実によって決まりました。チームや状況に合ったルールはありません。
于 2011-05-21T08:08:54.120 に答える