在Wildfly中,OSGI可以替代模块间服务注入？

Question

我们正在解开经典的传统单片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.

Answer 1

既然你在询问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模块也有办法解决这个问题,但我从他们的文档快速扫描中找不到任何东西.

无论如何,正如我在上面的评论中所说,我对你的动机感到困惑.您显然可以从OSGi提供的服务模型中获益,并且红帽仍然可以支持JBoss-OSGi ......那么为什么不继续使用它？特别是如果没有任何东西可以通过WildFly开箱即用,可以满足您的需求.