与软件开发相关的绝大多数成本与新应用程序的初始设计，开发和测试无关-尽管这些成本可能很高-但与此后应用程序的维护和发展无关。

通过仅通过定义明确的接口访问的一致，版本化，可重用的模块设计和构建应用程序和应用程序套件，可以降低复杂性，并在软件首次发布后提供最大的灵活性来维护和发展该软件。 模块化设计（其中的模块提供了定义良好的服务和接口），使大型项目可以在团队之间进行划分，而团队可以专注于自己的任务，而无需了解其他团队代码的细节，而无需达成共识，减少每个团队的复杂性，并缩短交付时间。 此外，通过最小化对应用程序的任何更改的影响范围（假设可以确定范围）来降低应用程序维护成本。 如果对模块的更改仅影响其内部，而不影响其外部合同，则可以对单个隔离的模块进行维护，并且可以更好地进行测试。 这一切都是不言而喻的，但是我们可以从开发工具和运行时基础结构的积极帮助中受益，以支持这种模块化设计方法。 例如，拥有更简单的方法来部署和维护多个EAR使用的通用代码不是很好吗？

首先，什么才是好的模块？

• 模块应提供一致的逻辑功能，并且应充分独立，以表示实用的“重用单元”。
• 一个模块应该通过定义良好的外部接口和依赖关系松散地耦合到其他模块。
• 一个模块应该将其内部与其他模块隔离开 ，以便对模块内部行为的更改不会影响任何其他模块

Java类通常过于细粒度，无法在应用程序之间形成逻辑重用单元，它们的隔离重点主要限于实例数据的封装。 通常将类打包在一个表示一致性函数的JAR文件中。 作为部署的单元（以及文件系统中存在的工件），JAR是非常实用的重用单元，但缺少良好模块的其他一些特征。

考虑可见性：如果在foo.bar包中的类中有一个方法需要对bar.foo包中的类可用，则需要使用公共访问修饰符声明该方法。 您没有办法指出该方法是否也应提供给JAR以外的类。 您可以应用约定和最佳实践。 您可以使用软件包命名约定将接口组织为外部和内部软件包。 例如，打算供应用程序使用的WebSphere Application Server接口包含在com.ibm.websphere或com.ibm.wsspi的子包中，而不打算供应用程序使用的内部接口则主要位于com.ibm的子包中。 ws。 如果在项目中不同模块上工作的不同团队在模块外部的定义和使用方面受到约束，则这些模块将仅通过定义的外部保持耦合。 当然，您的模块中总会有很少的plus-plus功能，这些功能是您生活中不可缺少的，但它不是模块接口的一部分。 因此，当另一个团队发现这还能使他们的生活变得更好时，让他们继续使用它有什么危害呢？ 毕竟，你们都在同一个整体项目上工作，而且他们使用的方法都具有公共Java可访问性，因此，无需费心修改即可同意让他们使用它-如果他们愿意打扰。 而现在，您毫无意义地打破了束之间所需的松散耦合。 现在，对捆绑包内部进行更改的“影响范围”可能会超出捆绑包的范围，这使得很难确定可能受到影响的内容以及因此需要测试的内容。

因此，很明显，尽管JAR是非常实用的重用单元，但它缺乏区分外部和内部的能力，也没有办法隔离外部和内部。 而且实际上比这还糟：虽然您很容易在其他环境中使用此JAR（您的重用单元），但您如何确定新环境是否可以满足其所具有的所有依赖性呢？ 如果弄错了，那您手上可能有一个定时炸弹，这意味着它可能快乐地运行了好几天，然后需要加载一个新环境没有的类并且繁荣起来 -ClassNotFoundException。 这里的问题是，除了不提供隔离之外，JAR还没有办法声明自己的依赖关系。

因此，JAR接近于您需要的一个良好的可重用模块，但是它缺少一些基本的模块化特性。 这是OSGi捆绑软件的来源。

OSGi捆绑包是一个JAR，但它在JAR清单中具有其他头。 在没有机制来处理此额外元数据的普通JVM中，捆绑软件的行为类似于普通的JAR。 在包含OSGi框架的JVM中，元数据由框架处理，并应用了附加的模块化特性。 清单1显示了一个示例MANIFEST.MF。

清单1.捆绑清单中的OSGi头

Manifest-Version: 1.0 Bundle-ManifestVersion: 2 Bundle-Name: MyService bundle Bundle-SymbolicName: com.sample.myservice Bundle-Version: 1.0.0 Import-Package: com.something.i.need;version="[1.0,2.0)" Export-Package: com.myservice.api;version=1.0.0

这里要注意的一些标题是：

• 导出软件包列出了一个或多个特定版本的软件包，这些软件包将从捆绑软件中导出。 捆绑包外部仅可见导出的软件包； 此处未列出的所有软件包仅在捆绑包内可见。
• 导入软件包列出了捆绑软件所需的一个或多个特定版本或版本范围的软件包。

在不涉及版本控制的细节的情况下（稍后将进行讨论），让我们考虑一下这两个标头在做什么。 回想一下，我们之前曾谈到需要建立开发最佳实践来定义模块的外部接口，并确保任何客户端模块都不会使用内部组件。 使用OSGi，您现在可以通过在运行时强制实施来支持此最佳实践，并为模块所有者提供适当封装其内部的机制。 此外，捆绑包清单中具有元数据，该元数据可以清楚地标识捆绑包所需的所有其他捆绑包需要提供的包。 在由许多捆绑软件组成的复杂应用程序中，这为您提供了更具确定性的方法，可以识别捆绑软件更改的影响并了解对系统其余部分的可能影响，从而降低软件开发生命周期中的风险和成本。

OSGi框架解析器提供元数据的处理和可见性规则的运行时实施。 在启动每个捆绑包时，解析程序会将每个捆绑包的导入与已安装到框架中的其他捆绑包声明的导出进行协调，并为每个捆绑包计算一个单独的类路径。 如果捆绑软件具有无法解决的依赖关系，则捆绑软件将不会启动。 前面提到的滴答定时炸弹（对于JAR转移到不能满足其所有依赖关系的新环境的情况）可以通过有效地去除保险丝来解决。 处理无法启动的应用程序比正常运行一段时间，然后由于ClassNotFoundException意外失败的应用程序容易得多。

到目前为止，我们还没有看到专门针对企业运行时的东西-那么这与企业Java应用程序或企业应用程序服务器有什么关系？

给定一个能够处理和遵守OSGi包元数据的企业应用服务器，那么OSGi的第一个明显的好处就是对包含大量模块的复杂企业应用进行了适当的模块化。 但这远不止于此，它还解决了企业环境中常见的许多其他问题。 我们已经简要介绍了其中之一：在许多部署了数十个或数百个EAR的大型企业部署中，通常情况下，每个EAR都是自包含的，其程度是应用程序使用的许多通用库都是包装在需要它们的每个EAR中。 当应用程序启动时，您最终将在EAR部署到的文件系统或存储库上以及内存中爆炸这些库的副本。 尽管通常可以将企业应用程序部署到各种供应商的企业环境中，并且为独立于EAR的共享库配置管理依赖性，但是这些机制因供应商而异，并限制了可移植性。 共享库的配置通常也与部署过程本身分离，因此需要单独的部署后管理配置，这增加了端到端部署过程的复杂性。

OSGi元数据和捆绑软件存储库使您有机会大大简化共享公共库的企业应用程序套件的部署，因此仅特定于应用程序的模块需要包含在应用程序存档中。 当了解OSGi元数据并可以根据部署环境中配置的软件包存储库的内容解决软件包依赖关系时，企业部署过程将变得更加强大。 可以在集中式软件包存储库中管理所有通用库，该存储库随后成为企业（单元）配置的一部分。

OSGi还为您提供了在企业环境中更好地进行版本控制的机会。 当今的企业应用程序通常包含第三方框架或库，它们对通用库的依赖性相似。 如果不同的框架需要不同版本的通用库，那么这可能会令人头疼。 当您一切正常时，这些头痛可能会变得非常严重，直到您需要更新供应商框架才发现自己无法使用，因为它依赖于应用程序中另一个框架已在使用的更高版本和不兼容的库版本。

OSGi版本控制元数据和类加载消除了此问题。 在上面的清单1中，Import-Package标头指示对包com.something.i.ne。的依赖关系，其版本范围为“ [1.0,2.0）”。 这意味着，该软件包的任何版本都可以满足该依赖关系，范围为：1.0≤version <2.0。 因此，版本1.0或1.5.0或1.9将满足依赖性，而版本2.0将不满足。 OSGi的版本控制机制使程序包提供程序可以指示程序包的新版本是否向后兼容先前的版本，而该版本主要部分的更改表示不兼容的更新。 包使用者可以指出他们可以使用的版本或版本范围。 （有关OSGi版本的更多信息，请参见此PDF白皮书 ）。 重要的是，如果应用程序中的两个捆绑包依赖于同一软件包的不同版本，则可以同时满足这些依赖性，因为OSGi解析器可以为两个捆绑包计算不同的类路径。

OSGi平台规范以及参考实现和合规性测试由OSGi联盟制定，并且已被普遍使用了十多年。 2010年3月， OSGi V4.2企业规范的发布包含了企业环境。 这定义了企业Java技术的OSGi语义，例如事务，持久性和Web组件。 这个重要的规范定义了将Java EE和OSGi世界融合在一起的标准机制，包括用于捆绑软件的OSGi元数据，以声明它是一个包含web.xml文件的Web捆绑软件，一个包含persistence.xml文件的持久性捆绑软件或一个蓝图。包含blueprint.xml文件的捆绑软件。 Web和持久性捆绑包只是熟悉的Java EE模块，带有附加的OSGi清单头。 蓝图包更像Spring模块，但是具有标准化的bean定义XML。

OSGi作为一项技术已经在独立应用程序和客户端应用程序技术中流行了很多年，并且在许多企业应用程序服务器（例如WebSphere Application Server）的实现中内部使用。 直到最近，由于缺少适用于企业应用程序的OSGi标准以及缺乏广泛可用的专用工具和企业运行时支持，这些应用服务器平台上运行的企业应用程序对OSGi的直接利用一直受到抑制。 随着OSGi企业规范的发布以及在越来越多的企业应用程序服务器中将应用程序作为OSGi捆绑软件部署的选项的可用性，这种情况已经发生了变化。

本文的其余部分讨论了在开发和部署用于OSGi应用程序和JPA 2.0的WebSphere Application Server V7功能包中引入的用于开发和部署企业OSGi应用程序的运行时和工具支持。

OSGi应用程序功能包

针对OSGi应用程序和JPA 2.0的WebSphere Application Server V7功能包中引入了对WebSphere Application Server中OSGi应用程序的支持。 与其他WebSphere Application Server功能包一样，这是一个免费下载的文件 ，可以在现有WebSphere Application Server V7.0.0.9或更高版本的基础上以附加方式安装和卸载。 该功能包实际上包括两个可安装的功能： OSGi应用程序功能和JPA 2.0功能 。 这些可以独立安装或一起安装； 这些功能一起使用时，将提供简化的基于POJO的组件模型，高性能持久性框架和模块化部署系统，从而简化Web应用程序的开发和单元测试。 本文仅关注OSGi应用程序功能。

WebSphere Application Server OSGi应用程序功能为您提供了以模块化方式开发和部署企业应用程序的机会，将可配置的OSGi软件包系统信息库引入了WebSphere Application Server管理流程。 这使常见的捆绑包可以从单个企业应用程序归档中分解出来，并在捆绑包存储库中进行集中管理。 捆绑软件存储库中可以管理捆绑软件的多个版本，并且可以在元数据中为这些应用程序指定与各个企业应用程序关联的适当版本。

让我们看看在WebSphere Application Server中成为OSGi应用程序意味着什么。

在最基本的级别上，OSGi应用程序可以与部署在Java EE企业归档文件（EAR）中的模块相同，但是具有附加的OSGi元数据，该元数据使模块可以作为OSGi捆绑包加载。 尽管使用Java EE类加载器运行标准Java EE应用程序或使用OSGi类加载器运行OSGi应用程序的最终结果没有区别，但是您可能出于多种原因选择开发和部署OSGi应用程序：

• 可以将应用程序部署在仅包含（如果需要）特定于应用程序的内容以及引用任何共享库（包）的元数据的存档中。 仅将公共库的单个副本加载到内存中时，应用程序存档会变得更小。
• 使用标准OSGi机制，可以在同一应用程序中同时加载多个版本的类。
• 可以在捆绑包级别以模块化方式管理更新已部署的应用程序。
• 在开发时，IBMRational®Application Developer中的企业OSGi项目会强制执行OSGi可见性规则，以便项目只能访问来自其他项目的软件包，这些软件包将其明确声明为项目外部的一部分，从而为开发最佳实践提供环境支持。
• 通过使用OSGi服务，可以将应用程序设计为可扩展性和动态更新。
• 在运行时，只有解决了所有依赖关系，应用程序才会成功启动，从而减少了在应用程序处理工作负载时ClassNotFoundExceptions的发生。
• 应用程序可以使用自己的通用实用程序类版本，而与服务器运行时的用法不同，而无需配置应用程序Java EE类加载器策略，例如PARENT_LAST模式。

随着应用程序复杂性的增加或部署的应用程序套件的大小的增加，使用OSGi的好处变得越来越明显，这增加了管理对应用程序模块及其使用的实用程序库进行更新的挑战。

OSGi应用程序入门

有多种方法可以将您的第一个OSGi应用程序部署到WebSphere Application Server。 可能最常见的方法是从您已经熟悉的现有Java EE Web应用程序开始，或者从作为OSGi应用程序功能的一部分附带的示例应用程序之一开始。 在所有情况下，都需要以可以部署的格式打包OSGi应用程序。

与其他任何应用程序一样，OSGi应用程序通过wsadmin或通过WebSphere Application Server管理控制台部署到WebSphere Application Server，但是打包在称为企业捆绑包归档 （EBA）的新型归档中。 这类似于EAR，但是其模块作为捆绑部署到所需的目标服务器。 EBA代表由多个应用程序模块之一组成的单个隔离的OSGi应用程序，并且是企业OSGi应用程序的部署单元。 与EAR文件类似，EBA可以包含构成应用程序的所有组成模块或捆绑软件，但可以只包含从已配置的捆绑软件存储库中定位那些捆绑软件所需的元数据。 元数据采用EBA级别的APPLICATION.MF文件的形式，该文件描述了应用程序的内容以及该应用程序是否公开了任何外部服务和引用。 就像包清单描述包的模块化特性一样，应用程序清单描述应用程序的模块化特性以及应用程序的可部署内容。

清单2显示了一个简单OSGi应用程序的完整应用程序清单。 Application-Content标头描述了组成应用程序的主要捆绑包，在部署应用程序时将对其进行部署。 您需要为正在部署的应用程序提供“内容列表”的原因是，因为并非所有这些内容都需要包含在EBA中的应用程序清单中； 这些捆绑包当然可以打包在归档文件中，但是WebSphere Application Server部署过程可以从已配置的捆绑包存储库中同样地配置其中的一些或全部捆绑包。 例如，如果com.example.common.audit捆绑包为IT组织管理的所有应用程序提供了公共审核服务，则应将该捆绑包安装到公共捆绑包存储库中，而不是作为每个应用程序EBA的一部分进行部署。

清单2. OSGi应用程序的简单APPLICATION.MF

Application-Name: MyAppApplication-SymbolicName: com.example.appApplication-Version: 1.0Application-Content: com.example.app.web;version=1.0.0,com.example.app.persistence;version=1.0.0,com.example.common.audit; version=1.0.0

借助OSGi应用程序功能，WebSphere Application Server提供了内置的OSGi捆绑软件存储库，其内容可以通过WebSphere Application Server管理来管理，如图1所示。WebSphereApplication Server还提供了使用访问的外部OSGi捆绑软件存储库的选项。通过配置的存储库URL。

图1.管理控制台中的内部OSGi捆绑软件存储库

在OSGi应用程序的部署期间，WebSphere Application Server管理为该应用程序计算所有软件包和OSGi服务级别的依赖关系，以确保可以从EBA和已配置的软件包存储库的组合中完全配置该应用程序。 应用程序清单文件本身可以由开发人员创作或由诸如Rational Application Developer的工具生成。 重要的是要理解，应用程序清单需要在Application-Content中仅列出主要应用程序捆绑包，并且不需要枚举这些依赖的所有提供程序包和提供服务的捆绑包。 WebSphere Application Server部署过程解析所有主捆绑包的依赖关系，以计算应用程序内容的传递关闭列表，并在解析过程检测到缺少依赖关系时阻止应用程序部署。 同样重要的是要了解配置是例外，因此，如果Application-Content全部包含在EBA中，则根本不需要应用程序清单。 构成Application-Content一部分的每个模块及其所有计算出的依赖关系，均作为OSGi捆绑软件部署。 如果Application-Content中包含不包含OSGi元数据的Web模块，那么WebSphere Application Server部署过程将在部署过程中自动将其转换为Web应用程序捆绑包 （WAB模块）。 按例外配置以及自动检测和转换WAR文件提供了开始使用OSGi应用程序的最快方法-您只需重命名存档的.ear，即可使用仅包含Web模块的Java EE EAR并将其部署为OSGi应用程序。 .eba的文件扩展名。

OSGi服务和蓝图组件模型

OSGi带来的另一个功能是通过OSGi服务的标准可扩展性模型。 您可以设计应用程序，以利用OSGi丰富且动态的基于服务的模型来使用OSGi服务注册表中的服务。 然后，OSGi服务成为您可以设计到应用程序中的扩展点，将来可以通过通过单独的捆绑包引入的服务提供程序实现来扩展它，而无需更改原始应用程序代码。 OSGi定义了用于注册和发现OSGi服务的Java API，但是对OSGi服务的声明性方法要简单得多。 这是企业OSGi V4.2蓝图容器的来源：蓝图容器管理POJO bean组件的生命周期和依赖项注入，并通过应用程序级XML bean定义文件进行配置，这是Spring的基于标准的演变。 bean定义XML。 通过在OSGi Alliance中标准化bean定义XML模式和bean生命周期管理语义，可以从应用程序（通常将Spring框架库打包在其中）和中间件中重构依赖项注入容器。 安装OSGi应用程序功能部件后，来自Apache Aries项目的企业OSGi v4.2蓝图容器实现将作为WebSphere Application Server运行时的一部分进行集成和扩展。

蓝图为OSGi应用程序提供了细粒度的bean组装模型，并提供了一种简单的声明性方法来发布POJO bean组件提供的服务。 例如，清单3中所示的bean定义代码片段定义了一个BloggingServiceComponent bean，由BloggingServiceImpl类实现，在OSGi服务注册表中为其注册了BloggingService服务。

清单3.蓝图bean定义

<blueprint><bean id="bloggingServiceComponent"class="com.ibm.ws.eba.example.blog.BloggingServiceImpl">
<property name="blogEntryManager" ref="blogEntryManager"/>
<property name="blogAuthorManager" ref="blogAuthorManager"/>
<property name="blogCommentManager" ref="blogCommentManager"/>
</bean>
<service ref="bloggingServiceComponent"
interface="com.ibm.ws.eba.example.blog.api.BloggingService"/>...
</blueprint>

在此示例中，容器在实例化时将三个属性（可能是对OSGi服务的引用或在bean定义blueprint.xml中其他位置定义的bean）注入到bloggingServiceComponent bean中。 使用Blueprint配置的bean为OSGi应用程序提供了一种方便的方法，将其业务逻辑封装到POJO组件中，这些组件的依赖关系和配置由Blueprint容器注入到POJO组件中。 由于POJO bean组件在应用程序服务器上没有Java依赖关系，因此在纯Java SE或Eclipse环境中对业务逻辑进行单元测试非常简单。

一个示例OSGi应用程序

让我们看一下作为OSGi应用程序功能一部分提供的示例之一，以说明通常如何开发和部署此类应用程序。 该示例是一个简单的博客发布应用程序，说明了OSGi应用程序中Web，蓝图和持久性技术的组合使用。 （如果您想更深入地研究代码，则OSGi Application功能包随附博客应用程序的源代码。）

图2. Blog示例应用程序

该博客样本演示了企业应用程序的典型体系结构。 它由四个松散耦合的包组成：Web层，业务逻辑层，持久性层和API包。

首先，请注意如何将API放入自己的捆绑包中。 这是OSGi的最佳做法，可保持联轴器松动。 如有必要，可以在部署时甚至在运行时轻松地将一种实现换成另一种实现。

包之间的耦合利用基本的OSGi构造服务（在图2中以三角形表示），这些服务保持包之间理想的松散耦合，并使包实现更容易替换，而对其余应用程序的影响最小。 。 如OSGi服务和Blueprint组件mModel中所述 ，OSGi应用程序不需要直接与OSGi服务注册表进行交互，而是可以通过简单的POJO bean的声明性Blueprint配置来进行交互。 Blog-biz和Blog-persistence捆绑包都使用配置了Blueprint的bean来封装业务逻辑，并通过管理其生命周期的Blueprint容器将其依赖项和配置注入到其中。 Blueprint容器将bean-biz捆绑包中的bean连接在一起，还将blog-biz捆绑包中的组件连接到blog-persistence包提供的Blog持久性服务。

该应用程序的前端是一个使用熟悉的Java EE servlet组件的Web模块。 为了说明将Java EE编程样式与基于OSGi服务的样式结合起来有多么简单，示例博客网络捆绑包遵循纯Java EE编程模型，并使用JNDI访问在Blueprint发布的OSGi服务。 企业OSGi规范为JNDI客户端定义了一种对OSGi服务的引用的标准机制，从而为两种编程风格之间提供了自然的桥梁。

blog-persistence-jpa捆绑包使用JPA作为持久性框架，博客作者和条目通过该框架持久化到数据库中或从数据库中检索。 它利用了Blueprint容器管理持久性上下文和全局事务的能力，以确保业务逻辑保持尽可能简单的开发和单元测试。

最后，博客JAR打包在一起放在EBA中，并部署到WebSphere Application Server。

让我们更详细地查看此应用程序的每个元素。

API包

也许并不奇怪，API捆绑包是最简单的组件。 这是一个简单的OSGi捆绑软件，不使用任何企业功能。 如上所述，正是JAR清单中的OSGi元数据赋予了JAR其“捆绑特征”。 对于Blog API，该捆绑包声明它导出了com.ibm.ws.eba.example.blog.api，com.ibm.ws.eba.example.blog.comment.persistence.api和com。 ibm.ws.eba.example.blog.persistence.api软件包，版本为1.0.0。

清单4. Blog示例API捆绑清单

Manifest-Version: 1.0Bundle-ManifestVersion: 2Bundle-Name: blogBundle-SymbolicName: com.ibm.ws.eba.example.blog.apiBundle-Version: 1.0.0Export-Package: com.ibm.ws.eba.example.blog.api;version=1.0.0,com.ibm.ws.eba.example.blog.comment.persistence.api;version=1.0.0,com.ibm.ws.eba.example.blog.persistence.api;version=1.0.0

Web应用程序包

Web捆绑包在很多方面都类似于标准的Java EE Web归档文件。 它在web.xml文件中声明其servlet映射，并将其代码打包在WEB-INF / classes中。 但是，有一些差异。 就像您对OSGi捆绑软件所期望的那样，清单声明了一些导入-在这种情况下，是API捆绑软件导出的博客API。 Web-ContextPath在清单中声明，而不是在EAR的application.xml文件中声明。 实际的原因是OSGi应用程序不是EAR，因此没有application.xml文件。 但是，还有一个更根本的动机。 在Web捆绑包本身内具有Web模块的所有配置信息，这使得Web存档更加模块化和独立，这符合OSGi的精神。

清单5. Blog示例Web捆绑清单

Manifest-Version: 1.0Bundle-ManifestVersion: 2Bundle-ClassPath: WEB-INF/classesBundle-Name: blog.webBundle-SymbolicName: com.ibm.ws.eba.example.blog.webWeb-ContextPath: blogBundle-Version: 1.0.0Import-Package: com.ibm.ws.eba.example.blog.api;version="[1.0.0,1.1.0)",com.ibm.json.java;version="[1.0.0,2.0.0)"

WebSphere Application Server中的OSGi框架将归档识别为Web捆绑包，并移交给Web容器以管理Servlet的生命周期。 Java EE Web容器和OSGi容器之间的集成是通过联合JNDI查找（企业OSGi规范的功能）来实现的。 所有OSGi服务都会自动在JNDI中注册，并且可以通过Java EE组件熟悉的方式进行访问。 例如，博客servlet访问BloggingService的实现，如清单6所示。

清单6.从Web组件访问OSGi服务

InitialContext ic = new InitialContext();return (BloggingService) ic.lookup("osgi:service/"+ BloggingService.class.getName());

它同样可以使用@Resource批注来注入引用，以替代使用JNDI Context API。

蓝图包

业务逻辑被实现为带有声明性blueprint.xml配置文件的POJO的集合，以将bean定义和引用与OSGi服务相关联。 蓝图容器负责与OSGi服务注册表的交互，以管理与服务的交互以及服务的生命周期。 清单3上所示的blueprint.xml代码段来自博客样本业务捆绑包，它说明了一种典型的模式，用于声明Bean，注入其依赖项（可能是对服务或其他Bean的引用）并将该Bean作为服务发布。

持久性捆绑

持久性捆绑包利用企业OSGi的另一个标准功能（JPA集成）来利用托管持久性。 通常通过persistence.xml文件配置JPA持久性单元。 持久性束的束清单需要一个Meta-Persistence标头来指示它是一个持久性束，如清单7所示。

清单7.博客示例持久性清单

Manifest-Version: 1.0Bundle-ManifestVersion: 2Bundle-Name: blog.persistenceBundle-SymbolicName: com.ibm.ws.eba.example.blog.persistenceBundle-Version: 1.0.0Meta-Persistence: Import-Package:com.ibm.ws.eba.example.blog.persistence.api;version="[1.0.0,1.1.0)",javax.persistence;version=1.0.0

持久性捆绑实际上比仅受管理的JPA有更好的协议-因为它是一个Blueprint捆绑（以及持久性捆绑），所以它获得了容器托管的JPA； Blueprint容器完全管理JPA PersistenceContext并将其注入到为blogExample持久性单元注释的托管bean（BlogPersistenceServiceImpl）中，如清单8所示。

清单8. JPA EntityManager的基于注释的注入

private EntityManager em;@PersistenceContext(unitName = "blogExample")public void setEntityManager(EntityManager e) {em = e;}

作为注释bean Java代码的替代方法，可以使用Blueprint bean定义中的<jpa：context>元素声明容器管理的PersistenceContext，如清单9所示。

清单9.蓝图容器管理的事务和持久性配置

<bean id="persistenceManager" class="com.ibm.ws.eba.example.blog.persistence.BlogPersistenceServiceImpl">
<tx:transaction method="*" value="Required"/>
<jpa:context property="em" unitname="blogExample"/>
</bean>

Listing 9 also illustrates Blueprint container-managed transactions. In this example, all the methods of the persistenceManager bean are run under a global transaction established (or joined) by the Blueprint container. The set of container-managed transaction values supported by the WebSphere Blueprint container is the same as that supported for the EJB container. (See Transactions and OSGi Applications for more details.)

Application assembly

The last piece of the sample blog application is the EBA. As described earlier , the EBA is the deployable unit, containing an application manifest which describes the application content. For the blog sample, the application manifest looks like Listing 10.

Listing 10. Blog Sample APPLICATION MANIFEST

Application-Name: BlogApplication-SymbolicName: com.ibm.ws.eba.example.blog.appApplication-Version: 1.0Application-Content:com.ibm.ws.eba.example.blog.api;version=1.0.0,com.ibm.ws.eba.example.blog.persistence;version="[1.0.0, 2.0.0)",com.ibm.ws.eba.example.blog.web;version=1.0.0,com.ibm.ws.eba.example.blog;version=1.0.0Use-Bundle: com.ibm.json.java;version=1.0.0

The basic format for this application-level metadata is described above . There are two things to note in the blog sample manifest:

• The API, blog, and Web bundles deployed for the application must be at version 1.0.0 or later, but the persistence bundle must be a version in the range 1.0.0 up to (but not including) 2.0.0. What this means is that, while all the bundles can be at version 1.0.0 when the application is initially deployed, the application has been assembled to accommodate future updates of the bundles. If later, after the application has been deployed, a 1.1.0 version of the persistence bundle becomes available then the WebSphere Application Server administrator can (through wsadmin or the admin console) update that bundle within the application. The blog sample provides an additional version 1.1.0 of the blog persistence bundle to demonstrate this administrative update capability.
• The Use-Bundle header lists the com.ibm.json.java bundle separately from the Application-Content. This indicates that this bundle is shareable with other applications. All the bundles listed in the Application-Content will run in an OSGi framework instance that isolates these bundles from other OSGi applications in the same application server. In this way, one OSGi application cannot have unintended side-effects on another OSGi application just because it is deployed to the same target server. Because one of the goals of OSGi application support is to simplify module-sharing between applications in a fashion that is integrated with the deployment process, the Use-Bundle header provides a mechanism to identify modules which should be shared. As well as explicit Use-Bundle content, any bundles whose packages or services are implicitly resolved when the application is deployed are also considered to be providing shared content. When the application is started on the target server(s), any bundles that are identified as being shared are loaded into a server-wide parent OSGi framework, the contents of which are visible to each of the isolated application frameworks.

The blog sample is packaged to illustrate the use of the WebSphere Application Server bundle repository: one of the required bundles, the com.ibm.json.java bundle, is provided separately from the blog.eba archive. This shared bundle must be installed into the WebSphere Application Server bundle repository before the blog.eba is deployed. The deployment process calculates the package and service dependencies of all application bundles against the contents of the deployed EBA archive, the configured bundle repositories, and WebSphere Application Server provided API/SPI packages (such as Java EE packages and com.ibm.websphere packages). If all the dependencies are resolved, the application is successfully deployed to the configured target server(s). In the WebSphere Application Server admin console, installed OSGi applications appear in the same Business-level applications (BLA) collection view as Java EE and SCA applications. (See administrative tasks for deploying OSGi applications for details.)

SCA composition

The OSGi application feature can be used in conjunction with WebSphere Application Server's Service Component Architecture (SCA) support when the WebSphere Application Server V7 Feature Pack for SCA v1.0.1.5 or later is installed. SCA provides an assembly model for composing potentially heterogeneous components into coarse-grained composites that define external services and references for which a variety of different bindings can be configured. SCA and OSGi share some common concepts around the notions of assembling components into a coherent module with explicitly declared externals. It is quite natural to use these technologies together, although they do address different and unique aspects of service assembly.

On its own, an OSGi application can be assembled from a collection of OSGi bundles, each of which performs a coherent function within the application, like the Web, business, and persistence bundles of the blog sample application:

• Within a bundle , fine grained components can be implemented as POJO beans and wired together using a Blueprint bean definition; the internals of one bundle are not visible to other bundles.
• Within an OSGi application , bundles are wired together through OSGi services or external package dependencies; the internals of one OSGi application are not visible to other applications.

The above are two different levels of modularity. SCA provides the next:

• Within an SCA composite , SCA components are wired together through SCA services; the internals of one SCA composite are not visible to other composites.

An OSGi application can be assembled as an SCA component within a coarse-grained SCA composite and can selectively expose the OSGi services it implements, using SCA to provide remote bindings for these services. An SCA component implementation provided by an OSGi application has an SCA component type of implementation.osgiapp . It might remotely expose any of its Blueprint-configured OSGi services as SCA services and configure remote bindings for these services.

For example, suppose you wanted to compose the blog sample OSGi application as an SCA component, along with some other components with a different implementation type (for example, an EJB component) into an SCA composite, and then expose the bloggingServiceComponent defined in the snippet shown in Listing 3 as an external service with a default SCA binding. The first thing you would need to do is update the Blueprint service definition from which this snippet is taken to indicate that the service is remoteable. This requires a standard OSGi property, service.exported.interfaces, to be added to the service definition (Listing 11).

Listing 11. Declare that a service is remotely available

<blueprint><bean id="bloggingServiceComponent"class="com.ibm.ws.eba.example.blog.BloggingServiceImpl">...
</bean>
<service ref="bloggingServiceComponent"
interface="com.ibm.ws.eba.example.blog.api.BloggingService">
<service-properties>
<entry key="service.exported.interfaces" value="*"/>
</service-properties>
</service>...
</blueprint>

The application manifest shown in Listing 10 needs to indicate that this service should be visible outside the OSGi application. Do this by adding the Application-ExportService header to the application manifest (Listing 12)

Listing 12. Export the service from the OSGi application

Application-Name: BlogApplication-SymbolicName: com.ibm.ws.eba.example.blog.appApplication-Version: 1.0...Application-ExportService: com.ibm.ws.eba.example.blog.api.BloggingService

Now you can configure an SCA component whose implementation is an OSGi application and which provides an SCA service (Listing 13)

Listing 13. Configure an SCA component

<composite name="SocialMediaComposite">
<component name="BlogComponent">
<scafp:implementation.osgiapp
applicationSymbolicName="com.ibm.ws.eba.example.blog.app"
applicationVersion="1.0.0"/>
<service name="bloggingServiceComponent">
<binding.sca>
</service>
</component>
</composite>

In this example, a default SCA binding is shown but other bindings (such as binding.ws for Web services or binding.jms for JMS) could be specified, depending on how the service needs to be exposed.

Similar to how it exports remote services, implementation.osgiapp SCA components can import remote service references. A broader discussion of the scenarios and patterns for using OSGi and SCA together are beyond the scope of this article. (See documentation for assembling and deploying OSGi components in SCA composites for more.)

开发工具

Most of the development activities, and hence development tools, used to build enterprise OSGi applications are common with Java EE tools, but there are some new considerations. Primarily, these are around the compile-time classpaths, the authoring of the OSGi bundle and application manifests and, optionally, Blueprint bean definition files. Rational Application Developer adds support for developing OSGi application tools with the introduction of new projects types for OSGi bundle projects and OSGi application projects, with automated generation of manifests and forms-based editors to modify them. OSGi modularity semantics are honored in the project build paths so that only the packages explicitly imported and exported in a project's bundle manifest are shared between projects. Rational Application Developer's facet-based configuration enables OSGi projects to be configured as OSGi Web projects or OSGi JPA projects, and integrates tools for authoring web.xml, persistence.xml, and blueprint.xml. Rational Application Developer's new Bundle Explorer can be used to visualize the relationships between the bundles in an OSGi application, as illustrated in Figure 3. OSGi application projects can be imported from or exported to .eba archives, and can be run from the Rational Application Developer workspace, either on the WebSphere Application Sever V7 optionally installed with Rational Application Developer or on a remote WebSphere Application Server V7 environment that includes the OSGi application feature.

Figure 3. Rational Application Developer Bundle Explorer

Beyond the integrated Rational Application Developer tooling, there are a number of open source tools to help generate OSGi bundle manifests. In addition, the EBA Maven Plugin developed by the Apache Aries community can generate an OSGi application manifest from a Maven pom configuration as part of a build.

Operational details

So far we've talked about developing, assembling, and deploying OSGi applications. This section takes a brief look at the result of a deployment and some of the administrative actions that can subsequently be taken.

A useful utility provided with the WebSphere Application Server OSGi application feature pack is the osgiApplicationConsole script installed in the install_dir/feature_packs/aries/bin/ directory. This is a wsadmin client application that provides a remote OSGi console for the specified application server. The command-line parameters are shown in Listing 14.

Listing 14. Using the OSGi application console utility

-h The host name of the target machine.-o The port number of the SOAP port of the target server-u The user ID, if the wsadmin connection is secured. -p The password, if the wsadmin connection is secured.example: install_dir/feature_packs/aries/bin/osgiApplicationConsole -h server1.acme.com -o 8880

At the command prompt, you can type help() for a list of interactive commands. If you run this command after deploying and starting the blog sample application and then type list() at the command prompt, you'll see entries for two OSGi frameworks on the target server. One is for the OSGi framework into which the blog sample application is installed and one is the server-wide shared framework. To find out details of bundles, services, and packages for each framework, you need first to connect to the desired framework: from the command prompt, type: connect(1) to connect to the application framework. To list all the bundles installed into this framework, and see their bundle states, type ss() . You should see something like Listing 15.

Listing 15. Interactive OSGi application console

wsadmin>ss()ID State Bundle0 ACTIVE org.eclipse.osgi_3.5.2.R35x_v201001261 ACTIVE com.ibm.ws.eba.example.blog.app_1.0.02 ACTIVE com.ibm.ws.eba.example.blog.persistence_1.0.03 ACTIVE com.ibm.ws.eba.example.blog.web_1.0.04 ACTIVE com.ibm.ws.eba.example.blog.api_1.0.05 ACTIVE com.ibm.ws.eba.example.blog_1.0.0

The WebSphere Application Server Information Center documents the interactive commands and filters you can use to get more information about running applications. Something this console helps you visualize very easily is the manner in which isolation is maintained for discrete OSGi applications so that the internal bundles and packages of one application are not visible to other applications. It is not necessary to deploy different applications on different servers just to isolate one application from another. Bundles that need to be shared between applications (for example, the Use-Bundle content described earlier (link to Application Assembly) are installed into the shared framework.

The last thing we'll look at is administrative update of a bundle in a deployed application.

After an application has been installed, you can navigate to the admin console's Assets view to see the installed versions of each bundle. If later versions of one or more of the bundles are available, in any of the configured bundle repositories, and those versions lie within the version ranges defined for the bundles in the OSGi application manifest, then you have the opportunity to administratively update some or all of those bundles to the desired version. By way of illustration, the blog sample provides an additional 1.1.0 version of its persistence bundle. If, after deploying the blog sample, you then add the 1.1.0 version of blog persistence to the WebSphere Application Server internal bundle repository, you can navigate via the Application Assets view in the panel shown in Figure 4.

Figure 4. Administrative update of bundles

You can now choose the 1.1.0 version of the persistence bundle and select the Preview button to re-resolve the application and check for any inconsistencies. If the preview produces no errors, you can then select the Commit button to update the application and save the configuration.

结论

The benefits of a modular approach to application design include reduced complexity, reduced time to delivery, and increased serviceability. While the benefits are well-understood and best practices are often put in place to encourage modular design, Java EE infrastructure on its own has limited ability to enforce or encourage modular design.

Enterprise OSGi combines the modularity principles and infrastructure of OSGi with a familiar Java EE programing model for enterprise applications and the server environments in which they run.

The OSGi application feature of the WebSphere Application Server V7 Feature Pack for OSGi Applications and JPA 2.0 provides comprehensive run time and integrated administrative support for deploying OSGi applications to WebSphere Application Server. Application integrity is maintained by isolating applications from one another while enabling the sharing of specific bundles to be directed by application assembly metadata. The application deployment process is augmented to enable application content to be provisioned from a combination of application-specific archives and shared OSGi bundle repositories, reducing application archive size as well as disk and memory footprint. Spring-like declarative assembly and dependency injection, with its benefit of simplified unit test outside the application server, is provided through the Blueprint container, governed by OSGi standards and integrated into the server runtime. Assembly of OSGi applications into heterogeneous composites and remote binding to OSGi services is provided through a new SCA component implementation type for OSGi applications.

Tooling for developers of OSGi applications is provided in Rational Application Developer, including generators and editors for OSGi metadata, enforcement of OSGi modularity constraints in the development environment, import/export of enterprise bundle archives, and workspace-integrated capabilities to run and debug OSGi applications on a server.

Try it out!

翻译自: https://www.ibm.com/developerworks/websphere/techjournal/1007_robinson/1007_robinson.html