skip to content

A client generated from a partner's WSDL 1.1 fails against the service although both stacks claim SOAP 1.1; which WS-I Basic Profile binding rules would you check, and why?

level: seniorimportance: should knowfreq 16%

answer

  1. a profile narrows a specification
  2. literal only, two shapes
  3. one part, unique signatures
  4. quoted SOAPAction, POST, 500 for faults

basics

~20 s

Check the binding against WS-I Basic Profile 1.1: literal use only, rpc-literal or document-literal with at most one document part, a distinct operation signature per operation, a quoted SOAPAction matching the binding, POST, and HTTP 500 for faults.

solid answer

~40 s

WS-I Basic Profile 1.1 exists because SOAP 1.1 and WSDL 1.1 left too many choices open for two conformant stacks to agree. Check the binding first: every `soapbind:body`, `fault`, `header` and `headerfault` must use `literal` (R2706), and the binding must be rpc-literal or document-literal (R2705). A document-literal body may list at most one part (R2201), defined with `element` (R2204). Each operation must produce a distinct **operation signature**, the qualified name of the Body's child (R2710), or the endpoint cannot dispatch. Then check the HTTP layer: `POST` only (R1132), a `SOAPAction` that is a quoted string equal to the binding's `soapAction` or `""` (R1109, R2744, R2745), and `500` for a Fault (R1126). The usual culprits are encoded arrays, a multi-part document binding and an unquoted or missing `SOAPAction`.

go deeper

for a junior

Recall that the WS-I Basic Profile narrows SOAP and WSDL so different stacks interoperate, and that it allows only literal use.

for a middle

Explain rpc-literal versus document-literal under the profile, the one-part rule and why operation signatures must be unique.

for a senior

Diagnose a failing integration from a wire capture: encoded payloads, duplicate signatures, a missing or unquoted SOAPAction, and fix the contract rather than the generated client.

for a principal

Decide how strictly to enforce profile conformance on partner contracts, and when a legacy encoded service is better wrapped than rewritten.

## Why a profile exists SOAP 1.1 and WSDL 1.1 were both W3C Notes with generous optionality: two styles, two uses, any encoding, any transport URI, `SOAPAction` with or without quotes. Two stacks could each follow the texts and still fail to exchange a single call. The **WS-I Basic Profile** is a set of numbered requirements (R-numbers) that removes those choices. Version 1.1 (final 2006) profiles SOAP 1.1 and WSDL 1.1; BP 1.2 keeps SOAP 1.1, and BP 2.0 moves to SOAP 1.2 and says its messages are inherently incompatible with BP 1.1's. When a generated client and a service disagree, walking the profile's binding rules is the fastest way to find which side left the interoperable subset. ## Step 1: the binding shape | Rule | Requirement | Typical violation | |---|---|---| | R2401 | use the WSDL 1.1 SOAP binding (WSDL 1.1 section 3) | a custom binding extension | | R2702 | the `transport` is the SOAP HTTP transport URI | another transport URI | | R2705 | binding is rpc-literal or document-literal | any encoded combination | | R2706 | `literal` in every `soapbind:body`, `fault`, `header`, `headerfault` | `use="encoded"` with SOAP encoding | | R2201 | a document-literal `soapbind:body` lists at most one part | two element parts under the Body | | R2204 | document-literal parts use `element` | a part declared with `type` | | R2203 | rpc-literal parts use `type` | a part declared with `element` | | R2710 | operations in a binding have different operation signatures | two operations sharing one input element | Encoded use is the classic failure. SOAP 1.1 Section 5 encoding allows multi-reference values (`id` and `href`), `SOAP-ENC:arrayType` arrays and `xsi:type` annotations in several equivalent forms; WSDL 1.1 calls this "reader makes right", and readers did not all make it right. The profile simply prohibits encodings. ## Step 2: dispatch The profile defines the **operation signature** as "the fully qualified name of the child element of SOAP body of the SOAP input message". An endpoint has to work out which operation was invoked from that name. In rpc-literal the wrapper named after the operation guarantees uniqueness; in document-literal the designer must ensure it, which is one reason the operation-named wrapper element convention spread. If two operations take the same element, a server that dispatches on the Body cannot tell them apart and may invoke the wrong one or fault. ## Step 3: the HTTP layer 1. **Method:** a request MUST use `POST` (R1132); the HTTP Extension Framework's `M-POST`, which SOAP 1.1 allowed, is prohibited (R1108). 2. **`SOAPAction`:** the value MUST be a quoted string (R1109). It must equal the binding's `soapAction` when one is declared (R2744), and be `""` when none is declared or it is empty (R2745). The profile calls the header "purely a hint", but some stacks reject a request whose header is missing or unquoted. 3. **Status codes:** a Fault MUST come back with `500 Internal Server Error` (R1126); a non-fault envelope SHOULD use `200` (R1111); the profile also recommends `400` for a malformed HTTP request, `405` for a method other than POST and `415` for a `Content-Type` the description does not permit. ## A diagnosis order that works 1. Capture one failing request and response on the wire, not the generated code. 2. Compare the Body's child with the binding: one element, the declared qualified name, no `encodingStyle` attributes (R1005 to R1007 forbid them on envelope elements, Body children and rpc-literal grandchildren). 3. Compare `SOAPAction` with the binding's `soapAction`, byte for byte including quotes. 4. Check the status code and Content-Type of the response against what the client expects. 5. If the WSDL itself violates the profile, fix the contract, not the client: a generated client faithfully reproduces whatever the description says. ## What the profile does not settle Conformance is a claim, and many descriptions in the wild predate it or ignore it. The profile also leaves real choices open: rpc-literal versus document-literal, the shape of the schema, and whether SOAP 1.1 or SOAP 1.2 (BP 2.0) is used at all. A failure between a SOAP 1.1 client and a SOAP 1.2 endpoint is a version mismatch, not a profile violation. Finally, a profile check proves only that both sides chose the same subset. It does not prove that the schemas agree on optional elements, that both read the same namespace version of the contract, or that the service behaves as documented; those still need contract tests against captured messages.

  • Two operations in a document-literal binding take the same input element. What fails, and how do you fix it?
    The binding breaks R2710: both operations have the same operation signature, so the endpoint cannot tell from the Body which one was invoked. Give each operation its own input element, usually named after the operation, or merge the two operations.
  • Does WS-I Basic Profile 1.1 cover SOAP 1.2 services?
    No. BP 1.1 and BP 1.2 profile SOAP 1.1; BP 2.0 is the first version that profiles SOAP 1.2, and it states that BP 1.1 conformant messages are inherently incompatible with BP 2.0 ones.
  • Why does the profile insist that SOAPAction be quoted when HTTP allows unquoted header values?
    Testing showed some SOAP implementations required quotes, so mandating them removed one interop failure for free. R1109 requires a quoted string, and R2744 and R2745 tie the value to the binding's soapAction or to an empty quoted string.

saying these in an interview costs you the question

  • A document-literal binding may list several Body parts if each one uses element.
  • Encoded use is safe as long as both sides declare the SOAP encoding URI.
  • SOAPAction can be omitted under the profile because the Body identifies the operation.
  • A generated client cannot be wrong if the WSDL compiled without errors.
  • Basic Profile 1.1 also governs SOAP 1.2 messages.