【转】OSGi 4.2发布了

原文：http://www.infoq.com/cn/news/2009/10/osgi-4-2-released

作者 Alex Blewitt 译者 张龙 发布于 2009年10月2日 上午6时13分

 

近日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