Physical Address
304 North Cardinal St.
Dorchester Center, MA 02124
ISO/IEC 29363 — Web Services Interoperability — WS-I Simple SOAP Binding Profile Version 1.0
Engineering Reference for the WS-I Simple SOAP Binding Profile: Conformance, Serialization, and Interoperability
ISO/IEC 29363 defines the WS-I Simple SOAP Binding Profile Version 1.0, a companion specification that constrains SOAP 1.1 binding practices to achieve the highest possible level of interoperability across heterogeneous web service stacks. While SOAP 1.1 is widely implemented, its flexibility with respect to encoding styles, serialization rules, and transport bindings has historically been a source of interop failures. This profile narrows that flexibility to a well-defined subset — the “simple” binding — that all major platforms (Java, .NET, Python, and C++) can support with consistent results.
The Simple SOAP Binding Profile effectively deprecates SOAP encoding (section 5 of SOAP 1.1 spec) in favor of literal XML representation. Teams designing new web services should default to document/literal with a named wrapper element for maximum toolchain compatibility.
1. Core Binding Constraints and Serialization Rules
The profile mandates a strict subset of SOAP 1.1 features. The most significant constraint is the prohibition of the SOAP encoding style (http://schemas.xmlsoap.org/soap/encoding/). Messages must use literal XML representation, meaning the SOAP body contains the actual XML schema types without encoding-specific artifacts such as soapenc:Array or soapenc:struct. The following table summarizes the key serialization rules.
| Constraint | Requirement | Impact |
|---|---|---|
| SOAP encoding style | MUST NOT be used | Array types use xsd:sequence instead of soapenc:Array |
| Body child namespace | MUST be qualified (not in default namespace) | Prevents ambiguity in element QName resolution |
| use attribute (binding) | MUST be “literal” | No SOAP encoding serialization; XML Infoset preserved |
| transport attribute | MUST be “http://schemas.xmlsoap.org/soap/http” | Only HTTP binding is supported |
| style attribute (binding) | “document” or “rpc” | Both allowed; “document” strongly preferred |
| soap:Header entries | mustUse=”literal” | Header blocks also use literal XML serialization |
| soap:Fault detail | Child elements MUST be namespace-qualified | Ensures fault detail can be reliably processed |
For RPC-style bindings, the profile requires that the wrapper element (the procedure name) be namespace-qualified and that the parts map directly to child elements under the wrapper. Crucially, the soapenc:root attribute and the soapenc:offset attribute used in SOAP Encoding are both prohibited, dramatically simplifying deserialization logic.
A frequent compliance failure is omitting the namespace qualifier on the body child element. When a SOAP body contains unqualified elements, schema-aware validators in .NET and CXF will reject the message with a validation error. Always verify that the body’s first child carries an explicit xmlns attribute or a qualified prefix.
2. Document/Literal vs. RPC/Literal — Engineering Decisions
The profile allows both document/literal and RPC/literal styles, but each carries distinct engineering trade-offs. Document/literal is the preferred pattern because it gives the developer full control over the XML Schema contract — the SOAP body directly contains one or more schema-validated elements. RPC/literal, while simpler to generate from IDL-style interfaces, introduces a wrapper element whose name is derived from the operation name, creating a tighter coupling between the WSDL and the programming model.
For new service development, adopt the document/literal wrapped pattern: define a request wrapper element (e.g., SubmitOrderRequest) and a response wrapper (SubmitOrderResponse). This pattern produces self-describing messages that are easy to validate, version, and route through enterprise service buses.
The table below compares the two binding styles in the context of the profile’s constraints.
| Aspect | Document/Literal | RPC/Literal |
|---|---|---|
| Body contains | One or more schema elements | Operation-name wrapper with child parts |
| WSDL complexity | Requires explicit schema types | Simpler; types inferred from parts |
| Schema validation | Full XSD 1.0 validation applicable | Wrapper element must be defined in schema |
| Versioning | Easier — add optional elements | Harder — changing parts changes the wrapper signature |
| Toolkit maturity | All modern stacks support | Widely supported but considered legacy |
| WS-I conformance | Strongly recommended | Permitted with wrapper constraints |
3. Transport Binding and HTTP Considerations
The profile explicitly restricts the transport binding to HTTP, effectively deprecating SMTP, JMS, and other protocol bindings for WS-I conformance. The SOAP action HTTP header (SOAPAction) must be present, and its value must be a quoted string matching the soapAction attribute in the WSDL binding. Services that omit or miscalculate the SOAPAction header will fail WS-I compliance validation.
A particularly pernicious issue arises when HTTP intermediaries or reverse proxies modify the Content-Type header of SOAP requests. The profile requires Content-Type: text/xml; charset=utf-8. If a proxy rewrites this to application/soap+xml (used by SOAP 1.2), SOAP 1.1 processors will reject the message. Ensure that infrastructure layers do not transform Content-Type headers between SOAP versions.
HTTP status code handling is also constrained: a successful SOAP response must use HTTP 200, while a SOAP Fault must be carried in an HTTP 500 response. Non-standard usage such as HTTP 202 for asynchronous acceptance is outside the profile scope.
4. Conformance Testing and Profile Assertions
The standard includes a comprehensive suite of profile assertions that can be validated using the WS-I Conformance Claim Attachments mechanism. Implementations claiming conformance must satisfy all mandatory assertions, covering envelope structure, serialization rules, header processing, and fault construction. The WS-I Testing Tools provide automated validation; engineering teams should integrate these tools into their CI/CD pipeline to catch regressions early.
For teams using contract-first development (WSDL before code), the profile offers a clear advantage: the WSDL document can be validated against the profile’s constraints at design time, long before a single line of implementation code is written. This catches interoperability problems at the specification stage, where they are cheapest to fix.
Q: Can I use the Simple SOAP Binding Profile with SOAP 1.2?
A: No — the profile is specifically scoped to SOAP 1.1. SOAP 1.2 has its own binding framework defined in the SOAP 1.2 specification and the W3C SOAP 1.2 binding recommendations. The WS-I Basic Profile (BP 1.2) covers SOAP 1.2 scenarios.
Q: Does the profile prohibit multi-reference accessors?
A: Yes, implicitly. Multi-reference accessors are a feature of SOAP Encoding (section 5), which is entirely prohibited. All values must be serialized inline using literal XML; reference-based graphs are not supported.
Q: How do I handle nillable elements in literal serialization?
A: Use xsi:nil=”true” on the element. This is fully compatible with literal XML serialization and is supported by all WS-I compliant toolkits. Do not omit the element entirely unless the schema explicitly makes it optional with minOccurs=”0″.
Q: Is the profile compatible with WS-Addressing?
A: Yes — WS-Addressing headers (wsa:Action, wsa:MessageID, wsa:To, etc.) are SOAP header blocks and are fully compatible with the literal header serialization requirement. The profile does not restrict WS-Addressing usage; it simply requires that header blocks be serialized literally with explicit namespace qualifications.
