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所需的组件。

参考资料

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

作者:Sebastian Daschner

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

9月福利,关注公众号

后台回复:004,领取8月翻译集锦!

往期福利回复:001,002, 003即可领取!

img

猜你喜欢

转载自www.cnblogs.com/liululee/p/11517579.html
今日推荐