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，用户可以指定的绑定类型包括：

　　1)SCA 绑定

　　2)Web服务绑定

　　3)无状态Session Bean绑定

　　4)消息绑定，包括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服务。

　　该场景虽然只是一个技术抽象，但是可以被赋予多种IT内涵和业务语义，比较典型的有：

　　基于WS-Policy服务非功能属性的服务匹配和选取。在这种情况下，每个被选取的Web服务都通过WSDL绑定声明了不同的WS-Policy断言。只有客户端SOAP请求中所携带的非功能性需求与当前服务的WS-Policy断言能力相符，该服务才可以被匹配从而进行调用。而一般情况下这种动态服务选取会将备选的Web服务元数据(包括WSDL，XSD以及WS-Policy)发布到一个元数据注册中心(目前IBM推荐的主流产品是WebSphere Registry & Repository)，由请求中介在运行时进行查询匹配(WID V6.0.2已经有中介组件支持对WSRR的查询)。已有的基于WS-Policy框架的服务策略规范(如WS-RM, WS-Security等)都将每次服务调用中的非功能需求嵌在SOAP Header中，在这种情况下，服务中介必须实现基于SOAP Header的服务匹配;

　　WebSphere Business Services Fabric(WBSF)是IBM新近推出的支持业务领域服务及服务策略建模、开发和运行时支持的新款产品。该产品已经在保险业得到广泛应用，并且成为IBM在SOA监管(Governance)方向的核心产品之一。基于该产品开发的业务策略也和每个备选的Web服务关联，并要求服务请求的SOAP Header中嵌入相应的与业务相关的选择条件，从而由WSBF做运行时策略使能，完成服务的选取。WSBF在未来也将架构于WPS/WESB之上，因而也面临本文所提及的问题。

　　本文的目的不是介入以上对相关IBM产品和Web服务规范应用的讨论，因而采用图1的简单的技术抽象来说明如何解决使用SCA Web服务绑定来传递SOAP Header这一问题。以下在第3节中将给出通常情况下使用WID来实现满足图1要求的SCA中介模块的基本做法，并说明问题所在;在第4节中将对第3节的配置进行修改，从而解决问题。

　　3. 初配SCA 中介模块——SOAP Header丢失

　　3.1 安装供选择的Web服务

　　从文章的“下载”一节中下载得到两个Echo Web服务的EAR文件EchoEJB1EAR.ear和EchoEJB2EAR.ear，并依照以下步骤安装并启动两个Echo Web服务：

　　启动WID后，切换到“J2EE” 视图，在Servers子窗口中选择“WebSphere ESB Server V6.0”并启动该服务器;

　　选择“File->Import->EAR file”，并导入以上两个Echo Web服务的EAR文件到当前的工作台中;

　　在Servers子窗口中右键点击“WebSphere ESB Server V6.0”，选择“Add and remove projects…”，并在弹出的窗口中选择添加“EchoEJB1EAR”和“EchoEJB2EAR”到WESB中。

　　至此，两个Echo Web服务已经成功完成了在WESB服务器中的安装和启动。