有关OSGi最重要的事情是支持模块化。但由于大多数应用程序和系统的目的不是为模块化，或被设计并建造为土生土长的模块化设计，采用的OSGi通常包含某种程度的困难。

　　有时候，我在思考这个问题的总体行业背景下努力改进应用程序的结构和应用程序的开发过程。大约20年前我为Digital's structured three-tier TP监察产品（ACMS）工作。我们认为我们的主要竞争是IBM的CICS ，一种更古老的技术。客户通常创造“意大利面式代码”，应用程序中使用CICS——没有结构，而且程序通常混杂终端用户和数据库操作。ACMS设计要求的开发者把用户代码和数据库的代码分离开，并通过唯一的接口类型把它们放到不同的程序中，还要求把它们部署到不同的地址空间中。我们还需要开发人员使用一种新的块结构的语言为中间层创建程序，后来我帮助其在X/Open中规范化。

　　当我们刚开始做这项工作，它有时似乎经常要求开发商相信我们会使其正确。在那些日子里实行的这种结构，并要求学习一门新的语言，也似乎常常是一种太多的负担，特别是对那些已成为习惯了具有更大的灵活性的旧非结构化办法，而且他们需要使他们的项目尽快完成。

　　在软件行业，似乎动态的重演，因为当我们看到一种新的方法，比如OSGi，程序的艺术铺垫了一两步，但合并更多的结构、学习一门新的语言（在OSGi的情况下，其元数据语言坐在模块之间）代价也随之而来。今天，很少有人会反对在一个TP的应用项目中使用3层或n层架构，并通过EJB2三层模型实际上就是Java EE。其优点是现在人们普遍理解分离最终用户和数据库代码以及包括一个或多个中间层的缓存、复制、故障转移以及各种可扩展性的技术。但是，当我们第一次试图强行将这个额外结构加给使用具有更大的灵活性和自由的开发人员时，我们遇到了很大的阻力。

　　这是一种长期的方式，我的回答是一旦已经准备就绪，就在您的项目使用OSGi。准备意味着愿意并能够通过额外结构的OSGi要求，以获得它的好处，并花费必要的时间和投资，真正采用模块化。

　　模块化编程的好处已经很好地被理解了约40年，但在OSGi之前，开发人员不得不自己发明模块化设计和系统。OSGi的具体好处相当于现在有案可稽的网站，首先是的OSGi联盟的网站（OSGi Alliance's website），并在一些相关的博客和文章中以及在最近出版的一些书籍，如Craig Walls所著的《Java的模块化》（Modular Java）和Neil Bartlett所著的《实践中的OSGi》（OSGi in Practice）。

　　总之，大型Java项目中从采用OSGi受益是因为该项目可以更容易地在众多开发人员之间分配，每个人创建单独的模块，随后可装配到OSGi框架，如Eclipse Equinox或者Apache Felix。最大的好处是，所有开发人员都采用OSGi元数据，而且也不用知道对方是什么做的——至少不是为了部署详细的了解如何汇集代码。当然，比我在此简要介绍的还有更多方法，但该方法已被工作所证明并已被证明是工业实力。所有主要的Java企业厂商已经采用或正在采用，在他们的内部大型Java项目采用这种做法。

　　但可能在为何个别公司或项目不应采用OSGi上有很好的理由。其中可能是允许在不够结构化的环境中要求更大的灵活性和控制，学到新的东西所花费的时间，或者在一个典型的企业发展的生命周期中使用OSGi的挑战性。最后一点是OSGi工具厂商和OSGi联盟正在努力改善。由于原来的OSGi旨在用于嵌入式应用的情况下，它仍然是流行的平台——企业的生命周期工具是刚刚开始出现。早期采用者报告说，发现它在处理这一事件上或多或少的是具有挑战性的，但将在今后几年改变。
 
　　我要补充一点，当谈论OSGi时，人们有时合并OSGi-enabled middleware（其中一种产品在国内使用OSGi，但不对开发人员暴露OSGi编程模型）和OSGi框架的“本土化”使用。使用OSGi编程模型直接为企业级应用使真正的利益得到实现，但一些挑战仍然存在。随着更多的OSGi结构的编程模型，然而，提高灵活性和降低成本是额外的好处。但是，真的没有一个单一的答案，适用于每个项目。