シングルEAR？または複数のEAR？

Question

JBoss EAP 6.1にデプロイするJavaEE 6ベースのアプリケーションを開発中です。このアプリケーションには、Web管理コンソールとRESTfulサービスAPIの2つの主なプレゼンテーションメカニズムがあります。バックエンドでは、管理コンソールとRESTfulサービスAPIの両方が、トランザクションロジックを実行するための一連のEJBと、データを取得するためのPOJOサービスに依存しています。

これらのさまざまなレイヤすべてのパフォーマンスとリソースのニーズは異なる可能性があります。管理コンソールはステートフルで、インタラクティブな機能が多く（したがって、より多くのメモリと処理が必要です）、RESTfulサービスはかなり薄く完全にステートレスです。 EJBはプライマリ・トランザクション・ビジネス・ロジックを実行するため、単純にデータベースに問い合せるPOJOデータ・サービスよりも処理能力が高くなります。

これらのコンポーネントをすべて使用して単一のEAR（クラスタ化された構成の複数のアプリケーションサーバー）を展開するか、個々のコンポーネントを別々のEARに分割する方が理にかなっていますか？別個のEARを使用する私の考えは、たとえWebコンソール（例えば）がスケーリングだけであっても、スケーラビリティの問題があるとわかった場合、EJBサービスのインスタンスをさらに展開することができるということです。

各レイヤー/コンポーネントのスケーラビリティが異なるということを考えれば、どのようなアプローチを取るべきですか？このようなモデルを考えるには、EAR全体でリモートEJBコールを行うことが高すぎるのですか？どんなアドバイスも大いに感謝しています！

Answer 1

「Java EE」の方法は、アプリケーションをクラスタ上に単一のEARとしてデプロイすることです。私はREST/adminコンソールからEJB-sへのローカル・インターフェース呼び出しを使用していると仮定します。デプロイメントは簡単です。セッションレプリケーションが必要ない場合（スティッキセッションを使用できます）、スケーラビリティは非常に優れています。

Webアプリケーション用のロードバランサ（たとえば、SSLデコード、静的リソースの処理、キャッシュされる可能性のあるキャッシュ要求など）を処理するApacheサーバだけが余分な要素です。

このような設定の唯一の問題は、負荷が高い場合に発生する可能性があります。たとえば、EJBは多くのサーバーリソースを消費する可能性があるため、Webアプリケーションのスループットは制御が難しく、EJBによって悪影響を受ける可能性があります。スティッキーセッションを使用すると、ユーザーは常に同じサーバーにリダイレクトされるため、ユーザーセッションが持続する限り、負荷の少ないサーバーにユーザーを移動する機会はありません。

高負荷を計画する場合は、WebアプリケーションとEJBを別々のボックス（または仮想マシン）に保存して、ボトルネックを特定しやすくなり、必要なレイヤーを容易に拡張できます。

これに対するペナルティは次のようになります。EJBへ

1. リモート呼び出し。しかし、JBoss 6はかなり高度なEJBプーリング設定を持っているので、それほどひどい問題ではないかもしれません。
2. これらのリモート呼び出しによってネットワークトラフィックが発生します（したがって、EJBとWebレイヤの間で多くのデータを渡すと問題になる可能性があります）。ピョートルの偉大なコメントのサポートで

Answer 2

：

は今、それらを一緒にバンドルし、実際の必要性は、将来的に発生した場合のみを分割します。

マーティンファウラーのFirst Law of Distributed Object Design: Don’t distribute your objects!を参考にしてください。あなたがそれを打破しようとするなら、少なくとも意識的に、実際のビジネスニーズに対応してください。