27

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

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

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

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

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

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

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

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

谢谢！

4

6 回答 6

21

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

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

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

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

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

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

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

于 2010-02-15T21:21:56.693 回答
9

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

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

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

于 2010-01-29T12:14:55.377 回答
5

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

我也一直使用热部署，并即时更新我的​​应用程序的某些部分，而无需重新启动。

于 2010-02-09T10:24:46.767 回答
4

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

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

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

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

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

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

于 2010-01-29T18:43:17.383 回答
4

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

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

I added the following slides and I will follow up with example code to demonstrate how to work successfully with OSGi if it is forced on you. http://www.slideshare.net/ielian/tdd-on-osgi

于 2014-01-28T00:09:09.600 回答
-1

No, OSGI will make you grey early.

于 2014-09-15T19:52:38.820 回答