まず、WebSphere などのアプリケーション サーバーの場合、1 つ (または複数) の WAR と 1 つ (または複数) の EJB JAR を含む単一の EAR を持つことができ、各 WAR と JAR を異なるサーバーにデプロイできます。したがって、これは EAR の数に関する問題である必要はありません。展開パターンは別の問題です。2 つの EAR を作成することもできますが、それは Java EE 仕様自体によって強制されているわけではありません。
次に、開発時に、EJB がリモートで呼び出し可能なインターフェースを公開するかどうかを決定する必要があります。これはまず第一に設計上の決定です。ローカル呼び出しに適した API が、リモート呼び出しに適しているとは限りません。たとえば、非常に細かい API は過度のメッセージ オーバーヘッドを招く可能性があります。リモート API を公開する場合は、粗い API を優先する傾向があります。
第 3 に、EJB 3.0 は、リモート デプロイメント パターンが適切かどうかに関するアーキテクチャおよび設計上の決定を根本的に変更しません。EJB 3.0 は、EJB 2.x よりもはるかに単純なプログラミング モデルを提供するため、記述するコード/XML ははるかに少なくなりますが、結果として得られる展開パターンに関しては、処理またはネットワーク全体のバイト フローに関して実際に何が起こっているかの変化はありません。 . Spring または Seam の開発者ではないので、Spring または Seam が同じことを言うかどうかはわかりませんが、リモートかどうかなどの基本的なアーキテクチャーの決定は、テクノロジーにとらわれないものになると思います。
では、Web と EJB を異なる層にデプロイするのにどのような力が働くのでしょうか?
コロケーション: シンプルさ、障害モードの減少、ネットワーク オーバーヘッドの削減。
分散型 EJB/WAR: スケーラビリティの分離 (Web 層または EJB 層に独立して処理能力を追加できます)、複数のクライアントのサポート、同じビジネス ロジックを他のクライアントに公開できます (スケーラビリティのニーズも生じる可能性があります)、独立メンテナンス リリース (Web へのパッチは EJB を混乱させません)。