嵌入式OSGi或应用程序包

Question

我刚刚花了两天的时间阅读所有可以得到的OSGi内容，我终于认为我已经掌握了它。

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

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

1. 我的整个应用程序应该成为默认安装在容器中的OSGi包;或
2. 我的应用程序应该启动一个嵌入式OSGi容器，并与所有插件服务进行交互。

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

Answer 1

对于选项1）你真的不希望你的整个应用程序在一个包中 - 你将失去OSGi的所有好处 - 但实际上这取决于你的应用程序的大小。

这实际上取决于您希望运行应用程序的位置以及您希望它执行的任务。此外，您可能希望使用某种远程访问来访问公开的服务。

选项1中的

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

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

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

我的建议是不要过于担心OSGi运行时开始 - 但是从OSGi开发开始 - 没有什么能阻止你开发“OSGi风格”并在标准的JRE环境中运行。

Answer 2

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

1. 它将改善您自己代码的模块化。您甚至可能会发现它的某些部分可以在原始应用程序之外提供使用服务。
2. 从OSGi内部使用其他捆绑包比从宿主应用程序更容易。由于主机应用程序无法看到捆绑包的类（并且捆绑包只能看到您从主机中明确显示的内容），因此您必须设置一个非常复杂的类路径或使用反射从容器外部调用捆绑包。

所以我会说即使在短期内，选项1也可能更容易。

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

Answer 3

我宁愿选择选项2， 本质上，您的应用程序不是捆绑包，而是应用程序。 如果您想要添加OSGi值，请从您的应用程序中生成OSGi容器。 这样，如果您决定放弃OSGi，将来可以做一个简单的方法。

Answer 4

你看过Spring Application服务器了吗？这不允许你管理这些东西吗？

Answer 5

我肯定会推荐1 - 应用程序应该成为一个OSGi包，而不仅仅是因为易于更新。如果你的一半代码在OSGi框架中，而另一半在外面，你将不得不为两半之间的通信构建一个桥梁;您也可能遇到类可见性问题。

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

• 将应用程序分成尽可能合理的模块。

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

• 分隔您在单独的捆绑包中使用的所有外部/开源库。它们很可能是必须更频繁地更新的部分，并且在与您自己的代码不同的时间轴上。这里更重要的是定义明确的包依赖关系，包版本，并避免依赖于实现部分而不是仅仅依赖于接口！

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

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

• 作为最后的提示 - 看看您选择的OSGi框架中已有哪些捆绑包。 OSGi规范定义了许多标准的OSGi接口 - 用于配置，日志记录，持久存储，远程连接，用户管理，事件等等。由于它们是标准的，因此您可以使用它们而不依赖于任何特定的OSGi实现。并卸载您不需要的内容。