アプリケーションのニーズによって異なります。Tomcat はほとんどが単なるサーブレット コンテナですが、JBoss、Websphere などは完全な Java EE サポートを提供します (通常、Java EE 仕様を超えた追加のプラットフォーム固有の機能に加えて)。
多くのアプリケーションでは、サーブレット コンテナで十分です。特に、Web アプリケーションの一部として適切なライブラリをバンドルするだけで、多くの Java EE のような機能を取得できるためです。しかし、場合によっては、本格的なアプリケーション サーバーの 1 つでしかすぐに利用できないこの機能またはその機能が必要になることがあります。
とはいえ、本当に必要なのはサーブレット コンテナーだけなのに、完全な Java EE サーバーを使用するのはかなりばかげていると思います。原則として、私は常に Tomcat から始めます。Tomcat では提供できない機能が必要であると判断した場合にのみ、JBoss などに切り替えます (頻繁に発生するわけではありません)。
Tomcat で実行される Web アプリケーションを JBoss で実行するのは非常に簡単なことです。そのため、より複雑なプラットフォームに直接ジャンプする理由はなく、ゲームの後半でそうすることにした場合でも実際のペナルティはありません。
ブログ記事で提起された特定のポイントについて：
EJB をサポートするアプリケーション コンテナが必要です
彼は正しい、あなたはこれを必要としません。EJB と同じ種類の機能を提供する Spring のような一般的なフレームワークがあります。両方を同時に使用することは通常ありません。
最適化されたアプリケーション サーバーがハードウェアを最適化
コメント無し。個人的には、ウェブアプリが大量のマルチメディア処理や同様のタスクを実行していない限り、最新のハードウェアは、特別な最適化がなくても、アプリが何であれ実行するのに十分な速度になっていると思います. そのため、仮想化は非常に重要です。単一のサーバーは現在、単一のサイトだけに専念するには強力すぎるため、それぞれが独自のサイトを実行する複数の仮想サーバーに分割します。
2 フェーズ コミットは深刻です
繰り返しますが、私はブログの投稿に同意しません。2 フェーズ コミットは、たまたま必要でない限り、深刻ではありません。そして、私は一度もそれを必要としたことはありません。私がこれまで携わってきたすべてのプロジェクトでは、楽観的なトランザクションとロールバックを備えたデータベースで十分でした。
管理性
開発者としての私の経験では、JBoss は Tomcat よりもはるかに「扱いにくい」ものです。構成がとてつもなく難しいだけです。確かに、この記事で言及されているのと同じ種類の管理機能ではありませんが、それでも注目に値するものです。それ以外に、Java EE コンテナには通常、サーバー管理に関連する組み込み機能がはるかに多くありますが、Tomcat (またはその他の種類のサーバー) から同様の機能を引き出すために使用できるサードパーティ ツールも多数あります。
クラスタリングは、スケーラビリティ、パフォーマンス、および可用性をサポートします
Tomcat はクラスタリングをサポートし、他のプラットフォームよりもスケーラブルです。実際、JBoss は Tomcat の上で実行されるため、Tomcat には本質的にスケーリングを妨げたり、エンタープライズ レベルのプラットフォームとしての使用に適さないようにするものは何もないことは明らかです。