サーブレット/jsp 要求を処理し、IBM WebSphere や BEA WebLogic などのアプリケーション サーバーに転送するために、Java EE アプリケーションに SUN Java Web サーバーなどの Web サーバーが必要ですか?
アプリケーションサーバーはそのようなサーブレット/jspも処理できるので?
このようなサーバー アーキテクチャの長所と短所は何ですか?
質問する
27240 次
3 に答える
40
Apache Tomcat、Jetty、およびSun Java System Web Serverは、Java Web (サーブレット) コンテナーにすぎません。つまり、サーブレット/JSP のみを実行できます。完全な Java EE API スタックは提供されません。
そのため、(EJB を含むモジュールも含まれる).warファイルはデプロイできず、JSF や CDI などの一部の Java EE API をすぐにサポートしません。またはその他の機能/API。Java EE6 以降、ファイルに EJB が含まれる可能性があることに注意してください。との違いに関する詳細情報。.ear.jar.war.war.ear
すべての Java EE サーバーには、Web コンテナー + EJB コンテナーがあります。( 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 は明らかに Apache Tomcat を Web コンテナーとして使用します。Glassfishは Apache Tomcat フォークも使用します。(はい、Apache Tomcat は非常に人気があるようです :)
以下の説明では、Tomcat を「Web コンテナー」に、JBoss を「完全に機能する Java EE サーバー」に変更することができます。（わかりやすくするために製品名を使用しました。）
画像: Java EE サーバーとコンテナー - ソース: Java EE チュートリアル。
Java Web サーバー (Tomcat など) でサーブレット/JSP 呼び出しを処理し、より複雑な要求を JBoss (または IBM WebSphere または BEA WebLogic) などのアプリケーション サーバーに転送することの (欠点) 利点は何ですか?
機能の観点からは、効果的なゲインはありません
JBoss の前にTomcat を配置する場合、実際に行うことは、常に JBoss の EJB コンテナの前にある JBossWeb (Web コンテナ、したがってすべての Web アプリケーションへの入り口) の前に Tomcat を配置することです。機能について話している場合、同じサービスが 2 回配信されるため、冗長です。
実装者の切り替えまたはクラスタリング機能
JBoss の前にTomcat を配置することは、JBoss を EJB コンテナーのみに使用している場合に意味があります。ここでの選択は、Web コンテナーの実装者での単純な切り替えになります。
また、Tomcat が別のネットワーク ノード (または複数の Tomcat/ノード) にある場合は、クラスタリング機能を適用できます (JBossWeb と JBoss は通常 1 つとして扱われ、同じマシンに配置されるため、それ以外の場合は適用できません)。 .
静的コンテンツの提供とセキュリティの問題
非常に一般的なのは、Web サーバー(Apache HTTPD や IIS など)を Java Web Container の前に配置することです。これには主に 2 つの動機があります。
- HTTPD に静的コンテンツ(画像など) を提供させ、残りを Java Web コンテナーに転送します。これが行われるのは、通常、Web サーバーは静的コンテンツを配信するタスクで最適化されているためです。
- セキュリティ: DMZ 内の HTTPD のみを公開します。DMZ で Apache HTTPD をセットアップし、すべてを Web コンテナー (Tomcat など) および JavaEE サーバー (JBosses など) に単純に転送することができます。
セキュリティを強化したい場合、DMZ で Web コンテナーを使用しても意味がありません。アプリを提供している (つまり、.warファイルがデプロイされている) 場合、アプリケーションは依然として「脆弱」です。リクエスト/レスポンスのみを転送する場合は、Apache HTTPD の方がはるかに優れたオプションです。
于 2013-04-14T09:10:36.783 に答える
3
Sun Java Web Server、IBM WebSphere Application Server、WebLogic、JBoss Application Server、Tomcat、Jetty... これらはすべてJava Web Application Serverであり、同じことを行います - 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 サーバーをセットアップし、すべてのトラフィックを から にリダイレクトするように構成する必要がありmod_proxyます。/myapphttp://myserver.com:8080/myapp
*: 正確な数は覚えていませんが、約 1024 です。これは Linux には当てはまりますが、Windows には当てはまらないかもしれません。Windows セットアップを使用してからしばらく経ちました。
更新：悪いことに、ここで説明されているよう に、「システムサービスとして実行」の部分を強調するのを忘れていました。
于 2013-04-14T09:01:21.793 に答える
1
アプリケーション サーバーには既にボード上にサーブレット コンテナーが含まれているため、着信 HTTP 要求を処理する Web サーバーをもう 1 つ持つことは冗長です。
しかし、このレイヤーが分離されたプロジェクトに取り組んだことがあります。JBoss サーバーのクラスターと、Tomcat サーバーの別のクラスターがありました。Tomcat は、ロード バランシングを使用して RMI 経由で JBoss を呼び出していました。これは、セキュリティ (Jboss サーバーは VPN 内にある) とスケーラビリティのために行われました。
于 2013-04-14T09:30:44.433 に答える