Web Services版本控制

　　在企业SOA进程中，需要认真考虑服务版本控制。让我们以在具有共享服务的组织中发布一个新版本的服务为例，在这种情况下，可能要求一种Web服务的多个版本同时可用。部分消费者可能会延用旧版本的服务，直至所有消费者代码都为新功能和/或新界面而迁移。

　　在本篇文章中，我会试着提出一些对组织内广泛应用的服务进行版本控制需要处理的方面。首先我会尝试定义可能发生的改变的类型，然后介绍几种可以考虑的不同模式，最后将这些模式映射到实际解决方案。应用这些模式时，我还会考虑到这些服务所属的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)。