连续适配

    下面有个问题，与一般的独立应用不同， SOA环境中每个Web Service更多的是通过Registry的登记，属于即插即用类型的，而且为了整合业务流程常常存在同时多次适配的情况，这种情况下怎么处置呢？可以通过增加一个ServiceAdapterChain来解决。

图2：通过增加ServiceAdapterChain进行连续适配

实现结构

    先从调用模式上分析，对于单向的“生产者+消费者”方式，那么仅需要在消费者服务一方增加对生产者服务的适配器；如果是另一种情况，则需要两个适配器。

图3：单向的“生产者+消费者”

图4：双向的“生产者+消费者”

    不过上面仅分析了不同调用模式下大概的实现方式，对于怎么解决具体某个Adapter还需要分上面提的三种情况分别对待：

1、 数据Schema适配 

    Schema的适配可以采用用代码实现，如果转换过程不是特别复杂，不需要使用外部非XML机制的话，也可以采用更简洁的XSLT方式。

//处理方式
XSD（source）-> XSLT（source->target）-> XSD（target）

    考虑到这种数据Schema的适配过程可能不止一个，不同的服务方法间适配可能也会遇到相同数据Schema对之间的适配过程，因此实现上增加一个XSLT的注册机制，统一管理这个登记、翻译和转换工作。

2、 服务方法兼容性适配 

    参数列表、返回值、参数类型都会导致生产者服务与消费者服务间的不兼容的。

3、 封装性适配

    对于2、3两种情况而言，与设计模式中的Adapter没有太大差别，不过多了一个选择，“是否考虑把Adapter作为一个独立的Web Service提供出来？”如果这么做，那么最大的区别在于消息机制的变化，从二进制（或文本数据）调用变成了SOAP调用。但这样做有一些很明显的不利因素，因此不建议把Service Adapter作为独立的Web Service提供。 

    •效率问题。 

    •最后，消费者服务仍然需要通过某种开发语言调用这个Adapter Service，这和写个Service Adapter类解决问题的方式一样的麻烦。