一、SOA现状

    SOA渐渐进入到开发的应用实践，其本质是保持业务敏捷，也就是“全心全意”的根据业务需要找到或集成相关的服务，然后快速适应业务变化。虽然通过很多管理的、技术协议的约束可以进行有效治理，但如果技术实现上缺乏灵活性，那么当技术环境变化的时候修改的代价一样会很大，为什么？

    以往单应用的开发模式模式下，与之相关的技术实体有限，通过采用软件工厂、合理运用设计模式、集成成熟框架的手段可以一定程度上降低应用内部模块间的耦合度。到了SOA时代，虽然服务接口被简化，应用间的耦合度降低了，但同时也等于把自己的应用推到一个更广泛的空间，怎样灵活的适配同样被置于互联网的各种服务也许成了更大的挑战。

    作为架构人员该考虑什么问题呢？把所有的变化“透明化”，无论是服务接口还是依赖的其它SOA组成变化时，要尽量确保应用感觉不到这些变化（或把变化集中在一个很小的范围）。

    XML Web Service作为SOA建设采用的一项普适技术，设计不当很可能成为阻碍业务敏捷的绊脚石，成为应用的累赘。本系列借鉴设计模式、架构模式和部分产品对Web Service的使用情况，结合相关项目的实施经验，介绍一些Web Service 设计与整合模式（Web Service Design &Integration Patterns），目的是找到特定上下文环境下设计和集成Web Service的“相对优”解。与其它模式方法介绍方法不同，Web Service更多的需要被放在整个SOA环境下考虑，而不仅仅是几个类的关系。

    下面是一个简化后的逻辑SOA环境：

图1：简化后的逻辑SOA环境

    不难看出，在ESB之外，Web Service仅仅作为一个个Provider，以插件方式安置到ESB中，客户程序也更多的通过ESB找到每个Provider。但它仅仅是一个较为理想的状态，现实情况下很多时候根本没有中间的ESB，客户程序就是直接按需使用Web Service。因此，这个点对点的调用成了这样：

图2：点对点的调用

    这里的中介者可能仅仅就是个网络，也可能包括一个在.Net或Java平台编译好的WSDL代理，也可能是更复杂的机制，它的设计和集成就成了很关键的因素，那么希望它起到什么作用呢？

    笔者认为主要有三个：

    •给客户程序一个透明的接口，借助它灵活的适应后端Web Service的变化。

    •降低客户程序与Web Service直接调用带来的1：1甚至1：N直接耦合。

    •提供高可用机制。

    （注：本系列很多内容引用到Apress出版的《Web Service Patterns: Java Edition》（下文简称WSP），但介绍的模式不仅限于该书提及的14种，而且实现上会采用Visual Studio.Net 2005，客户程序会以Test Project的Unit Test形式出现。）