java - 与 EAR 包装相比，WAR 包装有什么缺点吗？

Question

我有一个关于 EAR 打包在 Java EE 应用程序中的优点和缺点的一般架构问题。我有一个部署在多个服务器环境中的 Java EE 业务应用程序。该应用程序由以下主要模块组成:

• 具有业务逻辑的 EJB
• 网络用户界面
• REST API

在不考虑当前不同模块的更多细节的情况下，我将这些模块打包到一个 EAR 中以部署在 GlassFish 或 WildFly 等应用服务器上:

  my.ear
  /
  +- META-INF/
  |  |- application.xml
  |- my_ejb_module.jar
  |- my_web_module.war
  |- my_restservice.war

最近WebService和微服务架构被讨论的越来越多，不知道这种封装是不是有点过时了？

在我开始这个项目几年后，这种打包似乎是最好的解决方案，因为包含业务逻辑的 EJB 模块在两个 Web 模块之间共享。

但是当我今天看自包含的微服务时，我想知道将应用程序拆分为两个可部署的 Web 模块是否更好，每个模块都包含 EJB 模块:

  web-ui.war
  /
  +- WEB-INF/lib
  |  |- my_ejb_module.jar
  |- my_web_module.war

  restservice.war
  /
  +- WEB-INF/lib
  |  |- my_ejb_module.jar
  |- my_restservice.war

在此设置中，我将能够在单独的机器上部署 REST API。因此看起来该方法对 EAR 打包没有不利影响。

这是真的吗？我的问题是关于交易的。如果两个 Web 模块在 EAR 包中共享同一个 EJB 模块，有什么优势吗？还是第二种方法(两个 Web 模块都包含相同的 EJB 模块)提供了有关事务处理和并发性的相同功能？特别是当两个 Web 模块都部署在同一个应用程序服务器上时。

目前我能看到的唯一缺点是，我的 EJB 模块不能包含 Java EE TimerServices 或 MessageDriven EJB，因为部署在 war 模块中时不支持这些类型的 EJB。但这对我来说是可以接受的。

Answer 1

我试着自己回答我的问题:在进行了一些测试部署后，我得出结论，在我的情况下，拆分是不可能的。原因是，我的 ejb 模块包含 JPA 实体 bean。如果我部署两个包含相同实体 bean 的 Web 模块，这将破坏任何 JPA 缓存概念。仅当两个 Web 模块使用相同的 REST 服务来访问 JPA 实体 bean 时，才有可能进行分离。

所以我的示例部署应该是这样的

web-ui.war
  /
  |- my_web_module.war

restservice.war
  /
  +- WEB-INF/lib
  |  |- my_ejb_module.jar
  |- my_restservice.war

其中 restservice.war 是包含业务逻辑和数据库层(JPA 实体 bean)的主要模块，还发布了一个开放的 REST API。web-ui.war 仅包含一个 Web 应用程序，该应用程序通过来自 restservice.war 的 REST API 进行交互。但是将 ejb 模块捆绑在两个 web 模块中是一种不好的做法。 EAR 打包在将所有模块捆绑在一起的情况下是有意义的，并且提供了所有客户端模块(war 模块)可以透明地访问相同的 EJB 模块并以事务保存方式的优势。

因此，包含 JPA 实体 bean 的 EJB 模块应该只部署一次，而不应捆绑到多个部署单元中。