UIが個別のWARとしてパッケージ化され、サーバーが個別のWARファイルとしてパッケージ化されている製品があります。現在、これらのWARは両方とも同じアプリコンテナにデプロイされています。以下は、私が見つけたこのアプローチの長所と短所です。
異なるWARを使用することの長所：1。2つの異なるWARを使用すると、UIまたはサーバー側のコードのいずれかを他に影響を与えることなくリファクタリングできる柔軟性が得られると思います。2.メモリ使用量を最大化するために、2つの異なるコンテナにデプロイできます。したがって、以前はjboss全体に2 GBを使用していた場合（たとえば、jbossを使用している場合）、2つの異なるjbossアプリサーバー（もちろん異なるポート番号）にデプロイすると、4GBを使用できる可能性があります。3。アプリケーションをスケーリングできます。明日、サーバーが私のボトルネックであることがわかった場合、サーバー自体は別のWARであるため、UI WARを気にせずに、サーバーファームを作成できます（サーバーモジュールのみ）。4.緩く結合され、さまざまな統合ポイントが得られます
短所：1。UIには、primefacesを使用します。シーム付加価値のような統合フレームワークを見ることができるユースケースは見当たりません。統合フレームワークを持つことが私のUI戦争に意味があるかどうか誰かに教えてもらえますか？基本的に、seamの全体的な楽しみは、UI、EJBなどとの素晴らしい統合です。したがって、私のフォームは残りのAPIにすべての処理を実行するように要求するため、ここではあまり価値がありません。
複数の戦争が実際にスケーラビリティとメンテナンスに役立つかどうか誰かに教えてもらえますか？たとえば、2つの戦争があり、サーバープラットフォームをアップグレードする必要がある場合、UIを停止する必要がないという利点があります。私が上にリストしたもの以外に他の利点はありますか？
また、すべてがEARとしてパッケージ化されているかどうかを理解したいのですが、アーキテクチャの特定のレイヤーをどのようにスケーリングしますか。上記のように、サーバーレイヤーがボトルネックであると感じた場合、1つのWAR / EARの場合、アプリケーションをどのようにスケーリングしますか？
さまざまなアプリケーションサーバーでさまざまなWARのモデルを継続する必要があるのか、それともアプリケーション全体に対して1つのWARだけを使用する必要があるのかまだわかりません。案内してください...