在本篇文章中，我会试着提出一些对组织内广泛应用的服务进行版本控制需要处理的方面。首先我会尝试定义可能发生的改变的类型，然后介绍几种可以考虑的不同模式，最后将这些模式映射到实际解决方案。应用这些模式时，我还会考虑到这些服务所属的SOA层，以及一些与不同版本的服务的部署相关的实践考虑事项。

　　改变的类型

　　Web Services实现中的改变对此web services消费者的影响取决于以下几个因素：

　　Web服务操作参数的变化，比如添加新的参数(这会影响到当前消费者)或者改变已有参数，例如对XML文件中已有web服务的消息参数进行更改(使用打包的document/literal时，这是我喜爱的binding style)：XML文件中的改变可以包含增加可选的元素或属性(这可能会影响到当前的消费者)，或强制更改元素或属性(这必然会影响到当前的消费者)。

　　改变操作名称(这必然会影响到当前的消费者)。

　　增加操作(这可能会影响到当前的消费者)。

　　删除操作(这必然会影响到当前的消费者)。

　　因此，我们可以确定一种Web服务改变的分类法，根据改变对对当前消费者及其行为的影响来提出分类法。一种常见的办法是将其分为不会影响当前消费者的minor release和会产生影响的major release。

　　Minor Release

　　minor release可分为两种。第一种类型是更正bug或改进web服务的性能，这不会影响web服务的WSDL。第二种类型包括给web服务增加method，它会改变WDSL但不会对已存在的消费者产生影响。标注版本号时，这两种不同类型的发布可以区别出来。例如您可以选择改变小数点后第二位作为第一种类型，改变小数点后第一位作为第二种类型(1.0X或1.Y0)。

Major Release

　　会破坏向后兼容的改变叫做major release。消费者必须改变。在某些情况下，有些发布只影响web服务的功能但不影响WSDL。因为当前消费者只有仔细考虑这些改进的web服务功能才能调用新的web服务，所以这也被认为是一种major release。

　　既然我们已经确定了改变的种类以及它们对当前用户的影响，让我们关注一下不同模式的Web Services版本控制。

　　模式

　　消费者绑定模式

　　当一个新版本的web服务发布后，无论是major还是minor，这些变化会通知到消费者，他们有责任通过改变代码来访问新版本的服务。例如在一个UDDI注册库中，新的WDSL发布了，发给消费者一份通知，这样他们就能发现新服务并和服务提供者建立绑定。使用UDDI注册库是一种惯例，它包含了将给定版本的端口类型关联到特定的tModel，一个WDSL关联到一个tModel ，对major版本来说tModel应该包含版本的引用，因为两个major版本意味着两个不同的WSDL;如果两个minor 版本需要同时被访问，tModel可能需要包含对minor 版本的引用。该端口类型/版本的消费者可以进行UDDI绿页搜索来查找通知兼容性的服务，把它们与相应版本的tModel相关联。

　　这种方法可能会把改变强加在消费者身上，至少需要搜索注册库来并访问一个版本(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，直至所有消费者代码修改完毕。

　　适配器模式

　　适配器模式包括使客户端请求和响应相配合来消费服务的新major release。如果出于商业、法规或者组织方面的原因，服务的新major release是强制性的，使用这种模式将能够提供一种更为平滑的迁移。

(编辑:aniston)