OSGi的盈亏平衡点

Question

现在看来，OSGi是一个热门术语。许多利益被调用：

• 降低复杂度
• 再利用
• 容易部署
• 版本化

(等)

我想要一个非常具体的用例--小型到中型的web应用程序。OSGi会给这些人带来什么好处？这真的值得吗？

Answer 1

尽管我是的忠实粉丝，但我还是会冒险使用NO。除非您正在使用其他OSGi包，或者您有一个特定的问题，如果没有这个大锤，您很难解决这个问题。

好处是优雅的类路径分离(IMHO)。如果您需要同一个JAR/类的不同版本，比如在应用程序运行时升级它的某些部分，或者因为您合并了许多第三方模块，那么OSGi是很棒的。

这不是一件容易实现的事情，用OSGi也不容易实现。它是干净的，但代价是环境堆栈中的另一层。还有很多要学习和维护的工作。

更别提这些文档不是特别的初学者友好了。

我建议学习它--构建Eclipse插件是一种非常好的方法--但在您完全了解它之前，不要将它构建到开发计划中。

Answer 2

我会一如既往地说“视情况而定”。

您的环境

考虑一个没有OSGI经验的现有团队(他们自豪地认为自己是经验丰富的“完成任务”的开发人员。他们有机会经历重大的痛苦或缓慢的开始。

许多开发人员(比您想象的还要多)不熟悉构建工具，比如蚂蚁或Maven，当他们熟悉的时候，他们只使用那些构建工具的有限特性。

创建OSGI最好使用月食、蚂蚁任务或Maven BND插件与脚本或jar存档的手动编写清单进行比较。

小应用程序

对于小型应用程序，OSGI引入了不必要的复杂性，同时可以使用动态语言(如Jython等)或插件框架(如JPF或SPI )。您还可以直接使用反射和一个简单的自定义类加载器。

大应用

大型应用程序可能会受益于OSGI，特别是当它们是从头开始编写的时候。IMHO在现有应用程序中集成OSGI更像是引入了一个修补程序，以提供模块化的体系结构。

根据我的经验，在重写了许多应用程序之后，最好在项目的早期考虑模块化。

其他关注事项

部署:在任何应用程序中都是一样的。如果您习惯于部署Java应用程序，那么部署就不重要了。如果您已经习惯了OSGI，那么部署就不用担心了。

当涉及到在生产中部署应用程序时，在任何应用程序中都会偶尔出现问题，这是很自然的。

版本控制:在应用程序中提供版本控制的方法很多。但是，如果您只将版本控制用作“信息”而不是工具(管理依赖关系需求)，那么版本控制就不是一个问题。

重用:在使用OSGI时，您倾向于编写用于重用的代码，但是任何编写良好的API都考虑到代码重用。

Eclipse是一个成功的用OSGI编写的大型应用程序的一个例子。还有其他一些大型/不错的工具，它们不使用OSGI，而是模块化的。

结论

在许多模块化框架中，如果不重新启动应用程序，就很难在运行时处理依赖关系、停止/启动/卸载/安装功能。您可以使用自定义的类加载器、关机和启动挂钩等。

OSGI以较小的成本为您提供了这样的灵活性，IMHO。