java - Java EE アプリケーションのパッケージ化について正しいこと

Question

Beginning Java EE 6 with GlassFish 3を読んでいて、Java EE アプリケーションのパッケージ化について何が正しいのか混乱しています。

EJB Lite は、war または jar ファイルに直接パッケージ化できます。完全な EJB 仕様 (リモート インターフェイス、JMS、非同期呼び出しなど) を使用する必要がある場合は、war ではなく jar にパッケージ化する必要があります。

これは何を意味するのでしょうか？Glassfish で WAR としてパッケージ化されたアプリケーションをデプロイすると、すべての Java EE サービスが提供されませんか? もしそうなら、私は何が欠けていますか。

3.1 で導入された新しいプロファイル EJB Lite は、完全な仕様のサブセットとなることを意図しており、すべてを実装したくない実装者を対象としており、3.1 から WAR に EJB をパッケージ化し、指定されたサービスを使用できることを理解しています。 EJB Lite 仕様による。しかし、WAR をフルスペックのコンテナーにデプロイすると、JAR を作成した場合と同じようにすべてが提供されるはずですか? WAR は JAR の単なる別名ではありませんか? 区別は、パッケージ化されている方法ではなく、実際に何をサポートしているのでしょうか?

誰かが明確にすることができますか。

Answer 1

EJBロジックBeanをJARファイルに入れる動機は、ビジネスロジックとビューロジックの分離にあります。現時点では、私が知る限り、すべてのEJBをJARにパッケージ化してから、このJARをWARと組み合わせてEARにする必要はありません。

しかし...EJBはビジネスロジックにのみ集中することになっているため、EJBを別のアーカイブにパッケージ化することは理にかなっています。一方、WARは、GUIをユーザーに表示することに関連するすべてのもののアーカイブであるため、JSP、フェイスレット、画像、CSSファイル、およびJavaScriptライブラリーです。WARファイルは、WEB-INF\classesフォルダー内に一連のクラスを含めることができ、。内に独自のライブラリーを含めることもできますWEB-INF\lib。とにかく、WARファイルはファイルである必要はありません。WARファイルは展開されたWARになる可能性があり、基本的にはアーカイブにあったものと同じ構造のディレクトリになります。

その重要な側面は、クラスローダー階層でのクラスローダーの分離です。WARモジュールはEJBアーカイブ（JAR）のリソースにアクセスでき、EJBモジュールはEARファイル自体のリソース（ライブラリ）を参照してアクセスできます。他の方向、具体的にはEJBモジュールからのWARリソースへのアクセスは禁止されています。そして、それは、開発者（プレッシャーの下で作業している）がそれらの懸念を混ぜ合わせてスパゲッティコードを作成することを防ぐので、設計による方法です。ビジネスロジックは、Java SEクライアント、さまざまなWebモジュールクライアント、JAX-RS、またはSOAベースのソリューション内で再利用できるため、ビューロジックから分離する必要があります。ビジネスロジックにJSFまたはサーブレット間に依存関係がある場合、JavaSEデスクトップソリューションでそれらを使用することは不可能です。

したがって、多くのJARファイルとWARファイルで構成されるEJBアーカイブの構造を持つ必要はないかもしれませんが、これはベストプラクティスであり、そのルールに違反することに注意して注意する必要があります。