OSGi 4.2规范终于在9月中旬发布，下面介绍一些OSGi 4.2新规范中的特性。本文原文来自InfoQ的Alex Blewitt发布的消息。
51CTO编辑推荐：OSGi入门与实践全攻略
一些 OSGi 实现，例如 Equinox 3.5 与 Felix 2.0 早已针对 OSGi 4.2 规范做了一些兼容实现，但当时 OSGi 4.2 还没有发布，当然也不能说其实现了 OSGi 4.2 规范。现在规范正式发布了，各实现团队还需要进行一些调整已完全满足规范要求。
新的规范里有哪些特性呢？
框架启动（ Framework launching）
以前虽然可以在 Java 应用中（例如 Equinox 的 servlet 桥接 ）启动嵌入的 OSGi 引擎，但针对特定引擎都有特定的启动方式。虽然有一些包装器（例如 Pax Runner ）使得引擎启动相对容易，但还是必须熟悉特定引擎的知识。在现在的规范中，定义了透明的启动机制使得不需要知道 OSGi 实现引擎就可以将其启动。这样一来，不管是在 Equinox 还是 Felix 下测试都只用替换启动类路径下的相应引擎 Jar 包就可以了。
远程服务（Remote Service）
以前也许你曾经听说过分布式 OSGi（Distributed OSGi）以及 RFC 113，而 OSGi 4.2 中的远程服务就是类似技术的新名字，它将各个 OSGi 虚拟机（OSGi VMs）连接到了一起。远程服务采用了服务 的概念（热拔插 OSGi 应用的精髓），提供了导出服务到远程消费端与在本地消费远程服务的机制。与其他分布式方法（例如 RMI）不同的是，远程服务不需要实现特殊接口，也不用抛出 checked exception 。当然，发生异常的时候远程服务不会装作工作正常，可以把异常看作是一种在任何情况下都因该进入并作用于 OSGi 环境的服务。
筹备服务（Blueprint Service）
OSGi 4.2 中的筹备服务的概念非常类似于控制反转 / 依赖注射。它允许客户端从外部配置文件指定连接的服务，此服务将被动态地连接到客户端。向声明式服务一样，你可以对服务类型上做些限制，例如是否为强制（mandatory）；但与声明式服务也有些不同，当所需服务缺失时筹备服务可以提供一个默认的服务代理实现，当客户代码尝试调用此服务时，客户端将被服务代理阻塞，直到真正的服务连接成功。综上，使用筹备服务的特性可以避免与 OSGi 产生耦合，这使得应用既可以在 OSGi 环境内运行，也可以脱离 OSGi 环境运行。
Bundle 追踪器（Bundle Tracker）
OSGi 早已有了服务追踪器，用于监控服务的来龙去脉；而 Bundle 追踪器是追踪 bundles 的一个扩展。在以前在服务中就可以使用 BundleListener 来监听 bundle 动态进出，而如今的 BundleTracker 与 ServiceListener 有着同等的可用性。其可被用于执行动态注册当筹备服务或是声明式服务正在读取（与处理）元数据。例如，一个基于 Web 的引擎就可以自动地扫描出新安装的 bundles，并通过 HttpService 自动注册 servlets。
服务钩子（Service Hooks）
在判断存在什么服务时，是可以对服务之间的事件进行拦截、过滤的。例如在实现一个基于角色的权限模型或是针对不同产品级禁用 / 可用对应功能集。另一个方法是提供代理服务（或是负载均衡）从而拦截其他 bundle 的事件将其隐藏，以备在后续阶段代理给其他机制（例如分布式服务）。另外，监听钩子也可以在服务没有被注册前按需将服务启动。
条件化的权限（Conditional permissions）
OSGi 4.2 在有关权限方面的升级包含了拒绝访问（DENY access）与允许访问。在认证签名后，可以为 bundles 子集显示地指定操作权限。可以锁定未签名的 bundles 的安装，有助于构建一个安全的 OSGi 平台。
OSGi 4.2 规范相对于 4.1 版还有很多变化，例如 OSGi bundles 有自己的 MIME 类型 （application/vnd.osgi.bundle ），可以为某个 bundle 指定图标以及许可证，对于声明式服务可以简化其权限集合设置（使用包内友好替代了 protected）。DS schema 也允许其他对特定服务信息有助的 XML 元素。另外，提供了一个机制使得应用管理员可以在应用结束是获取该应用的返回值。
Equinox 3.5 已经提供了一些类似的功能，Apache Felix 对类似功能在这个月初也通过了测试（早于 4.2 规范发布）。这个月结束前，OSGi 官方将针对 4.2 规范发布测试套件相关信息。
【编辑推荐】
