网上有篇文章，大致这么说的（如下文），最后我采用的wsimport -XadditionalHeaders的方式。
StrikeIron offers two authentication methods for its for-pay web services, a "SOAP Header" authentication method and a "Non-SOAP Header" one (you can see examples of both in the WSDL section of their U.S. Census Information web service). The non-SOAP header validation method works normally with JAX-WS WSDL-to-Java tools (such as Metro's wsimport and CXF's wsdl2java) because the username and password information is provided as SOAP body request elements and hence parameters will be provided for them in the JAX-WS generated SEI's methods.
However, the SOAP header authentication method relies on implicit SOAP headers. These refer to SOAP headers for requests and responses that are defined in the WSDL binding section instead of the portType section. This is frequently done when the nature of the SOAP header information is metadata only indirectly related to the request and response; in such cases it would be desirable to keep this information separate from the business data referenced in the portType operation. However, implicit headers create a slight problem OOTB with JAX-WS tools, because per the JSR-224 specification WSDL-to-Java code generators only take parameters declared within the portType section into account when generating the SEI method signatures. As a result, necessary SOAP header parameters for making the SOAP request would not be available.
To illustrate this, let's choose one of the Census Information service's operations, say GetAllProfiles_ForZip. Its portType operation refers to two wsdl:messages, one each for request and response:
<wsdl:operation name="GetAllProfiles_ForZip">
<documentation xmlns="http://schemas.xmlsoap.org/wsdl/">
Returns all census information by zip</documentation>
<wsdl:input message="si:GetAllProfiles_ForZipSoapIn" />
<wsdl:output message="si:GetAllProfiles_ForZipSoapOut" />
</wsdl:operation>
<wsdl:message name="GetAllProfiles_ForZipSoapIn">
<wsdl:part name="parameters" element="si:GetAllProfiles_ForZip" />
</wsdl:message>
<wsdl:message name="GetAllProfiles_ForZipSoapOut">
<wsdl:part name="parameters" element="si:GetAllProfiles_ForZipResponse" />
</wsdl:message>
The elements in the request and response messages contain just the business data elements directly related to the operation. It is only within the binding section where the metadata SOAP header elements are defined:
<wsdl:operation name="GetAllProfiles_ForZip">
<soap:operation soapAction="http://www.strikeiron.com/GetAllProfiles_ForZip"
style="document"/>
<wsdl:input>
<soap:body use="literal"/>
...validation checks omitted...
<soap:header message="si:LicenseInfoMessage" part="LicenseInfo"
use="literal"/>
</wsdl:input>
<wsdl:output>
<soap:body use="literal" />
<soap:header message="si:GetAllProfiles_ForZipResponseInfo"
part="ResponseInfo" use="literal"/>
<soap:header message="si:SubscriptionInfoMessage" part="SubscriptionInfo" use="literal"/>
</wsdl:output>
</wsdl:operation>
Since these binding-defined SOAP header declarations are bypassed during wsimport/wsdl2java code generation, the SEI's generated do not supply parameters to allow the SOAP client to provide the authentication information on requests or receive other metadata information on the response:
public com.strikeiron.CensusProfile getAllProfilesForZip(
@WebParam(name = "zip", targetNamespace = "http://www.strikeiron.com")
java.lang.String zip
);
Possible solutions to this issue:
-
Use special wsimport/wsdl2java option settings to bring in implicit headers. Both CXF's wsdl2java and Metro's wsimport tools offer special flags for bringing in implicit SOAP headers when generating the Java artifacts. This is the easiest and probably most reliable solution.
For Metro's wsimport, use -XadditionalHeaders at the command line or xadditionalHeaders="true" for theant task.
For CXF's wsdl2java, use the -exsh true setting shown on the wsdl2java Wiki page.
Using this extension changes the operation signature to the following:
public com.strikeiron.CensusProfile getAllProfilesForZip( @WebParam(name = "zip", targetNamespace = "http://www.strikeiron.com") java.lang.String zip, @WebParam(name = "LicenseInfo", targetNamespace = "http://ws.strikeiron.com", header = true) com.strikeiron.ws.LicenseInfo licenseInfo, @WebParam(mode = WebParam.Mode.OUT, name = "ResponseInfo", targetNamespace = "http://www.strikeiron.com", header = true) javax.xml.ws.Holder responseInfo, @WebParam(mode = WebParam.Mode.OUT, name = "SubscriptionInfo", targetNamespace = "http://ws.strikeiron.com", header = true) javax.xml.ws.Holder subscriptionInfo ); -
Modify the WSDL prior to calling the WSDL-to-Java tool, or subsequently alter the generated classes to make the SOAP Headers explicit. This forum topic has an example of the former and blog entry of the latter. This seems tricky and cumbersome to do, however, and unless the flag options above are not working properly for a certain WSDL I wouldn't see any benefit of this over the first option.
-
Create a JAX-WS Handler and use SAAJ to add the SOAP Headers. SAAJ is a DOM-like API used for creation and manipulation of SOAP messages. As shown in Ivasena's blog entry, a class implementing the SOAPHandler interface can be used to modify the outgoing SOAP request by adding the SOAP header information. This can be a nicely viable option if you do not wish to encumber each SEI method call with authentication information, and by placing this logic in a handler it can be shared across multiple web service calls that need the same headers added. See JAX-WS handler tutorial for more information, and also the RPC/encoded article for examples of working with SAAJ. CXF provides interceptors as an additional option for adding SOAP headers.
-
(Metro only) Use the WSBindingProvider class to add the SOAP headers. As shown in the JAX-WS user's guide, Metro provides a WSBindingProvider that is implemented by proxy or dispatch objects. Methods on this interface allow for convenient adding of SOAP headers.
