企业中的OSGi

随着最近GlassFish 3.0 版“Prelude”，即 Sun 公司基于 OSGi 的 Java EE 6 服务器的发布，OSGi 在企业中的应用已经覆盖了几乎所有后端服务器。最近，OSGi 联盟的一份新闻稿列举了使用 OSGi 的厂商和技术：

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 服务器的优势，构建动态、模块化的应用成为企业追逐的目标。

查看英文原文：OSGi in the Enterprise

企业中的 OSGi