IBM WebSphere DataPower通常被用于将一个SOAP/HTTP后端Web服务转换或调整为不同的Web服务接口。在这些情况中，几乎都使用中间逻辑来转换SOAP消息。但是SOAPAction 报头的转换往往被忽略，这会导致后来在集成测试中出现问题。幸好，WebSphere DataPower非常灵活，您可以很容易用它来转换SOAPAction报头，而本文将介绍4种不同的转换方法。

　　SOAPAction报头的定义属于Web Service Description Language (WSDL) 1.1规范。最初，这个头主要是用来识别请求意图——后台所调用的操作。后来这个定义成为WS-I Basic Profile V1.1的一部分，我们建议不要过分依赖它，但是有一些服务提供商仍然采用这种方式。因此，在SOAP/HTTP Web服务 前增加一个中间层来保证将SOAPAction报头重写为中介逻辑（mediation logic）一部分，是一种更好的方法。

　　WSDL中绑定的每一个操作都会关联一个soapAction属性，而且它的值不必与操作名相同 —— 它可以是任意的URI。当通过 HTTP 发送SOAP请求时，SOAPAction定义的HTTP头的值与所请求操作的soapAction属性值相同，位于双引号中。清单1显示的是一个定义了soapAction属性的WSDL片段：

　　清单1. 绑定了soapAction属性的SOAP/HTTP 
    

以下是引用片段： <wsdl:binding name=”MyServiceBinding” type=”tns:MyServicePortType”>     <soap:binding style=”document” transport=”http://schemas.xmlsoap.org/soap/http”/>         <wsdl:operation name=”operation1″>             <soap:operation soapAction=”OP1″/>                 <wsdl:input>                     <soap:body use=”literal”/>                 </wsdl:input>                 <wsdl:output>                     <soap:body use=”literal”/>                 </wsdl:output>             </wsdl:operation>

　　SOAPAction报头部值请求的SOAPAction HTTP头部值必须是一个引用字符串，与操作的WSDL绑定的soapAction属性值相同。如果WSDL中的soapAction属性为空，那么请求的SOAPAction HTTP报头将是一个空字符串（两个双引号）。当在WebSphere DataPower中创建一个新的Web服务时，其中一个代理设置是 SOAPAction 策略，如图 1 所示的高亮部分，它包含三个选项：

　　Lax：默认选项。它要求SOAPAction报头必须包含与 WSDL中soapAction属性相同的值，但是它也允许空的SOAPAction值。
 
　　Off：SOAPAction报头上不执行任何检查。

　　Strict：SOAPAction报头必须与WSDL的soapAction属性相匹配，否则请求是不允许的。

图1. 代理设置中的SOAPAction策略

　　这个策略会影响WebSphere DataPower提供的服务，但不会影响后端Web服务。服务配置需要将到达的SOAPAction HTTP报头转换为后端Web服务所需要的值。下面的章节将介绍各种不同的转换方法。

　　方法1. 使用一个XSL文件

　　在这个方法中，您会开发一个XSL文件，它使用一个扩展元素set-http-request-header。这个元素有两个属性：

　　Name：您希望设置的头部名称。在这里，我们将它设置为SOAPAction。
 
　　Value：设置的头部值。它应该是后台服务的SOAPAction报头值。

　　下面是一个使用该元素的例子：

　　清单2. 用于重写HTTP SOAPAction报头的XSLT
    

以下是引用片段： <?xml version=”1.0″ encoding=”UTF-8″?> <xsl:stylesheet version=”1.0″                       extension-element-prefixes=”dp”      exclude-result-prefixes=”dp dpconfig”>     <xsl:param name=”dpconfig:SOAPAction” />     <dp:param name=”dpconfig:SOAPAction”>         <display>SOAPAction header value</display>     </dp:param>     <xsl:template match=”/”>         <xsl:copy-of select=”/*”/>         <dp:set-http-request-header name=”‘SOAPAction'”              value=”$dpconfig:SOAPAction”/>     </xsl:template> </xsl:stylesheet>

　　上面这个XSL文件将SOAPAction报头的值作为一个参数，所以当您配置这个转换操作时，打开Advanced选项卡，设置SOAPAction报头的值域，然后单击Save：

图2. 在Transform操作中配置SOAPAction报头的值参数

　　这个操作应该配置到您的处理策略请求规则中。在这个方法中，您可能不需要使用如 清单2所示的完全相同的代码。特别是当您准备使用一个 XSL 文件根据所调用的Web服务操作来设置SOAPAction报头信息时更是如此。

　　方法2. 使用一个报头重写操作

　　在这种方法中，我们要使用一个名为Header Rewrite的高级操作来重写SOAPAction报头。在配置请求处理规则时：

　　拖放Advanced操作图标：

　　从列表中选择Header Rewrite。

　　创建一个新的URL Rewrite Policy。

　　输入策略名称，然后选择URL Rewrite Direction为Request：

图3. 配置头重写策略 1

　　打开 URL Rewrite Rule 选项卡，然后单击 Add。填入如 图 4 所示的值，然后单击 Apply：

 

图4. 添加一个新的 URL 重写规则

　　URL Rewrite Type：URL重写规则的类型。header-rewrite表示一个请求报头将会被重写。

　　Match Expression：采用兼容Perl的正则表达式来匹配报头值。在图4中，.*表示匹配SOAPAction Header的任意值。

　　Input Replace Expression：规则执行之后报头的值。

　　单击Apply保存所有修改。

　　在这种方法中，您可以创建多个URL重写规则，其中每一个都负责将转换一个不同操作的SOAPAction报头。显然，您将需要将规则的匹配表达式修改为如图 4 所示的具体值。

　　方法3. 使用Web服务代理报头注入

　　在这个方法中，您不需要修改处理策略。相反，您只需要在Web服务代理级别上配置SOAPAction报头重写。配置步骤如下：

　　从Control Panel首页打开您的Web服务代理。

　　打开Headers/Params选项卡。

　　在Header Injection Parameters下单击Add。

　　填入如下所示值，然后单击Submit：

图5. 在一个Web服务代理中配置SOAPAction报头注入

　　Direction表示报头应该注入的时间。

　　Back表示当消息从 Web服务发到后台服务时，报头将被注入。

　　单击Apply保存所有修改。

　　方法4. 使用用户代理

　　在这个方法中，您不需要修改如上代理配置，但是您需要配置XML管理器的用户代理对象，它是由Web服务代理引用的。

　　打开User Agent对象。如果您不知道与Web服务代理关联的用户代理，那么可以打开Web服务代理的Proxy Settings选项卡，单击XML Manager旁边的…按钮，然后单击User Agent Configuration旁边的…按钮。

　　打开Soap-Action Policy选项卡。

　　单击Add。

　　在URL Matching Expression域中输入后台服务URL。在SOAP Action域中输入SOAPAction报头的值。

　　单击Apply保存所有修改。

　　这里不推荐修改用户代理或者名为default的XML管理器，因为它们是作为新服务使用的，一些已有服务也可能正在使用它们。相反，在应用上面的步骤之前，我们要先创建一个新的用户代理对象和/或XML管理器对象。

　　结束语

　　本文介绍了几种使用WebSphere DataPower重写SOAPAction报头的方法。文中介绍了SOAPAction报头是与一个Web服务关联的，而不是与一个Web服务接口关联。方法3将SOAPAction报头插入到所有通过Web服务传输到后台的请求中。因此，如果Web服务代理所提供的WSDL包含多个操作，那么这个方法可能并非最佳方法。方法4也存在同样的问题 —— 如果服务后台包含一个以上的操作，那么它可能也不是最佳方法。

　　方法1和方法2是很灵活的，它们不受类似于方法3和4的SOAPAction报头范围的影响。方法2是通过Web配置处理的，它不需要开发任何的XSLT。然而，如果您不熟悉正则表达式，那么方法1可以是最适合您使用的。