Service OSGi：服务如何在运行时自动发现部署的客户端包？

我有一个场景，在系统安装期间，一些服务被部署到OSGi容器上，这些服务将侦听提供数据的其他捆绑包，并在运行时动态安装和卸载

这些数据提供者不公开任何服务，甚至不应该调用服务；我的想法是使预部署的服务能够侦听这些数据提供程序包的安装事件，如果模式匹配，则处理数据并将其持久化到数据存储中

例如，我有一个WidgetService，它将侦听Widget数据提供程序包的安装或卸载事件，还有一个ShppingCartService，它将侦听ShoppableItem数据提供程序包的安装/卸载事件，等等

这有助于我保持处理和持久化逻辑的集中化，我的数据提供者不需要编写任何代码来处理他们的数据。数据提供程序捆绑包所需要的只是服务名称/id、服务版本、先决条件以及它们需要发布的数据

我读过几篇关于OSGi的文章，其中解释了服务的动态可插拔性，以及客户机能够根据其可用性发现或丢弃服务；然而，这些都是在讨论一些场景，在这些场景中，客户机将智能地发现并执行他们感兴趣的服务

我的意图是让客户机完全不知道任何服务发现，就这一点而言，不知道任何代码。客户机传递的所有信息都是关于客户机所在的服务、依赖项和数据的信息；客户应该是完全沉默的

这在OSGi中可能吗？我准备考虑这个架构，甚至要扩展一些OSGi核心框架类！p> 我在以下位置发现了一些关于堆栈溢出的远程相关问题：

但是，我需要一个钩子或事件，当安装了一个或多个数据提供程序包时，它将调用我各自的服务。这些数据提供程序包可能对系统中安装的任何服务感兴趣。我甚至准备编写一个中央bunle存储库管理器/监听器之类的东西，它将侦听任何捆绑包安装并调用我的服务外观，该外观将根据数据提供程序捆绑包提供的元数据决定执行哪个服务

我刚刚开始OSGi，所以需要一点关于如何前进的指导

如果你们能帮我做到这一点，我会非常感谢你们

我内心深处有一个疑问，这在OSGi中可能不容易实现，即使这是真的，我也准备花时间扩展框架来实现这一点。我所需要的只是一些指导方针和明确的方向。谁知道呢，如果OSGi真的缺少这个功能，那么它将是未来OSGi规范的一个非常有用的附加组件

我希望我能从OSGi社区得到一些帮助

感谢和问候，

---

Samba

您可以查看OSGi核心规范的第4.7节（事件）。当捆绑包的生命周期发生变化时（例如，在安装或卸载捆绑包时），该框架会引发BundleEvents。您需要做的是实现BundleListener，然后它将接收事件，以便您的服务能够对更改做出反应。

我描述了一个我调用的设计模式，它可能是您问题的解决方案

---

您想要调解的项目只需要在服务注册中心注册；所有依赖项都可以由中介器实现管理。

您好，感谢您的支持。我很高兴这可以通过核心OSGi框架本身来实现。我还有一个问题：OSGi服务中不鼓励侦听器模式，我在网上读了几篇文章，建议使用ServiceTracker实用程序的白板模式。是否也有这样的捆绑事件中央存储库处理程序？如果它不可用，我会面临针对侦听器模式吹捧的“bundle事件泛滥”的任何困难吗？你有没有建议解决这个问题的方法？谢谢和问候，SambaIn将军，你说得对。OSGi中不鼓励使用侦听器模式。但这只涉及捆绑包之间的侦听器，而不涉及您向框架注册的侦听器。BundleListener实际上是一个遵循白板模式的服务，也就是说，您不向其他bundle注册侦听器。这样，组件之间的关系非常松散。对于您的另一个问题：不，没有“事件存储库”。但别担心，这些事件只是对注册服务的调用。这是OSGi实现应该很好地处理的事情。非常感谢您的帮助，AKR！现在我相信我可以在OSGi中实现我的预期设计，而无需任何调整。我刚才遇到的另一个有趣的特性是Apache Felix OSGi实现有一个BundleTracker，类似于ServiceTracker实用程序，它将像ServiceTracker一样发布addingBundle（）、modifiedBundle（）和removedBundle（）回调。我不确定这是OSGi标准接口还是Felix扩展。如果您能澄清BundleTracker实用程序是否是OSGi标准，我将非常感谢您！谢谢你，欢迎你。是的，BundleTracker是标准的一部分。查看配套规范，第701.4章。您应该从OSGi web端（www.OSGi.org）下载OSGi规范。该规范实际上相当可读，并且有许多实现示例：-）您好。我知道已经两年了但是。。。在您的描述中，似乎没有任何代码示例。你能提供一个吗？我有兴趣测试这个OSGi中介：）