我们最近发布了有关从免费Plumbr部署中收集的应用服务器市场份额的数据 。 它产生了很好的共鸣-通过不同的渠道，我们获得了数百种有关如何解释数据的评论。 但是，通过各种渠道不断提出一种形式不同的论点。 无论是采用“ T omcat不是应用程序服务器 ”的形式还是“ 此数据都无关紧要，因为它没有集中在Weblogic或WebSphere等真实的应用程序服务器上 ”，它只是在不断出现。 这使我们感到奇怪– Java社区为什么对真正的应用服务器有如此不同的看法。 因此，我们决定对该问题进行一些说明。 调查最明显的来源（即Wikipedia ），事情看起来还不错：

应用程序服务器可以是提供通用方法来创建应用程序服务器实现的软件框架，而无需考虑应用程序的功能是什么，也可以是特定实现实例的服务器部分。 在这两种情况下，服务器的功能均致力于有效执行过程（程序，例程，脚本）以支持其应用程序。

到目前为止，一切都很好。 显然任何东西都可以是基于Wikipedia定义的应用程序服务器。 但是，当我们尝试为Java EE应用服务器找到正式定义时，事情就变得更加有趣了。

如果深入研究Java EE规范 ，您会发现Sun既没有过去的历史，也没有Oracle在官方规范中使用“应用程序服务器”一词。 而是在整个材料中使用了“容器”一词。 容器必须支持不同的规范，例如JMS ， JTA ， JSP，以保证应用程序可跨不同的实现移植。

下一个重要的事实–在Java EE 5之前， Sun / Oracle承认您的产品正式符合Java EE的唯一方法是实施整个规范。 这导致了大型，单一的“企业级”产品，例如臭名昭​​著的Websphere和2000年代中期的Weblogic。 结果，越来越多的人蜂拥而至，远离了几乎不可能使用的野兽，并开始使用诸如Tomcat或Jetty之类的更人性化的东西。 出乎意料的是，这些产品的供应商对官方规范的关注程度并不低，而是专注于为手头的工作提供良好的工具。 因此，规格委员会最终屈服并分解了规格。

Java EE 6中的这种故障称为Java EE配置文件。 Java EE 6规范使容器供应商可以选择是希望实现规范的子集以获得Web Profile认证，还是希望获得Full Profile并实现所有规范。 下表描述了相应配置文件中的强制性规范：

因此，如果您希望构建自己的完整Java EE实现，则最好为该列表中的所有30个缩写提供实现。 由于这绝不是一件容易的事，所以在发布本文时，只有以下应用程序服务器由Oracle 正式认证为Java EE 6：

如果现在将此列表与最受欢迎的应用程序服务器进行比较，我们会发现66％的用户群愉快地运行在诸如Tomcat和Jetty之类的产品上，而这在官方认证的容器列表中是遥遥无期的。 但是我们仍然认为它们两者都是为您的应用程序提供出色且易于使用的平台。 因此，正式而言，没有像Java EE Application Server这样的东西。 取而代之的是，我们有Java EE容器，如果供应商希望，可以在任何配置文件中申请官方认证。 而且，您绝对可以拥有自己的可爱应用服务器，仅实现Servlet规范，而忽略其他所有内容。 在这种情况下，您只是没有资格获得官方认证。

翻译自: https://www.javacodegeeks.com/2013/04/there-is-no-application-server.html