浅谈Web Services版本控制

　　论题

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

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

　　改变的类型

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

　　·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是强制性的，使用这种模式将能够提供一种更为平滑的迁移。

应用这些模式的解决方案

　　可以通过不同的方法来应用这些不同的模式。它可以通过消费者代码完成，也就是考虑客户端代码中的那些模式：这是罕见的情况，也意味着维护客户端代码将变得十分复杂。另一种办法是使用中介，令消费者与提供者解耦，将服务总线用作中介，其中应用那些模式。使用AquaLogic Service Bus作为中介层可以使间接层模式与适配器模式关联，客户端得以解脱。如下图所示：

使用这种基于AquaLogic Service Bus的方法有以下优势：

　　minor release改变可在不影响消费者的情况下完成，并有可能通过基于内容的路由或基于用户的路由定位试点网站。

　　向major release的迁移以一种比较主动的方式得到处理，它通过使用AquaLogic Service Bus来使客户端请求和响应适应服务的新major版本。

　　这种情况下UDDI 注册库的使用不是强制性的。

　　AquaLogic Service Bus通过业务服务的代理服务器提供了一个中介层。用版本的引用组织这些代理服务器的配置和业务服务可能是比较实用的。AquaLogic Service Bus中的代理服务器包括对major release的引用，业务服务包括路径中的minor release，例如，对于major v1.XX：

　　functional_block/module/proxies/v1_XX/

　　functional_block/module/businessservices/v1_00/

　　functional_block/module/businessservices/v1_01/

　　functional_block/module/wslds/v1_XX

　　对于major V2.XX：

　　functional_block/module/proxies/v2_XX

　　functional_block/module/businessservices/v2_00

　　functional_block/module/wslds/v2_XX

　　注意：代理服务器和WDSL对minor releases是相同的，包含它们的路径不包含minor 版本引用。

　　但如何在Weblogic上使用相同的编码环境部署两个不同版本的服务？这些服务可能含有相同的J2EEweb模块上下文路径，因为它们有可能是用同一个Workshop项目开发的。所以，除非您提供一个在J2EE web模块中加入版本引用的构件（使用ant），才可能想在不同的目标上部署同一服务的不同版本；目标是一个集群或一个托管服务器。如下图所示：

　　当消费属于业务服务层、数据访问服务层或编排服务层的服务时，表现服务和编排服务（业务流程服务）将受益于这种方法的透明度。但是表现服务的消费者，使用WSRP的复合门户消费远程portlet。此时也可使用这一方法，但我们要采用一种更简单合适的方法，它基于WebLogic Portal权限：使用基于访问者角色的规则和权限来展示复合门户中某些取决于用户配置文件的部分。在某些情况下，使用权限对表现服务层更加相关，因为表现服务可能依赖于最终用户的配置文件，并且权限规则相对来说绠关注复合门户引擎，而非总线。

　　因此表现服务层版本控制更适合使用消费者绑定模式。在这种情况下，无法依赖UDDI选择服务来应用此种模式，还需要复合门户中WebLogic Portal提供的权限。与消费者绑定模式的这种用法有关的一个重要的方面是，版本的选择通过配置完成，使用门户管理工具进行，这样就不会导致任何代码修改。

　　下图表明一个复合门户怎样在不同版本的相同应用程序中通过WSRP消费portlet。公开portlet的哪一个版本这一选择是在基于权限的复合门户中完成的。

　　这样做使同时运行同一应用程序的两个版本成为可能，新的功能以基于最终用户配置文件的约束为依据，仅展示给试点部分的最终用户。如果门户应用程序的J2EE模块使用相同的上下文路径，那么在这种情况下您可能需要给每个版本的门户应用一个域名（最后包含一个集群）。

上一页  [1] [2] [3] [4] [5] 下一页

　结束语

　　服务版本控制能否通过不同方式完成取决于需求和约束。处理方式可能有所不同，具体取决于服务所属的层和发生的业务约束。本篇博客文章提到这样几种可能：

　　同时处理多版本服务

　　根据请求者的内容将请求路由到恰当的服务端点

　　使请求与响应相配合，以保持向后兼容

　　用一种良好的方式来使服务更新换代

　　部署不同版本的服务

　　此外，还有其他一些事项应纳入考虑，例如XML 模式版本控制，以及管理服务与其所使用的XML 模式之间的依赖性。在组织水平上管理依赖性，并对改变进行合理的全盘推进，所有这一切都要求具备合适的工具。

上一页  [1] [2] [3] [4] [5]