WSDL Message Element and Its WSDL 2.0 Refactoring

In Web Services Description Language (WSDL), the message element was a foundational component of WSDL 1.1 used to define the format and structure of transmitted data payloads. However, with the release of WSDL 2.0, the specification underwent a major structural overhaul that completely eliminated the standalone message element in favor of direct references to XML Schema definitions. This article explains the role of the legacy message element in WSDL 1.1, the reasons behind its removal, and how payload definitions are handled in WSDL 2.0.

The Message Element in WSDL 1.1

In WSDL 1.1, a web service operation did not directly reference XML Schema (XSD) elements. Instead, it relied on the <wsdl:message> element as an intermediary abstraction layer.

A WSDL 1.1 message element contained one or more <wsdl:part> sub-elements. Each part represented a parameter or a component of the message payload and was defined using either an XSD type or an XSD element attribute.

For example, a typical WSDL 1.1 definition included:

<wsdl:message name="GetUserRequest">
    <wsdl:part name="parameters" element="tns:GetUserRequestElement"/>
</wsdl:message>

<wsdl:portType name="UserService">
    <wsdl:operation name="GetUser">
        <wsdl:input message="tns:GetUserRequest"/>
    </wsdl:operation>
</wsdl:portType>

In this model, the operation referenced the message, and the message referenced the actual data definition.

Why the Message Element Was Refactored

While functional, the WSDL 1.1 message construct introduced several architectural drawbacks:

  1. Unnecessary Indirection: The message element added an extra layer of abstraction between the operation signature and the XML Schema model without providing significant functional value.
  2. Ambiguity Between RPC and Document Styles: The ability to use either type or element within message parts created confusion, especially when mapping WSDL definitions to object-oriented programming languages and handling RPC/literal versus Document/literal SOAP bindings.
  3. Multi-Part Complexity: Allowing multiple <wsdl:part> elements within a single message often led to interoperability issues when serializing XML over standard SOAP protocols.

How Payloads Are Handled in WSDL 2.0

To streamline the specification and eliminate unnecessary complexity, WSDL 2.0 completely removed the <wsdl:message> element.

In WSDL 2.0: - The <wsdl:portType> was renamed to <wsdl:interface>. - The child elements of an operation (<wsdl:input>, <wsdl:output>, and <wsdl:infault>) now point directly to XML Schema element definitions using the element attribute.

The equivalent definition in WSDL 2.0 is written as:

<wsdl:interface name="UserService">
    <wsdl:operation name="GetUser" pattern="http://www.w3.org/ns/wsdl/in-out">
        <wsdl:input element="tns:GetUserRequestElement"/>
        <wsdl:output element="tns:GetUserResponseElement"/>
    </wsdl:operation>
</wsdl:interface>

By binding operations directly to global XML Schema elements, WSDL 2.0 established a cleaner, more intuitive mapping model, reduced document size, and standardized message definitions entirely around native XML Schema rules.