java - Glassfish 上的 OSGI 束间通信

Question

我正在尝试从一些自定义 OSGI 平台迁移到 Glassfish，以便于维护并更快地实现新包。

我在迁移时遇到了问题。所以我有 BundleA 和 BundleB，它们应该通过服务引用进行通信。引用接口(interface)位于 BundleC 上，它是自定义平台上的主要 bundle 。没有 BundleC，任何东西都无法启动，包括平台本身。所以我把接口(interface)放到了BundleC上。 BundleB 具有实现该接口(interface)的类，并在启动时将其注册为服务，而 BundleA 使用该服务。

在迁移到 Glassfish 时，因为它已经提供了适当的 OSGI 平台，所以我不需要旧的 BundleC。那么，在删除 BundleC 之后，除了导出和导入类或包含一个用于启动的包之外，如何提供正确的包间通信？我希望 BundleA 和 BundleB “几乎”独立，而不是耦合。

对于这种情况有什么解决办法吗？或者我仍然需要 BundleC 作为某种中间件？

Answer 1

假设您有以下设置:

                     Service    
  +-------+                                +-------+
  |   A   |---get------|>---register-------|   B   |
  +-------+             .                  +-------+
      !                 .                     !
      !         [service package]             !
      !                 .                     !
      !             +-------+                 !
      \----import-->|   C   |<---import-------/
                    +-------+

这意味着有 2 个生命周期。首先，A 和 B 必须针对 C 进行解析。C 的目的是将 A 和 B 彼此解耦，因为它包含唯一的共享部分，即接口(interface)。因此，从纯粹的耦合问题来看，这一般来说一点也不坏，很多人都推荐它。

然而，这个模型的问题是你会得到很多仅包含接口(interface)的微不足道的小包(尽管称其为中间件似乎有些牵强)。

因此，我通常选择其中一个 bundle 并使其导出服务包。所选的 bundle 必须是服务的提供商。这通常是您的服务接口(interface)的实现者(但不一定是，请阅读 OSGi Semantic Versioning Whitepaper 了解详细信息)。提供者是履行服务接口(interface)包所定义的服务契约的包。服务的提供者可能是bundle B。

然后，Bundle B 将导出服务接口(interface)的包。 Bundle A 导入此包。这提供了一个非常好的依赖模型:Bundle A 依赖于服务接口(interface)的包，但不依赖于 Bundle B。接口(interface)包的任何其他提供者也可以工作。同时，直到至少有一个提供者导出包之后，bundle A 才会启动。因此，您拥有一个非常好的依赖项管理解决方案，并且只需要 2 个 bundle ，而不是 3 个。

  +-------+                                +-------+
  |   A   |---get------|>---register-------|   B   |
  +-------+             .                  +-------+
      !                 .                     ^
      !         [service package]             !
      !                 .                     !
      \----import-----------------------------/

在 bnd(tools) 中，这很简单，只需将服务包添加到您的 Export-Package header 中，bnd 就会将该包从类路径复制到包 B 中。确保标记要使用的包的提供复选框适合导入的版本范围。