如果你进行计算机编程有何我们一样长的时间，你很可能记得你第一次试着去写一个面向对象程序，可能是用C++或者Java。这种做法的趋势是试图把所有的代码放到一个当读的对象中去。它花了一些时间让我们对这种开发对象表示的软件的新方法有了一些想法。总之，如何学会用C++和Java编程是很简单的事情，但是学会如何去构建一个“对象”确实在是很难的。从某一点来说，自从存在的一个时刻你发出“aha”的感叹是，你总是会想为什么以前会用其他的方法来编程呢.

　　转移到面向服务的开发也要求你的思维要有相同的转移。开发者试图构构建一些Services，尽管他们很多都已鲜有的功能的简单的API。确信的是，Web Services使得能够采用基于标准的接口，但是这又有什么关系呢?仅仅把所有的代码放到一个对象里面，这是一种缺少对新的方法的理解的表现，“每个服务一个接口”的想法也是由于那个关键的“aha”时刻。为了能够深入的了解Services，你必须了解在SOA中服务，合约和策略之间的关系。

　　一个服务可以有多余一个的合约吗?

　　面向服务的最主要的一个目标是把这个服务的接口(由合约和相关的元数据表示的)同这个服务的实现(由接口抽象出来的实质代码表示的)分离开来。由于我们在一个ZapFlash合约中定义的归属关系，一个服务合约定义了服务提供者和服务消费者之间的关系，以及对于涉及到的信息交换相关的需求。为了翻新，一个服务合约包含了两个重要的部分:具体的对服务消费者和服务提供者有什么样需求的功能性需求，第二个是管理和限制两者之间的相互作用的非功能性需求。尽管这些定义在表面上就非常清楚了，但是必须理解任何特定的服务都可以具有多余一个和它相关的合约，理解这一点这是很重要的。

　　实际上，一个服务具有多个合约是一种最好的练习，正是这种很明显而自然的方式，实际上就是一个最好的练习。届时这种方式是如何工作的最好方式就是通过例子来说明。在这个例子中，设想开发者在一个特定的公司中，该公司希望开发一种松耦合的服务，这个服务可以为顾客和授权的请求者提供相应的信息。在另外一个实例中，这个公司希望能够为请求者提供所有的客户数据，包括隐私信息，前提是他们必须提供一个授权的数字证书。为了更多的增加这个例子的价值，让我们假设我们希望对于这两种应用于这些服务的使用上的服务策略能够得到相同的服务质量。

　　在这个例子当中，一个服务消费者可以选择邦定到两个服务合约的一个:其中的一个不提供安全信息，从而只能得到一般的，公开的用户数据，并且前提是在他们在元素中提供有效信息;另一个中提供了一个授权的数字证书，并把所有的数据封装在一个XML文档中，包括在可选元素中提供的数据。关键是在这里我们只需要一个服务实现。使用第一个合约的开发者将会意识到两个合约具体的实现了非常相似的需求，并且开发者所需要做的就是确认是否有一个有效的数字证书被表示出来，并会返回适当的信息——这两者的结果都回同XML模式一同编译。

　　这个例子值得指出的一点是两个合约看起来非常相似，只是有一个显著的差别。在第一种情况下，策略#1应用于没有包含安全需求的第一个合约，而在另外一个情况下，策略#2应用于要求更严格的安全性的第二个合约。这个例子的另外一个有趣的东西是有第三个策略应用到任何情况下的这两个服务合约中，服务必须在30秒以内发出一个响应。因而，我们有三个策略，两个合约，并且只有一个服务实现。

　　为了让这个例子更加有趣，我们可以增加以一个完全不同的响应来表示的第三个服务合约，该合约只提供在有输入的情况下的域，正如上面图二中所示。当然，没有理由再需要另外的服务实现，从而这个服务实现具有至少三个服务合约。让这个例子起作用的关键之处是，服务消费者对选择适当的合约来邦定到服务上去——并要知道策略需求是什么，从而知道从该响应希望得到的是什么。

　　多余一个的服务可以实现一个单独的合约吗?

　　另外一个在这个合约同服务实现的例子的感想是一个单独的服务合约如何可以抽象多个服务实现。让我们通过增加另外一个能够只对提供数据的服务协议进行响应的服务来扩展上面的例子。在这种情况下，这种实现使用一个本地cache提供结果给服务消费者，这种方式比更通用目的的用户数据服务实现更快。

　　现在，你也许会问的第一个问题是为什么我们要使用两个服务来一个单独的合约?原因也许是实现这些服务也许决定在customerData Service被重载的时候去利用更具选择性的customerName Service，或者反之亦然，当实现服务合约#1时，只使用customerData Service，或者当调用服务合约#3的时候也许使用轮回的策略，忽略实现的机制，很清楚的一点是上面图中的两个服务实现能够对任何的邦定到合适的合约上的服务消费者提供合适的响应。

　　ZapThink的感想

　　为了创建送耦合的系统，并且真正的把接口同实现分离开来，我们需要允许在服务协议、实现和应用于任意数目的服务的合约之间有多对多的关系。这种模式同原来面向对象领域的的一个对象一个API的接口模式非常不同。在某种意义上，我们扩展了在OOAD中应用于方法的多态的原则，并把它扩展到了面向服务开发中的合约中。不管你怎么看它，策略、合约和服务之间的多对多关系表明的是服务开发者明白的一个重要时刻。

　　即使当开发者明白了面向服务开发的这个基本方面，他们仍然面临市场上没有足够可以获得的工具来创建服务合约和策略。实际上，当很多的具有服务合约开发，策略管理和策略执行的产品的公司在让用户能够创建策略的机制上都有自己的一套，没有一个公司的单独的一个工具可以用来管理他们的所有的服务实现的合约和策略。

　　另外，关于服务合约和策略仍然存在的最大的问题之一是需要一个充分描述服务合约和策略的所有方面的词汇表。从上面的例子可以清楚的看到WSDL本身并不足以充分描述服务的所有的功能需求和非功能性需求。并且对于那些已经认为WS-Policy也许损失了一些简单性，最可把的真相是它只证明了提供一个互操作容器来交换策略信息，但是并不会告诉你具体的策略将会如何运作。很多工作仍然需要去做，并且我们希望ZapFlash的读者，就像您，能够通过同我们共享您的经验、元数据或者其他的你是用来填满服务合约和策略框架的东西来为解决这个问题做出贡献。所以，如果你已经找到了一个很好的解决元数据的问题的方法，或者甚至已经提出了一个很好的Microsoft Word文档或其他的文本模版来定义元数据，请让我们知道，我们都洗耳恭听!

　　这些领域很明显的是SOA的状态艺术。我们希望2006年能够成为为企业界接受的一年。我们的技术成熟了，不仅我们理解什么是SOA，并且知道为什么我们要做它，如何处理服务，合约和策略，以使得我们能够以意识到IT系统的陈诺，那就是以灵活，敏捷和松耦合的方式来响应，从而改变商业的需求。