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

核心提示： 最佳实践本文介绍以下最佳实践：使用 Blueprint使用 Blueprint 来启用基于服务的供应使用 Blueprint 来启用 SCA 集成版本是可控的从实现中分离 API 共享服务而不是实现好的 bundle 就像构造良好的类：松耦合、高聚合避免包和 Require-Bundle 分离列

最佳实践

本文介绍以下最佳实践：

使用 Blueprint

使用 Blueprint 来启用基于服务的供应

使用 Blueprint 来启用 SCA 集成

版本是可控的

从实现中分离 API

共享服务而不是实现

好的 bundle 就像构造良好的类：松耦合、高聚合

避免包和 Require-Bundle 分离

列出 Application-Content 头中包含的内容

使用 WAB 而不是 WAR

必要时只使用 Use-Bundle

使用持久 bundle 来共享您的持久性单元

充分利用提供的组件模型

让容器担起重任

每个最佳实践在后续部分逐一详细介绍。

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 开发企业级 OSGi 应用程序 一文列出了 WebSphere Application Server 支持 Blueprint 组件模型的原因，这是由客户需求所激发的。WebSphere Application Serve 中支持的 OSGi 应用程序，其中大多数依赖于 Blueprint 的使用来启用某一个功能，例如基于服务的配置和 SCA 集成。尽管通常情况下使用 Blueprint 是一个好主意，当开发 WebSphere Application Server OSGi 应用程序时，甚至还有更多的理由这样做。