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

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

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

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

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

    结束语 

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

    同时处理多版本服务
    根据请求者的内容将请求路由到恰当的服务端点
    使请求与响应相配合，以保持向后兼容
    用一种良好的方式来使服务更新换代
    部署不同版本的服务

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