10

我们正在解开一个经典的遗留单片 EAR 封装的 Java EE 应用程序。我们（最复杂的）组件布线模式如下：组件 A“需要”接口 X，而组件 B 和 C (... N) 各自“提供”接口 X。我们的要求是打包和部署 A、B、C和 X 分开独立，以最大限度地减少停机时间并最大限度地减少业务影响。

因此，我们需要必要的稳健性以允许在运行时删除和添加（重新部署）接口的提供者（B，C），而无需重新部署接口的消费者（A），也不需要重新启动服务器。该解决方案将在 Wildfly 8 上运行，但只要它们在 Wildfly 8 上运行，就可以使用其他技术。

我们已经使用 JBoss-OSGI 和 Weld-OSGI 实现了一个 POC，它满足了我们的所有要求，并为我们提供了一个极好的迁移路径。然而，在 Wildfly 8 Alpha 3 中，JBoss-OSGI 已从默认发行版中移除。这让我们认为我们应该探索更符合 Wildfly 背后人们的想法的替代方案。

因此，问题是，在 Wildfly 8 上，对于满足我们要求的模块间服务注入的 OSGI 替代方案是什么？

为了预算、简单性、性能开销和公司政策，我们不得不消除以下内容：
1. 远程 EJB
2. Web 服务
3. JSON/Rest
4. SCA

请注意，这不是要求就 OSGI 的可行性进行辩论，也不是要求评估或比较不同的解决方案。我只是在寻找任何符合我们标准且不基于 OSGI 的解决方案。

4

3 回答 3

10

由于您询问的是 WildFly 背后人员的想法，因此我将向您推荐以下邮件列表消息。它由 David Lloyd 发布到 Jigsaw 开发列表中，他（我相信）是 WildFly 所基于的 JBoss Modules 的设计师。上下文是关于将服务模型引入 Jigsaw 的讨论：http: //mail.openjdk.java.net/pipermail/jigsaw-dev/2012-February/002161.html

大卫似乎在说服务本身的想法有缺陷——即你不需要它们！– 或者 Java 6 中引入的 ServiceLoader API 已经充分解决了该要求。

但是，众所周知，ServiceLoader 不适用于使用类加载器隔离的模块系统，其中包括 OSGi 和 JBoss 模块。这是因为 ServiceLoader 使用类路径扫描，并且在模块系统中没有“类路径”。在 OSGi 中，我们已经指定了一种适配 ServiceLoader 的方法（尽管它很糟糕并且需要字节码转换）。也许 JBoss Modules 也有处理这个问题的方法，但我无法通过快速扫描他们的文档找到任何东西。

无论如何，正如我在上面的评论中所说，我对你的动机感到困惑。您显然可以从 OSGi 提供的服务模型中受益，而且 JBoss-OSGi 仍然可用并受到 Red Hat 的支持……那么为什么不继续使用它呢？特别是如果 WildFly 没有明确提供开箱即用的功能来满足您的需求。

于 2013-07-26T10:28:02.747 回答
2

Apache Felix 可以作为“OSGI 主机”嵌入到您的应用程序服务器中。然后您可以为所需的系统创建插件机制。您的所有服务都可以实现为“捆绑包”。服务器中的 OSGI 主机可以在部署文件夹中找到捆绑包，并安装/启动它们。然后您可以启用您的 web 服务、rest 和其他服务，而无需重新启动应用程序服务器。

于 2013-07-26T09:15:45.737 回答
1

在我工作的地方，当 JBoss-OSGi 被宣布为 dead时，我们必须选择一些东西才能继续该项目。我们采用了 JBoss Modules + EJB 方法，因为它们实际上得到了 Red Hat 的支持。JBoss Modules 用于静态模块依赖，而 EJB 用于运行时注入服务。

我们不使用远程 EJB，而是使用 EJB 3.x 本地 EJB，而且您的列表中没有丢弃它，所以我想提供它是可以的。

于 2015-02-19T11:23:24.167 回答