我刚刚花了两天时间阅读了所有我可以接触到的 OSGi 内容，我终于认为我已经掌握了它。
我现在正尝试将其与现有应用程序集成，原因有很多，例如 3rd 方插件、自动更新，更不用说 SOA 只是让我高兴。
我现在有一个我正在努力做出的决定，那就是天气
我更喜欢 1，因为这让我可以轻松更新应用程序并且架构会保持一致。当然，我希望必须将应用程序重构为许多更小的包。不过2在短期内让事情变得更容易，但在未来会变得很尴尬。
【问题讨论】：
我肯定会推荐 1 - 应用程序应该成为一个 OSGi 捆绑包，这不仅仅是因为易于更新。如果你的代码一半在 OSGi 框架中，一半在外部，你将不得不为两半之间的通信搭建一座桥梁；您还可能遇到类可见性问题。
1也有很多好处，实现起来也不是那么难。我会推荐以下内容：
您不必拥有很多模块 - OSGi 可以轻松处理两个 10 MB 的包以及 100 个较小的包。分离应该是功能本身的结果 - 一个好的起点是您可能在开始实现这些东西之前所做的 UML 架构图。不同功能部分相互通信的地方正是你应该考虑定义接口而不是类的地方——然后这些接口将成为你的 OSGi 服务，实现将成为捆绑包——下一次你将拥有要更新某些部分，您会发现预测对应用程序其他部分的影响要容易得多，因为您清楚地将其分开并在捆绑包的清单中声明了它。
将您在单独的包中使用的任何外部/开源库分开。它们很可能是必须更频繁地更新的部分，并且在与您自己的代码不同的时间线上。这里也更重要的是定义清晰的包依赖关系、包版本，避免依赖于实现部分而不是仅仅依赖于接口！
考虑一下您希望将应用程序的哪些部分公开给插件。然后从这些部分中制作 OSGi 服务 - 即在 OSGi 注册表中发布接口。您不需要实现任何特定的东西——您可以发布任何 Java 对象。然后插件将使用注册表进行查找。
插件也是如此 - 考虑您希望从插件中获得什么，并定义插件可以实现和发布以及您的应用可以在注册表中查找的相应接口。
作为最后一个提示 - 查看您选择的 OSGi 框架中已经提供了哪些捆绑包。 OSGi 规范定义了许多标准的 OSGi 接口——用于配置、日志记录、持久存储、远程连接、用户管理、事件等等。由于它们是标准的，您可以使用它们而不依赖于任何特定的 OSGi 实现。并卸载你不需要的东西。
【讨论】：
我宁愿选择选项 2， 本质上，您的应用程序不是一个捆绑包，而是一个应用程序。 如果您想要增加 OSGi 价值，请从您的应用程序中生成 OSGi 容器。 这样一来，如果您决定离开 OSGi，将来可以通过简单的方式进行操作。
【讨论】：
我认为您希望使用选项 1，并让您的应用程序包含一组位于（大部分是开箱即用的）OSGi 容器内的捆绑包。
所以我想说，即使在短期内，选项 1 也可能更容易。
另外，我同意 Patrick 的断言，即您的大部分代码不需要关心它是在 OSGi 中运行还是在普通 JVM 中运行。特别是在使用声明式服务时，大大减少了从代码中使用 OSGi 接口和机制的需求：您只需将一些描述符文件添加到 jar 的 META-INF 中。
【讨论】：
对于选项 1)，您真的不希望将整个应用程序放在一个包中 - 您会失去 OSGi 的所有好处 - 但这实际上取决于应用程序的大小。
这实际上取决于您要在哪里运行应用程序以及您希望它执行的任务。此外，您可能希望通过某种远程处理来访问公开的服务。
在选项 1）中，您需要启用某种 http/servlet 捆绑包（存在一个桥接器） 在选项 2) 中，您的应用程序可以在应用程序服务器内运行，因此您不必担心。
您要问自己的第一个问题是关于运营环境的。谁将运行该应用程序？他们需要/想要接受 OSGi 培训吗？他们是否更适应 J2EE 堆栈？
我认为对你来说最好的选择是保持你的选择开放，1) 和 2) 之间没有真正的区别，但是什么是盯着 OSGi 框架，无论是你的代码还是框架代码。您的应用程序本身，即构成您的应用程序的包将完全相同。
我的建议是不要太担心从 OSGi 运行时开始 - 但从 OSGi 开发开始 - 没有什么能阻止你开发“OSGi 风格”并在标准 JRE 环境中运行。
【讨论】：
你看过 Spring 应用服务器吗？这不能让你管理这些东西吗？
【讨论】：