演化架构和紧急设计: 演化架构

一种替代方法就是把集成端点当做宽松类型对待，如图 6 所示：

图 6. 在集成端点采用宽松类型控制

通过将有趣的端点信息传送到一个文档内，您可以在通信双方任意一方主要升级和次要升级过程中保持端点定义不变。您可以灵活选择，而不是依赖 WSDL 来严格定义预期的内容。现在，端点总是接收一个封装该端点所需类型的文档。

要解决端点的版本控制问题，端点要做的第一步就是把文档解开，确定已经传输的内容，并用预期的内容与之协调。我通常联合使用 Factory 和 Strategy 设计模式来确定是否正在获得预期的内容，如图 7 所示：

图 7. 在端点内解开内容来确定类型

端点的首要工作就是查看文档的清单，确定它包含的内容。然后，它用一个库来实例化适当的策略，将那些信息从文档中抽出。一旦所有部分都通过验证（必要时可用 WSDL），反序列化的对象就被传递，用于业务处理。

这种方法有几个好处。首先，拥有一个带有两个正交作业的机制是个坏主意，然而那正是传统 RPC 所假设的：端点既要负责提供已发布的集成 API，又要负责验证类型。因为其有两个行为，所以您可能会弄混代码，使其更难理解和维护。其次，现在这个端点可以有多个用户，每个用户使用稍有差异的版本。只要您有一个策略，您就能够用相同的端点支持任何版本（包括那些更新缓慢的应用程序的老版本）。这允许您根据需要进行改变，不用担心这会迫使企业内应用程序的其他部分和您的改变保持一致 —— 它们可以根据自己的进度改变并使用新的文档版本。

目前没有任何工具或者框架允许您轻松地实现这种方法，但是一些额外的前期工作提供了之前提到过的好处。您可以使用 SOAP 或 REST 来实现这个样式（不过在 REST 中会更容易，因为它本身就是以文档为中心的）。通过创建一个宽松类型的生态系统，您可以使不同的开发小组按自己的节奏开展工作，从而使整个企业的应用程序使用以最小的摩擦前进。这就是演化架构的精髓：奠定一个基础来支持尽快实施无摩擦的、不损害功能的变革。

结束语

架构是个庞大且复杂的软件主题；在这部分中，我试图涉及许多不同的方面，从政治到 SOA 中的端点版本控制的实现细节。在以后的部分中，我将不断充实这些关于一般架构和新架构方法的想法，帮助您构建一个可发展的 SOA，以免向软件商支付数百万美元的高额费用。