为什么是企业级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技术，并期待它提供的许多好处。