将于今年8月底发布的OSGi 4.2具有很多新特性，其中一些特性已经被Equinox（Eclipse背后的OSGi引擎）实现。

以下是OSGi 4.2核心的新特性：

◆标准的启动框架，这会简化OSGi系统的启动过程而不管底层的实现如何（比如说可以通过变换类路径用Felix替换掉Equinox）。

◆Service Hooks，凭借它OSGi bundle能够拦截并过滤去往其他bundle的服务（这么做能够进行安全检查，诸如此类）。

◆Bundle tracker，它可以在bundle启动和停止时对其进行监控。

◆增强的安全机制，这样不管是肯定还是否定的许可都可以对授权机制进行定制。

◆标准的Bundle-License头，这样bundle就可以定义其协议需求以达到管理的目的。

OSGi纲要涵盖了可能会出现的其他服务，它规定下一个发布要遵循着核心，但还会包括：

◆信息初始化，初始化信息可以存储在bundle的清单中。

◆声明式服务，现在BND已经支持声明式服务了，同时消除了某些限制。

◆远程服务，之前发布的OSGi（即RFC 119）通过远程技术将不同VM之间的OSGi服务连接器来。Bundle的外部配置可以定义服务的连接方式。不像RMI那样，这些服务无需checked exception（很明显，如果发生了通信错误则会抛出RuntimeException）。这已被Eclipse的ECF及Felix CXF实现了。

◆Blueprint extender提供了一个配置驱动的服务模型（类似于声明式服务）但却基于Spring模式。未来，服务可以在启动时实例化并绑定到代理上，之后还可以进行改变。

Enterprise OSGi服务也不甘寂寞，它将含有一个基于OSGi的Transaction API（基于JTA），通过OSGi服务提供JDBC与JNDI，同时还会借助于JMX管理OSGi系统。Enterprise OSGi的一个难题就是Web容器，容器应该可以将WAR安装到运行着的OSGi系统中，正如Spring DM Server那样。

还有几个试验性质的服务（并没有定义在规范中），例如创建嵌套框架的能力（OSGi引擎可以在其上实例化另一个OSGi引擎来运行应用）以及TSL——一种基于shell的脚本语言，用于与OSGi服务进行交互并支持运行时命令。后者的目标是实现一个标准的shell以控制任意的OSGi引擎而不是针对特定系统的特定shell。像POSH和Pax-Shell这样的系统已经开始使用TSL了。

OSGi中那些试验性服务的试验手段与JCP中定义的那些试验性系统是有很大区别的，相对于花费很长时间来定义规范，然后再获得其工作方式的反馈信息，RFC采取了不同的策略：首先提供临时性的细节描述，然后采取多个实现（Felix、Knopflerfish及Equinox等等）来获得其反馈信息，接下来根据反馈来精华规范直到其稳定为止而不是发布某些不确定的东西（与Java的发布形成了鲜明的对比）。在发布最终规范前有机会进行试验并获得反馈信息意味着未来的变化不太可能对最终规范造成严重影响。

该演讲的一些结论与JSR 294的结果不谋而合。目前已经合并了很多需求和实现，由于JavaC处理元模块系统方式的原因，有人提出改变Java中可视化（visibility）的工作方式（包括新引入的模块keyword）。大家就元模块的含义与keyword展开了激烈的讨论。Sun工程师及Felix提交者Richard Hall说到：

就我来说，我很理解Peter的担忧：我们定义的东西含义太不明晰了，这最终会毁掉Java的愿景：“编写一次，到处运行”。定义东西时如果能具体一些就好了。

幸好JSR 294还有时间进行完善；最近关于JSR 294的众多评论表明大家都希望能有一个解决这些问题的合理方案。

【编辑推荐】

1. Spring Tool Suite开始支持OSGi
2. 基于OSGi的动态化系统搭建
3. 初探OSGi Web容器：控制Web程序的生命周期
4. Equinox的OSGi实现与应用服务器
5. Spring OSGi的整合