How WSDL Maps Abstract Messages to Concrete Protocols

Web Services Description Language (WSDL) bridges high-level service design with network implementation by decoupling what a service does from how it transmits data. This article explores how WSDL translates abstract components—data types, messages, and operations—into concrete XML network payloads and communication protocols such as SOAP over HTTP.

The Two-Layer Architecture of WSDL

WSDL organizes service definitions into two distinct layers:

1. Abstract Layer: Defines the data types, individual messages, and interface operations independently of any machine environment or network transport.
2. Concrete Layer: Specifies the exact protocol formats, serialization rules, and physical network addresses required to invoke the operations defined in the abstract layer.

The mapping process occurs when elements in the concrete layer reference and bind to elements in the abstract layer.

1. Defining the Abstract Data and Operations

Before mapping occurs, WSDL establishes the contract using three core abstract elements:

• <types>: Defines data structures using XML Schema (XSD).
• <message>: Represents a typed communication payload. Each message consists of one or more <part> elements that reference definitions in the <types> section.
• <portType> (or <interface> in WSDL 2.0): Combines messages into single interactions called operations (such as Request-Response, One-Way, Solicit-Response, or Notification). Each operation defines an <input>, <output>, and optional <fault> message.

At this stage, the operation describes what data is expected and returned, but contains no details regarding transport (HTTP, SMTP, JMS) or serialization style.

2. Binding Operations to Concrete Protocols

The <binding> element creates the direct mapping from the abstract portType to a concrete format.

Protocol Specification

The binding specifies the underlying protocol using protocol-specific extension elements, most commonly SOAP. The <soap:binding> element defines: * Transport: Indicates the underlying transport mechanism, typically transport="http://schemas.xmlsoap.org/soap/http". * Style: Specifies whether the message format is document (XML payload validated against schema) or rpc (operation name used as an XML wrapper containing parameters).

Operation Mapping

Within the <binding>, each abstract operation from the portType is declared with matching names: * <soap:operation>: Defines the soapAction header (for SOAP 1.1) used by network routers and servers to route requests without parsing the entire XML body. * Style Overrides: Allows specific operations to override the global binding style (document vs. RPC).

Payload Serialization (<input> and <output>)

The input and output sub-elements within a binding operation determine how abstract messages turn into XML payloads: * <soap:body>: Specifies how the message parts are serialized inside the <SOAP-ENV:Body> envelope. * Use Attribute (use="literal" vs use="encoded"): * literal: The message parts directly map to the concrete XML Schema definitions without modification. * encoded: The message parts are encoded according to specific serialization rules (e.g., SOAP Section 5 encoding rules). * <soap:header>: Maps designated parts of an abstract message directly into the <SOAP-ENV:Header> rather than the body for metadata like authentication tokens or transaction IDs.

3. Assigning Concrete Network Endpoints

Once operations and messages are mapped to a wire format, the <service> and <port> (or <endpoint> in WSDL 2.0) elements provide the physical location.

• The <port> element associates a <binding> with a concrete URI via <soap:address location="https://example.com/service"/>.

Summary of the Mapping Flow

1. An application calls an operation defined in a portType.
2. The runtime engine identifies the message definitions for the operation’s input.
3. The engine consults the binding to format the input data into an XML document (applying style, use, and header rules).
4. The serialized XML payload is wrapped in the specified transport envelope (such as a SOAP Envelope over an HTTP POST request).
5. The request is transmitted to the physical URI declared in the service’s port.
6. The reverse process occurs for the response via the output message mapping.