这些方法中的哪一种更适合将Spring Boot应用程序分为三层？

Question

我们正在尝试将大型的单片J2EE应用程序拆分为一组模块，以为所有Web应用程序客户端提供统一的业务逻辑。

我们的目标是拥有更小，更专业的业务模块，以供许多不同的Web应用程序以任何组合使用。这样，我们希望应用程序变得更易于单独维护（与现在高度耦合的单片应用程序相比）。

我们正计划将其安排如下图：

上层的Web Apps调用模块服务以通过方法调用处理业务逻辑（RMI是预期的协议，但我们对其他选项持开放态度。）

J2EE使得通过EJB远程bean在三层上安排服务变得容易。

但是我们还试图将这些模块设置为Spring Boot应用程序（使用Spring Boot JPA Starter），因为它使开发更加方便。

我最初的计划是使用Spring Boot实现模块，并在服务的实际实现中向EJB bean展示一薄层EJB bean作为代理。 EJB bean将使用SpringBeanAutowiringInterceptor类as in spring v4 documentation注入spring bean。

但是由于这种集成was removed from spring v5，我不知道如何进行。

如上所述，他们还考虑“ EJB作为一种已被弃用的技​​术”。但是对于我的用例，我找不到足够好的替代方法。

到目前为止，我已经想到了以下选项：

1. 使用自定义拦截器来解决问题。但这似乎是在重新发明一个废弃的旧轮子（如果这个比喻有意义）。
2. Spring remoting是替代方法，但要使其与Wildfly JNDI一起用于RMI配置并尝试像重新实现EJB远程处理一样，这是一个挑战。
3. Spring Integration对于这个简单的任务，我认为会增加太多的复杂性和开销。
4. 基于消息的集成（JMS，MQTT等）可能不合适，因为我们要实现的目标具有同步性。
5. REST API调用会添加很多样板代码（用于将对象序列化和反序列化为JSON，端点配置等），并且还会增加一些麻烦，因为HTTP处理。

按优先顺序排列的目标是：

1. 使此集成尽可能可靠和可靠。
2. 使从Web层到服务层的业务逻辑调用尽可能简单。
3. 开销尽可能少。

上面所说的全部五个选项（或者也许我没有考虑过的另一个选项）将是最好的方法，为什么？