OSGi 纲要规范添加了子系统、Repository 等内容

OSGi 联盟最新发布了第五版的OSGi 纲要规范（Compendium）。第五版的OSGi 核心规范（Core）已经于 2012 年 6 月份发布，企业级规范（Enterprise）发布于今年的早些时候。

纲要是一组服务的集合，除此之外还有版本信息以及API 定义，它们不是OSGi 核心释放规范的一部分，但是可能会用于模块化风格的应用之中。Equniox、Felix 以及其他的OSGi 项目已经实现了一些（不一定是全部）OSGi 纲要规范。

读者可能会意外地发现在纲要规范中已经没有Service Tracker API 以及SCA Configuration API 了；但是，它们分别被转移到了核心和企业级规范之中了。对应编号的RFC 创建了其API（Tracker 的编号是701，SCA Configuration 的编号是129）；最近，OSGi 联盟开放了审阅过程，所以一些规范可以在 GitHub 上找到。

那么，纲要规范的第五版究竟有什么新内容呢？配置管理（ConfigAdmin）——用于将配置信息传递给 bundle——版本号从 1.4 升级到了 1.5；还有一些新的 API 包括 Repository 服务、Service Loader Mediator、子系统（Subsystem）、通用的命名空间（Common Namespaces）以及 Resolver 服务。

配置管理（Config Admin）

配置管理 1.5 针对 _ 目标 PID（targeted PID）_ 提供了新的规范。它会使用特定的格式化 PID（持久化标示，Persistent IDentity）以及竖线来指向 bundle 的不同版本。如：

• com.example.config|com.example.bundle|1.2.3|http://example.com/config.jar
• com.example.config|com.example.bundle|1.2.3
• com.example.config|com.example.bundle

持久化标示符可以包含特定 bundle 的信息，会使用它的 Bundle-SymbolicName 和 Bundle-Version（甚至它的安装位置）来进一步精确特定可选项的配置。在运行时，会使用最为具体化的配置，这很类似于 Java 中资源 bundle 的国际化路由选择策略，如果能够找到的话，它会为特定的语言使用一个目标值。托管服务工厂（managed service factory）也有所变化，它会使用这种新的查找目标逻辑。

Repository 与 Resolver 服务

_Repository 服务 _ 以及 _Resolver 服务 _ 在特定的仓库类型（如 Maven、P2、OBR 以及 NuGet 等）之上抽象出了存储与网络协议，并且提供了一种基于一个或更多这种仓库解析限制的方式。这种限制使用了通用的 OSGi 需求功能（OSGi Requirement Capability），它表示特定 OSGi 模块所需要的内容（如包导入、最小的运行时环境以及针对平台和处理器的过滤条件）。

与 Maven 中心库（Maven Central）这种仓库不同，OSGi 仓库需要详细了解它所包含的组件，并且要能够返回一个综合的 XML 文件，这个文件描述了仓库的完整内容。对于基于本地文件的仓库，它可能运行得很好（能够以完全遍历的方式生成完整的元数据），但并不能扩展到更大型的仓库。在此之前，曾经制定过仓库规范，是形式是obr；与这个规范的不同之处在于，它能够包含其他潜在的仓库类型，如 P2。

为了保证依赖能够解析，_resolver 服务 _ 能够了解一组通用的需求和资产，确定那些资产能够满足需求的规划。在 Maven 中，这类似于 Aether 的解析功能；对于 OSGi 来说，这会通过像 Equinox 和 Felix 这样的运行时引擎来进行提供，这些引擎会基于本地的 JAR 解析 bundle。resolver 服务会以外部服务的形式提供这种机制，这样就能够允许工具或程序使用这些之前提到的内部 API，同时也能提升出现错误时的一致性。

Service Loader Mediator

Java 的 Service Loader 是一种有缺陷的通用服务加载机制；在设计之时，它就只能基于一个 ClassLoader 操作并为所返回的对象提供了静态绑定。因为 OSGi 会使用多个 ClassLoader 并且会处理动态的解决方案，因此 Service Loader 必须要进行修正。

Service Loader Mediator 提供了一种修正方式，通过启用像字节码织入这样的方案来替代对 Java Service Loader 的调用，会有一个合适的包装器以理解多个类加载器。通过探查需要启用 Service Loader 的 bundle，代码能够减少预先要处理的工作，同时允许已有的 JAR 使用 Java 包。通过往 manifest 中添加 OSGi 属性并选择 Service Loader Mediator 处理，bundle 能够马上进行升级，而不需要明显的重构。

Mediator 还能够用于将服务发布为 OSGi 服务，这样它就能够被运行时中的任意客户端所使用。

子系统（Subsystem）服务

OSGi 子系统允许在单个 OSGi 环境中托管多个部分所组成的应用程序。这样能够允许应用程序声明精确的 bundle 依赖（如 log4j 1.2.14），而同一个 OSGi 框架中的其他应用（不同子系统）可能所绑定的是不同的版本（如 log4j 1.2.16）。

子系统是 OSGi 中一个长期研究的结果，其目的在于按照各部分组成的方式运行多个应用程序。之前为大家所熟知的是复合 bundle（Composite Bundle）或嵌套框架（Nested Framework），子系统的目标在于概括在同一个地方运行多个 bundle 的需求。OSGi 第五版的释放第一次将其规范化；其他所有的迭代已经处于 RFC 级别。

Eclipse Equinox 曾经实现过以前版本的嵌套框架；它们在 Luna 版本中会将其移除，因为这个规范只是一个过程性的成果。另一方面，对于这种组合系统来讲，Eclipse Virgo 成为了重要的参与者，它提供了“用户区（user region）”以及“核心区”（借助 Spring 框架，在很大程度上分离出了潜在的依赖冲突问题，这是 Virgo 设计中重要的特点）。

通用命名空间（Common Namespace）

OSGi 5 的需求功能模型（requirement-capability model ）基于一组命名空间化的需求。这包括字符串形式的bundle-version和bundle-symbolic-name可以用来提供额外的限制。对于大多数的用户可能并不需要了解它，因为它实际上是一个粘合规范，会被 repository 和 resolver 服务所使用。

结论

OSGi 纲要涵盖了所有不适合放在核心规范或其他垂直规范（如企业级或 Residential 规范）中的内容。它们每隔一年或两年以一组服务的形式发布，以前的发布形式就是一些最终的规范。随着审阅过程的开放，可能这些规范将来会以更加迭代化的形式交付。具有讽刺意味的是，对于一个关注模块化的组织，它们的很多规范文档都是大量的各种 API 组合而成，这些 API 的进化速度各不相同；有很多（如 HttpService）在过去的多个释放版本中毫无变化，但在每年的纲要文档中都重复相同的文本。

云提供商——尤其是那些参与到 Eclipse Virgo 或其他高度模块化环境的——将会被子系统规范所吸引，它是这个释放版本的新内容。Repository 规范对那些目前使用 OBR 的人可能会感兴趣，但是在未来的几个释放版本期间，P2 可能不会转移到新的通用 Repository 服务。对所有人都会带来好处的是 Service Loader Mediator，它尝试解决了 Java 的 Service Loader API 缺乏类加载器支持的问题。

原文链接： OSGi Compendium 5 Adds Subsystems, Repositories and More