1. 引言

　　随着SCA (Service Component Architecture)规范的广泛推广， SCA编程模型和IBM 支持SCA的产品系列如WebSphere Process Service(WPS)，IBM WebSphere Enterprise Service Bus(WESB)越来越多的应用于实际的大型IT生产环境和业务集成中。SCA组件对业务数据进行操作，并使用统一的数据格式——SDO(Service Data Object)来表达业务数据，并在SCA组件之间进行传递。

　　但是在许多实际项目运营过程中，搭建单纯的符合SCA规范的IT架构一般难以实现，基于SOA可重用理念，很多情况下需要实现SCA组件和外部非SCA模块之间的集成，而这些模块往往是基于已有的J2EE平台实现的EJB、JMS终端或者能够接受SOAP消息的Web Service。IBM WebSphere Integration Developer(WID)在集成图(Assembly Diagram)上提供了SCA导入组件来引用外部的各种类型的服务组件，以及SCA导出组件来将内部的SCA组件暴露为可以和外部多种模块交互的服务接口，而所有这些交互类型都通过导入、导出组件上的绑定(Binding)类型来指定。截止到2007年初IBM发布的WID V6.0.2，用户可以指定的绑定类型包括：

• 　　SCA 绑定
• 　　Web服务绑定
• 　　无状态Session Bean绑定
• 　　消息绑定，包括JMS 绑定，MQ 绑定，MQ JMS 绑定

　　本文侧重于SCA导入、导出组件中对Web Service Binding的应用。该绑定能够在标准SOAP消息和SDO之间进行格式转换。SDO在进入SCA世界后被包装了相关的SCA协议头而成为在SCA组件之间传递的SMO(Service Message Object)。理论上来讲，SMO应该有完整的元数据格式以映射到SOAP的Schema，其中除了用于传递功能性调用的SOAP Body外，用于携带QoS以及非功能需求的SOAP Header也是重要的组成部分。WID的实现也确实做到了这一点，但是笔者在组内的项目中经历了一番挫折才认识到WPS运行时环境对实现SOAP Header在SOAP和SMO之间传递的特殊配置要求。本文就是想共享这方面的经验，希望无论是从事实际项目开发的软件工程师，还是在实验室中从事相关课题技术探索的研究人员能够从中获益，节省宝贵的研发时间。

　　2. 一个典型场景

　　笔者通过对所从事的项目进行技术抽象，得出以下的典型场景：

图1 一个典型的使用SCA中间模块基于SOAP Header进行服务选取的场景

　　如图1所示，假设一个Web服务请求客户端需要请求两个Web服务：Echo Web服务1和Echo Web 服务2。这两个Web服务虽然都提供了回应请求字符串的功能，但是他们的接口描述不同。该场景希望对服务请求进行中介，并选取了SCA中介模块来实现服务请求的路由、请求消息转换，面向服务请求客户端屏蔽中介细节，提供统一的服务调用界面。并且，服务请求客户端可以通过在Web服务请求的SOAP Header中嵌入路由信息，来标明每次请求所希望调用的远程Web服务。