OSGi 能否帮助降低复杂性?

2022-09-01 15:43:29

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

我想知道OSGi承诺解决的问题是否是一个问题......?这让我想起了OO的早期,当时类似的索赔是女仆:

当OO是新的时,最大的争论是可重用性。人们普遍认为,当使用OO时,人们只需要“写一次”,然后就可以“到处使用”。

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

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

我认为,应用OSGi时最困难的问题是“正确”地实现模块化。与在OO中获取正确的类接口类似,使用OSGi,问题保持不变,这次是更大的规模,包甚至服务级别。

正如您可能已经猜到的那样,我目前正在尝试评估OSGi以用于项目。我们遇到的主要问题是,随着代码库的增长,复杂性越来越高,我想将系统分解成更小的模块,这些模块具有越来越少的交互。

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

谢谢!


答案 1

OSGi之所以有回报,是因为它在运行时强制实施模块化,这是你以前没有的,通常会导致纸上的设计和实现渐行渐远。在开发过程中,这可能是一个巨大的胜利。

如果你让团队专注于单个模块(可能是一组捆绑包),并且如果你正确地实现了模块化,这绝对有助于使团队中的工作更容易。有人可能会争辩说,可以使用像Ant +Ivy或Maven这样的构建工具以及依赖项来做同样的事情,在我看来,OSGi使用的依赖项的粒度要优越得多,而不会导致JAR级依赖项导致的典型“拖入所有内容加上厨房水槽”。

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

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

只要你能管理你的模块和依赖关系,大项目就保持可管理性,并且可以很容易地发展(将你从可以说是糟糕的“完全重写”中拯救出来)。

OSGi的缺点是什么?这是一个非常低级的框架,虽然它很好地解决了它所针对的问题,但还有一些事情你仍然需要自己解决。特别是如果你来自Java EE环境,在那里你可以获得自由线程安全和其他一些概念,如果你需要它们,它们可能非常有用,你需要自己在OSGi中为这些概念提出解决方案。

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


答案 2

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

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

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


推荐