39

Java EE アプリケーション サーバーは tomcat のすべての機能を提供します。

特に、JPA、JAX-RS、JSF などの Java EE 機能が必要な場合は、EE 準拠のアプリケーション サーバーが標準で提供していたはずのライブラリをアプリケーションと一緒にパッケージ化する必要があります。

4

7 に答える 7

81

私たちの心にあった質問とTomEEを作成した理由は、なぜ人々は選択しなければならないのかということでした。

「Tomcat または JavaEE」というもの全体が使い古されています。

10年経った今でもそれが話題になり、人々はどちらが優れているのか、そしてその理由について互いに反論します.

短い形式の数学は次のとおりです。

  • Java EE 6 では、私たち (JCP) は Web プロファイルを作成し、焦点を絞った一連のテクノロジを使用したより小さなランタイムの必要性を正式に認めました。

すばらしい、道半ばですが、人々はまだ「TomcatかJavaEE か」について議論しています。解決策は明らかでした。Tomcat は Java EE 認定を受ける必要がありました。Web プロファイルは、まさにそれを可能にするために作成されました。

  • 2011 年に、私たち (Apache) は Apache Tomcat を認定する作業を開始しました。JavaOne 2011 で Apache TomEE として認定され、発表されました。4月に最終リリースが発表されました。

素晴らしい、今私たちはそこにいます。

新しい現状

  • JavaEEの軽量バージョンがあります
  • TomcatのJavaEE認定バージョンがあります

これはすべて過去2年間に起こりました。世の中変わったんだよ。

Tomcat と JavaEEが必要な場合は、それを使用できます。

于 2012-06-30T17:29:02.973 に答える
6

プレーンな Tomcat を使用する人はめったにいません。彼らは常に、Webフレームワーク、いくつかのorm、いくつかのDIフレームワークなどのように、たくさんの余分なものを追加します.

これには Spring を使用できますが、最終結果は大きく肥大化し、多くの XML プログラミングを余儀なくされることになります。

最新の Java EE 6 実装は非常に軽量 (TomEE と Resin はわずか 25 MB) で、必要なもの (Web、永続性、DI) がすべて含まれています。いわゆる Web プロファイルには、めったに必要としないものは含まれていません。最新の Java EE 6 サーバーは 1 秒か 2 秒で起動します。これは、裸の Tomcat と同じレベルですが、日常的に必要なツールを実際に提供します。

于 2012-06-30T15:09:47.633 に答える
5

ほとんどの Java EE アプリケーション サーバーはかさばり、不要な機能が多数搭載されており、開発/テスト サイクルが非常に遅い (Java 反逆者の生産性レポートを確認してください)。Java EE 機能の一部が本当に必要な場合は、それを使用する必要がありますが、ほとんどの場合、同じ基本機能 (サーブレット コンテナーは本質的に、Java EE 技術のほとんどを軽量などの tomcat の上に配置できます) を持つことができます。 ejb コンテナーなど) を tomcat またはその他の軽量サーブレット コンテナーと共に使用します。

また、アプリケーション サーバーの外部で JPA、JSF、JAX-RS を使用できることにも注意してください。

TL;DR: Java EE アプリケーション サーバーは明らかに遅いです。オンザフライでクラスをリロードせず、非常に苛立たしいコード/デプロイ/テスト サイクルを強制しないでください (Java コード内の変更をテストするのに 20 秒から 8 分かかると考えてください)。ほとんどの人は、基本的な機能 (本質的にはサーブレット コンテナー) だけを必要とします。

2011 年からの再展開時間に関するレポートは次のとおりです: http://zeroturnaround.com/java-ee-productivity-report-2011/#redeploy_times

于 2012-06-29T13:43:03.950 に答える
3

Tomcat は、多数の JVM Web アプリケーションに必要なすべてを実行する、よくできた軽量のサーブレット コンテナーです。ブラウザと直接通信する Web サーバーとして、本番環境でうまく機能します。多くの人にとって、Java EE には、安定した便利なアプリケーションを構築するのに必要以上のものが含まれています。このタイプの人は、より少ない、より多くの機能を持たないツールを探し、機能よりも安定した適切に記述されたコードを重視します。ソフトウェア選択の世界はマーケットプレイスであり、Tomcat はそのマーケットプレイスの一部をうまく提供しています。他の市場と同様に、代替案を見て、ニーズに合ったものを選択する必要があります. Tomcat は多くの選択肢の 1 つにすぎません。

設計構造行列に関するこの論文http://www.people.hbs.edu/cbaldwin/DR2/LaMantia-Cai-MacCormack-Rusnak%20WICSA2008.pdfには、Tomcat の興味深い視点があります。彼らはそれを名前のない競合他社と比較し、うまく設計されていることに気づきました。独自のコードを分析することに興味がある場合、私が知っている唯一の DSM 実装は IntelliJ Enterprise エディションですが、数週間の無料試用版が提供されます。

個人的には、単純さがサポート ソフトウェアの美徳であり、サーブレット コンテナーはアプリケーションの一部ではなく、サポート ソフトウェアであると考えています。

于 2012-06-30T03:11:33.527 に答える
3

上で @Miguel Ping が説明したように、アプリケーション サーバーには開発者が必要としない機能が含まれています。
たとえば、多くの開発者はメッセージング用のコードを必要としないため、JMS jar は必要ありません。
他の開発者はクラスタリングを必要としない場合があるため、クラスタリング コードは必要ありません。
現在、ほとんどの UI は Web 向けであるため、アプリケーション サーバーによって提供される必要があるサーブレット コンテナーはますます重要なコンポーネントになり、多くの開発者はサーブレット コンテナー (つまり、Tomcat) のみを使用することを決定します。
この場合、多くの開発者は Spring フレームワークを使用して、プレーンな Java EE の機能を置き換える (または Java EE と統合する - Spring はアプリケーション サーバー上でも実行できます)。
スプリングコアライトウェアであり、主に Depdency Injection/Inversion-Of-Control コンテナーを提供します (Java EE で EJB コンテナーを置き換えます)。
アプリケーションにより多くの機能を提供するために、Spring フレームワークから他のモジュールを追加することができます。一方、多くのアプリケーション サーバー (EJB 3.0 以下のアプリケーション サーバー) では、アプリケーション サーバーがスタック全体をロードし、これがアプリケーション サーバーの起動時間にも影響します (そしてこの個人的な経験から、開発者にとっては非常に迷惑です）。

そうは言っても、EJB 3.1 にはプロファイルが含まれるようになりました。たとえば、Java EE 仕様からロードされるパーツの数が少ない Web プロファイルです。さらに、Jboss はJBoss AS 7で、アプリケーション内の依存関係を分析し、独立したコンポーネントの並列デプロイメントを実行する並列デプロイメント メカニズムを導入しました。
たとえば、oVirtオープン ソース プロジェクトでは、仮想化環境の単純なデプロイの開始時間を 1 分以上から 3 秒程度に短縮しました。そのようなメカニズムが他の EJB 3.1 アプリケーション サーバーに存在するかどうかはわかりませんが、前述のように、プロファイルを非常に簡単に定義するか、 Web プロファイル (EJB lite)
などの既存のプロファイルを使用して起動時間 を短縮することができます。過去には、Tomcat は主に起動時間を短縮し、ロードされるモジュールの量を減らすために使用されていました。 Spring は、Java EE 開発のモジュール式の代替手段を提示し、tomcat で使用できます。




. 今日、EJB 3.1 では、Java EE もモジュール化を採用しており、JBoss AS 7 などのアプリケーション サーバーは、展開中に行われるあらゆる種類の最適化により、起動時間を数秒に短縮します。

于 2012-06-29T16:31:45.570 に答える
0

ほとんどの場合、アプリケーション サーバーの選択 (Tomcat と JBoss のような AS) に関する決定は、小規模な IT 部門の管理/開発チームの経験と知識に基づいて行われます。IMO は技術的な問題よりも政治的な問題です。さらに、多くの場合、Tomcat にデプロイされるプロジェクトは、統合の概念がほとんどなく、複雑な Web アプリケーションであることがよくあります。このようなプロジェクトでは、軽量のコンテナとフレームワーク (Spring、Struts) がよく使用されます。しかし、プロジェクトが複雑になり、分散化が進む場合は、スケーラビリティ、「監視」、高可用性 (JBoss の @HASingleton など) などの属性が必要になります。所定の位置に。そして、ASのすべての機能を取得するために、プレーンなTomcatにサードパーティのフレームワークを装備するのは非常に面倒です。

于 2012-06-30T18:27:18.693 に答える
0

彼らは軽量化を選択していると考えていますが、結局のところ、アプリケーションは Java EE Web プロファイルを使用する場合よりもはるかに重くなります。春を選択すると、展開が非常に大きくなり、ビルドとサーバーの起動時間が遅くなる可能性があります。開発者の生産性が低下する ... アプリをできる限りシンプルかつ軽量にしたい場合は、Web プロファイルをサポートする Java EE サーバーを選択してください。

于 2014-07-23T15:14:10.607 に答える