Providing SOAP-Based Web Services - Java SOA - page 439

string. The second is that the SEI will contain additional methods to make an invocation of
the add operation asynchronously.
There are two other attributes allowed on the bindings element. The first is version , which
by default is 2.0 and refers to the JAX-WS version. The other is node , which allows you to
limit the application of this binding customization to an element within the target WSDL that
you specify in an XPath expression.
Using inline elements
With this approach, you must not specify a WSDL location in the jaxws:bindings element,
as any customization can apply only to the current WSDL, nor are you allowed to use an
XPath expression indicating the node this declaration applies to.
Example 7-9 shows how to use the inline declaration to enableAsyncMapping .
Example7-9.An inline jaxws:bindings element
<wsdl:definitions targetNamespace="..."
xmlns:jaxws="http:java.sun.com/xml/ns/jaxws" >
<wsdl:portType name="CalculatorWS">
<wsdl:operation name="add">
<wsdl:input message="tns:add"></input>
<wsdl:output message="tns:addResponse"></output>
</wsdl:operation>
<jaxws:bindings>
<jaxws:enableAsyncMapping>true</jaxws:enableAsyncMapping>
<jaxws:bindings>
</wsdl:portType>
</wsdl:definitions>
In terms of how your customizations are applied by the runtime, there is no semantic dif-
ference between specifying your bindings externally or inline. There is a difference for your
maintenance program, however. You may find that it is more flexible to put unrelated cus-
tomizations in separate files, and have them all applied to the same WSDL as necessary. This
gives you a separation of concerns but also makes it harder to determine what exactly is being
applied to your WSDL because the binding files refer to the WSDL, and not the other way
around.
Also, you might decide that you do not want to advertise certain capabilities directly in the
WSDL in order to keep it free of platform-specific code.