自从我担任技术决策职务以来已经过去了一年多，很高兴看到我仍然与之保持着完美的和谐。 几个月前，我在KaiWähner的一个不错的博客中写了一个有关JEE与Spring的答案。 如果观点没有不同，那么讨论的附加值在哪里？ 我确实同意Kai的许多观点。 但是，对我而言，它不是Java EE *或* Spring（如最近这篇文章中所建议的），也不是功能的问题，因为最终，功能在两种体系结构选项（及其相应的生态系统）中都进行了很好的分类。 如果缺少某些东西，那里的人已经编写了一个好的库并将其开源。 这也不是“重量重”或“重量轻”的问题。

几年后，由于向下兼容性要求，任何框架都将承担一些固定费用。 由于这些原因，本博客将不是有关Spring和Java EE的内容和原因的技术文章。 首先，我认为整个问题归结为您要在其中放置用作开发API的框架库以编写业务应用程序的问题：在服务器库目录中，或在WEB-WAR / EAR文件中INF / lib。

图2：Spring和Java EE应用程序的简化开发架构

Spring和“纯” Java EE应用程序之间最大的相关差异在于，Spring应用程序中的开发框架API是部署到任意Java运行时的Java应用程序（WAR或EAR文件）的一部分。 相反，纯Java EE应用程序仅包含业务代码，并且应用程序框架是应用程序服务器的一部分。 因此，业务应用程序直接在应用程序服务器API上工作。 除了这些纯粹的方案外，当今的大多数Java企业应用程序还使用Java EE和Spring API的混合。 几乎可以在任何不同的主题（Web服务，IoC容器，GUI等）中做出Java EE *或* Spring决策。

还有针对Java EE和Spring应用程序的纯运行时环境：兼容Java EE的服务器（Redhat JBoss，IBM WebSphere，Oracle WebLogic）和VMWare的vFabric tc Server。 因此，在一个绿色领域，人们可以选择纯Java EE应用程序体系结构而不是纯Spring应用程序体系结构。 但是，如前所述，大多数应用程序都是混合运行的。 我尚未进行过评估，但是我怀疑许多应用程序在带有Spring IoC容器的Java EE或Tomcat服务器环境中运行。 与其使用* only * Java EE或完整的Spring堆栈，不如使用成熟的Java EE和Spring API的均衡组合来实现。

Java EE的优势是各方在书面过程中建立的开放标准。 因此，尽管许多项目仅使用少量的Java EE API，但为此平台构建应用程序却非常受欢迎。 需要注意的另一个重要事实是，每个（明智的）Java打包软件供应商都支持主要的Java EE平台。 因此，许多大型企业无论如何都在内部托管Java EE服务器。 到那时，就可以在Java EE服务器上运行Spring应用程序了。 这种设置可以为生产中有数十甚至数百个Java应用程序的企业提供好处。

1 –迁移JEE服务器要容易得多，因为应用程序*直接*使用更少的服务器API。
2 –为了减少迁移成本，大多数内部客户将决定将其业务应用程序迁移到当前服务器版本。
3 – IT环境中的服务器数量减少了，生产中Java版本的数量减少了，本地开发环境的数量也减少了，更简单的ALM解决方案–总而言之：可管理的复杂性和更统一的环境。 4 –快速响应新的客户端需求：如果您需要新的（Spring）功能，则只需编译新版本的WAR / EAR文件，然后将其部署到任意Java运行时。 5 –与Java EE完整堆栈相比，潜在目标运行时环境的范围将更大。 这意味着您可能独立于“更多”平台。 6 –使用Spring，您可以在应用程序或服务器环境中增加较小的功能（避免：滚雪球效应）。 7 –与Java EE相比，完整的创新周期更快（从功能请求到生产中的使用）。 8 –根据实际的实际客户项目要求对Spring进行了增强，以确保其实际适用性。 9 –应用程序开发团队对应用程序开发堆栈负责，并可以灵活地决定哪种API可以满足客户的需求。

在纯Java EE开发堆栈中很难实现所有这些好处（其中一些解决了Java EE中的概念性问题）。 一种可能的选择是模块化JEE应用服务器体系结构。 像Java SE中一样，模块化是标准。 考虑发布过程（即JCP）也可能是有效的。

就像我之前说的，我确实相信从来没有像现在这样反对JEE，因为这两个选项在很多情况下都可以和谐地协同工作。 今天，仍然可以同时使用Spring和Java EE，就像我在其他博客文章中所解释的那样。 我相信过去的重要讨论更多地是针对我们的业务应用程序的编程模型：CDI与Spring IoC以及JSF与Spring MVC。 辩论通常也是关于是否喜欢“ EJB”的情感辩论（出于历史原因）。 此外，您的业务应用程序与基础平台（服务器，操作系统，硬件）的“真实”独立性有很多。 例如：我们使用EJB作为集成技术，但是业务应用程序对此一无所知。 平台独立性的关键不是使用Java EE还是使用Spring，而是：合理地决定在业务应用程序编程模型中直接使用哪些API。 有时最好不要使用一些application-server-lib-directory派生的目录。

参考：为什么我会在2012/2013年继续通过我们的JCG合作伙伴 Niklas在新的Enterprise Java项目中使用Spring *和* Java EE。