近日，Paremus发表博文谈到了OSGi为业务所带来的好处，博文就模块化将成为大型代码基管理与维护的未来方向这一观点进行了讨论。报告还就如何迁移到OSGi上给出了建议：首先通过自动化构建生成OSGi元数据，然后将应用分别迁移到OSGi框架上。

　　很多人认为迁移到OSGi上的代价非常大，但通常这里面包含了模块化本身的代价。无论使用的是OSGi、Jigsaw还是其他的模块化架构，要想对大型、复杂、纵横交错的库进行模块化都要付出代价，而这种模块化对于维护者来说并没有立竿见影的好处。然而如果不这么做，系统就会随着时间的推移变得更加复杂、更加的纵横交错，维护代价也会增加。这就好像我们要经常对车进行保养来保持良好的车况一样；如果长年不保养，那么发动机大修的费用就会比所有的保养费还要高，甚至会缩短车的使用寿命。

　　Paremus给出了如下的迁移计划：

　　1. 清除

• 　　成立由模块化专家所构成的小团队，确保得到管理层的支持
• 　　分析现有项目之间的依赖关系，去除不必要或不合适的依赖

　　2. 工具与元数据

• 　　评估并使用支持OSGi元数据的工具与仓库
• 　　为所有项目生成OSGi元数据，以此作为构建过程的一部分（即便没有转向OSGi）

　　3. 运行时

• 　　根据敏捷与重用性为迁移选择候选者
• 　　使用现有库（以此作为粒度级别）创建工作运行时Bundle
• 　　在OSGi与非OSGi运行时下进行并发测试

　　4. 迭代

• 　　一旦迁移到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还是模块化领域中的一个工具，可用于模块化并在模块之间强制施加边界。随着项目规模的不断扩大，强有力的模块化系统所带来的价值已经超越了实现模块化的代价。