Java EE—最轻量级的企业框架?

确保高效发展进程的建议

很久以前，J2EE，特别是应用程序服务器被认为过于臃肿和“重量级”。对于开发人员来说，使用此技术开发应用程序会非常繁琐且令人沮丧。但是，由于 J2EE 框架的名称已更改为Java EE，因此该假设不再适用。 Java EE 与其他企业框架相比区别在哪以及框架轻量级的标准是什么？

在选择技术时，需要考虑的最重要方面之一是开发人员在开发过程中的生产力。工程师应该花费尽可能多的时间来实现用例和创收功能，因为这将使公司朝着目标前进。

所选择的技术和方法应该最大限度地缩短开发人员的时间。具体哪些时间呢:等待构建，测试和部署; 配置应用; 实施与业务用例无关的管道; 并配置构建环境和外部依赖项。 但是大多数可用技术都没有这样做。

1.为什么标准?

与其他框架相比，Java EE 的最大优势之一是使用的API的标准化。标准听起来可能很无聊而且不够创新 - 从本质上讲，这是真的，因为Java规范请求（JSR）已经成为行业内过去已经过充分证明的结果。 但使用这些标准有几个优点。

2.整合规范

Java EE中的特定API - 例如上下文和依赖注入（CDI），JAX-RS，JSON 处理（JSR 353）和 Bean验证 - 可以很好地协同工作，并且可以无缝地相互组合。 最重要的是，CDI 被用作应用程序组件之间的“粘合剂”。 该规范包含诸如“如果容器支持规范 A 和 B，那么 A 必须与 B 无缝集成并良好地工作。”

例如，JAX-RS 支持 JSONP 类型，例如JsonObject用作请求或响应实体，它支持调用Bean 校验功能 - 如果验证失败，则包括正确的HTTP状态代码（参见清单1）。

@Path("duke")
public class DukeResource {
    @GET
    public JsonObject getDuke() {
        return Json.createObjectBuilder().add("name", "Duke").build();
    }
    @POST
    public void create(@Valid @NotPlayedYet Game game) {
                // game object has been validated at this point
    }
}

清单1. JAX-RS的JSONP和Bean Validation集成

使用 JSONP 类型意味着内容类型将是 application / json，并且如果验证失败，将发送HTTP状态代码 400 Bad Request。 这无需编写任何配置代码就能使一切都完成。

另一个例子是 CDI 使开发人员能够通过 @Inject 将任何 bean 和用户定义的对象注入 Java EE托管组件。 请参阅清单2，了解一个 bean 验证 Validator，它直接使用另一个 CDI 托管bean。

public class GameNotPlayedValidator implements ConstraintValidator<NotPlayedYet, Game> {
    @Inject
    GameHistory history;
    public void initialize(NotPlayedYet constraint) {
        // no initialization needed
    }      

    public boolean isValid(Game game, ConstraintValidatorContext context) {
        return !history.exists(game);
    }
}

清单2. bean 验证的 CDI 集成

集成是规范的一个主要方面，可以提供直接的开发人员体验。开发人员可以依赖应用程序服务器进行集成和配置工作，从而可以专注于应用程序的业务逻辑。

3.按配置约定驱动开发

由于 Java EE 的配置约定驱动方法，大多数实际应用程序不需要大量配置。 繁琐的 XML 描述符的日子结束了。 对于简单的 Java EE 应用程序，您不需要单个 XML 文件。

由于声明性注释，一个简单的带注释的普通旧 Java 对象（POJO）处理 HTTP 请求（@Path），或分别作为 Enterprise JavaBeans（EJB）bean（@ Stateless） - 包括事务，监视或拦截器。过去，这些方法已在各种框架中得到很好的证明，并已在 Java EE 中进行了标准化。

如果需要，XML 描述符仍可用于部署时配置，但是配置约定有助于最大限度地提高开发人员的工作效率。

4.外部依赖

少数实际企业项目在部署工件中没有任何额外依赖项的情况下工作。 但这些依赖关系的理由主要是由技术驱动 - 例如包括日志记录或实体映射框架或 Apache Commons 或 Google Guava 等常用库 - 而不是用例。

Java EE 7 - 尤其是与 Java 8 一起使用时 - 具有足够的功能来覆盖大多数用例而没有任何其他依赖性。开箱即用的内容大部分都可以用最少量的代码来实现，例如，通过 CDI 提供商的可注入配置，通过拦截器的断路器（查看 Adam Bien 的开源库），或通过复杂的收集操作 Java 8 lambda 表达式和流。

当然，你可以争辩说不要在这里重新发明*。 但实际上，为了节省一些自编写的代码行，将兆字节的外部依赖项包含在部署工件中并没有多大意义。

经验表明，最大的问题不是直接引入的依赖，而是传递的依赖。传递的依赖经常与应用程序服务器上已有的库版本冲突，并导致具有挑战性的冲突。在一天的工作时间内，开发人员要花费更多时间来管理这些冲突，而不是聚焦在将小功能实现到项目中所需的时间。这主要适用于具有技术驱动而非用例驱动的依赖关系的情况。

有关简单的 Java EE 7 项目Maven项目对象模型（POM）的文件启发，请参阅清单 3，该文档受Adam Bien的启发 Java EE 7 Essentials Archetype.

<project xmlns="http://maven.apache.org/POM/4.0.0"
     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
     xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
 <modelVersion>4.0.0</modelVersion>
 <groupId>com.sebastian-daschner</groupId>
 <artifactId>game-of-duke</artifactId>
 <version>1.0-SNAPSHOT</version>
 <packaging>war</packaging>      

 <dependencies>
     <dependency>
          <groupId>javax</groupId>
          <artifactId>javaee-api</artifactId>
          <version>7.0</version>
          <scope>provided</scope>
     </dependency>
 </dependencies>      

 <build>
     <finalName>game-of-duke</finalName>
 </build>      

 <properties>
     <maven.compiler.source>1.8</maven.compiler.source>
     <maven.compiler.target>1.8</maven.compiler.target>
     <failOnMissingWebXml>false</failOnMissingWebXml>
     <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
     </properties>
</project>

清单3. Java EE 7 Maven POM 文件

当然，有时应用程序确实需要集成对于实现软件目标至关重要的库。但是，这些依赖关系需要通过业务需求来证明。一般来说，它很有意义，可以节省时间和精力来最小化外部生产库。

对于测试依赖关系，这是一个不同的故事，因为库，例如JUnit，Mockito或者在某些情况下，Arquillian - 是至关重要的。 但同样，关注测试依赖项列表也是有意义的。

5.精简部署 Artifacts

由于应用程序服务器知道Java EE API，因此该API不必包含在部署 artifact 中。 只包含业务逻辑 - 只需最少的胶水代码和交叉关注点。

因此，这些千字节大小的工件可以使构建时间非常短，因为构建过程不需要复制很多东西。这可以在每个构建上产生几秒钟的差异。 如果总结开发人员和持续集成（CI）服务器所花费的所有额外时间，那就会产生很大的不同。项目建设的频率越高 - 对于持续交付（CD）情景尤其如此 - 影响越大。

除了较短的构建时间外，小型部署 artifacts 还可确保较短的发布和部署时间。 由于实现已经包含在运行时中，所以在所有情况下，移动部件花费的时间都是最小的。

6.Docker的理想框架

这正是Java EE成为Docker等容器技术的完美框架的原因。Docker 镜像基于图层，构建图像时，基本图像已包含操作系统，Java运行时和应用程序。因此，在每个构建中添加的唯一内容是部署工件的最后一个千字节薄层。与胖WAR或独立JAR方法相比，这节省了时间和存储 - 不仅在每个构建上，而且在图像版本化或发布版本时 。

无论在哪个阶段，拥有精简的部署 artifacts 都可以实现非常快速和高效的部署管道。

7.现代应用服务器

J2EE 应用程序服务器是重量级软件在启动和部署时间，安装大小和资源占用空间方面的体现。 但是在 Java EE 的新世界中，这已不再适用。

所有现代Java EE 7应用程序服务器（如WildFly，Payara，WebSphere Liberty，Profile和TomEE）都可在几秒钟内启动和部署。由于内部，全面的模块化，他们只能加载所需的组件并尽快部署精简的应用程序 artifacts。

现在的安装尺寸和占地面积非常合理。 应用程序服务器不会消耗比简单的 servlet 容器更多的东西，但它具有完整的 Java EE 功能。 有趣的是，现在运行的浏览器实例消耗更多内存。

话虽如此，每个服务器只部署一个应用程序是可能的，也可以是合理的 - 无论是在容器中还是在内部。 通过“每个容器每个应用程序服务器一个应用程序”方法，您可以为现代微服务架构提供高效且灵活的解决方案。

8.打包

在打包过程中，不应该继续使用EAR文件了。将整个应用程序部署在独立的专门的服务器上，要求我们在那个环境中必须可以访问所有的组件方法，这样做可以节省更多的构建和部署时间。除此之外，这还避免了EAR文件倾向于导致的类加载层次结构问题。

在大多数云和微服务部署中，使用独立的JAR包。 它们包含应用程序和运行时实现。 在Java EE领域，这种方法可以使用特定于供应商的工具链来实现，例如 WildFly Swarm，Payara Micro 或TomEE Embedded。

但是，由于上述原因，我强烈建议尽可能将业务逻辑与运行时分开。 这意味着将应用程序打包在仅包含应用程序代码的WAR文件中。

在我看来，如果由于公司“政治”问题而不是技术原因而无法控制安装或操作流程，则独立 JAR 文件是一种有用的解决方法。 然后运送部署工件中所需的所有内容并且只需要 JRE 时可以解决相当多的非技术问题。

9.关于高效研发进程的建议

企业项目最有效的解决方案之一如下：

• 仅在提供 API 时使用 Java EE 7 和 Java 8
• 构建一个千字节大小的 WAR 文件，其中仅包含业务逻辑和最小管道（例如 JAX-RS 资源或JPA）
• 构建 Docker 镜像 - 仅将 WAR 文件添加到包含已配置的应用程序服务器的基础镜像
• 通过使用容器部署应用程序的 CD 管道进行传送

10.结论

“重量级 Java EE”的日子肯定结束了。 Java EE 中包含的 API 提供了高效且愉快的开发人员体验以及标准内的无缝集成。 特别是，将应用程序代码与运行时分离的方法可实现快速，高效的开发过程。

通过由多个供应商发起的新MicroProfile计划，将来可能会进一步缩小Java EE所需的组件。

参考资料

• Java EE 7 Essentials Archetype
• 博客文章: "Stop saying 'heavyweight'"
• Java EE circuit breaker implementation

原文：https://community.oracle.com/docs/DOC-1008823

作者：Sebastian Daschner

译者：[KeepGoingPawn](https://blog.csdn.net/hengji666

---

9月福利，关注公众号

​

后台回复：004，领取8月翻译集锦!

​

往期福利回复：001，002, 003即可领取！