当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来说，路还很长。

　　在随后的文章中，我们会继续为您介绍松散耦合的七个级别中的其他内容。敬请关注。