用 OSGi 应用程序开发和工作的最佳实践 （1）

look_w

1. 使用 Blueprint一般而言，使用 Blueprint 是一个最佳实践。Blueprint 提供的一些 Blueprint 支持一个简易的 POJO 开发，并支持测试模型、简易组件组装和基于开发标准的这一事实。在 WebSphere Application Server OSGi 应用程序中使用 Blueprint 是额外推荐的，因为它增强了对容器集成、Service Component Architecture (SCA) 集成和基于服务的供应的支持。
原因如下
Blueprint 是一个基于 Spring Framework 的简易组件装配模型，它是被 SGi Alliance 在 Enterprise                OSGi R4 V4.2 规范中由 SpringSource  进行标准化的。作为标准化的 Spring，它支持相同的依赖注入模式，使简单的 Java 组件能够不使用框架 API 而进行开发，易于进行单元测试。
一文列出了 WebSphere Application Server 支持 Blueprint 组件模型的原因，这是由客户需求所激发的。WebSphere Application Serve 中支持的 OSGi 应用程序，其中大多数依赖于 Blueprint 的使用来启用某一个功能，例如基于服务的配置和 SCA 集成。尽管通常情况下使用 Blueprint 是一个好主意，当开发 WebSphere Application Server OSGi 应用程序时，甚至还有更多的理由这样做。
2. 使用 Blueprint 启用基于服务的供应（专用于WebSphere Application Server）
使用 Blueprint 开发和使用 OSGi 服务时，Blueprint 定义将被用来确保在应用程序配置到 WebSphere Application Server 时满足服务依赖性。
原因如下
一个 OSGi bundle 清单描述了一个 bundle 从另一个 bundle 导入的包以及导出给其他 bundle 使用的包。因此，对于给定一个具体 bundle，为了满足所有包导入（包括传递依赖），决定一组必须的 bundle 很有可能。一个最佳实践是将界面和实现分到不同的 bundle（见 ）。另一个最佳实践是使用  OSGi 服务实现依赖（见 ）。这两个最佳实践的结果就是配置包依赖项仅满足界面需求，而不能提供实现 bundle。WebSphere Application Server OSGi 应用程序特性通过使用 Blueprint 定义决定一个 bundle 提供和需要的服务来解决这一问题。然后，在应用程序部署期间使用该信息从应用程序归档文件（.eba）或内部 bundle 存储库（一个配置和管理 WebSphere Application Server 管理的 bundle 存储库）提供实现。
示例
图 1. 基于供应示例的服务图 1 显示了一个 API bundle、一个提供服务的实现和一个使用来自实现 bundle 的客户端 bundle。客户端 bundle 和实现 bundle 在 API bundle 上都有一个包依赖项（package dependency），其中含有服务 Java 界面。客户端 bundle 是 OSGi 应用程序（在内容中列出）的一部分，API 和实现 bundle 是共享的，都是来自于内部  bundle 存储库。API bundle 将配置到 WebSphere Application Server 作为包依赖的结果，如果客户端 bundle 和实现 bundle 都是使用 Blueprint 实现的，那么实现 bundle 也将被配置。如果这两个 bundle 中有一个不使用 Blueprint，那么将不配置实现 bundle 。
如果，实现 bundle 使用 Blueprint，而客户端不使用，那么也提供应用程序，但是没有实现 bundle 。这是因为供应程序没有意识到客户端 bundle 缺失服务依赖。如果客户端 bundle 使用 Blueprint 但是实现 bundle 没有使用，那么应用程序将不能部署，因为供应程序不能满足客户端 bundle 服务依赖。
3. 使用 Blueprint 来启用 SCA 集成（专用于 WebSphere Application Server）
开发集成其他技术的 OSGi 应用程序时，一个最佳实践（实际上是必不可少的）是使用 Blueprint 来定义 OSGi 应用程序的服务实现。
原因如下
在 WebSphere Application Server 中，SCA 用于聚合 OSGi 应用程序和其他应用程序类型（例如，Java EE）。它也用来通过各种传输和协议（例如 JMS、Web services、Atom）公开 OSGi 应用程序服务，也可使服务依赖通过这些传输和协议进行调用。要做到这一点，SCA 需要一个由 OSGi 应用程序提供的服务描述和应用程序需要的服务。SCA 重新使用 Blueprint XML 中描述的信息来推出 SCA 所需的信息。因此将 OSGi 应用程序公开到 SCA 时，必须使用 Blueprint。如果一个 OSGi 应用程序包含使用 Blueprint 时没有定义的服务，那么必须创建向 Blueprint 描述这些服务的 Blueprint 虚包，然后将请求转发给非 Blueprint 服务实现。  
图 2.  Blueprint 支持 SCA 集成图 2 显示了一个 OSGi 应用程序和一个 bundle，提供了一个由 SCA 从应用程序外部调用的服务。这个调用来自另一个组件（似乎是另一个 OSGi 应用程序或一个 Java EE 应用程序），或者来自一个特定的绑定，例如一个 Web 服务或 JMS 调用。同一个 bundle 也需要一个由 SCA 提供的外部应用程序服务。这可能再一次调用另一个 SCA 组件，或在一个特定的绑定上进行一次调用。在图 2 的第一个图表中，Bundle A 是使用 Blueprint 实现的。SCA 使用 Blueprint 服务定义来了解如何分辨和调用目标 OSGi 服务。SCA 不使用 Blueprint 服务参考定义，因为在应用程序清单（用于定义一个 OSGi 应用程序的构件）中有充足信息来确定什么样的服务是有效目标。在第二个图表中，服务和参考资料在 Bundle B 中使用其他组件模型实现，例如，声明服务（DB）。SCA 不能理解 DS，因此这是无效的。在第 3 个图表中，一个 Blueprint  虚包 bundle（Bundle C ）用于向 SCA 描述服务，然后将调用转发到 Bundle B 中的 DS 服务实现。