Web Services Quiz: Issue 9 - the Answer

  • [アーティクル]

Both, Christian and Davanum were absolutely right with their answers: Issue 9’s Operation Add (part of the CalculatorPort) defines first its output and then the corresponding input message.

  <portType name="CalculatorPort">

    <operation name="Add">

      <output name="AddResponse" message="tns:AddResponseMsg" />

      <input name="AddRequest" message="tns:AddRequestMsg" />

    </operation>

  </portType>

You may ask yourself why .NET’s wsdl.exe has trouble to generate proxies/stubs based on such porttypes. Well, the answer can be found in the WSDL 1.1 specification: As in many other specifications, some aspects are completely over engineered where some others are just missing. The section about port types is a good example. Here’s an excerpt of it:

WSDL has four transmission primitives that an endpoint can support:

· One-way . The endpoint receives a message.

· Request-response . The endpoint receives a message, and sends a correlated message.

· Solicit-response . The endpoint sends a message, and receives a correlated message.

· Notification . The endpoint sends a message.

WSDL refers to these primitives as operations. Although request/response or solicit/response can be modeled abstractly using two one-way messages, it is useful to model these as primitive operation types because:

· They are very common.

· The sequence can be correlated without having to introduce more complex flow information.

· Some endpoints can only receive messages if they are the result of a synchronous request response.

· A simple flow can algorithmically be derived from these primitives at the point when flow definition is desired.

Although request/response or solicit/response are logically correlated in the WSDL document, a given binding describes the concrete correlation information. For example, the request and response messages may be exchanged as part of one or two actual network communications.

Although the base WSDL structure supports bindings for these four transmission primitives, WSDL only defines bindings for the One-way and Request-response primitives. It is expected that specifications that define the protocols for Solicit-response or Notification would also include WSDL binding extensions that allow use of these primitives.

This never happened: There are no binding extensions to use Solicit-response or Notification. They’re not implemented in most of the available toolkits, and .NET is no exception: There is no support for these two transmission primitives. Given our initial Issue, we still don’t know why the order of the message definition within an operation matters. The answer can be found on section 2.4.3 of the WSDL 1.1 specification:

The grammar for a solicit-response operation is:

<wsdl:definitions .... >

    <wsdl:portType .... > *

        <wsdl:operation name="nmtoken" parameterOrder="nmtokens">

      <wsdl:output name="nmtoken"? message="qname"/>

           <wsdl:input name="nmtoken"? message="qname"/>

           <wsdl:fault name="nmtoken" message="qname"/>*

        </wsdl:operation>

    </wsdl:portType >

</wsdl:definitions>

First input then output à Request-response

First output then input à Solicit-response

Let’s thank WS-I Basic Profile; it explicitly disallows Solicit-Response and Notification messages:

R2303 A DESCRIPTION MUST NOT use Solicit-Response and Notification type operations in a wsdl:portType definition.

Ende gut alles gut…