使用MDSD开发安全可靠的软件

核心提示： API 的不兼容性 每个暴露给外部的API都声明了提供者与其编程接口的潜在消费者之间的契约，使用新的不兼容的API替换现存的API将会导致正在使用旧API的客户端死锁，使用MDSD开发安全可靠的软件(4)，这不仅只是针对类似Java的普通编程语言，对于所有暴露接口的形式（例如Web服务）都一样，

API 的不兼容性

每个暴露给外部的API都声明了提供者与其编程接口的潜在消费者之间的契约。使用新的不兼容的API替换现存的API将会导致正在使用旧API的客户端死锁。这不仅只是针对类似Java的普通编程语言，对于所有暴露接口的形式（例如Web服务）都一样。

API的不兼容性可以通过一个专门的向后兼容层来解决。当软件系统无法支持以前版本API，而只是暴露最新版本的API时，我们可以在目标系统（客户端系统）前部署向后兼容层，它会提供当前软件系统中所有版本的API。对于这个向后兼容层到底是以中间件ESB（企业服务总线）的形式部署还是直接部署于目标系统中我们不做深究。向后兼容层在此扮演了一个API门面的角色，它在各API版本间进行消息转换[7]。有了这个架构，我们就需要制定消息转换的规则。

对于每个不兼容的API都必须定义对应的消息转换规则，这是MDSD的关键所在。在重要项目中，我们应该将定义消息转换规则视作正常处理而非异常处理。因此，编写转换代码是经常性的并且是非常关键的任务。如果遗漏了一项转换，那么就会导致无法使用以前对应版本的API接口。如果遵循模型驱动方法，API接口应该定义为一个模型。对于软件系统的每个版本都对应一个模型。当比较不同版本的API接口时，可以通过对比它们对应的模型实例看出差异。由此您可以得到所谓的系统差异模型，其包含了两个系统版本间的所有差异。以该差异模型作为输入，可以生成一份可读的变更报告，该报告描述了两个系统版本的细节差异。以该报告作为检查清单，您可以控制系统发生的所有改变。而不会再忽略了任何一个变更或是遗漏了编写该变更对应的转换代码。对于一组接口的变更处理和上面是类似的。有了差异模型，您可以更顺利地处理后续项目任务。另外，对于转换通常是给转换数据添加一个必须的类型字段，以标识出该消息需要转换成的类型。对于同一类消息的转换而言，这项工作是非常乏味、重复的，最好将其自动化。在没有模型驱动支持时，开发者不得不手工编写所有转换代码，但当我们拥有整个变更信息时，通过模型驱动的方式，可以以某个确定的标识模式生成消息转换代码。这可以将开发人员从重复、易出错的任务中解放出来，将他们的时间投在其他更值得去做、更有挑战性的任务上。当然，模型驱动的方法也是有局限性的。100% 生成转换代码只是一种乌托邦式的期待。在模型中总有一些复杂变更不能标识到模式目录。对于这样的情况，转换只能手工编写。因此，我们需要时刻谨记区分自动生成与手工编写变换代码的最佳实践[2]。说到这里，您可能会问“为什么我们要付出如此多的努力在向后兼容上？”，这个问题问到点上了，而且必须针对每一种不同产品的具体情况来回答。对于历史遗留系统，您没有选择，必须保持向后兼容。这点在电子保健领域印证无疑。有很多医疗机构需要与中心外部系统保持通信，而这些中心系统一般都非常古老，并且希望有稳定的接口与其通信。改变目标接口，那么每个医疗机构都必须做出相应的修改。投入一些时间来解决目标端的不兼容性冲突比想办法移除所有异构遗留环境更为合理。