10

在过去的两天里，我刚刚阅读了所有我能拿到的 OSGi 东西，我终于认为我已经掌握了它。

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

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

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

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

4

5 回答 5

2

for option 1) you really don't want your whole application in one bundle - you would loose all the benefit from OSGi - but really that depend on the size of your application.

It really depends where you want to run application and which task you want it to perform. Also you probably want to have some kind of remoting to access the exposed services.

in option 1) you need to enable some kind of http/servlet bundle (there is a bridge that exists) in option 2) you application can run inside an application server so you don't have to worry about that.

The first question you want to ask yourself is about the operational environment. Who is going to run the application? Do they need/want to be trained on OSGi? Are they more comfortable with the J2EE stack?

I think the best option for you is to keep your options open, there is no real differences between 1) and 2) but what is staring the OSGi framework, either your code or the framework code. Your application itself, ie the bundles constituting your application will be exactly the same.

My advice would be not to worry too much about OSGi runtime to start with - but start on OSGi development - nothing stop you from developing "OSGi-style" and running in a standard JRE environment.

于 2009-02-01T22:35:00.627 回答
1

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

  1. 它将提高您自己代码的模块化。您甚至可能会发现它的某些部分可以提供原始应用程序之外的使用服务。
  2. 从 OSGi 内部使用其他包比使用主机应用程序要容易得多。因为主机应用程序看不到包的类（并且包只能看到您从主机显式公开的内容），所以您必须设置一个非常复杂的类路径或诉诸反射以从容器外部调用包。

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

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

于 2009-02-10T00:24:58.913 回答
1

我宁愿选择选项 2，本质上您的应用程序不是一个捆绑包，而是一个应用程序。如果您想要增加 OSGi 价值，请从您的应用程序中生成 OSGi 容器。这样，如果您决定在未来某个日期离开 OSGi，您可以通过一种简单的方式进行操作。

于 2010-10-31T06:17:01.793 回答
0

你看过 Spring 应用服务器吗？这不能让你管理这些东西吗？

于 2009-02-01T15:14:52.153 回答
0

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

1的好处也很多，实现起来也不是那么难。我会推荐以下内容：

  • 在您认为合乎逻辑的情况下，将应用程序分成尽可能多的模块。

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

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

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

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

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

于 2012-06-01T09:27:13.470 回答