随着最近GlassFish 3.0版“Prelude”，即Sun公司基于OSGi的Java EE 6服务器的发布，OSGi在企业中的应用已经覆盖了几乎所有后端服务器。最近，OSGi联盟的一份新闻稿列举了使用OSGi的厂商和技术：IBM的WebSphere Oracle的Weblogic Paramus的Infiniflow Service Fabric ProSyst的ModuleFusion Red Hat的JBoss SpringSource的SpringSource应用平台 Sun Microsystem的GlassFish企业服务器         Peter Kriens指出，Jonas——第一个基于OSGi的J2EE服务器，因为不是OSGi成员，所以没有在名单中列出。他同时表示，SAP NetWeaver将来也会迈向OSGi。        正如InfoQ之前所报道的， 这些系统转向OSGi的主要原因是为了更好的模块化。这使得系统可以分解成更便于管理（和测试）的单元，同时提供更多可重用的组件库。目前，大公司（ IBM、甲骨文）一直在应用内部使用OSGi，没有直接暴露给应用的客户，但其他厂商（ SpringSource ）事实上则允许OSGi容器本身（而不仅仅是应用）对外开放其扩展性。        使用Maven构建的项目也同样是组件化的，这导致一些人想知道OSGi在模块化方面有什么特别之处。在Maven的模块化和OSGi的运行时之间两个最关键的区别是：Maven的依赖关系基于特定文件，而OSGi可以通过运行时发现的任意文件导入Java包。 Maven的构建时特性意味着它并不支持运行时动态行为。         类似SpringSource’s DM Server的应用服务器利用OSGi的动态特性部署Spring beans到OSGi容器中，允许运行时停止和重启服务。Spring动态模块框架在底层透明的处理关联和运行时。        开源项目也在转向OSGi。在Apache FelixOSGi服务器的刺激下，其他Apache服务器在它们的产品中生成OSGi元数据或者完全迁移，就像Apache Tuscany的最近迁移。对于那些不生成元数据的的开源项目，存在很多OSGi束库（SpringSource企业束库、OBR、Eclipse Orbit、Felix束库等等），它们为带特定注释的开源Jars提供OSGi元数据。        随着OSGi的成长，基于Web的和后端系统都直接构建在OSGi上。Linked In对OSGi的使用已经在他们的工程博客上讨论过 ，你也可以看到科罗拉多2008软件峰会的相关演讲稿。甚至可以在亚马逊EC2和iPhone上运行OSGi服务。        不论是直接还是间接使用，OSGi在企业中的应用机会正在逐步提高。随着Spring框架成为应用开发的事实标准和Spring DM服务器的优势，构建动态、模块化的应用成为企业追逐的目标。