Java Webサーバー+アプリケーションサーバーでのEEアプリケーション

Question

Java EEアプリケーションで、Sun Java WebサーバーなどのWebサーバーを使用して、サーブレット/ jspリクエストを処理し、IBM WebSphereやBEA WebLogicなどのアプリケーションサーバーに転送する必要がありますか。？

アプリケーションサーバーはこのようなサーブレットやjspも処理できるため、

このようなサーバーアーキテクチャの長所と短所は何ですか？

acdcjunior · Accepted Answer

Apache Tomcat、Jettyおよび Sun JavaシステムWebサーバーは、Java Web（サーブレット）コンテナのみです。つまり、サーブレット/ JSPのみを実行できます-完全なJava EE APIスタックを提供していません。

そのため、これらは.warファイルのみをデプロイでき、.ear（EJBを含む.jarモジュールも含む）をデプロイできません。また、JSFやCDIなどの一部のJava EE APIをサポートしていません）。その他の機能/ API。 _{Java EE6、 .warファイルにはEJBが含まれている可能性がある。 .warと.earの違いに関する詳細情報であることに注意することが重要です}。

すべてJava EEサーバーにはWebコンテナ+ EJBコンテナがあります）（- here および here TomcatおよびJettyはJavaEEサーバーではなく、サーブレット（Web）コンテナであると主張しているだけです。）

JBoss Application Serverは、WebとしてJbossWeb（Apache Tomcatフォーク）を使用しますコンテナ。そのEJBコンテナーは、まあ、JBossです（「JBoss EJBコンテナー」以外の名前はありません）。

その他（IBM WebSphere、Oracle/BEA WebLogic、TomEE、Glassfish）にも、Webコンテナ+ EJBコンテナがあります。

TomEEは明らかにWebコンテナーとしてApache Tomcatを使用しています。 GlassfishもApache Tomcatフォークを使用します。（はい、Apache Tomcatは非常に人気があるようです:)

以下の説明では、Tomcatを「Web Container」で変更し、JBossを「Fully Capable Java EE Server）」で変更できます（わかりやすくするために製品名を使用しました）。

JavaEE Server Containers

^{画像：Java EEサーバーおよびコンテナー-ソース：Java EEチュートリアル。}

Java Webサーバー（Tomcatなど））がサーブレット/ JSP呼び出しを処理し、より複雑な要求をJBoss（またはIBM WebSphereまたはBEA WebLogic）などのアプリケーションサーバーに転送することの（欠点）の利点は何ですか）？

機能性の観点から、効果的な効果はありません

TomcatをJBossの前に配置する場合、実際に実行しているのは、Tomcatの前にJBossWeb（Webコンテナ、すべてのWebアプリケーションへの入り口）は常にJBossのEJBコンテナの前にあります。機能について言えば、同じサービスが2回提供されるため、これは冗長です。

実装者またはクラスタリング機能の切り替え

Tomcatをbeforeの前に配置する（---）そのEJBコンテナーのみにJBossを使用している場合、JBossは理にかなっています。ここでの選択は、Webコンテナーインプリメンターでの単純なスイッチです。

また、Tomcatが別のネットワークノード（または複数のTomcat /ノード）にあった場合、クラスタリング機能を適用できます（JBossWebとJBossは通常1つとして扱われるため、同じマシンに移動するため、そうしないと適用できませんでした）。。

静的コンテンツの提供とセキュリティの問題

veryの共通点はWebサーバーの配置（Apache HTTPDなど）またはIIS）Java Web Containerの前）これには2つの主な動機があります。

HTTPDに静的コンテンツ（画像など）を提供させ、残りをJava Webコンテナに転送します。これはWebサーバーは通常、静的コンテンツを配信するタスクで最適化されているためです。
セキュリティ：DMZでHTTPDのみを公開します。 DMZでApache HTTPDをセットアップして、すべてをWebコンテナ（Tomcatsなど）とJavaEEサーバー（JBossesなど）に転送するだけです。

セキュリティを強化したい場合は、DMZでWebコンテナーを使用しても意味がありません。アプリケーションがサービスを提供している（つまり、.warファイルがデプロイされている）場合、アプリケーションは依然として「脆弱」です。リクエスト/レスポンスを転送するだけの場合は、Apache HTTPDの方がはるかに優れています。

Cebence · Answer

Sun Java Webサーバー、IBM WebSphereアプリケーションサーバー、WebLogic、JBossアプリケーションサーバー、Tomcat、Jetty ...それらはすべてJava Webアプリケーションサーバーそして同じことを行います-WARまたはEARでパッケージ化されたアプリケーションを実行します（EARは「エンタープライズ」用で、1つ以上のWARが含まれています）。

1つのアプリケーションを実行するためにセットアップに2台のサーバーがある場合、展開戦略/設計に問題がある可能性があります。

マルチサーバーセットアップの場合もありますが、それらは通常、Javaアプリケーションサーバーの前にApache HTTPサーバーがある負荷分散およびプロキシセットアップです。

たとえば、ポート8080でアプリケーションを提供するTomcatがあり、http://myserver.com/myapp/ではなくhttp://myserver.com:8080/myapp/を使用したいとします。 Javaはポート1024（*）を下回ることができないため、Tomcatだけではそれを行うことはできません。これを実現するには、ポート80にApache HTTP Serverをセットアップし、mod_proxyを構成して、すべてのトラフィックを/myappからhttp://myserver.com:8080/myappにリダイレクトする必要があります。

*：正確な数は覚えていませんが、1024前後です。これはLinuxにも当てはまりますが、Windowsには当てはまらない場合があります。Windowsセットアップを使用してからしばらく時間が経っています。

UPDATE：悪いことに、「システムサービスとして実行」の部分をここで説明として強調するのを忘れていました。

Anton · Answer

まあ、Applications Serverにはすでにボード上にサーブレットコンテナが含まれているので、着信httpリクエストを処理するWebサーバーをもう1つ持つのは冗長です。

ただし、このレイヤーが分離されたプロジェクトに取り組んだことがありました。 JBossサーバーのクラスターとTomcatサーバーの個別のクラスターがありました。 Tomcatは、ロードバランシングを使用してRMI経由でJBossを呼び出していました。これは、セキュリティ（JbossサーバーがVPN内にある）とスケーラビリティのために行われました。