ZapThink总在说变更，因为变更是企业业务中总在发生的事情。毕竟，变更对于业务来说就是要实现SOA的优势，因为实施SOA项目的主要原因就是改进今天脆弱的、不灵活的、紧耦合的系统，提高其业务灵活性，同时降低IT费用。但是，我们也不要太过陶醉于SOA的美景中，因为实现SOA本身也会引入变更，这与SOA要解决的变更问题同样重要。SOA实现必须得变更，否则企业就不能意识到SOA承诺的灵活性和成本节省。于是，当处理今天企业需要的SOA时，就产生了一些变更和版本问题。

　　版本化服务合约元数据

　　ZapFlash提出的核心问题是如何为变更构建SOA实现，而没有版本和变更管理的缺陷。当然，任何有关SOA的变更的讨论都应该从松耦合开始。作为SOA的一个主要优点，松耦合让开发人员能够自由的改变服务的实现而不必改变服务的消费方，反之亦然。这种松耦合让企业在面对IT异构性时拥有了灵活性。但是，松耦合并不意味着对服务的任何改变都不会影响到其它部分。实际上，松耦合只有在底层实现仍然遵守现有服务合约时才起作用。因此，对服务合约本身的变更将带来大麻烦。

　　ZapFlash的What Belongs in a Service Contract文章中指出，服务合约包含描述如何与服务交互的功能性元数据以及定义在什么条件和约束下消费方能访问服务功能的非功能性元数据。按照这种说法，WSDL只是定义服务的一小部分元数据。我们还需要安全、处理、服务质量、商业需求等其它信息。在SOA中，合约对服务代码同样重要。因此，当开发人员决定对合约元数据进行哪怕细小的改动，例如可接受的安全需求或服务质量，就会造成非常严重的后果。任何遵循合约元数据的服务消费方将被打破，整个系统也不在起作用了。

　　那么，松耦合还有意义吗?毕竟，意义在于只存在服务实现变更，而不能改变服务合约元数据。因此，企业实现服务时如果改变服务元数据，怎样才能不对工作造成影响呢?这就必须保证老版本的服务合约得到有效维护，直到企业确认不在有消费方使用这种合约元数据为止。

　　策略版本化

　　安全和策略元数据是服务合约版本化讨论的一部分，但是改变服务合约只是策略版本化问题的一部分。策略是应用于任何数量服务的一套规则。策略管理着在什么条件下消费方能够访问服务功能。有的策略可能与安全有关，而另一些策略可能与时间或过程有关。策略可以应用到多个服务，因此在服务合约中单独维护策略就很重要。在一些大型组织中，管理服务策略的人是从管理服务实现或服务合约元数据的人中间分离出来的。于是，策略很可能在服务合约元数据保持不变时发生改变。

　　独立改变服务合约和策略会显著增加SOA实现的复杂性。不管在什么时候，对一个策略的改变会影响到不确定数量的服务，使其停止功能。有两种方法防止对策略的改变造成未知的后果:通过实现控制谁在何时能改变策略的元策略，以及通过建立对创建、通信和加强这种策略的足够控制。用这种方法，策略只能被授权的个人改变，甚至只能在对后果有足够认识时才能改变。

　　但是，实现自身的合适管理并不能解决元数据版本化问题。一个潜在的问题是，他们自己的SOA实现只在后来才请求对这种服务的跨组织边界的共享。此时，尽管有管理可以限制服务合约与策略变更时带来的影响，但决定企业如何创建与建立控制框架的元策略的改变会导致不可预知的后果。实现控制的附加层将带来无数策略和服务合约的变更，导致迅速增加的开销和复杂性。因此，在SOA项目早期拥有合适的企业级控制框架对项目的成果非常关键。

　　模式版本化

　　一个比处理合约与策略问题更困难的问题是处理服务消费方与提供方数据交换的问题。当服务合约元数据和策略保持不变而数据模式发生改变时，会发生什么呢?在这种情况下，服务很有可能无法互交互和通信。毕竟，服务合约仅仅是系统之间的接口。通过这些接口流动的是系统相关的真实数据。在ZapFlash Semantic Integration: Loosely Coupling the Meaning of Data的文章中，我们认为如果服务消费方和提供方都决定于对通信数据的相互理解的话，那么我们只能得到可接受的松耦合级别。因此，决定今天很多服务的一些词汇表和本体将在可服务的对话中得到共享。在面向服务的环境中，这种在模式中描述数据的词汇表会发生变化。

　　为了解决改变数据模式的问题以保护服务的互操作性，对模式的管理必须与对所有服务元数据的管理同时进行。实际上，我们应该把数据模式和语义看成对服务交互非常重要的元数据的关键部。不管什么时候模式一旦发生改变，所有相关服务就应该被检查，以确保它们依然能够遵循各自的服务合约。甚至还要把管理扩展到数据模式管理，因为整个架构的可靠性都依赖于数据模式管理的可靠程度。

　　The ZapThink take

　　有了所有这些在SOA实现中元数据的改变方法，一个组织如何对它的服务交互进行审计和日志呢?为了理解可审计性的问题，让我们来看看组织在哪里为今后的检索而保存所有的服务消息，很可能是出于调整兼容性的原因。假设，一年后他们调用其中一个服务，接着会为了验证而检索数据。但是，在这一年中，模式、服务合约和对访问数据的安全策略都发生了改变。结果，被保存的消息无法依据现在的模式而生效。而且，现在的用户也不能被授权访问这些消息。就算他们可以访问消息，也没有办法在各种系统中跟踪其交互，因为合约和过程已经在过去一年中发生了改变。

　　企业可能会通过保存所有元数据的版本来解决问题，以使得用户可以重新创建某个时间点上的系统。但是，这种方法是不现实的。有太多的数据需要保存，太多的相关改变需要跟踪消息历史，而且在这些数据上重建系统也不容易。缺乏可审计性是现有SOA最佳实践还没有解决的问题。

　　但是，还存在非SOA才有的问题。不过，SOA还是让组织有决心解决所有的变更管理问题。今天，企业还没有看到变更管理的问题，因为系统还没有充分互连，而且是紧耦合的，变更被局限在特定系统内。IT组织正在花费如此多的精力让系统互通，以至于还来不及关心管理、策略、版本化方面的问题。SOA不只在系统基础上为变更提供了一种统一方法，它更是通过一种系统方法提供了解决所有元数据变更的途径，不论是底层系统、还是过程或者应用程序。

　　如果企业希望实现松耦合，很明显，他们必须投资元数据管理。但是，真正的问题是，企业需要领悟到变更是不可避免的，即使在SOA的时代，也是如此。他们必须对处理这些变更有足够的方案，以避免在采纳SOA后就遭到失败。