模块化成熟度模型

  • Alex Blewitt
  • 王丽娟

2011 年 10 月 18 日

话题:Java语言 & 开发架构

在九月下旬召开的OSGi 社区大会上,来自 IBM 的 Graham Charters 博士发表了题为《建立模块化成熟度模型》的演讲,模块化成熟度模型是一组正在确定的需求,用来标识模块化相关系统的成熟度。这个模型的目的类似于能力成熟度模型,为组织或项目推行模块化的程度提供了一种度量方式。

请注意,下面的内容还在处理,编号和描述可能会随着时间的推移而发生变化。目前的模块化成熟度模型是:

  • 级别 1:特定的。什么都不是模块化的。所有的内容是一堆 JAR 包,更糟糕的话,可能只是一堆类。这通常会形成一个单一却庞大的应用。
  • 级别 2:模块。模块有正式的版本标识,依赖关系由模块标识处理,而不是模块自己处理。Maven、Ivy、RPM 和 OSGi 就属于这一类。
  • 级别 3:模块化。模块用模块契约声明,而不是用明确的模块标识或版本声明。这个要求可能是抽象的(比如 Declarative Services 可用),也可能是特定的包(像 org.osgi.framework)。
  • 级别 4:松耦合。实现不通过工厂或构造方法获得,而是从注册表里动态查询,或是按需注入。
  • 级别 5:委托。工件的所有权委托给具备模块概念的仓库。这些仓库可能会支持协作或治理,以便通过所需功能之间的关系访问资产。
  • 级别 6:动态化。模块参与到动态的生命周期里,这个动态的生命周期能够在运行时添加、更新、删除模块,同时保留系统中的状态。

InfoQ 有幸对 Graham Charters 博士进行了采访,问他的第一个问题是,是什么驱使他创建了这个成熟度模型:

Graham Charters:过去这些年我有幸和很多客户进行了交谈,他们都采用了 OSGi,处于不同的阶段。他们通常都是事后才采用模块化的,也就是说他们有一些已有的应用,或者有一些无法维护、阻碍他们业务调整和增长的应用。这些客户一般都觉得自己是拓荒者,没有地图,没有明确的目标。成熟度模型所作的就是描述目前最常见、合乎逻辑的应用之旅。成熟度模型是技术无关的,因为最低级别并不需要 OSGi,不过在我看来,OSGi 是最好的解决方案,因为它有助于更清楚地描述各个级别的特点和优势,而不用关注实现它的具体技术细节。

InfoQ:项目在这个模型里的分布情况是怎样的?

Graham Charters:我在 OSGi 社区大会上做了一个调查,结果差不多证实了我的想法。从现场看,整个行业平均处于级别二(模块)。我也曾特意问过 Eclipse Tools 项目这个问题,他们差不多处于级别三(模块化)。有一些项目达到了级别四(松耦合),并恰当地利用了 OSGi 服务模型,但他们的关注点往往是 OSGi,这样的项目有 Apache Aries、Apache Felix、Eclipse Gemini、Eclipse Virgo。委托(级别五)和有状态服务里真正的动态化(级别六)非常少见。我希望即将问世的 OSGi Bundle 仓库规范能达到级别五。

InfoQ:这些级别是线性延续的么?委托和动态化呢?

Graham Charters:通常来说,组织会线性地去遵循这些级别。这个顺序基本上是按照客户最常采用的路径排列的,在现有技术下也最合逻辑。也就是说,委托和动态化之间的顺序不是非常强,更多的是反映了客户的兴趣分布。对客户来说,考虑仓库协作和治理是很正常的,而动态化则更专业一些。我觉得动态性和 OSGi 的 Headless/ 嵌套用法之间有相当高的相关性。

模型的另一个部分可以随着时间的推移而演进,这部分内容就是模块化和松耦合之间的顺序和区别。有人会说,模块之间的松耦合或独立实现就是模块化的一部分。这在一定程度上是正确的。你可以根据需求和功能共用实现。但通常情况下,客户需要在非模块化的环境中运行他们的模块,所以采用松耦合就是有问题的。这就是我觉得微服务(又名 pojoSR)有用的原因。这种技术也可以让客户交换采用模块化和松耦合的顺序。松耦合一般不会注意它对模块化层的影响。如果你的模块是围绕服务等内容而协作的,这就会大大减少模块间 API 的“表面积”,因为你不再需要共享实现类。

InfoQ:沿着成熟度模型发展会节约成本么?能不能逐步做到?

Graham Charters:是的,会节约成本,清楚阐明这一点也是模型的目标之一。我想为每一层都提供一种通用的表达,说明组织必须具备什么特征,也就是在模块化方面,组织必须反复做哪些事情,以及这么做的好处。就开发、构建和运营时所采用的具体实践来说,升级到上一层会有成本,但也会有好处。我描述了解耦方面的所有好处,每次解耦都能提升组织的敏捷度,进而降低成本、减少实现价值所需的时间。举例来说,一个组织要从模块提升到模块化(从级别二提升到级别三),必须要去描述他们模块的外部环境,让开发、构建和运营适应新级别。这样做的好处是能更深刻地认识系统结构,降低系统的腐坏程度,让系统更易于维护。模块有任何变化,你都可以立即确定它对系统的影响,因为模块可以描述这是个不会引起中断的实现变更,还是个 Bug 修复,抑或是会引起变化的实现等等。你也不用关心模块重构,因为模块的消费者不再关心某个功能到底是哪些模块提供的。最后,要是有任何重大的结构变化,你很早就能知道警告信息,因为你马上就能确定是否有没满足的需求。

当组织成功营造这么一个环境,或是围绕模块展开协作(提交、审查、讨论等)的环境,他们就不太可能去创建重复的模块。这就会降低成本、提高重用率。随着重用率的提高,质量也会提升。那组织又有什么理由不让他们的开发人员去搜索所需的 API 和服务,把高质量的模块放到项目里,而是让他们去找一些不知质量如何的东西,或是从头编写呢?

InfoQ:这些判断标准是专门针对 OSGi 的么?还是它们也适合其他的模块化框架?

Graham Charters:这些判断标准和好处都与技术无关。我这么做是出于两个原因,第一,我觉得这有利于向更多的组织解释某一级别需要具备的特性。如果一个组织处于级别二(模块化),他们并没使用 OSGi,那跟他们谈论导入包和导出包就没什么意义,告诉他们定义模块外部环境的好处则比较清楚。第二个原因是,这样能帮助人们去评估模块化框架。并非所有的模块化框架都是相当的,所以这个模型可以帮助人们确定所需的特性和好处,从而确定适用的框架。

InfoQ:有没有计划把这个模型作为正式的标准文档,通过 OSGi 或其他组织发布出来呢?有没有相关的时间表?

Graham Charters:坦白说,我不确定这个想法是否能被认可,实际上我对这些正面的响应也有些不知所措。我希望有人能喜欢这个主意,而且愿意一起合作。我不确定这算不算授权标准,但我知道它正在制定白皮书,类似于 OSGi 联盟发布的语义版本。我希望下个月左右能发布第一版。

InfoQ:作为行业和 OSGi 社区,我们能从成熟度模型里学到些什么呢?

Graham Charters:我在 OSGi 社区大会上做的调查并不是很科学,调查结果显示,大部分组织和项目处于级别二(模块)。就个人而言,我相信在提升到级别五(委托)的过程中,质量和生产率方面会受益颇多。对拥有大型分布式开发和运营团队的组织来说,尤其是这样。如果我们设定的目标是级别五,我们就需要说服人们去接受更高级别的好处,让他们尽可能简单地从现有级别向上升级。举例来说,要提升到级别三,就需要用好的工具去定义模块的外部环境,执行持续构建,让模块和系统分析发现潜在的问题、帮助确定问题。

OSGi 社区 Wiki上的模块化成熟度模型已经可用了。你的项目或组织处于模块化成熟度模型的哪个级别呢?

查看英文原文Modularity Maturity Model

Java语言 & 开发架构