JavaEE 6 WARとEARでのEJBのパッケージ化
新しいプロジェクトを開始し、WAR対EARでのEJBのパッケージ化の長所と短所を知りたい。
EJBがWARにある場合でもJNDIは機能しますか？効率？等。？
ありがとう。
別のJARにEJB Beanを配置する重要な動機は、古くからあるビジネスロジックとビューロジックを分離することです。
EJBはビジネスロジックのみに集中することになっているので、EJBを別のモジュールに入れることは理にかなっています。
これは、従来のJava Enterprise Archiveが促進するものとまったく同じです。EJBBeanはEJB moduleを表すJARファイルに入りますが、Web関連のアーティファクト（ファセットレット、バッキングBean、ユーティリティコード） ）Web moduleを表すWebアーカイブ（WAR）ファイルに移動します。WARは実際にはファイルである必要はありません。いわゆる展開形式では、これらは単なるディレクトリです。
この分離の重要な側面は、これらの2つのモジュールがクラスローダー階層を介してisolatedであることです。 Web moduleはEJB moduleからリソース（通常はBean）にアクセスでき、EJB moduleはEARアンブレラ全体で定義されたリソース（通常はライブラリ）を参照できます。他の方向は不可能です。具体的には、EJB moduleはWeb moduleで定義されたリソースにアクセスできません。
この強制は慎重に行われます。
ビジネスロジックは、ビューテクノロジから完全に独立している必要があります。この分離を適用することで、開発者が偶然に、または圧力がかかっているときにこれらの懸念を混同することを防ぎます。この分離の利点は、ビジネスロジックを他の人が簡単に使用できることですJava SEクライアント、Webモジュールクライアント、JAX-RSクライアントなど）。ビジネスロジックに誤ってJSFまたはサーブレットの依存関係があった場合、Java SEクライアントから使用するのは非常に難しいでしょう。
これを、スクリプトレットの使用を許可しないFaceletsと比較してください。これにより、Faceletsがクリーンに保たれ、コンポーネントのレイアウトとマークアップに専念できるようになります。もう1つの例えは、インターフェイスへのコーディングです。これにより、コントラクトが実装から分離されます。
したがって、別個のEJBモジュールを持つことは、実際にはベストプラクティスです。しかしながら...
小規模なプロジェクトの場合、このように分離する必要はないかもしれません。また、初心者のプログラマーにとっては、どこに行く必要があるかという構造を理解するのが難しいかもしれません。したがって、必須の分離を削除すると、経験の浅い開発者がJava EEから始めるのが簡単になります。これにより、Java EEとその後getレイヤー化のアイデア、彼らはとにかくEJB moduleを導入することを選択できます。
これまでのところ、これは私が得たものです。
WARのEJB
長所：
開発と展開が簡単
セッションBeanメソッドは、REST @Pathアノテーション付きのサービスとして公開できます。 こちら を参照してください。
短所：
JNDIルックアップはサポートされていないため、別のアプリケーションクライアントからRMIを実行できないと思います
Arjanが指摘したように、設計にはモジュール性が欠けています。
覚えておく必要があるのは、WAR内のEJBはEJB Liteの一部であるということです。これは、EJBコンテナによって提供される最小限のサービスでアプリケーションを実行するための素晴らしい取り組みです。 EJBコンテナによって提供されるすべてのサービスが常に必要なわけではないからです。
したがって、WARまたはEARでのEJBのパッケージ化の長所と短所について疑問がある場合は、必要なサービスの量を検討する必要があります。
HTH。
私は現在、EJB 3.1認定のガイドを勉強しており、そのすべての機能をテストする必要があります。そして、戦争を使用するとき、すべてが利用可能です。
これは、WARパッケージとは非常に異なるEJB Liteです。
Webプロジェクトに含めることができるejb jarを使用して、いくつかの論理モジュール性を持つことができます。ただし、すべてのモジュールが同じ環境（jndi）を共有しているため、名前の衝突が発生する可能性があります。 EARプロジェクトでは、各モジュールに独自の名前空間があります。
私はこのトピックについていくつかの実験を行い、その結果に本当に驚いた。私の結論では、WARでEJBを使用することはありませんでした。 EJBコンテナーに任せましょう。誰かが最良でエラーのない開発を実現したい場合は、代わりにEARを使用してください。
NetBeans 7.1.3、Glassfish 3.1.2.2、およびJRebelを使用して開発を高速化するためにEJBをWARで動作させたとき、JRebelがEARパッケージにデプロイされた場合、EJBモジュールで行われた変更のリロードでのみ完全に機能することがわかりました。単純なWARパッケージを作成した場合、クラスローダーは開発段階でまったく奇妙な動作をし、多くのランダムなバグを引き起こしました。
とにかく、通常の展開での戦争パッケージは、他の人たちによるメンジオドとして完璧に機能しました。
また、WARパッケージでは、保存してコンパイルした後、NamedQuery文字列の変更が反映されませんでした。 EARにパッケージ化した場合、開発はスムーズで迅速でした。もちろん、これはJRebelのバグかもしれません。