Bundle.update：OSGi 现状

OSGi 4.2 已经发布一月有余了（查看InfoQ 的报道），在这一个月当中都发生了哪些事情呢？

今年初发布的 Equinox 3.5 实现了 OSGi 规范草案，而最近发布的 Apache Felix 2.0 也提供了对 OSGi 4.2 的支持。除此之外，前几天发布的 Knopflerfish 3.0 beta 除了框架加载器还在开发当中外已经实现了 4.2 核心。

两周前发布的 Apache Karaf 1.0 构建在核心框架之上，其目的在于形成一个独立于引擎的 OSGi 框架，同时带有几个事先打好包的 bundle，比如 Blueprint、provisioning、日志、远程访问（通过 SSH）等。对于那些 OSGi 新手来说，这是一个很好的起步点，因为它把所有东西都已经打好包了，就像是构建在标准 Linux 内核之上的 Linux 分发一样，可以提供额外的特性和管理功能。

近日 SpringSource （已经被 VMware 收购）发布了 dm Server 2.0M5 ，该版本也为 Blueprint 服务提供了 OSGi 参考实现（查看InfoQ 的报道）并使用了嵌套框架（nested framework）特性。该特性在OSGi 4.2 意见征集时被提出来，但却被搁置到未来版本中，OSGi 框架可以利用该特性为特定的应用创建内部框架（在dm Server 术语中叫做region ）。这样我们就可以在系统中安装多个应用并将这些应用与其他框架隔离开来。从中获得的经验一定会为下一版本的OSGi 铺平道理.

近日 Jetty 7.0 发布了（查看InfoQ 的报道），它既能作为独立的Java Web 引擎，也可以嵌入到其他应用中（包括OSGi 和传统的Java）。Oracle 也宣布了 WebLogic 路线图，其中就包含了正在进行当中的基于 OSGi 的 microService 架构。最后，Sun 开发的 GlassFish 服务器也发布了 V3 Preview ，该版本也基于 OSGi, 大家可以下载使用。

OSGi 企业专家组正致力于定义一套 OSGi 服务（比如解析 JNDI 和 Web Servlet），同时也已经定义好了 OSGi 远程服务，这部分内容已经成为 4.2 规范的组成部分了。专家组希望在明年初发布一个版本，但目前的情况是每个主流的应用服务器的运行时都基于 OSGi。

OSGi 系统的运行是件轻而易举的事情，但构建却不是那么回事了。虽然像 Ant 之类的工具可以处理平的类路径、公共包可视化之类的事情，但 OSGi 运行时提供了一个更加模块化的类路径（既包括运行时，也包括编译期）。现有的构建方案如 Eclipse PDE 对于特定的用例（如构建 Eclipse 插件）没什么问题，但却无法做到独立于 IDE 或是客户化的构建。目前其他的构建引擎（如基于 Any/Ivy 的 Apache Sigil ，其目标是不仅支持 Eclipse，还要支持 NetBeans 下的 OSGi 开发）也取得了长足的进展。尽管还处在孵化期，但最近 Apache Sigil 已经可以实现自我构建，今年底就将发布版本了。

现在 Pax Construct 已经成为基于 Maven 构建的不可或缺的手段，它联合使用了 bnd 工具，而后者则被 Felix maven bnd 插件所用。甚至还有人想从 Maven 仓库中构建 Eclipse，这样我们就可以创建基于 Maven 的 OSGi bundle 并使用基于 Eclipse 的 bundle 了。然而最初这只适合于一小撮项目，他们可以展示这类系统的好处和必要性。

与此同时，Eclipse 正致力于与另一个项目进行协同构建，这次叫做 B3 。这么做并不会改变 Eclipse 项目的构建方式，相反，其目标在于将当前的 PDE 构建与其他构建 / 部署系统如 Buckminster 和基于 Hudson 的构建系统联合起来。

现在 NetBeans 仍然徘徊在 OSGi 之外，这是因为 netisgo （为 NetBeans 提供了 OSGi 支持）仍处在开发当中。另一方面， IntelliJ 9.0 预览版于近日发布了，社区版与旗舰版（在社区版的基础上提供了额外的插件）都提供了 OSGi 支持。

Eclipse 3.6M2 已经发布几周了，它是 Eclipse 平台下一版本的里程碑版本。其 Equinox 支持包含了 OSGi EventAdmin，这在目前正在开发当中的 OSGi 平台的异步支持中得到了广泛的应用（以前 Equinox 所提供的 EventAdmin 是个单独下载的 bundle，这意味着没几个人会使用到它；由于合并到了 RCP 中，默认情况下就可以使用它了，因此其使用的范围也更加广泛了）。Equinox 3.6M2 还为 bundle 提供了加载期编织的功能，这是通过在 bundle 加载期利用 AspectJ 注入代码实现的。除此之外，Equinox 控制台也变成多会话的了，这样多个用户就可以同时连到远程实例上了。

最近在工具领域中 Eclipse E4 1.0M1 异军突起。Eclipse E4 是 Eclipse 平台在 JavaScript 运行时（如 Web 浏览器）上的一个分支，其关注点在于异步。Eclipse 3.x 中的很多行为都是同步的，这意味着用户的行为会阻塞界面的响应。为了支持远程客户端，Eclipse 修改了行为以支持异步访问，其计划是在未来将这些内容融合进 Eclipse 3.x 当中。其所提供的一个特性就是在纯 JavaScript 中创建 OSGi bundle，大家可以访问 E4/JavaScript wiki 来了解它是如何借助于 JSFramework 和 JSConstants 对象进行工作的。我们期待着 E4 1.0M1 的发布。

未来 6 个月要召开不少大会，OSGi 无疑将成为一个明星。首先就是下周的 SpringOne America ，届时将公布 Burton Group 2nd Annual OSGi 的调查结果（请花点时间填一下调查吧）。接下来就是本月底的 EclipseCon Summit Europe ，然后就是下个月的 QCon SF 。明年 1 月份将召开 OSGi DevCon London 2010 ，紧跟其后的是 3 月底的 QCon London 以及将于加利福尼亚举行的 EclipseCon 2010 。

全球的 OSGi 用户群在蓬勃发展着，最近由 Tara Simpson of Instil Software 在 Paremus 举办的 OSGi in Anger 对电信系统中应用 OSGi 以确保远程管理并提供服务的经验进行了探讨。后续的讨论在酒吧进行（由 Luminis 赞助），收到了很好的效果。由 SkillsMatter 记录的演示资料与视频放在了会议主页上。很多项目从貌似的模块系统迁移到了OSGi 上，这有助于发现遗漏的包；Jetty 在迁移到Eclipse 上也遇到了同样的问题。一旦这些系统迁移到OSGi 上人们就会觉得如果没有OSGi 的话，想要构建这些复杂系统将是一件多么难的事情啊。

简单模块系统怎么样了呢？它的目标是为OSGi 和 Jigsaw 创建一个共同点。虽然一开始是很有前途的，但就运行时空间到底应该成为一个平的类路径（就像现在的 Java）还是嵌套类路径（就像 OSGi 和编译路径），人们众说纷纭。未来的专家组也许可以解决这个问题，但现在似乎还遥遥无期。Neil Bartlett 将在伦敦的大会上谈到这个问题。

InfoQ 上有个关于 Java 模块化的专题，专题的下一期将在下周发布。

查看英文原文： Bundle.update: the Current State of OSGi