近日 OSGi 联盟的技术指导 Peter Krien 在 UK OSGi Users Group （由 Paremus 资助，在伦敦的 SkillsMatter 举办）上就即将到来的 OSGi 4.2 发表了一个主题演讲。该活动已经被全程录制下来，同时还有演讲视频。
将于今年8 月底发布的OSGi 4.2 具有很多新特性，其中一些特性已经被 Equinox （Eclipse 背后的 OSGi 引擎）实现了。
OSGi 核心的新特性包括：
- 标准的启动框架，这会简化 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 的众多评论表明大家都希望能有一个解决这些问题的合理方案。
查看英文原文： OSGi: The Next Release
暂无签名
中国开发者画像洞察研究报告 2024
分析开发者的行为模式、工作价值、职业发展等内容，帮助整个行业生态更深入地理解开发者，为他们提供更精准...
评论