Design patterns OSGi应用程序设计-我是否滥用了服务框架？

在我们正在开发的应用程序中，我为要实现的数据提供程序组件提供了一个公共接口，我将这些提供程序作为服务连接起来

我的一位同事建议，最好只创建一个服务来跟踪这些实现（目前有多少个可用，也许可以通过getter将它们提供给代码库的其他部分），我们可以使用实现包的激活器来注册/注销它们

虽然这通常是可行的，但这（几乎）正是服务层首先提供的，对我来说，这就像是在复制功能

---

你觉得怎么样？

那将是复制功能。您管理其他有效服务的服务将成为服务注册中心

现在，您的任何服务都依赖于您的数据提供商，也依赖于您的服务管理器，只有这样，它们才能进行查找以获得所需的实际服务

最好是将实际需要的依赖项注入到实际需要它的代码中，有许多工具（DS、Spring DM、Blueprint…）将根据规范中定义的功能提供此功能。即，服务注册表

---

更新：如果您正在进行动态加载，正如您所暗示的，那么OSGi已经为此提供了一个ServiceListener，消费者需要了解这一性质并进行适当的编码。上述工具也可以处理这些情况。

您可以查看以下页面：http://www.ibm.com/developerworks/websphere/techjournal/1007_charters/1007_charters.html

---

希望对您有所帮助

您的用例是service registry的主要OSGi用例之一。service registry主要用于需要在未耦合的模块之间共享实例的此类应用程序

使用您获得的服务注册表：

声明性服务或Blueprint等工具允许您不耦合到OSGiAPI

事件

内省

并发性

任何模块都可以加入池，而无需更改中心配置

具有强大过滤器的可选择性（可通过DS配置运行时）

现有shell的可调试性

标准化

---

OSGi的主要用途始终是为其他人提供服务的独立模块，例如黑板编程模型。这提供了一个非常优雅的对等解耦编程模型。整个类加载战争总是掩盖了这一点。

这是不必要的重复，因为您不希望将代码与OSGi框架分离。正如您和Robin所注意到的，您将重新实现关于服务注册中心的控制盘。使用org.osgi.util.tracker.ServiceTracker/ServiceTrackerCustomizer将优雅地为您提供“跟踪”功能，如JNDI、JDBC、XML解析器、JAXB插件、安全提供商、，JPA等都是在单个服务存储库的基础上实现的。大多数人不知道，如果我们删除所有带有服务的工厂，Java可以简化多少…：-(