为 WebSphere Application Server 开发企业 OSGi 应用程序（4）

look_w

OSGi 服务和 Blueprint 组件模型OSGi （通过 OSGi 服务）引入的另一个特性是一个标准可扩展性模型。您可以设计您的应用程序以利用 OSGi 丰富的基于服务的动态模型，从而使用来自 OSGi 服务注册表的服务。这样，OSGi 服务就成为可以设计到您的应用程序中的扩展点，应用程序将来可以通过单独的 bundle 引入的服务提供商实现来进行扩展，且不必为原始应用程序代码付费。OSGi 定义一些 Java API 来注册和发现 OSGi 服务，但 OSGi 服务的一个声明性方法更加简单。这就是企业 OSGi V4.2 Blueprint 容器发挥作用的地方：Blueprint 容器管理 POJO bean 组件的生命周期和依赖项注入，并通过一个应用程序级别 XML bean 定义文件配置，这个文件是 Spring bean 定义 XML 的基于标准的演变。通过标准化 OSGi Alliance 中的 bean 定义 XML 架构和 bena 生命周期管理语义，就有可能将依赖项注入容器从应用程序（其中通常打包了 Spring 框架库）分离出来并重构到中间件中。在安装 OSGi 应用程序特性时，来自 Apache Aries 项目的企业 OSGi v4.2 Blueprint 容器实现被集成并扩展为 WebSphere Application Server 运行时的一部分。
Blueprint 为 OSGi 应用程序提供了一个细粒度的 bean 组装模型，以及一种简单的声明性方法来发布由 POJO bean 组件提供的服务。例如，清单 3 中显示的 bean 定义代码段定义了一个 bloggingServiceComponent bean（通过 BloggingServiceImpl 类实现），一个 BloggingService 服务在 OSGi 服务注册表中注册了这个 bean。
清单 3. Blueprint bean 定义

1 2 3 4 5 6 7 8 9 10 11

<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>

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