XML-RPC: The Simple Ancestor
Dave Winer published the XML-RPC spec in 1998. The idea was pragmatic: call functions on remote servers using HTTP and XML. POST an XML document describing the method name and parameters to a URL, get back an XML document with the result. The entire spec fit on one page. It supported basic types and nothing else. Intentional constraint.
SOAP: When Simple Gets Complicated
SOAP (Simple Object Access Protocol) started as a Microsoft refinement of XML-RPC in 1999. By SOAP 1.1 (2000, W3C), it had grown into a complete messaging framework. SOAP envelopes wrapped any XML payload. The protocol was transport-agnostic: you could send SOAP over HTTP, SMTP, JMS, or raw TCP. Headers provided an extensible mechanism for metadata. Faults provided structured error information.
SOAP itself was manageable. The ecosystem that grew around it was not. SOAP was the foundation for WS-Star, a family of specifications that stacked on top: WS-Security for message signing and encryption, WS-ReliableMessaging for guaranteed delivery, WS-AtomicTransaction for distributed transactions, WS-Coordination for orchestrating these, WS-Policy for declaring service capabilities. Each spec had hundreds of pages. Each had multiple partial implementations.
WSDL: Machine-Readable Contracts
WSDL (Web Services Description Language) was the SOAP ecosystem answer to API documentation. A WSDL file described every operation your service supported, the exact XML types for every request and response, and the endpoint URL. Tools could generate client stubs from a WSDL. IDEs could provide autocomplete. You could validate a request against a WSDL schema before it ever hit the network.
This idea - a machine-readable contract that tools can process - is genuinely valuable. OpenAPI/Swagger is a direct descendant. The difference is that a WSDL file for a modest service could be 2,000 lines of XML, while an equivalent OpenAPI spec is 200 lines of YAML.
The Enterprise Service Bus
The ESB (Enterprise Service Bus) extended the SOAP model to integration middleware. Instead of services calling each other directly, everything went through a central bus that handled routing, transformation, orchestration, and protocol mediation. IBM WebSphere, Oracle SOA Suite, TIBCO BusinessWorks - million-dollar products running in the core of every major enterprise.
The ESB promised to solve integration once and for all. It created a single point of failure, a massive operational burden, and a chokepoint that every message in the enterprise had to pass through. Microservices architecture was partly a reaction to the ESB: distribute the integration logic, not centralize it.
What the Industry Kept
The WS-Star stack did not disappear. Financial services, healthcare, and government systems still run SOAP services built in 2002. The ideas that survived: machine-readable contracts (OpenAPI), structured error responses (RFC 7807 Problem Details), and message-level security patterns (JWT). The implementation got simpler. The underlying problems were real.
SOAP's Genuine Technical Contributions
It is easy to mock SOAP in retrospect, but the problems it tried to solve were real. Enterprise systems genuinely need reliable message delivery across unreliable networks. They need end-to-end message-level security that survives being routed through multiple intermediaries (transport-level TLS only protects point-to-point). They need distributed transactions that span multiple services. WS-ReliableMessaging, WS-Security, and WS-AtomicTransaction were serious attempts at serious problems. The implementations were terrible and the specifications were unusable, but the problem statements were correct.
These problems did not disappear when REST won. They moved to different layers. Reliable message delivery is now Kafka with consumer group offsets and at-least-once delivery guarantees. Message-level security is now JWTs (signed, not encrypted) or JOSE (JSON Object Signing and Encryption) for end-to-end encryption. Distributed transactions are now the saga pattern and outbox pattern. The SOAP ecosystem built these capabilities into the protocol layer. Modern systems build them into the application and infrastructure layers. The capabilities exist; the packaging is different.
WSDL as OpenAPI's Direct Ancestor
The OpenAPI ecosystem is a direct descendant of WSDL's vision: one machine-readable contract, many tool-generated artifacts. The difference is one of pragmatics. A WSDL for a banking service might be 10,000 lines of XML with namespaces, embedded schema definitions, binding specifications, and port type declarations. An equivalent OpenAPI 3.0 spec is 500 lines of YAML. The conceptual model is identical. The representation is dramatically more accessible.
Modern API development tools have fully realized what WSDL promised. Swagger UI generates interactive documentation from OpenAPI specs. OpenAPI Generator creates typed client SDKs in 40+ languages. Pact uses OpenAPI as the basis for consumer-driven contract testing. Postman collections can be generated from OpenAPI. The WSDL dream of 'write the contract once, generate everything else' is now fully achievable with tooling that developers actually enjoy using.
- Write OpenAPI spec first, before implementation. The act of specifying clarifies design decisions that are invisible in code.
- Use semantic versioning in your API spec and communicate breaking changes through the spec before deploying them.
- Contract testing (Pact, Dredd) uses your spec as an executable contract. Tests that validate both client and server against the spec catch drift before production.
- The best documentation is always generated from a single source of truth. Never maintain documentation separately from the API spec.
- SOAP's enterprise deployment patterns (DMZ, service registry, message transformation) still appear in API gateway architectures. The vocabulary changed; the topology did not.
SOAP in 2024: Where It Still Lives
SOAP is not dead. It has outlived every announcement of its death. Banking systems (SWIFT messaging), healthcare interoperability (HL7 FHIR's SOAP binding), government services (many national ID and tax systems), and telecom infrastructure (SS7 and DIAMETER protocol gateways expose SOAP APIs) all use SOAP in production. If you work in one of these industries, you will integrate with SOAP services. Knowing how to consume them is a practical skill.
Python's zeep library, Java's JAX-WS, and .NET's WCF are the standard tools for consuming SOAP services. Most modern integrations generate client code from the WSDL using these tools, which encapsulates the XML handling. The developer experience is not as bad as writing SOAP by hand - it is roughly equivalent to using any typed API client. The complexity is in finding, understanding, and negotiating access to the WSDL, not in writing the actual integration code once you have it.
The WS-* Lessons Applied to Modern Microservices
The WS-* specifications failed to achieve adoption partly because they were too ambitious - they tried to solve every distributed computing problem in a single protocol layer. Modern microservices have distributed the same set of problems across multiple layers and tools, which is why they work. WS-ReliableMessaging is now Kafka with consumer acknowledgments. WS-Security's message integrity is now request signing (AWS Signature V4, mTLS between services). WS-AtomicTransaction is now the saga pattern with compensating transactions. WS-Policy is now service mesh configuration (Istio policies, Kubernetes RBAC). The problems are the same. The implementations are more composable.
SOAP's Genuine Technical Contributions
It is easy to mock SOAP in retrospect, but the problems it tried to solve were real. Enterprise systems genuinely need reliable message delivery across unreliable networks. They need end-to-end message-level security that survives being routed through multiple intermediaries (transport-level TLS only protects point-to-point). They need distributed transactions that span multiple services. WS-ReliableMessaging, WS-Security, and WS-AtomicTransaction were serious attempts at serious problems. The implementations were terrible and the specifications were unusable, but the problem statements were correct.
These problems did not disappear when REST won. They moved to different layers. Reliable message delivery is now Kafka with consumer group offsets and at-least-once delivery guarantees. Message-level security is now JWTs (signed, not encrypted) or JOSE (JSON Object Signing and Encryption) for end-to-end encryption. Distributed transactions are now the saga pattern and outbox pattern. The SOAP ecosystem built these capabilities into the protocol layer. Modern systems build them into the application and infrastructure layers. The capabilities exist; the packaging is different.
WSDL as OpenAPI's Direct Ancestor
The OpenAPI ecosystem is a direct descendant of WSDL's vision: one machine-readable contract, many tool-generated artifacts. The difference is one of pragmatics. A WSDL for a banking service might be 10,000 lines of XML with namespaces, embedded schema definitions, binding specifications, and port type declarations. An equivalent OpenAPI 3.0 spec is 500 lines of YAML. The conceptual model is identical. The representation is dramatically more accessible.
Modern API development tools have fully realized what WSDL promised. Swagger UI generates interactive documentation from OpenAPI specs. OpenAPI Generator creates typed client SDKs in 40+ languages. Pact uses OpenAPI as the basis for consumer-driven contract testing. Postman collections can be generated from OpenAPI. The WSDL dream of 'write the contract once, generate everything else' is now fully achievable with tooling that developers actually enjoy using.
- Write OpenAPI spec first, before implementation. The act of specifying clarifies design decisions that are invisible in code.
- Use semantic versioning in your API spec and communicate breaking changes through the spec before deploying them.
- Contract testing (Pact, Dredd) uses your spec as an executable contract. Tests that validate both client and server against the spec catch drift before production.
- The best documentation is always generated from a single source of truth. Never maintain documentation separately from the API spec.
- SOAP's enterprise deployment patterns (DMZ, service registry, message transformation) still appear in API gateway architectures. The vocabulary changed; the topology did not.
SOAP in 2024: Where It Still Lives
SOAP is not dead. It has outlived every announcement of its death. Banking systems (SWIFT messaging), healthcare interoperability (HL7 FHIR's SOAP binding), government services (many national ID and tax systems), and telecom infrastructure (SS7 and DIAMETER protocol gateways expose SOAP APIs) all use SOAP in production. If you work in one of these industries, you will integrate with SOAP services. Knowing how to consume them is a practical skill.
Python's zeep library, Java's JAX-WS, and .NET's WCF are the standard tools for consuming SOAP services. Most modern integrations generate client code from the WSDL using these tools, which encapsulates the XML handling. The developer experience is not as bad as writing SOAP by hand - it is roughly equivalent to using any typed API client. The complexity is in finding, understanding, and negotiating access to the WSDL, not in writing the actual integration code once you have it.
The WS-* Lessons Applied to Modern Microservices
The WS-* specifications failed to achieve adoption partly because they were too ambitious - they tried to solve every distributed computing problem in a single protocol layer. Modern microservices have distributed the same set of problems across multiple layers and tools, which is why they work. WS-ReliableMessaging is now Kafka with consumer acknowledgments. WS-Security's message integrity is now request signing (AWS Signature V4, mTLS between services). WS-AtomicTransaction is now the saga pattern with compensating transactions. WS-Policy is now service mesh configuration (Istio policies, Kubernetes RBAC). The problems are the same. The implementations are more composable.