最近《Pattern-Oriented Software Architecture》出版了4、5卷，联想到现在正快速发展的Web服务建设，他们同样也进入到系统化设计、实施的阶段，也到了该应用模式化设计的阶段。设计模式不仅是方法论，很多时候也是实现技巧、代码重构设计思路、解决方案等。Web 服务与GOF23提到的面向对象设计模式本身有很大差距，因为它提供的是基于WSDL的一个个API，也就是说它是“平”的，没有所谓的继承关系。
       现阶段Web 服务更多的被架构师设计为应用的“一张皮”，即便这样经过近几年数量众多的Web 服务建设，它还是形成了很多固定的模式（为了区别于经典的模式名称，这里每个模式名称前都增加了一个“Service”）：
l         Service Facade：Web 服务是平台、开发语言无关的，那么为了实现无关那就需要把原有的资源包装好，这个意义上讲，Web 服务天生就有很朴素的Facade特性；
l         Service Adapter：Web 服务间的调用越来越普遍，尤其在互操作或者与合作伙伴Web 服务交互的过程中，如何使不同Service Endpoint互联本质上也是WSDL与WSDL接口间的交互，概念上适配器就是很不错的选择；
l         Service DTO（Data Transfer Object）：Web服务的调用是相对很昂贵的，但客户程序很少有机会决定服务端的接口颗粒度，如果对方颗粒度很小，但自己需要的数据本身就很粗，那么如何将多次调用打包成一个，DTO就是不错的选择；
l         Service Observer：既然架构上Web服务被定义为SOA环境的普遍技术，那么设计上也更需要面向客户，无论是最终客户应用、人还是客户Web服务，很多情况下都需要异步根据既定内容提供消息，Observer这时候就很有用武之地，进一步还可以扩展为Service Subscriber / Publisher；
l         Service Visitor：虽然现在绝大多数企业内Web 服务还远没有达到形成双因素依赖的程度，但很多协作方Web服务间已经形成了很多基于“服务——请求”链条的双因素依赖关系，当两个服务之间“拆解”有问题的时候，恐怕就是“外来和尚好念经”了，Visitor是个不错的思路；
l         ... ...
       
       概念上应用这些模式很清晰，但实现上要求架构师有几个“坎”必须跨越：
l         首先，实现上述模式的基础是解决Web服务依赖倒置的问题，虽然WSDL很好的描述了Web服务接口部分的抽象，但服务实体本身必须增加一个抽象逻辑层适配WSDL的描述，否则WSDL与Web服务实体间还是1：1的紧密耦合，想通过模式玩点“花样”很难；
l         其次是参数、消息内容上必须（起码是强烈建议）采用XML家族的技术，XSD、XSLT、XML数据访问技术（Xpath / XQuery）等；
l         然后，标准化是时时要考虑的问题，设计模式没有提到版本问题，但Web服务发展的太快，为了更好的把他们服务化，供其它客户程序使用，不仅要设计上有好的规划，实现上也要处处留意标准化，因为很多时候要靠相关标准的兼容性保证自己Web服务的兼容性。

From:
http://www.infoq.com/cn/news/2007/09/WSNeedDesignPattern