【IT168 技术文章】

    论题

    在企业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）。

    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，它指的是绑定决策发生在消费者端这一现象。稍后能看您将看到，使用这种模式可能会非常有趣。