何时使用ServiceLoader而不是OSGi之类的东西

Question

作为对依赖性过敏的人,我什么时候会使用类似OSGi而不是内置的java 6 http://java.sun.com/javase/6/docs/api/java/util/ServiceLoader.html(我想要的)让插件罐子掉进去).

(仅供参考,这是一个scala应用程序,对任何建议持开放态度,ServiceLoader非常接近我想要的).

Answer 1

如果ServiceLoader最符合您的需求,那就说您正在通过类路径上的文件存在来寻找服务发现.这只是OSGi提供的一小部分.

OSGi将允许您在应用程序运行时动态安装捆绑包,宣传服务,撤消广告和卸载捆绑包.此外,作为服务的消费者,您可以热切地查找它们 - 使用过滤谓词查询 - 并检测提供的服务提供商何时来去.这些束不必位于类路径上,它们可以以各种形式提供; 我记得两个Jar文件和"爆炸目录".

相比之下,ServiceLoader只做一件事:它暴露了可发现的工厂.通常,您将创建一个工厂样式的接口,该接口使用一些参数来确定该提供程序是否可以提供适当的服务,例如将给定的字符集名称映射到a CharsetDecoder.没有用于从这样的提供者获取和发布服务的正式协议.OSGi确实正式确定了消费者与服务的绑定和解除绑定.当新的提供者上线时,消费者可以接收通知,并且当消费者获取和释放服务实例时,提供者可以接收通知.如果这个生命周期控制对您的服务很重要并且您放弃了OSGi,那么您必须自己构建它; ServiceLoader不会那么远.

或者,您可以采用更加被动的声明性方法,而不是急切的服务查找和使用,让其中一个OSGi依赖关系管理器将您指定的需求与可用的服务提供商相匹配.有许多依赖管理器可供选择.Spring Dynamic Modules是最强大的模块之一.

OSGi提供了许多其他"中间件"设施.我不会试图在这里推销你,因为你的问题主要集中在你选择的错过的东西上ServiceLoader.

Answer 2

正如 seh 指出的那样，如果您只对简单的服务发现感兴趣，那么 ServiceLoader 是一种将消费者与提供者分离的轻量级方法。但它不提供将服务组合在一起的任何帮助。

例如，假设服务 A 需要使用服务 B。这是一个“服务依赖”……但是如果 B 不可用，A 该怎么办？在 OSGi 中，我们可以安排如果 B 不可用，那么 A 也不可用——假设依赖是强制性的；我们还可以支持可选的依赖项。另一方面，当使用 ServiceLoader 时，只要包含它的 JAR 位于类路径上，服务 A 就无法控制其可用性……因此，即使没有所需的“后端”服务，它也必须提供其功能。

ServiceLoader 要记住的另一件事是尝试抽象查找机制。发布机制非常好，干净和声明性。但是查找（通过 java.util.ServiceLoader）就像地狱一样丑陋，作为类路径扫描器实现，如果将代码放入任何没有全局可见性的环境（例如 OSGi 或 Java EE）中，它就会严重中断。如果您的代码与此纠缠不清，那么稍后您将很难在 OSGi 上运行它。最好编写一个可以在时机成熟时替换的抽象。