间接层模式

    在新的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 注册库的使用不是强制性的。