Java Reference
In-Depth Information
type="tns:SecureCatalogPortType">
<soap:binding style="document"
transport="http://schemas.xmlsoap.org/soap/http"/>
<wsdl:operation name="execute">
<soap:operation/>
<wsdl:input>
<soap:body message="tns:aRequest"/>
<soap:header message="tns:usernameHeader"
part="usernameHeader"/>
</wsdl:input>
<wsdl:output>
<soap:body message="tns:aResponse"/>
</wsdl:output>
</wsdl:operation>
</wsdl:binding>
In this WSDL, you have one operation, called
execute
, which accepts a single parameter,
aRequest
, and returns
aResponse
. The binding also specifies that there is a single header,
usernameHeader
, that will be passed along with the SOAP message. This header is not speci-
fied within the
portType
, but is present in the operation definition, which means that it is not
part of the abstract contract for the service. Because of this, when you use
wsimport
to cre-
ate an SEI, nothing will be generated to account for the header. Only
wsdl:part
information,
representing the abstract contract, is mapped to method parameters in the SEI. The method
would map to the following signature:
public String execute(String arg0)
There's no accounting for the header. So you need another mechanism to allow clients to pass
a value for it. That mechanism, if you're using the RI, is to pass
-XadditionalHeaders
to the
wsimport
tool.
WARNING
While it is convenient to generate SEIs with a tool such as
wsimport
, be aware that you are limiting
your portability by using the
-XadditionalHeaders
option.
By using this option, the
wsimport
tool will generate a signature such as this:
public String execute(String arg0, String additionalHeader);
