skip to content

What did WSDL 2.0 change from WSDL 1.1 in how a service's operations, messages and endpoints are described?

level: middleimportance: nice to knowfreq 7%

answer

  1. renamed: description, interface, endpoint
  2. no message element any more
  3. exchange patterns named by URI
  4. one interface per service

basics

~20 s

WSDL 2.0 renamed portType to interface and port to endpoint, dropped the message element so operations reference XSD elements directly, named each operation's message exchange pattern by URI, and added interface inheritance; most contracts in use stayed on WSDL 1.1.

solid answer

~40 s

WSDL 2.0, a 2007 W3C Recommendation, keeps the abstract-versus-concrete split but reshapes it. The root is `description`; `portType` became `interface` and `port` became `endpoint`, which carries an `address` attribute. The `message` element is gone: an operation's `input` and `output` name an XSD element directly through `element`, or a token such as `#any` or `#none`. Faults are declared once on the interface and referenced by `infault` and `outfault`. Instead of inferring the operation shape from element order, an operation names a message exchange pattern by URI — `in-out` by default, `in-only` with no faults, `robust-in-only` where the single input may trigger a fault. Interfaces can `extends` other interfaces, a service implements exactly one interface, and `targetNamespace` is required. Toolkit support for 2.0 stayed thin, so WSDL 1.1 is still what partners usually hand over.

go deeper

for a junior

Recognise a WSDL 2.0 document by description, interface and endpoint, and know that 1.1 is still the version usually met.

for a middle

Explain the dropped message element, the element tokens, and the three MEP URIs with the fault rule each one uses.

for a senior

When a counterpart sends a WSDL 2.0 contract, map its interface, patterns and single-interface services onto the 1.1 concepts your tooling expects, and spot what does not translate.

for a principal

Weigh publishing a contract in the better-specified 2.0 against the wider tooling reach of 1.1 plus the Basic Profile for the consumers you actually have.

## Two texts with different standing - **WSDL 1.1** (March 2001) is a **W3C Note**: a member submission published for discussion, never endorsed as a standard. Interoperable use of it is defined largely by the **WS-I Basic Profile**. - **WSDL 2.0** (June 2007) is a **W3C Recommendation** in three parts: Part 0 a non-normative Primer, Part 1 the Core Language, Part 2 the Adjuncts (message exchange patterns and the SOAP and HTTP bindings). Its namespace is `http://www.w3.org/ns/wsdl`. Despite its higher standing, WSDL 2.0 saw limited adoption by toolkits — an observation about the ecosystem, not about either specification — so a contract handed over by a partner today is usually WSDL 1.1. Knowing 2.0 still matters when you meet one, and because its changes show what 1.1 left unclear. ## Side by side | Concept | WSDL 1.1 | WSDL 2.0 | |---|---|---| | Root element | `definitions` | `description` | | Abstract operations | `portType` | `interface`, which may `extends` other interfaces | | Message content | `message` with typed `part`s | no message element; `input` and `output` carry `element` | | Operation shape | inferred from the order of `input` and `output` | `pattern` attribute holding a message exchange pattern URI | | Faults | named per operation, each pointing at a message | declared on the interface, referenced by `infault` and `outfault` | | Endpoint | `port` plus a binding extension such as `soap:address` | `endpoint` with an `address` attribute | | Service | may group ports of several portTypes | implements exactly one interface | | Binding | always references one portType | `interface` attribute optional, so a binding can be reused | | `targetNamespace` | optional | required | | Modularity | `import` | `import` for foreign namespaces, `include` for the same namespace | ## No more message element In WSDL 1.1, the path from an operation to its data runs through a `message` and its parts. WSDL 2.0 removes that indirection: the `element` attribute on `input`, `output` or an interface `fault` names an XSD element declaration directly, or holds one of the tokens `#any` (any single element), `#none` (no content) or `#other` (content declared in a non-XML type system through an extension). One operation message is one element, which removes the multi-part ambiguity that 1.1 bindings had to resolve. ## Message exchange patterns An operation names its **message exchange pattern** (MEP) by URI. Part 2 of the Recommendation defines three and points to a separate non-normative note for further patterns: 1. **In-Only** — `http://www.w3.org/ns/wsdl/in-only`: exactly one message received from some node, under the *No Faults* rule, so faults MUST NOT be propagated. 2. **Robust In-Only** — `http://www.w3.org/ns/wsdl/robust-in-only`: exactly one message received, under the *Message Triggers Fault* rule, so the message may trigger a fault that is delivered back to its originator. 3. **In-Out** — `http://www.w3.org/ns/wsdl/in-out`: a message received from a node and a response sent to that node, under the *Fault Replaces Message* rule, so the response may be replaced by a fault. When an operation omits `pattern`, its exchange pattern is **in-out**. Each rule is itself identified by a URI, so a new pattern can be defined from the same building blocks. ## Interface inheritance and services - An `interface` may list other interfaces in `extends` and then contains their operations as well as its own. Inheritance loops are prohibited: the interfaces an interface extends must not themselves extend it, directly or indirectly. - The Primer uses this for compatible versioning: a client that understands only the base interface keeps working against the extended one. It cannot express a mandatory new operation, though, because the old interface's clients would still be accepted. - A `service` names exactly one `interface`, and its endpoints are alternative places where that one interface is offered. In WSDL 1.1, by contrast, one service may group ports whose portTypes differ. ## Reading a contract in practice - Seeing `description`, `interface` or `endpoint` tells you it is 2.0; `definitions`, `portType` and `port` mean 1.1. - A 2.0 binding of type `http://www.w3.org/ns/wsdl/soap` uses `wsoap:version` to say whether it targets SOAP 1.1 or SOAP 1.2. - When translating between the two mentally: one 1.1 message with a single element part maps to one 2.0 `element` reference; 1.1 one-way and request-response operations correspond roughly to in-only and in-out.

  • What can a WSDL 1.1 service express that a WSDL 2.0 service cannot?
    Grouping endpoints of different abstract interfaces. In WSDL 1.1 one service may contain ports whose bindings reference different portTypes. A WSDL 2.0 service names exactly one interface, and its endpoints are alternative places offering that interface; offering a second interface means describing a second service, or one interface that extends both.
  • How does WSDL 2.0 interface inheritance help versioning, and where does it stop helping?
    An interface that extends another contains all of its operations, so a client written against the base interface keeps working when the provider adds operations in an extending one — a compatible change. It cannot force clients onto a new mandatory operation, because the old operations stay available; the Primer says incompatibility must be signalled by something in the message instead.

saying these in an interview costs you the question

  • WSDL 2.0 keeps the message element and merely renames it.
  • WSDL 2.0 is a W3C Note, just like WSDL 1.1.
  • In-only and robust-in-only differ in whether a response message is returned.
  • A WSDL 2.0 service can expose several unrelated interfaces at once.
  • WSDL 2.0 still infers an operation's shape from the order of its input and output.