Java Reference
In-Depth Information
</operation>
</portType>
<binding name="CatalogPortBinding" type="tns:CatalogService">
<soap:binding transport="http://schemas.xmlsoap.org/soap/http"
style="document"></soap:binding>
<operation name="secureGetTitle">
<soap:operation soapAction=""></soap:operation>
<input>
<soap:body use="literal" parts="parameters"></soap:body>
<soap:header message="tns:secureGetTitle" part="usernameToken"
use="literal">
</soap:header>
</input>
<output>
<soap:body use="literal"></soap:body>
</output>
</operation>
</binding>
Because the part element, which is part of the abstract contract, specifies the header informa-
tion, clients should be able to address the headers easily.
However, not all WSDLs will specify headers like this one does—it depends on whether it
is written by hand, is working but non-compliant, uses a different tool, or what have you.
The JAX-WS specification indicates that tools are not required to consider the binding sec-
tion when generating SEIs—they need only inspect the
portType
, as it is part of the abstract
WSDL.
NOTE
There is a bit of a gray area with respect to proper header usage. Many public services, such as some
posted by the United States Post Office, use what are sometimes called “implicit headers.” These
headers are not defined as part of the
wsdl:portType
as you have done here. At first glance, not
including information necessary to the contract within the operation may seem like bad practice. The
argument is that if the header information is really metadata regarding the request, it should not be
part of the signature proper, as it isn't part of the business operation. The net effect for you is that,
whichever route you choose, you need to consider how clients will interact with your code, and com-
municate to them what they are required to pass when invoking service operations.
