模块化成熟度模型

在九月下旬召开的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