OSGi 4.2 发布了

  • Alex Blewitt
  • 张龙

2009 年 10 月 2 日

话题：Java语言 & 开发架构

近日OSGi 联盟发布了OSGi 4.2 规范。虽然早期草案已经发布了，但此次则为最终版。

某些引擎如Equinox和Felix分别在其 3.5 版和 2.0 版的时候就已经开始兼容 OSGi 4.2 了。然而由于 4.2 版那时还没有发布，这些引擎就不能说兼容于 OSGi 4.2。现在 4.2 版已经发布了，这些团队到底如何来满足规范的要求只是个时间问题了。

此次发布都包含哪些内容呢？InfoQ 此前曾报道过关于草案的相关信息，但现在规范最终版已经发布了，下面就是新版的一些内容：

  • 框架加载（Framework Launching）。虽然我们可以从 Java 应用中运行嵌入式 OSGi 引擎（比如 Equinox 的Servlet 桥）, 但这种方式却将应用与具体的引擎绑定在了一起。借助于包装器（比如Pax Runner）可以通过相对简单的方式将特定于引擎的内容编码到引擎中来启动。现在可以通过一种透明的机制进行加载了，这意味着可以加载一个 OSGi 运行时而无需担心是哪个运行时。这样我们就可以通过替换启动类路径上的 JAR 文件在 Equinox 及 Felix 下测试应用了。
  • 远程服务（Remote Service）。过去叫做分布式 OSGi 及 RFC 119，现在称作远程服务的技术是用于连接多个 OSGi VM 的。远程服务采用了服务的概念（这对于动态 OSGi 应用来说非常关键）并提供了一种机制以将服务公开给远程使用者（使其可以在本地使用远程服务）。并不像其他方式（比如 RMI）那样，远程服务无需实现不同的接口或是抛出受检查的异常。同时它也不会假设万物都会正常工作，而是认为 OSGi 服务是动态的，无论如何服务都能够在 OSGi 环境下抛出并处理异常。
  • Blueprint 服务（Blueprint Service）。对于熟悉 Spring IoC 与 DI 的开发者来说会发现 Blueprint 服务与其有异曲同工之妙。客户端可以根据外部的配置文件来决定连接到哪些服务上，同时还会动态连接这些服务。就像声明式服务那样，你可以约束所用的服务类型（比如强制与否等），但与声明式服务不同的是，在缺少服务的情况下 Blueprint 服务会提供一个相应的代理。在客户端代码与服务进行交互时，客户端会被阻塞住直到定位到服务之后。最后，凭借 Blueprint 服务之类的特性，我们可以避免应用中出现特定于容器的代码，这样无论系统运行在 OSGi 运行时内部还是外部都是大有裨益的。
  • Bundle 跟踪器（Bundle Tracker）。OSGi 早就有了一个服务跟踪器（Service Tracker）用于监控进出的服务，Bundle 跟踪器是对服务器跟踪器概念的一个延伸，用于监控 bundle 的信息。此前服务可以通过 BundleListener 来动态查看进出的 bundle，而 BundleTracker 也达到了同样的高度，就像 ServiceTracker 之于 ServiceListener 一样。我们可以通过这个特性执行动态注册之类的功能，就好象是 Blueprint 服务或声明式服务读取或处理元数据一样。比如说，Web 引擎可能会通过 HttpService 自动扫描新安装的 bundle 和自动注册的 Servlet。
  • 服务钩子（Service Hook）。除了判定当前的服务外，我们还可以拦截服务之间的事件并对其进行过滤。这可用来实现基于角色的许可模型或是根据产品的不同而开启不同的功能集。此外还可以通过拦截另一个 bundle 的事件而提供代理（或是负载平衡）同时又隐藏这些事件，然后用另一种机制进行代理（比如说分布式服务）。监听器钩子可以按需实现这些功能而无需提前注册。
  • 条件许可（Conditional Permission）。OSGi 4.2 中许可的一大变化是增加了 DENY 访问及允许访问的能力。通过与证书签名的结合，这种方式可以显式指定某个 bundle 的子集上都允许哪些许可权限。这有助于创建安全的 OSGi 平台，可以阻止安装那些未授权的 bundle。

新的规范还有很多其他变化，比如 OSGi bundle 具有了自己的 MIME 类型（application/vnd.osgi.bundle）、指定 Bundle-Icon 及 Bundle-License 的能力、声明式服务的变化以允许更少的许可集合（package 访问能力而非 protected）。DS schema 还支持其他的 XML 元素，这有助于特定于服务的信息的传递。此外，由应用管理员所管理的应用现在可以在完成后获取其返回值了。

Equinox 3.5 已经部分支持 OSGi 4.2 了，Apache Felix在上月初也已经通过了一个测试集（在 4.2 规范发布前）。我们相信本月底一切都会明朗起来，包括 4.2 规范的官方定论及测试工具集。

InfoQ 就此次新版本的发布请Paremus的创建者与 CEO、Paremus Service Fabric OSGi cloud 的作者 Richard Nicholson 谈谈自己的看法：

“在过去几年中，我们一直从事着分布式 OSGi 系统的构建，非常高兴看到 OSGi 4.2 规范的发布，此次发布引入了标准的远程服务与 Blueprint 服务。”

你认为 OSGi 4.2 中哪些地方最值得关注呢？

查看英文原文：OSGi 4.2 released

Java语言 & 开发架构