From the preceding section, you’d think that SOAP and HTTP are similar enough that the outbreak of WS-Peace would be imminent. After all, both define envelopes, both have an end-to-end processing model that includes intermediaries, and both rely on metadata. If there is complexity in the Web Services stack, it doesn’t come from SOAP.
But we don’t have to go far into the Web Services stack to find the source of most complexity: the Web Services Description Language, or WSDL. While WSDL pays lip service to SOAP’s message-oriented processing model, in fact it is mostly used as nothing more than a verbose object interface definition language (IDL), which forces an unsuitable RPC-like model of parameters, return values, and exceptions onto Web Services.
Center stage in WSDL 1.1 is the
portType (the equivalent in WSDL 2.0 is the
more honestly named
is where all of the operations (!) that a Web Service supports are
declared. Even to the casual observer, it’s clear how the WSDL in Example 11-4 maps directly onto the equivalent Java
code in Example 11-5, or
indeed how easy it would be to go from Java to the corresponding
WSDL—both encouraging unhelpful tight coupling between the service’s
contract and its implementation.
Example 11-4. Typical WSDL use
<wsdl:portType name="ordering"> <wsdl:operation name="placeOrder"> <wsdl:input message="restbucks:Order"/> <wsdl:output message="restbucks:OrderConfirmation"/> <wsdl:fault name="fault" message="restbucks:OrderException"/> ...