当ZapThink考虑做面向服务架构（SOA）的时候，我们通常要避免关于“什么是或者不是SOA” 语义的争论，但是侧重于确定面向服务系统的特性和提供机构采用的架构方法的益处。尤其是，我们要致力于三个核心的原则：消费者和供应商之间的服务的松散耦合、多种等级粒度的可组合性和事件驱动，异步样式的相互作用，可以实现广泛的使用方案。

　　然而这些特性似乎是不同的，实际上他们是相互连接的。在长时间运行的事务的环境中要组成任意的服务，需要一定的松散耦合。然而，架构师似乎对“松散耦合”这一术语感到困惑。一些人错误的认为，系统要么松散耦合，要么紧密结合，就像耦合的测定是二次评价一样。现实情况是，耦合这个概念就像粒度一样，是一个相对的概念。有些事情比允许更大程序的变化，和特殊方面的自由更加的松散耦合。简而言之，耦合是为了让服务的供应商和消费者得到更好的结果，而在一定程度上的依赖性和通用性。

　　鉴于这种情况，松散耦合是一个范围。系统可以在一个方面紧密结合，而另一面松散耦合。许多架构师说，他们想完成系统的解耦，以至于可以处理系统中的一些变化，而不必重新实现服务的供应商和消费者。因为在ZapFlashes上我们已经讨论过，完成解耦是极其困难并且昂贵的，甚至不可能办到。所以，在不花费巨大的成本的情况下，什么是架构师为实现正确的松散耦合等级，促进业务的敏捷性而做的计划呢？

　　因此，ZapThink已经发现了七个真正的级别，或者在他们的SOA提议中，架构师应该考虑松散耦合方面的事情。他们的SOA越大程序和水平的松散耦合，那些系统越能更好的处理变化。

　　松散耦合的实施

　　SOA最基本的承诺之一是服务的消费者对服务的供应商使用的实施技术视而不见，反之亦然。甚至，服务抽象的整体思路是，技术的实施被掩盖。SOA最基本的特点是用基于标准、互操作性规范和协议实现的，在服务消费者和供应商之间提供基于契约的整合。Web服务作为REST和其他样式的服务实施一定符合该法案。事实上，这个等级的松散耦合不是互操作规范（基于XML或不是）的选择，而是服务契约。适当的服务契约将允许服务消费者绑定到广泛的服务供应商的实施，而根本不必知道服务的实现是否用Java、 .NET、PHP、C++、或者是Basic。所有的SOA实施必须至少是松散的！在实施的等级上耦合，但是要清楚，这不能保证完成业务所需的松散耦合。

　　松散耦合的服务契约

　　XML、Web服务、REST和其他规范掩盖了服务的实施，如当服务实施改变，服务的消费者不需要知道这件事。然而，当服务契约本身变化时会发生什么呢？简单的改变系统可接受的输入或功能的行为，能够对服务消费者产生深远的影响。因此，架构师想要处理他们的SOA提议，并超越简单的Web服务整合，需要解决服务契约变化的管理，在契约改变的情况下不能破坏服务的消费者。

　　这似乎是一个困难的提案，但是，有大量的最佳做法、架构方法和技术来减轻这个等级的松散耦合的困难。首先，适当的服务契约，中立的接口会减少很多服务契约改变管理的问题。在得到ZapThink架构师的许可（LZC），ZapThink共享了服务描述架构（SDF），中立服务契约模板之一。在那些方法中，新的服务契约不只是取代旧的。如果服务消费者不提供转换路径，旧的契约永不过时。这可以视为简单的转换，或者是复杂的面向服务流程，当服务消费者请求旧（弃用）的版本的服务契约时被触发。因此，契约的改变作为策略问题必须被处理。人们应该通过元数据控制得到的服务的版本，而不是通过程序或者紧密耦合的基础架构。

　　积极的管理和服务的媒介可以进一步简化服务契约改变管理的问题，如提供异常管理和处理不同服务契约。当然，SOA治理在这里起到了巨大的作用，帮助管理那种改变和版本出现的问题。但是在这一领域的最佳实践是后期绑定方法的使用，利用运行时的注册和基于契约的结合，抽象服务消费者的绑定规范，防止传播服务契约的改变。后期绑定的主题本身是一种深入的会话，需要重新思考服务消费者绑定服务供应商的方式，对于ZapFlash来说，路还很长。

　　松散耦合的服务策略

　　发挥服务契约的作用，要抽象实施、后期绑定、使用媒介、基于注册的系统要在没有断裂的情况下，允许无破损服务契约的改变，使系统更大程度上变化，但是我们远远还没有完成。事实上，即使服务契约保持稳定，服务策略的一处小的改变可能产生巨大的反响，这就是我们讨论的ZapFlash蝴蝶效应。

　　公司着眼于处理服务变化应该以他们处理服务契约相同的方式处理策略的改变：后期绑定、使用服务媒介、基于注册和治理。策略是一种元数据的形式，如契约，而事实上，服务策略和契约的唯一不同是，策略可以适用于多种服务。因为策略控制服务的非功能部件的许多方面、架构师需要为处理服务策略版本的控制，包含在他们的架构方案方法和实践中，以及利用这些为服务契约建立的技术和实践的策略版本。公司需要测试策略，正如他们测试服务实施一样，管理策略如严格管理服务一样。这样做不仅能使系统更加可靠，还能使用更多等级的松散偶合。

　　松散耦合流程

　　当然，松散耦合服务消费者，如果服务不能聚合在一起，服务供应商只能提供灵活性。一旦你有一个业务流程，构成一群服务，我们有一个潜在的紧耦合区。当流程改变了会发生什么呢？理想地，当流程重新配置时，服务消费者根本不必知道。幸运的是，实现这一等级的松散耦合是相当简单的。

　　SOA和BPM市场的趋向已经从基础的实施朝向单独的流程定义层发展。通过在元数据中定义流程，并用服务契约导出那些流程（递归的服务和暴露其服务），从服务消费者中抽象出流程的实施。事实上，在这种情况下，业务流程实际上是服务实施的一种形式。正如服务契约提供服务实施的松散耦合，他们提供松散耦合的面向服务流程。

　　松散耦合的数据模型

　　如果我们已经使用以上定义的所有松散耦合的等级，公司应该能使他们的服务实施、契约、策略和未破损的流程任意变化。然而，这不足以应付不断变化的业务需求。当基础数据模型改变了会发生什么呢？如果服务消费者和供应商需要有共同的认识，为了之前定义的紧密耦合进行一次会话。因此，机构需要进一步他们的松散耦合目标，在服务的消费者和供应商之间共享数据模型，能使他们动态的、多种多样的改变。

　　对一些人来说，这似乎是一个非常复杂的任务。计算机毕竟不是人，所以他们不能处理任何格式或者数据定义的变化。然而，在这里，并不是所以希望都不能完成。首先，服务不能真正的互操作，除非他们能够理解和处理常见的数据。这意味着，尽管在他们之间存在语义依存的关系（我们会在短期内解决），因此不需要在他们之前信赖结构数据。模型的关键是服务数据的互操作性。然而，当模型改变了会发生什么呢？一个关键的方法是与你服务元数据的管理相同的方法，来来解决信息和模型的管理。数据模型可以视为元数据形式和异常管理、转换、服务媒介和数据服务（在这里详细描述）的使用，是使用所有松散耦合的数据结构的关键。引入松散耦合实施数据层，在某种程序上，提供了不同的关注点，以至于最根本的基本数据改变与上面的业务服务隔离。

　　此外，公司需要使维护服务的元数据和维护数据模型的结果一致。为什么维护模型的人们不是架构团队的一部分呢？模型与服务契约是不同的。他们以编码的元数据形式表示业务需求。因此，我们经常告诫公司，把他们架构团队的数据和信息引入到企业架构中。这个简单的调整和建立元数据并能够改变管理的行为，允许松散耦合数据模型和结构。

　　松散耦合的基础设施

　　在我们解决松散耦合最后一个困难之前，值得注意的是，如果它依靠一个供应商实施的话，这些所有等级的松散耦合都无关紧要。很多次，我们与声称他们的系统是松散耦合的架构师交往，但是如果他们从企业服务总线（ESB）或服务的基础设施迁移他们的实施到另一个地方，那么就会违反耦合。怎样才能真正的说他们的实施在如此庞大的信赖性的情况下是松散耦合的呢？企业架构师不值得全信，要求他们的服务的基础设施是中立的。这意味着，在任何时候，公司可以改变他们的基础设施，而不必重新建立所胡服务的消费者和供应商。

　　许多厂商承诺这种可交替性，但很少提供。事实上，整个行业似乎迈向单一供应商的SOA平台，这将使许多SOA提议在这一层紧耦合。这个ZapFlash服务作为警告公司，想要实现高程度的松散耦合：保持你的实施基础设施的中立，你就会成功。否则，你的SOA提议只能使你的业务部分的灵活性。

　　松散耦合的语义层

　　最后一级松散耦合是最富有挑战的。即使公司启用服务的实施、契约、策略、流程、基础设施和数据结构等它能想到的所有的变化，每当改变语义时问题仍然出现。正如我们进行详细的语义整合：松散耦合ZapFlash数据的含义，如果我们强迫服务请求者使用服务供应商的数据结构，结果是之前的架构方法完全是紧耦合的。为了提供准确无误的数据整合的承诺，我们必须超越简单的松散耦合应用程序接口，另外在语义层提供松散耦合接口。

　　当我们详细讨论那些ZapFlash时，为了实现我们寻找的那种主义数据整合，我们必须实施动态服务定义。本质上，服务接口的定义必须基于服务请求者的环境改变。因此，服务能够在调用时改变它的契约。例如，服务供应商需要姓名不能超过40个字符，不应该要求请求者知道这个事实。契约服务接口支持提供隔离。服务接口因此必须变得比之前更加的智能。而不必提前知道服务需要哪些具体的数据。服务请求者应该能够动态的发现服务的接口，不仅提供所需的功能，而且还要了解信息净荷容量。

　　ZapThink的需要

　　SOA作为一个整体，在复杂系统的松散耦合中是一个应用，必须合作以满足业务需要。因此，随着企业寻找他们成熟的SOA提议，他们应该设法通过上述不同的等级，反复松散耦合他们的系统。松散耦合最令人惊讶的部分是系统最大程度的容错性，使你的业务更加的灵活。不仅如此，如果企业能够设法解决这七层松散耦合，同时保持一定的架构开销，那么我们已经达到IT和业务关系的理想状态：IT可以不用施加任何额外的时间或者开销，实现业务所有的需求和期望的结果，

　　具体而言，系统能够使用七层松散耦合，改变服务的实施、业务流程、服务契约、服务策略、运行时基础设施、数据模型和语义而不会破坏系统。你能想到在那些等级的松散耦合中不能解决的业务需求吗？这种敏捷性视角正是SOA的目标，它明确要求明白SOA比简单的实施仅是Web服务提供的松散耦合的能力更加广泛。