我正在尝试从一些自定义 OSGI 平台迁移到 Glassfish，以便于维护并更快地实施新的捆绑包。
我在迁移时遇到了一个问题。所以我有 BundleA 和 BundleB，它们应该通过服务引用进行通信。参考的接口在 BundleC 上，它是自定义平台上的主要包。如果没有 BundleC，什么都不会启动，包括平台本身。所以我把接口放在了BundleC上。 BundleB 具有实现接口的类，并在启动时将其注册为服务，而 BundleA 使用该服务。
在迁移到 Glassfish 时，由于它已经提供了合适的 OSGI 平台，我不需要旧的 BundleC。那么在删除 BundleC 之后，除了导出和导入类或包含一个用于启动的包之外，如何提供适当的包间通信？我希望 BundleA 和 BundleB “几乎”独立，而不是耦合。
这种情况有什么解决办法吗？或者我仍然需要那个 BundleC 作为某种中间件？
【问题讨论】：
假设您有以下设置：
Service
+-------+ +-------+
| A |---get------|>---register-------| B |
+-------+ . +-------+
! . !
! [service package] !
! . !
! +-------+ !
\----import-->| C |<---import-------/
+-------+
这意味着有 2 个生命周期。首先 A 和 B 必须针对 C 进行解析。C 的目的是使 A 和 B 彼此分离，因为它包含唯一的共享部分，即接口。所以从纯粹的耦合问题来看，这总体上还不错，很多人都推荐它。
然而，这个模型的问题是你会得到很多只包含接口的小包（虽然称它为中间件似乎有点牵强）。
因此，我通常选择其中一个捆绑包并将其导出服务包。选择的捆绑包必须是服务的提供者。这通常是您的服务接口的实现者（但不一定是，请阅读OSGi Semantic Versioning Whitepaper 了解详细信息）。提供者是履行服务接口包所定义的服务契约的捆绑包。服务的提供者很可能是 B 包。
Bundle B 然后会导出服务接口的包。 Bundle A 导入这个包。这提供了一个非常好的依赖模型：Bundle A 依赖于服务接口的包，但不依赖于 Bundle B。接口包的任何其他提供者都可以正常工作。同时，在至少有一个提供程序导出包之前，包 A 不会启动。所以你有一个非常好的依赖管理解决方案，只需要 2 个包而不是 3 个。
+-------+ +-------+
| A |---get------|>---register-------| B |
+-------+ . +-------+
! . ^
! [service package] !
! . !
\----import-----------------------------/
在 bnd(tools) 中，这很简单，只需将服务包添加到您的 Export-Package 标头，然后 bnd 会将包从类路径复制到包 B。确保您标记要使用的包的提供复选框导入的正确版本范围。
【讨论】：
如果我正确理解您的架构，我认为您做的是正确的事情，除了因为您现在使用 Glassfish 作为您的 OSGI 容器，您应该不需要 bundle C 中的任何东西，除了您的服务接口的定义.
bundle C - 应该只定义服务接口（不提供实现）。 bundle B - 实现了 bundle C 定义的服务接口，并将自己注册到 OSGI 容器作为该接口的服务提供者。
bundle A - 依赖于 bundle C 中定义的服务接口。
【讨论】：