SOAP: XML Messaging Protocol
- SOAP is an XML-based messaging protocol that structures requests and responses with an Envelope, optional Header, and mandatory Body.
- It integrates with WSDL and security standards like WS-Security and XML Digital Signatures to ensure protocol compliance and message integrity.
- SOAP supports multiple transport bindings and flexible payload handling to achieve interoperability and scalable security in distributed architectures.
Searching arXiv for SOAP web-services papers to ground the article in relevant sources.
SOAP, the Simple Object Access Protocol, is an XML-based messaging framework for exchanging structured information in a decentralized, distributed environment. In service-oriented architectures, it acts as an envelope model for requests and responses between service consumers and providers: a SOAP message contains a single <Envelope>, an optional <Header>, and exactly one <Body>, while the application-level payload is defined outside SOAP itself, typically through WSDL-described operations and XML schemas. Because SOAP is purely XML, it can be carried over HTTP, SMTP, JMS, or other transports, and it is commonly composed with specifications such as WS-Security and MTOM to provide integrity, authenticity, and efficient transfer of binary content (Schaaff et al., 2011, 0812.4181).
1. Message model and processing semantics
SOAP strictly defines message structure rather than application semantics. The <Envelope> is the outer container; the <Header> carries processing metadata such as security or routing information; and the <Body> contains the application payload. In conformant message formatting, the envelope has at most one header followed by exactly one body, and no other elements may appear as direct children of <soap:Envelope>. User-defined payload elements must reside in their own XML namespace rather than the SOAP namespace, whereas the Envelope, Header, Body, and Fault elements must come from the standard SOAP namespace (Schaaff et al., 2011).
Within SOA deployments, the message model is paired with interface descriptions in WSDL. Operations are exposed through a WSDL interface and invoked by sending a SOAP request; the response is likewise a SOAP message. This division of responsibilities is central: SOAP supplies the envelope and processing model, while WSDL and XML Schema define operation signatures and payload structure. A minimal exchange therefore consists of an XML envelope whose body contains operation-specific content, with optional headers for concerns such as security, routing, or intermediary processing (0812.4181).
A persistent misconception is that SOAP intrinsically determines the payload model. The standards described here indicate the opposite: SOAP defines the wrapper and processing slots, but not the business-level document vocabulary. This separation is a major reason SOAP could be deployed across heterogeneous platforms and toolkits, but it also means that interoperability depends heavily on binding conventions and profile compliance rather than on the envelope alone.
2. Versions, bindings, and interoperability constraints
Two versions are explicitly described in the cited profile literature. SOAP 1.1 is defined at http://www.w3.org/TR/soap/ with namespace http://schemas.xmlsoap.org/soap/envelope/, and SOAP 1.2 is defined at http://www.w3.org/TR/soap12-part1/ with namespace http://www.w3.org/2003/05/soap-envelope. The IVOA Web Services Basic Profile 1.0 mandates conformance with WS-I Basic Profile 1.1, which is based on SOAP 1.1, even though many toolkits also support SOAP 1.2 (Schaaff et al., 2011).
Interoperability profiles impose constraints beyond the core envelope grammar. At the highest level, SOAP-based VO services must conform to WS-I Basic Profile 1.1 and WS-I Simple SOAP Binding Profile 1.0. These profiles forbid SOAP Encoding, require body parts to be literal, and state that WSDL bindings shall use style="document", with RPC style discouraged and, if used, still required to remain literal. For SOAP 1.1 bindings, soap:binding/@transport uses http://schemas.xmlsoap.org/soap/http; for SOAP 1.2, it uses http://www.w3.org/2003/05/soap/bindings/HTTP/. Each wsdl:operation must include a soapAction attribute, and SOAP requests must be enclosed in HTTP POST rather than GET, PUT, or DELETE (Schaaff et al., 2011).
The profile also standardizes operational details that are easy to overlook in ad hoc deployments. For SOAP 1.1 over HTTP, the Content-Type must be text/xml; charset=utf-8; a normal SOAP response uses HTTP 200; and a SOAP Fault should use HTTP 500. The SOAP 1.1 fault structure includes <faultcode>, <faultstring>, optional <faultactor>, and optional <detail>, with the <detail> payload defined in WSDL or XSD. Conformance is checked with WS-I Testing Tools, specifically the Monitor and Analyzer, by capturing sample HTTP/SOAP exchanges and validating them against WS-I assertion files (Schaaff et al., 2011).
These constraints are not merely stylistic. They reduce ambiguity in namespace handling, serialization style, dispatch, and transport behavior, allowing client stubs and server frameworks to interoperate predictably. A plausible implication is that many practical SOAP failures attributed to “SOAP complexity” are in fact profile violations or binding mismatches rather than defects in the core envelope model.
3. WS-Security, XML signatures, and XML rewriting attacks
SOAP’s XML substrate makes it naturally composable with WS-Security, which places security headers in the SOAP header and commonly relies on XML Digital Signature to guarantee integrity and authenticity for selected parts of the message. An XML signature signs canonicalized XML fragments rather than raw byte streams, which may be summarized as
At verification time, each Reference resolves a node by URI, canonicalizes it, hashes it, and compares the result to the stored DigestValue; the verifier then checks the SignatureValue over the SignedInfo block (0812.4181).
The principal weakness discussed in the XML rewriting literature is that a reference such as URI="#foo" identifies an element by wsu:Id, but does not assert where that element is located in the SOAP tree. As a result, an attacker who cannot break the cryptography may still move, wrap, or duplicate signed nodes without invalidating the signature, provided that the referenced subtree remains unchanged. In the canonical attack pattern, an adversary intercepts a signed request, relocates the signed body into a different subtree, injects a new body with altered application data, and relies on the fact that standard XML-DSig validation still succeeds because the original node with the referenced identifier remains present and hashes identically (0812.4181).
This attack class demonstrates that successful XML-signature verification does not, by itself, imply preservation of SOAP message semantics. The proposed hardening strategy is to bind content to location by signing, for each referenced node, the triplet
Verification then checks not only the digest and signature value, but also whether the current depth and parent identifier match the signed metadata. The recommendation is to attach wsu:Id attributes to all signed header and body elements, enforce uniqueness of those IDs, and validate both depth and parent information before dispatching the message to business logic (0812.4181).
A common misconception is that SOAP insecurity is caused by XML signatures being “weak cryptography.” The cited analysis indicates a different diagnosis: the cryptographic primitives are not broken; rather, the indirection between a signed fragment and its document location creates a structural integrity gap unless location semantics are also protected.
4. Integrity and authentication without confidentiality: HTTPI over SOAP
Some SOAP deployments do not require confidentiality but do require endpoint authentication and message integrity. For such “open applications,” an alternative design combines SOAP, WS-Security, and HTTPI. In this model, authentication is provided either by a UsernameToken or by an X.509 BinarySecurityToken, integrity is provided by an XML Signature such as RSA-SHA1 over the SOAP body and selected headers, and session continuity is represented by an httpi:Continue header carrying a nonce, a session identifier, and a message number. For UsernameToken, the password digest is
The protocol establishes a non-encrypted session in three signed messages: client request with nonce and empty session, server response echoing the nonce and returning a fresh session identifier, and client request referencing the agreed session identifier (Choudhary et al., 2013).
The reported performance comparison uses four scenarios: no security, UsernameToken only, HTTPI with signature and X.509, and full signature plus encryption over HTTPS. Under the described soapUI load test, the average response time is 19.56 ms for no security, 26.20 ms for UsernameToken only, 30.45 ms for HTTPI, and 43.16 ms for signature plus encryption; throughput is 6.81, 5.79, 5.14, and 4.01 transactions per second, respectively; and reply size grows from approximately 600 bytes to approximately 1,440 bytes, with HTTPI at approximately 1,020 bytes (Choudhary et al., 2013).
The architectural significance of this result is narrow but clear. SOAP security does not always require transport confidentiality, and a message-level design can target integrity and authentication specifically. This suggests a more differentiated view of SOAP security stacks: HTTPS is not the only secure deployment pattern, and the choice between transport security and message security depends on whether confidentiality is actually a requirement.
5. MTOM, large binary payloads, and non-blocking signature generation
SOAP’s XML format is inefficient for large binary payloads unless binary transfer is externalized. MTOM, together with WS-Security, is the W3C-recommended mechanism for streaming binary data efficiently while still applying XML Signature. However, the standard signing process for SOAP with MTOM is blocking: the sender reconstructs the logical XML Infoset by base64-encoding each binary chunk, computes all <ds:DigestValue> elements and then the <ds:SignatureValue>, injects the signature into the SOAP header, and only then reverts to raw MTOM streaming for transmission. For large attachments, this causes a 33% data expansion plus memory for the DOM, an sender-side delay before any bytes are placed on the wire, and even out-of-memory failures in practice, including Axis2 failures on files larger than a few hundred megabytes (0709.2635).
The non-blocking alternative exploits the observation that attachment digests can be computed while the data is being streamed, and that the final signature can be deferred until the end of the multipart MIME message. The SOAP header’s <ds:Signature> contains an XOP <xop:Include> pointing to a not-yet-sent MIME part for the signature. Each MTOM DataHandler updates a MessageDigest while streaming bytes from local storage to the HTTP socket, so no base64 reification and no Infoset build are required. After the last payload chunk has been transmitted, the handler computes the final digital signature over the digests and emits the resulting signature as the last MIME part (0709.2635).
The timing model given in the paper formalizes the gain. For payload size , network throughput , base64-plus-DOM time , and XML-signature time ,
whereas for the streaming method
with intermediate digest computation overlapped with transmission. The reported speedup is approximately
0
Experimentally, a no-security baseline reaches approximately 70% of a 100 Mbps link, blocking signing reduces throughput by approximately 50% and causes out-of-memory failures on large files, while streaming signing reaches approximately 75% of baseline and remains stable for multi-hundred-megabyte payloads (0709.2635).
This case is important because it contradicts the assumption that SOAP’s overhead is invariant once MTOM is enabled. The cited results show that message-security implementation strategy, not just envelope syntax, can dominate end-to-end performance for bulk-transfer services such as data staging or e-health imaging.
6. Serialization choices, transport bindings, and operational trade-offs
SOAP payloads may be transmitted either as normal XML-textual content in the <soap:Body> or as serialized Java-object bytes embedded in the envelope, for example as a Base64-encoded blob. In experiments comparing SOAP over HTTP and SOAP over JMS, with payload sizes stepped from 1 MB to 22 MB and each data point averaged over 45–50 runs, the timing components grow roughly linearly in message size 1:
2
and the total transaction time is expressed as
3
At 22.2 MB, normal SOAP over HTTP yields 4 ms, 5 ms, and 6 ms, while serialized SOAP over HTTP yields 7 ms, 8 ms, and 9 ms. Over JMS at the same size, normal SOAP yields 0 ms and serialized SOAP yields 1 ms (Dauda et al., 2020).
The reported causes of overhead are specific rather than generic. Serialization and deserialization are CPU-intensive because they traverse object graphs, encode type metadata and references, and copy large byte arrays. Serialized payloads can be up to 5–10% larger than pure XML because of padding, object headers, and class descriptors. Stateless HTTP POST amplifies client blocking and channel reestablishment overhead, while repeated object churn in the JVM produces garbage-collection spikes accounting for 5–25% of runtime, especially between 13 MB and 22 MB. JMS avoids repeated handshake costs through a persistent session, although JNDI lookup and deserialization can still introduce transient latency (Dauda et al., 2020).
Taken together, these observations sharpen several recurring misunderstandings about SOAP. SOAP is not synonymous with HTTP, since it can also ride on JMS and other transports. Serialization does not uniformly improve performance; under HTTP it is markedly worse in the reported experiments, while under JMS it is modestly better at large sizes. Security does not always imply confidentiality, since HTTPI-based SOAP targets integrity and authentication without encryption. And successful XML-signature verification does not guarantee semantic integrity unless document location is also protected. In that sense, SOAP is best understood not as a single protocol behavior, but as an XML messaging framework whose practical properties emerge from the combined choices of version, profile, transport, security composition, and payload handling strategy (Dauda et al., 2020).
