Why does WSDL 1.1 separate abstract messages and portTypes from concrete bindings and ports, and what does a stub generator read from each?
answer
- reuse across protocols and addresses
- binding MUST NOT carry an address
- how abstract is a message?
- the address is only a default
basics
~20 sWSDL 1.1 keeps operations and messages abstract so one portType can be bound to several protocols and deployed at many addresses; a generator takes signatures and data types from the abstract half, wire format and a default address from the concrete half.
solid answer
~50 sThe WSDL 1.1 Note separates *what* a service does from *how and where* it is reached so the abstract part can be reused: there may be any number of bindings for one portType, and any number of ports for one binding. The seam is enforced — a binding MUST NOT carry an address and a port MUST NOT carry anything but its address. A generator reads the abstract half (`types`, `message`, `portType`) to produce data types and one method per operation, and the concrete half (`binding`, `port`) to know how to put each message on the wire — SOAP version, the `soapAction` value, how parts sit in the Body — and which address to call by default. Because nothing abstract depends on the address, the same stub can be pointed at a test endpoint without regenerating anything; a change to a message or operation, by contrast, means regenerating.
go deeper
Remember the split: types, message and portType are the abstract what; binding, port and service are the concrete how and where.
Explain the Note's MUST rules at the seam — one protocol per binding, no address in a binding, one address per port — and what a generator takes from each half.
Predict which partner changes force a client rebuild and which need only configuration: new ports and bindings versus changed messages, parts or operations.
Use the split deliberately when publishing contracts: keep the abstract layer stable and versioned, and let environments and protocols vary only in the concrete layer.
## The two halves of a WSDL 1.1 document The WSDL 1.1 Note opens with its central design decision: the **abstract** definition of endpoints and messages is kept separate from their **concrete** network deployment and data-format bindings. The point is reuse. **Messages** are abstract descriptions of the data being exchanged, **port types** are abstract collections of operations, a **binding** is the concrete protocol and data format for one port type, and a **port** associates a network address with a binding. | Element | Half | What it fixes | Typically changes when | |---|---|---|---| | `types` | abstract | XSD element and type definitions | the data model changes | | `message` | abstract | which typed `part`s make up one message | an operation's payload changes | | `portType` | abstract | operations and their input, output and fault messages | operations are added, removed or reshaped | | `binding` | concrete | one protocol plus encoding details per operation | a protocol or wire format is added or changed | | `port` / `service` | concrete | one address per port; ports grouped into a service | the service is deployed somewhere new | ## Why the split exists - **One contract, several protocols.** The Note says there may be any number of bindings for a given portType. A provider can offer the same operations over SOAP 1.1 and SOAP 1.2 by writing two bindings, without duplicating a single operation. - **One binding, several places.** Each port is a binding plus an address. Ports in one service that share a portType but differ in binding or address are **alternatives** with semantically equivalent behaviour, and the consumer chooses by protocol or location. - **Deployment without re-contracting.** Moving a service, adding a disaster-recovery site or exposing a test environment touches only ports; the abstract half — the part clients compile against — stays untouched. - **Honest about abstraction.** The Note admits the line is not always sharp: for some bindings the abstract message matches the wire almost exactly, while another binding of the same message may need extensive mapping, so "it is not until the binding is inspected that one can determine how abstract the message really is". ## What the Note forbids at the seam 1. A binding MUST specify exactly one protocol. 2. A binding MUST NOT specify address information. 3. A port MUST NOT specify more than one address. 4. A port MUST NOT specify any binding information other than address information. 5. A port using the SOAP binding MUST specify exactly one address, and its URI scheme must match the transport the binding names. These rules are what make the halves independently replaceable. If a port could tweak protocol details, two ports of one binding would no longer be interchangeable; if a binding held an address, every deployment would need its own binding. ## What a stub generator reads from each half Exactly what a generator emits is each toolkit's choice — names, packaging and language mapping are not specified anywhere in WSDL. What it *can* read is fixed by the document: - **From `types` and `message`**: the data structures to build and parse, one per XSD element or type that a part references. - **From `portType`**: one callable per operation, its parameters and result taken from the input and output messages, and its declared faults from the named `fault` messages. - **From `binding`**: how to serialise each call — the SOAP version (the binding extension's namespace tells SOAP 1.1 from SOAP 1.2), the `soapAction` value from `soap:operation`, and how the parts are placed inside the SOAP Body, which depends on the binding's style and use. - **From `port`**: the address to call when the application gives no other — usually compiled in as a default that the calling code can override at run time. ## Consequences for a client team - A partner adding a **port** or a whole **new binding** for the same portType does not change the code a client compiled against an existing binding. - A partner **moving** an endpoint changes only `soap:address`; clients that take the address from configuration need no new stub. - A partner changing a **message part**, an **XSD element** or an **operation** changes the abstract half, and every generated client built from it must be regenerated and rebuilt. - Reading the abstract half alone does **not** tell you the exact XML on the wire; the binding does. Two clients generated from the same portType but different bindings can send quite different messages. The split is also why a WSDL is usually authored in layers — data types, abstract definitions, then bindings and services — and why the Note's own authoring-style example spreads exactly those three layers across three documents joined by imports.
- If two ports in one WSDL 1.1 service share a portType, what does the Note say about them?They are alternatives. When several ports share a port type but use different bindings or addresses, each provides semantically equivalent behaviour within the limits of its transport and message format, so a consumer may pick one by protocol, distance or another criterion. The Note also says ports in a service never communicate with each other.
- Why does the WSDL 1.1 Note say you cannot tell how abstract a message is until you inspect the binding?Because the binding decides the mapping. For some bindings the message definition already matches the wire representation closely, so the binding adds almost nothing; another binding of the same message may need extensive mapping information — for example placing parts under an operation-named wrapper rather than directly in the Body. The abstract message alone never fixes the bytes.
A WSDL's abstract half is a restaurant's menu: it says which dishes exist and what goes into each. The concrete half is the branch's ordering terms and street address. One menu can be served from several branches, and moving a branch to a new street changes no dish on the menu.
saying these in an interview costs you the question
- The endpoint URL belongs inside the binding element.
- Moving a service to a new host changes its abstract contract.
- Each protocol needs its own copy of the portType and its messages.
- A port may list several addresses so clients can fail over.
- The portType alone tells you the exact XML sent on the wire.