这种方法可能会把改变强加在消费者身上，至少需要搜索注册库来并访问一个版本(minor或major)的服务，对minor release也是这样。如果您需要两个minor version同时运行会怎么样呢?例如，您可能希望在试点网站上部署minor release，供部分消费者使用，同时使大部分已有消费者依然可以使用旧版本。即使WSDL没有修改(因为是minor版本)，试点网站上部署的服务的消费者还是需要改变服务的端点。在这种特定情况下，消费者和提供者之间设一个间接层是比较实际的，这可以以一种良好的方式推进不同消费者的迁移。

　　注意：消费者绑定模式并不一定表示应用UDDI，它指的是绑定决策发生在消费者端这一现象。稍后能看您将看到，使用这种模式可能会非常有趣。

　　间接层模式

　　在新的minor 版本发布后，消费者会透明地向服务的新minor release迁移：这由间接层通过路由机制提供，它确保基于内容的路由或基于用户的路由(例如基于请求者的IP，或者在传播安全角色时，基于请求者的主要角色)调用web服务的不同版本。

　　使用间接层时，两个minor release可在不改变消费者代码的情况下共存，并且能确保新的发布版得到很好的迁移。

　　但是major release就要求消费者改变他们的代码。如果出于某些组织上的原因，我们需要在不改变所有当前消费者的代码的情况下来迁移到新的major release，并使用旧客户端来调用新服务，那么该怎么办?这种情况完全可能发生，例如：某些法规要求意味着，仅通过使用服务的新major release才可使用一种更改，即使用户仍使用旧的客户端界面。这使我们能够作出一些调整，使当前消费者能够利用新的major release，直至所有消费者代码修改完毕。