Java 嵌入式OSGi或应用程序包

我刚刚花了两天的时间阅读了所有OSGi的资料，我想我终于明白了

我现在正试图将其与现有应用程序集成，原因有很多，比如第三方插件、自动更新，更不用说SOA让我感到高兴了

我现在有一个我正在努力做的决定，那就是天气

我的整个应用程序应该成为默认安装在容器中的OSGi包；或

我的应用程序应该启动一个嵌入式OSGi容器，并为所有插入的服务与之交互

---

我更喜欢1，因为这让我可以轻松地更新应用程序，并且体系结构是一致的。当然，我希望必须将应用程序重构为许多更小的包。然而，2在短期内使事情变得容易，但在将来会变得尴尬。

您看过Spring应用服务器吗？这难道不允许您管理这些东西吗？

对于选项1）您确实不希望将整个应用程序放在一个捆绑包中—您将失去OSGi的所有好处—但这实际上取决于应用程序的大小

这实际上取决于您希望在何处运行应用程序以及希望它执行的任务。此外，您可能还需要某种远程处理来访问公开的服务

在选项1）中，您需要启用某种http/servlet捆绑包（存在一个网桥） 在选项2）中，您的应用程序可以在应用程序服务器内部运行，所以您不必担心这一点

您想问自己的第一个问题是关于操作环境的。谁将运行该应用程序？他们需要/想要接受OSGi培训吗？他们对J2EE堆栈是否更满意

我认为最好的选择是保持选项的开放性，1）和2）之间没有真正的区别，但是OSGi框架的出发点是什么，无论是您的代码还是框架代码。应用程序本身（即构成应用程序的包将完全相同）

---

我的建议是不要过分担心OSGi运行时，而是从OSGi开发开始，没有什么可以阻止您开发“OSGi风格”并在标准JRE环境中运行。

我认为您希望使用选项1，并让您的应用程序由一组包组成（大部分是开箱即用的）OSGi容器

它将改进您自己代码的模块化。您甚至可能会发现，它的某些部分可以提供原始应用程序之外的服务

从OSGi内部使用其他捆绑包比从主机应用程序更容易。因为主机应用程序看不到bundle的类（而bundle只能看到您从主机显式公开的内容），所以您必须设置一个非常复杂的类路径，或者求助于反射从容器外部调用bundle

所以我想说，即使在短期内，选择1可能更容易

---

此外，我同意Patrick的断言，即大部分代码不需要关心它是在OSGi中运行还是在普通JVM中运行。特别是在使用声明性服务时，代码中使用OSGi接口和机制的需求大大减少：只需向jar的META-INF中添加一些描述符文件即可。

我宁愿选择选项2， 您的应用程序本质上不是一个捆绑包，而是一个应用程序。 如果希望增加OSGi值，请从应用程序中生成OSGi容器。

---

这样，在将来的某个日期，如果你决定离开OSGi，你可以用一种简单的方式来做。

我绝对推荐1-该应用程序应该成为一个OSGi捆绑包，而不仅仅是因为易于更新。如果一半的代码在OSGi框架中，一半在外部，那么您必须为这两部分之间的通信构建一座桥梁；您还可能在类可见性方面存在问题

1还有很多好处，实现起来并不困难。我的建议如下：

• 将应用程序按您认为合理的数量分成多个模块

您不必拥有很多模块——OSGi可以轻松处理两个10 MB的捆绑包以及100个较小的捆绑包。分离应该是功能本身的结果-一个好的起点是UML架构图，您可能在开始实现这些东西之前就已经做了。不同功能部件相互通信的地方正是您应该考虑定义接口而不是类的地方——这些接口将成为您的OSGi服务，实现将成为捆绑包——下一次您必须更新某些部件时，您将发现它预测对应用程序其他部分的影响要容易得多，因为您清楚地将其分开，并在捆绑包的清单中声明了它

• 将您在单独的捆绑包中使用的任何外部/开源库分开。它们很可能是那些需要更频繁更新的部分，并且更新的时间与您自己的代码不同。这里更重要的是定义清晰的包依赖关系、包版本，并避免依赖于实现部分而不仅仅是接口

• 考虑一下你想向插件公开应用程序的哪些部分。然后用这些部分创建OSGi服务，即在OSGi注册表中发布接口。您不需要实现任何特定的东西——您可以发布任何Java对象。然后插件将使用regitry进行查找

• 插件也是如此——想想你想从插件中得到什么，定义插件可以实现和发布的相应接口，你的应用可以在注册表中查找

• 作为最后一个提示，请查看哪些捆绑包已经可用