近日， Paremus 发表博文谈到了 OSGi 为业务所带来的好处，博文就模块化将成为大型代码基管理与维护的未来方向这一观点进行了讨论。报告还就如何迁移到 OSGi 上给出了建议：首先通过自动化构建生成 OSGi 元数据，然后将应用分别迁移到 OSGi 框架上。
很多人认为迁移到 OSGi 上的代价非常大，但通常这里面包含了模块化本身的代价。无论使用的是 OSGi、Jigsaw 还是其他的模块化架构，要想对大型、复杂、纵横交错的库进行模块化都要付出代价，而这种模块化对于维护者来说并没有立竿见影的好处。然而如果不这么做，系统就会随着时间的推移变得更加复杂、更加的纵横交错，维护代价也会增加。这就好像我们要经常对车进行保养来保持良好的车况一样；如果长年不保养，那么发动机大修的费用就会比所有的保养费还要高，甚至会缩短车的使用寿命。
Paremus 给出了如下的迁移计划：
- 清除
- 成立由模块化专家所构成的小团队，确保得到管理层的支持
- 分析现有项目之间的依赖关系，去除不必要或不合适的依赖
- 工具与元数据
- 评估并使用支持 OSGi 元数据的工具与仓库
- 为所有项目生成 OSGi 元数据，以此作为构建过程的一部分（即便没有转向 OSGi）
- 运行时
- 根据敏捷与重用性为迁移选择候选者
- 使用现有库（以此作为粒度级别）创建工作运行时 Bundle
- 在 OSGi 与非 OSGi 运行时下进行并发测试
- 迭代
- 一旦迁移到 OSGi，那么可能还有更多的候选者来对现有库进行模块化
- 就共享模块进行报告
- 单独迁移随后的应用
成功案例
虽然有博文报道说 MuleSoft 没有成功迁移到 OSGi ，但几个评论家已经证明了 OSGi 无论对应用服务器还是中间件都是很棒的选择。
- 所有主流的 JavaEE 应用服务器都运行在 OSGi 上（ GlassFish 、 WebSphere 与 JBoss ）
- SAP 将要使用 Virgo 作为其 OSGi 运行时
- WSO2 Carbon成功运行在了 OSGi 上
- Apache Camel 是个 ESB（类似于 Mule），但它既能运行在 OSGi 容器内，也能运行在容器外
- JBoss 正在开发自己的 OSGi 运行时
就像其他很多框架一样，使用 OSGi 并不意味着一定就会成功，它还经常需要在使用上与代码上进行一些变化以便进行迁移。事实上， OSGi 并非万灵丹——但我们不能仅仅因为它不适合于一个项目就说它也不适合于其他项目。人们可能不会使用 OSGi 实现解析 CSV 并将其加载到数据库中这样的单一用途应用，但他也不可能使用 Spring 或其他框架完成这件事（有些人可能会说这种情况下最好使用 Python 或 Perl 而不是 Java）。
OSGi 还是模块化领域中的一个工具，可用于模块化并在模块之间强制施加边界。随着项目规模的不断扩大，强有力的模块化系统所带来的价值已经超越了实现模块化的代价。
查看英文原文： Business Benefits of OSGi
暂无签名
分布式云行业实践指南（2023）
业内首个分布式云行业实践方法论、工具箱。
评论