skip to content

What does a WSDL 1.1 document describe, and which of its elements say what a service does, how to reach it and where?

level: juniorimportance: must knowfreq 40%

answer

  1. an XML contract, not code
  2. abstract layer first, concrete second
  3. messages made of typed parts
  4. binding: one protocol, no address
  5. port = binding plus one address

basics

~20 s

A WSDL 1.1 document is an XML contract for a web service: types and message define the data, portType lists the abstract operations, binding fixes protocol and format, and service groups ports, each a binding at one address.

solid answer

~40 s

WSDL 1.1, a W3C Note from 2001, describes a service as endpoints that exchange messages, and it splits that description into layers. The **what**: `types` holds XML Schema definitions, each `message` is a set of named `part`s typed by an XSD `element` or `type`, and a `portType` is a named set of `operation`s whose `input`, `output` and `fault` point at messages. The **how**: a `binding` names one portType and fixes exactly one protocol and data format for its operations, for example SOAP 1.1 over HTTP. The **where**: a `port` gives one binding one network address, and a `service` groups related ports. All of it sits under a `definitions` root and is linked by qualified names, so a client generator can walk from an address down to the schema of every message.

code

xml · 25 lines
xml
<definitions name="OrderStatus"
    targetNamespace="http://example.com/orders/wsdl"
    xmlns:tns="http://example.com/orders/wsdl"
    xmlns:ord="http://example.com/orders/schema"
    xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
    xmlns="http://schemas.xmlsoap.org/wsdl/">
  <types><!-- xsd:schema declaring ord:StatusRequest, ord:StatusReply --></types>
  <message name="StatusIn"><part name="body" element="ord:StatusRequest"/></message>
  <message name="StatusOut"><part name="body" element="ord:StatusReply"/></message>
  <portType name="OrderStatusPortType">
    <operation name="GetStatus">
      <input message="tns:StatusIn"/>
      <output message="tns:StatusOut"/>
    </operation>
  </portType>
  <binding name="OrderStatusSoap" type="tns:OrderStatusPortType">
    <soap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/>
    <!-- per-operation soap:operation and soap:body here -->
  </binding>
  <service name="OrderStatusService">
    <port name="OrderStatusPort" binding="tns:OrderStatusSoap">
      <soap:address location="https://api.example.com/orders"/>
    </port>
  </service>
</definitions>

go deeper

for a junior

Recall the six elements and sort them: types, message and portType say what; binding says how; port and service say where. Know that the address lives on the port.

for a middle

Trace the QName chain from a port's address through binding and portType to each message part and its XSD element, and explain why a binding may not carry an address.

for a senior

Read an unfamiliar partner contract quickly: spot which ports are alternatives, which binding namespace signals SOAP 1.1 or 1.2, and which schema each message really depends on.

for a principal

Treat the WSDL as the integration's source of truth: decide who owns it, where it is published and how consumers learn that it changed, rather than letting generated code become the contract.

## What a WSDL document is **WSDL** (Web Services Description Language) is an XML format for describing a network service: which operations it offers, what the messages for those operations look like, which protocol carries them and at which network address the service listens. Version **1.1** was published in March 2001 as a **W3C Note** — a submission made available for discussion, never a W3C Recommendation. It is still the version most SOAP contracts are written in, usually under the constraints of the **WS-I Basic Profile**, which narrows its looser corners for interoperability. A WSDL document is a contract that tools read. A client team receives the document (often from a URL the provider publishes), feeds it to a generator, and gets typed client code — a **stub** — that builds and parses the messages for them. To read one by hand, you need to know what each element is responsible for. ## The six elements, layer by layer The Note itself lists six major elements, all children of the `wsdl:definitions` root (namespace `http://schemas.xmlsoap.org/wsdl/`): | Element | Layer | Answers | Key rule in the Note | |---|---|---|---| | `types` | abstract | what data types exist | XSD is the canonical type system; others may be plugged in by extension | | `message` | abstract | what one message contains | one or more `part`s, each typed by `element` or `type` | | `portType` | abstract | which operations exist | a named set of operations; each refers to input, output and fault messages | | `binding` | concrete | how messages travel | references one portType; MUST specify exactly one protocol; MUST NOT specify an address | | `port` | concrete | where one endpoint is | a binding plus a single address | | `service` | concrete | which endpoints belong together | a named group of related ports | The Note also names the **operation** as a seventh concept: an abstract description of one action, living inside a portType. ## How the elements point at each other Every cross-reference is a **qualified name** (QName) resolved against the document's `targetNamespace`, so a reader or a generator can follow a chain: 1. A `service` contains a `port`, which carries the address in a binding-specific child such as `soap:address location="..."`. 2. The port's `binding` attribute names a `binding`. 3. The binding's `type` attribute names the `portType` it makes concrete, and its children say, per operation, how input and output are encoded. 4. Each `operation` in the portType names its `input` and `output` messages (and any named `fault` messages). 5. Each `message` part names an XSD element or type declared in `types` or in an imported schema. Each kind of definition has its own name scope: a port and a message may share a name without conflict, but two messages may not. ## What the Note requires of each part - A **binding** MUST specify exactly one protocol and MUST NOT carry address information. - A **port** MUST NOT specify more than one address and MUST NOT carry binding information other than the address. - A port using the SOAP binding MUST specify exactly one address, and its URI scheme must match the transport the binding declares. - **Ports in one service** do not talk to each other; when several share a portType through different bindings or addresses, they are alternatives with semantically equivalent behaviour, and the consumer picks one. - **Extensibility elements** — `soap:binding`, `soap:operation`, `soap:body`, `soap:address` and the like — MUST use a namespace different from WSDL's own. This is how one description language serves SOAP, plain HTTP and MIME. ## How the operation shape is chosen A portType operation's shape comes from the order of its children: `input` alone, `input` then `output`, `output` then `input`, or `output` alone. These four operation types, and which of them interoperable contracts may use, belong to the study of SOAP bindings; for reading the document it is enough to know that the portType states the shape abstractly and the binding states how it travels. ## Where WSDL 1.1 stands - The Note defines bindings for **SOAP 1.1**, **HTTP GET/POST** and **MIME** only. Describing a SOAP 1.2 endpoint in WSDL 1.1 uses a separate 2006 W3C Member Submission with its own binding namespace (`http://schemas.xmlsoap.org/wsdl/soap12/`). - **WSDL 2.0** (a 2007 W3C Recommendation) renamed and restructured several of these elements, but contracts met in practice are still mostly WSDL 1.1. - The **WS-I Basic Profile** adds rules on top of the Note — for example on imports and operation names — and conformance to it is what most partners mean by an interoperable WSDL.

  • Can one WSDL 1.1 service offer the same operations over two different protocols?
    Yes. Write two bindings that reference the same portType — for instance one for SOAP 1.1 and one for SOAP 1.2 — and give each its own port in the service. The Note says ports that share a portType but use different bindings or addresses are alternatives with semantically equivalent behaviour, so a consumer picks the one whose protocol or location suits it.
  • What is a message part, and can a WSDL 1.1 message have more than one?
    A part is a named logical unit of a message, typed either by an XSD element (the `element` attribute) or by an XSD type (the `type` attribute). A message may carry several parts — the Note's own example pairs a purchase order with an invoice — but how those parts are laid out in the SOAP Body depends on the binding, so the binding has to be read too.

saying these in an interview costs you the question

  • The binding element holds the URL that clients send their requests to.
  • WSDL defines its own type language instead of using XML Schema.
  • Offering a second protocol needs a second, duplicated portType.
  • A WSDL 1.1 service element can contain only a single port.
  • WSDL 1.1 is a W3C Recommendation, just like SOAP 1.2.