Spring - OSGi 项目的第一个里程碑版本近期刚刚发布,该项目提供了将 Spring 应用部署到 OSGi 环境的支持。由于 OSGi 的重点在于模块的动态化管理,这给 Spring 的集成团队带来了很多特殊的挑战。
采用 OSGi 的最大挑战之一就是处理其动态本质。在应用程序中,服务(以简单对象实例形式存在)加进来移出去,而你的应用必须对其进行处理。解决方法并不是很直截了当的,需要根据不同的实际情况而采用不同的处理方式,并且如同异常处理和事务处理一样,需要应用级别的全局作用域。在模块化的过程中,类装载方式的限制会显得更加突出,而这种限制与 AOP 的合并则会带来更大的麻烦:开发人员不得不另觅蹊径,但这样一来,就会把 OSGi 带来的好处扔的一干二净。这只是我们在 Spring-OSGi 里面正在处理的事情中的很少一部分而已,在最终版本中,肯定会与 OSGi 平滑相接。
这个发布版的部分核心特性包括:
OSGi 应用上下文(OSGi Application Context)
尽管 OSGi 采用的是基于 bundle——也就是独立模块——的架构,但 Spring-OSGi 增加了应用级别的上下文,这样开发人员就可以通过它对存放整个应用的 OSGi 上下文进行访问。
对资源的抽象(Resource Abstraction)
OSGi 向 classpath 中加入了一个抽象层,在该层中有一个 URL scheme,它会根据实现的不同而变化。Spring-OSGi 对这个 scheme 进行了封装,并提供了一个很轻便的查询接口。
动态服务支持(Dynamic Service Support)
通过 XML 配置,把任何对象转换成 OSGi 服务都是轻而易举的事情。
集成测试(Integration Testing)
Spring-OSGi 在 JUnit 的基础上,添加了一个用于测试的微架构,这样一来,从 IDE 中运行需要在容器中执行的测试就会更加简单了。
Hal Hilderbrand 指出,对 JUnit 的支持尤其引人注目:
从根本上说,任何有关容器内测试(In-container Testing)的问题都可以归结于如何将测试在容器内运行起来。我们首先必须要配置并启动容器,当然,需要部署测试代码(在 OSGi 容器中,则需要部署测试场景所需的 bundle),然后就剩下 JUnit 测试了。接下来我们必须要从容器外触发测试的运行,并通过某些方式得到测试的运行结果。Costin 的框架很漂亮的解决了这一点,它在同一个进程中配置并启动 OSGi 容器,同时把所有的 JUnit 测试类包装到一个自动生成的 OSGi bundle 中。其结果就是,现在的容器内测试可以完全和任何 JUnit 测试一样运行 - 用 Ant 或者 Maven,或任何一款你所偏爱的 IDE。正如我所说过的一样,这项功能非常酷,你应该亲身体验一下来确信这一点。甚至没有任何容器曾经向它靠拢过。
译者简介:李剑,中国Eclipse 社区插件开发版版主,在JavaEye 拥有 RCP 专栏, 北航软件工程硕士。现就职于 Ethos ,热衷于设计模式,敏捷软件开发的研究与实践。为 InfoQ 中文站贡献内容,请邮件至 china-editorial@infoq.com 。
评论