我很高兴报告(与 Adrian 一起)经过 3 个里程碑和 2 个候选发布版后,Spring Dynamic Modules(之前称为 Spring OSGi)1.0 已正式发布。
自我上一篇帖子(关于 1.0 M1)以来,许多功能得到了改进或增加;我将在未来的博文中更详细地讨论它们(还有参考文档详细解释了该库),所以我在此仅列举几点:
- 一致性
我们希望提供一个强大、简单且一致的编程模型。这就是 Spring Dynamic Modules 构建在 Spring 之上,并利用其久经考验的概念、可靠性和普适性的原因。
- 高度非侵入性
推荐使用 Spring DM 的方式是不要在你的代码中使用它的类,也不要在你的 Bundle 清单文件中导入它们。如果你不在代码中使用 Spring,只将其用于应用程序配置,同样的规则也适用。Spring DM 会为你创建应用程序上下文,因此你无需依赖 Spring 或 Spring DM。而且不用担心自定义命名空间或 XML Schema 之类的事情,我们已经涵盖了这些。
- OSGi 服务动态生命周期管理
这是 Spring DM 最重要的特性之一——能够像与普通 Bean 一样与 OSGi 服务交互。你无需编写任何代码即可发布和消费 OSGi 服务;我们将为你处理这些动态变化——并且你拥有完全的控制权(将来会详细介绍)。
- 更智能的集成测试框架
由于我们在内部广泛使用 Spring-DM 集成测试,我们改进了默认设置、Maven 集成,并使自动清单生成比以前更快、更智能。例如,该框架会自动确定测试 Bundle 中可用的类,并且不会为其生成导入语句。
- 简单的 Bundle 交互
Andy Piper(博客)添加了一种简单、声明式的方式,根据模块生命周期和 Spring Bean 依赖关系来安装/启动/停止/更新 Bundle。
- 受管的启动/关闭上下文创建
在 OSGi 中,应用程序被分解成各种模块(也称为 Bundle),它们相互依赖于彼此的服务。这在模块之间创建了一个依赖树,这在启动和关闭过程中变得非常重要。传统上,这可以通过根据依赖顺序安装和启动 Bundle 来解决,然而,这并不能完全解决问题。正如 OSGi 规范建议的那样,初始化时间长的 OSGi 服务(例如连接池)应该依赖于与用于启动和停止 Bundle 的线程不同的线程。这意味着,如果一个 Bundle 已启动,并不代表其服务也已可用。而且并非每个应用程序都准备好在启动期间等待所需的服务——事实上,很少有这样做。这意味着一个 Bundle 将会失败,因为它依赖的服务在几毫秒后才发布(OSGi 默认是一个虚拟机内平台,其中事情发生得非常快)。
这种行为并非罕见——事实上,在多核平台和多个 Bundle 同时启动时,这种情况非常普遍。Spring DM 通过确定依赖关系(从 Spring 配置中获取)并在它们可用后才创建应用程序上下文来解决这个问题。在关闭时也会采用类似的过程,Spring DM 将根据依赖顺序停止上下文,这样你就无需担心启动或停止你的 Bundle。
- 无线程依赖等待
我无法讨论依赖机制而不提及 Hal Hildebrand(参见他的博客)实现的用于依赖等待的“无线程”方法(我知道这听起来有点像矛盾修饰,我们正在为此想一个更好的名字)。由于各种服务需要可用才能使模块正常启动,因此需要某种形式的等待/监控,这传统上意味着使用一个线程。
然而,在一个 OSGi 平台上可能有(而且将来会有)多个模块(几十个很常见)——为每个模块使用一个等待线程根本无法扩展。我们努力改进这个模型,我相信我们提供了一个非常好的解决方案——在等待过程中完全不使用线程。这意味着无论部署了 3 个 Bundle 还是 300 个,都不会消耗 CPU 时间,除非你的模块实际开始启动。
Spring Dynamic Modules 不仅仅是将一个 API “Spring 化”,而是处理一个不同的运行时环境。
在工具方面,Spring IDE 支持 Spring DM 命名空间,并且(感谢 Christian)还为 Eclipse PDE 提供了 Spring-DM 特定的目标,这些功能在 Spring IDE nightly builds 中可用(有关安装和使用插件的更多信息可在参考文档中找到)。
未来方向
既然 1.0 已经发布,下一步是什么?有很多领域需要涵盖:
Web 支持
OSGi 平台提供了专用的 Http 服务,但使用它需要编写代码。资源加载、JSP 生成和部署等事情可以大大简化。这是 1.1 版本的主要重点领域。
持久化
现代持久化工具提供了诸如延迟加载等高级功能,这些功能由于依赖于类生成和代理而会弯曲 OSGi 环境强制执行的模块边界。我们希望解决这个问题,并像 Web 支持一样,在使用纯 JDBC 或/和 ORM 工具时提供流畅的体验。
AOP
继持久化问题之后,我们正在寻找在 OSGi 内部进行通用 AOP 的解决方案。这是一个难题,要正确实现它,需要内部 OSGi 平台的支持。好消息是,像 Equinox Aspects 这样的项目已经开辟了道路,并且 OSGi 企业专家组 (EEG) 也已将此问题提上议程。
说够了
如果你想了解更多关于 Spring Dynamic Modules 的信息,请查看项目页面和参考文档,并务必使用我们的邮件列表(论坛即将上线)。此外,最近我们制作了一些 OSGi/Spring DM 截屏视频,这些视频可在 Spring DM 主页上找到。第一个视频(分为两部分),由我亲自制作,展示了如何快速创建一个项目,以便使用 Spring DM 进行集成测试。
为什么是集成测试?因为使用 Spring DM,这是一个非常简单快捷的过程,也是学习 OSGi 的非常有效的方式(尤其是在模块化方面)。
未来会有更多截屏视频——请告诉我们你想看什么,我们将根据请求数量进行安排。
事不宜迟,"使用 Spring DM 进行 OSGi 集成测试"
