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

核心提示： 更动态的类型控制在端点处是很重要的，因为这些端点会在以不同速度演变的系统之间形成一个已发布的集成 API，演化架构和紧急设计: 演化架构(7)，您想在那些系统之间避免严格耦合的特定签名（类型和参数名），因为那样会使通信的双方都很脆弱、容易崩溃，但那并不会有很好的效果，根本问题就是端点间的严格耦合

更动态的类型控制在端点处是很重要的，因为这些端点会在以不同速度演变的系统之间形成一个已发布的集成 API。您想在那些系统之间避免严格耦合的特定签名（类型和参数名），因为那样会使通信的双方都很脆弱、容易崩溃，削弱了您分别对两个应用程序进行版本升级的能力。

这里有个例子。在传统的 SOAP 式集成中，使用的协议类型是 Remote Procedure Call (RPC)，并用 WSDL 来定义两个应用程序间通话的详细信息，如图 5 所示：

图 5. 在应用程序间使用 RPC 式调用

RPC 式集成使用 WSDL 来进行一个 “常规” 方法调用，并将其抽象出来发送到 SOAP。这样，每个类都映射到 WSDL 中的一个类型，包括其所有参数的类型。这种方法将通信双方强烈耦合到一起，因为它们都依赖 WSDL 来定义发送的内容和预期接收的内容。问题源于这种严格的定义。如果您需要修改其中一个应用程序来采用不同的参数或者改变现有的类型，且不能同时更改这两个应用程序，那又该怎么办呢？该如何对端点进行版本控制？有几个方法是可行的，但所有这些方法都有严重的妥协之处。例如，您可以用新的 WSDL 定义创建另外一个端点。如果原始端点命名为 addOrder，那么您可以创建另一个端点，命名为 addOrder2。您会看到这种方法前景不妙。不久，您就会有数十个稍有不同、到处包含重复代码的端点来处理一次性情况，因为一旦发布，就很难预测人们会怎么应用这些集成点。您也可以使用 Universal Description, Discovery, and Integration (UDDI)（或者仅仅是哈希图）这样的工具来欺骗端点，但那并不会有很好的效果。根本问题就是端点间的严格耦合，那会阻止其按自然、独立的速度发展演变。