IBM 和 OSGi
OSGi 是 Java 语言的动态模块系统。IBM 是 OSGi 联盟的初始成员之一，该联盟旨在促进 OSGi 服务平台的广泛采用，确保通过网络交付和管理的应用程序和服务的互操作性。多年来，IBM 一直在 IBM Lotus 和 WebSphere 产品中使用 OSGi 技术。事实上，从 IBM WebSphere Application Server 6.1 版本就开始使用 OSGi 了。用户看不到它，因为使用 OSGi 是为了实现底层应用程序服务器架构的模块化，从而使其易于开发和支持。WebSphere Foundation 一直在使用 OSGi 改进 IBM 产品， 现在 WebSphere Application Server V7 Feature Pack for OSGi Applications and Java Persistence API (JPA) 2.0 （以下简称为 OSGi 功能包）支持您使用 OSGi 改进自己的应用程序和服务。
引进企业级 OSGi 应用程序编程模型的关键因素之一是确保它是整个行业认可的标准。这是 OSGi 联盟的企业专家组 (EEG) 的焦点。该企业专家组的专家由来自 Oracle、SAP、VMWare、Redhat、Progress 和 IBM 等的代表组成。许多供应商都向该组提供专业经验，以确保任何标准都能够得到广泛支持。
为什么是企业级 OSGi？
在介绍 OSGi 功能包的重要内容之前，值得花些时间概述一下它有助于解决的问题。
值得一提的是，组织使用 WebSphere Application Server 的功能部署和管理大量应用程序。这些应用程序通常包含公共库。在这种情况下，应用程序开发人员在其应用程序中包含相同的库就很正常。尽管这是每个应用程序获得预期库的一种安全方法，但是此策略可能会占用过量内存并使应用程序更新变得比较困难。软件供应商提供了解决此问题的解决方案，但他们是针对供应商的，并且会导致管理时间成本增加。
有时会在应用程序中使用供应商库，通常开发人员无法控制这些库的依赖关系。所以当一个应用程序使用的两个库具有不同且不兼容的内部依赖关系时，就会出现问题。例如，一个库可能需要 ASM 3.0，而同一应用程序使用的另一个库可能需要 ASM 2.0。要解决这种问题，通常需要更改代码。
总的说来，这两个问题在 Java EE 中通常都可以解决，那么为什么要忍受 OSGi 可以解决的问题呢？
OSGi 联盟的 EEG（企业专家组）成立于 2007 年，并且制定了 OSGi 功能包实现规范。EEG 的目的是查看最常用的 Java EE 技术（例如，JPA、JTA、JNDI 和 JMX 等），并构建使用部署到 OSGi 框架的应用程序绑定技术的标准方法。
开源和 OSGi
去年启动了提供 OSGi 企业规范实现的两个开源项目。Apache Aries 孵化器项目在 2009 年 9 月启动，并具有由 Apache Geronimo 社区开发的 Blueprint 实现。2009 年启动的企业模块项目（Enterprise Modules Project）由 Eclipse Foundation 主办，该项目与 Aries 项目的目标大致相同。
在很短的时间内，就建立了许多与 Apache Aries 相关的活跃团体。参与者包括来自 IBM、Progress、RedHat、Ericsson、SAP、Prosyst 和 LinkedIn 等的个人。由于 Blueprint 的最初贡献，JTA、 JPA、JNDI 和 JMX 的组件都已添加。演示如何使用这些技术（包括 Blog Sample 和 Aries Trader 应用程序）的示例是项目的重要部分。
Aries 积极开发的另一个领域是 “应用程序” 概念，这是将 bundle 分组为单个应用程序或 Enterprise Bundle Archive (EBA) 的一种方式。
OSGi 功能包
OSGi 功能包提供了一个整合应用程序框架，有助于 Java EE 应用程序开发人员利用 OSGi 企业架构。该功能包整合了 Apache Aries 开发的组件和 WebSphere Application Server 运行时与管理。（JPA 2.0 支持也是功能包的一部分，但在本文中不会详细介绍它。）
具体来说，功能包交付 OSGi Blueprint Container 规范的开放社区和基于标准的实现，并且具有将应用程序组装、部署和管理为 OSGi bundle 版本集合的能力。常见 Web 应用程序的模块设计、简单的基于 POJO 的组件和高效数据访问需求，都可以使用 OSGi 应用程序和功能包的 JPA 2.0 组件解决。
功能包的一些主要功能如下所述。下面将详细介绍这些功能以及其他一些功能。
Enterprise Bundle Archives
组成 OSGi 应用程序的 bundle 经过合理组装，可形成可部署的 Enterprise Bundle Archive 或 EBA。开发 Java EE 应用程序时，通常会将所有模块库（应用程序内容）放在 EAR 文件中。相反，尽管 EBA 中的应用程序元数据描述应用程序内容，但是无需在 EBA 中包含二进制内容。EBA 可以仅指从 bundle 库的相应阶段获得的 bundle。最常见的情形可能包括在 EBA 中放置其他 bundle 并包含其他内容。例如，Web 模块是应用程序的主要部分，所以它们自然位于 EBA 文件中；而非应用程序特定内容（比如共享库）从 bundle 库获得可能会更好。后续文章将探讨 bundle 库，以及如何且何时提供 bundle。
Web 应用程序
正如 OSGi Web Container 规范定义的那样，OSGi 应用程序的 Web 内容仅是具有其他 OSGi 元数据的 Web 模块。该规范定义了 Web 应用程序 bundle 所需的元数据。部署时，WebSphere Application Server 将 EBA 中的 WAR 文件转换为 OSGi bundle。将 Web 模块作为 bundle 部署的优势是，可以将其依靠的库从 WAR 移动到集中式、托管的、版本化的 bundle 库中，在 WebSphere Application Server 部署流程中使用该库。
Blueprint
OSGi 服务平台企业规范 介绍了 Java EE 中一种称为 Blueprint 的主要技术，这是 Spring Dependency Injection 模型的标准化。尽管企业级 OSGi 应用程序不需要使用 Blueprint，但是 WebSphere Application Server 实现提供了许多功能，这些功能使 Blueprint 成为开发人员乐于使用的一种技术。
OSGI 功能包的 Blueprint 实现提供了用户期望 Dependency Injection (DI) 容器拥有的功能；例如，使用 POJO 进行构建的能力，以及使容器控制那些 POJO 生命周期的能力。通过 DI 容器（比如 Spring Framework）进行 Blueprint 实现的一个好处是 OSGi 整合。这意味着发布服务的 bundle 稍后可以被注入其他组件甚至是其他 bundle 中。此依赖性注入模型还支持在 Java EE 或 OSGi 运行时以外的时间进行单元测试。
在 OSGi 功能包中实现的 Blueprint 容器是中间件的一部分，而不再是应用程序的一部分，这就为应用程序员消除了一个令人头疼的问题。
JPA 持久化
OpenJPA 是 WebSphere Application Server 默认的持久化提供者。OSGi 功能包包括 JPA 2.0 支持，所以开发人员可以使用 WebSphere Application Server V7 中现有的 JPA 1.0 支持或 OSGi 应用程序中的新 JPA 2.0 支持。
除了 OSGi 服务平台企业规范中介绍的 JPA 模型，功能包还包括扩展的 JPA 支持，向 Blueprint 组件提供由容器完全托管的 JPA，从而向目前正在使用 Java EE 的 JPA 的应用程序开发人员提供一种熟悉的开发体验。
此功能包还包括对 Blueprint 的扩展，所以容器可以将持久化单元和上下文注入到 Blueprint bean 中。EJB 中应用程序开发人员熟悉的事务性行为同样存在于 OSGi 功能包中。
结束语
寻找可靠和已验证的模块化技术的企业 Web 应用程序开发人员，已经有很多都转向了使用 OSGi。IBM WebSphere Application Server V7 Feature Pack for OSGi Applications and Java Persistence API (JPA) 2.0 提供了一种环境，该环境支持 Java EE 开发人员使用 OSGi 功能构建应用程序。
用户对 OSGi 功能包的反馈、对 Apache Aries 的兴趣，以及对现有 WebSphere Application Server 的兴趣表明，Java EE 开发人员乐于使用 OSGi 技术，并期待它提供的许多好处。