随着最近 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 Felix OSGi 服务器的刺激下，其他 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 服务器的优势，构建动态、模块化的应用成为企业追逐的目标。
查看英文原文： OSGi in the Enterprise
评论