用于初始化依赖于另一个应用程序 EJB 的 EJB 的模式答案

【问题标题】：Pattern to initialize an EJB that depends on another application EJB用于初始化依赖于另一个应用程序 EJB 的 EJB 的模式
【发布时间】：2014-12-11 09:07:59
【问题描述】：

当 EJB 依赖于位于另一个集群中的另一个应用程序但仍未启动时，我应该如何初始化它？

我该怎么做？

@PostConstruct：也许我可以循环直到依赖的 EJB 可用，但我担心它会超时或阻塞服务器加载过程。
@Schedule：可能会安排初始化过程以避免服务器阻塞，然后仅在初始化完成后才服务请求，否则会抛出错误。

您认为我应该如何进行？你能推荐我一些 Pattern 吗？

【问题讨论】：

在第二台服务器上的一个应用程序中制作 PostConstruct。当第二台服务器启动时，调用 RMI（远程 EJB）并从该 EJB 初始化
@ashokhein 那可能是！但是，应用程序 2 不必知道应用程序 1。这会产生我想避免的耦合和循环依赖。还是谢谢你。
怎么可能是循环依赖。因为这是单向方向。应用 2 ---> 应用 1
@ashokhein 我认为它是：application2 --> application 1 (init) --> application 2。但是，application2 实际上是一个“网关”，因此它执行隧道请求。 app2 的要求是不应该依赖于它的客户端。
我假设您的第一个 (A) 应用程序在第二个 (B) 完全启动之前无法使用。然后我会说在 B 准备好之前启动 A 是没有意义的，所以我会默认将其保持为停止状态。为了避免强耦合，我可能会创建第三个应用程序 - 一个启动器 (S)，它会监视 B 是否准备好，如果准备好，那么它将启动 A。

标签： java jakarta-ee design-patterns architecture ejb-3.1

【解决方案1】：

我认为以上所有建议都是有效的。我认为这是围绕你的问题的环境问题。

根据您是否可以独立启动 A，您可以使用建议的 Gas 之类的第三个元素来保证如果 B 未准备好，A 不会出现（失败或卡住）。

另一方面，如果 A 自动启动并且您无法更改它，那么这取决于您是否可以控制初始化过程何时发生。如果您安排整个依赖链的初始化，它应该可以工作，但是如果您不知道或无法控制B何时上线而A无论如何都会启动，那么别无选择，只能轮询直到B向上。

就个人而言，我已经看到轮询并没有那么糟糕，只要您等待的是可用的快速启动或在失败的情况下快速恢复。

另一方面，您不能通过配置控制集群的启动方式吗？如果你让第二个应用程序的集群总是先启动，你可以避免这个问题。

【讨论】：

感谢您的回答。我不知道真正的问题是底层基础设施（B 应用程序没有集群），还是执行集群的基础设施人员重新启动。无论如何，正如你所说，我认为轮询将是这种情况下的最佳解决方案。

【解决方案2】：

即使您设法解决了 EJB 的初始化问题，您最终也会创建依赖项。从架构上讲，初始化依赖将撤销决定拆分 App#1（网关）和 App#2（服务主机）的原因。

替代建议是让它们保持独立，就像它们目前一样，而是依赖异常处理。如果 App#2 中的服务无法访问，您可以选择抛出“服务不可用，请稍后再试”等自定义异常，或者根据需要，在服务再次可用时将请求合并起来执行。

这也可以保护您在启动后避免 App#2 出现故障，例如如果由于某些内部错误而停机维护或无响应。

【讨论】：