为什么选择tomcat而不是Java EE兼容的应用服务器？

Question

Java EE应用服务器提供了tomcat的所有功能，那么为什么要使用tomcat（而不是glassfish，例如官方的）？

特别是当需要Java EE功能时，如JPA，JAX-RS，JSF，因此需要将更多的库与应用程序打包在一起，而符合EE标准的应用程序服务器是否可以提供开箱即用的功能？

Answer 1

我们心中的问题以及我们创建TomEE的全部原因是，为什么人们必须选择？

整个“Tomcat或JavaEE”的东西已经累了。

10年后，它仍然出现，人们互相争论哪个更好，为什么。

这是简短形式的数学：

• 在Java EE 6中，我们（JCP）创建了Web Profile，以正式承认需要使用一组专注的技术来实现更小的运行时。

太好了，我们已经到了中途，但人们仍在争论“Tomcat 或 JavaEE”。解决方案很明确，Tomcat需要通过Java EE认证。创建Web配置文件是为了允许完全符合。

• 2011年，我们（Apache）开始着手验证Apache Tomcat。认证达到并在JavaOne 2011上宣布为Apache TomEE。最终版本于4月公布。

太棒了，现在我们在那里。

新的现状

• 有一个较轻的JavaEE版本
• 有一个JavaEE认证的Tomcat版本

这一切都发生在过去的两年里。情况发生了变化。

如果你想要 Tomcat和JavaEE ，你可以拥有它。

Answer 2

很少有人使用普通的Tomcat。他们总是添加大量额外的东西，比如webframework，some orm，一些DI框架等等。

你可以使用Spring，但最终结果会很大，膨胀，你将被迫进行大量的XML编程。

现代Java EE 6实现非常轻量级（TomEE和Resin只有25mb）并且包含您需要的所有内容（Web，持久性，DI）。所谓的Web Profile不包含您很少需要的任何内容。现代Java EE 6服务器在一两秒内启动，与裸Tomcat处于同一联盟，但它们实际上每天都提供您需要的工具。

Answer 3

大多数Java EE应用程序服务器体积庞大，具有许多不需要的功能，并且开发/测试周期非常慢（只需查看java反叛者生产力报告）。如果你真的需要一些Java EE功能，那么你应该使用它，但是大多数情况下你可以拥有相同的基本功能（基本上是servlet容器，你可以将大部分Java EE技术放在tomcat之上，比如轻量级ejb容器等）与tomcat或任何其他轻量级servlet容器。

另请注意，您可以在应用程序服务器之外使用JPA，JSF，JAX-RS。

TL; DR： Java EE应用程序服务器显然缓慢，不会动态重新加载类并强制非常恼人的代码/部署/测试周期（想想在20秒到8分钟之间的任何地方来测试你的java代码中的一些变化）。大多数人只需要基本功能（基本上是servlet容器）。

以下是关于2011年重新展开时间的报告：http://zeroturnaround.com/java-ee-productivity-report-2011/#redeploy_times

Answer 4

如上所述@Miguel Ping，应用程序服务器包含开发人员不需要的功能。
例如，许多开发人员不需要代码进行消息传递，因此他们不需要JMS jar。
其他开发人员可能不需要群集，因此他们不需要群集代码，等等。
由于今天大多数UI都面向Web，因此必须由应用程序服务器提供的Servlet容器变得越来越重要，因此许多开发人员决定只使用Servlet容器（即tomcat）。
在这种情况下，许多开发人员使用Spring框架来替换他们使用普通Java EE的功能（或者与Java EE集成 - Spring也可以在应用程序服务器上运行）。
Spring-core是轻量级软件，主要提供Depdency Injection / Inversion-Of-Control容器（在Java EE上替换EJB容器）。
您可以从Spring框架添加其他模块以为您的应用程序提供更多功能。而在许多应用程序服务器（EJB 3.0及更低版本的服务器）中，应用程序服务器正在加载整个堆栈，这也会影响Application Server的启动时间（以及从个人经验来看，开发人员非常讨厌。

话虽如此，EJB 3.1现在包含配置文件，例如 - web配置文件，它从Java EE规范中加载较少数量的部件。此外，Jboss在JBoss AS 7中引入了一种并行部署机制，该机制分析应用程序中的依赖关系，并执行独立组件的并行部署。
例如，在oVirt开源项目中，我们将虚拟化环境的简单部署的启动时间从1分钟缩短到3秒钟。
我不知道其他EJB 3.1应用程序服务器中是否存在此类机制，但是，如前所述，您可以非常轻松地定义配置文件或使用现有的配置文件，例如web profile (EJB lite)以减少启动时间。

总之， 过去 - 人们主要使用tomcat来减少启动时间并减少加载的模块数量。
Spring提供了Java EE开发的模块化替代方案，可以与tomcat一起使用。
。 今天，使用EJB 3.1，Java EE还支持模块化，并且有一些应用程序服务器，例如JBoss AS 7，由于在部署期间进行了各种优化，因此可以将启动时间缩短到几秒钟。

Answer 5

Tomcat是一个编写良好的轻量级servlet容器，可以完成大量JVM Web应用程序所需的一切。它作为直接与浏览器对话的Web服务器在生产中很有效。对于许多人来说，Java EE中有太多的东西，超过了构建稳定有用的应用程序所需的东西。这种类型的人寻找的工具具有更少，而不是更多，并且价值稳定，编写良好的代码高于上述功能。软件选择的世界是一个市场，Tomcat很好地服务于该市场的一部分。就像在任何市场中一样，您需要查看备选方案并选择满足您需求的方案。 Tomcat只是众多选择中的一种。

本文中有一个关于Tomcat的有趣观点http://www.people.hbs.edu/cbaldwin/DR2/LaMantia-Cai-MacCormack-Rusnak%20WICSA2008.pdf 关于设计结构矩阵。他们将其与未命名的竞争对手进行比较，并发现它设计得很好。如果您有兴趣分析自己的代码，我知道的唯一DSM实现是IntelliJ企业版，但它们确实为您提供了几周的免费试用。

就个人而言，我认为简单是支持软件的优点，而servlet容器是支持软件，而不是应用程序的一部分。

Answer 6

在大多数情况下，关于应用程序服务器选择（Tomcat与AS之类的JBoss）的决定将根据小型IT部门的管理/开发团队的经验和知识以及IMO的政治而不是技术问题来制定。 此外，最多部署在tomcat上的项目通常是具有很少集成概念和复杂性的Web应用程序。对于这样的项目，经常使用轻量级容器和框架（Spring，Struts）。但是，如果项目变得越来越复杂和分布越来越多，诸如可扩展性，“监视”，高可用性（如JBoss的@HASingletons）等属性来了。到位。然后，让你的普通tomcat配备第三方框架以获得AS的所有功能是非常痛苦的，并且大多数时候你都会挑战来运行所有这些。

Answer 7

他们认为他们选择轻量级但是在一天结束时，他们的应用程序将比使用Java EE Web配置文件更重。如果他们选择spring，他们的部署可能会非常大，构建和服务器启动时间会变慢。开发人员的工作效率下降......如果您希望您的应用程序尽可能简单轻便，请选择支持Web配置文件的Java EE服务器。