面向对象的架构(SOA)终于已经改变其方向:公司正在从试探性的第一步，只是用于少数分散系统的服务，转移到战略上SOA的全面推广，这一推广已经得到了IT部门高级经理以及业务主管的认可。通过去年ZapThink 所接受的上百次采访，我们已经意识到了一个清晰的确定的发展趋势:体系结构正在朝着SOA的方向发展，而远离过去的那种紧密耦合的脆弱的集成方法。我们不再对“什么是SOA””及“为什么要用SOA”质疑，而是希望了解“如何使用SOA”和“什么时候使用SOA”。实际上，公司已经不再讨论是否需要着手开始使用SOA。最终转移到SOA - 正在迅速地变为既成事实。

　　在这个具有决定性的朝着SOA方向发展的过程中，现在我们开始遇到更多难以解决的策略上的问题，它们是关于如何实现SOA的。其中一些问题是内在的组织结构方面的问题，同时也有很多技术上的问题。这些问题一般集中在SOA的核心争论上。虽然我们无法同样地把重点放在处理那些技术上的有力反驳，例如:启动并发的基于事务处理的系统，并使其达到每秒百万条信息吞吐量的最好办法;但是相反地，我们完全可以着重解决一些人们可能提出的关于SOA的最简单的问题。大多数问题集中在如何创建一个服务。特别地，许多系统架构师向我们提出的问题是:确切得说，在服务契约中应当包含哪些内容。

　　服务契约:SOA最重要的原数据

　　在面向对象的架构(SOA)中，最基本的交互是在服务提供者和服务用户之间进行的。对于每一次这两者之间的交互，其中一方提供数据和功能的某一组合，而另一方则使用它。在提供者能够向用户提供所有的由该服务提供的数据功能之前，无论采用何种方法，这两者必须达成共识，或者说建立契约，来指定提供者正在执行的这个服务的详细信息。就像是建立任何好的合法契约，这两者处于“正常交易关系” – 也就是说，它们仍然是相互独立的个体，双方不会互相干扰彼此的事务处理，除非契约明确规定需要这样做。从本质上而言，这个契约使提供者和用户之间的关联关系满足松散耦合。

　　值得注意的是:然而，在这个交互过程中存在两种不同性质的契约。第一种，在两个业务实体之间有合法的约定，第二种是这两者之间的旨在共同协作的技术关系。为了简化这个技术关系，我们可以在契约中使用一个代表某些简化的抽象，这些简化是针对服务如何象个体一样工作而言的。 正像合法的契约是对一系列可执行规则和约定进行概述的文档，这些规则和约定是由双方都理解的语言编写的，在IT业我们也需要以用户和提供者都理解的标准化方式来定义一个保证IT“约定的规则”的契约。这些信息同样也应该写入对每个使用者而言的外部文档，这个文档为每个使用者提供其相互交流所需要的信息。

　　这些契约是松散耦合的关键，这句话抓住了SOA的实质。松散耦合要求交互的双方应该含有尽量少的控制它们之间关联关系的必要信息。更进一步，我们希望软件满足松散耦合的全部原因在于:这样的话，我们可以完全独立的创建和控制每一个IT环境下的组件。我们选择实现松散耦合的方法是:通过实现系统的契约接口，以及当允许交互双方的每一方都可以独立改变它们实现契约的方式时，确保我们仍然保持那些已被契约约定的关联关系。

　　契约和策略

　　因此，如果契约是使服务起作用的关键，那么确切地说，在服务契约中应该包含什么内容呢?正像合法的契约促进牢固的业务关系一样，软件契约也促进牢固的松散耦合的分布式计算。 下面介绍契约中包含的内容 – 计算机需要理解的性质，而不是人需要理解的性质。

　　契约应该描述功能需求，也就是说，提供者将向任何选择遵守契约内容的用户所提供的功能。契约应该定义提供者所提供的函数，返回数据或者是这两者的组合。

　　契约也必须指定非功能需求，不仅仅是服务做什么而是它针对业务如何做的详细信息。这包括两方面的信息，提供者为提供其功能以及数据的责任，同样用户提供其功能以及数据的期望的责任， 以及他们需要提供的返回，例如有效性，安全性，和基于服务考虑的其他性能。

　　契约也需要指定在用户和提供者之间的约定的规则，这就是通常所说的策略，控制谁可以访问提供者，使用者必须遵守的安全规程，以及其他所有的适用于这个交换的规则。

　　契约是对服务行为的可见内容的表示，因此在契约中绝对不会包含提供者和用户实际交换的数据，或者任何关于提供者和用户是如何满足契约要求的说明。另外，由于用户是随着提供者的变化而变化的，那么对于一个简单的服务就可能存在多个契约。另外一个关于透明度的观点就是契约和策略两者之间的差异。这些术语的定义可以千差万别，但是理解这个差异的普遍方法是:策略是一系列条件，它们可以适用于任何数量的契约，从不包含契约到包含所有的契约。例如，一个策略可能表明所有的服务交互必须是由安全套接字层保护的(SSL-secured)，而且在一个体系结构中，这个策略可以适用于所有的服务契约。

　　为什么Web 服务定义语言不足

　　所有Web服务契约的核心是Web服务定义语言(WSDL)，它为服务提供者构成了基础的契约，把服务标识为Web服务。然而，在很多方面，Web服务定义语言并不能充分描述契约的所有要求。首先，Web服务定义语言仅仅定义了一套基础的功能需求，尤其是当它们应用于Web服务的时候。Web服务定义语言也不足以定义非功能需求，例如对一个服务而言的安全性，交互性能，处理性能，商业性能，可靠性和服务级别要求，而且它甚至不能确切定义一个服务实际上产生的数据的语义要求。因此，服务契约需要更多的信息，而不仅仅是Web服务定义语言所提供的。

　　理想地, 假设存在一种通用的服务契约定义语言，它包括服务语义描述, 服务能力和限制的定义，以及一个数据和行为都适用的交互模型。然而，这种单独的语言是不存在的。取而代之，有一系列附加的规范，它们在开发中扩充Web服务定义语言(WSDL)，设法增加服务契约的丰富程度，但这样的操作也只是一点一点地勉强进行。

　　在这些与契约相关的规范中，最显著的是策略规范例如Web服务策略(WS-Policy)。WS-Policy并不为定义策略提供实际的语义，而是为指定策略考虑的范围提供一个通用的容器。因此，我们需要附加的规范来更加详细地指定非功能需求，例如Web服务安全性(WS-Security)、Web服务业务流程执行语言(WS-BPEL)、Web服务编排描述语言(WS-CDL)、Web服务等级协议(WSLA)和Web服务提供语言(WSOL)。我们同样迫切需要的还有另外一些规范，它们旨在为定义服务契约提供一个更加完整丰富的语言，例如面向服务的Web本体语言(OWL-S)。

　　然而，你并不需要等到这些规范都制定好了才去创建完美的合法的服务契约。在此期间，你必须以提供者和用户都理解的格式指定契约元数据。下面是这套步骤是我们推荐企业执行服务契约定义流程

　　第一，定义服务

　　定义服务所提供给预期用户的价值

　　描述服务的功能

　　叙述服务品质和适用性的约束条件

　　定义用户类型或其他使用要求的约束条件

　　下一步，定义如何使用服务

　　定义请求的消息和语义格式

　　识别特殊结果和行为的条件

　　确定产生结果的处理、活动、步骤的流程

　　最后，定义服务间如何交互

　　定义用户如何与服务通讯

　　描述可接受的通讯协议

　　选定适合的调用风格(请求/响应、通知、事件驱动)

　　设置你对期等待时间的期望

　　完成上述这些步骤之后，你将处于很好的状态来创建基于定义明确的契约并且满足松散耦合的服务。

　　ZapThink

　　显而易见，如果不关注规范的话，那么现在这些公司都还正在努力解决如何创建服务契约的问题。规范在不断增加这一事实是非常重要的标志，它表明了面向服务的架构(SOA)是多么的具有生命力。然而，你并不需要等待所有的元数据规范都整理就绪了才创建服务契约。事实上，一个公司所能够做到的最重要的活动之一就是:使用一种人类可以理解的语言来定义他们公司的契约和策略。

　　如果人们能够把注意力从开发代码上集中到在开发契约上的话，在创建松散耦合系统这一领域，我们早就已经取得重大进展了。下一步要做的就是:把这些契约和策略编码，使服务能够真正的工作。选择元数据规范和语义来进行这样的操作将反映出你已经做出的决定乃至你认为契约中应该包含的内容。

　　请记住，契约无非就是描述用户如何交互的元数据，策略也是元数据，它描述的是那些具有权限的用户进行交互的条件。因此，面向服务的架构(SOA)是有可能实现对策略和契约所作的改变进行响应，而不需要通过紧密耦合的，死板的程序设计 – 本质上就是，改变策略，调整契约，用户和提供者仅仅遵循修改后的契约。这就是SOA的先见之明在起作用。