使用 Blueprint Container 规范构建 OSGi 应用程序.docVIP

Open Service Gateway initiative (OSGi) Alliance 框架变得越来越受欢迎。它为开发模块化的动态应用程序提供了良好的机制。最新发布的 OSGi Service Platform Release 4 V4.2 规范引入了 Blueprint Container 规范。在本文中，了解在不复杂化 Java? 代码的情况下，Blueprint Container 如何为在 OSGi 环境中创建动态应用程序提供简单的编程模型。本文提供了大量示例帮助您开始使用 Blueprint XML 文件和组件 XML 定义。 简介 OSGi 框架为开发模块化的动态应用程序提供了良好的机制，它最近正变得十分流行。最新的 OSGi Service Platform Release 4 V4.2 规范包括了一个名为 Blueprint Container 的规范。 Spring 动态模块 如果熟悉 Spring 框架的话，您将注意到 Spring 和 Blueprint Container 规范之间有许多相似点。Blueprint 规范的基础恰好是 Spring Dynamic Modules 项目。 Blueprint Container 规范为 OSGi 定义了一个 依赖性注入（dependency injection）框架。它的目的是处理 OSGi 的动态特性，即服务可以在任何时间变得可用和不可用。该规范的另一个意图是处理普通旧 Java 对象（POJO），这样相同的对象就可以用于 OSGi 框架的内部和外部。定义并描述应用程序各个组件的 Blueprint XML 文件对 Blueprint 编程模型十分重要。规范描述了组件如何被实例化，以及如何相互连接在一起形成一个可以运行的应用程序。 Blueprint Container 规范使用了一个扩展器（extender）模式，借助这种模式，扩展器包监视框架中的包的状态，并根据这些包的状态为它们执行操作。Blueprint 扩展器包等待包被激活，然后检查它们是否是 Blueprint 包。如果一个包包含一个或多个 Blueprint XML 文件，那么它就被认为是 Blueprint 包。这些 XML 文件位于一个 OSGI-INF/blueprint/ 目录下的某个固定位置，或者在 Bundle-Blueprint 清单头部中显式指定。 一旦扩展器确定某个包是 Blueprint 包后，它将为这个包创建一个 Blueprint Container。这个 Blueprint Container 负责完成以下操作： 解析 Blueprint XML 文件 实例化 将组件连接在一起 在初始化期间，Blueprint Container 确保强制服务引用得到满足，将所有服务注册到服务注册表中，然后创建初始的组件实例。Blueprint 扩展器包还在包停止后为该包销毁 Blueprint Container。 本文将关注 Blueprint XML。通过若干示例展示组件 XML 定义及其使用。 Blueprint XML Blueprint XML 文件被标识为顶级 blueprint 元素，如清单 1 所示。 清单 1. Blueprint XML 文件片段 ?xml version=1.0 encoding=UTF-8? blueprint xmlns=”/xmlns/blueprint/v1.0.0” ... /blueprint Blueprint XML 文件包含各种组件管理器的定义。Blueprint Container 规范定义了四种主要的组件管理器：一个 bean manager、一个 service manager 和两个 service reference managers。每种管理器都负责创建和管理所创建组件的生命周期。管理器提供了一个组件实例。每个管理器都拥有相应的 XML 元素，用于描述管理器属性。管理器可以是顶级管理器，或者内联在其他管理器定义内。管理器还具有一些通用的属性。 id 定义管理器的 ID。id 属性是可选属性。如果没有指定的话，将自动生成一个唯一 ID 并分配给顶级管理器。内联管理器被认为是匿名的，因此不允许设置 id 属性。管理器 ID 在 Blueprint Container 内对于所有顶级管理器必须是唯一的。管理器使用 ID 彼此引用。例如，在注入期间，管理器将要求被引用的管理器提供对象，该对象将被注入到管理器正在创建的组件中。 activation 这个可选属性为管理器定义激活模式。可支持两种激活模式： eager，其中管理器在 Blueprint Contain