在Wildfly中，OSGI用于模块间服务注入的替代方法是什么？

问题描述：

我们正在解开经典的传统整体EAR封装Java EE应用程序。我们的（最复杂的）组件布线模式如下：组件A'需要'接口X，而组件B和C（... N）'提供'接口X.我们的要求是打包和部署A，B，C和X单独和独立，以最大限度地减少停机时间并尽量减少业务影响。在Wildfly中，OSGI用于模块间服务注入的替代方法是什么？

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

我们已经使用JBoss-OSGI和Weld-OSGI实现了POC，它满足了我们所有的要求，也为我们提供了一条出色的迁移路线。但是，在Wildfly 8 Alpha 3中，JBoss-OSGI已从默认发行版中删除。这让我们认为我们应该探索更符合Wild behind背后人们思想的替代方案。

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

对于预算，简便，性能开销和公司政策的缘故，我们不得不消除如下：
1.远程EJB的
2. Web服务
3. JSON/REST
4。 SCA

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

我很欣赏你不想辩论做的，你说得对，*的不是争论的地方。但是......您说JBoss-OSGi满足了您的所有要求，并提供了一条出色的迁移路径。而且要清楚的是，JBoss-OSGi仍然可用并得到Red Hat的支持，尽管现在作为可选附加组件而不是开箱即用。所以我不太了解这个问题的动机。 –

有效的点。是JBoss-OSGI仍然可以作为附加组件提供。但是，红帽的支持是一个比较棘手的问题，不包括EAP等，这是我首先关注的问题。另外，当Wildfly背后的重要人物没有真正购买它时，在Wildfly上使用JBoss-OSGI是有风险的。我再一次不想辩论他们观点的有效性，但它存在的事实是使用JBoss-OSGI的风险。最后，我觉得我错过了他们为这样一个场景实际想到的更明显的解决方案，并且我在OSGI概念中思考的倾向可能已经让我闭上眼睛。 –

嘿@ArjanTijms，你真的整个*上的巡逻，以确保人们说：“Java EE的”，而不是广泛理解的术语JEE和J2EE？您对术语和商标的投入是令人钦佩的，但有点狭隘地集中......我的意思是为什么不将OSGI改正为OSGi？ –

答

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

什么大卫好像是说既可以是服务本身的纰漏的想法 - 即你不需要他们！ - 或者Java 6中引入的ServiceLoader API已经充分解决了这一要求。

但是，已知ServiceLoader不适用于使用classloader隔离（包括OSGi和JBoss模块）的模块系统。这是因为ServiceLoader使用类路径扫描，并且在模块系统中没有“classpath”。在OSGi中，我们已经指定了一种适应ServiceLoader的方式（尽管它很糟糕并且需要字节码消息传递）。也许JBoss Modules也有处理这个问题的方法，但是我无法从文档的快速扫描中找到任何东西。

无论如何，正如我在我上面的评论中所说的，我对你的动机感到困惑。您显然从OSGi提供的服务模式中受益，而且JBoss-OSGi仍然可用并受到Red Hat的支持...为什么不继续使用它？特别是如果没有明确提供的WildFly开箱即用，无法达到您想要的效果。

非常相关的链接，它澄清了很多。我可以看到David Lloyd会去哪里，但在我们的案例中，我确实认为可以为服务理念提供一个很好的论点。不是因为它是传统的应用程序，所以我无论如何都没那么奢侈。关于我的动机，请参阅我上面的评论。 –

你能否支持声明jboss-osgi仍然可用并受Red Hat支持？据我所知（我已经长时间关注这个问题，也有RH支持），它从未得到红帽的支持，只有社区的努力，现在甚至都没有。它也不能用任何最终版本的Wildfly工作（参见[this]（https://developer.jboss.org/thread/238007）和[this]（https://developer.jboss.org/thread/） 237976）），负责整合的人员（Thomas Diesler）不再是Red Hat的雇员。 – eis

好的，我刚刚注意到这个消息是在2013年编写的。当时至少有一个想法，JBoss-OSGi会得到支持，所以可能这个答案在这方面已经过时了。 – eis

答

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

虽然Felix确实是JBoss-OSGI的替代品，并且您的解决方案可以很好地工作，但它不会让我们远离OSGI。请记住，我们正试图将我们的思想与这方面的蜻蜓8世界联系起来，这是一个没有OSGI的世界。 Wildfly的jboss-modules基础结构为OSGI提供了许多类似的功能，因此某种类似OSGI的解决方案必须可以实现，而不必实际使用OSGI。我会把你的建议放在我的待办事项列表上，尽管... –

'没有OSGI的世界'。 Apache Felix在那里为您提供osgi功能，而不是WildFly。然后，您可以使用IPojo或其他等等......但是您也想摆脱OSGI解决方案，不仅仅是因为使用了WildFly限制？ – Canberk

正确。请参阅我对Neil Bartlett对我推理的评论的回应。 –

答

我在哪里工作，我们只好捡东西，以继续该项目时，JBoss的OSGi的是declared dead。我们采用了JBoss Modules + EJB方法，因为它们实际上受到了Red Hat的支持。 JBoss模块用于静态模块依赖关系，EJB用于运行时注入服务。

我们不使用远程EJB但EJB 3.x的本地EJB，而不是扔掉你的列表，所以我想它的确定提供了这一点。

这的确确实现了模块间注入的需求，但据我所知，当你注入EJB的接口时，必须指定实现。这意味着你在一个特定的实现上创建一个静态依赖关系 - 在我的问题中是B或C. OSGi和Neil提到的Java ServiceLoader框架都提供了一种方法来提供一个接口的多个实现，并且只在运行时决定使用哪一个接口。 –

@AmpieBarnard um。不，你不必指定实现。这点很重要。我们有很多单个接口的实现，您可以更改运行时。 – eis

我很难过。请您附上一些代码，其中您有两个相同接口X的EJB实现（B和C），将接口注入到EJB A中，然后在运行时部署这两个实现，然后决定使用哪个实现？ –

在Wildfly中，OSGI用于模块间服务注入的替代方法是什么？

相关推荐