OSGi 可以帮助降低复杂性吗？答案

【问题标题】：Can OSGi help reduce complexity?OSGi 可以帮助降低复杂性吗？
【发布时间】：2011-01-10 19:49:26
【问题描述】：

我在OSGi 上看到了很多演示文稿，我认为这听起来很有希望实施更好的模块化。显然“热部署”和“并行运行不同版本的 x”也是市长的卖点。

我想知道 OSGi 承诺解决的问题是否甚至是一个问题......？这让我想起了早期的 OO，当时类似的说法是女仆：

当 OO 是新事物时，最大的争论是可重用性。人们普遍声称，在使用 OO 时，只需“编写一次”，然后就可以“到处使用”。

在实践中，我只看到这适用于一些非常低级的示例。我认为这样做的原因是编写可重用的代码很难。不是从技术上讲，而是从界面设计的角度来看。您必须预测未来的客户将如何使用您的课程并预先做出正确的选择。从定义上讲，这很困难，因此潜在的可重用性优势往往无法实现。

对于 OSGi，我怀疑我们可能会再次信守承诺，为我们实际上没有的问题提供潜在的解决方案。或者如果我们有它们，我们没有足够大的数量和严重程度来证明购买 OSGi 寻求帮助是合理的。例如，“热部署”模块子集绝对是一个好主意，但它真正多久工作一次？有多少不是因为事实证明您对特定问题的模块化错误？多个模块之间共享的模型实体怎么样？这些模块是否都必须同时更改？还是您将对象扁平化为基元并仅在模块间通信中使用这些对象，以便能够保持接口契约？

应用 OSGi 时最困难的问题是，我想，要“正确”模块化。类似于在 OO 中正确获取类的接口，使用 OSGi，问题保持不变，这次在更大的范围内，包甚至服务级别。

您可能已经猜到了，我目前正在尝试评估 OSGi 以在项目中使用。我们面临的主要问题是随着代码库的增长而增加复杂性，我想将系统分解为具有越来越少定义交互的更小的模块。

鉴于没有任何框架可以帮助决定什么要模块化，OSGi 有没有为您带来回报？
团队合作是否让您的生活更轻松？
它是否有助于减少错误数量？
您是否曾成功“热部署”主要组件？
随着时间的推移，OSGi 是否有助于降低复杂性？
OSGi 是否信守承诺？
它达到了您的期望吗？

谢谢！

【问题讨论】：

OSGi 在我看来就像一个伪装的框架。
请创建这个社区维基。

标签： java osgi complexity-theory modularity

【解决方案1】：

OSGi 得到了回报，因为它在运行时强制执行模块化，这是您以前没有的，这通常会导致纸上设计和实现分崩离析。这可能是开发过程中的一大胜利。

如果您让团队专注于单个模块（可能是一组捆绑包），并且正确地进行模块化，那么它肯定有助于更轻松地在团队中工作。有人可能会争辩说，可以使用 Ant+Ivy 或 Maven 等构建工具和依赖项来做同样的事情，我认为 OSGi 使用的依赖项粒度要好得多，不会导致典型的“拖入所有东西加上厨房水槽” JAR 级别的依赖关系导致的。

依赖较少的模块化代码往往会导致代码更简洁、更少，从而导致更容易测试和解决的错误更少。它还提倡尽可能简单直接地设计组件，同时可以选择插入更复杂的实现，或添加缓存等方面作为单独的组件。

热部署，即使您在运行时不使用它，也是验证您是否正确模块化应用程序的一个很好的测试。如果您根本无法以随机顺序启动捆绑包，您应该调查原因。此外，如果您可以更新任意捆绑包，它可以大大加快您的开发周期。

只要您可以管理您的模块和依赖项，大型项目就可以保持可管理性并且可以轻松发展（使您免于可以说是糟糕的“完全重写”）。

OSGi 的缺点？这是一个非常低级的框架，虽然它很好地解决了它打算解决的问题，但仍有一些问题需要您自己解决。特别是如果您来自 Java EE 环境，您可以在其中获得免费的线程安全和其他一些在需要时可能非常有用的概念，您需要自己在 OSGi 中为这些提出解决方案。

一个常见的陷阱是不在 OSGi 之上使用抽象来使普通开发人员更容易做到这一点。永远不要让他们手动弄乱 ServiceListeners 或 ServiceTrackers。仔细考虑什么是捆绑包，什么是不被允许的：您是否愿意让开发人员访问 BundleContext 或者您是否通过使用某种形式的声明性模型对他们隐藏所有这些。

【讨论】：

为什么在 SO 上的 OSGi 知识如此匮乏？您似乎是这里为数不多的能够充分回答 OSGi 相关问题的人之一。
感谢您的客气话。这里有不少经验丰富的 OSGi 开发人员，但我同意应该会有更多。不过，请继续提问，SO 是一个很好的获取和寻找答案的网站！

【解决方案2】：

我已经使用 OSGi 多年了（尽管是在 Eclipse 项目的上下文中，而不是在 Web 项目中）。很明显，该框架并没有让您摆脱对如何模块化的思考。但它使您能够定义规则。

如果您使用包并定义（在设计文档中？口头？）某些包可能无法访问其他包中的类，如果不强制执行此约束，它将被破坏。如果您雇用新开发人员，他们不知道规则。他们会打破规则。使用 OSGi，您可以在代码中定义规则。对我们来说，这是一个巨大的胜利，因为它帮助我们维护了系统架构。

OSGi 不会降低复杂性。但它绝对有助于处理它。

【讨论】：

【解决方案3】：

我已经使用 OSGI 超过 8 年了，每次我潜入一个非 OSGI 项目时，我都会感到在没有系安全带的情况下超速。 OSGI 使项目设置和部署更加困难，并迫使您提前考虑模块化，但让您在运行时轻松执行规则。以 maven apache camel 为例。当您创建一个新的 maven 项目并将 apache camel 添加为依赖项时，应用程序似乎具有其所有依赖项，并且您只会在运行时注意到 ClassNotFoundExceptions，这很糟糕。当您在 OSGI 容器中运行并加载 apache camel 模块时，未满足依赖关系的模块不会启动，并且您预先知道问题所在。

我也一直使用热部署，无需重启即可即时更新部分应用程序。

【讨论】：

【解决方案4】：

我在一个项目中使用了 OSGI（我承认 - 不是很多）。它提供了很好的承诺，但正如 @Arne 所说，您仍然需要自行考虑如何模块化。

OSGI确实帮助了我们的项目，因为它使架构更加稳定。打破模块化更加“困难”，因此我们做出的关于如何模块化的决定在更长时间内保持有效。
换句话说 - 没有 OSGI，并且在交付时间的压力下，有时您或您的团队成员会做出妥协、捷径和其他黑客行为，从而失去了架构的初衷。

因此，OSGI 本身并没有降低复杂性，但它保护它不会随着时间的推移而不必要地增长。我想这是一件好事:)

我没有使用热部署功能，所以我无法对此发表评论。

回答你的最后一点，它确实符合我的期望，但它需要一个学习曲线和一些适应，而且回报只是长期的。

（作为旁注，你的问题让我想起了“maven 是构建系统的 awt”这句格言）

【讨论】：

我之前没有听说过“maven 是构建系统的主宰”的说法，并且无法通过 Google 找到它。有链接吗？
来自此链接：prezi.com/ngwwf1wcfn7n/your-next-sucessful-build ...演示文稿正下方的文字：“使用 Maven2 构建工具就像 AWT 对 UI 框架：革命性的，但并非没有缺点。”

【解决方案5】：

OSGi 没有回报。事实上，OSGi 并不容易使用，并且在一天或一年结束时，取决于您需要多长时间才能使事情正常工作，它不会增加价值：

您的应用程序总体上不会更加模块化，相反，它最终会更加暴露并且不会与其他应用程序隔离，因为它是共享所有内容而不是共享任何内容。
版本控制被进一步推到堆栈中，您与 maven 传递依赖项搏斗，只是为了在 OSGI 运行时再次这样做。
大多数库被设计为在应用程序类加载器中作为库工作，而不是与它们自己的类加载器捆绑。
可能适用于需要对第三方开发人员进行沙盒处理的插件架构，或者可能只是重新使用 EJB2.0。

我添加了以下幻灯片，我将跟进示例代码来演示如何成功使用 OSGi，如果它是强加给你的。 http://www.slideshare.net/ielian/tdd-on-osgi

【讨论】：

欢迎来到Stack Overflow。您可能想要扩展您的答案，例如为什么 OSGi 难以使用以及 OSGi 是否有任何好处。您可能想看看How to Answer，它提供了有关如何写出出色答案的有用提示。
感谢您的评论。我希望我包含的幻灯片对此有所帮助。
"分享一切而不是分享拱门。" -> OSGi 子系统。 “版本控制被进一步推到堆栈中，你与 maven 传递依赖作斗争只是为了在 OSGI 运行时再次这样做。”-> 当存在版本冲突时，它实际上解决了许多与传递依赖相关的问题。 “大多数库被设计为在应用程序类加载器中作为库而不是作为包工作”-> 只有极少数库在 OSGi 环境中使用时存在实际问题（我上次检查时休眠是最好的例子）
我不能再强调我如何支持你的回答了。一年多来，我一直在从事一个小项目，该项目做了很多技巧。最初它是一个小型单体，然后决定模块化，依赖/版本地狱继续存在。一年后，该项目由 100 多个 maven 模块组成，其中大多数包含 2-3 个类，只是为了提供灵活性。我们必须为跨其他团队使用的每个模型对象创建一个对等接口，以隔离对其他库的传递依赖。这是一个包地狱+一个依赖地狱。

【解决方案6】：

不，OSGI 会让你早早变灰。

【讨论】：

这没有提供问题的答案。要批评或要求作者澄清，请在其帖子下方发表评论。
那么这个怎么样？鉴于没有任何框架可以帮助决定模块化什么，OSGi 有没有为您带来回报？否团队合作是否让您的生活更轻松？否是否有助于减少错误数量？否您是否曾成功“热部署”主要组件？否 OSGi 是否有助于随着时间的推移降低复杂性？否 OSGi 是否信守承诺？否是否满足您的期望？没有
承认@Jeb 的最后一条评论充满了有时是多余的批评，我可以根据我的经验列出多个案例来证明他是对的。此外，许多主要框架放弃了对 OSGI 的支持，使用第三方库成为一个真正的问题，即使运行时包装到包，例如由 Apache Karaf 提供。一位聪明人的一句话非常准确地描述了我多年使用 OSGI 的经验——“听起来不错，但行不通”。
在一家公司合并 osgi 和非 osgi 项目至少具有挑战性。如果您甚至想重用来自其他团队的 pojo，比如说，来自您未使用或无法向服务用户公开的库中的注释，这真的很困难。向 pojo 添加新字段成为一项艰巨的任务，因为您必须记住使用这个新事物来增加服务的版本。我个人并没有发现 osgi 可以证明引入另一个复杂性向量的合理性。如果要隔离，使用 spring 和 docker 会容易得多。其余的纯粹是浪费时间（我的观点）。