java ee技术_Java EE 6与Spring Framework：技术决策过程

java ee技术

在过去的几个月中，我们经历了这个决策过程：为Java平台上的企业开发选择哪种技术堆栈？有多种选择。但是，我们深入讨论的是：纯Java EE 6堆栈与带有Java EE的Spring。

以下博客文章总结了当您考虑这些技术堆栈选项之一时发现的有趣的关键问题。我不会试图说服某人选择两者之一。这对我来说很重要，我想分享的是决策过程和关键论点。

什么是“标准”？

在我们的讨论中，“标准”一词非常重要，特别是对于执行管理层而言。我认为这使决策者对保护投资充满热情。但是什么是标准，在Java生态系统中我们可以认为什么是标准？ Codecentric AG的创始人兼董事会成员Mirko Novakovic写了一篇非常有趣的博客文章，名为：“ Java EE vs Spring。或者：什么是标准？ ” Mirko指出以下内容：

对他来说，标准是建立，接受和主导的东西
遵循此定义，仅将某些Java EE API（例如Servlet规范）视为标准，因为它们已广泛应用于Java生产技术领域
他过去曾说过，某些Java EE标准API几乎没有投资保护，例如EJB规范（过去十年中大量API发生了变化）
他还声称，JPA和JSF的1.0版本不足以满足大型企业开发项目中的技术要求。
他将CDI视为另一个年轻的标准，它需要证明其长期稳定性，然后才能被视为Java企业应用程序中的标准IOC机制。
因此，他目前的结论是：Sping和Hibernate仍然是Java企业开发的“实际”标准。

Mirko描述了一个有效的观点。另一个有效的观点是：在Java规范请求（JSR）中指定和发布的所有（唯一的）API都可以视为标准。应用服务器供应商根据这些JSR构建产品。因此，如果Java开发人员使用这些标准API，他们可以构建可在任何应用程序服务器平台上运行的Web应用程序。在Java EE 6中，他们可以构建企业级Web应用程序，而无需进一步依赖于第三个库。结果是一个非常轻便的Web应用程序（WAR或EAR文件），仅包含您开发的代码。那是Java EE的情况，也是有效和结论性的。

当您必须决定在编程模型中使用哪些API时，对您来说最重要的是什么？有很多决策参数，例如简单性，API的完整性，改进的生产稳定性等等。我们在研究中列出了一长串参数。其中一些比其他一些更为重要，它们是：API的成熟度，供应商独立性，生产就绪性，投资保护和共同判断。

标准API的生命周期

我们的假设是，每个API进入Java EE标准时都会经历理想的 生命周期 （我们在过去已经观察到）。这些阶段是：Newby，Storm，Stabalize，Matural，Dead。标准API的第一个（ Newby ）版本1.0几乎没有功能。通常，仅仅满足大型开发项目的功能和性能的技术要求是不够的。这是Mirko反对CDI或JPA 1.0的观点。有些人使用这些API，但他们还必须编程许多变通方法以获取所需的全部功能（例如，JPA 1.0中的第二级缓存）。

这些阶段的经验教训进入了后续的API版本，因此，API有时会变得不稳定。增加了功能，减少了采用，简化的API等。如果客户希望遵循该标准，那么这种动荡且不确定的风暴阶段会导致迁移成本增加。即使2.0版本向下兼容，使用不错的新功能代替许多变通办法也意味着重构工作。如果该API并非没有问题，兼容的API更改会强制执行迁移工作，则别无选择。过了一会儿，但是API变得成熟，这些重构，成本下降，该API进入stabalization的阶段。

一个成熟的 API始终具有较低的迁移和重构成本，因为未应用任何基本更改。一段时间后，不再使用某种技术，因为它已被其他创新的API所取代。技术已死了–这些API不再投资，社区停止了该项目。图1显示了理想的API生命周期。

图1：理想的Java EE API生命周期

生命周期模型的关键假设是：您决定越早使用API标准，则在后续版本中增强API时，可能要付出的重构成本就更多。因此建议是：您必须判断生命周期中（Java EE）API的状态。然后，您决定是否要使用成熟的API和更低的制罐成本。还是您想成为利用技术束缚的先驱之一。尽早采用的优势之一可能是早日实现更高的开发效率，与其他标准API的更高集成度或开发咨询知识。

我们已决定仅使用成熟的API，我们不希望与“ Newby”状态API相关的迁移成本。我们的信任度很低，因为我们在EJB时代遭受了很多苦难。如果我们回顾一些Java EE标准的历史，则与API稳定性相关的变化是巨大的。因此，我们宁愿等到API成熟并且已成为生产中大型应用程序系统的成熟技术。如果我们认为Java EE API已经成熟，则可以考虑使用它。

独立性（开发，运营和OE供应商）

对我们而言，架构决策中的另一个重要因素是：我们希望为以后的架构，设计或实施决策提供最大的灵活性。那是什么意思例如，如果您选择的技术堆栈是应用程序服务器的一部分，那么您的应用程序开发部门，基础架构人员和原始设备（OE）供应商之间的关系将非常紧密。为什么？因为新的应用程序服务器版本包含您在业务应用程序中使用的新API版本。结果是，当您决定使用新版本的应用程序服务器时，可能必须更改现有代码。所有这些降低了灵活性。

另外，OE供应商可能会急着迁移您，因为“如果您想拥有我们应用程序服务器的此独特监视或集成功能，则必须使用最新版本的XY Java EE服务器”。 OE供应商通常会对他们感兴趣，因为他们希望您使用最新版本。对于他们来说，支持更少的生产版本只是更便宜。它为他们带来更少的维护成本和更高的咨询收入。

我们在生产中运行了50多个Java EE应用程序。出于上述原因，保持独立于运行时基础结构对我们非常重要。因此，我们通常更喜欢业务应用程序和应用程序服务器之间的“层”。换句话说：我们通常不直接使用Newby API，我们通常有一个包装它们的包装器API（参见图2）。

该包装器用作构建业务应用程序的API。包装器API可以是Spring框架，也可以是您自己的一组自定义框架API。这样，当我们分别移动到新的应用程序服务器版本或Java EE版本时，进行所需的更改将更容易，更有效。包装器吸收了Java EE API的更改，使我们免去了更改50个应用程序的负担。相反，我们只在中央位置进行一次更改。我们的开发小组不受应用程序服务器升级的影响。 OE供应商和Java Communication Process（JCP）不会影响我们的决定和努力。

基础架构的生产就绪性（或：现在还是以后？）

您的应用服务器是否有生产就绪版本，可以实现新的Java EE 6标准？在我们的情况下（IBM WebSphere），Z系列上没有任何Java EE 6版本。因此，如果我们还不能在生产环境中运行应用程序，那么思考Java EE 6几乎没有任何意义。您必须决定是现在还是以后使用某种技术。例如，作为IOC机制的CDI（JSR 299/330）对于大型应用程序还不够成熟。因此，你可能要选择像Spring框架或谷歌吉斯的替代品来完成这项工作，如果你想现在已经送到您的客户端（效益分析）值。

投资保护（或：兼容性低下）

我已经在前面提到过：直接将Java EE API用于许多生产应用程序（可能是50或100），可能会降低设计和实现决策的灵活性。在研究投资保护时，同样的论点也适用。对我而言，投资保护主要涉及在特定时期内较低的技术（重构）成本。您想花费金钱来实现业务价值，您想专注于实现业务功能。你不想花费在生活必需品技术的精力（例如，发布版本升级，平台迁移，开发自定义的API）。为了实现这一点，选择正确的开发API至关重要。根据我们的生命周期模型，一个不错的选择是在生命周期的长期成熟阶段开始时选择API。这降低了重构成本，从而增加了投资保护。

我们已经解释了Java EE不仅提供成熟的API。例如，CDI在其JSR 299/330版本中还不成熟。解决该难题的一种可能的方法是组合来自不同来源的API，您可以为业务应用程序配置自己的API集。如果您使用自己的一组 真实的标准API，则可以保护您的投资。

我说的是您自己的一套，因为您可能会使用混合技术堆栈 （图2）：一些成熟的Java EE API（例如Servlet，JPA 2.0），一些实际标准（例如Spring IOC）和一些专有的自定义API作为围绕Newby Java EE API的包装而开发的。最重要的是，这些API支持生产应用程序的低兼容性 。当您要移至新的Java EE 应用程序服务器版本时，必须找到一组API，这些API可使您免于繁重的迁移工作。

图2：用于Java企业开发的混合技术堆栈

共同判断

我做决定时要做的事情就是共同判断。其他专家怎么看？他们有什么意识形态？他们对一个或另一个建议有什么兴趣？如果查看像Spring Framework这样的大型Java企业开发框架，您会发现它们使用标准的Java EE API，但仅使用它们认为已经成熟的API。对于我是否使用特定的API，这是一个很好的提示。无论您是查看Spring还是观察其他框架，都不会满足。关键是您可以对照其他资深（最好是独立的）专家的意见来验证您的意见。

摘要

当您决定使用哪种技术堆栈时，有一长串参数。我在本文中描述的内容在我们的决策过程中非常重要。我们的结论是，目前最好的方法是使用混合技术堆栈。一些API是事实上的标准，一些是Java EE标准，其他是我们开发的自定义API。我们的主要目标是随着时间的推移以较低的重构成本保持灵活性。

关于标准的最后思考：您是否曾经问过自己，遵循标准是否真的很重要？有时，我的印象是，对某些人来说，使用标准是接近绝对真理的事情，是普遍要做的事情。水是湿的，天空是蓝色的，使用标准是正确的。你知道我想说什么吗？所有这些事实上的标准（例如Spring和Hibernate）如何成为标准？

答案是：因为有人有勇气使用它，而其他人（包括Java EE）则紧随其后。 “标准”是社区中很大一部分用来在生产中运行大型应用程序的工具。标准不一定是Java EE标准。过去，Java EE标准遵循事实上的标准框架（例如Hibernate，Spring）。在开源框架中，任何新技术很可能首先达到一定的成熟度。然后它们将成为Java EE标准。这是因为至少在最近十年中，绝大多数Java技术创新都源于社区。

参考： Java EE 6与Spring Framework：我们JCG合作伙伴 Niklas的技术决策过程。

相关文章：